data bus

[John Gutmann]

I don't know how the robot controller is setup up on the inside, but try SPI. It is a VERY simple system.

-John

[Alan Anderson]

Originally Posted by John Gutmann

I don't know how the robot controller is setup up on the inside, but try SPI. It is a VERY simple system.

The Robot Controller's SPI hardware is already taken by the master-to-user processor link. It isn't available for outside use.

[bear24rw]

I dont know what the minimum clock speed is for spi but you could probably just do it manually without using the hardware, you would just have to clock out your own bits.

[sciguy125]

Originally Posted by bear24rw

I dont know what the minimum clock speed is for spi but you could probably just do it manually without using the hardware, you would just have to clock out your own bits.

That's sort of the problem I've run into. The I/Os are so heavily filtered that I don't think I'll be able to get a reasonable data rate. I think this problem is a project killer.

[Stuart]

Well Ill share what Ive been working on for a while. what you could do is use the on board TTL serial port to talk with another micro chip( I would suggest a propeller chip from parallax). then set up another serial port on that microchip(ie 2 serial ports on 1 chip)so you dont lose the camera . you could then use the rest of the io pins on the chip to do what ever data you want to do.



and yes I am being coy about this. While I cant say much at this time(its not ready yet) I can say that this is a problem that my team talked about at the end of last year, and think we might have a solution.

[Alan Anderson]

Just how much data do you think you'll want to be passing between devices? The I/O is certainly fast enough for communicating with sensors and adjusting the motors based on the data. I'm assuming that part of the goal of using an external device is to preprocess information and give simple answers to the Robot Controller. If you're planning to read large amounts of data from the device, what benefit do you expect to get from using it?

[sciguy125]

I wasn't as concerned about how much data, but rather how fast I can get the data I want. (say encoders that need to be read at a known time) After thinking about it more, it's probably alright.

For a parallel bus, the data and address lines would probably have to be shared to minimize the number of I/Os it eats. This means that it takes two bus operations to read/write data. The ports have an RC constant of 6.8us. We'd probably have a settling time of ~25us for solid operation. So, access time is ~50us. That's an enternity in processor terms, but it might still work. How long is the access time for the analog ports?

A large amount of data may be a problem. However, a loop running in the background (triggered by a timer set to interrupt) could work on transfering data in a buffer. For anything that is time sensative, there could be a "do this now, I'm waiting" function.

[JimWright949]

What you can do is use an Atmel AVR to convert the TTL serial port to a I2C bus (Two-wire Serial Interface), then use another Atmel AVR to convert I2C (Two-wire Serial Interface) to TTL for the camera. Then you can hang other things off of the I2C (Two-wire Serial Interface) bus. I use AVRs because there is very little overhead to programming them, about $5 of Radio shack parts.

The AVR can also be used to convert the serial port to an external SPI bus.

-Jim