THE QUESTIONI was wondering if it was possible to interface one of your 4x20 LCD displays (LCD420A) to your CPU_1A1 board; and if so, would I also be able to interface the CPU_1A1 to a computer and a keypad? The idea is to have it run on its own, without input from the computer, read from Dallas 1-wire temperature sensors, store the information and display it on the LCD while allowing the pc to read it at the same time. Also, at the same time allowing the pc to send data to be displayed on the LCD. What about having two LCD displays, where one displays temperatures from the temperature sensors, and the other displays data from the pc; all while still allowing the PC to read the temperatures? THE ANSWERIn short; Not a problem. There are two parts to the answer; hardware and software. Hardware:There are hardware options, and some questions to be answered and guidlines to be set.
I would usually try to trade off hardware and software. We don't want the hardware or the software to be too complex. Usually simplifying the hardware complicates the software and vise-versa. LCD Interface:The only tricky part from the hardware side is the LCD interface. Lets run with 2 parallel 4-line 20-character LCD modules. The interface that uses the least I/O on the CPU is 4-bit mode; unfortunately it still needs 7 or 8 I/O lines, and an enable for each LCD. Thats no good because is would tie up all of the good I/O on the CPU. Assuming we are going to only write, we need CPU output lines. Another option would be to put a serial-to-parallel latch between the CPU and the LCDs. Two 74HC595s would provide 16 outputs from only 3 or 4 CPU I/O lines; enough for two LCDs, a keypad driver and a couple of LEDs and buzzer. The only real disadvantage is that you need CPU code (a program) to manage the few CPU I/O lines to make everything work (bit bashing - assembly code programming recommended). A third option would be to use a smarter interface between the CPU and LCDs. The GPC_5A1 would reduce the software overhead by looking after the LCDs, but increases the hardware cost. Probably only one GPC_5A1 would be needed to drive 2 LCDs because of a feature that allows it to drive 4-line 40-character LCDs (which appear as 2 seperate displays). The software is simplified because the subroutine to drive the GPC_5A1 is provided and you send higher level commands to the displays. Keypad Interface:How easy this is depends on how many buttons you need. The best way is uaually to scan the buttons in a grid array of rows and coloums. 4x4 will give you 16 buttons. This requires 4 outputs and 4 inputs. The 4 outputs can come from the CPU directly or from the 74HC595 latches mentioned above. It also requires some software to do the scanning. Another option is to use an external keypad controller. Probably not warranted in this case. A third option would be to use a PC keyboard. This gives you plenty of buttons, but you need a software routine to communicate with the keyboard. The PS2 keyboards use a serial protocol; USB is too complex for this application. Note, combined LCD/keypad:I have made some interface boards with keypads and LCDs that connect to the CPU in a same way to the GPC_5A1 interface mentioned above. The largest is 2-line 40-character with 16 buttons. Cost is probably a bit restrictive for this application. RS-232 and Dallas 1-wire:The RS-232 is easy with a MAX-232 interface chip, like on the CPU_1A development board. The Dallas sensors connect directly to the CPU_1A I/O lines. Software:Writing the software would be the biggest part of the project. Lets assume a 74HC595 latch interface. The first step would be to write a driver. This would probably be a small group of subroutines that take convenient data bytes and send them to the LCDs while scanning the keypad buttons. The next level up would would deliver the data bytes as required. The result is that you save a string to a buffer and call a subroutine, as if magic, the text appears on the LCD. By making better use of the interrupts, you don't even have to call the subroutines. Your application writes strings to a buffer in RAM that resembles the LCD's, and the messages appear on the LCDs. I would recommend using assembly language programming to do this. Higher level languages could do it, but I think, more slowly and with more processor overhead. In assembly the whole LCD and keypad support system should not be more than about 1K bytes of code. Reading Dallas temperature sensors is not too difficult; been there, done that. Supporting one sensor on the bus is relatively easy. When you have more it gets a bit more complex because you have to address individual sensors. The protocol to identify sensors on the bus is also rather complex. It is possible to read and register the sensors one at a time. Some good assembly language subroutines hide most of the work involved in talking to the sensors. Using the RS-232 is also not too difficult. Again, subroutines take care of transmitting and receiving bytes. Interrupts should be used to avoid loosing characters and corrupting messages. So, there are a group of low level functions that support the hardware. Your main application passes data to these functions and receieve data from them. You main application then basically just has to shuffle the data at a higher level. As you can tell from all this, I like and use assembly language a lot. Because I have a large library of functions for the HC11 and many standard I/O devices it's not too difficult to patch things together. For anyone using our hardware modules I don't mind assisting with support and assembly software code where I can.
|
|
LOW COST, Small Size |
Low Power, Simple to use |
||
|
Simplifies I/O expansion |
Use with any small micro |
||
|
*** . *** |
|||
|
. |
|||
|
|||
|
Information, Links and Files |
||
|
GPC_5A1 Circuit Diagram (pdf) |
||
|
. |
. |
. |
|
PMB home |
|
last updated: 19 June 2003 |
