This page created 11-04-2002 23:11:17

Back to Index

Kilian's Robot Shop of Horrors - 11/01/2002

Click thumbnails for a larger view.


Subject: [TCRG] Trippy moves!!!!!!!
Date: Sat, 2 Nov 2002 11:13:42 -0600 (CST)
From: Alan Kilian
To: tcrobots@orbis.net (Twin Cities Robots Group)

Thanks to Jeff and Brynn last night, Trippy actually moves!!!

And has a super cute 4x20 LED back lit LED that can display text. (Brynn, you were right. We needed to make a 2 Inch long cable.)

The "getting it to move" problem was this. I'll send an answer in a later message.

There is a setting for the motor proportional constant from 0 to 65535 in some units. I tried setting a value of 1000, and the motor wouldn't move.

This value is known to work.

The PIC-SERVOs have a serial link, so you send a string of bytes like AA 01 04 E8 03 to set a value of 1000 (3E8 in hex)

The code looks something like this: (Of course this isn't real code)

int Kp;
unsigned char *p = (unsigned char *)&Kp;

Kp = 1000;
send_byte(0xAA); // Initiator
send_byte(0x01); // Which motor
send_byte(0x04); // Kp command
send_byte(p[0]);
send_byte(p[1]);

Which works when run on a PC, but doesn't work when run on a Motorola 68332 processor.

OK, I'll give you a hint.

If you do:
send_byte(p[1]);
send_byte(p[0]);

It doesn't work either.

Well, it was a mystery for about 20 minutes, and then I changed just four characters and it works.

And the LCD just REFUSED to work even after we figured out that the MRM has pins 1->14 wired up as pins 14->1 and we even made three cables to get things working. (Jeff made I should say)

We had about 8 Inches of ribbon cable going to the LCD, and when we had it plugged in, the MRM wouldn't boot. It got a RAM self-check error.

Brynn kept saying the cables were too long, but REALLY! 8 Inches of cable?

Well, (after he left) we had run out of options, and we made a 2 Inch cable, and guess what??? It works perfectly.

I's a good thing to have many opinions at the ready when you are having problems.

-Alan

Mark Castelluccio wrote:

Alan,

I have found that the maximum length of the LCD cable is about 3 inches. The LCD is mapped directly to the data bus and at 16Mhz, the extra loading from a long cable is enough to cause problems.

Is the answer, 32bit ints?

Mark

Jeff Sampson wrote:

After we decided the cable length really was the problem, we tried to theorize why that was so. We finally decided it was the "E" line. Which is the enable to the LCD. The "E" line had to be toggling because the data on one of the LCDs would randomly change on it's own.

http://www.robominds.com/Downloads/mrmsch.pdf for those that want to follow along...

We looked at the CS9 (chip slect 9) and CS10 for quite awhile and also at the tristate buffer that combines the two to create the "E" signal. (U5:B at bottom of page 1) First we couldn't figure out why two chip selects were being used and then why they were combined with a tristate buffer.

After more digging we decided the CS10 line was some kind of Motorola magic to allow slow I/O devices.

I personally think the LCD cable problem is R10. I'm thinking the relatively high impedance when U5:B is not enabled allows the "E" line to pick up cross talk from adjacent lines on the cable. So a quick thing to try would be to solder a lower value resistor right on the LCD from "E" to GND. (100, 470, 1000 omhs?) Then run it on a long cable and see if it works right. If that works then it won't require hacking the MRM board. Maybe we can try that next week.

--
Jeff Sampson

Alan Kilian wrote:

Well,......

Don't Pentiums have 32-bit ints?

The code does work on a Pentium.

(But you're soooo close)

-Alan

Brynn: Keep your mouth shut.

Mark Castelluccio wrote:

Pentium is little endian vs 332 which is big endian.

Bill Arden wrote:

Yes, however [0],[1] would be [3],[4]

When speed and code size is not important I would use.

(Kp | 0xff)
((KP >> 8) | 0xff)

The 0xff is not needed if send_byte accepts a unsigned char.

Alan Kilian wrote:

And Bill gets it right too.

And that's a good way to handle it "endian-neutral"

Even if it takes some processor time.

-Alan

Mark Castelluccio wrote:

Jeff,

I have experimented a little with your idea of changing R10 to improve the LCD cable length. First, I made a 6 inch LCD cable and it exhibited the flaky character behavior as expected. I soldered in a 1K resistor directly on the LCD between the E and gnd pins and the LCD appears to operate correctly. Next, I tried a 15 inch cable and it worked as well. Then I removed the resistor on the LCD and replace R10 with a 1K resistor, the 6 inch cable works, the 15 inch cable is still a little flaky but works much better.

It looks like a 1K resistor on the LCD end of the cable will work well.

Thanks for the idea,

Mark

Alan Kilian wrote:

Jeff is the man for this kind of thing.

I am going to solder a 1K Ohm resistor at the LCD end on my short cable just to keep things sturdy.

-Alan


Trippy LCD

rsoh03.jpg
This is what Trippy looked
like before we started.
rsoh02.jpg
Some of the displays. Alan
wants to use the lower one.
rsoh01.jpg
We needed to go from a 2x7
connector to a 1x14
connector. So we went to the
bag of cables.
rsoh04.jpg
We found this schematic on
the Internet. But it had 16
pins and ours had 14 pins.
rsoh05.jpg
Jeff prepares top solder
the cable to the LCD.
rsoh06.jpg
Brynn brought some Swedish
Fish just in case we needed
any. Tasty.
rsoh07.jpg
Oh, the MRM connector is
backwards. Jeff unsolders
the cable and uses solder
wick on the pads. Then
solders the cable in the
reverse direction.
rsoh10.jpg
We kept referring back to the
spec sheets to figure out the
chip selects on the MRM (Mini
Robomind) board to see why it
still didn't work.
rsoh08.jpg
It still won't work. So
Jeff solders a 2x7
connector on another LCD.
rsoh09.jpg
Ready for testing.
rsoh12.jpg
On a 12 inch cable the LCD
randomly displays these
characters all the time.
rsoh11.jpg
A quick shot of the
development environment.
rsoh15.jpg
The original LCD with a 2
inch cable.
rsoh13.jpg
We didn't have the backlight
connected so we used a
flashlight.
rsoh14.jpg
After we hooked up the
backlight and had the
PIC-SERVO code fixed.


Back to Index

Back to my home page http://www.pobox.com/~jsampson

Visit Twin Cities Robotics Group

This page is currently maintained by Jeff Sampson