How does one achieve a high baud rate on a micro with an LCD attached?

Status
Not open for further replies.

mik3ca

Member
I'm making an application that communicates to the world wirelessly over a UART. specifically, I'm using the HM-TRP module with an AT89C4051 micro with a 22Mhz clock and an LCD.

I'm trying to run the module at 38Kbps and have the results show in 16-byte fragments on an LCD. I tested the modules in other setups and they work correctly, but when I'm trying to record real-time data and display it on the LCD, I run into trouble.

The best case I had was using a fixed (non-ring) buffer for both transmission and reception, but that caused loss of characters (particularly when printing characters on the LCD). I tried storing a character in the buffer until the buffer has 16 received characters then I disable the reception until I spit them all out on the LCD and start the buffer all over again and re-enable reception.

I feel that between the buffering, I'm losing characters because what happens in between is that I print the characters to the LCD all at once. This means roughly 57uS per LCD write times 16 = ~900uS. Each byte at 38Kbps takes around 200uS So every now and then I lose a character.

I was thinking of lowering my buffer size but is that a good idea? I want to avoid lowering the baud rate.

Pommie

Well-Known Member
I do all RS232 send and receive using fifo buffers and interrupts.

Why do you need to write the whole display for every byte received?

Why can't you send a "frame" 50 times per second therefore knowing that you have time to write to the LCD after the frame is received?

Mike.

Nigel Goodwin

Super Moderator
If the data is coming faster than you can display, then you need to either buffer it (which only helps if it's not continuous), or use handshaking to pause it.

A lot really depends on what your data is, and how often it's sent.

Ian Rogers

User Extraordinaire
Forum Supporter
My first thought!! I have recently dabbled in Modbus RTU where data transmission is required every 100mS..

To prepare the packet, grab data, process data and display data meant no time left.. Here we A) need to go to a faster MPU or B) slow down transmission..

If the data is being shifted this fast, then how is it being displayed? You wouldn't see the changing data, the screen update will be too fast for the human eye..

If you need to see real time data, then you need to "graph" the results or log into a large file so the end user can view the results.. How many packets a second are you sending? ( mirroring Nigels question )

mik3ca

Member
I am buffering data. I set it so that when 8 bytes are received they are copied to user space. On the micro, that whole copy procedure takes likes roughly 50 uS. I also made it where commands to the LCD don't consume so much time but that didn't help.

What I did notice is that data reception on the micro side is rather slow. I can tell by the lights on the HM-TRP module. I even tried sending data super slow to the micro wirelessly (at say 1 byte every 1.5 seconds) and still, the HM-TRP module couldn't pick up every character on the micro side yet both modules are roughly 12 inches apart with no obstacles in-between so reception can't be an issue?

I wonder if there is a setting on the HM-TRP module itself that needs optimizing

Pommie

Well-Known Member
Sounds like you have interference. Send your data as packages with a checksum so you can discard corrupt packages.

Mike.

ronsimpson

Well-Known Member
I wonder if there is a setting on the HM-TRP module itself that needs optimizing
Now that we know there is "RF" involved, we can work on trouble shooting that.
Sounds like your software is not the problem.

mik3ca

Member
The modules are always in enable mode.

Based on research, I may have incorrect settngs for frequency deviation or receiving bandwidth, but then I wonder if maximum transmission power to my nearby receiver causes a bad effect.

When I tried 10Khz deviation The results were substantially worse, so I moved that setting now to 160Khz. I couldn't remember the receive bandwidth setting I used, but I think I selected the max of 620Khz. The minimum is 30Khz

Now maybe someone is right... because of such large numbers chosen, I'm picking up computer noise.

Is there a way to calculate optimal values for the above settings for the data rate 38.4kbps?

mik3ca

Member
Ok, so I looked at a bunch of code. On http://www.atmel.com/Images/doc4346.pdf, their routine for receiving a byte is like the following:

Code:
;get serial data AFTER clearing serial reception flag
start of ISR:
clr RI
mov A,SBUF
Other sites do this:

Code:
;get serial data BEFORE clearing serial reception flag
start of ISR:
mov A,SBUF
clr RI
But my code starts as follows (note two sections):

Code:
;clear reception flag ASAP
start of ISR:
jbc RI,ISR_CONTD
end_ISR:

ISR_CONTD:
mov A,SBUF
sjmp end_ISR
But something makes me thing the order of clearing the receive flag and receiving one byte does not matter provided that everything is done within one bit time (of 260uS at 38400bps if my calculation is right). I calculated the worst case scenario for my interrupts and that clocks in around 40uS so I should still have another 220uS headroom before RI can change by the micro right?

If my theory here is right, then something is going on with the radios themselves

Pommie

Well-Known Member
If you clear the flag before reading the byte it may occasionally get overwritten.

Mike.

mik3ca

Member
Beau, I have already done the programming on the HM-TRP.

If you clear the flag before reading the byte it may occasionally get overwritten.
You mean the incoming data may get overwritten, or just the flag status itself?
I'm trying to understand exactly what happens to SBUF and RI behind the scenes

Beau Schwabe

Active Member
Let me ask you this ... Does the communication work as expected if you have a direct connection? IOW if you bypass the RF.
Another question are you implementing any kind of checksum on your data. If not, it may not be a bad ides to do so. I do this with direct connections all the time between a touch screen display and a micro controller and it's a direct connection. Another thing that might help is to pause just a little bit after every data packet. Asynchronous serial communication has the potential for framing errors if the transmitter and receiver do not sync properly or are sent back-to-back without any delays.

Edit: The checksum does not need to be complex, a simple BYTE by BYTE XOR is usually enough and simple to decode on both ends.

mik3ca

Member
Let me ask you this ... Does the communication work as expected if you have a direct connection? IOW if you bypass the RF.
something is weird now. I hooked up TX to RX and RX to TX using jumper leads and half the data being transferred in both directions turn up as corrupted.

What I did notice with the modules in place is that sending data to the pc is fine and the PC can read it but when sending it to the micro, the micro occassionally skips some characters and this is shown on the receiving module (light blinks slower)

Another question are you implementing any kind of checksum on your data.
I will later. Right now I want the modules to work.

Im using 47nF for decoupling caps. I'm gonna up those values and see if that makes a difference.

mik3ca

Member
Ok, I did increase the caps around the LM117-3.3 regulator that powers the radio from two 47nF's to 47uF and 220uF and I noticed significant improvements in data flow, so now my errors are maybe 1 in every 1000 or so bytes as opposed to 1 every 50. I wonder if I should increase the caps more because something makes me think these radio modules suck up alot of power when trying to receive data.

Pommie

Well-Known Member
You should have both electrolytic and ceramic capacitors before and after the regulator.

Mike,

mik3ca

Member
Today the errors went up. I'm predicting radio interference. there were people working nearby at the time that may had radio equipment. I should probably use 115200bps speed and have the transmitter transmit the same data 4 times in hopes the receiver can receive it correctly at least 1 of the 4 times. Now I'm wondering if that is guaranteed to work in a noisy environment.

Status
Not open for further replies.