unusual communications problem

C

c6jones720

Member
Hi guys, I wondered if anyone could help me.

I've written some code for bidirectional serial communications using a standard picaxe 18. Ive managed to get around the serin wait forever problem so my program does useful stuff while it waits for a valid bayte on its serial input. That all works perfectly fine on the standard picaxe 18 (Ive tried it one about three different chips).

Ive just opened up a new tube of picaxe 18A parts (set to 4MHz) and put exactly the same program onto one of those and it dosent work at all. chips okay, wiring & PSU are okay the only difference is the picaxe part number. Does anybody know why there might be a difference between the 18 and the 18A chips?
 
hippy

hippy

Ex-Staff (retired)
Theoretically there should be no difference, but the PICAXE-18A has a narrower operating volatge range ( 4.0V-5.5V ) than the PICAXE-18 ( 3.0-5.5V ), there are different amounts of SFR if you are using that, and I recall the 18A has a wider manufacturer's tolerance on the internal oscillator ( +/-5% @ 25'C, +/-25% otherwise ) than the 18, and frequency does vary with temperature, and possibly voltage.

If bit-banged serial as the PICAXE uses is out of spec by around 6% ( ie +3% and -3% at each end etc ) it can cause serial problems.

There do seem to be more problems reported on this forum with the 18A relating to download than other PICAXE's, and you may have run into a baud rate tolerance issue.

Not sure what you configuration is or what you are communicating with but it's probably worthwhile checking that your 18A's can send to the Programming Editor Terminal and echo data received properly ( they should if downloading worked ), and then see if they can communicate with each other if that's what you are doing. It might be worth checking that if an 18-to-18 works and 18A-to-18A doesn't, what happens with an 18-to-18A.

Apart from simply guessing what may have gone wrong you'll have to start experimenting and debugging to identify what does work and what doesn't, and try and determine what the problem is. Changing temperature could mean that the problem may only be intermittant - That could be why at one time you thought "SETFREQ M4" had fixed it, but hadn't ?

If you've got access to a scope or logic analyser you could look at the signals the PICAXE is putting out to check timing, and you could try playing with the CALIBFREQ command.

Edited by - hippy on 17/06/2006 15:23:39
 
C

c6jones720

Member
thankyou for your prompt reply.

Thats just it. I am actually sitting right here with my scope. When I use the 18A I can see the serial data frames coming out of it but when I connect it to hyperterminal, hyperterminal only sometimes picks up bytes. Ive tried using a 180r resitor in series with the serial out and removing it and it dosent make any difference.

When I connect and disconnect the picaxe TXD wire from the circuit hyperterminal sometimes reports bytes. Thing is I know for sure thats not a bad conection because with an 18 standard I simply dont have these sort of problems. (PSU supply is 5.01v)
 
hippy

hippy

Ex-Staff (retired)
If it is a baud rate problem, it's an intrinsic issue with the underlying PICmicro, and your best bet ( other than using a different PICAXE type ) would be to try the CALIBFREQ command. If it is a temperature related problem, you may have to re-select a new CALBIFREQ value if temperature does change.

You should be able to write a program which varies the CALIBFREQ value, and prints that value along with some text through HyperTerminal, so you can see which ( if any ) gives reliable results.

This bypasses CALIBFREQ and uses a direct poke to the OSCTUNE register ...

- MainLoop:
- FOR b0 = 0 TO 63
- POKE $90,b0
- PAUSE 1000
- SEROUT pin,baud,("Using ",#b0," - The quick brown fox ...",CR,LF)
- NEXT
- GOTO MainLoop

Edited by - hippy on 17/06/2006 15:42:40
 
You must log in or register to reply here.
Top