Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

LCD display that can show the asynchronous output of a device

Status
Not open for further replies.

louislu

Member level 1
Joined
Apr 5, 2004
Messages
40
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
426
hi...i need some lcd display to show the asynchronous output of a device...that device may send out a continuous words to my microcontroller upon the request...so i wish to have my lcd to display those words in scrolling manner...from right to left...must b slow enough for user to b able to read...i wil make use of my microcontroller serial buffer SBUF to communicate to that device.

any sample prog to help...thanks
 

Re: lcd display

hi louislu,

I noticed no-one replied to your post, so I thought I'd try and help. Ok, firstly, try to be very specific about what exactly you are trying to do. Reading your post a few times I assume you want to to this:

Device(async output) -> Microcontroller(SBUF in) -> LCD. Dunno if this is right, but this is what I'll assume for my reply.

Now, if you don't know anything about LCD's, try here:

**broken link removed**
**broken link removed**

Great little tutorials on how these work, and these only talk about the most common character LCD, probably the best option for your project, and they'r easy to interface.

So you've got data coming in from your 'device' into the microcontroller. Now, If this data (say ASCII characters) is coming in quite regularly, are you sure that you could display these on the LCD fast enough? Scrolling is easy, you can configure the LCD to scoll every time you enter a character to it, but I'm thinking of the datarate problem. After all, you want people to read the LCD, so I'd say you might need a 'buffer' in the micro, a FIFO type thing, with a timer interupt controlling when you write a character to the LCD. A bit of multitasking is required, after all, you don't want to miss any data coming in whilst you're writing to the LCD. If you have 2 serial ports on your micro, you could use a serial LCD. these are a bit more expensive, but your micro will only need about 3 pins for the LCD, whereas, if you write in parallel, (8-bit or 4-bit mode) you're looking at at least 7 pins.

There are loads of LCD routines on the net for both C and Assembly of LCD routines, for initialization and displaying characters....google is a wonderful thing.

Hope this helps, bit more info and I'm sure I (and others) could be more help.

BuriedCode
 

    louislu

    Points: 2
    Helpful Answer Positive Rating
Re: lcd display

thanks...ya basically what u said is correct...so now the problem is on the data rate i think...the data rate from that serial device may b too fast for user to catch up...so i think i would need a buffer or what to slow down the dispaly spped on lcd...what kind of buffer can i use...?anyone can help me?
 

Re: lcd display

Hi again,

Well, as I said for a buffer, a 'FIFO' (first in first out) sort of thing. Its basically (correct me of I'm wrong people) and elastic buffer. Say you have 20 registers set aside, named, temp1- temp20 for exmaple, every time you get data coming in from your serial port (the micro will take care of this on its own if set up right), it will be stored in a temperary register, think its SBUFF for the PIC serial port. Set up an interupt, and when this buffer is full (you got data!) the interupt polls, and you got to a subroutine, this simply writes to the 'temp1'. And then increment a counter, so that when the next lot of data comes in, it writes to 'temp2'. Without writing to the LCD, and keeping the data stored, you'll be able to capture 20 bytes before your buffer overflows. You can then take each byte, (starting from temp1) and write it to the LCD. its messy, but I've done things like this before.

Assuming you have a hardware serial port on your micro, (ie: not code), then recieving data is easy, you just set it up with the correct baud (for async) and connect up the pins, possibly requiring a level changing circuit (changing rs232's 12v/-12v to 5v/0v for the pic, the MAX232 can do this easily). And you can execute any code you want untill data have been recieved, then you'll need the interupt, which can send you to a subroutine (am I repeating myself?).

Right, so you've got data coming in, and you are storing it appropriately, sweet. But what about the LCD? Well, when the data received intrupt goes, your subroutine will be pretty small and will only execute when a data packet comes in, which means you micro is doing nothing most of the time, so, your 'main' code can be your LCD writing routine. This will go through your temperary registers (temp1- temp20) and write each one to the LCD. If you want it to write each character slowly, use a timer interupt. But, be warned, you want your data interupt to take priority over the timer interupt, otherwise, you could miss data while you're writing to the LCD.

Btw, I've made some huge leaps of faith with assuptions here, I only really have experience with PIC micro's. And as I said before, what is this device thats sending the async data? Is it standard 1 start, 8 data, 1 parity, 1 stop type scenario? The regularity of the incoming packets to your micro will determine the size of your buffer. And........(sorry, I'll stop in a bit)....If you're getting say, 600 bytes per sec coming in, you can't store all of it till the end of time, the speed at which you write to your lcd will ultimately have to be the same speed as the incoming data. A buffer is only to allow for changes, for example, you get a burst of 10 packets at 9600bps, one after the other, every 10 seconds. Your LCD could display these either as soon as they come in, or you could spread them over the 10 seconds, ie: write one character per second. The latter idea requires the buffer to keep the data safe, until its sent to the LCD.

I'm sure I'm overcomplicating it, if its for a keyboard, then you'll have no problem, I hope this makes some sort of sense, its late :(

Buried(in)Code.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top