Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Intel Galileo: "Pentium class" 32 bit Quark SoC X1000 with an Arduino header. November 29th.

TI Arduino TRE: 1-GHz Sitara AM335x processor plus an AVR processor for the Arduino side. Includes the Arduino sockets and it looks like an X-Bee socket. This looks like a Beaglebone combined with an Arduino. Ships sometime in Spring of 2014.

Of the two I find the TRE more interesting. Precise control of pins is difficult in Linux where you could be preempted and holding the CPU and counting cycles is frowned upon.

BTW: If anyone invents a time machine, please go back and get the original Arduino header alignment fixed.



If you need microsecond or nanosecond-level control of I/O, you're probably a little too advanced for an Arduino-type environment.

If you do, the AM335x offers a subsystem called the PRU that lets you program I/O that runs independently from the core. Kind of like, hmm, a bunch of Little Arduinos inside the Big Arduino.

http://www.ti.com/lit/wp/spry136a/spry136a.pdf


I use my arduino nano to drive 12 servos. This requires microsecond level accuracy. It can be done without too much trouble using the 16 bit clock.


The thing is, the only tool provided for using the PRU is an assembler[1]. So trying to make an AM335x into an "Arduino" required at a minimum: a friendlier real-time IO system / PRU toolchain, the creation of an Arduino sketch and library API compatibility layer, and circuitry to deal with 5V IO.

Solving all that by just bolting an ATMega beside the AM335x isn't the least bit elegant, but Arduino has never seemed to be too bothered about elegance.

_1: https://github.com/beagleboard/am335x_pru_package


But the reality is that at gigahertz speed you could run the TRE's I/O from userspace and have pretty accurate timing. Just latch your LEDs. =)


It seems the Galileo board controls GPIOs indirectly trough an I2C expander on a bus running @100kHz, so it'll be hard to do very precise control of the IOs even at the millisecond scale.


>BTW: If anyone invents a time machine, please go back and get the original Arduino header alignment fixed.

The TRE has all of the arduino signals on a 2x17 0.1" header, the one with a white background around it (which seems to mean 5v-safe / AVR-connected on the TRE). Then there's also the remaining double-row headers, which I'd assume are arranged on a 0.1" spacing in relation to each other, and are possibly a new Arduino standard for a 3.3V-only header layout.

It's still not perfect, though. Personally I wish they had made the new standard headers closer together than the old headers instead of further apart, to make it possible to at least bridge across some of them with a $10 5x5cm PCB (even the existing Arduino header standard is just a bit too large to fit on a 5x5cm board, and that's the standard lowest-price tier at all of the super cheap chinese PCB services). But I guess if you only need access to the Uno-era Arduino pins, you can now fit everything into a ~4.4cm long double header. But it's a double header, so you can't make your 'shield' able to pull double duty by plugging directly into a breadboard, which you could have if there had been two close rows of 5V headers instead of a single double-row.

But it is an improvement, and the form factor does have a history of working, a single double-row header is the basis for the entire Pi-Crust/Plate/Shield ecosystem.

High-resolution photos at http://e2e.ti.com/blogs_/b/toolsinsider/archive/2013/10/03/i...


The problem with Quark X1000 is that it has SMM - you don't have to worry about Linux messing up timing (it's the easily replaceable part), but the firmware.


CONFIG_PREEMPT_RT

Oh, and Debian has a ready made one in the repositories so you don't even have to compile it yourself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: