Wishlist/Expansion Protocols - Revision history

Zimon :P: /* I2C breakout */

2008-10-21T17:54:03Z

‎I2C breakout

Zimon :P: /* I2C breakout */

2008-10-21T17:48:32Z

‎I2C breakout

DolfjeBot1: Wishlist:Expansion Protocols moved to Wishlist/Expansion Protocols: Replacing 'Wishlist:' with 'Wishlist/'

2008-08-31T12:21:27Z

Wishlist:Expansion Protocols moved to Wishlist/Expansion Protocols: Replacing 'Wishlist:' with 'Wishlist/'

Glenn: +{{Hardware Wishlist}}

2007-07-17T06:56:10Z

+{{Hardware Wishlist}}

Glenn: catspec

2007-07-16T11:36:40Z

catspec

Glenn: +cat

2007-07-16T10:18:29Z

+cat

Speedevil: /* What FIC could do. */ Add I2C from main wishlist

2007-07-15T11:51:28Z

‎What FIC could do.: Add I2C from main wishlist

Speedevil: Page detailing hardware and software protocols for expansion.

2007-07-15T11:50:28Z

Page detailing hardware and software protocols for expansion.

New page

===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.

@@ Line 21: / Line 21: @@
 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.
-What did you mean by this "digital input/output chips to 1-wire bridge chips "
+-What did you mean by this "digital input/output chips to 1-wire bridge chips "
-And I fully agree It would be really good to have it :)
+-And I fully agree It would be really good to have it :)

← Older revision		Revision as of 17:48, 21 October 2008
Line 17:		Line 17:

	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?		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.		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.
		+
		+	What did you mean by this "digital input/output chips to 1-wire bridge chips "
		+	And I fully agree It would be really good to have it :)

← Older revision		Revision as of 06:56, 17 July 2007
Line 1:		Line 1:
		+	{{Hardware Wishlist}}
		+
	===What FIC could do.===		===What FIC could do.===

Line 17:		Line 19:

	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.		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.
−
−	~~[[Category:Hardware ideas]]~~

← Older revision		Revision as of 11:36, 16 July 2007
Line 18:		Line 18:
	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.		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.

−	[[Category:Hardware]]	+	[[Category:Hardware ideas]]

← Older revision		Revision as of 10:18, 16 July 2007
Line 17:		Line 17:

	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.		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.
		+
		+	[[Category:Hardware]]

← Older revision		Revision as of 11:51, 15 July 2007
Line 6:		Line 6:
	This would be a one-time plug in to the connector by the user.		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.		The cable would then be taped or glued onto the case, to provide strain relief in case the user opens the case without care.
		+
		+	===I2C breakout===
		+	[[I2C]] is an internal 2-3 wire bus in the phone. It is low powered, and can be daisy-chained. It would be a great candidate to bring out into the [[Expansion Back]] with an additional connector.
		+
		+	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.