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.