Hey guys! Its been an amazing year so far. We bought an LCD from sparkfun. I have no idea how to get it to work? I checked Kevin’s site but he has no diagram or code on it. I saw one called serial driver but I have no clue how to use that code to make the LCD work. Is it possible someone can give me some directions? for example how to wire it and what code to use? Please be as clear as possible.
Which LCD did you buy?
Serial input?
You’re going to have to write the code yourself. The LCD communicates via serial, and does things based on different commands. There is documentation on these commands.
The link leads to the LCD we are using. I am so confused on how to hook it up. I know that i have to attach it using RS32 but how do i connect RS232 to this LCD device since it has this small adapter attached to it??? and where do i connect this RS232 on the operator interface? Seems kinda a weird, its like i am going in circles.
this is the link to the adapter that is attached at the back of the LCD already called “Backpack.” Also our adapter has the female end for the “GND 5V RX” pin because in the image you sill see two different adapters. One with male end and one with female end. Please let me know if you guys can come up with solution.
The link you provided points to a conventional character type LCD display with a KS0066U controller on it. This controller is compatible with the older Hitachi HD44780 controller. Overall, this type of controller is very popular and if you use your favorite search engine with one of those part numbers and the phrase “source code”, you’ll find quite a bit of helpful information already targeted towards a “how to” approach as well as a variety of source code drivers.
In short, you’ll need to connect the RS (register select), R/W (read /write), E (clock), and either 4 or 8 of the data lines to I/O pins on your microcontroller… in addition to providing power and a contrast adjustment pot.
Here are some links you may find helpful:
http://www.sourceboost.com/Products/C2C-plus/ExampleCode.html
A posting in the sourceboost forum
http://panda.bg.univ.gda.pl/~janusz/software.html#lcd
If you poke around on the SourceBoost website, I was able to find several different versions of HD44780 compatible drivers written by a few different people.
Hopefully that will get you pointed in the right direction…
Hey Dave thanks for the message. Just to clear up, I want to use this LCD for OI so the drivers can view the heading angle of the robot etc. So, how can I connect? Like its not clear. Using the adapter which sparkfun has already attached to LCD there are only 3 holes I see, 1) 5V 2) GND 3) RX. I have looked at many codes infact kevin has written one as well but what I understand so far is that these codes are written so that the LCD can be mounted onto the robot not on Operator Interface. Please let me know Dave if I misunderstood something. I really appreciate your input.
The Backpack handles the serial communication and can be hooked up directly to the TTL port on the RC (gnd-to-gnd, 5v-to-5v, Backpack/Rx-to-RC/Tx). I do have example code that uses a digital output instead to communicate through, but the TTL port is the easiest way to do so and has the advantage of using more efficent dedicated hardware. Kevin’s example is very clear too.
The OI does not have a serial port that you can control well enough to allow you to hook your LCD up directly to it. You’d need something to take input from the OI’s Dashboard port, decipher the format, extract the data you wish to display, then issue the appropriate sequence of LCD commands.
Thanks Mark for clearing up. So with the help of “Backpack” I don’t have to do anything, absolutely no wiring but simply attach that LCD to the serial port. Also for the coding I can simply use Mr. Kevin’s code for serial driver.
What if I am also using a camera? How do I manage to use serial driver than?
Also mark as you stated that we can use digital input/output pins to use the LCD. Is it possible you can share that example code with us so we can probably elaborate on it? Please let me know thanks.
It sounds like you are trying to set up a system that connects to the OI dashboard, parses the data, and then prints it out onto a LCD.
If you are looking at just doing the current angle, why don’t you use the 3 number display already on it?
if you still want to do the LCD, I would suggest using a 16f628 and decoding the dashboard data. The specs on the data packets are on IFI’s website.
The serial driver should take care of everything in the background. Just set where you want to send the data and go for it. The problem is not so much the serial driver (everything is done in printf’s, there is no need to recieve or parse any data), but rather the code to drive the LCD itself. Serial is the established protocol for the LCD screen and you have something to stick to that protocol, but you still need to write code to make the LCD work.
What exactly do you plan to use this LCD for?
There are two native serial ports on the RC. The TTL port could be used for the LCD and the programming port can plug right into the camera. Kevin’s camera code is setup to handle that for you with one change. You’d have to swap the programming port plug to download new programs, or you might be able to make a splitter cable to share the port, then you’d just have to turn the camera off long enough to download program changes.
The example code is here. It isn’t as nicely commented as Kevin’s code. It’s real purpose was to support training on the use of timers and some programming concepts.
It looks like many of the other responses you are getting in this thread may have missed your desire to have this on the Operator Interface.
As Mark corrected pointed out, the ‘backpack’ will need something in between the dashboard port and the backpack’s serial port.
Also keep in mind that the ‘dashboard’ port has RS-232 levels on it, whereas the backpack is expecting a TTL level signal.
The Backpack uses a PIC16 CPU that is FLASH based, and the programming header at JC1 could be used to reprogram the PIC with your own custom software. This would allow the display to work directly from the dashboard data, but for that you not only need to write the display drivers (which I’ve already provided pointers to) but also the serial port parsing code to interpret the dashboard data and turn it into something meaningful on your display.
You will also need an in-circuit programmer. Microchip’s ICD2 is about $160, but if you search around you’ll find clones for less and information on how to homebrew them.
The PIC16F688 only has 7K of program memory, which might be a little small if you want to write the new program in “C”, so unless you can avoid doing anything that requires one of the “C” libraries to be linked in, you might end up needing to write the new program in assembler.
Writing new code would be the cleanest way to do it, but certainly inserting a small microcontroller with two serial ports in series would be another way to do it.
Thank you very much everyone. This post has been really helpful to me. Thanks Mark for sharing your code. The purpose of this LCD is to check the flow of current in our robot, check robot’s current angle and distance travelled which is monitored by Gear Tooth Sensor and Gyro. However, the LCD adds the cool factor to the control system. Since its difficult to attach this LCD to the Operator Interface. Now we are planning on attaching a tablet to the OI and have it setup up so the drivers can see all motor values, gyro value, gear tooth value and infact they can precisely control the robot by looking at these values. Also, it helps in troubleshooting our autonomous after every game because we will have record of what went wrong where. So ya!
Is it possible I can change between the two codes in my robot? for example a default code and camera code in robot without downloading back and forth? So I can have control over which code will be used during each game just by flicking some switches on and off?
Hey Dave thanks for sharing that info its really amazing. Thats exactly what I am planning on doing with my Tablet, I don’t want to use the IFI’s Dashboard. or infact use it but have more features to it example it shows ur gyro angle and GTS tooth count, camera values etc. So Dave would the process be still the same for tablet? the fact that I would have to create a cross platform between what Dashboard recevies and what info shows up on my tablet? and what programming language do you prefer this platform to be made in? V.B? C? C++?
If you have some unused Digital I/O inputs, configure one or more of them to control which ‘code’ runs.
unsigned char whichone = 0;
if (rc_dig_in 14) whichone |= 1;
if (rc_dig_in 15) whichone |= 2;
if (rc_dig_in 16) whichone |= 4;
switch (whichone) {
case 0: {
// run this code
}
case 1: {
// or run this code
}
case 2: {
// and so on...
}
default: {
// just in case...
}
} // switch
On the digital inputs just make up some jumpers, or install some switches between the digital input and ground. You might want to avoid using miniture switches that might be jarred during competition.
If you search a little here on CD you’ll find previous discussions and pointers on dealing with the dashboard data. Included with IFI’s dashboard download you should find their documentation on the serial protocol.
In short, each frame consists of 26 bytes, with the start of the frame consisting of 0xff 0xff. There are three frame types, and you need to look at bits within control bytes to figure out which frame of data you’ve just received.
The ‘dashboard’ port is simply the raw data from either the RC->OI OR the OI->RC, the shunt near the connector controls which half of the conversation you are monitoring. The bit rate is 19200.
Remember, this is the raw, unchecked data passing between the OI and RC. There are two “checksum” bytes in the middle of the packet that the RC and OI use to determine whether the packet was good or whether it was corrupted.
For some odd reason, IFI won’t document the “checksum” works, and I guess once you know how it works, we aren’t supposed to reveal their “secret”.
I suppose for just displaying data, data from an errored packet will be quickly replaced by good data and any resulting ‘glitch’ will probably go un-noticed by the end user. If you use the ‘user’ bytes to multiplex more data at a slower speed, then understanding how the “checksum” works becomes more important.
As far as the language choice, VB, C, C++, Delphi, will all work fine. It is more a matter of which platform and compiler you are most comfortable and experienced working with.
Thanks Dave that was really helpful! 
I hope I succeed in my mission.