From lkcl at lkcl.net Mon Sep 1 09:34:37 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Sep 2014 10:34:37 +0200 Subject: [Arm-netbook] eoma68-a20 rev 2.2 pcbs done Message-ID: the rev 2.2 boards are now at wits tech, there are three with 1gb of RAM, the 2 with 2gb RAM need to be redone, will keep people informed. l. From lkcl at lkcl.net Mon Sep 1 09:36:32 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Sep 2014 10:36:32 +0200 Subject: [Arm-netbook] eoma68 trademark Message-ID: i think i have a solution now to the eoma68 trademark issues, i will let people know in a couple of months how it goes. l. From lkcl at lkcl.net Mon Sep 1 11:12:07 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Sep 2014 12:12:07 +0200 Subject: [Arm-netbook] mendel90 3d printer arrived Message-ID: also the mendel 90 kit arrived last week, i am about 20% through a build, it is... challenging shall we say: around 200 nuts/bolts/screws which i really wasn't expecting! i'll likely be done by end of this week and can start experimenting. l. From simon at koala.ie Tue Sep 2 09:26:01 2014 From: simon at koala.ie (Simon Kenyon) Date: Tue, 02 Sep 2014 09:26:01 +0100 Subject: [Arm-netbook] thoughts about a set top box Message-ID: <54057F19.9040306@koala.ie> i've been thinking about this over the last year to two. decided to put it out there to see if anyone a) had any comments b) knows of existing hardware or c) interested in collaborating the idea is for a device which can act as a set top box, either as a pure player of content stored or streamed from elsewhere or as a receiver of content using one or more DVB-S2/T2 tuners. design criteria: - linux - open source including all drivers and codecs - fast enough to render 1080p - hdmi out - bluetooth/wifi on board - all connectors on one edge of board so casework can be professional quality - tuners on board or pluggable. i had an idea to re-use the dimensions of a standard motherboard and instead of spci slots - have usb plugs instead. a tuner could then plug in like a pci card. - space on the pc for a 2.5" disk (see http://www.sinovoip.com.cn/ecp_view.asp?id=554) -- simon Simon Kenyon Managing Director. The Koala Computer Company Limited e: simon at koala.ie m: +353 86 240 0005 l: http://ie.linkedin.com/pub/simon-kenyon/0/6b2/744/ s: simonckenyon t: @simonckenyon g: google.com/+SimonKenyon From joem at martindale-electric.co.uk Tue Sep 2 12:10:47 2014 From: joem at martindale-electric.co.uk (joem) Date: Tue, 2 Sep 2014 11:10:47 +0000 Subject: [Arm-netbook] mendel90 3d printer arrived In-Reply-To: References: Message-ID: <1409656248.9278.7.camel@jm-desktop> On Mon, 2014-09-01 at 12:12 +0200, Luke Kenneth Casson Leighton wrote: > also the mendel 90 kit arrived last week, i am about 20% through a > build, it is... challenging shall we say: around 200 nuts/bolts/screws > which i really wasn't expecting! i'll likely be done by end of this > week and can start experimenting. If you do 3D modelling in scripted parametric openscad, I'm in with whatever is doable to help. Maths, formulas, etc, and anything that can be done up xmaxima + surfaces that can be done in K3DSurf surface generator, doing test prints etc. From lkcl at lkcl.net Tue Sep 2 12:27:27 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 2 Sep 2014 13:27:27 +0200 Subject: [Arm-netbook] mendel90 3d printer arrived In-Reply-To: <1409656248.9278.7.camel@jm-desktop> References: <1409656248.9278.7.camel@jm-desktop> Message-ID: On Tue, Sep 2, 2014 at 1:10 PM, joem wrote: > On Mon, 2014-09-01 at 12:12 +0200, Luke Kenneth Casson Leighton wrote: >> also the mendel 90 kit arrived last week, i am about 20% through a >> build, it is... challenging shall we say: around 200 nuts/bolts/screws >> which i really wasn't expecting! i'll likely be done by end of this >> week and can start experimenting. > > > If you do 3D modelling in scripted parametric openscad, > I'm in with whatever is doable to help. i'm using pyopenscad, it auto-generates openscad files based on python classes: it is as weeird as the openscad language :) > Maths, formulas, etc, and anything that can be > done up xmaxima + surfaces that can be done in K3DSurf > surface generator, doing test prints etc. okay! cool, i'd not heard of k3dsurf. awesome. ta joe. From joem at martindale-electric.co.uk Tue Sep 2 13:17:29 2014 From: joem at martindale-electric.co.uk (joem) Date: Tue, 2 Sep 2014 12:17:29 +0000 Subject: [Arm-netbook] mendel90 3d printer arrived In-Reply-To: References: <1409656248.9278.7.camel@jm-desktop> Message-ID: <1409660250.9278.24.camel@jm-desktop> On Tue, 2014-09-02 at 13:27 +0200, Luke Kenneth Casson Leighton wrote: > On Tue, Sep 2, 2014 at 1:10 PM, joem wrote: > > On Mon, 2014-09-01 at 12:12 +0200, Luke Kenneth Casson Leighton wrote: > >> also the mendel 90 kit arrived last week, i am about 20% through a > >> build, it is... challenging shall we say: around 200 nuts/bolts/screws > >> which i really wasn't expecting! i'll likely be done by end of this > >> week and can start experimenting. > > > > > > If you do 3D modelling in scripted parametric openscad, > > I'm in with whatever is doable to help. > > i'm using pyopenscad, it auto-generates openscad files based on > python classes: it is as weeird as the openscad language :) > > > Maths, formulas, etc, and anything that can be > > done up xmaxima + surfaces that can be done in K3DSurf > > surface generator, doing test prints etc. > > okay! cool, i'd not heard of k3dsurf. awesome. > > ta joe. pyopenscad i believe is used to script up complex functions to generate objects surfaces because openscad is relatively simple language and doesn't have the giant features of python. Openscad is evolving - the latest version does tapered screw spirals. I made a tapered screw chuck type thing that is 1 inch and so strong it can take a spanner to tighten it and thread don't break. Unlike nylon screws. And this thing is done in PLA :( ! Anyway lots of designs released in openscad at thingiverse. Search for parametric designs - reduce chance of re-inventing wheel. From lkcl at lkcl.net Wed Sep 3 12:04:40 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 3 Sep 2014 13:04:40 +0200 Subject: [Arm-netbook] mendel90 3d printer arrived In-Reply-To: <1409660250.9278.24.camel@jm-desktop> References: <1409656248.9278.7.camel@jm-desktop> <1409660250.9278.24.camel@jm-desktop> Message-ID: On Tue, Sep 2, 2014 at 2:17 PM, joem wrote: > On Tue, 2014-09-02 at 13:27 +0200, Luke Kenneth Casson Leighton wrote: >> On Tue, Sep 2, 2014 at 1:10 PM, joem wrote: >> > On Mon, 2014-09-01 at 12:12 +0200, Luke Kenneth Casson Leighton wrote: >> >> also the mendel 90 kit arrived last week, i am about 20% through a >> >> build, it is... challenging shall we say: around 200 nuts/bolts/screws >> >> which i really wasn't expecting! i'll likely be done by end of this >> >> week and can start experimenting. >> > >> > >> > If you do 3D modelling in scripted parametric openscad, >> > I'm in with whatever is doable to help. >> >> i'm using pyopenscad, it auto-generates openscad files based on >> python classes: it is as weeird as the openscad language :) >> >> > Maths, formulas, etc, and anything that can be >> > done up xmaxima + surfaces that can be done in K3DSurf >> > surface generator, doing test prints etc. >> >> okay! cool, i'd not heard of k3dsurf. awesome. >> >> ta joe. > > > pyopenscad i believe is used to script up complex functions > to generate objects surfaces because openscad is relatively simple > language and doesn't have the giant features of python. relatively simple... still incredibly awkward to understand: it's the "container" notation. which way round should it go? what should contain what? should an object be added to a union or a union added to an object? also the language is not NP-complete so is, by definition, extremely limited for doing anything beyond what the designers of the language envisioned - and therefore forced onto its users - what it should be used for. so the fact that the openscad language has a special feature for doing parametric screws has me alarmed, _not_ impressed. what's next to be added? what special extra feature? now fast-forward a decade and now the "relatively simple language" has become something that should be avoided at all costs. > Anyway lots of designs released in openscad at thingiverse. > Search for parametric designs - reduce chance of re-inventing wheel. do they have 3D spine surfaces yet, where the surface may be specified by a 2D array of 3D points and the intermediary points created to a required level of detail using bezier splines? the answer should be *no* because it is a slippery slope to add such functionality to the base language. l. From lkcl at lkcl.net Fri Sep 5 09:40:40 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Sep 2014 09:40:40 +0100 Subject: [Arm-netbook] eoma68 a20 rev 2.2 cpu cards Message-ID: ... have passed testing and are being shipped out to me today. still todo: the micro-desktop board prototypes. l. From lkcl at lkcl.net Fri Sep 5 10:34:26 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Sep 2014 10:34:26 +0100 Subject: [Arm-netbook] Fwd: Allwinner A33 Quad Core 2GB board in development In-Reply-To: References: Message-ID: this has gone out to debian-arm and fedora arm lists, if anyone else would like an A33 CPU Card let me know. l. ---------- Forwarded message ---------- From: Luke Kenneth Casson Leighton Date: Fri, Sep 5, 2014 at 10:33 AM Subject: Fwd: Allwinner A33 Quad Core 2GB board in development To: Fedora ARM i'm doing an EOMA68-A33 CPU Card which will cost $5600 to complete the layout and 5 samples. i can cover that cost over a couple of months, so it is going ahead, and first (working) 5 samples should be done and received by Dec 2014. if there is anyone who would like to buy either one of the 5 samples (at a premium) or would like to be part of a group-buy please do contact me directly. specifications are: * Allwinner A33 Quad Core ARM Cortex A7 * 2GByte RAM on a 32-bit interface * 18-pin RGB/TTL up to 1280x800 resolution * on-board SMC9514 USB-Ethernet IC (10/100) * 2x USB2 (480mb/s) on EOMA68 interface * 1x USB-OTG (can be used to power CPU Card) * 1x Micro-SD note that unlike the A20 CPU Card this one does *not* have HDMI out (it's a lower-cost SoC) and the max resolution really is limited to 1280x800 because the A33 is a tablet SoC... albeit a quad-core one. news as it happens will be at http://rhombus-tech.net/allwinner/a33/news/ l. From gacuest at gmail.com Fri Sep 5 11:56:05 2014 From: gacuest at gmail.com (Miguel Garcia) Date: Fri, 5 Sep 2014 12:56:05 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console Message-ID: I appreciate you analyze the block diagram. If you know any better component or an error or a missing connection, please tell me. Thanks. ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- Block Diagram EOMA-68 Handheld Games Console v.1.0 ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- A basic sketch of the block diagram: http://oi57.tinypic.com/16aeffb.jpg ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- ----------------- Slot PCMCIA: ----------------- Part Number: Amphenol G659EU1X2472X Datasheet: 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-68_pinouts ------------ Display: ------------ Part Number: BTL507212-W677L Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/5.0''%20LCD%20HD%20-%20GL5005%20Spec_D.pdf Connections: - The MIPI pins are connected to MIPI pins of the MIPI-a-RGB IC. - The pins of the PWM are connected to PWR pins of the EOMA-68. - The display is connected to GPIO of the STM32F for power-up of LCD. --------------- MIPI-to-RGB IC: --------------- Part Number: SSD2828 Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/SSD2828QN4_1.0.pdf Connections: - The MIPI pins are connected to MIPI pins of the display. - The RGB pins are connected to RGB pins of the EOMA-68. - The SPI pins are connected to SPI pins of the EOMA-68. ---------------- Touch Panel: ---------------- Part Number: no hay Part Number definitivo. Datasheet: no definitive part number. A datasheet of a similar part number: https://dl.dropboxusercontent.com/u/19251472/D50-L4030A-K0D.pdf Connections: - The I2C pins of the Touch Panel are connected to I2C pins of the EOMA-68. ----------- Battery: ----------- Part Number: LP8067100-CI Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/LP8067100-CI.pdf Connections: - The pins of the battery are connected to battery connector. ------------------ Battery Connector: ------------------ Part Number: PH-LT-WT-NA Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/PH-LT-WT-NA%E6%89%BF%E8%AE%A4%E4%B9%A6.pdf Connections: - The pins of the battery connector are connected to battery pins of the PMIC. ------------------ MicroUSB for Charging: ------------------ This microUSB is only responsible for charging the battery (no USB Host). Part Number (provisional): 47590-0001 Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/micro_usb_ab_475900001_sd.pdf Connections: - The power pins of the microUSB are connected to load pins of the PMIC. ------------------ 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). Connections: - The pins of the LED of Charging are connected to LED pins of the PMIC. -------------- PMIC: -------------- Part Number: AXP209 Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/AXP209-SpecSheet-Translated.pdf y http://hands.com/~lkcl/eoma/kde_tablet/AXP209%20Datasheet%20v1.0_cn.pdf Connections: - The PMIC are connected to PWR1, PWR2, PWR3 and PWR4 pins of the EOMA-68. - The PMIC are connected to I2C_SCL and I2C_SDA pins of the EOMA-68. - The PMIC are connected to a GPIO of the STM32F microcontroller (IRQ-OUT of AXP209). - The pins of the battery connector are connected to battery pins of the PMIC. - The power pins of the microUSB are connected to load pins of the PMIC. - The pins of the LED of Charging are connected to LED pins of the PMIC. ------------ EEPROM: ------------ Part Number: AT24C64 Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/AT24C64.eeprom.pdf Connections: - The EEPROM pins are connected to I2C pins of the EOMA-68. ------------------ Accelerometer: ------------------ Part Number: MXC6225XU Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/MXC6225XU.pdf Connections: - The Accelerometer pins are connected to I2C pins of the EOMA-68. - The Accelerometer is connected to a GPIO of the STM32F microcontroller (accelerometer IRQ). ------------ MicroSD: ------------ Part Number: MM027S020R Datasheet: http://hands.com/~lkcl/eoma/allwinner/litkconn_MICRO%20SD%20PUSH-PUSH%20A.pdf Connections: - The MicroSD pins are connected to GPIO pins of the EOMA-68. - The MicroSD is connected to a GPIO of the STM32F microcontroller (for MicroSD "detect"). --------------- Power Button: --------------- The Power Button is a generic button with click Connections: - The Power Button is connected to 43 POWER# of EOMA-68. ----------------- Audio Jack: ----------------- Part Number: PJ-3545-5L1G Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/PJ-3543-L6G%20Model%20(1).pdf Connections: - The pins of the Audio Jack are connected to USB Audio Controller. ---------------- Speaker (x2): ---------------- We have not yet selected a part number (a generic Speaker (x2)). Connections: - The speaker pins are connected to Audio Amplifier pins (x2). ---------------------- Audio Amplifier: ---------------------- Part Number: UTC2822D Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/YW-UTC2822D_C.pdf y http://pdf.datasheetcatalog.com/datasheets/90/492970_DS.pdf Connections: - The Audio Amplifier is connected to the audio output that goes from the USB Audio Controller to Audio jack. - The speaker pins are connected to Audio Amplifier pins (x2). -------------- Microphone: -------------- We have not yet selected a part number (a generic Microphone). Connections: - The Microphone pins are connected to USB Audio Controller. -------------------------- USB Audio Controller: -------------------------- Part Number: CM108AH Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/CM108_DataSheet_v1.6.pdf Connections: - The USB Audio Controller is connected to USB HUB. - The USB Audio Controller is connected to a GPIO of the STM32F microcontroller (to alter volume on headphone-out). - The Microphone pins are connected to USB Audio Controller. - The pins of the Audio Jack are connected to USB Audio Controller. ------------- WIFI USB: ------------- Part Number: CCandC WM-294 1T1R Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/WM-294_module-V2.2%28PCB%20v%20C%29.pdf Connections: - The Wifi USB pins are connected to USB HUB. ---------------- Bluetooth USB: ---------------- The Bluetooth USB part number has not yet been chosen, even so, is a generic BT, so the onnection/power would be similar to the WIFI. Connections: - The BT USB pins are connected to USB HUB. ---------------- USB Host 2.0: ---------------- The USB Host 2.0 part number has not yet been chosen, even so, is a generic USB Host 2.0, so the connection/power would be similar to the WIFI. Connections: - The USB Host 2.0 pins are connected to USB HUB. ---------------- USB HUB: ---------------- Part Number: FE1.1s Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0).pdf Connections: - The USB HUB is connected to 1st USB pins of the EOMA-68. - The USB Host 2.0 pins are connected to USB HUB. - The BT USB pins are connected to USB HUB. - The Wifi USB pins are connected to USB HUB. - The USB Audio Controller is connected to USB HUB. ------------------------ 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). Connections: - The Digital Button is connected to a GPIO of the STM32F microcontroller (x17). --------------------------- 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). Part Number (potentiometer): Panasonic EVA-W7NR04B34 Datasheet: http://www.digikey.com/product-detail/en/EVA-W7NR04B34/P13569-ND/1135944 Connections: - The potentiometer pins are connected to an ADC of the STM32F microcontroller (x2). ----------------- Joystick (x2): ----------------- Part Number: CTS 254TA103B50B-ND Datasheet: http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/1755918 Connections: - The analog pins of the Joystick are connected to 2 ADCs of the STM32F microcontroller (x2). - The digital pin of the Joystick is connected to a GPIO of the STM32F microcontroller (x2). -------------------- Microcontroller: -------------------- Part Number: STM32F072xx (we have not yet chosen a specific part number). Datasheet: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/programming_manual/DM00051352.pdf http://www.st.com/web/en/resource/technical/document/datasheet/DM00090510.pdf y http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF259717 Connections: - The STM32F is connected to 2nd USB pins of the EOMA-68. - The analog pins of the Joystick are connected to 2 ADCs of the STM32F microcontroller (x2). - The digital pin of the Joystick is connected to a GPIO of the STM32F microcontroller (x2). - The potentiometer pins are connected to an ADC of the STM32F microcontroller (x2). - The Digital Button is connected to a GPIO of the STM32F microcontroller (x17). - The USB Audio Controller is connected to a GPIO of the STM32F microcontroller (to alter volume on headphone-out). - The MicroSD is connected to a GPIO of the STM32F microcontroller (for MicroSD "detect"). - The Accelerometer is connected to a GPIO of the STM32F microcontroller (accelerometer IRQ). - The PMIC are connected to a GPIO of the STM32F microcontroller (IRQ-OUT of AXP209). - The display is connected to GPIO of the STM32F for power-up of LCD. From lkcl at lkcl.net Fri Sep 5 12:01:55 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Sep 2014 12:01:55 +0100 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 11:56 AM, Miguel Garcia wrote: > I appreciate you analyze the block diagram. the diagram is out-of-date it references ADC ICs and doesn't have an STM32F072 on it also could you send the link to the "raw" image in future rather than the one which has advertising on it, it is deceptive in that there is a "close" button in the top right which, instead of *being* a close, takes you to a link. as i am in a secure environment this has caused an unauthorised security breach, so please only send the link to the "raw" image. l. From gacuest at gmail.com Fri Sep 5 12:18:14 2014 From: gacuest at gmail.com (Miguel Garcia) Date: Fri, 5 Sep 2014 13:18:14 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: Oh, shit. I forgot to update the image. The new link: http://i.imgur.com/sN2xAgA.png Thanks. From maillist_arm-netbook at aross.me Fri Sep 5 12:19:53 2014 From: maillist_arm-netbook at aross.me (Alexander Stephen Thomas Ross) Date: Fri, 05 Sep 2014 12:19:53 +0100 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: <54099C59.9040903@aross.me> you can dump things here: ftp://sharedwriteaccess:0Sharedwriteaccess at ftp.george.the-petries.co.uk/eoma/tmp for tmp files put in this tmp dir for longer term files put them in the dir above. if a file is more that 1gb please treat it as short term upload. the webhost doesn't like all these gb's I'm using up. read access via http: http://aross.me/shared-write-access/eoma From gacuest at gmail.com Fri Sep 5 12:30:33 2014 From: gacuest at gmail.com (Miguel Garcia) Date: Fri, 5 Sep 2014 13:30:33 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <54099C59.9040903@aross.me> References: <54099C59.9040903@aross.me> Message-ID: 2014-09-05 13:19 GMT+02:00 Alexander Stephen Thomas Ross : > you can dump things here: > ftp://sharedwriteaccess:0Sharedwriteaccess at ftp.george.the-petries.co.uk/eoma/tmp > > for tmp files put in this tmp dir for longer term files put them in the > dir above. if a file is more that 1gb please treat it as short term > upload. the webhost doesn't like all these gb's I'm using up. > > > read access via http: > http://aross.me/shared-write-access/eoma Thanks! The link: http://george.the-petries.co.uk/shared-write-access/eoma/Block%20Diagram%20Console%201.0.png From lkcl at lkcl.net Fri Sep 5 12:48:54 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Sep 2014 12:48:54 +0100 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: there are two EINT lines on EOMA68. i suggest that one of them be connected to the AXP209, and the other to the STM32F072, although because there are only 2 this leaves some slight issue with the touchpanel to resolve (in linux kernel source, which will need modification). the problem is this: things like the touchpanel it is fairly essential (because you want to wake up the entire device based on an EINT) to have external interrupt. one alternative to modifying the linux kernel source is to have a NAND (NOR?) IC multiplexing multiple IRQ lines from various peripheral ICs onto the one EINT line. another alternative is to wire the AXP209 to the STM32F (on one of its GPIOs, then put that into EINT mode), then have the STM32F software generate a simple GPIO pull-up out to one of the EOMA68 EINTs. so instead of doing the multiplexing using a NAND (NOR) gate IC, you do it in software (firmware) instead. then you can do whatever you want, without modifying any linux kernel source. so, you need to identify which devices have IRQ outputs. i count these: * Accelerometer * Touch panel * AXP209 * STM32F072xx * MicroSD * Headphone detect all of these _should_ be connected to (generate) EINTs... but there are only 2 EINTs available... * analog joysticks are exactly that, they always generate data so there is no concept of "IRQ" * power button is connected to the AXP209 so the AXP209 does the "IRQ" * Buttons are converted to USB HID (keyboard) events via the STM32F072 in software... anything else? l. From lkcl at lkcl.net Fri Sep 5 12:52:33 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Sep 2014 12:52:33 +0100 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 12:18 PM, Miguel Garcia wrote: > The new link: http://i.imgur.com/sN2xAgA.png taaa. btw the MXC6225XU is basically "are we vertical, are we horizontal" it doesn't provide any kind of "tilt" or angle, and it is 2-axis not 3-axis. the data output is either 0x00 or 0xff. you might want to consider a more expensive part from MXC which does range *from* 0x00 to 0xff, and maybe on 3 axes. especially for a games console. l. From gacuest at gmail.com Sat Sep 6 10:37:03 2014 From: gacuest at gmail.com (Miguel Garcia) Date: Sat, 6 Sep 2014 11:37:03 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: 2014-09-05 13:48 GMT+02:00 Luke Kenneth Casson Leighton : > there are two EINT lines on EOMA68. i suggest that one of them be > connected to the AXP209, and the other to the STM32F072, although > because there are only 2 this leaves some slight issue with the > touchpanel to resolve (in linux kernel source, which will need > modification). > > the problem is this: things like the touchpanel it is fairly essential > (because you want to wake up the entire device based on an EINT) to > have external interrupt. > > one alternative to modifying the linux kernel source is to have a NAND > (NOR?) IC multiplexing multiple IRQ lines from various peripheral ICs > onto the one EINT line. > > another alternative is to wire the AXP209 to the STM32F (on one of its > GPIOs, then put that into EINT mode), then have the STM32F software > generate a simple GPIO pull-up out to one of the EOMA68 EINTs. > > so instead of doing the multiplexing using a NAND (NOR) gate IC, you > do it in software (firmware) instead. > > then you can do whatever you want, without modifying any linux kernel source. Thanks. And, what is your recommendation? > * Headphone detect What is the INT/IRQ pin here? Thanks. From lkcl at lkcl.net Sat Sep 6 17:39:22 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Sep 2014 17:39:22 +0100 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: On Sat, Sep 6, 2014 at 10:37 AM, Miguel Garcia wrote: > 2014-09-05 13:48 GMT+02:00 Luke Kenneth Casson Leighton : >> there are two EINT lines on EOMA68. i suggest that one of them be >> connected to the AXP209, and the other to the STM32F072, although >> because there are only 2 this leaves some slight issue with the >> touchpanel to resolve (in linux kernel source, which will need >> modification). >> >> the problem is this: things like the touchpanel it is fairly essential >> (because you want to wake up the entire device based on an EINT) to >> have external interrupt. >> >> one alternative to modifying the linux kernel source is to have a NAND >> (NOR?) IC multiplexing multiple IRQ lines from various peripheral ICs >> onto the one EINT line. >> >> another alternative is to wire the AXP209 to the STM32F (on one of its >> GPIOs, then put that into EINT mode), then have the STM32F software >> generate a simple GPIO pull-up out to one of the EOMA68 EINTs. >> >> so instead of doing the multiplexing using a NAND (NOR) gate IC, you >> do it in software (firmware) instead. >> >> then you can do whatever you want, without modifying any linux kernel source. > > Thanks. > > And, what is your recommendation? i'd suggest multiplexing them all via the STM32F07xx onto one pin. this will mean that all drivers which use that pin will all receive interrupts whenever any of the other devices generate one but that is much more preferable to polling >> * Headphone detect > > What is the INT/IRQ pin here? i don't understand the question. the headphone detect pin is the INT/IRQ pin. l. > Thanks. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From zink at hexatux.org Mon Sep 8 10:33:45 2014 From: zink at hexatux.org (Richard Zink) Date: Mon, 8 Sep 2014 09:33:45 +0000 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: <20140908093345.68f3e83b@hexatux.org> On Fri, 5 Sep 2014 12:52:33 +0100 Luke Kenneth Casson Leighton wrote: > aaa. btw the MXC6225XU is basically "are we vertical, are we > horizontal" it doesn't provide any kind of "tilt" or angle, and it is > 2-axis not 3-axis. the data output is either 0x00 or 0xff. In fact it *gives* you an output for X and Y (Which is from -128 to 127). Have a look at page 9. It just gives you an additional register with some bits which will show you the basic orientation and if the devices has been shaken. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From lkcl at lkcl.net Mon Sep 8 10:23:02 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Sep 2014 11:23:02 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <20140908093345.68f3e83b@hexatux.org> References: <20140908093345.68f3e83b@hexatux.org> Message-ID: On Mon, Sep 8, 2014 at 11:33 AM, Richard Zink wrote: > On Fri, 5 Sep 2014 12:52:33 +0100 > Luke Kenneth Casson Leighton wrote: > >> aaa. btw the MXC6225XU is basically "are we vertical, are we >> horizontal" it doesn't provide any kind of "tilt" or angle, and it is >> 2-axis not 3-axis. the data output is either 0x00 or 0xff. > > > In fact it *gives* you an output for X and Y (Which is from -128 to 127). i have the prototype first tablet, i tested the MXC6225 which was installed on it: the only values given were 0x00 and 0xff. the MXC6225 is basically for ultra-low-cost devices where all you need to know is: "is this device upright or is it on its side, yes or no". a games console may wish to use an accelerometer (or tilt system) where the motion of the device - a small tip to the left - is used in essence as a mouse or analog joystick. i think there's a gnu/linux game where you have a ball-bearing that you steer through obstacles by moving the mouse to "tilt" a surface. the MXC6225 would be completely and utterly inadequate for such a game. l. From lkcl at lkcl.net Mon Sep 8 10:38:58 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Sep 2014 11:38:58 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: <20140908093345.68f3e83b@hexatux.org> Message-ID: On Mon, Sep 8, 2014 at 11:23 AM, Luke Kenneth Casson Leighton wrote: > On Mon, Sep 8, 2014 at 11:33 AM, Richard Zink wrote: >> On Fri, 5 Sep 2014 12:52:33 +0100 >> Luke Kenneth Casson Leighton wrote: >> >>> aaa. btw the MXC6225XU is basically "are we vertical, are we >>> horizontal" it doesn't provide any kind of "tilt" or angle, and it is >>> 2-axis not 3-axis. the data output is either 0x00 or 0xff. >> >> >> In fact it *gives* you an output for X and Y (Which is from -128 to 127). http://www.memsic.com/accelerometers/MXC6226XU this is one that gives values from -128 to 127 - the MXC6226 not the MXC6225. l. From zink at hexatux.org Mon Sep 8 13:27:48 2014 From: zink at hexatux.org (Richard Zink) Date: Mon, 8 Sep 2014 12:27:48 +0000 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: <20140908093345.68f3e83b@hexatux.org> Message-ID: <20140908122748.16ce8857@hexatux.org> On Mon, 8 Sep 2014 11:38:58 +0200 Luke Kenneth Casson Leighton wrote: > On Mon, Sep 8, 2014 at 11:23 AM, Luke Kenneth Casson Leighton > wrote: > > On Mon, Sep 8, 2014 at 11:33 AM, Richard Zink wrote: > >> On Fri, 5 Sep 2014 12:52:33 +0100 > >> Luke Kenneth Casson Leighton wrote: > >> > >>> aaa. btw the MXC6225XU is basically "are we vertical, are we > >>> horizontal" it doesn't provide any kind of "tilt" or angle, and it is > >>> 2-axis not 3-axis. the data output is either 0x00 or 0xff. > >> > >> > >> In fact it *gives* you an output for X and Y (Which is from -128 to 127). > > http://www.memsic.com/accelerometers/MXC6226XU > > this is one that gives values from -128 to 127 - the MXC6226 not the MXC6225. Yes, the MXC6225 should give you the correct values for acceleration, which is 64 LSB/g and a measuring range of +/- 2g. I don't have a device using this chip, so I need to rely on the datasheet ( http://hands.com/~lkcl/eoma/kde_tablet/MXC6225XU.pdf / http://www.memsic.com/userfiles/files/Datasheets/Accelerometer-Datasheets/MXC622xXC-Rev-A_Data_Sheet.pdf ) If I'm wrong with the datasheet, please point me to the correct one. - Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From lkcl at lkcl.net Mon Sep 8 12:30:47 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Sep 2014 13:30:47 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <20140908122748.16ce8857@hexatux.org> References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> Message-ID: On Mon, Sep 8, 2014 at 2:27 PM, Richard Zink wrote: > On Mon, 8 Sep 2014 11:38:58 +0200 > Luke Kenneth Casson Leighton wrote: >> On Mon, Sep 8, 2014 at 11:23 AM, Luke Kenneth Casson Leighton >> wrote: >> > On Mon, Sep 8, 2014 at 11:33 AM, Richard Zink wrote: >> >> On Fri, 5 Sep 2014 12:52:33 +0100 >> >> Luke Kenneth Casson Leighton wrote: >> >> >> >>> aaa. btw the MXC6225XU is basically "are we vertical, are we >> >>> horizontal" it doesn't provide any kind of "tilt" or angle, and it is >> >>> 2-axis not 3-axis. the data output is either 0x00 or 0xff. >> >> >> >> >> >> In fact it *gives* you an output for X and Y (Which is from -128 to 127). >> >> http://www.memsic.com/accelerometers/MXC6226XU >> >> this is one that gives values from -128 to 127 - the MXC6226 not the MXC6225. > > Yes, the MXC6225 should give you the correct values for acceleration, a-a-ahh nooo, it *doesn't*. it does *not* give *any* values for acceleration, the MXC6225 is a *tilt* sensor. > which is 64 LSB/g and a measuring range of +/- 2g. > I don't have a device using this chip, i do. i read the data using python-i2c. it gave either 0x00 or 0xff. that was all. i did not see any changes in the values read from the device when either shaking it or rotating it slightly. > so I need to rely on the datasheet > http://www.memsic.com/userfiles/files/Datasheets/Accelerometer-Datasheets/MXC622xXC-Rev-A_Data_Sheet.pdf ) > If I'm wrong with the datasheet, please point me to the correct one. ok that's a general-purpose datasheet covering the *family* of MXC622x products (landing patterns, I2C communication protocols etc.). so it covers *both* the MXC6225 *and* the MXC6226 which have *different* capabilities. from what i can see, the 6225 has less capabilities than the MXC6226. does anyone know where the specific datasheets are so that this can be made absolutely clear? the right IC needs to be found. l. From zink at hexatux.org Mon Sep 8 15:09:32 2014 From: zink at hexatux.org (Richard Zink) Date: Mon, 8 Sep 2014 14:09:32 +0000 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> Message-ID: <20140908140932.0879fe41@hexatux.org> On Mon, 8 Sep 2014 13:30:47 +0200 Luke Kenneth Casson Leighton wrote: > ok that's a general-purpose datasheet covering the *family* of > MXC622x products (landing patterns, I2C communication protocols etc.). > > so it covers *both* the MXC6225 *and* the MXC6226 which have > *different* capabilities. from what i can see, the 6225 has less > capabilities than the MXC6226. > > does anyone know where the specific datasheets are so that this can > be made absolutely clear? the right IC needs to be found. Oh, now I understand. Sorry for worrying you with that nonesense. You can simply forget anything I said about that ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From lkcl at lkcl.net Mon Sep 8 13:11:51 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Sep 2014 14:11:51 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <20140908140932.0879fe41@hexatux.org> References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> <20140908140932.0879fe41@hexatux.org> Message-ID: On Mon, Sep 8, 2014 at 4:09 PM, Richard Zink wrote: > On Mon, 8 Sep 2014 13:30:47 +0200 > Luke Kenneth Casson Leighton wrote: > >> ok that's a general-purpose datasheet covering the *family* of >> MXC622x products (landing patterns, I2C communication protocols etc.). >> >> so it covers *both* the MXC6225 *and* the MXC6226 which have >> *different* capabilities. from what i can see, the 6225 has less >> capabilities than the MXC6226. >> >> does anyone know where the specific datasheets are so that this can >> be made absolutely clear? the right IC needs to be found. > > Oh, now I understand. Sorry for worrying you with that nonesense. nono, i was asking you if you could double-check :) From zink at hexatux.org Mon Sep 8 15:41:51 2014 From: zink at hexatux.org (Richard Zink) Date: Mon, 8 Sep 2014 14:41:51 +0000 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> <20140908140932.0879fe41@hexatux.org> Message-ID: <20140908144151.53dfe873@hexatux.org> On Mon, 8 Sep 2014 14:11:51 +0200 Luke Kenneth Casson Leighton wrote: > >> ok that's a general-purpose datasheet covering the *family* of > >> MXC622x products (landing patterns, I2C communication protocols etc.). > >> > >> so it covers *both* the MXC6225 *and* the MXC6226 which have > >> *different* capabilities. from what i can see, the 6225 has less > >> capabilities than the MXC6226. > >> > >> does anyone know where the specific datasheets are so that this can > >> be made absolutely clear? the right IC needs to be found. > > > > Oh, now I understand. Sorry for worrying you with that nonesense. > > nono, i was asking you if you could double-check :) Will try to get the proper datasheet in the evening and do a check then. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From lkcl at lkcl.net Mon Sep 8 14:29:59 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Sep 2014 15:29:59 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <20140908144151.53dfe873@hexatux.org> References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> <20140908140932.0879fe41@hexatux.org> <20140908144151.53dfe873@hexatux.org> Message-ID: On Mon, Sep 8, 2014 at 4:41 PM, Richard Zink wrote: > On Mon, 8 Sep 2014 14:11:51 +0200 > Luke Kenneth Casson Leighton wrote: > >> >> ok that's a general-purpose datasheet covering the *family* of >> >> MXC622x products (landing patterns, I2C communication protocols etc.). >> >> >> >> so it covers *both* the MXC6225 *and* the MXC6226 which have >> >> *different* capabilities. from what i can see, the 6225 has less >> >> capabilities than the MXC6226. >> >> >> >> does anyone know where the specific datasheets are so that this can >> >> be made absolutely clear? the right IC needs to be found. >> > >> > Oh, now I understand. Sorry for worrying you with that nonesense. >> >> nono, i was asking you if you could double-check :) > > Will try to get the proper datasheet in the evening and do a check then. star. > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From zink at hexatux.org Tue Sep 9 10:10:35 2014 From: zink at hexatux.org (Richard Zink) Date: Tue, 9 Sep 2014 09:10:35 +0000 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> <20140908140932.0879fe41@hexatux.org> <20140908144151.53dfe873@hexatux.org> Message-ID: <20140909091035.6496aa16@hexatux.org> On Mon, 8 Sep 2014 15:29:59 +0200 Luke Kenneth Casson Leighton wrote: > > Will try to get the proper datasheet in the evening and do a check then. > > star. Datasheets: http://www.memsic.com/userfiles/files/Datasheets/Accelerometer-Datasheets/MXC6226XU_Rev_1_3.pdf http://media.digikey.com/pdf/Data%20Sheets/MEMSIC%20PDFs/MXC6225XU.pdf I've checked both datasheets, but can't find any difference between the two ICs. The technical specifications are the same (the 6226 is a bit more detailed), but both tell the same information. Your output of python-i2c is "safe"? Checked it with a different IC? Maybe we should ask the manufacturer if the values are right or if the IC gives a floating output between -128 to 127. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From lkcl at lkcl.net Tue Sep 9 08:41:11 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Sep 2014 09:41:11 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <20140909091035.6496aa16@hexatux.org> References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> <20140908140932.0879fe41@hexatux.org> <20140908144151.53dfe873@hexatux.org> <20140909091035.6496aa16@hexatux.org> Message-ID: On Tue, Sep 9, 2014 at 11:10 AM, Richard Zink wrote: > On Mon, 8 Sep 2014 15:29:59 +0200 > Luke Kenneth Casson Leighton wrote: > >> > Will try to get the proper datasheet in the evening and do a check then. >> >> star. > > Datasheets: > http://www.memsic.com/userfiles/files/Datasheets/Accelerometer-Datasheets/MXC6226XU_Rev_1_3.pdf > http://media.digikey.com/pdf/Data%20Sheets/MEMSIC%20PDFs/MXC6225XU.pdf > > I've checked both datasheets, but can't find any difference between the two ICs. > The technical specifications are the same (the 6226 is a bit more detailed), but > both tell the same information. bizarre. > Your output of python-i2c is "safe"? yeah. > Checked it with a different IC? no i only had the one. > Maybe we should ask the manufacturer if the values are right or if the IC gives a > floating output between -128 to 127. ... or find an IC from a company with a better datasheet! l. From henrik at henriknordstrom.net Tue Sep 9 19:06:21 2014 From: henrik at henriknordstrom.net (Henrik =?ISO-8859-1?Q?Nordstr=F6m?=) Date: Tue, 09 Sep 2014 20:06:21 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> Message-ID: <1410285981.11328.3.camel@localhost> mån 2014-09-08 klockan 13:30 +0200 skrev Luke Kenneth Casson Leighton: > a-a-ahh nooo, it *doesn't*. it does *not* give *any* values for > acceleration, the MXC6225 is a *tilt* sensor.' >From what I understand the whole series is primarily a tilt sensor, with the only difference between the chip numbers being the I²C address they respond to. datasheets says those two registers is the instaneous orientation reading, but none of the suggested applications uses more than the status tilt-orientation & shake bits. I doubt this series of accelerometers are intended for any detailed readings of orientation as needed for making a air mouse / game controller type application. Regards Henrik From lkcl at lkcl.net Tue Sep 9 21:03:43 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Sep 2014 22:03:43 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: <1410285981.11328.3.camel@localhost> References: <20140908093345.68f3e83b@hexatux.org> <20140908122748.16ce8857@hexatux.org> <1410285981.11328.3.camel@localhost> Message-ID: On Tue, Sep 9, 2014 at 8:06 PM, Henrik Nordström wrote: > mån 2014-09-08 klockan 13:30 +0200 skrev Luke Kenneth Casson Leighton: > >> a-a-ahh nooo, it *doesn't*. it does *not* give *any* values for >> acceleration, the MXC6225 is a *tilt* sensor.' > > From what I understand the whole series is primarily a tilt sensor, with > the only difference between the chip numbers being the I²C address they > respond to. > > datasheets says those two registers is the instaneous orientation > reading, but none of the suggested applications uses more than the > status tilt-orientation & shake bits. > > I doubt this series of accelerometers are intended for any detailed > readings of orientation as needed for making a air mouse / game > controller type application. can you recall which manufacturers do something more appropriate? From lkcl at lkcl.net Wed Sep 10 09:54:32 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Sep 2014 10:54:32 +0200 Subject: [Arm-netbook] Operating Systems, CPU Cards, EOMA68 Message-ID: this is triggered mainly by the discussion last month from manuel, i had a bit of time to think and i came up with an idea. if you recall, manuel asked "would it be ok to buy a specific model of CPU card, install an OS that only works with the Games Console?" and the answer was "yes... but you could not call it EOMA68 compliant" so anyway i thought about this a bit and i figured that it makes a lot of sense to have the OS (which really has nothing to do with the CPU Card per se) basically adjust so that it works with whatever it detects... ... in other words, from an end-user perspective, you would buy a Gaming *Card*, or an Work *Card*, or an Android *Card*, or a Photo/Camera *Card* that would have an OS preinstalled which adapts to the base units it's plugged into. i'd be interested to hear people's thoughts on this. l. From gacuest at gmail.com Wed Sep 10 12:32:25 2014 From: gacuest at gmail.com (Miguel Garcia) Date: Wed, 10 Sep 2014 13:32:25 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: 2014-09-05 13:52 GMT+02:00 Luke Kenneth Casson Leighton : > taaa. btw the MXC6225XU is basically "are we vertical, are we > horizontal" it doesn't provide any kind of "tilt" or angle, and it is > 2-axis not 3-axis. the data output is either 0x00 or 0xff. you might > want to consider a more expensive part from MXC which does range > *from* 0x00 to 0xff, and maybe on 3 axes. > > especially for a games console. Is Bosch BMA250 a better alternative? Datasheet: http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/BST-BMA250-DS002-05.pdf Thanks. From lkcl at lkcl.net Wed Sep 10 12:47:08 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Sep 2014 13:47:08 +0200 Subject: [Arm-netbook] Block Diagram EOMA-68 Handheld Games Console In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 1:32 PM, Miguel Garcia wrote: > 2014-09-05 13:52 GMT+02:00 Luke Kenneth Casson Leighton : >> taaa. btw the MXC6225XU is basically "are we vertical, are we >> horizontal" it doesn't provide any kind of "tilt" or angle, and it is >> 2-axis not 3-axis. the data output is either 0x00 or 0xff. you might >> want to consider a more expensive part from MXC which does range >> *from* 0x00 to 0xff, and maybe on 3 axes. >> >> especially for a games console. > > Is Bosch BMA250 a better alternative? yes very much so. > Datasheet: http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/BST-BMA250-DS002-05.pdf which says it's designed for games consoles, so yes. l. From gacuest at gmail.com Wed Sep 10 13:05:51 2014 From: gacuest at gmail.com (Miguel Garcia) Date: Wed, 10 Sep 2014 14:05:51 +0200 Subject: [Arm-netbook] Operating Systems, CPU Cards, EOMA68 In-Reply-To: References: Message-ID: 2014-09-10 10:54 GMT+02:00 Luke Kenneth Casson Leighton : > this is triggered mainly by the discussion last month from manuel, i > had a bit of time to think and i came up with an idea. > > if you recall, manuel asked "would it be ok to buy a specific model of > CPU card, install an OS that only works with the Games Console?" and > the answer was "yes... but you could not call it EOMA68 compliant" > > so anyway i thought about this a bit and i figured that it makes a lot > of sense to have the OS (which really has nothing to do with the CPU > Card per se) basically adjust so that it works with whatever it > detects... > > ... in other words, from an end-user perspective, you would buy a > Gaming *Card*, or an Work *Card*, or an Android *Card*, or a > Photo/Camera *Card* that would have an OS preinstalled which adapts to > the base units it's plugged into. > > i'd be interested to hear people's thoughts on this. I think it is best to do EOMA-68 compatible with all devices. Those devices that need special software, which also are compatible with EOMA-68 and with own cards (a renamed EOMA-68). The other way, you have to define the standard controls for all consoles compatible with the Gaming *Card*. From lkcl at lkcl.net Wed Sep 10 13:57:08 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Sep 2014 14:57:08 +0200 Subject: [Arm-netbook] Operating Systems, CPU Cards, EOMA68 In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 2:05 PM, Miguel Garcia wrote: > 2014-09-10 10:54 GMT+02:00 Luke Kenneth Casson Leighton : >> this is triggered mainly by the discussion last month from manuel, i >> had a bit of time to think and i came up with an idea. >> >> if you recall, manuel asked "would it be ok to buy a specific model of >> CPU card, install an OS that only works with the Games Console?" and >> the answer was "yes... but you could not call it EOMA68 compliant" >> >> so anyway i thought about this a bit and i figured that it makes a lot >> of sense to have the OS (which really has nothing to do with the CPU >> Card per se) basically adjust so that it works with whatever it >> detects... >> >> ... in other words, from an end-user perspective, you would buy a >> Gaming *Card*, or an Work *Card*, or an Android *Card*, or a >> Photo/Camera *Card* that would have an OS preinstalled which adapts to >> the base units it's plugged into. >> >> i'd be interested to hear people's thoughts on this. > > I think it is best to do EOMA-68 compatible with all devices. Those > devices that need special software, which also are compatible with > EOMA-68 and with own cards (a renamed EOMA-68). > > The other way, you have to define the standard controls for all > consoles compatible with the Gaming *Card*. taking the Gaming "Card" as a very good example: yes. exactly. ok, that's one possibility. it would help if the Gaming "OS" (or the game itself) detected the various different capabilities of the base unit(s) it was plugged into. just as with existing linux games where you install a game and you go in and reconfigure the controls to your preferences, i see no reason to consider this to be any different from that scenario _except_ that: a) swapping the entire computer between base units might be made easier if the controls preferences were either saved on a per-base-unit per-game basis or b) a reasonable set of defaults (keys, mouse, touch, joystick) was set up which would reasonably be expected to work across a large number of base units and c) there are going to be some games that simply cannot be played well (or at all) on certain base units (games designed to be used exclusively with touch panels) and well... being philosophical about that, they should unplug the CPU Card and plug it into a base in which that game _will_ work. just out of curiosity, are you intending to write games from scratch for this unit or to use pre-existing games software and install that? l. From lkcl at lkcl.net Mon Sep 15 14:53:47 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 15 Sep 2014 15:53:47 +0200 Subject: [Arm-netbook] eoma68-a20 v2.2 PCBs arrived Message-ID: ok i haven't tested them yet - wits tech kindly ran a preliminary check - they arrived over the weekend. they have at least been booted up from USB-OTG and an OS installed, so it is known that RAM, CPU, PMIC, NAND, HDMI and USB-OTG all operate correctly. i will be able to fully test the rest of the functionality once the micro-desktop PCBs are assembled, which should be another month or so. l. From maillist_arm-netbook at aross.me Tue Sep 16 20:44:15 2014 From: maillist_arm-netbook at aross.me (Alexander Stephen Thomas Ross) Date: Tue, 16 Sep 2014 20:44:15 +0100 Subject: [Arm-netbook] eoma68-a20 v2.2 PCBs arrived In-Reply-To: References: Message-ID: <5418930F.50708@aross.me> thanks for the update. :) From joem at martindale-electric.co.uk Thu Sep 18 08:30:03 2014 From: joem at martindale-electric.co.uk (joem) Date: Thu, 18 Sep 2014 07:30:03 +0000 Subject: [Arm-netbook] PC Duino nano out Message-ID: <1411025402.10400.5.camel@jm-desktop> PC Duino nano out. Allwinner A20 dual core. Ethernet 10M/100M/1Gbps, SATA, Ubuntu 12.04 http://www.cnx-software.com/2014/09/18/39-pcduino3-nano-arm-linux-development-board-features-hdmi-sata-gigabit-ethernet-arduino-headers/ http://www.pcduino.com/pcduino3nano/ At $39 very nice me thinks. From lkcl at lkcl.net Thu Sep 18 09:45:26 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Sep 2014 10:45:26 +0200 Subject: [Arm-netbook] PC Duino nano out In-Reply-To: <1411025402.10400.5.camel@jm-desktop> References: <1411025402.10400.5.camel@jm-desktop> Message-ID: On Thu, Sep 18, 2014 at 9:30 AM, joem wrote: > PC Duino nano out. > > Allwinner A20 dual core. > > Ethernet 10M/100M/1Gbps, SATA, Ubuntu 12.04 > > http://www.cnx-software.com/2014/09/18/39-pcduino3-nano-arm-linux-development-board-features-hdmi-sata-gigabit-ethernet-arduino-headers/ > > http://www.pcduino.com/pcduino3nano/ > > At $39 very nice me thinks. wow, pretty awesome. 1GB RAM but that's ok. arduino compatible headers so getting the benefit of all the existing shields. great product. l. From joem at martindale-electric.co.uk Fri Sep 26 08:11:09 2014 From: joem at martindale-electric.co.uk (joem) Date: Fri, 26 Sep 2014 07:11:09 +0000 Subject: [Arm-netbook] 3D printable laptop (raspberry pi project) Message-ID: <1411715469.18978.8.camel@jm-desktop> 3D printable laptop (raspberry pi project) out: http://liliputing.com/2014/09/pi-top-3d-printable-raspberry-pi-laptop-crowdfunding.html Its going for crowd funding. Close to what I had in mind for a 3D printed EOMA netbook but a little more flair needed with the case styling and more features rather than just a bland copy of a box with a lid. Better get a move on with openscad scripting Luke :) Things are moving on fast.. This PC also out and it seems very fast compared to previous ARM: http://liliputing.com/2014/09/mk902-ii-le-tiny-ubuntu-pc-rockchip-rk3288-cpu.html (No sata on it as far as I can tell.) From lkcl at lkcl.net Fri Sep 26 09:55:55 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 26 Sep 2014 10:55:55 +0200 Subject: [Arm-netbook] 3D printable laptop (raspberry pi project) In-Reply-To: <1411715469.18978.8.camel@jm-desktop> References: <1411715469.18978.8.camel@jm-desktop> Message-ID: On Fri, Sep 26, 2014 at 9:11 AM, joem wrote: > 3D printable laptop (raspberry pi project) out: > > http://liliputing.com/2014/09/pi-top-3d-printable-raspberry-pi-laptop-crowdfunding.html > > Its going for crowd funding. > > Close to what I had in mind for a 3D printed EOMA netbook > but a little more flair needed with the case styling > and more features rather than just a bland copy of a > box with a lid. woo! i shall copy their 3D designs and modify them :) > Better get a move on with openscad scripting Luke :) well i am more than happy to contact them and/or wait until they're done > Things are moving on fast.. > This PC also out and it seems very fast compared to previous ARM: > http://liliputing.com/2014/09/mk902-ii-le-tiny-ubuntu-pc-rockchip-rk3288-cpu.html > (No sata on it as far as I can tell.) > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From joem at martindale-electric.co.uk Fri Sep 26 13:50:15 2014 From: joem at martindale-electric.co.uk (joem) Date: Fri, 26 Sep 2014 12:50:15 +0000 Subject: [Arm-netbook] 3D printable laptop (raspberry pi project) In-Reply-To: References: <1411715469.18978.8.camel@jm-desktop> Message-ID: <1411735814.6347.46.camel@jm-desktop> On Fri, 2014-09-26 at 10:55 +0200, Luke Kenneth Casson Leighton wrote: > On Fri, Sep 26, 2014 at 9:11 AM, joem wrote: > > 3D printable laptop (raspberry pi project) out: > > > > http://liliputing.com/2014/09/pi-top-3d-printable-raspberry-pi-laptop-crowdfunding.html > > > > Its going for crowd funding. > > > > Close to what I had in mind for a 3D printed EOMA netbook > > but a little more flair needed with the case styling > > and more features rather than just a bland copy of a > > box with a lid. > > woo! i shall copy their 3D designs and modify them :) More flair - the lid which houses the LCD can have 2 doors/flaps that open out and reveal 2 x surface area solar panel. The other side of these flaps face the user and could be used to mount a mobile phone on the left and say phablet on the right. So now you got phone on the left screen, Linux computer on the mid screen and phablet on the right screen. The keyboard needs to be bluetooth and custom built so that it can store 3 pairing values - one for the tablet, one for the Linux computer, one for the phablet. Change the pairing by pressing buttons on the keyboard. Then you can talk down the phone, whilst watching movie on phablet on right side and compile some code with Linux computer in between. From maillist_arm-netbook at aross.me Sun Sep 28 12:35:44 2014 From: maillist_arm-netbook at aross.me (Alexander Stephen Thomas Ross) Date: Sun, 28 Sep 2014 12:35:44 +0100 Subject: [Arm-netbook] What Linux Users Should Know About Open Hardware - Datamation Message-ID: <5427F290.6030304@aross.me> http://www.datamation.com/open-source/what-linux-users-should-know-about-open-hardware-1.html From lkcl at lkcl.net Sun Sep 28 23:18:58 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Sep 2014 00:18:58 +0200 Subject: [Arm-netbook] What Linux Users Should Know About Open Hardware - Datamation In-Reply-To: <5427F290.6030304@aross.me> References: <5427F290.6030304@aross.me> Message-ID: good one thanks alex On Sun, Sep 28, 2014 at 1:35 PM, Alexander Stephen Thomas Ross wrote: > http://www.datamation.com/open-source/what-linux-users-should-know-about-open-hardware-1.html > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From maillist_arm-netbook at aross.me Mon Sep 29 03:36:26 2014 From: maillist_arm-netbook at aross.me (Alexander Stephen Thomas Ross) Date: Mon, 29 Sep 2014 03:36:26 +0100 Subject: [Arm-netbook] What Linux Users Should Know About Open Hardware - Datamation In-Reply-To: References: <5427F290.6030304@aross.me> Message-ID: <5428C5AA.3050402@aross.me> thank http://techrights.org/?stories :) From maillist_arm-netbook at aross.me Mon Sep 29 16:19:56 2014 From: maillist_arm-netbook at aross.me (Alexander Stephen Thomas Ross) Date: Mon, 29 Sep 2014 16:19:56 +0100 Subject: [Arm-netbook] Existing Projects, Products That Could Be A EOMA-68 Device Message-ID: <5429789C.1020209@aross.me> I find my self coming across projects that are using a SOM that I think could have been a eoma-68. all those lost orders that would have made all the difference in getting cards rolling off the production line at a preferable price and into many peoples hands. todays example: https://www.kickstarter.com/projects/modduo/mod-duo-the-limitless-multi-effects-pedal/ From lkcl at lkcl.net Tue Sep 30 14:00:37 2014 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 30 Sep 2014 15:00:37 +0200 Subject: [Arm-netbook] Existing Projects, Products That Could Be A EOMA-68 Device In-Reply-To: <5429789C.1020209@aross.me> References: <5429789C.1020209@aross.me> Message-ID: On Mon, Sep 29, 2014 at 5:19 PM, Alexander Stephen Thomas Ross wrote: > I find my self coming across projects that are using a SOM that I think > could have been a eoma-68. all those lost orders that would have made > all the difference in getting cards rolling off the production line at a > preferable price and into many peoples hands. we need product sales and awareness, first. to get to that phase we need 100% proven and 100% tested products. the products are due back in the next week or so from assembly and can then be tested. so there is a chain of things that need to happen, which are in progress, which, when they have progressed, will mean that these kinds of things you describe will happen. l.