I know that the VEX 2.0 controller design is probably wrapped up and you are working on manufacturing logistics at this point, but I’d like to suggest an option/upgrade if it isn’t too late:
SD/MMC memory slot or an SPI bus interface.
Several folks have wanted to create bots that make maps or record logs. An SD/MMC flash slot would make that easy, as well as introduce a new way to get programming into the controller.
A second choice would be to include an SPI bus, which allows a trivial interface to an SD/MMC card reader, since it is basically just a cable. And of course, SPI covers pretty much all the add-on parts that aren’t I2C so having both would be a big win IMHO.
The I2C interface that is currently planned (THANKS!) should allow for the creation of a flash card reader peripheral, but it would require an MCU to translate from SPI to I2C.
Also, I realize that the WiFi interface will allow a computer to capture data coming from the controller, but having local storage allows for more interesting autonomous operation.
That’s a really great idea! You can have any amount of storage space you need for complex programs and maps! You should have a block in Easy-C that allows you to use the data! It would be great if you could store programs on the memory card too, so you can switch between programs. If there was another card slot, could you use the memory card for RAM? Would it make much of a difference?
Yeah, that occurred to me, but I didn’t want to be greedy
I figured an I2C D->A convertor would be a nice add-on that could be used to generate audio from an array of samples. Of course, the easiest part I’ve found for decoding actual MP3s is the VS10xx family, which is interfaced via an SPI bus
While I’m posting, I’ll recommend how I’d bring out an SPI port:
Use a standard VEX 3-wire connector for the 3 shared SPI signals: SCK, MISO, MOSI. Each SPI device would attach to this shared SPI port as well as one (or more) digital-out ports for their CS signal, ground, and power.
So, every SPI device would have at least two cables: One for the shared SPI port (use Y-cables as needed), and one or more cables for power and chip select.
*[EDIT]
*On second thought, the shared SPI connector needs to be slightly different from a standard VEX 3-wire connector - perhaps just keyed differently. You wouldn’t want somebody plugging the SPI cable (which is just signals) into a regular (powered) VEX port by mistake. The basic idea still works, though.
*[/EDIT]
*
Cheers,
If the SPI port were a 3 wire connection as you suggested then the only downside is that someone would plug an existing motor or sensor into the jack. That should not be a problem since you are not shorting any pins out.
Plugging the SPI port cable from the device into the wrong jack is a problem, if you made the center pin (what could be +5v) the MOSI pin then pulling it high should be OK.
Too right. The reason I thought it might be a problem is if the SPI cable is plugged into a motor port, but the CS cable isn’t. In that case the unpowered SPI device would have a pair of signals driven hard at up to 9V.
This may be kind of an odd-ball case, but it is the kind of ruggedness that the VEX parts seem to be designed to withstand.
This could be resolved with suitable protective electronics in the SPI device, but I thought a custom connector might be an easier/cheaper option. Of course, only having to use one kind of extension cable is a plus…
And since the SPI cable doesn’t carry power, there is no risk of an exposed end of an extension cable hitting a metal part and shorting the power rails.
Now that we’ve got it all designed, we just need to kind folks at IFI to build it for us
An then again, on Second Thought, they could still plug the Expansion Cable back into the Vex Controller, in a PWM or I/O connector, and then damage the SPI connection.
The SPI port will still need to be Protected, in some way…
Right, but at least it is just the port on the microcontroller that needs to be protected. The individual SPI peripherals would not need elaborate protection on their side of the interface.
Just because you are paranoid, does not mean they are not out to get you.
The VEX platform is known for making things as robust as possible, so thinking this out is good. Trying to keep builders from making expensive errors is always good.
I’d also like to see an SPI link on the new controller too!
I can’t be sure if this has/hasn’t been mentioned at all, but using usb-usb to transfer data to the micro-controller might be helpful, that way there won’t be any time wasted converting to serial…
Well, USB is serial (that what the middle letter means ). If you’ve looked at USB software, the complexity of the stack required for a conforming implementation is pretty daunting. I2C, SPI, and async serial (RS232) are trivial by comparison.
