20x2 64Mhz testing

jmumby

Senior Member
Has anyone had a crack at running a 20x2 at this speed? What is the theoretical maximum baud do you think? Any kiwi's know where to find the correct resonators?
 

Dave E

Senior Member
The 20X2 does not need external resonators. It has everything you need built in. Very handy chip.
I run them at 64MHz with a 19200 baud serial output to an LCD.

Dave E
 

MartinM57

Moderator
What is the theoretical maximum baud do you think?
I've used 115200 with no problems.

However, without an external resonator, the chip is running on its own internal oscillator which:
-isn't as accurate as an external resonator
-(I believe - but data sheet analysis will tell) drifts with temperature more than an external resonator

The danger is that the internal oscillator will be out by, or drift by, enough to cause baud rates to go out of spec and comms to fail.

For anything other than playing around, I would always use a resonator controlled PICAXE, which unfortunately usually precludes me from using 20X2's at 64Mhz for serious work i.e. where I have to rely on baud rates being in spec, all the time and at all reasonable temperatures
 

hippy

Technical Support
Staff member
Theoretical maximum baud rate at 64MHz will be 1,000,000 baud ( 1Mbps ).

Though receiving 1 million bits in a second ( 100,000 bytes per second ) is unlikely to be achievable, with suitable pacing ( gaps / pauses between each byte sent ) it should be possible to use 1Mbps comms. Not that it would really make much sense to do it that way in most cases.

Using the 20X2 background receive buffer it is possible to send at any allowable baud rate and receive back what was sent by linking TX to RX in what's commonly called 'loopback' mode. This allows various baud rates to be tested and you can look at the signals on TX and RX. You can add lengths of cable between TX and RX to see what effect length of cable has and this way determine what issues may occur between two 20X2 over that length of cable.

Internal oscillator drift is an issue with serial comms but in general serial comms is tolerant to around +/-6% combined baud rate error of transmitter and receiver. If the transmitter is 2% fast and receiver 2% slow that should still work ( 4% combined error ). This is regardless of actual baud rate, fast or slow, though it depends on how the receive is implemented; bit-banged reception may require lower error than an on-chip UART baud rate error at higher baud rates. Distortions of the signal caused by cable will also create some error in itself.

Internal oscillator error comes down to manufacturing accuracy, natural drift and change caused by temperature and voltage. If the later two can be controlled there should be very little change in any error other than through natural drift. They often cannot so devices with external crystals or resonators would be recommended for reliable communications. In most cases there usually is no problem, but a comms link from indoors to outside where temperatures may vary widely ( -10C to +40C say ) and power comes from unregulated solar panels or batteries which deplete over time and problems are far more likely to arise. It is however possible to adjust baud rates to compensate if there is no rapid change in baud rate. Easier though to use external crystals and resonators to avoid all that though.
 

SGraham

New Member
What am I missing?

I have a project using a 20X2. I had a #freq m4 line in the code but found some parts of the code was running slow so I tryed changing the #freq comand. I get an error saying "invalid #freq value forthis type -" for any #freq value but m4 and No #freq line. I am using the internal resonator. I am using the Version 5.2.7 Programming Editor.
Why can't I use m8,m16,m32 or m64?

S Graham.
 

hippy

Technical Support
Staff member
For the 20X2 you can simply forget about "#Freq" directives - they are only used to control the download link speed once a SETFREQ had been issued on earlier PICAXE chips.

The SETFREQ command is what sets the operating speed; so drop the "#Freq" and add a "SETFREQ M64" or whatever you require.

The PICAXE will download correctly no matter what speed it is operating at, no matter what previous SETFREQ has been executed. The only time it will not download is if SERRXD or DISCONNECT has been executed or the PICAXE is waiting for input ( SERIN, IRIN etc ) and does not notice the download.

We would also recommend downloading the latest 5.2.9 version of the Programming Editor.
 

moxhamj

New Member
I've just checked our local supplier Microzed. 20X2 for $13.85. Very nice!

(As an aside, good to see Westy's Pebble on the main page as a download)

The 20X2 with the fast clock opens up some new possibilities. I've been pondering a "baud rate translator" - eg feed it a few bytes at 1200 baud and it spits them out another pin at 9600 baud. For those devices that only can talk at a certain frequency.

The fast clock also is going to be useful for all sorts of things.
 

hippy

Technical Support
Staff member
Converting-up of baud rates is easy with any PICAXE which supports background receive, slow incoming to HSERIN pin, fast output via SEROUT ...

#Picaxe 20X2
#No_Data
#No_Table
#Terminal 9600

HSerSetup B1200_8, %111
Do
Do : Loop Until ptr <> hSerPtr
SerOut B.0, N9600, ( @ptrinc )
Loop

Dropping baud rates has problems though as while outputting at a slow baud too much may come in at a fast baud while it's busy doing that so data can get lost.
 
Top