Has anyone looking into trying to implement an external data bus for the RC? I’ve been thinking about it, but I’ve come up against some big limitations.
The first is that the digital I/Os are filtered. I think I figured that the regular ports would get ~10 bytes/ms with an 8bit wide parallel bus. Using the interrupt ports (with a higher pass filter) would require a serial bus because of their limited number. I figured that it’d get about the same data rate, but would also require control bytes. Essentially, no real gain, but with much more complexity.
The next options are the serial ports. The TTL port is out of the question because it would eat the camera’s interface. This leaves the program port. My main concern is that it would eat the RC’s main debugging port. Actually…what would happen if more than two devices are connected to this port? Say that the bus controller is on the same port (split cable), but has a command set that would have it ignore any traffic between the RC and a PC. Of course, the conflict resolution would be really nasty. There’s also the option of passthrough; flag the bus traffic and pass anything else.
Sorry for the rambling, I just want to get ideas out.
Yeah, we played with 8 bit dual port ram. The idea was to have a small amount of parallel transfer buffering between various smart peripherals. Each would own a different address chunk and there would be a different dual port ram associated with each peripheral.
We never got it very reliable due to heavy RC filtering on the pins. I was going to go back and put some schmitt buffers to clean up the signal edges as I thought the slow rise/decay times that might be part of the problem… but never got back to it.
Always the biggest problem with parallel data transfer (and one of the major reasons it disappeared from printers) is that no matter what you do, all 8 signals do not arrive at the same time… and the smallest little change in the electromagnetic field surrounding and within the wires can change the time it takes for each signal to travel.
However, in your case, I think you can make the parallel work. What you’ll have to do is make your parallel bus synchronous, not asynchronous. You might try having 9 lines run from one device to the other. 8 for data, one for sync. The 8 data lines can run to/from any old DigitalI/O pins, but run the sync line to a PORTB interrupt pin. All you’ll have to do is make sure that you wait a microsecond or so (at least 5 nanoseconds per foot of transmission distance) then send your sync pulse. Or, you can write your byte and send the sync pulse all at the same time, then have your recieving device read they byte when the sync pulse goes low (again watiting at least 5 nanoseconds per foot).
If you don’t want to play around with synchronous parallel (i wish you would though, sounds like a fun project!) I like your idea of putting a bus control module on the program port… very interesting. You might make up some kind of command set to direct where the serial port on the controller connects to… kind of like a digitally controlled serial switch box. You’d just need a micro with a few UARTS to pass bytes around inside… i’m sure most low end DSPs and probably some higher end embedded processors would have the 3+ uarts you’d need (unless you want to bit bang, which is another option entirely).
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.
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.
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?
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.
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.