AXE133Y OLED sometimes displays some garbage characters

I just finished assembling the AXE133Y OLED and it seems to be basically working but is has some problems. I tested it by sending inverted 2400 bps data from my PC and it worked pretty good, but occasionally a character would be scrambled. I was able to fix that occasional scrambling by specifying the PC to send two stop bits instead of one.

So I then connected it to my Picaxe 20x2 and the data the 20x2 sent was badly scrambled on the OLED screen. After experimenting a little it seems that some types of the serout command work without error, but other types have bad errors. For example, serout B.6, n2400, ("hello world") seems to work perfectly. However serout B.6, n2400, (">",#parameter1, #parameter2) almost always produces a few garbage characters after sending the first 2 or 3 characters perfectly. I don't know if two stop bits can be configured in the 20x2, but if it can that may solve the problem like it did above with my PC configured with two stop bits.

I'm guessing that the clock frequency of the Picaxe chip in the OLED is slightly off frequency, and maybe somehow the small timing difference caused by the 20x2 having to convert the variable to ASCII characters is causing errors on the OLED. Just a wild guess.

I tried hooking up the input of my PC serial port in parallel with the OLED so that both devices read the same data stream simultaneously. The PC displays the characters perfectly while the OLED shows the same data stream with garbage characters similar to above.

I looked through the Pixace manual to see if there is a way to specify 2 stop bits in my 20x2, but didn't see any way to do that.

Anybody have any suggestions? Can the clock in the 20x2 or in the OLED Picaxe chip be adjusted somehow?

P.S. The AXE133y gets it's power from the same supply as the 20x2.

What firmware version is installed in your 20x2? There was an issue with serial baud rate accuracy reported in versions prior to version C.3, although this was primarily associated with 9600 baud;

"ISSUE - IMPROVED SERIN AND SEROUT BAUD RATE ACCURACY (9600_8) The following baud rate settings are not as accurate as would be expected for serin/serout commands : 9600 at 8MHz : 4800 at 4MHz : 19200 at 16MHz : 38400 at 32MHz To workaround this issue use the baud rate at a different setfreq frequency, e.g. instead of using serin pin,N9600_8,variable use 9600 at 16MHz instead e.g. setfreq m16: serin pin,N9600_16,variable : setfreq m8 Fixed in vC.3 - "

This probably isn't the issue though at 2400 baud. This thread http://www.picaxeforum.co.uk/showthread.php?20342-Solving-Serin-amp-Serout-Problems-with-20M2-and-20X2 details a lot of discussion about 20X2 and baud rates and also mentions adjustment of the PICAXE clock and tuning the frequency with CALIBFREQ.

I would be more inclined to check your setup; I have used many AXE133Y OLED units with complete success on a range of PICAXE chips and with no errors ever. One thing that I do is a belt, braces and nail-through-the-navel approach to the power supplies; I run the AXE133Y off one voltage regulator and the main PICAXE chip and associated circuitry off another. Can you show your rig in a picture? Do you have proper decoupling capacitors installed etc.?

Circuit said:

What firmware version is installed in your 20x2? There was an issue with serial baud rate accuracy reported in versions prior to version C.3, although this was primarily associated with 9600 baud;

"ISSUE - IMPROVED SERIN AND SEROUT BAUD RATE ACCURACY (9600_8) The following baud rate settings are not as accurate as would be expected for serin/serout commands : 9600 at 8MHz : 4800 at 4MHz : 19200 at 16MHz : 38400 at 32MHz To workaround this issue use the baud rate at a different setfreq frequency, e.g. instead of using serin pin,N9600_8,variable use 9600 at 16MHz instead e.g. setfreq m16: serin pin,N9600_16,variable : setfreq m8 Fixed in vC.3 - "

This probably isn't the issue though at 2400 baud. This thread http://www.picaxeforum.co.uk/showthread.php?20342-Solving-Serin-amp-Serout-Problems-with-20M2-and-20X2 details a lot of discussion about 20X2 and baud rates and also mentions adjustment of the PICAXE clock and tuning the frequency with CALIBFREQ.

I would be more inclined to check your setup; I have used many AXE133Y OLED units with complete success on a range of PICAXE chips and with no errors ever. One thing that I do is a belt, braces and nail-through-the-navel approach to the power supplies; I run the AXE133Y off one voltage regulator and the main PICAXE chip and associated circuitry off another. Can you show your rig in a picture? Do you have proper decoupling capacitors installed etc.?

Click to expand...

It looks like you steered me in the right direction. My firmware is C.0 and therefore has the potential for baud rate accuracy problems.

I tried setting the clock to 16mhz and sure-enough the error rate was much improved. Still not good enough to say that the problem is solved, but it did make a dramatic difference. I have some recently purchased 20x2's that I will try when I get a chance. Although I would think that the real problem is the Picaxe 18m2 in the OLED circuit because my PC read the 20x2 data-stream with no problem.

I also have to read that thread you referenced more thoroughly, perhaps there are other solutions.

Thank you.

frank2644 said:

It looks like you steered me in the right direction. My firmware is C.0 and therefore has the potential for baud rate accuracy problems.

I tried setting the clock to 16mhz and sure-enough the error rate was much improved. Still not good enough to say that the problem is solved, but it did make a dramatic difference. I have some recently purchased 20x2's that I will try when I get a chance. Although I would think that the real problem is the Picaxe 18m2 in the OLED circuit because my PC read the 20x2 data-stream with no problem.

I also have to read that thread you referenced more thoroughly, perhaps there are other solutions.

Thank you.

Click to expand...

The fact that your PC could read the data stream may be misleading; it might just be more tolerant of baud rate errors.
A couple of other thoughts; with what frequency are you sending text messages to the AXE133? Try a "pause 30" between successive text messages to allow the AXE133 to process the last text. Also, I presume that you do have the ground leads of the AXE133 power supply and the PICAXE power supply common to each other?

The main issue is usually inter-byte gap time, which is extended on the PC by adding the extra stop bit. The 18M2 on the AXE133 has to have that inter-byte gap time to process the last character received and be ready for the next. If the sender sends too quickly characters may get corrupted.

What could be happening is that #variable is sending the digits of that variable with a shorter inter-byte gap time than if those digits were sent separately. Two solutions for that if it is the case are; (1) to use BINTOASCII to extract the individual digits and send those separately, (2) to drop the operating system speed before the SEROUT and increase it again after, adjusting the baud rate as appropriate -

setfreq m4
serout B.6, n2400_4, (">",#parameter1, #parameter2)
setfreq m8

Circuit said:

The fact that your PC could read the data stream may be misleading; it might just be more tolerant of baud rate errors.
A couple of other thoughts; with what frequency are you sending text messages to the AXE133? Try a "pause 30" between successive text messages to allow the AXE133 to process the last text. Also, I presume that you do have the ground leads of the AXE133 power supply and the PICAXE power supply common to each other?

Click to expand...

Yes the grounds are common and I have bypass caps.

And I have pause 30 statements everywhere, I even tried Pause 300 to no avail.

I agree that the PC situation could be misleading, but the thread you mentioned also says that the AXE133Y 18m2 chip has similar serial timing problems so I'm still leaning in that direction. Also I have used this same 20x2 in several other circuits and never had any transmission problems. Of course, it could still be the 20x2, I'm not ruling out anything. I have some newer 20x2's somewhere that I will try when I find them.

Admittedly the circuit is a little bit of a rats nest, but I think it's okay.

Thanks for the help.

hippy said:

The main issue is usually inter-byte gap time, which is extended on the PC by adding the extra stop bit. The 18M2 on the AXE133 has to have that inter-byte gap time to process the last character received and be ready for the next. If the sender sends too quickly characters may get corrupted.

What could be happening is that #variable is sending the digits of that variable with a shorter inter-byte gap time than if those digits were sent separately. Two solutions for that if it is the case are; (1) to use BINTOASCII to extract the individual digits and send those separately, (2) to drop the operating system speed before the SEROUT and increase it again after, adjusting the baud rate as appropriate -

setfreq m4
serout B.6, n2400_4, (">",#parameter1, #parameter2)
setfreq m8

Click to expand...

Although your explanation made a lot of sense, when I tried your suggestion to lower the clock speed the problem became much worse. Strangely after running for a minute or so the OLED just went dark and did not display anything. Even after reloading the 20x2 to go back to the m16 clock speed the OLED had to be power reset before it began functioning again. I tried this a second time and got the same "dark screen" result and I had to power reset again. I'm guessing that the very high error rate of the lower clock speed somehow made one of the transmissions look like a shutdown or similar command to the OLED (just a wild guess).

As I mentioned in an earlier post making the clock speed higher (m16) improved things dramatically, but it still has an occasional error.

Thanks for the help.

hippy said:

The main issue is usually inter-byte gap time, which is extended on the PC by adding the extra stop bit. The 18M2 on the AXE133 has to have that inter-byte gap time to process the last character received and be ready for the next. If the sender sends too quickly characters may get corrupted.

What could be happening is that #variable is sending the digits of that variable with a shorter inter-byte gap time than if those digits were sent separately. Two solutions for that if it is the case are; (1) to use BINTOASCII to extract the individual digits and send those separately, (2) to drop the operating system speed before the SEROUT and increase it again after, adjusting the baud rate as appropriate -

setfreq m4
serout B.6, n2400_4, (">",#parameter1, #parameter2)
setfreq m8

Click to expand...

Hippy, as the 18M2 is running at M16, is it reasonable to clock it up to M32 to make it less sensitive to inter-byte gap time? Obviously the internal pauses will have to be doubled etc. but I just wonder why the AXE133 "firmware" does not run at M32. As it was written by RevEd, I guess that I am missing a point here...what am I missing in my digital naivety?

Hi Circuit

Serin @ 2400 baud is not possible at 32 MHz. 16MHz is the highest clock speed that will support software serial @ 2400 Baud.

This is why 16MHz is used on the 18M2.

Thanks Tex; I knew I was missing something but didn't look for the obvious!

I tried setting the clock to 16mhz and sure-enough the error rate was much improved. Still not good enough to say that the problem is solved, but it did make a dramatic difference. I have some recently purchased 20x2's that I will try when I get a chance. Although I would think that the real problem is the Picaxe 18m2 in the OLED circuit because my PC read the 20x2 data-stream with no problem.

Click to expand...

Have you tried one of the more recently purchased 20X2's yet?

The "problem" is most likely that the 18M2 is using software serial and must process a byte of data before receiving the next byte of data. With an actual 1 stop bit between bytes coming from the 20X2 to the 18M2. This gives the 18M2 only 418 us to process a byte of data and get ready for the next byte.

20X2 Firmware Version C.1 and higher adds an extra stop bit between sent data bytes when using serout (#var). This gives the 18M2 about 836 us to process a received byte and get ready for next received byte.

From http://www.picaxe.com/Hardware/PICAXE-Chips/PICAXE-20X2-microcontroller/#tRevisionHistory



So if your 20X2 has version C.0 firmware, it is likely that there could be display errors ( occasional garbage) when sending serout data to the AXE033.

Correction: Testing with a Logic Analyzer shows that there are 3 stop bits ( 1.26 ms) between serout bytes with a 20X2 and Frrmware C.2. I cannot test version C.0 Firmware to see the difference.

Goeytex said:

Have you tried one of the more recently purchased 20X2's yet?

The "problem" is most likely that the 18M2 is using software serial and must process a byte of data before receiving the next byte of data. With an actual 1 stop bit between bytes coming from the 20X2 to the 18M2. This gives the 18M2 only 418 us to process a byte of data and get ready for the next byte.

20X2 Firmware Version C.1 and higher adds an extra stop bit between sent data bytes when using serout (#var). This gives the 18M2 about 836 us to process a received byte and get ready for next received byte.

From http://www.picaxe.com/Hardware/PICAXE-Chips/PICAXE-20X2-microcontroller/#tRevisionHistory

ISSUE - MODIFIED SEROUT TIMING FOR MORE RELIABLE OPERATION WITH AXE033 SERIAL LCD
On #var within 'serout' commands the data may be sent to quickly for AXE033 to process.
To workaround this issue use BINTOASCII instaed of #var
Fixed in vC.1​

So if your 20X2 has version C.0 firmware, it is likely that there could be display errors ( occasional garbage) when sending serout data to the AXE033.

Correction: Testing with a Logic Analyzer shows that there are 3 stop bits ( 1.26 ms) between serout bytes with a 20X2 and Frrmware C.2. I cannot test version C.0 Firmware to see the difference.

Click to expand...

I just replaced the 20x2 with a newer C.3 chip and the problem is fixed. Of course it would have been better if the AXE133y software could have been fixed since that is apparently where the real problem exists.

Interestingly, operating the 20x2 at a lower clock speed as suggested by Hippy should have also worked given the explanation that the 20x2 is basically "too fast" for the 18m2, but it did not. Perhaps after lowering the clock speed the 20x2 was still too fast for the 18m2.

Thank you

frank2644 said:

I just replaced the 20x2 with a newer C.3 chip and the problem is fixed. Of course it would have been better if the AXE133y software could have been fixed since that is apparently where the real problem exists.

Click to expand...

Unfortunately the 18M2 running the AXE133 software requires a minimum inter-byte gap time to perform its tasks and there is no easy solution to making the 18M2 execute faster. The only solution is to make the sender run slower or otherwise extend the inter-byte gap.

frank2644 said:

Interestingly, operating the 20x2 at a lower clock speed as suggested by Hippy should have also worked given the explanation that the 20x2 is basically "too fast" for the 18m2, but it did not. Perhaps after lowering the clock speed the 20x2 was still too fast for the 18m2.

Click to expand...

That may well be the case. Sending digits individually may be a solution and sending one digit per SEROUT command should provide an additional larger inter-byte gap.

It may be worth trying that and checking it does work. Then you can continue to work with the C.3 version and, when done, port that for the C.0 version, put that in your project, and continue using the C.3 version for the next project.

By using #DEFINE and #IF you should be able to make the same source code work for either C.0 or C.3 versions.

hippy said:

Unfortunately the 18M2 running the AXE133 software requires a minimum inter-byte gap time to perform its tasks and there is no easy solution to making the 18M2 execute faster. The only solution is to make the sender run slower or otherwise extend the inter-byte gap.



That may well be the case. Sending digits individually may be a solution and sending one digit per SEROUT command should provide an additional larger inter-byte gap.

It may be worth trying that and checking it does work. Then you can continue to work with the C.3 version and, when done, port that for the C.0 version, put that in your project, and continue using the C.3 version for the next project.

By using #DEFINE and #IF you should be able to make the same source code work for either C.0 or C.3 versions.

Click to expand...

At this point I'm not inclined to spend anymore time and I am happy with the solutions that have been uncovered in this thread.

However, I am puzzled about the suspected reason for this problem. IOW, how can the 20x2 send #var characters faster than it can send ASCii constants. I would think it takes more work to send a #var because it has to first be converted to ASCII.

I just replaced the 20x2 with a newer C.3 chip and the problem is fixed. Of course it would have been better if the AXE133y software could have been fixed since that is apparently where the real problem exists.

Click to expand...

Glad this is resolved and you are happy with with the solution.

As I see it there is nothing to be fixed or that can be fixed with the 18M2 software. The AXE133Y was designed and is marketed as an economy OLED display and as a consequence it has some significant limitations.

These limitations are a result of 1) Using a Picaxe 18M2 with interpreted Basic for the serial interface and 2). Using software bit banged serial instead of the hardware USART. Since the 18M2 firmware does not support background receiving of serial data, using its USART would be rather pointless.

If you look at the 18M2 code for the AXE133Y, you will see that it is actually quite efficient (for interpreted BASIC) and that there is really nothing that can be fixed in the software. It is what it is, and will only work properly if there is sufficient latency between the bytes of data that it receives. The C1 and above firmware adds that latency to the 20X2's serout. Problem resolved. If you scope the other Picaxe models you will see that they also have added latency between serout data bytes (for compatibility)

Considering the price, the AXE133Y is a very good deal for an OLED Display for those that can live with 2400 baud. For higher performance there are many other options, including the AXE033Y.

Goeytex said:

Glad this is resolved and you are happy with with the solution.

As I see it there is nothing to be fixed or that can be fixed with the 18M2 software. The AXE133Y was designed and is marketed as an economy OLED display and as a consequence it has some significant limitations.

These limitations are a result of 1) Using a Picaxe 18M2 with interpreted Basic for the serial interface and 2). Using software bit banged serial instead of the hardware USART. Since the 18M2 firmware does not support background receiving of serial data, using its USART would be rather pointless.

If you look at the 18M2 code for the AXE133Y, you will see that it is actually quite efficient (for interpreted BASIC) and that there is really nothing that can be fixed in the software. It is what it is, and will only work properly if there is sufficient latency between the bytes of data that it receives. The C1 and above firmware adds that latency to the 20X2's serout. Problem resolved. If you scope the other Picaxe models you will see that they also have added latency between serout data bytes (for compatibility)

Considering the price, the AXE133Y is a very good deal for an OLED Display for those that can live with 2400 baud. For higher performance there are many other options, including the AXE033Y.

Click to expand...

I would think that operating the AXE133Y at 1200 bps would be a viable fix for the software. Perhaps they could even have an alternative software module to speed up to 2400 bps for those folks where 1200 bps is too slow and have a 20x2 >C.0 or an equivalent message source.

frank2644 said:

I would think that operating the AXE133Y at 1200 bps would be a viable fix for the software. Perhaps they could even have an alternative software module to speed up to 2400 bps for those folks where 1200 bps is too slow and have a 20x2 >C.0 or an equivalent message source.

Click to expand...

To use software serial @ 1200 baud would require reducing the 18M2 MCU speed to 8 MHz. See Manual 2 "Serout" p202. This would increase the command processing overhead and most likely exacerbate the problem, not to mention the agonizingly slow display performance. You can easily prove or disprove this by changing the 18M2/AXE133Y software yourself.

The code is freely available === > HERE.

Personally, I cannot live with the painfully slow 2400 baud, much less an agonizingly slow 1200. Maybe OK for kiddies in the classroom but not for any of my projects.

Considering that the actual display is capable of 115,200 baud and beyond, operating it at 2400/1200 baud is like putting bicycle wheels on a Ferrari.

frank2644 said:

I am puzzled about the suspected reason for this problem. IOW, how can the 20x2 send #var characters faster than it can send ASCii constants. I would think it takes more work to send a #var because it has to first be converted to ASCII.

Click to expand...

The difference is that the #var conversion to digits and the subsequent sending is all done in firmware at native execution speeds.

When two byte variables are sent in a SEROUT command the PICAXE has to read a token which says what the first variable is, get its value, send it, then advance the program counter, read the token which says what the second variable is, get its value and send that. It is this time between the two sends which makes up the inter-byte gap time.

When sending a '#variable', the firmware gets the variable values and splits that into digits. Each digit can then be sent back to back, or at least much quicker, because it doesn't have to go and get any further tokens.

It's like a single shot gun where you have to go get a bullet between shots and a multi-shot gun where you may spend longer loading the magazine but, once that's done, the bullets can be fired out in quick succession.

Goeytex said:

To use software serial @ 1200 baud would require reducing the 18M2 MCU speed to 8 MHz. See Manual 2 "Serout" p202. This would increase the command processing overhead and most likely exacerbate the problem, not to mention the agonizingly slow display performance. You can easily prove or disprove this by changing the 18M2/AXE133Y software yourself.

The code is freely available === > HERE.

Personally, I cannot live with the painfully slow 2400 baud, much less an agonizingly slow 1200. Maybe OK for kiddies in the classroom but not for any of my projects.

Considering that the actual display is capable of 115,200 baud and beyond, operating it at 2400/1200 baud is like putting bicycle wheels on a Ferrari.

Click to expand...

Okay, I agree that if the clock speed has to be reduced than operating at 1200 bps doesn't make sense.

Thanks.

Faster PICAXE-based alternative

A few years ago, I wanted a faster serial interface with Rev-Ed's OLED display. I developed an interface based on the 20X2 documented here, using its background serial reception capability. The interface can handle async serial speeds at up to 76800 baud and can also receive 115200 baud with occasional character drops.

Using locally generated text, I managed to display 1669 characters-per-second using the 4-bit interface and the 20X2 running at 64MHz.

inglewoodpete said:

A few years ago, I wanted a faster serial interface with Rev-Ed's OLED display. I developed an interface based on the 20X2 documented here, using its background serial reception capability. The interface can handle async serial speeds at up to 76800 baud and can also receive 115200 baud with occasional character drops.

Using locally generated text, I managed to display 1669 characters-per-second using the 4-bit interface and the 20X2 running at 64MHz.

Click to expand...

I haven't looked into much of the capabilities of the AXE133Y, but from the little I know I can't see an advantage to speeds higher than say 9600bps.

Maybe to help learn speed reading?

frank2644 said:

I haven't looked into much of the capabilities of the AXE133Y, but from the little I know I can't see an advantage to speeds higher than say 9600bps.

Maybe to help learn speed reading?

Click to expand...

Think about it ...

The primary advantage is that the entire program will execute faster. The faster the display can be written, the sooner the program can move on to the next task. A slow display can bog down a timing critical program.

Faster speeds look better also. I operate my displays at ~20,000 characters per second. At that speed you can write an entire screen of characters and they all appear to change instantly.

Goeytex said:

Think about it ...

The primary advantage is that the entire program will execute faster. The faster the display can be written, the sooner the program can move on to the next task. A slow display can bog down a timing critical program.

Faster speeds look better also. I operate my displays at ~20,000 characters per second. At that speed you can write an entire screen of characters and they all appear to change instantly.

Click to expand...

I like the instantaneous change of the display. Actually, I was hoping that the AXE133Y had the capability to do that natively, perhaps by somehow commanding it to receive and store the message before displaying it.

Thanks

The AXE133 software / firmware is available as example code in PE6 so it can be modified as required. It is possible to store whole pages of data and then output them at a faster rate using buffering such as (untested/example) ...

You would probably want to add extra processing to handle cursor positioning, where to write to next, clear screen and so on.

You can also use a RAM copy of what should be on the display so you can buffer the input stream, leisurely update the RAM copy, then splat that out at the fastest speed to the display. That could even be designed to only update characters on the display which have changed.

Even if you don't want to build a full X2 interface to an LCD/OLED as inglewoodpete did it is possible to build a small interface board with an X2 on it which let the X2 handle incoming data which then sends data to an AXE133 which actually controls the physical LCD/OLED.

frank2644 said:

I like the instantaneous change of the display. Actually, I was hoping that the AXE133Y had the capability to do that natively, perhaps by somehow commanding it to receive and store the message before displaying it.

Click to expand...

You can do that as in Hippy's example, but you would need to decide how you'd signal that you want to display the message. You could have a separate I/O line, or display the text as soon as a fixed number of characters have been received.

The best and fastest way is to use a bigger PICAXE chip as your master and connect the LCD module to it directly using the parallel interface. Writes are so fast that if you change the text being displayed, then change it back again immediately, you wouldn't see anything happen.

Be warned though, once you get used to projects with the LCD connected using the parallel interface, projects using the serial interface will look slow and laggy if you go back. Not because they weren't before, but because it was harder to notice when you hadn't seen better.

Thanks, guys for the ideas about "splatting" messages on the AXE133Y. When I get some time I'll probably try some of these suggestions.

Great message board!

The best and fastest way is to use a bigger PICAXE chip as your master and connect the LCD module to it directly using the parallel interface.

Click to expand...

Whether it is the best way is highly debatable. What is best for one project may not be best for another. Cost, board space, code complexity and speed requirements should all be considered before deciding what is best for a particular application.

The SEROUT command is quite efficient for getting data to a serial LCD and only uses one I/O line but does have a speed cost.

Direct parallel control of the LCD increases speed but uses more I/O lines and makes getting data on to the display more difficult and often requires more program memory to be used.

A faster serial interface gives the benefits of the SEROUT serial solution without such high communications overheads but adds more cost and needs to be implemented.

Using I2C or SPI are other solutions which do not have all the overheads of a direct parallel connection but are not as simple as the SEROUT serial solution and can be slow depending on how the LCD is actually interfaced to its controller chip.

It is not really possible to say there is a single best, as Goeytex notes, particularly when speed of display update may not always be important.