- arm-netbook - Mailman test

identification EEPROM: writable or not?
by Aaron J. Seigo 07 Nov '13

07 Nov '13

hi.. the LAST thread in the saga! perhaps not as fun to read as your average Terry Pratchett novel, but hopefully as or more useful ;) ok, so this thread is about the decision of whether to permit within the EOMA68 spec for the identification EEPROM to be writable. there are three options: a) the ID EEPROM must be writable b) the ID EEPROM must not be writable c) the ID EEPROM may be writable, but this should not be relied on by any software let’s consider each in turn: a) must be writable this option raises quality issues for consumer devices where easy access to the EEPROM may be implicated in a variety of device damaging events. from virus propagation to accidental destruction of the device tree due to user- initiated EEPROM write ... this just isn’t a great option for many mass-market devices. ergo, (a) is not an option. b) must not be writable for generic chassis (including, but not limited to, engineering boards) being able to write to the EEPROM is a requirement. so if the EOMA68 standard says that the EEPROM “must not be writable” then none of those boards can ever be certified as EOMA68 compliant. this will result in specification defying chassis that work with EOMA68 CPU cards, but which aren’t themselves EOMA68 chassis. encouraging such defiance of the standard simply to fulfill completely valid use cases is a great way to lower the value of the standard" "sure, there’s a standard *wink* *wink* but we all know that not all devices *really* follow it." that is a horrible precedence to set in the very first revision of the spec. c) may be writable, but portable software may not rely on this this is a middle ground which allows devices which would be in violation of the standard in the (b) case to remain compliant, while allowing devices which really are best served by (a) to not only be compliant but also avoid having theoretically portable software not performing correctly on them. basically, (c) implies that the EEPROM must be treated as not-writable in the general case. any user actions or software that attemps to write to the EEPROM is classified as non-portable and device-specific, and the EOMA68 would provide zero guarantees as to the expected behaviour in such cases. as this allows for compliant generic chassis *and* mass-market consumer devices, i highly recommend (c) -- Aaron J. Seigo

6 17

defining the eoma68 eeprom usage
by Aaron J. Seigo 06 Nov '13

06 Nov '13

Hi... On the eoma68 spec it says: "The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA-68." My understanding from past threads on the matter is that currently the only specified usage for this by EOMA-68 is a product ID string + device node tree. It would be most useful if there was a definition on the layout. *cough* A defined data structure allowing for future expansion as well as vendor specific additions would be golden. A simple page based system would suffice afaics. Sth like: Address Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data 0x06 val 0x02 Page data Page data would (obviously) be limited to a maximum 64k in size, but that really should not be an issue given the application (and given how much data you can read at a time via i2c_smbus calls). A checksum could be added to the page header if desired to verify the data read in, but that could also be left to the page specific data. I don’t think a checksum is needed for the device ID page, for instance. Page identifiers would be things like: "0x01 Device ID". A simple, sequential page ordering would to make it easy to use a function lookup table to parse the data. Page 0x00 would be a special “there are no more pages” id. The page ID # space could be split in 2 between EOMA68 and vendor, giving 32768 possible page IDs to both (far more than necessary, but 1 byte isn’t enough, and i don’t see any benefit to trying to pack bytes together and bit twiddling on the software side to unpack them). this would have the nice characteristic of any page id with the high bit set to 1 would be a vendor page. The device ID page data definition might look sth like: Size in Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring A set of defined pages would be marked as REQUIRED and standard page IDs would be defined as well. I’d actually recommend this definition to be housed *outside* of the EOMA68 spec so that it can be used more broadly by the open hardware community (where such things seem non-existent) and to keep the EOMA68 spec from becoming too monstrous. This approach would have a number of advantages imo: * quick access to any given page without lots of index overhead (just jump through the page headers) * minimum size is self documenting: all REQUIRED pages (e.g. device ID page) become the minimum size for the EEPROM on the device * It avoids (imho) stupid hard coded lengths; it’s no longer 1985, even in the embedded world people and many/most of the products we’re working on have application class processors, and even the ones with “just” microcontrolers can do a hell of a lot such that hard coded page sizes just don’t make sense * It allows some vendor flexibility I am willing to write a small C library that takes a well formed set of data, parses all the EOMA68 bits and offers nice API to access things like device ID data, keeping implementation details at arms length from applications. I could also provide a tool that takes a descriptor file in a human readable format and converts it into a proper EOMA68 packed structure to be written to an EEPROM. Obviously we need agreement on the above before I do this. Some additional semi-random notes from reading the EOMA68 spec regarding the EEPROM: In the "Start-up procedure” section, it gives the EEPROM address as 0xA2 rather than 0x51. I would recommend not putting the address here, but rather dealing with all those details in the "Requirements for I2C” section and giving the EEPROM a proper name there (e.g. the RID EEPROM, for Required IDentification). In fact, I’d re-org that section entirely to be like: Required Interfaces Rational for interface selections* i2c The "Required IDentification” EEPROM USB SATA ETHERNET RGB/TTL * I would remove all mention of specific vendors here; this is a specification after all, so I’d kill the last para about All Winner and costing. I would also move each of the line items about the interfaces to the section on that interface Thoughts? -- Aaron J. Seigo

8 18

identification EEPROM: device ID and device tree pages
by Aaron J. Seigo 06 Nov '13

06 Nov '13

hi... Purpose: assuming agreement on the DIDS layout, below is a proposed definition for the two pages we currently know we must have: * a device ID page * a device tree page Goals: To standardize the process of identifying a chassis (or any hardware device, for that matter?) and the components/devices on the chassis which can not be discovered reliably through probing. Proposal: Define two DIDS conforming pages, one for identification information and the other for device tree information, and assign them Page Identifiers (PID). Implementation: Name: Device Identification PID: 0x01 Page data layout: Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring Name: Device tree PID: 0x02 Page data consists of a standard “dtb” blob as generated by a device tree compiler (dtc) compliant with the Device Tree standard defined at http://devicetree.org -- Aaron J. Seigo

2 3

identification eeprom: data layout
by Aaron J. Seigo 06 Nov '13

06 Nov '13

hi all, i’m going to try this again in a new thread and with hopefully more clarity. i mixed 4 related topics into one email last time and apparently that doesn’t work here, which is fine. i’ll try again and break this into dedicated threads for each so we can (hopefully) discuss each topic without distraction. this email is about the layout of data on the EEPROM. Purpose: Each chassis needs to ship chassis-specific information such as the vendor and device ID on the identification EEPROM. There must be a defined data structure for that information such that a bootloader/OS loaded on any given CPU card can read it out. Goals: * Appropriate for storage on an EEPROM (low overhead) * Appropriate for access via i2c+smbus * Can be use to store heterogeneous data. Already identified are: * Device and vendor ID * Device tree * Reliable, within the first two constraints, it must involve as few hacks as possible and as many reasonable mechanisms for reliable usage * Extensible, allowing for future expansion as necessary Proposal: To create a specification for the “device information data segment” (DIDS) to be referenced by the EOMA68 standard in relation to the data stored on the EOMA68 identification EEPROM. Keeping it separate from the EOMA68 standard: * keeps the EOMA68 spec concise * allows other open hardware implementations to more easily consider adoption Implementation: The DIDS will consist of a single contiguous block of binary data. The IDS will be segmented into variable size pages, and the IDS will be prefaced with a header. Header The header will be 4 bytes in size with the following layout: Byte Size Value ====== === ==== 0x00 2 Capabilities bytes 0x02 1 Checksum byte 0x03 1 Reserved The capabilities bytes are a bitfield. All bits are currently reserved for future usage and may only be assigned in future revisions of the EOMA68 specification. An IDS for this version of the EOMA68 spec must contain the value 0x00 The checksum byte is the CRC-8 result of the IDS. (The CRC-8 algorithm must be referenced from the final specification to avoid any ambiguities.) The final byte is reserved for future use. Pages Other than the header, the remainder of the IDS will be divided into variable length pages. Each page starts with a header with the following format: Byte Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data The page identifier (PID) is used to detect the layout of the data in the page, and all PIDs up to and including 32768 are defined in the DIDS specification. Values above 32768 are reserved. The page data then follows directly after the header. The maximum size of page data is limited by the page size value contained in 2 bytes, or 64k. A page may consist of 0 bytes of data, which may be used in cases where the PID itself is sufficiently informative on its own. The only page layout exception allowed is for the last, or terminal, page. The 0x00 value is used to identify the terminal page, and the remaining 2 bytes are ignored and therefore may contain any values. The terminal page always has page size of zero, regardless of the value stored in the last 2 bytes. Navigating between pages becomes an exercise in reading page headers, seeking to the end of the page (processing the contents along the way if desired) and repeating for the next page until the terminal page is encountered. There is no page index. Variable length pages without an accompanying index means that it is not possible to seek directly to a given page; however given the relatively small size of the IDS, the small number of pages and that the headers allow skipping from page to page this is deemed acceptable. -- Aaron J. Seigo

4 7

[flying squirrel] need quick review of power input for RTC battery on ATSAM4S
by luke.leighton 06 Nov '13

06 Nov '13

this is mainly a question for joe (and anyone else with schematics review experience!) the goal is to provide dual-power for the ATSAM4S. atmel recommend using 2 diodes however the voltage for the IO needs to be above 3.0v in order to run USB, the AXP209 can only output 3.3v max and a diode would suck 0.7v off of that. so i've been advised to use a MOSFET instead, and need to check it's going to work. so here's the schematic that needs checking: * http://hands.com/~lkcl/eoma/kde_tablet/rev3_review/atsam_vddio_power.png * note the diode which provides backup power (from the AXP209 RTC supply) * also i'd like to use the AXP209's "PWROK" signal to control when the ATSAM4S powers up. the datasheet says it's "HIGH" when power is "OK" and it starts off "LOW" when the AXP209 starts up. as the AXP209 PWROK signal is "HIGH" when "OK", that's why i *believe* that the transistor (Q6) is needed, to invert that so that when PWROK is "HIGH", the MOSFET delivers power. greatly appreciated a quick review of that logic. l.

2 5

identification EEPROM: vendor-defined pages
by Aaron J. Seigo 05 Nov '13

05 Nov '13

hi ... 3rd email in this saga, which asks the question: Should the DIDS spec allow for vendor-defined pages? In the proposed DIDS layout, page IDs above 32767 are reserved. The opens the door for vendor specified pages. A maker may wish to define and add non-standard pages to their DIDS for (at least) one of the two following reasons: * the page definition has been proposed to the standard, but is not yet part of the DIDS spec. this allows a maker/vendor to ship a device with that information without being held up by (or worse: *violating*) the specification. * it may be device implementation specific data, and by allowing the additional pages to be included in the DIDS it allows using a single EEPROM chassis design Benefits include: * allowing re-use of pre-existing chassis PCB layouts without needing to adjust them so as to add additional EEPROMs * prevents inappropriate use of mass storage (do we really want to see more “magic” partitioning, such as magic offset values, for mass storage devices?) * conservation (the ecological argument): if there is space on one EEPROM, why use two? With the proposed paged layout, there is zero technical reason why allowing make/vendor-defined pages would be a bad thing. The DIDS spec has 10s of 1000s of page IDs left to use for standard pages and it comfortably allows for vendor pages without making reading/writing of the DIDS any harder or more complex. There is zero cost to the EOMA68 standards or the DIDS layout by allowing maker/vendor-defined pages. Zero. The only reason provided so far is a desire to control vendors. As a maker/vendor, I find that concept utterly repugnant when there are reliable and sensible technology answers. Specifications should standardize and enable, rather than shackle, adopters. -- Aaron J. Seigo

1 0

[flying squirrel] rev 3 preliminary routing nearly done - HELP NEEDED REVIEWING
by luke.leighton 03 Nov '13

03 Nov '13

almost there, just need a last schematics review, the plan is to send the PCB off early next week (2-3 days time). I REALLY NEED HELP here. reviewing schematics and so on. this will be the first board i've done, and it's detailed and complex (but not amazingly hard). phil, nginx/apache appears to be out on hands.com so i'm putting a copy of the schematics here: http://lkcl.net/tablet2.pdf l.

3 10

LCD wiring diagram for EOMA done up
by joem 03 Nov '13

03 Nov '13

Hi, LCD wiring diagrams done up in kicad (and pdf): http://www.gplsquared.com/eoma_boot/eoma_boot.html#working_lcd The script.fex and guide to how to get it working with Ubuntu 13.04 all there as well. Still waiting on 5" display to turn up to do that as well. When I get the MEB2, I fold it into a case and put the LCD on the lid and make a really smart brick sized brickbook (TM) :D One with 18650 batteries and one without. Hurry up Chris!! I ain't got all day waiting on you for your MEB2!!!! There is a brick I have to make and throw at someone.

3 2

[eoma68] power issues
by luke.leighton 02 Nov '13

02 Nov '13

folks, as you saw a couple months back we have an issue with the EOMA68-A20 CPU Card where [without authorisation] some changes were made to the power distribution by the ODM. i still haven't worked out if those changes were/are a blessing or a curse. a reminder of the issue: they connected the ACIN *directly* to VBUS on the USB-OTG input, removing the usual safety and detection features (a SY6280 plus use of some GPIO) which allow programmable (or AXP209-controlled at least) switching between USB-OTG power and 5V input power. i have this sneaking suspicion that the solution might actually be staring me in the face, so wanted to run it by people, see what they thought. what i *believe* the solution is, is to simply move that USB-OTG/5V detection circuitry (in this case a SY6280 plus use of some GPIO) onto the I/O boards, and to effectively treat the EOMA68 5V power "as if" it was a USB-OTG two-way power system. so rather than have in the spec "you must provide 5V power", change that to "you must imagine that the power circuits are identical to what you'd normally have to do for USB-OTG". which, because wits-tech directly connected the bloody USB-OTG power to the ACIN by fusing the pins together at the AXP209 is actually exactly how it is. the advantage of this change (i say change, it's more like being frog-marched unwillingly towards a solution...) is that if people happen to accidentally plug in the CPU Card into a USB-OTG socket and keep it powered up, then a) the CPU Card will survive unplugging and can transition happily from one chassis to another b) as long as it doesn't draw too much current it would be possible to power a portable device *from* the USB-OTG... or at least charge its battery (if it has one) c) i'm sure there's something else... anyway i *think* it's a blessing - it would just have been nice to have been consulted by the ODM, eh? if anyone's got any other suggestions on how to manage USB-OTG power switching it would be very helpful to hear them: i will put them into the EOMA68 spec as implementation guidelines. l.

1 0

Double checking script.fex for eoma68-a20
by Ryan Mullen 01 Nov '13

01 Nov '13

Hi, I am booting an eoma68-a20 using the script.fex (converted to script.bin with sunxi-tools' fex2bin) found here: http://rhombus-tech.net/allwinner/a20/boot/script.fex I have run the instructions found on that page under the subtitle "setup boot instructions for booting directly off of sd/mmc" and all seems well. However, my kernel (linux-sunxi 3.4 with some custom config options) tells me this when booting: [ 1.663649] [mmc-msg] sw_mci_init [ 1.667156] [mmc-msg] get mmc1's IO(det) failed [ 1.671684] [mmc-msg] Not using mmc1 due to script.bin parse failure [ 1.678123] [mmc-msg] MMC host used card: 0x9, boot card: 0x0, io_card 8 [ 1.685471] [mmc-msg] sdc0 set round clock 400000, src 24000000 [ 1.691708] [mmc-msg] sdc0 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.702062] [mmc-msg] sdc0 Probe: base:0xf0034000 irq:64 sg_cpu:ffdfb000(4fc00000) ret 0. [ 1.710382] [mmc-msg] sdc3 set round clock 400000, src 24000000 [ 1.716717] [mmc-msg] sdc3 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.726839] [mmc-msg] sdc3 Probe: base:0xf0036000 irq:67 sg_cpu:ffdfa000(4fc01000) ret 0. After I boot an initrd, there are no /dev/mmcblk0 entries in my dev filesystem. However, I can make it appear if I do the following: echo 1 > /proc/driver/sunxi-mmc.3/insert This causes the card to be registered at /dev/mmcblk0 as expected. Digging deeper, it would seem that the script.fex sets the card-detect mode for mmc0 and mmc1 both to 1, which is CARD_DETECT_BY_GPIO. The failure in the kernel log occurs when the script.bin parser tries to read the "sdc_det" key and doesn't get a valid value describing the GPIO it should be using, I assume. mmc3 doesn't have that problem because script.fex sets the card-detect mode to 4, which is manual mode - this requires me to write a 1 to the control node in the procfs as I experienced. Is the script.fex incomplete? What's going on here? Thanks for any help, Ryan

3 12

Interfacing touch screen to EOMA68-A20
by joem 01 Nov '13

01 Nov '13

Hi, I got me 5 pieces of 4.3" touch screens. It should be same as the lcd described here that is already working: http://gplsquared.com/eoma_boot/eoma_boot.html#working_lcd It has something extra - 4 wires for a touch interface - resistive. The signal pins are marked: 37 XR Touch panel XR 38 YD Touch panelYD 39 XL Touch panel XL 40 YU Touch panel YU They were purchased from Aliexpress - (cheaper when I bought it). http://www.aliexpress.com/item/4-3-inch-KD43G18-40NB-A1-KD43G18-A5-4-3-C430… Any ideas which cheapie chips best to use with EOMA68-A20 to get touch screen operational? I assume it has to be I2C and somehow a bit of driver software will run and convert the I2C signals to mouse movements. Any pointers appreciated.

2 2

BOM of Cubietruck?
by Alexey Eromenko 30 Oct '13

30 Oct '13

SoC Allwinner A20 $8 (I assume only a bit more expensive than last year's A10 at $7) RAM chip $4 per 4 gigabit. (512 MB) x4 = $16. (Dram exchange) Flash 8GB $2 (dram exchange) Gigabit Ethernet PHY $4 (guesstimate based on old data) Intermediate total ($30) Do you happen to know the price of the following: Wifi+BT chip (it seems to have antenna on chip) How much for ports? VGA HDMI TOSLI NK RJ45 2X USB PCB (board itself) headphones audio out MicroSD slot Assembly work $4 ? Cables Package This will give us a very rough gross profit margin of Cubie.

4 3

goodbye LM13700, hello CM108AH
by luke.leighton 29 Oct '13

29 Oct '13

it is with much sadness and regret that for parts in the flying squirrel i say goodbye to the LM13700M, a part with a huge and rich history, having seen its first emergence into the world around 1967 even predating the moon landing. the reason is simple: the bias for the diodes is 3x 0.7 volts and on rails of +/-2.5V it's simply not enough. i'm seeing silence at low volumes... and then huge clipping. i simply don't have time to resolve this. instead unless there's a good reason (e.g. conexant responds to enquiries) i'm going with the CM108AH and keeping the TDA2822 as a speaker amplifier. the reason for choosing the CM108AH: no good reason other than the datasheet contains an example schematic and there were no NDAs required to get hold of that datasheet. l.

2 2

[flying squirrel] schematics review needed
by luke.leighton 29 Oct '13

29 Oct '13

hi folks i'm onto the 3rd revision of the flying squirrel, i need help: a systematic review of the schematic pages, to make sure i haven't missed anything. the schematic is partly copied from other drawings as well as application notes. the CM108AH is to be replaced with a Conexant USB-Audio IC. the pdf's here: http://hands.com/~lkcl/eoma/tablet2.pdf - any comments gratefully received. timescales are short but a careful review is essential. thank you everyone. l.

1 1

car "infotainment" doesn't upgrade....
by luke.leighton 24 Oct '13

24 Oct '13

http://tech.slashdot.org/story/13/10/22/2211209/automakers-struggle-with-pa… funny that....

3 5

[flying squirrel] revision 3 started
by luke.leighton 24 Oct '13

24 Oct '13

http://rhombus-tech.net/community_ideas/kde_tablet/news/revision_3_starts/ well... i've been quiet for the past few days because i've been incredibly busy. the experiments with the STM32F103 for use as a camera _would_ i think eventually have been fine... except that the speed simply wasn't up to scratch. so instead an extremely rapid bit of evaluation took place (thanks to a friend at atmel) and the SAM4S QFN64 was picked. the past two evenings have been spent doing a near-complete re-layout of the PCB. by shrinking the component sizes (0402) it's been possible to make just enough space to optionally fit a SATA, Ethernet, 4-pin header for USB and a 12-pin FPC as an expansion port. WIFI stacks on top via a 2nd 4-pin USB header with 3.3v power. there's going to be a bit of connector shuffling before this goes out, but it's basically doable. so, in effect, this PCB is one step away from being the Monster Engineering Board. it's also only 12cm x 10cm (under 5in x 4in) which is nice. l.

1 0

One other thing -- emulation question...
by Christopher Havel 23 Oct '13

23 Oct '13

One more idea that just popped up (I promise I won't spam the list too much with this kind of junk). How much of a performance penalty/loss would be incurred by "pulling a Transmeta" -- by which I mean emulating x86 hardware with, in this case, ARM...? Say, convincing an A20 to emulate something like a P3 CPU? The idea comes from the Transmeta Crusoe CPU -- which is NOT x86 at all! It's something I'm really unfamiliar with called VLIW, and it has what amounts to a software emulation layer between it and the rest of the system, so that it can run x86 code. Of course that incurs an INSANE amount of overhead, because the CPU is basically doing its job twice -- translating the instructions and then executing them. It's a remarkable kludge if you ask me, but it works.

5 13

Just a thought...
by Christopher Havel 23 Oct '13

23 Oct '13

It occurred to me, just now, that if the MEB (or any other EOMA-68 carrier board) is put in a housing with built-in guides for the CPU Card, then we don't necessarily need a proper PCMCIA slot -- just a 2x34 right-angle pin header with 1.27mm spacing. Have the bezel of the CPU card stick out just a touch from the housing, so that someone can get their fingernail (or a small slot screwdriver) under it and pry just enough so that they can yank it out. Seems to me that it'd be a cheaper option as well, because of the wonders of injection-molded plastic... even making the housing out of something fairly sturdy, say 2mm ABS, surely wouldn't cost too terribly much... plus, it's potentially possible to 3d print such a thing, which would make this stuff even more accessible to the (far richer than me) hobbyist. (Of course it'd also be possible to 'jerry-rig' it with scrap materials and lots of fussing.) I'd love to see a housing like that, with a small carrier board (perhaps a VGA-enabled version of the MEB?) and a VESA 75mm mounting option. It would enjoy a permanent placement on the back of my spare LCD for sure. (The carrier board would definitely have to support VGA through some means, though, to work with that screen.)

4 9

lkcl: you jammy toe rag!
by joem 22 Oct '13

22 Oct '13

http://www.gplsquared.com/eoma_boot/video-2013-10-21-15-06-42.mp4

4 5

Progress Report
by martin brook 22 Oct '13

22 Oct '13

Hi Guys, Just a quick note on my progress with EOMA and MEB EOMA Adaptation packages at http://repo.merproject.org/obs/home:/vgrade:/branches:/home:/mdfe:/hw:/sunx… Followed instructions at http://www.gplsquared.com/eoma_boot/eoma_boot.html to get eoma to boot from sdcard, please note use, http://www.gplsquared.com/eoma_boot/script.fex_2013_09_17 Mer image boots from sdcard, hdmi, serial, ethernet all working Pic of board running libhybris test_glesv2 https://twitter.com/vgrade/status/392416401790869504/photo/1 Thanks to all involved in bringing EOMA, MEB, linux-sunxi to the community. BR Martin

1 0

stress! and working with libopencm3, stm32sprog and an STM32F103
by luke.leighton 21 Oct '13

21 Oct '13

well. there is a particular issue with stm32sprog which has massively hindered progress over the past few weeks. it's very simple: when uploading and running a program using stm32sprog, if it has interrupt service routines it is guaranteed to crash. however if you then set BOOT0 to 0 and do a RESET, the program will work absolutely fine [assuming it's coded correctly] this simple little thing has prevented progress over the past couple of weeks because it has been impossible to distinguish "code incorrectly written" from "code that crashed due to stm32sprog". dozens of examples and bits of code that _should_ have worked - DMA, ADC, DAC, Timers - will and can now all be revisited. patience, patience... ... anyway i'm currently tracking how to get timers to update from an external gpio pin, and from there to fire DMA. it _is_ possible... just.... requires a huge amount of careful reading and research just to come up with only 30 lines of code that connect all the dots together without connecting any of the thousands of other options. i think... to be absolutely honest, if i had known that the STM32F was so comprehensive / complex i would have said "sod it" and used a low-cost FPGA instead. but, hey, this is kinda hair-raisingly fun.... l.

5 12

Allwinner A10 vs A20 power requirements
by Alexey Eromenko 20 Oct '13

20 Oct '13

Hi, I was unable to find the power requirements for A10 and A20 chips. (under near idle use and max. Performance scenarios) Do you know where that data is buried? (A20-based Cubietruck, according to documentation, can work with 0.5 amp x 5 volt = 2.5W total for the board, without SATA. ) What about Raspberry Pi's Broadcom chip? What it's power requirements? Alexey

1 0

Re: [Arm-netbook] My little idea...
by Hans-Christian Jehg 18 Oct '13

18 Oct '13

On Wed, 16 Oct 2013 14:12:24 -0400, Christopher Havel wrote: > Here, have a scan, guys! -->http://i.imgur.com/f2lbm3R.jpg > > There's the VGA interface. Any tweaks you want to add, add. WOW > To enable 18b VGA you need one GPIO. > Adding 24b capability requires a second GPIO. The circuit as drawn uses > GPIO3 and GPIO4 to not conflict with the earlier schematics which use > GPIOs 0,1,2 to drive the Ethernet port LEDs. How about putting those VGA GPIO on an I2C extender to keep GPIO free for something that needs GPIO? - Just a thought :-) HC

2 1

A20 Hummingbird Development System
by krasi gichev 18 Oct '13

18 Oct '13

Anyone checked this one? I got notification from wits-tech about it.

3 5

MEBv1 - All dressed up and no EMOA to go.
by Scott Sullivan 18 Oct '13

18 Oct '13

EMOA MEB's, Now in Colour! http://revident.net/projects/emoa-68/meb-v1-w-cases-in-colour.jpg So, the last to arrive due to a shipping malfunction, my MEBs arrived today. This evening I spent some time with the Laser Cutter at Hacklab.to to cut out Joem's cases design. I didn't get in on the initial batch of cards due to constraints in time, budget and skills. Now that the peripherals are confirmed I'm looking forward to standing on the shoulder of giants. Great projects lay ahead. -- Scott Sullivan

5 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook