BasicCoder2 wrote:Your description of what you are trying to do isn't all that clear to me. I read you as saying you want a remote keyboard and display for an electrical instrument that already has a keyboard and display? It doesn't seem to me that the code would be very complex and thus would be easy enough to develop up front using the Arduino board alone. I am not even sure where the serial connection comes into it? Does the current keyboard and display have a serial connection to the instrument?
Instrument meaning a specialized device that does GPS tracking and recording. The user interface is a 2-line display and a couple of buttons. The main board communicates with the screen and buttons in the same chassis over a serial link. There's a protocol that is used to tell the screen what to display and where. And when buttons are pressed, this information is transmitted back to the main board over the link. Think of the screen and buttons as it's own separate computer, because it actually is. This sort of modularity is very common in the embedded world. One microprocessor may do the main work while another one handles the UI. Another yet may interface with sensors. They all communicate together over busses of different kinds, usually i2c or serial.
And actually if you think about it your computer does something similar. When you press a key on the keyboard a microprocessor determines what key it was, debounces it, and sends a signal using a particular protocol over a particular bus (USB often). Even modern computer monitors have powerful computers in them to render the image coming over HDMI, DVI, or VGA signals, and drive the LCD matrix. Anyway I digress. Sorry to hijack your thread. Clearly our aims are slightly different.
My remote display unit will allow me to place the screen and buttons in a more convenient place while the main unit (with it's own screen and buttons built into the chassis) will be elsewhere. Here's an example of the protocol. It's an ASCII, line-based protocol:
Code: Select all
Each of the three lines here is terminated with a CR/LF. Anyway, see if you can make sense of that (though without seeing the actual screen and what's being displayed it won't make as much sense). The first hex number is telling the display we want to write to row 0, column 6, and then the next 4 numbers tell it to write "----" to the screen. The number after that (078) tells the screen that ASCII character 15 is going to be defined to be a custom bitmap, which the next 8 numbers specify (8 rows of bitmaps for one character), and the 002 specifies the end of the definition. It goes on from there, using a similar pattern.
So it's simple enough , but it took me a while to figure out it. Looking at the numbers in binary helps me identify patterns I can look for. A programmer's calculator is pretty important here to easily convert between hex, decimal, and binary.
Anyway the reason they use a protocol is so that the screen unit can easily detect valid data and ignore stuff it doesn't recognize such as errors or noise in transmission. One thing that tripped me up is that when a character is redefined to a custom bitmap, it changes all existing instances on the screen already to this new bitmap. Lots of trial and error! This is why the PC is logical to work on first, not the Arduino. Debugging is much easier!