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

[mik3ca]

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]

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]

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]

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]

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]

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

Mike.

 

[Ian Rogers]

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

You are not putting the module to sleep are you??

 

[ronsimpson]

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]

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]

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:

;get serial data AFTER clearing serial reception flag
start of ISR:
   clr RI
   mov A,SBUF

Other sites do this:

;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):

;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

 

[Beau Schwabe]

Page 5 of the datasheet says that the default speed is set to 9600 Baud.... You need to program it if you want a faster speed. See instruction "1E"

**broken link removed**

 

[Pommie]

If you clear the flag before reading the byte it may occasionally get overwritten.

Mike.

 

[mik3ca]

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]

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]

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]

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]

You should have both electrolytic and ceramic capacitors before and after the regulator.

Mike,

 

[mik3ca]

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.