hack #1?

Hi all. I've begun setting up the serial comm setup for the back-end. As expected, I've come across a few hangups while designing it.First the good news: the CON1 header provides me with a nice interface to the various GPIO pins. A section is connected to the LEDs, and another is connected to the switches. There are also 4 unconnected pins connected to solder pads on the reverse side.

Unfortunately, the DSP36761 does NOT have a UART, which would require me to bit-bang the RS232 interface. This is achievable, but not as elegant as I would like. Once the real DSP stuff gets running on the chip, I can foresee some communication problems (missed bytes, corrupt data, etc.) Therefore, I opted to use the SHI peripherals that the DSP36761 provides: SPI and I2C. As mentioned earlier, the CON1 header has connections to the GPIO pins, but NOT to the SHI pins... but remember what I said about the open solder pads on the reverse side? In the manual, it suggests that these pads be used as endpoints for jumpers to the I2C pins that are underneath one of the switches.

Now that that's done, I still need to somehow convert the I2C protocol stuff to RS232. Well I thought about it for a bit, looked around my shoebox, and realized I could use my leftover dsPIC to handle the comm with the front-end (implementing the protocol state machine) and convert the I2C bytes to RS-232 bytes. The MAX232 would be connected to the dsPIC's UART pins for some level-translating action.

edit: I just finished whipping up the schematic and layout for the I2C <-> RS-232 board. I'll put in an order to BatchPCB.com and get this thing spun in a jiffy.

edit 2: I just realized that since the I2C bus is essentially visible through the RS-232 serial port, it'll be possible for the EEPROM (where the code is stored for the DSP) to be updated through the serial port. Field updatability perhaps?
- Marc