Strange behavior of 20X2

Again a strange behavior of 20x2 connected to a AXE033 - try to look at this very simple program:

#picaxe 20x2
#No_Data
#No_Table

let dirsB = %11111111
let w0 = 0

loop1:
w0 = w0 + 1
serout b.0,N2400, (254,1)
;serout 4,N2400, (254,1)
pause 30
serout b.0,N2400, (254,128,#w0)
;serout 4,N2400, (254,128,#w0)
pause 500
goto loop1

Click to expand...

The LCD start counting OK from 1 to 9, but then things goes wrong. The numbers 10, 11, 12 are shown as 1%, 1%, 1%, where % indicates garbage. That means many strange characters.
It is always the least significant digit that goes wrong.
Number like 20, 21, 22 shows as 2%, 2%, 2% and 55, 56 shows as 5%, 5%.
And the number 356 shows as 35%. (again % indicates garbage).
When I use Sertxd instead of the Serout commands everything looks OK.
Also nearly the same program used on a Picaxe 08M works perfectly.

#picaxe 08m
#No_Data
#No_Table

let w0 = 0

loop1:
w0 = w0 + 1
serout 4,N2400, (254,1)
pause 30
serout 4,N2400, (254,128,#w0)
pause 500
goto loop1

Click to expand...

What happens here or what do I do wrong?

If you are using the internal oscillator, it could be a baud rate problem.
Have read of and a play with CALIBFREQ.

@BeanieBots
Now tried CALIBFREQ with values from -15 to +15. Same result.
Also as I am the "happy" owner of two 20X2, I have tried the other one and got the same garbage from this one as well.

Now tried with a 18X, and as with the 08M this also work OK.
Only 20x2 has a strange behavior

I don't have an answer but connecting the 20X2 output to an 18X input and I don't see any particular problems with the comms. May have to power-off cycle both 20X2 and 18X to get them into synch -

#Picaxe 20X2
#No_Data
#No_Table
Pause 2000
Let dirsB = %11111111
Let w0 = 00345
Do
w0 = w0 + 1
SerOut B.0, N2400, ( 254, 1 )
Pause 30
SerOut B.0, N2400, (254, 128, #w0 )
Pause 500
Loop

#Picaxe 18X
#No_Data
#Terminal 4800
Do
SerIn 0, N2400, b1, b2
SerTxd( #b1, " ", #b2, CR, LF )
SerIn 0, N2400, b1, b2, b3, b4, b5
SerTxd( #b1, " ", #b2, " ", b3, b4, b5, CR, LF )
Loop

I'm wondering if the issue is more related to the AXE033 than the 20X2, though tweaking CALIBFREQ should cure any baud rate issues on the AXE033.

Clutching at straws; you could try 20X2 to AXE033 with a 1K to 10K pull-down on the B.0 pin,

@ Hippy
I think you have misunderstood me. I have tried to connect, first an 18X and later on an 08m to my AXE033. This is without problems. When I'm doing exactly the same (nmearly the same program) with a 20X2 I have problems as described.
Maybe my English is worse than I thought.

The program
from post #1 produces codes from
asc 204, 230 and others, on the AXE033.
PS. Does not work with the 10k to ground.

The code works fine on three different LCD modules,
using FRM010. (20 x 2, 40 x 2, 20 x 4)


A possible workaround
Obviously, there are ways to improve the digit display.



e

@ wlie : No, I didn't misunderstand you and your English is fine - just trying to get to the bottom of what the issue may be.

SEROUT from a 20X2 seems to work just as well as from an 08M and 18X when received by an 18X ( and FRM010 - thanks eclectic ) so it's unclear why it would not be the same when received by an AXE033.

What's odd is that the code which doesn't work with SEROUT reportedly works with SERTXD and both commands AFAIK use the same firmware routine to send a numeric stream. SERTXD runs faster with shorter bit times so I would have expected any timing problems to be more apparent with SERTXD than SEROUT.

If the characters displayed are those with ASCII code 204 ( $CC ) etc that suggests there is some corruption of the last character sent / received or some timing error on last character. Why that is only an issue with 20X2 to AXE033 and not in any other combination, whether a 20X2 or an AXE033 issue, is something which will need to be investigated. Regardless, any fix needed would likely be applied to the 20X2.

I can confirm that behaviour of 20X2 with AXE033

However, when I tried CALIBFREQ it DID correct the situation.
Surprisingly, the error persisted until a value of -10 to -15 was used.
At values >0, the AXE033 refused to play at all.
This is true on all port b pins.

I've not tried the AXE033 with another PICAXE to confirm if the cold has put it out a bit which I know they do suffer with but not usually by that much.

So far, using a value of -12 has been reliable.

re axe033

Hi,
Could it be due to lack of delays? I've just looked at the axe033 datasheet and it say all command codes should be followed by a 1sec delay (pause 1000).
Hope this helps.


regards john

@BeanieBots
Confession - I was probably not careful enough when I tried to CALIBFREQ command. I have now tried again and this time I got it to work when CALLIBFREQ was set to -10.

So I think that the development department should consider a firmware change.

@john hauton
Your are right - the instruction for AXE033 says that all write command should be followed by a 1000ms pause. But even this long pause doesn't help and for 18X and 08M this long pause is not needed.

There does seem to be something odd about the 20X2 oscillator. You need CALIBFREQ -10, I need CALIBFREQ +4, and this guy needs CALIBFREQ -1.

Any ideas what could be wrong Hippy? Sounds like the problem is at microchip's end...

A

I too experienced the same behavior with SEROUT on 20X2 using a graphics display and driver from Sparkfun. I ended up using HSEROUT which worked fine.

Andrew Cowan said:

Any ideas what could be wrong Hippy? Sounds like the problem is at microchip's end...

Click to expand...

Could be. Unfortunately the latest 18F14K22 available still has the electrical characteristics marked as "Advance Information" and the entire datasheet "Preliminary".

If oscillator drift made serial marginal, one would expect failures to be much more frequent, and less consistent, so it's a bit of a mystery at present.

Is this relevant?
18F1xK22 Errata

http://ww1.microchip.com/downloads/en/DeviceDoc/80437B.pdf

Page 5.

@ Dippy : Thanks. It could be but would need to have combined +/-5% error to mess up serial. It does reduce the margin of error though.

Hi,
i have the same problem, i used CALIBFREQ -32 and the display now works well.
regards Claudio

The 20X2 problem with AXE033 is not actually anything to do with the calibration, it is just that bytes are sent back to back maginally a little faster than the AXE033 can keep up with. This is because the 20X2 processes faster than other PICAXE chips, hence the gap between consequative bytes is less. The 'between byte delay' is only very slightly off, which is why some 20X2s work and some don't, and playing with calibfreq may well get things going (by making the delay slightly longer), but it is not our recommended solution.

As the AXE033 processes each byte at a time as they are received, with very close togther bytes it eventually misses part of a byte and hence the corrupt characters appear. Serial streams to, for instance, computers won't be affected as the computer can easily keep up, it is generally onbly hardware like serial LCDs that will suffer.

The situation is worst when #var is used to send ASCII bytes back to back, so using

bintoascii b1,b2,b3,b4
serout pin,N2400_8,(b2,b3,b4)

is better than
serout pin,N2400_8,(#b1)

but best of all is
bintoascii b1,b2,b3,b4
serout pin,N2400_8,(b2)
serout pin,N2400_8,(b3)
serout pin,N2400_8,(b4)

as that introduces a larger delay between each byte.

The current release 20X2 firmware, C.1, has this issue fixed by making the 'between byte delay' slightly longer.

Is there been any further info on this issue or do I need to just get away from the C.0 version on the firmware?
I have run into the exact problem with 2 different 20X2 (C.0) chips and a serial OLED display. I am using the chip on a breadboard with a direct connection to the OLED. If I replace the chip with a 20M2, the problem goes away. I have used CALIBFREQ from -30 to +20 with no improvement. I have looked at the serial signal with a scope and things look well behaved as far as I can tell. In my case, I can tell that the ones digits that are odd charactors are repeated. 1 is the cent symbol, 2 is a lower case "P", the other digits are odd symbols but they are the same if the display shows 11-20 or 5411-5420.

Dave E

As BB has indicated it is likely its a internal frequency problem, the 20X2 is very well noted for the frequency problem and its serial data effect.
Try running this small program to set the frequency, you will need to press F8 and use the terminal window to veiw the data via the serial cable (programming cable).

You should see no corrupt charactors in the strings of UUUUUUUUUUUUUUUU, you will need to change the calibfreq -13 to somewhere between -30 and 30 (thats a range of 60 overall, with 0 being the factory setting), i normally go in steps of 5 untill the error is resolved and then go 5 greater till the error appears again, then set the value in the middle.

On average it is always a minus value required for the 20X2 chip, but not all 2 chips are the same in the value required.

Once the corect calibfreq value is found then you MUST use Calibfreq -XX at the start of you program as it is not a hard setting and needs to be activated on each bootup of the program


#Picaxe 20X2
#Terminal 4800

'CalibFreq -14

Main:

setfreq m8

CalibFreq -13

Do
SerTxd( "U" )
Pause 2
Loop

Dave E said:

Is there been any further info on this issue or do I need to just get away from the C.0 version on the firmware?

Click to expand...

As noted, version C.1 extended the inter-byte gaps so that would likely be the best course, adjusting with CALIBFREQ until something acceptable was found, or sending each character individually.

Thanks for the updates.

Dave E

Please see port 18. It is highly unlikely you will actually need calibfreq at all if you increase the gap between each byte sent to the LCD.
Many people assume LCD issues are a baud rate issue on C.0, it is not, it is a gap between bytes issue - bytes coming marginally faster than the third party LCD can process.
In fact the baud rate was not changed, simply a longer gap between bytes was inserted on firmware version C.1.

Tweaking calibfreq sometimes helps firmware C.0 'indirectly', because it also makes the gap between bytes longer. But it is not a good fix for LCDs.

Severe baud rate inaccuracy has been previously documented with the 20X2 serout at certain frequency baud rate combinations. However, 8 MHz and 2400 Baud was not one of the particularly bad combinations. In any case, try operating the Picaxe 20x2 at both 4 MHz and 16 mhz and see what happens.

Setfreq M4
serout b.0, N2400_4, (whatever)

then try:

Setfreq M16
serout b.0,N2400_16 (whatever)


You should also try hserout instead of serout. I have found hserout to be dead on in regards to baud rate accuracy.

There was a comment by Hippy on the 4th February that Technical would provide more information on the serial (baud rate ?) inaccuracy issue.

What was the response, I must have missed it ?

@Dave E

What Picaxe frequency & baud rate are you trying to use ?

I started out at 8MHz which is the 20X2 default then tried 4MHz. Any time I have had a SEROUT issue I always drop down to the lowest frequency I can to "loosen things up" and see if that affects things. This time it did not help.
I do have several LCDs running off of 20X2s (C.0) @ 9600 baud without any problem. Must be slight differences between the LCD and OLED firmware. They are from different manufacturers.

Dave E

On the 20x2, 8mhz and 9600 baud are a known "bad combination" using serout, with the actual serout baud rate being about 9150. This is a serial baud error of > 4% and will cause problems with many devices. Adding extra time between bytes is a work around to the actual problem and in many cases simply does not work.

If you set the Picaxe frequency to M16 and the baud rate to N9600_16 ... the problem should disappear ... IF .. it is a baud rate issue.

Please try this and let me know ....

Goey

Goey,
The issue I have is with a Rev-Ed OLED which as far as I know is fixed at 2400 baud. I believe I saw somewhere that I can change the firmware default frequency and load the modified software. Is there another way to change the OLEDs baud rate?

Dave E

Dave,

I have not worked with the Rev Ed AXE033Y OLED Displays. Others here will be able to help you with that better than I.

However, from looking at the AXE 133Y firmware code, it may be possible to increase the frequency from 16 MHz to 32 Mhz and operate at 4800 baud. I cannot see any other way of increasing the baud rate short of using a different microcontroller on the OLED. I am guessing that 9600 would probably not be doable due to the processing overhead of the 18m2 used with the Rev Ed OLED displays.

If the problem is occuring at 2400 baud using a 20x2 then the root cause is probably not the baud rate but more likely the inability
of the 18M2 on the OLED to keep up when consecutive bytes are sent.

Have you tried using hserout instead of serout? With my 20x2's (c.2 Firmware) there is a substantial delay between bytes using hserout. Your C.0 firmware may be different but it may be worth a try.

As pointed out by Technical and hippy, the problem is not the baud rate but the (lack of) time/gap between the characters.

When working with slow peripherals, like some serial LCDs, use a For/Next loop and a Lookup command to pick each character out of the string to be sent. Then, in the loop, send one character at a time.

Something like (untested):