Github repo (Its MIT licensed): https://github.com/kanflo/aaduino
What I really liked about this approach is that it makes packaging the "Arduino" inside a common battery holder very easy. Maybe one or two holes are needed to connect sensors and you have a pretty nifty enclosed "Arduino". What we now need is someone to build a battery enclosure with exposed poins. Anyone from Adafruit, Tindie, etc. here? :)
With the low price of something like the Pi Zero which is running a full version of linux, or something like the Esp8266 which can run many different languages, you're basically paying shipping costs. What benefit does arduino have in this future, other than a large existing network, which I understand can't be overlooked as a strength.
That's the difference between having to change a couple AA batteries every day or two (Pi Zero) and running for a year off of a coin cell (Arduino).
Here's an article on power consumption of an Arduino Pro Mini: http://www.home-automation-community.com/arduino-low-power-h...
Here's one on Pi Zero power consumption: http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi...
You'd have to deal with different architectures and a lot of headaches, but it's the idea behind ARM's big.LITTLE, where you pair high-perf high-power and low-perf low-power cores. So your tablet's SoC might have a ~200mW A53 for mostly-idle use with a ~1W A72 for more active "high-performance" work loads. And the only additional hardware is the additional cores and the interconnect, the SoC is shared between "low-perf" and "high-perf" cores, which probably wouldn't be the case for an arduino/arm mix.
The Arduino is underpowered for anything more than a supervisory role, and even those applications are tending towards Cortex-M series.
Maybe that can be worked around? eg if updating only a small area. Or as a second display for docs.
If the eInk display doesn't use this raster model but rather an addressing model then it might be possible to support partial updates. I doubt very much that it does though.
The other difference from a traditional raster display is there is no minimum refresh rate.
Eink controller chips use an addressing model and handle the partial updates for you, so the main processor sees a bare framebuffer.
see also: https://arduinohistory.github.io/#when-did-arduino-begin-and...
Not just the timing is critical, also the failure causes (and modes) are far bigger in number when running an OS.
E.g. if you properly code in C or ASM for a microcontroller and avoid things like recursion, it's very hard to crash due to OOM errors.
- DRAM refresh
- cache hits/misses
In essence, a job that requires 90% of the CPU time on predictable hardware can often be solved by just throwing faster hardware at it. If the RasPi can do it using 5% CPU, then it's probably fine.
YMMV. Don't do this on medical equipment, space rockets, or self-driving cars.
That's funny because I was coming here to say that I built a real-time system running on Windows... for a medical instrument. Windows was fine because speed didn't matter, predictability did, and our latencies were measures in hundreds of milliseconds and Windows has no problem keeping up with that. The only time I saw CPU usage go above 1% was when the instrument was shutting down and had to clean up a lot of objects.
The AM335x has a pair of "PRU" units on the die, that are roughly little microcontrollers that have access to the main ARM's memory.
So, you can write to main memory from Linux, jitter and all, and then let the PRU stream it out to anything that needs high speed, predictable data.
This guy put a BB black inside an old MAC SE, and is driving the CRT with the PRU...very cool: http://www.nycresistor.com/2014/02/02/30th-anniversary-mac/
Very cool project, thanks for linking!
Not saying running on the bare metal is worthless, but an Arduino is a really low end board.
Microcontrollers like the Arduino/Atmel are perfect for situations where you need to guarantee that some signal will be asserted exactly 250 (no more, no less) nanoseconds after some other external event, _no_matter_what_.
Since there's usually no OS running on something like an Arduino, you're basically forced to write very deterministic event driven programs. Also, since most (maybe all) instructions on those Atmel microcontrollers execute in a single clock cycle, you can easily dissect your C functions and know exactly how long they will take to execute.
I wouldn't trust Linux for such an application even with a "real time" scheduler.
Linux as a RTOS certainly has it's place, but it's best left for systems that can actually benefit from the added complexity.
For most typical microcontroller projects, the extra features of a full Linux kernel would just get in the way.
Note: There's nothing stopping someone from using a RPI in such a way as well (bare metal), but they are really geared for more complex applications, so there isn't as much support in that area. Also, the hardware is probably a little more complex. Therefore, my statements assume we're comparing an Arduino to an RPI running Linux.
What is an example of something like that?
Incidentally, I've written a post about high-resolution timers with Arduino. The normal timing functions are not accurate enough for my sort of work, but the nice thing about Arduino is that you can easily drop down to the native AVR code, or even assembly if you need.
I was able to get pictures like this  with a $25 microcontroller board (even cheaper now), about $150 in camera equipment, and a $40 pellet rifle. The setup was simple , with just a regular camera flash under a plastic bag (cheap diffuser!) and a configurable delay. The firing of the timer was controlled by the AVR's ADC readout of an electret mic. I ended up delaying about 20 milliseconds for the shots I took.  The AVR triggered the flash via an optoisolator relay. Pretty simple, I was glad to find out that even just placing a coin across the contacts will trigger the flash.
Now I'm excited to measure how fast that standard flash really was, with your article's advice. And then, for the cherry on top, compare it to my General Radio 1531-AB stroboscope.  It was the cheapest externally triggerable stroboscope that I could find on eBay at the time. I got that flash because it can produce strobes as short as 0.8 microseconds! I really want to recreate an old high speed shot and see the difference between the flashes first hand. But college happened and I haven't touched photography in about a decade. I haven't even taken a darn photo with the stroboscope, I've just turned it on and soothed myself with the rapid and loud clicking. :P I hope your post motivates me!
Your Vela One... so tempting...
Perhaps I can tempt you further with a discount. Use the code HACKERNEWS for 10% off. That's open to anyone else reading this too, and is valid until next week.
EDIT: another example is controlling a UAV. You can design around a system that consistently takes 20ms to process an input (e.g. by limiting the max speed). It's a lot more difficult to design around a component that takes 5ms most of the time, but will randomly take 50ms here and there, because you don't get to control when those lag spikes happen.
For UAVs, you're typically talking to ESCs that want PWM signals in 1-2ms ranges, so 10s of microseconds of jitter would certainly matter for PWM generation, but that's why you'd probably offload that to an external PWM chip, and handle the code that will tolerate 20ms processing times with 100us jitter (like the flight-control loop) on the CPU.
Bare-metal can't be beat for tiny (easily-auditable) code size, and general lack of "what if the timing goes wrong somehow" situations, of course. Plus, who knows if the rt-linux patches would actually perform to that level on a Pi-zero.
That being said, there is stuff like VxWorks, which kind of proves that it is possible, if you have full control over the hardware and the OS.
RTOSes can be extremely useful, but they're not a perfect substitute for bare metal.
You can still transmit and receive if your devices have a lot of jitter, but you'll have to kill your transmission rate to keep things working reliably.
Whilst the raspberry pi has the ability generate PWM, you can't guarantee when they run because something else might be scheduled to be on the CPU at the time.
The fancy RGB lights require a precise, complex signal running at ~800KHZ* you can't miss a signal slot because it'll change colour. Its the same for servo motors, although thats more simple as it only needs a static PWM to hold position.
*might be less
Note the comment:
# Note that sometimes you won't get a reading and
# the results will be null (because Linux can't
# guarantee the timing of calls to read the sensor).
# If this happens try again!
Just because it's slow doesn't mean you can't predict what's going to happen, they're two separate issues.
Does an architecture (ARM / AVR / x86) limit the possibility of writing real-time code if the code is the OS, and just runs on the bare metal?
Your program would run in ring 0, be the only "process" and have full access to RAM. You decide whether you want to handle interrupts or not. (I assume there's a way to select what interrupts you want to handle.)
 For e.g., this tutorial explains how to write a basic x86 kernel: http://www.jamesmolloy.co.uk/tutorial_html/
Edit: And, of course, it is probably exploitable in some way. See http://bits-please.blogspot.com/2015/08/exploring-qualcomms-...
The Pi Zero is the next thing over from vaporware. I know some people who have a few, but all of the official vendors linked from https://www.raspberrypi.org/products/pi-zero/ are either out of stock, or have "limit one per household."
I'd been having trouble figuring out where to source the BCM 2835 SoC that powers the Zero, and there's (allegedly) a reason for that: https://olimex.wordpress.com/2014/08/28/who-fears-from-the-c...
I really like that bigger better tiny hobby computers are being developed, but the things you mentioned - running Linux & many different languages - don't appeal to me the same way Arduino does. Adding modern day benefits like tons of memory or 3D display means I'll be just programming, like I would at my day job developing console games. With the Arduino, on the other hand, I'm always hacking.
Yes it has sleep modes, but they are not as deep as the arduinos, and require work to make them effective.
The only problem I've heard of with these is that the drivers are not shipped with some operating systems (such as OS X) and so you might have the hassle of installing a driver. FTDI drivers come with all major operating systems, so one less thing to deal with.
I believe I've seen Uno clones on AliExpress that are about twice as expensive as the cheapest clones (so around $6) that use an ATmega16u2 to handle this, which is what a genuine Arduino Uno uses, and so is no more hassle than a real Uno.
There are some USB->serial chips that cost more than a CH340 but quite a bit less than an FTDI, and that work with the generic serial communications driver that is built into all major operating systems. I haven't seen any Arduino clones that use these, which is a shame. I'd love not having to rely on any vendor-specific code.
And things like the Beaglebone Black have better real time capabilities but as someone who has worked with BBB for over a year now, it is so horrible to develop for I almost cried.
Embedded Linux is pretty bad for hacking, but it's pretty good for industrial controllers and other "solved" problems. Microcontrollers are still the way to go.
Charging Non-cobalt-blended Li-ion
While the traditional lithium-ion has a nominal cell voltage of 3.60V, Li-phosphate (LiFePO) makes an exception with a nominal cell voltage of 3.20V and charging to 3.65V. Relatively new is the Li-titanate (LTO) with a nominal cell voltage of 2.40V and charging to 2.85V. (See BU-205: Types of Lithium-ion.)
Chargers for these non-cobalt-based Li-ions are not compatible with regular 3.60-volt Li-ion. Provision must be made to identify the systems and provide the correct voltage charging. A 3.60-volt lithium battery in a charger designed for Li-phosphate would not receive sufficient charge; a Li-phosphate in a regular charger would cause overcharge.
I've looked in to little tumble generators (I don't know the actual term, something that could generate power off of movement) but again, my knowledge is lacking in that department.
Would make for neat little animal tracking devices, if they could generate power from movement, store in a battery, and then 'pulse' out on a regular interval (whatever interval is allowed by the generation from the shake/tumble generator).
A lot depends on how often you actually need to gather GPS data, and how often you need to report it. A GPS can use a relatively large amount of power while first getting a fix, but then updating that fix later, if it hasn't moved too far, will use a lot less power.
The datasheet for a GPS module should tell you the power consumption during various operations, and how long those operations can take, so you can figure out the power needs for a given updating schedule.
You could probably do some clever things, like include an acceleration sensor and only update the GPS when you infer from the acceleration sensor that you've moved.
Similar considerations apply to reporting data. Frequent reporting will use more power than saving up the data and sending it one bigger batch, because there is overhead in setting up a connection to whatever you are reporting to.
There are commercially available GPS trackers that run for two weeks on two AA alkaline batteries or three weeks on AA lithium batteries. I don't think the ones I saw reported wirelessly...they were the kind you have to retrieve to get the tracking log, but this suggests that an AA GPS tracker with wireless reporting with enough runtime to be quite useful is feasible for a lot of applications.
Everything seems to have disappeared. What happened?
This would be a great way to prototype a simple wearable project that doesn't use wireless radios.
See for more info on this:
I recently bought teensys (or teensies?) to get smaller (a little to wide for AA slots though): https://www.pjrc.com/teensy/teensyLC.html Given the cost you might want to try to sand of one side of connectors to make it fit :)
So you can swap out one part to interchange between BLE or Wifi.
I appreciate what arduino has done, but at some point it's too much.
There's nothing "basic" about the hardware itself: you can at any time switch to C and compile with gcc, just like for any Atmel chip.
Great guide here on how to do that.
If you want even more control, you can just use the avr C libraries with any atmega328, Arduino included.
It's sort of similar to how Python runs on top of C. To the processor, it's all the same. It had no idea that you wrote your application in C or Python. They both end up as machine instructions.
Production-ready examples that are so much more capable than Arduino:
Cypress PSoC 4/5/whatever (these guys are pretty schmick)
Atmel ATMegas, the chips behind Arduino.
Am I missing something, or is this just your average TC article?
The author is just marveling at this novel / nonobvious form factor, and referencing this bit as elegant / cool / new:
> The + and – markings on the PCB indicates (this is important, read carefully) the positive and negative poles of the battery we are pretending the AAduino is. [...] Also note! If you want to power the AAduino from a bench power supply, connect the power supply’s black negative lead to the + marking and the red positive lead to the – marking.
Typically your electronics have polarity labelings based on which end of the battery they'd connect to - e.g. you'd have a red wire going from the positive terminal of the battery to the positive terminal of the device being powered, which this paragraph is warning is not correct for the AAduino because it's labeled as a battery would be instead.
I guess this serves as a cautionary tale, illustrating the power of a well-known brand and what happens when you lose control of it.
It happens to be the largest development community in the world for 8 bit microcontrollers.
It only makes sense that people who want to give their projects maximum visibility would use arduino, and not genuino. The top comments in threads about genuino would just be people talking about the name dispute, not the actual project.
I wonder how all the cheap-ass Android device makers get BT(LE) running... or wait, often they don't and the user is screwed...
Just like any networking stack, there's a decent learning curve, but its not like it requires any fundamental tool foreign to firmware development. On the other hand, your average arduino tinkerer has been handed so much abstraction of low level details, learning BLE, at least on the device side, would be a tall task.
Specific implementations of stacks and sdks will obviously vary in quality and documentation. On the device side, Nordic does a very good job with tools and documentation for their parts. There are several companies that make modules with nordic parts and provide libraries and example projects.
I've also used noble, which is a node js module that allows you discover and connect to devices. On a Mac, all you need is Xcode.
Devices advertise their presence when they are not connected. The usual connection is one device to one client, although multiple simultaneous connections are possible. Clients can look at advertisement data to see what services the device offers. Once a client connects to a device, it can interrogate the device further.
A BLE device makes multiple pieces of data available individually, called characteristics. So if your device had a heartrate sensor and a battery, your bluetooth profile would likely have a heart rate characteristic and a battery level characteristic. A client that connects to this device could discover these characteristics, and read/write them, as well as set up notifications, so the device can asynchronously send the client data.
An IP based system treats its connection as a single pipe, whereas in a BLE system, on top of a single physical connection, you effectively plumb a separate pipe to each piece of information you make available to the client. Each characteristic has its own read and write callbacks, and each characteristic can be individually customized with things like read write notify permissions, data type, description, etc.
Like "Health Thermometer" is crazy specific.
The nice thing about standard services is that 3rd party apps that know how to interact with those services can work out of the box.
DRM and obfuscation is even present in these devices -...-
I'll agree though that you are more likely to find compatibility on a development board level than in a commercial product.
The documentation is a bit on the weak side, but it's small, easy to use, and low-power (~1.3mA @ 3V connected, ~0.2mA advertising)!
I recently used one to make a BLE smartwatch that uses my iPhone as a network connection (http://workhardanywhere.com/smartwhatch)
It is based on a single-chip wireless microcontroller that has both support for both BLE and IEEE 802.15.4 (6lowpan/ZigBee). It is supported by the Contiki OS (http://www.contiki-os.org/). The learning curve is probably quite a bit steeper than that of an Ardiuno, but the board and the chip can be readily included in commercial products. There are reference designs with design files, BOMs, schematics available from TI.
Since it has both BLE and 6lowpan support, you can do some pretty nice things with it, such as providing both quick discovery via smartphones and secure remote access: http://www.thingsquare.com/blog/articles/proximity-control/
FCC Certified, how neat! It's got a tiny CPLD on it with programmable analog routing logic as well (DACs, ADCs, op amps).
I was trying to use one of these to drive my Nixie Tube Clock and using the CPLD to do the multiplexing in hardware but I accidentally touched 12V on one of the pins and it blew up :(
I read that with a Boston accent
Kinda wish I was better at stuff like this, maybe I should begin playing around with my Arduino again.
Edit: well that didn't work. URL changed back from http://johan.kanflo.com/the-aaduino/.
(We detached this subthread from https://news.ycombinator.com/item?id=11538219 and marked it well off-topic.)
> Error establishing a database connection
I'm never sure quite what to do in this situation. It depends on what the author would want.
Maybe a web archive link? You are always on top of things dang!