The low end Fire supports USB On The Go, therefore connecting custom external peripherals is possible via USB. This is from the xda dev pages:
Working
Full size Qwerty Keyboard
USB Mouse
USB to SD card converter
USB Ethernet
USB to Serial (FTDI)
USB Webcam
Not Working
USB to Serial converter (?)
Parani-UD100a USB Bluetooth Adapter
Parani & TP-Link did not show in Network Info II app
" It does not appear to support OTG + charging."
Reference: http://forum.xda-developers.com/amazon-fire/general/otg-2015-fire-kffowi-ford-t3245644
Overall this is pretty good convergence to tactile electronic paper. My design suggestion for a production product (not talking educational or toy use) would be to use a Microchip PIC18 or PIC24 both of which have full speed USB and solid peripherals on chip (such as 16-bit A/D on PIC24). Software development with MPLABX toolchain. Or for the non-C programmers, an option is to write in python and use micropython on chip. Unfortunately these days I'm away from my lab setup otherwise I'd have a demo up already.
By the way to answer a previous comment, the MIPS cores, such as 4K (now considered a microcontroller range), and MIPS-based chips are technologically superior to ARM in many ways. There's a billion types of ARM based chips out there because ARM licensed the core in a more widespread way (but not the bus!) based on royalty whereas MIPS did not license their IP in that "saturate the market" type of way. Also from a software developer standpoint it is usually better to go with the vendor with the more singular solution (MIPS in this example) rather than the highly branched solution (such as, ARM core in ST chip which uses a third-party ARM peripheral bus running with third-party software tools and open source libraries and bundled driver libraries that are demo quality in my opinion, if you look deep into the code, and incredibly bloated).
If the device (tablet in this case) is customized, then that is branching off of the convergence line. The result in the long term will only gain from the technology convergence up to the point of the branch, and won't benefit from the further technology gains (without continual custom development). Stay on the convergence curve, rather than branch off, for best results. That means building software which is distributable directly on amazon's default app store and accessory hardware which plugs in without hardware modification. However - it's more rare for companies take the approach of building an accessory for a device on the convergence curve because the priority of a company is to create ecosystem lock-in, basically the expression "We don't want to be a peripheral on someone else's device." Fighting the "Let's just branch!" instinct can be difficult on both the business side and the developer side.
The major limitation of these tablets is that they are not readable under sunlight - so outdoors use in the field could be limited. The e-ink readers would be the natural choice but the software development is more difficult (proprietary libraries, and custom development).
Working
Full size Qwerty Keyboard
USB Mouse
USB to SD card converter
USB Ethernet
USB to Serial (FTDI)
USB Webcam
Not Working
USB to Serial converter (?)
Parani-UD100a USB Bluetooth Adapter
Parani & TP-Link did not show in Network Info II app
" It does not appear to support OTG + charging."
Reference: http://forum.xda-developers.com/amazon-fire/general/otg-2015-fire-kffowi-ford-t3245644
Overall this is pretty good convergence to tactile electronic paper. My design suggestion for a production product (not talking educational or toy use) would be to use a Microchip PIC18 or PIC24 both of which have full speed USB and solid peripherals on chip (such as 16-bit A/D on PIC24). Software development with MPLABX toolchain. Or for the non-C programmers, an option is to write in python and use micropython on chip. Unfortunately these days I'm away from my lab setup otherwise I'd have a demo up already.
By the way to answer a previous comment, the MIPS cores, such as 4K (now considered a microcontroller range), and MIPS-based chips are technologically superior to ARM in many ways. There's a billion types of ARM based chips out there because ARM licensed the core in a more widespread way (but not the bus!) based on royalty whereas MIPS did not license their IP in that "saturate the market" type of way. Also from a software developer standpoint it is usually better to go with the vendor with the more singular solution (MIPS in this example) rather than the highly branched solution (such as, ARM core in ST chip which uses a third-party ARM peripheral bus running with third-party software tools and open source libraries and bundled driver libraries that are demo quality in my opinion, if you look deep into the code, and incredibly bloated).
On 12/3/15 4:21 PM, Bryan Bishop wrote:
Amazon Fire and other Android tablets can run debian chroots and a number of other alternatives are possible with the android kernel kvm branch. You don't need to write Android apps to use an originally-Android device.
If the device (tablet in this case) is customized, then that is branching off of the convergence line. The result in the long term will only gain from the technology convergence up to the point of the branch, and won't benefit from the further technology gains (without continual custom development). Stay on the convergence curve, rather than branch off, for best results. That means building software which is distributable directly on amazon's default app store and accessory hardware which plugs in without hardware modification. However - it's more rare for companies take the approach of building an accessory for a device on the convergence curve because the priority of a company is to create ecosystem lock-in, basically the expression "We don't want to be a peripheral on someone else's device." Fighting the "Let's just branch!" instinct can be difficult on both the business side and the developer side.
The major limitation of these tablets is that they are not readable under sunlight - so outdoors use in the field could be limited. The e-ink readers would be the natural choice but the software development is more difficult (proprietary libraries, and custom development).
## Jonathan Cline ## jcline@ieee.org ## Mobile: +1-805-617-0223 ########################
0 comments:
Post a Comment