How to Hook up LCD

[magical hands]

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.

[Mark McLeod]

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.

[magical hands]

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?

[magical hands]

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.

[Binome]

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.

[Mark McLeod]

Originally Posted by magical hands

What if I am also using a camera? How do I manage to use serial driver then?

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.

Originally Posted by magical hands

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?

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.

[magical hands]

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?

[magical hands]

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++?

[Dave K.]

Originally Posted by magical hands

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 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.

[magical hands]

Thanks Dave that was really helpful! I hope I succeed in my mission.

[Dave K.]

Originally Posted by magical hands

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?

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.

[Tom Bottiglieri]

Originally Posted by magical hands

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?

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?

[Dave K.]

Originally Posted by magical hands

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.

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.