Serial input to LCD problem

rodmcm

Member
I have an 18X running an LCD
if I program

OutputByte = "W"
gosub WriteToLCD

then my write routine puts a W on the screen, no problems

I am using the picaxe Serial Terminal to send characters to pin 2 on the 18X to learn about serial to LCD

However if , under interrupt I use

serin 2, N2400, OutputByte
gosub WritetoLCD

W 0101(HB) 0111(LB) gives me U (umlat) 1111(HB) 0101(LB)
G 0100 0111 gives the ohm sign 1111 0100
7 0011 0111 gives infinity 1111 0011

There is almost a reversal ( but not quite) of the upper and lower bits
What is it I am missing?
 

moxhamj

New Member
It could be a serin problem rather than an LCD problem. Serin will (sort of) work reading one single byte, but it works a lot better with leadin characters (eg 4 "U"s) and a checksum at the end. Then you can be sure the character is exactly what you want.

For starters can you try

serin 2, N2400, OutputByte
debug
gosub WritetoLCD

and see what is coming in.
 

hippy

Ex-Staff (retired)
You say "under interrupt"; what exactly does that mean, how are you reading your incoming data ?

If you are interrupting on incoming data and then trying to read what was sent that won't work because there is a delay in responding to the interrupt and SERIN doing its thing. Serial is sent inverted with lsb first and wrapped with Start and Stop Bits, so sending "W" ($57) is sent as a stream of ...

1000101010000000000
S01234567E.....idle.....

If you interrupt on the Start (S) Bit, SERIN wll start looking for the next start bit and then build up the data it thinks it as received which will be ...

101010000000000
34567E.....idle.....

It mis-interprets bit 3 as if it were a start bit so reads that bit stream as ...

1010100000
S01234567E

Invert the data bits, re-order from lsb first and the data received will be $F5, the umlat you're seeing.
 

hippy

Ex-Staff (retired)
There are solutions to your problem, but first the analogy of the problem ...

You have a Fax machine but for security purposes it feeds its output straight into a shredder. You're at your desk when you hear the Fax and shredder fire up ( the interrupt ), you rush over to read what's sent ( SERIN ) but by the time you get there half the first page has been shredded ( the data corruption you are seeing ).

The solutions ...

Polling : You stand by the Fax machine waiting for incoming data. You cannot do anything else while waiting.

Dummy Data : Your senders have to always send a dummy or blank start page which gives you enough time to run to the Fax, see but discard the half-lost first sheet, then read the second sheet.

Front-End Buffering : You get a secretary ( another PICAXE ) to watch the Fax machine ( as per polling ) who will obtain everything that's received, store it, then tell you there's a message received ( the interrupt ) and you can pick it up at your leisure.

Which solution depeds upon what you are trying to do. I'm guessing you want to create your own AXE033/FRM010 replacement using just a PICAXE ?

If so you do not want to lose data and perhaps don't need to do anything when you've had data and dealt with it. You could therefore do polling. You don't however want to lose data so it may be an idea to buffer up incoming data until you see an 'end of data' then obey all that was sent; if you handle each item of data as it arrives you may be dealing with that while more is arriving and miss it, or again get back when the data sent has been half-lost leaving you with corrupt data.

Replicating the AXE033/FRM010 isn't a simple task because the PICAXE is much slower than the PICmicro's used for those products. It can however be done, but a lot depends on what you're doing, where the data comes from and how your system integrates.
 

stocky

Senior Member
With an RF system i'm using a dummy data burst to trip the interrupt then jump to the serin routine and look for the real data - timeout if nothing seen

works reasonably well - although not yet completely tested.
 

rodmcm

Member
Thanks, I get it.
I am really trying to learn lots of things, from LCD writing, serial comms and of course the logic step was have the LCD read the serial. I have got the LCD scrolling for long data lines so the idea was to capture a stream (albeit i realised it had to be slow) serial data and read it continuously on a scrolling 2 line LDC. Nearly there - Thank you
 
Top