m (Wishlist:Expansion Protocols moved to Wishlist/Expansion Protocols: Replacing 'Wishlist:' with 'Wishlist/')
Revision as of 12:21, 31 August 2008
|Hardware wishes warning! This article or section documents a Hardware Wish List item, the features described here may or may not be implemented in future devices.|
What FIC could do.
On slightly deeper modifications, one or two GPIO pins brought out to a connector would be ideal. Perhaps a connector next to the USB port, with connections for all the USB pins, 2 GPIO, battery VCC. I2C would be a great addition, perhaps instead of the GPIO pins.
This would be a one-time plug in to the connector by the user. The cable would then be taped or glued onto the case, to provide strain relief in case the user opens the case without care.
Readily available I2C chips range from temperature sensing, digital input/output chips to 1-wire bridge chips (which is designed for external switches, ID, sensing, ...)
Many microcontrollers, e.g. the Atmel AVR ATmega8 popularized by the Arduino project or many Microchip PIC ones, are able to serve as I2C slaves. This may allow easy and inexpensive creation of wide array of peripherals, e.g. a TV remote control (leverage the LIRC.org project here, namely use an avrlirc device modified to use 3.3V and I2C instead of UART) or an arbitrary number of buttons or an entire external keyboard (or even mouse/trackball), RFID reader, A/D and D/A converters with any desired precision, arbitrary number of GPIO pins, short-range nRF24L01 based transceiver to communicate with other devices, tamper-resistant ID tokens, or just about anything. The advantage over USB is the absence of need for an USB hub for connection of more devices, and no cost/logistics/power consumption of USB interfacing. The disadvantage is lower speed, which is irrelevant for most low-speed applications, especially if the I2C bus runs on 400 kHz.
A set of design guidelines, unifying and streamlining the process of interfacing with such peripherals (registration of a peripheral, polling for status changes...), maybe additional signals for things like sleep mode forcing (perhaps two power lines, one active always, one only when not sleeping, allowing the add-on microcontrollers to either directly sense the sleep mode and adjust their behavior or directly power the hungrier additional electronics - eg. LEDs - only when not sleeping, further simplifying the design), may speed up add-on development and increase compatibility. A nice thing to have would be a protocol standard for additional buttons and LEDs, with adequate software-side support, offering an easy solution for a range of other hardware wishlist items; maybe a functional equivalent of /dev/usb/event devices?
With a suitable simple mechanical/electrical standard for clip-on add-on modules there can be even a sizable secondary market for such enhancements. Even a suggested size of the add-on boards (considering the possibility of using multiple add-ons concurrently), especially together with the Expansion Back, would be greatly useful. A problem with limited set of I2C addresses would have to be solved (e.g. by plug-and-play like software allocation, microcontrollers allow setting their I2C address via a register) but that can be solved by a predefined power-on address (eg. 0x7F), an internal device unique ID, and an iterative device enumeration protocol similar to 1-wire scan.