We are designing a handheld-game console (based on EOMA-68).
The problem is that EOMA-68 has very few GPIO.
We have 17 digital buttons, 2 analog joystick ( http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/175591... ) and 2 analog triggers ( http://www.digikey.com/product-detail/en/EVA-W7NR04B34/P13569-ND/1135944 ).
Luke will use on the tablet the next IC: PCA9536.
However, this component does not meet our requirements.
Does anyone know a IC that meets these requirements (at least 17 digital buttons and at least 4 ADCs)?
Thanks.
Miguel Garcia wrote:
We are designing a handheld-game console (based on EOMA-68).
The problem is that EOMA-68 has very few GPIO.
We have 17 digital buttons, 2 analog joystick ( http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/175591... ) and 2 analog triggers ( http://www.digikey.com/product-detail/en/EVA-W7NR04B34/P13569-ND/1135944 ).
Luke will use on the tablet the next IC: PCA9536.
However, this component does not meet our requirements.
Does anyone know a IC that meets these requirements (at least 17 digital buttons and at least 4 ADCs)?
I count 6 ADCs channels required.
I suspect the only single-chip soloution would be a microcontroller of some sort.
On Sun, Jul 27, 2014 at 3:58 PM, peter green plugwash@p10link.net wrote:
I count 6 ADCs channels required.
I suspect the only single-chip soloution would be a microcontroller of some sort.
yeahhh i have circuits already done for the ATSAM4SB which is a very nice choice, and only around $2.50 or thereabouts in appx 10k volume.
2014-07-27 21:30 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
yeahhh i have circuits already done for the ATSAM4SB which is a very nice choice, and only around $2.50 or thereabouts in appx 10k volume.
Maybe too complex for what we need.
On Sun, 2014-07-27 at 20:30 +0100, Luke Kenneth Casson Leighton wrote:
On Sun, Jul 27, 2014 at 3:58 PM, peter green plugwash@p10link.net wrote:
I count 6 ADCs channels required.
I suspect the only single-chip soloution would be a microcontroller of some sort.
yeahhh i have circuits already done for the ATSAM4SB which is a very nice choice, and only around $2.50 or thereabouts in appx 10k volume.
2 Microcontroller SoM board in KiCAD GPL'd http://www.gplsquared.com/SoM1/SoM1.html
Make the IO controller swappable.
Board done up for LPC176x 100 pin chips, but easy enough to modify for any kind of similar chip and also go about standardising the connections.
Another option is the ST chip http://www.aliexpress.com/item/STM32F103ZET6-STM32F103ZET-STM32F103ZE-STM32F... (which is supported by the 'free' coocox compiler http://www.coocox.org)
Has LCD controller. Requires RAM: http://www.aliexpress.com/item/10PCS-IS62WV51216BLL-55TLI-IS62WV51216BLL-55-...
And plenty of NAND to store graphics http://www.aliexpress.com/item/FLASH-WINBOND-W25Q64FVSSIG-W25Q64FVSIG-SOP-8-...
On 08/15/14 13:02, joem wrote:
On Sun, 2014-07-27 at 20:30 +0100, Luke Kenneth Casson Leighton wrote:
On Sun, Jul 27, 2014 at 3:58 PM, peter green plugwash@p10link.net wrote:
I count 6 ADCs channels required.
I suspect the only single-chip soloution would be a microcontroller of some sort.
yeahhh i have circuits already done for the ATSAM4SB which is a very nice choice, and only around $2.50 or thereabouts in appx 10k volume.
2 Microcontroller SoM board in KiCAD GPL'd http://www.gplsquared.com/SoM1/SoM1.html
Make the IO controller swappable.
Board done up for LPC176x 100 pin chips, but easy enough to modify for any kind of similar chip and also go about standardising the connections.
Another option is the ST chip http://www.aliexpress.com/item/STM32F103ZET6-STM32F103ZET-STM32F103ZE-STM32F... (which is supported by the 'free' coocox compiler http://www.coocox.org)
Has LCD controller. Requires RAM: http://www.aliexpress.com/item/10PCS-IS62WV51216BLL-55TLI-IS62WV51216BLL-55-...
And plenty of NAND to store graphics http://www.aliexpress.com/item/FLASH-WINBOND-W25Q64FVSSIG-W25Q64FVSIG-SOP-8-...
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
<bleat tone="plaintive"> why do hardware designers think that all four edges of a PCB are fair game for off board connectors? </bleat> it makes mechanical design a lot more complicated than it should be.
he quickly steps off his soapbox.
On Fri, Aug 15, 2014 at 4:27 PM, Simon Kenyon simon@koala.ie wrote:
why do hardware designers think that all four edges of a PCB are fairgame for off board connectors?
</bleat> it makes mechanical design a lot more complicated than it should be.
http://rhombus-tech.net/community_ideas/micro_desktop/news/
weeelll i left a leeetle bit of space :)
why do hardware designers think that all four edges of a PCB arefair game for off board connectors?
it makes mechanical design a lot more complicated than it should be.
True and a good point - the best alternative is the fpc connector and they are both cheaper and denser.
Companies like Itead make flexible PCB prototypes - easy to custom build fpc ribbon as needed. http://imall.iteadstudio.com/open-pcb/pcb-prototyping.html
On Sun, Jul 27, 2014 at 1:04 PM, Miguel Garcia gacuest@gmail.com wrote:
We are designing a handheld-game console (based on EOMA-68).
great!
The problem is that EOMA-68 has very few GPIO.
ah - it now has quite a few: 17 at the last count, however yes they are all multiplexed.
We have 17 digital buttons, 2 analog joystick ( http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/175591... ) and 2 analog triggers ( http://www.digikey.com/product-detail/en/EVA-W7NR04B34/P13569-ND/1135944 ).
Luke will use on the tablet the next IC: PCA9536.
yep. it is a low-cost I2C 8-bit GPIO
However, this component does not meet our requirements.
no ADC...
Does anyone know a IC that meets these requirements (at least 17 digital buttons and at least 4 ADCs)?
that's quite a lot!
but you should be able to do keyboard matrix scanning to cover 16 buttons, 4 input 4 output... unless you really really want all possible button combinations, hmmm...
are there any keys which may not be pressed together, so you can do matrix-scanning on those, at least?
i will see if there is an I2C ADC/GPIO IC around... also now SPI is available so you could use that.
l.
ok so the MCP3004 is an SPI-based 10-bit ADC 4 channel, $1.50 in 5k volume, 200k-samples/sec, that's possibly waay more than you need? it's popular on adafruit and other places
and if you use the next one up from the PCA9536 - the 16-bit one - i think you're covered?
http://uk.farnell.com/texas-instruments/ads7949srter/ic-adc-8bit-srl-2msps-1...
that one looks ok....
l.
2014-07-27 17:20 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
ok so the MCP3004 is an SPI-based 10-bit ADC 4 channel, $1.50 in 5k volume, 200k-samples/sec, that's possibly waay more than you need? it's popular on adafruit and other places
MCP3004 and MCP3008 (we need 6 ADCs) seem a good choice. There are also many examples of code for Raspberry (easier to program).
Peter Green is right. We need 6 ADCs.
2014-07-27 17:06 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
but you should be able to do keyboard matrix scanning to cover 16 buttons, 4 input 4 output... unless you really really want all possible button combinations, hmmm...
are there any keys which may not be pressed together, so you can do matrix-scanning on those, at least?
Matrix-scanning is not a good idea. We want all possible button combinations.
Thanks.
On Mon, Jul 28, 2014 at 9:13 AM, Miguel Garcia gacuest@gmail.com wrote:
Peter Green is right. We need 6 ADCs.
2014-07-27 17:06 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
but you should be able to do keyboard matrix scanning to cover 16 buttons, 4 input 4 output... unless you really really want all possible button combinations, hmmm...
are there any keys which may not be pressed together, so you can do matrix-scanning on those, at least?
Matrix-scanning is not a good idea. We want all possible button combinations.
thought so :)
ok so you have an IC for the GPIO, and one for the ADC. i'm happy to help you with the PCB: would you like to try sending me a DXF file with the outline of the PCB edge, maybe also where the buttons are supposed to go? we can see if i can import it?
l.
2014-07-28 20:41 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
thought so :)
ok so you have an IC for the GPIO, and one for the ADC. i'm happy to help you with the PCB: would you like to try sending me a DXF file with the outline of the PCB edge, maybe also where the buttons are supposed to go? we can see if i can import it?
We are now doing the block diagram to decide which components we will use.
After we will do the schematics and later the PCB layout (routing).
When we have some schematics and PCB files, we will post them here so that you can see and help.
Thank you very much for your help and interest.
On Tue, Jul 29, 2014 at 12:08 AM, Miguel Garcia gacuest@gmail.com wrote:
2014-07-28 20:41 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
thought so :)
ok so you have an IC for the GPIO, and one for the ADC. i'm happy to help you with the PCB: would you like to try sending me a DXF file with the outline of the PCB edge, maybe also where the buttons are supposed to go? we can see if i can import it?
We are now doing the block diagram to decide which components we will use.
After we will do the schematics and later the PCB layout (routing).
When we have some schematics and PCB files, we will post them here so that you can see and help.
awesome.
Hi everyone, Miguel brought me here :) Thanks for everyone's help and sorry if this message doesn't turn up in the proper thread or if the quotes are messed up since I'm not used to mailing lists.
On Mon, Jul 28, 2014 at 9:13 AM, Miguel Garcia <gacuest at gmail.com http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook> wrote:
Peter Green is right. We need 6 ADCs.
2014-07-27 17:06 GMT+02:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook>:
but you should be able to do keyboard matrix scanning to cover 16 buttons, 4 input 4 output... unless you really really want all possible button combinations, hmmm...
are there any keys which may not be pressed together, so you can do matrix-scanning on those, at least?
Matrix-scanning is not a good idea. We want all possible button combinations.
thought so
ok so you have an IC for the GPIO, and one for the ADC.
We could use two different IC's, but wouldn't using an appropriate microcontroller be a less complex solution? That would probably make the schematics and PCB easier to design, although having to develop the software for the uc is a big con. Plus those I2C expansion chips look pretty neat.
Some uc's in the ATtiny48 family have 6 ADCs and enough I/O pins. Also, while we're only considering what we need for user input, there may be other needs I don't know about (an extra ADC for battery monitoring? I have no idea). That would be a point in favor of using a uc.
On Tue, Jul 29, 2014 at 6:12 PM, Daniel Iglesias daniel.iglesias@gmail.com wrote:
Hi everyone, Miguel brought me here :) Thanks for everyone's help and sorry if this message doesn't turn up in the proper thread or if the quotes are messed up since I'm not used to mailing lists.
you're here now. if you look up any netiquette set of instructions on how to interact with people - top-posting and not cutting context being the two biggest no-no's - you'll do fine. an introduction like you just did, at the top of the message, is great, btw.
Matrix-scanning is not a good idea. We want all possible button combinations.
thought so
ok so you have an IC for the GPIO, and one for the ADC.
We could use two different IC's, but wouldn't using an appropriate microcontroller be a less complex solution?
software-wise, no. with a microcontroller you have to a) write the firmware b) have two compilers c) upload the firmware d) design into the hardware a means to upload the firmware.
Some uc's in the ATtiny48 family have 6 ADCs and enough I/O pins.
ok yeah something like the arduino PICs would be extremely good, the infrastructure is amazing and they have support in sdcc. i helped out on the OSMC project a loong while ago so i know that you *do not* need all the 168mbyte crud that comes with the arduino just to compile sub-8k applications! :)
l.
2014-07-29 21:05 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
We could use two different IC's, but wouldn't using an appropriate microcontroller be a less complex solution?
software-wise, no. with a microcontroller you have to a) write the firmware b) have two compilers c) upload the firmware d) design into the hardware a means to upload the firmware.
Some uc's in the ATtiny48 family have 6 ADCs and enough I/O pins.
ok yeah something like the arduino PICs would be extremely good, the infrastructure is amazing and they have support in sdcc. i helped out on the OSMC project a loong while ago so i know that you *do not* need all the 168mbyte crud that comes with the arduino just to compile sub-8k applications! :)
There are 2 options for the controls: - Use MCP23017 (for the 19 digital buttons) and MCP3004/8 (for the 6 ADCs, we must look if we can use the model finished in 4 or we have to use the model finished in 8). This option is easier to program, but I suppose that it's hard to design the PCB (it's 2 IC). - Use a microcontroller like ATtiny48 (for the 19 digital buttons and the 6 ADCs). This option is more difficult to program, but easier to design the PCB (it is one IC).
What is your recommendation?
Thanks.
On Mon, Aug 4, 2014 at 11:22 AM, Miguel Garcia gacuest@gmail.com wrote:
There are 2 options for the controls:
- Use MCP23017 (for the 19 digital buttons) and MCP3004/8 (for the 6
ADCs, we must look if we can use the model finished in 4 or we have to use the model finished in 8). This option is easier to program, but I suppose that it's hard to design the PCB (it's 2 IC).
it'll be pretty straightforward. also you have the advantage that you can separate the analog ADC IC from the digital one, separate the ADC IC with some ground protection and you'll get less noise.
- Use a microcontroller like ATtiny48 (for the 19 digital buttons and
the 6 ADCs). This option is more difficult to program, but easier to design the PCB (it is one IC).
What is your recommendation?
honestly i'd go for the less difficult to program option, straight away. you're not on a huge cost-saving exercise so it's fine.
l.
I suspect that we are not looking at the complete picture here. Don't you have some more sensors to add on the I2C? Like accelerometer, magnetometer, maybe light sensor (for auto brigthness) and so on? Maybe battery monitoring? I see that you are discussing about using I/O expanders and ADC chips. Not to say that IN YOUR CASE you have to use microcontroller - just to show some points that could help you to take the right decision. . Using I/O expander means that you need several chips - at least two. This will take some board space and pin connections. Don't forget that beside I2C lines (SDA, SCL) you might need some (maybe one, maybe two) interrupt lines. Some clock lines in addition? Also, those simple chips will force you in scanning very often (1ms, 10ms?) about actual data. Using microcontroller is not easy, that's right. But don't forget that it adds a lot of flexibility. Most modern microcontrollers now have built-in (ROM) bootloader with support for UART, SPI, I2C and so on. I would propose STM32 for example (it is quite well supported by open source tools and code base). You get low power, low latency processing core - think of filtering, post processing, event detection. Yes, you need to manage firmware update - but this is just because IT IS POSSIBLE to do on the field update (vs fixed function I/O expanders). Some manufacturers (e.g. microchip), and distributors allow ordering chips with pre-programmed user firmware - so no need for programming equipment or JTAG port on the board. I could imagine that in your case you might even use the microcontroller without precise crystal/ceramic resonator - just with built in RC oscillator (1-2% precision but this does not matter on I2C). The code itself will not be much of an issue - I suspect that this will be open sourced too so you can get a lot of help on this. So called "sensor fusion" is quite close to your application.
I haven't used yet any of LPC line of Cortex-M microcontrollers from NXP, but I like one of the features - every signal from internal peripheral could be mapped to any microcontroller pin. This means several things: - you can use all functionalities (internal blocks) without conflicts because of pre-defined "alternative function" mapping - usually this means that you get the smallest possible package to solve your task - you get the flexibility to change pin mapping later - when the board is ready (but 2 pins were swapped ...) - you can change pin mapping in runtime - think of using some pins as UART at power on, then switching to I2C
If you have a space USB port on the EOMA, you could put the STM/LPC on the USB. Than use the ready made USB HID examples and feed in your data. Than, use the whole input infrastructure of linux/android and get your events - without coding on the Linux side? (don't know if this is true, just speculating).
2014-08-04 14:14 GMT+03:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Mon, Aug 4, 2014 at 11:22 AM, Miguel Garcia gacuest@gmail.com wrote:
There are 2 options for the controls:
- Use MCP23017 (for the 19 digital buttons) and MCP3004/8 (for the 6
ADCs, we must look if we can use the model finished in 4 or we have to use the model finished in 8). This option is easier to program, but I suppose that it's hard to design the PCB (it's 2 IC).
it'll be pretty straightforward. also you have the advantage that you can separate the analog ADC IC from the digital one, separate the ADC IC with some ground protection and you'll get less noise.
- Use a microcontroller like ATtiny48 (for the 19 digital buttons and
the 6 ADCs). This option is more difficult to program, but easier to design the PCB (it is one IC).
What is your recommendation?
honestly i'd go for the less difficult to program option, straight away. you're not on a huge cost-saving exercise so it's fine.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Wed, Aug 6, 2014 at 9:57 AM, krasi gichev krasimirr@gmail.com wrote:
I suspect that we are not looking at the complete picture here. Don't you have some more sensors to add on the I2C? Like accelerometer, magnetometer, maybe light sensor (for auto brigthness) and so on? Maybe battery monitoring? I see that you are discussing about using I/O expanders and ADC chips. Not to say that IN YOUR CASE you have to use microcontroller - just to show some points that could help you to take the right decision. . Using I/O expander means that you need several chips - at least two. This will take some board space and pin connections. Don't forget that beside I2C lines (SDA, SCL) you might need some (maybe one, maybe two) interrupt lines.
i've added 2 EINTs to the specification for exactly this purpose.
(ROM) bootloader with support for UART, SPI, I2C and so on. I would propose STM32 for example (it is quite well supported by open source tools and code base).
this is the original that i used in one of the early prototype tablet pcbs, it's very good, however the low-cost ones (STM32F103) don't do USB, you have to go to the $5 variants to get USB.
i think, manuel, if you draw out (even sketch) the full connectivity required then we can help evaluate.
l.
2014-08-06 10:23 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
if you draw out (even sketch) the full connectivity required then we can help evaluate.
A basic block diagram. If there is any error or someone knows a better component or a better way to do the connections, I appreciate that that person says it.
---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- Block Diagram EOMA-68 Handheld Games Console v.0.9 ---------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------
----------------- Slot PCMCIA: -----------------
The part number of Slot PCMCIA is: Amphenol G659EU1X2472X
The datasheet is: https://dl.dropboxusercontent.com/u/19251472/11/G659EU1X2472X.PDF
Table of EOMA-68 pinouts: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Table_of_EOMA-6...
------------ Display: ------------
The part number of display is: BTL507212-W677L
The datasheet is: https://dl.dropboxusercontent.com/u/19251472/11/5.0%27%27%20LCD%20HD%20-%20G...
The connector of this display is MIPI, while the connector of EOMA-68 for the display is RGB, so we use a MIPI-to-RGB.
The part number of MIPI-to-RGB is: SSD2828
The datasheet is: https://dl.dropboxusercontent.com/u/19251472/11/SSD2828QN4_1.0.pdf
The display is connected to MIPI-to-RGB, and MIPI-to-RGB is connected to EOMA-68 (RGB pinout – 2 to 4, 6 to 8, 10 to 14, 36 to 38, 40 to 42, 44 to 48).
---------------- Touch Panel: ----------------
There is no definitive part number, because we have to design it specifically for our display (due to inches and resolution).
We have chosen a similar part number that will be used, but this part number is not the part number that we use (we selected this because the connector is the same).
The datasheet is: https://dl.dropboxusercontent.com/u/19251472/D50-L4030A-K0D.pdf
The connector of the Touch Panel is I2C.
The Touch Panel is connected to I2C of the EOMA-68.
----------- Battery: -----------
The part number of battery is: LP8067100-CI
The datasheet is: https://dl.dropboxusercontent.com/u/19251472/11/LP8067100-CI.pdf
The connector of the battery to PCB is: PH-LT-WT-NA
The datasheet of the connector of the battery to PCB is: http://hands.com/~lkcl/eoma/kde_tablet/PH-LT-WT-NA%E6%89%BF%E8%AE%A4%E4%B9%A...
The connector of the battery to PCB is connected to PMIC.
The part number of PMIC is: AXP209
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/AXP209-SpecSheet-Translated.pdf and http://hands.com/~lkcl/eoma/kde_tablet/AXP209%20Datasheet%20v1.0_cn.pdf
The PMIC is connected to PWR1, PWR2, PWR3, PWR4, I2C_SCL and I2C_SDA of EOMA-68.
------------ EEPROM: ------------
The part number of EEPROM is: AT24C64
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/AT24C64.eeprom.pdf
The EEPROM is connected to I2C of the EOMA-68.
------------------ Accelerometer: ------------------
The part number of Accelerometer is: MXC6225XU
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/MXC6225XU.pdf
The Accelerometer is connected to I2C of the EOMA-68 and one of the GPIO of the EOMA-68.
------------------ USB Host 3.0: ------------------
The part number of USB Host 3.0 (provisional) is: 10117835-002LF
The datasheet is: http://portal.fciconnect.com/Comergent//fci/drawing/10117835.pdf
The USB Host 3.0nis connected to 1st USB + USB 3.0 of the EOMA-68.
-------------------------------- MicroUSB for Charging: --------------------------------
This microUSB is only responsible for charging the battery (no USB Host).
The part number of microUSB (provisional) is: 47590-0001
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/micro_usb_ab_475900001_sd.pdf
The MicroUSB is connected to AXP209.
---------------------- LED of Charging: ----------------------
This LED is used to illuminate when the battery is charging.
We have not yet selected a part number (a generic LED).
The LED is connected to AXP209.
------------ MicroSD: ------------
The part number of microSD is: MM027S020R
The datasheet is: http://hands.com/~lkcl/eoma/allwinner/litkconn_MICRO%20SD%20PUSH-PUSH%20A.pd...
The MicroSD is connected to GPIO of EOMA-68.
------------- WIFI USB: -------------
The part number of WIFI (USB) is: CCandC WM-294 1T1R
The datasheet is: https://dl.dropboxusercontent.com/u/19251472/11/WM-294_module-V2.2%28PCB%20v...
The WIFI USB is connected to USB HUB.
The part number of USB HUB is: FE1.1s
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0)....
The USB HUB is connected to 2nd USB of EOMA-68.
---------------- Bluetooth USB: ----------------
The Bluetooth USB part number has not yet been chosen, even so, is a generic BT, so the connection/power would be similar to the WIFI.
The BT USB is connected to USB HUB.
The part number of USB HUB is: FE1.1s
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0)....
The USB HUB is connected to 2nd USB of EOMA-68.
--------------------------------- FlashDrive USB (optional): ---------------------------------
Not sure to include the flashdrive, but is an option because is not a big change in the design (the same USB HUB is used). You can remove the USB Flash Drive and use this for controls.
The FlashDrive USB part number has not yet been chosen, even so, is a generic FlahsDrive, so the connection/power would be similar to the WIFI.
The FlashDrive USB is connected to USB HUB.
The part number of USB HUB is: FE1.1s
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0)....
The USB HUB is connected to 2nd USB of EOMA-68.
-------------- Microphone: --------------
We have not yet selected a part number (a generic Microphone).
The Microphone is connected to USB Audio Controller.
The part number of USB Audio Controller is: CM108AH
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/CM108_DataSheet_v1.6.pdf
The USB Audio Controller is connected to USB HUB.
The part number of USB HUB is: FE1.1s
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0)....
The USB HUB is connected to 2nd USB of EOMA-68.
----------------- Audio Jack: -----------------
The part number of Audio Jack is: PJ-3545-5L1G
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/PJ-3543-L6G%20Model%20(1).pdf
The Audio Jack is connected to USB Audio Controller.
The part number of USB Audio Controller is: CM108AH
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/CM108_DataSheet_v1.6.pdf
The USB Audio Controller is connected to USB HUB.
The part number of USB HUB is: FE1.1s
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0)....
The USB HUB is connected to 2nd USB of EOMA-68.
---------------- Speaker (x2): ----------------
We have not yet selected a part number (a generic Speaker (x2)).
The Speaker (x2) is connected to Audio Amplifier.
The part number of Audio Amplifier is: UTC2822D
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/YW-UTC2822D_C.pdf and http://pdf.datasheetcatalog.com/datasheets/90/492970_DS.pdf
The Audio Amplifier is connected to the audio output that goes from the USB Audio Controller to Audio jack.
The part number of USB Audio Controller is: CM108AH
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/CM108_DataSheet_v1.6.pdf
The USB Audio Controller is connected to USB HUB.
The part number of USB HUB is: FE1.1s
The datasheet is: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0)....
The USB HUB is connected to 2nd USB of EOMA-68.
--------------- Power Button: ---------------
The Power Button is a generic button with click
The Power Button is connected to 43 POWER# of EOMA-68.
------------------------ Digital Buttons (x17): ------------------------
4 buttons (2 digital triggers and Vol + and Vol-) would be generic buttons with click (although maybe we put rubbers to makes softer press them, should be viewed) and the other buttons are the typical buttons ABXY on the PCB with rubbers (similar to xbox 360 controller or snes controller).
The Digital Buttons are connected to ?????????
----------------- Joystick (x2): -----------------
The part number of Joystick es: CTS 254TA103B50B-ND
The datasheet is: http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/175591...
Each joystick has 2 ADCs and 1 digital button. We need 2 joystick, so we use 4 ADCs and 2 digital buttons.
The Joystick is connected to ?????????
--------------------------- Digital Trigger (x2): ---------------------------
The analog trigger is a piece of plastic connected to a potentiometer, which when pressed moves the potentiometer, and to return to its original position there is a spring (see analog trigger of GameCube or Wii Classic Controller as an example).
The part number of potenciómetro is: Panasonic EVA-W7NR04B34
The datasheet is: http://www.digikey.com/product-detail/en/EVA-W7NR04B34/P13569-ND/1135944
Each potentiometer has 1 ADCs. We need 2 potentiometers, so we use 2 ADCs.
The Potentiometer is connected to ?????????
---------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------
A basic sketch of the block diagram: http://oi57.tinypic.com/16aeffb.jpg
---------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------
Do you want some more detail?
Thanks for your help!
On Wed, Aug 6, 2014 at 1:19 PM, Miguel Garcia gacuest@gmail.com wrote:
A basic sketch of the block diagram: http://oi57.tinypic.com/16aeffb.jpg
ok great.
so, things that are missing from the diagram:
* digital GPIO IC connects its IRQ-OUT to EINT0-IN on EOMA68 * one GPIO IC IN pin is needed for MicroSD "detect" * EOMA68 PWM out goes to LCD PWM * digital GPIO IC OUT pin needed for power-up of LCD * accelerometer IRQ goes to digital GPIO IC IN * digital GPIO IC IN pin connects to IRQ-OUT of AXP209 * digital GPIO IC IN pin connects to Headphone-detect (in case you want to alter volume on headphone-out)
so you probably want at least 2 16-pin Digital GPIO ICs because that's quite a lot of GPIO. you have two EINTs so you can at least chain all the EINT IRQs together.
if you start using USB (with an STM32F) then you will need 2 USB hubs (or drop the USB Flash Drive idea)
if you use UART (with an STM32F) i would be concerned about the speed / latency of the control protocol communicating data.
honestly i think you are better off with discrete GPIO and ADC ICs (SPI for preference, I2C otherwise).
l.
06/08/14 14:18, Luke Kenneth Casson Leighton wrote:
On Wed, Aug 6, 2014 at 1:19 PM, Miguel Garcia gacuest@gmail.com wrote:
A basic sketch of the block diagram: http://oi57.tinypic.com/16aeffb.jpg
ok great.
so, things that are missing from the diagram:
- digital GPIO IC connects its IRQ-OUT to EINT0-IN on EOMA68
What's the purpose of this IRQ line? After looking at the GPIO IC datasheet I'm assuming it's there so the IC is polled only when the inputs change, is this correct? (i.e., avoiding busy-waiting)
- one GPIO IC IN pin is needed for MicroSD "detect"
- EOMA68 PWM out goes to LCD PWM
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
so you probably want at least 2 16-pin Digital GPIO ICs because that's quite a lot of GPIO. you have two EINTs so you can at least chain all the EINT IRQs together.
if you start using USB (with an STM32F) then you will need 2 USB hubs (or drop the USB Flash Drive idea)
if you use UART (with an STM32F) i would be concerned about the speed / latency of the control protocol communicating data.
Low latency is crucial, otherwise we'd just buy a random Android console from JXD instead of building our own one, so thanks for bringing that up :) A polling rate higher than 100 Hz would be nice. Assuming 6 8-bit ADC's, 19 digital buttons and a 200 Hz polling rate that'd give 13400 bps plus overhead, which isn't too high. How much latency do you expect there would be, depending on whether we use UART or SPI? What about software/OS-side latency, how predictable is that? I'd say much more than 16 ms wouldn't be acceptable.
honestly i think you are better off with discrete GPIO and ADC ICs (SPI for preference, I2C otherwise).
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Wed, Aug 6, 2014 at 6:10 PM, Daniel Iglesias daniel.iglesias@gmail.com wrote:
06/08/14 14:18, Luke Kenneth Casson Leighton wrote:
On Wed, Aug 6, 2014 at 1:19 PM, Miguel Garcia gacuest@gmail.com wrote:
A basic sketch of the block diagram: http://oi57.tinypic.com/16aeffb.jpg
ok great.
so, things that are missing from the diagram:
- digital GPIO IC connects its IRQ-OUT to EINT0-IN on EOMA68
What's the purpose of this IRQ line? After looking at the GPIO IC datasheet I'm assuming it's there so the IC is polled only when the inputs change, is this correct? (i.e., avoiding busy-waiting)
http://www.nxp.com/products/interface_and_connectivity/i2c/i2c_general_purpo...
you _want_ one that has an IRQ. don't use one that doesn't.
- one GPIO IC IN pin is needed for MicroSD "detect"
- EOMA68 PWM out goes to LCD PWM
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
so you probably want at least 2 16-pin Digital GPIO ICs because that's quite a lot of GPIO. you have two EINTs so you can at least chain all the EINT IRQs together.
if you start using USB (with an STM32F) then you will need 2 USB hubs (or drop the USB Flash Drive idea)
if you use UART (with an STM32F) i would be concerned about the speed / latency of the control protocol communicating data.
Low latency is crucial, otherwise we'd just buy a random Android console from JXD instead of building our own one, so thanks for bringing that up :) A polling rate higher than 100 Hz would be nice. Assuming 6 8-bit ADC's, 19 digital buttons and a 200 Hz polling rate that'd give 13400 bps plus overhead, which isn't too high. How much latency do you expect there would be, depending on whether we use UART or SPI?
SPI goes up to 25mhz (i believe), UART you will be very lucky to get 4mhz if you are extremely careful, you can realistically expect 115200 (1mhz).
On Thu, Aug 7, 2014 at 7:55 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Wed, Aug 6, 2014 at 6:10 PM, Daniel Iglesias daniel.iglesias@gmail.com wrote:
06/08/14 14:18, Luke Kenneth Casson Leighton wrote:
On Wed, Aug 6, 2014 at 1:19 PM, Miguel Garcia gacuest@gmail.com wrote:
A basic sketch of the block diagram: http://oi57.tinypic.com/16aeffb.jpg
ok great.
so, things that are missing from the diagram:
- digital GPIO IC connects its IRQ-OUT to EINT0-IN on EOMA68
What's the purpose of this IRQ line? After looking at the GPIO IC datasheet I'm assuming it's there so the IC is polled only when the inputs change, is this correct? (i.e., avoiding busy-waiting)
http://www.nxp.com/products/interface_and_connectivity/i2c/i2c_general_purpo...
you _want_ one that has an IRQ. don't use one that doesn't.
...except do try to find one that's a bit less than $0.95 in volume!! http://www.futureelectronics.com/en/technologies/semiconductors/comm-product...
2014-08-07 8:57 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
...except do try to find one that's a bit less than $0.95 in volume!! http://www.futureelectronics.com/en/technologies/semiconductors/comm-product...
If SPI is better, MCP23S17 is an interesting alternative.
$1.00 en volume: http://www.digikey.com/product-detail/es/MCP23S17-E%2FSS/MCP23S17-E%2FSS-ND/...
Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf
-------------
Regarding the analog-to-digital IC, we have this IC: MCP3008
It is SPI, but I do not see that this has INT. Should we look for other IC with INT?
Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/21295d.pdf
Thanks.
On Thu, Aug 7, 2014 at 8:51 AM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-07 8:57 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
...except do try to find one that's a bit less than $0.95 in volume!! http://www.futureelectronics.com/en/technologies/semiconductors/comm-product...
If SPI is better, MCP23S17 is an interesting alternative.
faster for sure. I2C tops out safely at 4mhz. SPI i believe can do 25mhz.
$1.00 en volume:
blegh - and you need 2 of them _and_ 2 analog ICs as well. that's starting to make the STM32F103 (64-pin variant) look attractive. and i know you can get that at around the $2.50 mark in 10k volumes.
*sigh* ok do you really need that USB Flash thing? because of a) the cost (at least $4.50) b) the number of ICs (4) it's starting to tip in favour of the STM32F again, i get the feeling you'd be better off wiring up the STM32F as a USB 1.1 device. you'll also need to wire up the UART to the EOMA68 interface and a couple of other pins to put it into "firmware upload" mode, but that's ok.
the advantage there is that i have some GPL'd KiCAD designs with STM32F already in them (or have found some out there when i last checked).
l.
2014-08-07 10:13 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
blegh - and you need 2 of them _and_ 2 analog ICs as well. that's starting to make the STM32F103 (64-pin variant) look attractive. and i know you can get that at around the $2.50 mark in 10k volumes.
*sigh* ok do you really need that USB Flash thing? because of a) the cost (at least $4.50) b) the number of ICs (4) it's starting to tip in favour of the STM32F again, i get the feeling you'd be better off wiring up the STM32F as a USB 1.1 device. you'll also need to wire up the UART to the EOMA68 interface and a couple of other pins to put it into "firmware upload" mode, but that's ok.
the advantage there is that i have some GPL'd KiCAD designs with STM32F already in them (or have found some out there when i last checked).
Yes, the USB flash drive can be removed.
I think Daniel also prefers a microcontroller.
2014-08-06 14:18 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
- one GPIO IC IN pin is needed for MicroSD "detect"
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
So, do we connect all this to STM32F? Or do we have to add the STM32F and the digital GPIO IC?
Thanks.
On Thu, Aug 7, 2014 at 10:07 AM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-07 10:13 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
blegh - and you need 2 of them _and_ 2 analog ICs as well. that's starting to make the STM32F103 (64-pin variant) look attractive. and i know you can get that at around the $2.50 mark in 10k volumes.
*sigh* ok do you really need that USB Flash thing? because of a) the cost (at least $4.50) b) the number of ICs (4) it's starting to tip in favour of the STM32F again, i get the feeling you'd be better off wiring up the STM32F as a USB 1.1 device. you'll also need to wire up the UART to the EOMA68 interface and a couple of other pins to put it into "firmware upload" mode, but that's ok.
the advantage there is that i have some GPL'd KiCAD designs with STM32F already in them (or have found some out there when i last checked).
Yes, the USB flash drive can be removed.
I think Daniel also prefers a microcontroller.
i'll check and see what i have on the KiCAD front, tonight.
2014-08-06 14:18 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
- one GPIO IC IN pin is needed for MicroSD "detect"
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
So, do we connect all this to STM32F?
yes. and the analog ADC stuff as well. an STM32F can cope admirably. i have some test code kicking about so can help out there.
Or do we have to add the STM32F
yes.
and the digital GPIO IC?
no.
the nice thing about using the USB interface is that a it's pretty quick (ok 11mbits/sec) but also IRQs etc. are all handled over USB.
the down-side is you'll need to write both the firmware on the STM32F as well as a matching library, but hey that should be fine: i'd suggest doing something like a USB-HID device and a USB-Mouse device, there is plenty of example code for both. anything else you can do as say a USB-ACM (modem) to read unusual stuff.
l.
Firmware update of newer STM32s could be done over USB too - you don't need separate UART for this. Just wire BOOT pin (pins) to GPIO(s) from EOMA to allow entering firmware update mode (DFU over USB). 64pin seems an overkill - there a lot of other package options, e.g. 48pin QFN, not to mention the BGA variants. Also, F103 is quite old one, probably the price might be good, but I would recommend some of newer ones (Cortex-M0 even) - look at F0, F2, F3 series. A good option could be this: STM32F071CB, the price goes below $2.50 for 100pcs, and it seems to have all you need - http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN7/PF259662
SiLabs "Precision 32" are also nice ones - very well balanced peripherals and packages (e.g. QFN40, SiM3U154), built in regulator from 5V (if needed). But the price is higher.
2014-08-07 12:07 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-07 10:13 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
blegh - and you need 2 of them _and_ 2 analog ICs as well. that's starting to make the STM32F103 (64-pin variant) look attractive. and i know you can get that at around the $2.50 mark in 10k volumes.
*sigh* ok do you really need that USB Flash thing? because of a) the cost (at least $4.50) b) the number of ICs (4) it's starting to tip in favour of the STM32F again, i get the feeling you'd be better off wiring up the STM32F as a USB 1.1 device. you'll also need to wire up the UART to the EOMA68 interface and a couple of other pins to put it into "firmware upload" mode, but that's ok.
the advantage there is that i have some GPL'd KiCAD designs with STM32F already in them (or have found some out there when i last checked).
Yes, the USB flash drive can be removed.
I think Daniel also prefers a microcontroller.
2014-08-06 14:18 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
- one GPIO IC IN pin is needed for MicroSD "detect"
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
So, do we connect all this to STM32F? Or do we have to add the STM32F and the digital GPIO IC?
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Thu, Aug 7, 2014 at 3:00 PM, krasi gichev krasimirr@gmail.com wrote:
Firmware update of newer STM32s could be done over USB too - you don't need separate UART for this. Just wire BOOT pin (pins) to GPIO(s) from EOMA to allow entering firmware update mode (DFU over USB). 64pin seems an overkill
... until you realise that there are around 32 GPIOs needed and around 10 ADCs, then you have I2C, SPI, UART and others, it ends up at quite a lot of pins.
- there a lot of other package options, e.g. 48pin
QFN, not to mention the BGA variants. Also, F103 is quite old one, probably the price might be good, but I would recommend some of newer ones (Cortex-M0 even) - look at F0, F2, F3 series. A good option could be this: STM32F071CB, the price goes below $2.50 for 100pcs, and it seems to have all you need - http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN7/PF259662
oo. it doesn't have USB, but it does have SPI, so apart from being a slight pain (having to write a custom linux kernel driver) it would be okay.
SiLabs "Precision 32" are also nice ones - very well balanced peripherals and packages (e.g. QFN40, SiM3U154), built in regulator from 5V (if needed). But the price is higher.
2014-08-07 12:07 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-07 10:13 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
blegh - and you need 2 of them _and_ 2 analog ICs as well. that's starting to make the STM32F103 (64-pin variant) look attractive. and i know you can get that at around the $2.50 mark in 10k volumes.
*sigh* ok do you really need that USB Flash thing? because of a) the cost (at least $4.50) b) the number of ICs (4) it's starting to tip in favour of the STM32F again, i get the feeling you'd be better off wiring up the STM32F as a USB 1.1 device. you'll also need to wire up the UART to the EOMA68 interface and a couple of other pins to put it into "firmware upload" mode, but that's ok.
the advantage there is that i have some GPL'd KiCAD designs with STM32F already in them (or have found some out there when i last checked).
Yes, the USB flash drive can be removed.
I think Daniel also prefers a microcontroller.
2014-08-06 14:18 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
- one GPIO IC IN pin is needed for MicroSD "detect"
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
So, do we connect all this to STM32F? Or do we have to add the STM32F and the digital GPIO IC?
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Yep, 071 is good if host connection is either I2C or SPI. There are 2 I2C controllers so it can run as gateway. But for USB there is STM32F072CBT6 - at Digikey it is priced at 2.37USD for 1000pcs - http://www.digikey.com/product-detail/en/STM32F072CBT6/497-14645-ND/4815292. This one is in 48 pin. If more pins are needed, just switch to: STM32F072RBT6 - http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259605
2014-08-07 17:11 GMT+03:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Thu, Aug 7, 2014 at 3:00 PM, krasi gichev krasimirr@gmail.com wrote:
Firmware update of newer STM32s could be done over USB too - you don't
need
separate UART for this. Just wire BOOT pin (pins) to GPIO(s) from EOMA to allow entering firmware update mode (DFU over USB). 64pin seems an overkill
... until you realise that there are around 32 GPIOs needed and around 10 ADCs, then you have I2C, SPI, UART and others, it ends up at quite a lot of pins.
- there a lot of other package options, e.g. 48pin
QFN, not to mention the BGA variants. Also, F103 is quite old one,
probably
the price might be good, but I would recommend some of newer ones
(Cortex-M0
even) - look at F0, F2, F3 series. A good option could be this:
STM32F071CB,
the price goes below $2.50 for 100pcs, and it seems to have all you need
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN7/PF259662
oo. it doesn't have USB, but it does have SPI, so apart from being a slight pain (having to write a custom linux kernel driver) it would be okay.
SiLabs "Precision 32" are also nice ones - very well balanced peripherals and packages (e.g. QFN40, SiM3U154), built in regulator from 5V (if
needed).
But the price is higher.
2014-08-07 12:07 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-07 10:13 GMT+02:00 Luke Kenneth Casson Leighton <lkcl@lkcl.net
:
blegh - and you need 2 of them _and_ 2 analog ICs as well. that's starting to make the STM32F103 (64-pin variant) look attractive. and i know you can get that at around the $2.50 mark in 10k volumes.
*sigh* ok do you really need that USB Flash thing? because of a) the cost (at least $4.50) b) the number of ICs (4) it's starting to tip in favour of the STM32F again, i get the feeling you'd be better off wiring up the STM32F as a USB 1.1 device. you'll also need to wire up the UART to the EOMA68 interface and a couple of other pins to put it into "firmware upload" mode, but that's ok.
the advantage there is that i have some GPL'd KiCAD designs with STM32F already in them (or have found some out there when i last checked).
Yes, the USB flash drive can be removed.
I think Daniel also prefers a microcontroller.
2014-08-06 14:18 GMT+02:00 Luke Kenneth Casson Leighton <lkcl@lkcl.net
:
- one GPIO IC IN pin is needed for MicroSD "detect"
- digital GPIO IC OUT pin needed for power-up of LCD
- accelerometer IRQ goes to digital GPIO IC IN
- digital GPIO IC IN pin connects to IRQ-OUT of AXP209
- digital GPIO IC IN pin connects to Headphone-detect (in case you
want to alter volume on headphone-out)
So, do we connect all this to STM32F? Or do we have to add the STM32F and the digital GPIO IC?
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
2014-08-07 16:23 GMT+02:00 krasi gichev krasimirr@gmail.com:
Yep, 071 is good if host connection is either I2C or SPI. There are 2 I2C controllers so it can run as gateway. But for USB there is STM32F072CBT6 - at Digikey it is priced at 2.37USD for 1000pcs - http://www.digikey.com/product-detail/en/STM32F072CBT6/497-14645-ND/4815292. This one is in 48 pin. If more pins are needed, just switch to: STM32F072RBT6 - http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259605
And this: http://www.digikey.com/product-search/en?KeyWords=STM32F072VBT6 ??
Thanks.
Wow, this is 100 pins ... sure it has everything you need (and a lot of things that you don't need). But is 14mm square, I hope you have enough board space. Check this link for reference - you can use design files of this eval board for quick start: http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF259717
There is a claim in the datasheet: "Internal 48 MHz oscillator with automatic trimming based on ext. synchronization" - not sure but I suspect that this would be a good option if used on USB - no need for clock crystal for the STM32.
2014-08-07 17:29 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-07 16:23 GMT+02:00 krasi gichev krasimirr@gmail.com:
Yep, 071 is good if host connection is either I2C or SPI. There are 2 I2C controllers so it can run as gateway. But for USB there is STM32F072CBT6 - at Digikey it is priced at 2.37USD
for
1000pcs -
http://www.digikey.com/product-detail/en/STM32F072CBT6/497-14645-ND/4815292 .
This one is in 48 pin. If more pins are needed, just switch to: STM32F072RBT6 - http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259605
And this: http://www.digikey.com/product-search/en?KeyWords=STM32F072VBT6 ??
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Update - it is written at line 1 at page 1 of the datasheet "ARM-based 32-bit MCU, up to 128 KB Flash, *crystal-less* USB FS 2.0, CAN, 12 timers, ADC, DAC & comm. interfaces, 2.0 - 3.6 V" - so it should do clock recovery from USB data stream.
Another note (if you go this way) - this chip has two I2C controllers - so you could "spread" the sensors on both of them to get better throughput. Just take care to estimate the data rate of each one of them so make a good balance.
2014-08-07 17:42 GMT+03:00 krasi gichev krasimirr@gmail.com:
Wow, this is 100 pins ... sure it has everything you need (and a lot of things that you don't need). But is 14mm square, I hope you have enough board space. Check this link for reference - you can use design files of this eval board for quick start: http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF259717
There is a claim in the datasheet: "Internal 48 MHz oscillator with automatic trimming based on ext. synchronization" - not sure but I suspect that this would be a good option if used on USB - no need for clock crystal for the STM32.
2014-08-07 17:29 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-07 16:23 GMT+02:00 krasi gichev krasimirr@gmail.com:
Yep, 071 is good if host connection is either I2C or SPI. There are 2
I2C
controllers so it can run as gateway. But for USB there is STM32F072CBT6 - at Digikey it is priced at 2.37USD
for
1000pcs -
http://www.digikey.com/product-detail/en/STM32F072CBT6/497-14645-ND/4815292 .
This one is in 48 pin. If more pins are needed, just switch to: STM32F072RBT6 - http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259605
And this: http://www.digikey.com/product-search/en?KeyWords=STM32F072VBT6 ??
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Thu, Aug 7, 2014 at 3:49 PM, krasi gichev krasimirr@gmail.com wrote:
Update - it is written at line 1 at page 1 of the datasheet "ARM-based 32-bit MCU, up to 128 KB Flash, crystal-less USB FS 2.0, CAN, 12 timers, ADC, DAC & comm. interfaces, 2.0 - 3.6 V" - so it should do clock recovery from USB data stream.
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259604#
woo! $2 in 10k volumes, and there's a 7x7mm UFBGA variant.
2014-08-07 18:04 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
woo! $2 in 10k volumes, and there's a 7x7mm UFBGA variant.
So I suppose we should use STM32F072VBH6, is that correct? I hope that this microcontroller does not complicate much the design or programming.
Thanks.
On Thu, Aug 7, 2014 at 6:21 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-07 18:04 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
woo! $2 in 10k volumes, and there's a 7x7mm UFBGA variant.
So I suppose we should use STM32F072VBH6, is that correct?
looks like it. more modern than the STM32F103 (which only has USB 1.1) and lower-cost too.
I hope that this microcontroller does not complicate much the design or programming.
naah.
2014-08-07 19:57 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Thu, Aug 7, 2014 at 6:21 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-07 18:04 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
woo! $2 in 10k volumes, and there's a 7x7mm UFBGA variant.
So I suppose we should use STM32F072VBH6, is that correct?
looks like it. more modern than the STM32F103 (which only has USB 1.1) and lower-cost too.
Is there a smaller one in the same family we could use? Such as the STM32F072'C' or 'R', which have 37 and 51 GPIOs respectively and nearly the same number of ADCs as the bigger 'V' variant. I suppose it'd make PCB design/routing easier, since the number of pins and the dimensions of the IC roughly double between the 'C' and the non-BGA 'V' variants. I don't know if there are any disadvantages to using the smaller ones though.
On Fri, Aug 8, 2014 at 10:33 AM, Daniel Iglesias daniel.iglesias@gmail.com wrote:
2014-08-07 19:57 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Thu, Aug 7, 2014 at 6:21 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-07 18:04 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
woo! $2 in 10k volumes, and there's a 7x7mm UFBGA variant.
So I suppose we should use STM32F072VBH6, is that correct?
looks like it. more modern than the STM32F103 (which only has USB 1.1) and lower-cost too.
Is there a smaller one in the same family we could use? Such as the STM32F072'C' or 'R', which have 37 and 51 GPIOs respectively
probably: you'll just have to read the datasheets very carefully, paying attention to the available number of pins (some of which are multiplexed), and connect everything up, and see if it's enough.
so, i'd suggest just getting on with it and see what happens.
l.
2014-08-08 10:33 GMT+02:00 Daniel Iglesias daniel.iglesias@gmail.com:
Is there a smaller one in the same family we could use? Such as the STM32F072'C' or 'R', which have 37 and 51 GPIOs respectively and nearly the same number of ADCs as the bigger 'V' variant. I suppose it'd make PCB design/routing easier, since the number of pins and the dimensions of the IC roughly double between the 'C' and the non-BGA 'V' variants. I don't know if there are any disadvantages to using the smaller ones though.
And they are cheaper.
STM32F072CB: http://www.stmicroelectronics.com.cn/web/catalog/mmc/FM141/SC1169/SS1574/LN1...
STM32F072RB: http://www.stmicroelectronics.com.cn/web/catalog/mmc/FM141/SC1169/SS1574/LN1...
A stupid question. STM32F072 has USB 2.0 connectivity. Does connectivity can also be USB 1.1? I say this because the second USB of EOMA may be USB 1.1 and will not always be USB 2.0.
Thanks.
On Fri, Aug 8, 2014 at 1:04 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-08 10:33 GMT+02:00 Daniel Iglesias daniel.iglesias@gmail.com:
Is there a smaller one in the same family we could use? Such as the STM32F072'C' or 'R', which have 37 and 51 GPIOs respectively and nearly the same number of ADCs as the bigger 'V' variant. I suppose it'd make PCB design/routing easier, since the number of pins and the dimensions of the IC roughly double between the 'C' and the non-BGA 'V' variants. I don't know if there are any disadvantages to using the smaller ones though.
And they are cheaper.
STM32F072CB: http://www.stmicroelectronics.com.cn/web/catalog/mmc/FM141/SC1169/SS1574/LN1...
STM32F072RB: http://www.stmicroelectronics.com.cn/web/catalog/mmc/FM141/SC1169/SS1574/LN1...
A stupid question. STM32F072 has USB 2.0 connectivity. Does connectivity can also be USB 1.1?
very good point. and it's not a stupid question at all, because if you look e.g. at the OMAP35xx series they *only* support full-speed (480mbit/sec) USB, they *do not* support slower speeds so you always had to connect a full-speed USB Hub to them if you wanted to connect even a single USB 1.1 device.
I say this because the second USB of EOMA may be USB 1.1 and will not always be USB 2.0.
well, you could just make sure that you go through the hub... which you are planning anyway, then it is the hub's problem to do the buffering and packet forwarding.
so i *believe* it's fine...
you're planning to pass the "main" USB (the one that can be up to USB 3.0) directly through to a USB Host connector aren't you.
l.
2014-08-08 14:06 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
well, you could just make sure that you go through the hub... which you are planning anyway, then it is the hub's problem to do the buffering and packet forwarding.
so i *believe* it's fine...
you're planning to pass the "main" USB (the one that can be up to USB 3.0) directly through to a USB Host connector aren't you.
1st USB + 3.0 ----> USB Host Connector.
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
The USB HUb is FE1.1s (is the same of the KDE Tablet).
Will there be any problem?
Thanks.
On Fri, Aug 8, 2014 at 3:28 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-08 14:06 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
well, you could just make sure that you go through the hub... which you are planning anyway, then it is the hub's problem to do the buffering and packet forwarding.
so i *believe* it's fine...
you're planning to pass the "main" USB (the one that can be up to USB 3.0) directly through to a USB Host connector aren't you.
1st USB + 3.0 ----> USB Host Connector.
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
The USB HUb is FE1.1s (is the same of the KDE Tablet).
Will there be any problem?
the FE1.1 should do conversion and buffering of HS to FS.
l.
2014-08-08 16:47 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
the FE1.1 should do conversion and buffering of HS to FS.
But, what if the 2nd USB of EOMA provides less than USB 2.0 (like 1.1 or 1.0)? Will STM32F072 work correctly?
Thanks.
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
If "2nd USB" is USB1.1 that this picture will have problems. Most ot them not related to the STM. Not enough bandwidth to serve audio and wifi.
2014-08-08 20:07 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-08 16:47 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
the FE1.1 should do conversion and buffering of HS to FS.
But, what if the 2nd USB of EOMA provides less than USB 2.0 (like 1.1 or 1.0)? Will STM32F072 work correctly?
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
But on your question - yes, STM should work fine with USB1.1 host (don't know any 1.0 hosts...)
2014-08-09 6:13 GMT+03:00 krasi gichev krasimirr@gmail.com:
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
If "2nd USB" is USB1.1 that this picture will have problems. Most ot them not related to the STM. Not enough bandwidth to serve audio and wifi.
2014-08-08 20:07 GMT+03:00 Miguel Garcia gacuest@gmail.com:
2014-08-08 16:47 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
the FE1.1 should do conversion and buffering of HS to FS.
But, what if the 2nd USB of EOMA provides less than USB 2.0 (like 1.1 or 1.0)? Will STM32F072 work correctly?
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
2014-08-09 5:13 GMT+02:00 krasi gichev krasimirr@gmail.com:
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
If "2nd USB" is USB1.1 that this picture will have problems. Most ot them not related to the STM. Not enough bandwidth to serve audio and wifi.
So maybe Luke should set minimum requirements for 2nd USB in at least USB 2.0...
Or is there another possibility?
2014-08-09 5:15 GMT+02:00 krasi gichev krasimirr@gmail.com:
But on your question - yes, STM should work fine with USB1.1 host (don't know any 1.0 hosts...)
Thanks!
On Sat, Aug 9, 2014 at 10:25 AM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-09 5:13 GMT+02:00 krasi gichev krasimirr@gmail.com:
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
If "2nd USB" is USB1.1 that this picture will have problems. Most ot them not related to the STM. Not enough bandwidth to serve audio and wifi.
So maybe Luke should set minimum requirements for 2nd USB in at least USB 2.0...
nope. that rules out the IC1T and the jz4775 CPU cards. not gonna happen.
Or is there another possibility?
use the 2nd USB direct to the STM32, route the 1st USB to the FE1.1.
2014-08-09 5:15 GMT+02:00 krasi gichev krasimirr@gmail.com:
But on your question - yes, STM should work fine with USB1.1 host (don't know any 1.0 hosts...)
Thanks!
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
2014-08-09 13:38 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
use the 2nd USB direct to the STM32, route the 1st USB to the FE1.1.
But the minimum requirement for the 1st USB is USB 1.0. We have the same problem.
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Requirements_fo...
Is there another possibility?
Thanks.
On Sat, Aug 9, 2014 at 1:55 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-09 13:38 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
use the 2nd USB direct to the STM32, route the 1st USB to the FE1.1.
But the minimum requirement for the 1st USB is USB 1.0. We have the same problem.
don't worry about it. really.
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Requirements_fo...
Is there another possibility?
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
2014-08-09 16:09 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
don't worry about it. really.
1st USB ---> USB5434B-JZX --> USB Host 3.0 --> USB WIFI --> USB BT --> USB Audio
2nd USB ---> STM32F072
What about this?
The USB5434B-JZX seems to supports 3.0, 2.0 and 1.1.
USB5434B-JZX datasheet: http://www.mouser.com/catalog/specsheets/USB5434.pdf
USB5434B-JZX mouser: www.mouser.com/ProductDetail/Microchip-Technology/USB5434B-JZX/?Microchip-Technology/USB5434B-JZX/&qs=sGAEpiMZZMtv%252bwxsgy/hiFSa2hlhMdZw/zniVqeXLCU=
Thanks.
On Sat, Aug 9, 2014 at 7:34 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-09 16:09 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
don't worry about it. really.
1st USB ---> USB5434B-JZX --> USB Host 3.0 --> USB WIFI --> USB BT --> USB Audio
2nd USB ---> STM32F072
What about this?
The USB5434B-JZX seems to supports 3.0, 2.0 and 1.1.
have you also added in a PMIC for supporting the USB3 current requirements?
USB5434B-JZX datasheet: http://www.mouser.com/catalog/specsheets/USB5434.pdf
USB5434B-JZX mouser: www.mouser.com/ProductDetail/Microchip-Technology/USB5434B-JZX/?Microchip-Technology/USB5434B-JZX/&qs=sGAEpiMZZMtv%252bwxsgy/hiFSa2hlhMdZw/zniVqeXLCU=
$4 from a US-based company is a hell of a lot more than $1 for an extremely popular FE1.1.
honestly the extra power requirements and the cost i would say are simply not worth the hassle.
l.
nope. that rules out the IC1T and the jz4775 CPU cards. not gonna
happen. It is always to balance between requirements. If this CPU card forces Miguel to add $4 IC, that what's the benefit of $2 SoC? In fact probably his product will be useless with IC1T? If I was him, I would say that such cards are not supported in his product and put an end to this. Instead of searching for expensive hubs and changing the base board to support this - just to be able to conform to all options and support card that just can't be used there because of other limitations. Is it so that any EOMA based product (like his console) should run with any EOMA card (I mean to be able to run with minimum supported feature set of the standard)? Is it allowed to have a product that requires some of optional features to be present? If this is out of the scope of the discussion, just ignore it. Personally I have some other problems with EOMA idea so I had to switch my design to other form factor - so I don't "deserve" answer. Just trying to be helpful.
2014-08-09 21:43 GMT+03:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Sat, Aug 9, 2014 at 7:34 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-09 16:09 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
don't worry about it. really.
1st USB ---> USB5434B-JZX --> USB Host 3.0 --> USB WIFI --> USB BT --> USB Audio
2nd USB ---> STM32F072
What about this?
The USB5434B-JZX seems to supports 3.0, 2.0 and 1.1.
have you also added in a PMIC for supporting the USB3 current requirements?
USB5434B-JZX datasheet:
http://www.mouser.com/catalog/specsheets/USB5434.pdf
USB5434B-JZX mouser:
www.mouser.com/ProductDetail/Microchip-Technology/USB5434B-JZX/?Microchip-Technology/USB5434B-JZX/&qs=sGAEpiMZZMtv%252bwxsgy/hiFSa2hlhMdZw/zniVqeXLCU=
$4 from a US-based company is a hell of a lot more than $1 for an extremely popular FE1.1.
honestly the extra power requirements and the cost i would say are simply not worth the hassle.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Aug 10, 2014 at 9:56 AM, krasi gichev krasimirr@gmail.com wrote:
nope. that rules out the IC1T and the jz4775 CPU cards. not gonna happen.
It is always to balance between requirements. If this CPU card forces Miguel to add $4 IC, that what's the benefit of $2 SoC?
if someone is buying a product with a $2 SoC then they can expect to get what they pay for. the software will have to be configured to take into account that one of the interfaces is slower and e.g. ramp down the WIFI speed. or disable it.
basically the way that i see it is that *not* the base-board designers problem if someone buys a lower-spec CPU card. they pay less money, they get lower quality.
so, for example, with the IC1t they will be paying for something that can only do 480p video. and you know what? they are paying less money, they get lower quality.
In fact probably his product will be useless with IC1T?
... and they paid less money, so they understand that as part of the contract of sale they get lower quality. this is the bargain that they struck. it is *not* the base unit designer's problem.
If I was him, I would say that such cards are not supported in his product and put an end to this.
mmm... no, because, for example in this case, the software can always configure a 1mbit/sec WIFI speed. for example in this case, the software can always configure a 32k 16 bit audio rate (or, if that still is not enough, an 8k 16 bit audio rate).
Is it allowed to have a product that requires some of optional features to be present?
NO. absolutely not. absolute without a shadow of doubt, unassailably unarguably and with absolute no way in hell that there will be even the remotest, slightest possibility, not now, and not ever, will there be anything remotely approaching "optional features" in ANY standard i have anything to do with.
think about it. the "sales pitch" to end-users is "just buy any CPU Card, it will work". now, the _honest_ sales person will attach "however of course you get what you pay for" to that "simple sales pitch".
now think about what you are proposing. you are proposing that some features be "optional", yes? let's take the case where some arbitrary functionality only works on certain CPU Cards but not others.
how the heck is the sales person going to explain that??
no.
i don't *want* them to be "quotes explaining quotes" it. *any* CPU Card which does not provide some level of service - even a degraded one - on EVERY interface, automatically does NOT qualify for Certification.
If this is out of the scope of the discussion, just ignore it.
not at all, it presents an opportunity to makes things clear.
Personally I have some other problems with EOMA idea so I had to switch my design to other form factor - so I don't "deserve" answer. Just trying to be helpful.
appreciated.
out of curiosity, i'd be interested to hear if the design that you are creating is intended for anything approaching a decade-long support and end-user lifespan.
l.
2014-08-10 10:52 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
if someone is buying a product with a $2 SoC then they can expect to get what they pay for. the software will have to be configured to take into account that one of the interfaces is slower and e.g. ramp down the WIFI speed. or disable it.
So we have 2 options:
- Option A:
1st USB + 3.0 ----> USB Host 3.0
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
- Option B:
1st USB ---> FE 1.1 --> USB Host 2.0 --> USB WIFI --> USB BT --> USB Audio
2nd USB ---> STM32F072
-------------
What should we use?
Option A is the most complete, but if option B is the most compatible...
Thanks.
On Sun, Aug 10, 2014 at 12:04 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-10 10:52 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
if someone is buying a product with a $2 SoC then they can expect to get what they pay for. the software will have to be configured to take into account that one of the interfaces is slower and e.g. ramp down the WIFI speed. or disable it.
So we have 2 options:
Option A:
1st USB + 3.0 ----> USB Host 3.0
plus 900mA power requirements (0.9A) which the AXP209 can't handle, so you'll need to replace that (which means finding a suitable replacement plus example circuit)
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
Option B:
1st USB ---> FE 1.1 --> USB Host 2.0 --> USB WIFI --> USB BT --> USB Audio
2nd USB ---> STM32F072
... where you can use the AXP209, it can handle the 0.5A load for the USB 2.0 Host, you have plenty of example circuits to use.
What should we use?
Option A is the most complete, but if option B is the most compatible...
take power requirements into consideration i think it's fairly clear which option is most favourable.
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
out of curiosity, i'd be interested to hear if the design that you are creating is intended for anything approaching a decade-long support and end-user lifespan.
First of all, I want to make it clear that my area is closer to industrial and sometimes automotive than consumer. Also, I am sure that I don't have your experience and I don't see all the details that you have seen - and large customers that expect the CPU cards.
And, the usual disclaimer, this post will not bring any creative ideas, it will explain my position, so feel free to stop reading here...
But what I have learned in recent years is that there is no such thing like "one size fits all". Even if something fits well at the current time, this is temporal and will change in several months or an year. In our devices, in past 10 years, we had passed over several form factors of "processing boards" - PC104, ISA, ETX, and some other, our own too. And what we got like benefits is limited to: - possible second source - I hope the EOMA will be able to attract more that one designer and producer of CPU cards - possible upgrade of the CPU card - this works sometimes, but never for 10 years - maybe 2-3-5 years is realistic ( I mean in industrial, in consumer 1 year top); with current CAD tools it is not so hard to redesign to other form factor (you know it, you have made many desing recently) - save us some investment in development and gives us faster time to market - this is true for something like 100-5000 pcs per year, but not in mass market
Nope, I cannot even imagine that something (commercial) will live for so long. It might run fine but customers are always demanding new features, better perfomance (even just better design). And even if the lives than it will not be upgraded. Maybe it will be glued to the fridge for recipes in the kitchen, or will become garage door opener with twitter notifications ...
Components are getting obsolete, sometimes looking around the whole world to get some more pieces to build next batch is harder than to redesign (and at the end you have to redesign). Let's imagine that I get a product with EOMA slot - a good one with FHD, 1000:1 IPS and so on. I could imagine that in 2 years (or, more likely, 12 months) I would like to get a UHD display, probably AMOLED, probably one that consumes 50% of the power of the old one, probably better colors, maybe something like e-ink, maybe flexible... Probably a new wave of special batteries will be out there in 2 years... My point is (and probably I am biased by my lifestyle) that I will prefer to put the old one in the basement, or on the e-bay, and just go for the newest. Or, if you prefer, recycle it. My USB connectors will be worn out (yes, I use tham a lot, 2xJTAG, logic analyzer, serial converters and so on), my DC jack too. The electrolitic capacitors in the device will reach their 5000hour lifespan. Flash erase cycles will pass the limit. The keyboard will go bad, the screen will be scratched. (now I recognize that I can overcome this on my current laptop if I use a docking station - some 200USD for some plastic and connectors? But quite close to "base product" around a EOMA card?...) There are 2 type of user - one that would upgrade and others that will not. First one will like to get 4G RAM instead of 2 - so with EOMA they have to drop the complete card, istead of swapping a SODIMM? Others already have 8G of RAM, but want a faster CPU or 3D - they will have to dump (or re-buy) the 8G at the old board. It is similar to desktop-vs-laptop trends. One gives you limitless upgrade, other gives you mobility. The other players like smartphones and tablets are on the extreme side of "hey, remove the microSD slot to save some space, solder the battery to make it 6mm". So I am wondering were does the EOMA product go? Not in smartphones (hey, google, modular smartphone? worst idea I have seen from them since long time). Hard in tablets, where thickness, weigth and design are important. And that usually finish their life with cracked screen when someone drops them or sits on. Laptops? I like my i5 with 12GB RAM, don't count me in, next thing will be i7 with SATA6G SSD (at least, maybe something newer and faster then 6GBits/s). Desktops? No. NAS devices and home servers? Maybe, but CNX is full of news for android tv devices, now with RK3288, 4K UHD... DIY market? yes, why not, but do I need the PCMCIA housing and (limiting) connector when I put it on my breadboard, beside the arduino, to create a fancy LED flasher with "social services"? What's wrong with Olimex boards for this project? Aha, one is discontinued and the next one is not pin-compatible? Ok, redesign and be more careful. But this is nice opportunity to fix those hair wires below, or to add a header for second UART. There is nothing to fix or improve on this board anymore, the whole redesign it just to use another cpu card? Dream on, never on this planet.
It is not only the CPU and the memory, everythings get old and our of time.
I also use some old devices. e.g. one thinkpad. I liked it a lot - it is almost 10 years old. The keyboard was fine until I started using it a lot - obviously the previous owner had used a docking and external keyboard that saved it through the years. But 2 years in my hands and it is nothing special any more. And dirty, too. Display is slow, low res, not as bright as current ones.
What is probably a moving force behind this project, I believe, is the usage of the Linux, and huge market of Android devices. This means that a lot of people work hard to design cores, make chips, make hardware, port software. And this efforts come back as cheap SoCs with ready made android support.
You have given one example to support EOMA - everybody can push the switch and plug out the PCMCIA card, that put the other one. But I don't see my father, for example, doing this. For the same reason why only geeks (and normal engineers like us) are replacing SODIMMs, HDD, SSD on their laptops. So, what happens if somebody gets a CPU card and it does not work in Miguel's product? The same what happens when I buy a normal product and it does not run in my house / car / pc - I send it back (RMA). In current scenario, I don't see why his console will not bring a message - hey, I know this cheap CPU cards, but I cannot work with it! Please, open a web page and get the list of certified boards, or just order through our store, or contact your seller for replacement. That's all, simple and easy. Because if he does not refuse this card, he will start getting other question - hey, my wifi is damn slow, my audio does not work, my USB transfer to external HDD is slow? What? It is because of the new cpu card? That I want a replacement! I checked your web site, you have removed the list of compatible EOMAs? What? You had to do this because the standard says that it should run with all? But now you will pay the return shipment! You had to warn me that this is not going to work! If I only knew this issues I wouldn't order this, so that is now your problem, pay for return and find me a new one - and I am not going to pay anything above the original price!
I hope that there is enough user base that can benefit of the EOMA. In industrial area similar solution might work - if only it was designed to support CAN, Profibus and other industrial communication standards (more pins!). It it was "board level" product that 200 pins are there. Yes, non technical people cannot replace it, but hey, some people cannot work with computers either! And in fact similar standard are used very often here.
Again, saying "my point", I still believe what I said long ago, even before this list existed - open source (HW and SW) system-on-module using those cheap ARM SoCs is a good idea, but I see better marker for regular sodimm / qseven or even SMD soldered "cpu boards". That simplify the design of the end used products and don't add restrictions like "any board on any product". Maybe closer to the Olimex things - not much noise but several well selling boards. And more to come. Designed to allow entusiastic people to make their "startup".
2014-08-10 15:41 GMT+03:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Sun, Aug 10, 2014 at 12:04 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-10 10:52 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
if someone is buying a product with a $2 SoC then they can expect to get what they pay for. the software will have to be configured to take into account that one of the interfaces is slower and e.g. ramp down the WIFI speed. or disable it.
So we have 2 options:
Option A:
1st USB + 3.0 ----> USB Host 3.0
plus 900mA power requirements (0.9A) which the AXP209 can't handle, so you'll need to replace that (which means finding a suitable replacement plus example circuit)
2nd USB ----> USB HUB -----> USB WIFI -----> USB BT -----> USB Audio -----> USB STM32F072
Option B:
1st USB ---> FE 1.1 --> USB Host 2.0 --> USB WIFI --> USB BT --> USB Audio
2nd USB ---> STM32F072
... where you can use the AXP209, it can handle the 0.5A load for the USB 2.0 Host, you have plenty of example circuits to use.
What should we use?
Option A is the most complete, but if option B is the most compatible...
take power requirements into consideration i think it's fairly clear which option is most favourable.
Thanks.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Mon, Aug 11, 2014 at 2:17 AM, krasi gichev krasimirr@gmail.com wrote:
out of curiosity, i'd be interested to hear if the design that you are creating is intended for anything approaching a decade-long support and end-user lifespan.
First of all, I want to make it clear that my area is closer to industrial and sometimes automotive than consumer. Also, I am sure that I don't have your experience and I don't see all the details that you have seen - and large customers that expect the CPU cards.
And, the usual disclaimer, this post will not bring any creative ideas, it will explain my position, so feel free to stop reading here...
But what I have learned in recent years is that there is no such thing like "one size fits all". Even if something fits well at the current time, this is temporal and will change in several months or an year. In our devices, in past 10 years, we had passed over several form factors of "processing boards" - PC104, ISA, ETX, and some other, our own too. And what we got like benefits is limited to:
- possible second source - I hope the EOMA will be able to attract more that
one designer and producer of CPU cards
- possible upgrade of the CPU card - this works sometimes, but never for 10
years
ok, this intrigues me, that it is not clear why you believe that the interfaces selected would not last another 10 years. do you have time to go through them?
* ethernet. GbE. has been around for 2+ decades. do you expect GbE to be around for another 10 years?
* USB3. USB2 has been around for 2 + decades. it has been upgraded to USB3 which is 5gb/sec at the moment.. do you expect USB3 to be around for another 10 years? in fact, i understand that USB3 is to get at least *another* speed upgrade.
* GPIO, UART, I2C, SPI i think it safe to say that these will be around for at least a decade?
* SD/MMC. has been around for around 2 decades, and is constantly being upgraded. i think it safe to say that this will be around for another decade?
* RGB/TTL. has been around for 2+ decades. it's the baseline for video output. there's always going to be converter ICs, no matter what the latest-and-greatest standard.
i think it reason-ably safe to say that every single interface picked on the EOMA68 standard has a lifetime of at least one decade. as in there are reasons why every single interface has already been long-term and will continue to be so.
- maybe 2-3-5 years is realistic ( I mean in industrial, in consumer 1
year top); with current CAD tools it is not so hard to redesign to other form factor (you know it, you have made many desing recently)
yeees, but now you have set a MOQ for pricing for your clients. the purpose of the EOMA68 standard is to bring the benefit of mass-volume pricing *even* to this smaller custom run market.
Nope, I cannot even imagine that something (commercial) will live for so long. It might run fine but customers are always demanding new features,
how many of those features do not fit into USB3, SPI, SD/MMC and I2C?
better perfomance (even just better design).
what do you mean by performance? do you mean anything other than better CPU, better RAM, faster RAM, more RAM or more storage? because those are exactly what is on the CPU Card.
My point is (and probably I am biased by my lifestyle) that I will prefer to put the old one in the basement, or on the e-bay, and just go for the newest. Or, if you prefer, recycle it.
exactly! so just buy a new base-unit, keep the CPU Card, you have just saved 30% on the cost of a monolithic unit.
ok, there's a lot here, i have to get on, more later ok?
l.
I see your point. At this precise moment, your standard is up-to-date. I cannot complain. But just imagine that the EOMA things had gone faster and 1 year ago it was in production - before list discussion took place and decision to add USB3.0 was made (there is a planned update to USB3.1 with something like 10Gbit). Could we say that EOMA will be limiting for its users (it it missed the USB3.0)? Could you claim Gbit ethernet if EOMA had only USB2.0? Will anyone that plans on NAS-like server usage jump on EOMA product if he knows that there is no native SATA but just USB to SATA + USB to Gbit on one 480mbit/s port? Not to mention possibility to end up with 12Mbit/s port on some cards... Even now it is limiting because the same A10, A20, i.MX provide SATA, PCIe that base board designer cannot use. Not to mention MIPI and other high speed board interfaces. Is there a good way to add a camera (or even 2) to an EOMA based board? I think USB will come to the resque? But even now it is over-saturated for some of the boards... I checked EOMA page at elinux - there is a planned update of the standard in "2-3 years". I would say, backward compatibility will be lost? New base boards for new CPU cards? Where is the 10 years lifespan? Who will care producing old standard cpu cards with new SoCs? You say Gbit Ethernet - but IC1T does not have this? So I, in the position of designer of base board, cannot rely on this because some cards with give limited speed? In fact you are using one single multifunctional interface as backup - I mean the USB. If SoC does not support something, add it on USB. From the early days of EOMA you are ruling out the OMAPs because of HS-only USB. But the same workaround as for low end cards could have save the OMAP CPU card - you just need a HUB (on the CPU card). Probably this was the point behind developing SoC with HS only USB? Even with other "supported" SoC designers are ending with USB HUBs on the base board... So there is an alternative solutioin - base boards that need to connect internal low/full speed USB devices need to add a hub. If my product does not export user USB out of the "base board", and has nothing but HS capable on board peripherals, I can safely use any card, even those with OMAPs. Miguel speaks about <16ms reaction time (this is another topic), but obviously he demands some performance. So, for this reason or another, his product will never work with low end card (beside presenting "unsupported cpu card" message). To be able to sell products he has to satisfy user demands. Limited audio bit depth and network speed are bad for him - one youtube review about slow game console and mass user will be lost. Yes, geeks will know that with good cpu card everything is fine, so it comes to the same point where we started - "someone" will define list of supported cards, even if it is not Miguel because he is not allowed to do it by standard.
I have another question, sorry if it is out of context here. I know PCMCIA was designed long ago - is it certified that it will run fine with 5Gbits signals USB3.0? Does it comply to impedance matching for all interfaces? How about EMI? I am asking because one reason (for us) to switch to another SoM format was newer, high speed interfaces. Our suppliers switched to connectors that are compatible with newer standards. Maybe they could route out HS USB or SATA on ISA connector... I even doubt if PCMCIA can cope to USB2.0 HS routing requirements. I know it works in practice, even with flying wires. But not for production HW.
2014-08-11 9:48 GMT+03:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Mon, Aug 11, 2014 at 2:17 AM, krasi gichev krasimirr@gmail.com wrote:
out of curiosity, i'd be interested to hear if the design that you are creating is intended for anything approaching a decade-long support and end-user lifespan.
First of all, I want to make it clear that my area is closer to
industrial
and sometimes automotive than consumer. Also, I am sure that I don't have your experience and I don't see all the details that you have seen - and large customers that expect the CPU cards.
And, the usual disclaimer, this post will not bring any creative ideas,
it
will explain my position, so feel free to stop reading here...
But what I have learned in recent years is that there is no such thing
like
"one size fits all". Even if something fits well at the current time,
this
is temporal and will change in several months or an year. In our devices, in past 10 years, we had passed over several form
factors of
"processing boards" - PC104, ISA, ETX, and some other, our own too. And
what
we got like benefits is limited to:
- possible second source - I hope the EOMA will be able to attract more
that
one designer and producer of CPU cards
- possible upgrade of the CPU card - this works sometimes, but never for
10
years
ok, this intrigues me, that it is not clear why you believe that the interfaces selected would not last another 10 years. do you have time to go through them?
- ethernet. GbE. has been around for 2+ decades. do you expect GbE
to be around for another 10 years?
- USB3. USB2 has been around for 2 + decades. it has been upgraded
to USB3 which is 5gb/sec at the moment.. do you expect USB3 to be around for another 10 years? in fact, i understand that USB3 is to get at least *another* speed upgrade.
- GPIO, UART, I2C, SPI i think it safe to say that these will be
around for at least a decade?
- SD/MMC. has been around for around 2 decades, and is constantly
being upgraded. i think it safe to say that this will be around for another decade?
- RGB/TTL. has been around for 2+ decades. it's the baseline for
video output. there's always going to be converter ICs, no matter what the latest-and-greatest standard.
i think it reason-ably safe to say that every single interface picked on the EOMA68 standard has a lifetime of at least one decade. as in there are reasons why every single interface has already been long-term and will continue to be so.
- maybe 2-3-5 years is realistic ( I mean in industrial, in consumer 1
year top); with current CAD tools it is not so hard to redesign to other form factor (you know it, you have made many desing recently)
yeees, but now you have set a MOQ for pricing for your clients. the purpose of the EOMA68 standard is to bring the benefit of mass-volume pricing *even* to this smaller custom run market.
Nope, I cannot even imagine that something (commercial) will live for so long. It might run fine but customers are always demanding new features,
how many of those features do not fit into USB3, SPI, SD/MMC and I2C?
better perfomance (even just better design).
what do you mean by performance? do you mean anything other than better CPU, better RAM, faster RAM, more RAM or more storage? because those are exactly what is on the CPU Card.
My point is (and probably I am biased by my lifestyle) that I will
prefer to
put the old one in the basement, or on the e-bay, and just go for the newest. Or, if you prefer, recycle it.
exactly! so just buy a new base-unit, keep the CPU Card, you have just saved 30% on the cost of a monolithic unit.
ok, there's a lot here, i have to get on, more later ok?
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Mon, Aug 11, 2014 at 10:00 AM, krasi gichev krasimirr@gmail.com wrote:
You say Gbit Ethernet - but IC1T does not have this? So I, in the position of designer of base board, cannot rely on this because some cards with give limited speed?
again, the end-users get what they pay for. if they pay only $20 for a CPU Card, they should expect to get $20 of functionality. if however they pay $100 for a CPU Card and it says GbE and USB3, and 4gb of RAM, and octal-core, they again get what they pay for.
I have another question, sorry if it is out of context here. I know PCMCIA was designed long ago - is it certified that it will run fine with 5Gbits signals USB3.0? Does it comply to impedance matching for all interfaces?
give-or-take, yes. the impedance of PCMCIA pins is around 100 ohms. USB is 90 ohms. i'd say they're close enough, and the distances involved are very very short.
How about EMI?
this was discussed a couple of years back.
to repeat that discussion: we'll find out soon enough :)
again, to repeat what was mentioned back when this was first discussed: if it turns out to be a problem there is the "gold card" version (known as CardBus) where a metal shield is soldered at 10 different points onto the PCB, covering the PCMCIA connector.
also what was discussed, and repeated now, is that unlike with the original PCMCIA signalling the high-speed signals going over the PCMCIA connector are mostly differential pairs with much lower voltage swings.
the only one that may be of concern is the RGB/TTL interface, which will be operating at (in some cases) 75mhz.
so, to repeat the conclusion of the discussion from two years ago: if the EMI tests do not pass, we simply convert to the CardBus version with the gold shielding. however if it is not needed i do not wish to pay the extra costs, hence the reason why we go with the standard version for now.
l.
hi krasi, lots to answer here, apologies i don't have time to go through it all, first thing, i noticed you mentioned that your father would have difficulty swapping out an EOMA68 CPU Card, because SO-DIMMs and CPUs and PCI cards are hard to change in desktop PCs.
... can you see the logical fallacy in that statement that you have made?
i find it fascinating that people - especially engineers - confuse the fact that there is RAM and a CPU inside the CPU card's metal case with "therefore it must be hard to change".
serious question here: does your father have a camera? does that camera have a memory card? does he have physical or mental difficulty popping out and replacing the memory card of that camera?
the CPU Cards are exactly the same thing.
to the average person there really is no conceptual difference. push button. pull out. done in seconds. to the *engineer* - who has to have tools, and take anti-static precautions - the task *appears* difficult based on their prior experience.
but that prior experience is misleading you.
l.
Ok, no need to discuss this further. The only point that I will add is that open source embedded platform simply needs open source design files - schematic, layouts, BOM, board support packages and so on. How this files will be used is not important for the basic project. One could deside to make EOMA cpu cards with standartized connectors, form factor and feature set. Other can make board with 2.54mm headers on 4 sides. Or solder joints on the edge. This should be separate from the schematics in the same way as linux source code is separated from any particular "board form factor" or 'SoM standard". I see this like the greatest benefit of EOMA project.
2014-08-11 12:55 GMT+03:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
hi krasi, lots to answer here, apologies i don't have time to go through it all, first thing, i noticed you mentioned that your father would have difficulty swapping out an EOMA68 CPU Card, because SO-DIMMs and CPUs and PCI cards are hard to change in desktop PCs.
... can you see the logical fallacy in that statement that you have made?
i find it fascinating that people - especially engineers - confuse the fact that there is RAM and a CPU inside the CPU card's metal case with "therefore it must be hard to change".
serious question here: does your father have a camera? does that camera have a memory card? does he have physical or mental difficulty popping out and replacing the memory card of that camera?
the CPU Cards are exactly the same thing.
to the average person there really is no conceptual difference. push button. pull out. done in seconds. to the *engineer* - who has to have tools, and take anti-static precautions - the task *appears* difficult based on their prior experience.
but that prior experience is misleading you.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Mon, Aug 11, 2014 at 11:55 AM, krasi gichev krasimirr@gmail.com wrote:
Ok, no need to discuss this further. The only point that I will add is that open source embedded platform simply needs open source design files - schematic, layouts, BOM, board support packages and so on.
i know. here's a start: http://git.rhombus-tech.net/eoma.git - more as it happens. but we have to get the first cards and base units out there.
so much to do!!
I have a question about the EOMA-68.
If you (or someone else) manufactures and sells its own EOMA-68, how it will work on the console?
Let me explain. I suppose that the EOMA-68 for the console need special drivers for controls and STM32F. Possibly someone buy a EOMA-68 in a store and that EOMA-68 does not have these drivers. Can he not use that EOMA-68 on the console?
Thanks.
On Mon, Aug 11, 2014 at 3:26 PM, Miguel Garcia gacuest@gmail.com wrote:
I have a question about the EOMA-68.
If you (or someone else) manufactures and sells its own EOMA-68, how it will work on the console?
Let me explain. I suppose that the EOMA-68 for the console need special drivers for controls and STM32F. Possibly someone buy a EOMA-68 in a store and that EOMA-68 does not have these drivers. Can he not use that EOMA-68 on the console?
interesting and relevant question!
interesting because there is still quite a bit of work that needs to be done.
addressing the drivers:
a) there needs to be (will be) an "official" kernel area for eoma68 cards. pulling random kernels and software is going to "work" for a given value of "work" but it won't really be properly eoma68 compliant unless people use the proper kernels
b) so for example the drivers needed for the console will be in that "official" area.
c) part of that area involves the device-tree "merging" code (that will need to be written), so that the CPU Cards can dynamically detect what they're plugged into, load the Device-Tree fragment out of the EEPROM and go from there.
addressing the software:
a card out-of-the-box (3rd party) isn't exactly going to have the games or other apps on it, is it! :) so, it would "work"... but it would work only with what the OS software could find: screen, USB-HID devices, USB Audio and so on. soooo.... in theeorryyy, with the STM32F publishing "buttons" via a USB-HID, and publishing the analog joystick again as a USB mouse, in theeeoorrryyy "Random OS Mk VII" *might* actually work.
l.
I've been thinking about this.
There are instances where I might be interested in installing an OS optimized for consoles (such as OpenDingux in JZ4775 like GCW-Zero).
I think it would be interesting to sell this card with this OS installed. But this would only interest in a console (not in tablets or similar), so it makes no sense a EOMA-68 with this software.
Could we buy you the EOMA-68 that interest us, rename it (for example TOTOTO), install on it our software and sell only for the console?
The console will be compatible with EOMA-68 and TOTOTO. But other EOMA-68 chasis won't be compatible with TOTOTO.
Then, geeks users can install the OS/software of EOMA-68 in TOTOTO and convert the EOMA-68 in a TOTOTO card. Or install the OS/software of TOTOTO in EOMA-68 and convert the TOTOTO in a EOMA-68 card.
2014-08-11 16:46 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Mon, Aug 11, 2014 at 3:26 PM, Miguel Garcia gacuest@gmail.com wrote:
I have a question about the EOMA-68.
If you (or someone else) manufactures and sells its own EOMA-68, how it will work on the console?
Let me explain. I suppose that the EOMA-68 for the console need special drivers for controls and STM32F. Possibly someone buy a EOMA-68 in a store and that EOMA-68 does not have these drivers. Can he not use that EOMA-68 on the console?
interesting and relevant question!
interesting because there is still quite a bit of work that needs to be done.
addressing the drivers:
a) there needs to be (will be) an "official" kernel area for eoma68 cards. pulling random kernels and software is going to "work" for a given value of "work" but it won't really be properly eoma68 compliant unless people use the proper kernels
b) so for example the drivers needed for the console will be in that "official" area.
c) part of that area involves the device-tree "merging" code (that will need to be written), so that the CPU Cards can dynamically detect what they're plugged into, load the Device-Tree fragment out of the EEPROM and go from there.
addressing the software:
a card out-of-the-box (3rd party) isn't exactly going to have the games or other apps on it, is it! :) so, it would "work"... but it would work only with what the OS software could find: screen, USB-HID devices, USB Audio and so on. soooo.... in theeorryyy, with the STM32F publishing "buttons" via a USB-HID, and publishing the analog joystick again as a USB mouse, in theeeoorrryyy "Random OS Mk VII" *might* actually work.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
mån 2014-08-11 klockan 18:20 +0200 skrev Miguel Garcia:
There are instances where I might be interested in installing an OS optimized for consoles (such as OpenDingux in JZ4775 like GCW-Zero).
Ok.
I think it would be interesting to sell this card with this OS installed. But this would only interest in a console (not in tablets or similar), so it makes no sense a EOMA-68 with this software.
Why? If the console is using EOMA68 interface connector and signalling then why would it not be EOMA-68?
Could we buy you the EOMA-68 that interest us, rename it (for example TOTOTO), install on it our software and sell only for the console?
Yes, unless the manufacturer of said card has some meaningful objections on you relabeling their card and refuses to deal with you..
The console will be compatible with EOMA-68 and TOTOTO. But other EOMA-68 chasis won't be compatible with TOTOTO.
What in TOTOTO makes it not EOMA-68?
Then, geeks users can install the OS/software of EOMA-68 in TOTOTO and convert the EOMA-68 in a TOTOTO card. Or install the OS/software of TOTOTO in EOMA-68 and convert the TOTOTO in a EOMA-68 card.
Sure.
Regards Henrik
2014-08-12 0:54 GMT+02:00 Henrik Nordström henrik@henriknordstrom.net:
Why? If the console is using EOMA68 interface connector and signalling then why would it not be EOMA-68?
The console will be compatible with EOMA-68 and TOTOTO.
You can use any EOMA-68 card if you want.
Furthermore, the TOTOTO card would be an exclusive card for this console. This card will bring all software for the console already prepared and optimized. It would be especially for normal users who want everything without doing anything
However, we would release the software of TOTOTO cards and if you already have a EOMA-68, you can install this software on it.
What in TOTOTO makes it not EOMA-68?
Software optimized for the console that makes no sense in a generic EOMA-68 card (such as a tablet or a router).
The rest is the same as a EOMA-68 card.
For example, imagine a card that when you turn it on, the card run only emulators (like SNES, PSX, Dreamcast...) optimized for that card. That does not make sense in a tablet or a router and would be impossible in a generic EOMA-68 card.
On Mon, Aug 11, 2014 at 5:20 PM, Miguel Garcia gacuest@gmail.com wrote:
I've been thinking about this.
There are instances where I might be interested in installing an OS optimized for consoles (such as OpenDingux in JZ4775 like GCW-Zero).
I think it would be interesting to sell this card with this OS installed. But this would only interest in a console (not in tablets or similar), so it makes no sense a EOMA-68 with this software.
ahh... well the general idea is that the CPU Card should work with anything, regardless of what it's plugged in to. much as i don't want to say it general-purpose scripted / VM languages such as java would tend to be the recommended base.
Could we buy you the EOMA-68 that interest us, rename it (for example TOTOTO), install on it our software and sell only for the console?
sure, that'd work well.... just please don't promote that it's EOMA68 compliant, because it certainly won't be.
l.
On 12/08/14 08:55, Luke Kenneth Casson Leighton wrote:
On Mon, Aug 11, 2014 at 5:20 PM, Miguel Garcia gacuest@gmail.com wrote:
I've been thinking about this.
There are instances where I might be interested in installing an OS optimized for consoles (such as OpenDingux in JZ4775 like GCW-Zero).
I think it would be interesting to sell this card with this OS installed. But this would only interest in a console (not in tablets or similar), so it makes no sense a EOMA-68 with this software.
ahh... well the general idea is that the CPU Card should work with anything, regardless of what it's plugged in to. much as i don't want to say it general-purpose scripted / VM languages such as java would tend to be the recommended base.
Could we buy you the EOMA-68 that interest us, rename it (for example TOTOTO), install on it our software and sell only for the console?
sure, that'd work well.... just please don't promote that it's EOMA68 compliant, because it certainly won't be.
what if it's duel boot? Could it auto switch so when it's plugged into the game console it boots the game console only distro and anything else the generic full system?
heck could you turn the game distro human interface into a desktop environment?
On Tue, Aug 12, 2014 at 11:49 AM, Alexander Stephen Thomas Ross maillist_arm-netbook@aross.me wrote:
On 12/08/14 08:55, Luke Kenneth Casson Leighton wrote:
On Mon, Aug 11, 2014 at 5:20 PM, Miguel Garcia gacuest@gmail.com wrote:
I've been thinking about this.
There are instances where I might be interested in installing an OS optimized for consoles (such as OpenDingux in JZ4775 like GCW-Zero).
I think it would be interesting to sell this card with this OS installed. But this would only interest in a console (not in tablets or similar), so it makes no sense a EOMA-68 with this software.
ahh... well the general idea is that the CPU Card should work with anything, regardless of what it's plugged in to. much as i don't want to say it general-purpose scripted / VM languages such as java would tend to be the recommended base.
Could we buy you the EOMA-68 that interest us, rename it (for example TOTOTO), install on it our software and sell only for the console?
sure, that'd work well.... just please don't promote that it's EOMA68 compliant, because it certainly won't be.
what if it's duel boot? Could it auto switch so when it's plugged into the game console it boots the game console only distro and anything else the generic full system?
brain-storm ideas, good one. ... anyone else?
heck could you turn the game distro human interface into a desktop environment?
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
2014-08-12 11:49 GMT+02:00 Alexander Stephen Thomas Ross maillist_arm-netbook@aross.me:
what if it's duel boot? Could it auto switch so when it's plugged into the game console it boots the game console only distro and anything else the generic full system?
heck could you turn the game distro human interface into a desktop environment?
Seems a good idea. The problem is when you have many devices based on EOMA-68 (such as routers, etc.). That's difficult with your idea. You would need several OS at once.
EOMA-68 is good for generic OS (also useful in the console). But if you want to offer specifics features/software, you need specific cards.
On Wed, 13 Aug 2014 11:14:43 +0200 Miguel Garcia gacuest@gmail.com wrote:
Seems a good idea. The problem is when you have many devices based on EOMA-68 (such as routers, etc.). That's difficult with your idea. You would need several OS at once.
Why not just implement the system (OS side) a bit different:
- Put the base OS on the microSD onboard the EOMA68 module - Put an additional storage (Flash/SD/eg.) onboard the carrier board (Laptop/Beamer/TV/Router/eg.)
With this way it would be possible to have all specific drivers shipped with the CPU module and have the desired user space programs (GUI/Shell/needed programs) shipped with the carrier. So it would be easier to swap the CPU card (on which you could store your user settings).
On Wed, Aug 13, 2014 at 1:28 PM, Richard Zink zink@hexatux.org wrote:
On Wed, 13 Aug 2014 11:14:43 +0200 Miguel Garcia gacuest@gmail.com wrote:
Seems a good idea. The problem is when you have many devices based on EOMA-68 (such as routers, etc.). That's difficult with your idea. You would need several OS at once.
Why not just implement the system (OS side) a bit different:
- Put the base OS on the microSD onboard the EOMA68 module
- Put an additional storage (Flash/SD/eg.) onboard the carrier board (Laptop/Beamer/TV/Router/eg.)
With this way it would be possible to have all specific drivers shipped with the CPU module and have the desired user space programs (GUI/Shell/needed programs) shipped with the carrier. So it would be easier to swap the CPU card (on which you could store your user settings).
ok think it through. remember that the guiding rule is, for the end-user "it must just work" and that translates to (in the standard) "there must be ZERO options" (as in, you are not permitted to choose "i think i will implement only part of the standard", nor does the standard itself say "you may implement only one of the 2 USBs, you *MUST* have both, even if they are slower or faster").
so, what in effect you are saying is that *ll* carrier boards *must* have:
1) some additional storage. that would need to become part of the specification. it would then be necessary to specify the minimum requirements (size, transfer rate). the type doesn't actually matter because the EEPROM can specify where it is accessible from as a DeviceTree overlay.
2) userspace programs *per CPU*. so, there must be MIPS versions of the programs, ARM (32-bit) versions, ARM (32-bit) hard-float versions, ARM (64-bit) versions... when they come out, x86 versions of the programs (32-bit, 64-bit, 486 variants)....
basically (1) is not hugely desirable but could be done but (2) would be a complete nightmare of the first order.
there are two maybe 3 possible ways around it though:
2a) you ship interpreted applications *only*. java, python, perl, ruby, .NET and so on
2b) you actually ship the full source code and the CPU Card will have a complete compiler
2c) you have a web site that allows OS applications to be downloaded, stored on e.g. external media or whatever the end-user chooses.
i think, really, 2c is the most practical / realistic way. allow people to select and install complete OSes, provide a base mechanism to do that.
which would be kinda cool. "oh you plugged in to this type of base unit, let me just offer you the opportunity to download a complete OS you can use which is customised to fit it".
l.
2014-08-13 12:16 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
i think, really, 2c is the most practical / realistic way. allow people to select and install complete OSes, provide a base mechanism to do that.
Yes, option 2c is the best.
You sell the card with a generic OS. When you connect the EOMA-68 to the console, this EOMA-68 reads a code in the EEPROM and the EOMA-68 searches a specific OS on the Internet for that code. Then download this secondary OS. Then you can choose between generic OS or secondary OS every time you turn on the console.
Also, if you change the EOMA-68 to another device, this card should read the EEPROM code and if the code is not the same, it will be impossible to run the secondary OS that was installed (to avoid errors/incompatibilities).
On Wed, Aug 13, 2014 at 12:36 PM, Miguel Garcia gacuest@gmail.com wrote:
2014-08-13 12:16 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
i think, really, 2c is the most practical / realistic way. allow people to select and install complete OSes, provide a base mechanism to do that.
Yes, option 2c is the best.
Also, if you change the EOMA-68 to another device, this card should read the EEPROM code and if the code is not the same, it will be impossible to run the secondary OS that was installed (to avoid errors/incompatibilities).
preeecisely.
... quoting the black widow from "The Avengers":
"sure, why not - it'll be fun"
:)
ons 2014-08-13 klockan 12:16 +0200 skrev Luke Kenneth Casson Leighton:
- some additional storage. that would need to become part of the
specification. it would then be necessary to specify the minimum requirements (size, transfer rate). the type doesn't actually matter because the EEPROM can specify where it is accessible from as a DeviceTree overlay.
I disagree that this need to be in EOMA68 standard. But it may well be in some OS specifications for specific usage. I.e. you need at least X amount of storage in the carrier board for storing games, videos or whatever and this OS supports this/these cards.
with unfortunately no guarantee that stored data is meaningful with another OS or card. Standard only gives that you can speak to the same storage device no matter what card or OS you have installed, not that you can exchange data between all OS:es/cards when swapping card.
- userspace programs *per CPU*. so, there must be MIPS versions of
the programs, ARM (32-bit) versions, ARM (32-bit) hard-float versions, ARM (64-bit) versions... when they come out, x86 versions of the programs (32-bit, 64-bit, 486 variants)....
Ugh.. no.
2b) you actually ship the full source code and the CPU Card will have a complete compiler
Unlikely, and even then programs often fail compiling with another compiler version or library versions..
2c) you have a web site that allows OS applications to be downloaded, stored on e.g. external media or whatever the end-user chooses.
Yes, that would work, and connects fine with above storage requirements.
which would be kinda cool. "oh you plugged in to this type of base unit, let me just offer you the opportunity to download a complete OS you can use which is customised to fit it".
OS or application doesn't matter. But in either case it will likely be tied to CPU card + carrier combo.
imho having EOMA68 evolve into a full OS specification requirement would be a bad idea. It's hard enough to get the hardware side right.
Having some recommendations is fine, i.e. how storage should be managed so that data can be shared etc.
Regards Henrik
On 13/08/14 10:14, Miguel Garcia wrote:
2014-08-12 11:49 GMT+02:00 Alexander Stephen Thomas Ross maillist_arm-netbook@aross.me:
what if it's duel boot? Could it auto switch so when it's plugged into the game console it boots the game console only distro and anything else the generic full system?
heck could you turn the game distro human interface into a desktop environment?
Seems a good idea. The problem is when you have many devices based on EOMA-68 (such as routers, etc.). That's difficult with your idea. You would need several OS at once.
It's not preferable, it's a compromise. I would strongly recommend putting the software you want to say the (for example) debian repos or (for the short term) in your own repo. with packages that setup the configuration you want, the desktop environment you want. "apt-get install game-console"
with auto switch desktop environment depending with device its plugged into or manual override at the login screen (or during boot?) where you can force a DE should you really want to.
I guess your concerned about more than a DE but about the background stuff and perhaps having a very minimal system. Don't see why a minimal system can't be loaded instead of the normal full system.? I guess it's a lot of work to take a system, DE that is designed for a minimal, custom, different system and have it working on a full debian system for example, and to maintain it, to merge changes from upstream into these err Debian compatible versions is that your thinking? if so, thats why I suggested the compromise of duel boot this time round but long term, I'd like to see these things integrated into full generic distos.
EOMA-68 is good for generic OS (also useful in the console). But if you want to offer specifics features/software, you need specific cards.
not so preferable, urrg.
hmm didn't the improv kde people have a automated compiling farm/service or something?
2014-08-12 9:55 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
ahh... well the general idea is that the CPU Card should work with anything, regardless of what it's plugged in to. much as i don't want to say it general-purpose scripted / VM languages such as java would tend to be the recommended base.
And we want that any EOMA-68 compatible with this console.
Only in some cases, we want specific software and we need our own card (because EOMA-68 can not do this).
sure, that'd work well.... just please don't promote that it's EOMA68 compliant, because it certainly won't be.
Of course. Because these TOTOTO cards only have software to run on this console and therefore will not work correctly on other devices compatible EOMA-68.
On Tue, Aug 12, 2014 at 1:36 PM, Miguel Garcia gacuest@gmail.com wrote:
Of course. Because these TOTOTO cards only have software to run on this console and therefore will not work correctly on other devices compatible EOMA-68.
i think that's the best we can do for now until the software infrastructure is more mature.
l.
2014-08-12 15:18 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Tue, Aug 12, 2014 at 1:36 PM, Miguel Garcia gacuest@gmail.com wrote:
Of course. Because these TOTOTO cards only have software to run on this console and therefore will not work correctly on other devices compatible EOMA-68.
i think that's the best we can do for now until the software infrastructure is more mature.
Yes, it's the best.
Anyway, we try to make all drivers open, it will be easier to support EOMA-68.
Thanks.
mån 2014-08-11 klockan 15:46 +0100 skrev Luke Kenneth Casson Leighton:
c) part of that area involves the device-tree "merging" code (that will need to be written), so that the CPU Cards can dynamically detect what they're plugged into, load the Device-Tree fragment out of the EEPROM and go from there.
Beaglebone have something like that in their kernels with device tree overlays loaded runtime based on eeprom contents of connected "shields".
publishing "buttons" via a USB-HID, and publishing the analog joystick again as a USB mouse, in theeeoorrryyy "Random OS Mk VII" *might* actually work.
I might even say SHOULD work, that's the point of having USB standards. But not all buttons might be mapped to meaningful events out of the box.
And joystick do have it's own USB-HID profile.
Regards Henrik
On Mon, Aug 11, 2014 at 11:49 PM, Henrik Nordström henrik@henriknordstrom.net wrote:
mån 2014-08-11 klockan 15:46 +0100 skrev Luke Kenneth Casson Leighton:
c) part of that area involves the device-tree "merging" code (that will need to be written), so that the CPU Cards can dynamically detect what they're plugged into, load the Device-Tree fragment out of the EEPROM and go from there.
Beaglebone have something like that in their kernels with device tree overlays loaded runtime based on eeprom contents of connected "shields".
oh gooood, whew.
publishing "buttons" via a USB-HID, and publishing the analog joystick again as a USB mouse, in theeeoorrryyy "Random OS Mk VII" *might* actually work.
I might even say SHOULD work, that's the point of having USB standards. But not all buttons might be mapped to meaningful events out of the box.
true
And joystick do have it's own USB-HID profile.
oh, duh :) thank you for pointing that out.
l.
2014-08-12 0:49 GMT+02:00 Henrik Nordström henrik@henriknordstrom.net:
I might even say SHOULD work, that's the point of having USB standards. But not all buttons might be mapped to meaningful events out of the box.
And joystick do have it's own USB-HID profile.
Our idea is to do open drivers for controller. Anyone can make another console based on EOMA-68 with the same drivers for controller.
These drivers might become a standard and included them in all EOMA-68.
On Sat, Aug 9, 2014 at 3:11 PM, Stefan Monnier monnier@iro.umontreal.ca wrote:
If "2nd USB" is USB1.1 that this picture will have problems. Most ot them not related to the STM. Not enough bandwidth to serve audio and wifi.
FWIW, I've used a cheap USB audio dongle on USB 1.1 (on an ASUS WL-500g) and it worked fine.
384kb/sec so yes well below the USB 1.1 11mbit/sec - it's when WIFI is added to that when it will get tricky.
Stefan
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook@lists.phcomp.co.uk
-
Alexander Stephen Thomas Ross -
Daniel Iglesias -
Henrik Nordström -
joem -
krasi gichev -
Luke Kenneth Casson Leighton -
Miguel Garcia -
peter green -
Richard Zink -
Simon Kenyon -
Stefan Monnier