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? :)
Great form-factor to easily re-use existing battery enclosure, but I have been wondering lately about the long-term future of arduino.
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.
Pi Zero consumes about 80 mA when idle. An Arduino Pro Mini can do an order of magnitude better, and that's without getting fancy with sleep modes and a watchdog timer. For things where most of the time is idle, and so you can have the Arduino spend most of its time in a very low power mode and just wake up when it is time to read a sensor or adjust a control or something like that, you can do something like on average three orders of magnitude better than the Pi Zero. (Four orders of magnitude if you do a little hardware hacking on the Arduino).
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).
I wonder whether it would be possible to create a tablet/laptop with an e-ink display, where the processing switches between a low-powered ARM and something like an Arduino. When the Arduino is used, the ARM would be turned completely off.
> I wonder whether it would be possible to create a tablet/laptop with an e-ink display, where the processing switches between a low-powered ARM and something like an Arduino.
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.
That's the thinking behind the big.LITTLE concept, and it's in use today. It's nice because in addition to power savings, it doesn't take up as much of the PCB as an ARM+Arduino combo would.
This does actually somewhat exist now. Most modern phones/tablets/ereaders have a low power core for monitoring and sleep modes. The problem is as soon as you want to 'do' anything you need the performance of the main core. Especially anything with graphics (like eink).
The Arduino is underpowered for anything more than a supervisory role, and even those applications are tending towards Cortex-M series.
It depends quite a bit on how the screen is updated. If it's like a traditional raster image, then you have to clock out each individual pixel in the image along with some blanking periods. The controller on the display is then responsible for taking that pixel data, syncing on the blanking periods, and drawing lines of pixels whenever data enable goes high.
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.
Eink uses a raster mode, but with (somewhat) tri-state pixels. You can send a 'no change' to any particular pixel. The disadvantage is you still need to scan the entire screen, so it isn't really useful for changing individual pixels, but partial updates are common.
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.
Note the link I submitted above, where it says that yes you have to send all rows with every refresh, but for every row you can tell it not to do anything. Presumably that means if you skip all but few rows, you'll get a faster update.
Pi Zero will never directly replace something like the arduino. Running linux (or any OS) can be a huge liability when you need to talk to some other bit of hardware that has strict timing requirements. That said, things like the ESP8266 and Arm Cortex M* processors are definitely becoming far more attractive than the AVRs in the lower end Arduino products (Due and others are also using ARM).
For what it's worth, you can code bare metal on the Raspberry Pi as well. It just doesn't have the community and support that Arduino currently has.
https://github.com/dwelch67/raspberrypi
There are quite a lot of systems out there with real-time requirements, where the system is not running a real-time predictable operating system - instead the likelihood of a missed deadline are averted simply by over-provisioning. You can get away with murder pretty much this way by just making your processor several times faster than is strictly necessary, provided you don't have any really long pauses in processing (like for instance having to swap in a page from disc). It works well enough most of the time for video playback.
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.
In the literature, that's often distinguished as soft real-time vs hard real-time requirements. Hard real-time is for when you absolutely cannot miss a deadline without adverse effects (production stalls, equipment crashes, etc), while soft real-time is for situations where missing a deadline is recoverable (like your example, a video renderer would simply skip the current frame and start processing the next frame).
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.
To be fair, a 8MHz (16MHz?) CPU is also a huge liability when you have strict timing requirements. For almost anything, the Pi will probably give you better guarantees by sheer speed... and you can always compile the kernel with a real-time patch.
Not saying running on the bare metal is worthless, but an Arduino is a really low end board.
Timing requirements don't necessarily translate to _speed_ requirements.
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.
>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_.
I make two products [1] that both use AVR microprocessors (though not Arduino), and both rely on sub-microsecond accuracy. One is a high-speed LED camera flash. The pulse width needs to be exactly the same every time, and so does the latency, otherwise the shot will be missed. The other is a sound trigger for flahes and cameras. That has to both be as fast as possible, but also exactly the same every time. If you're lining up a photo of a bullet passing through a cherry, you need to know that the bullet will be in the same position every time.
Incidentally, I've written a post[2] 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.
This post made my day! High speed photography prompted my true diving into the guts of computers. It introduced me to C, in very raw way, by my use of the AVR Butterfly demo board. Prior to that I had only tinkered around with Perl/PHP/Java.
I was able to get pictures like this [1] with a $25 microcontroller board (even cheaper now), about $150 in camera equipment, and a $40 pellet rifle. The setup was simple [2], 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. [3] 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. [4] 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!
Nice shots! If you do it again, you might find the AVR's analog comparator is a better route than the ADC. I use an external comparator on an interrupt pin in my sound trigger, which gives more flexibility.
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.
Music, for example. If you're doing audio processing for music, it's much more preferable to have something that takes 20ms consistently to transform an input than something that takes 5ms 90% of the time and 50ms 10% of the time (due to, e.g. interrupts). That 50ms gap will show up as a note that's audibly behind the beat, while the improvement from 20ms to 5ms isn't really that beneficial.
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 music, it seems like the rt-linux patch ought to be enough. They claim sub-100 microsecond timing jitter for process wakeup (https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Benchm...). That ought to be tiny, if you're talking about audio latency in the range of milliseconds.
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.
My last experience with rt-linux teached me that the kernel is not the only thing that needs to support real-time. As soon as you have any drivers (DMA!) or e.g. Service Management Interrupts (SMIs) that circumvent any smart preemptive scheduler of the kernel you're still screwed.
So, what was said is correct, hard real-time is hard, and an OS on top of a "general purpose" hardware platform makes it harder.
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.
100μs of jitter is enough to cause major problems if you're bit-banging or doing high-speed closed-loop control. Something like the Bus Pirate is almost trivial to implement on bare metal, but a complete nightmare if there's an OS involved.
RTOSes can be extremely useful, but they're not a perfect substitute for bare metal.
Well, right, that needs to be a multi-purpose serial interface device, and who knows what crazy timing requirements some sensor or interface chip will need. An example: There are some cheap little radios around. They literally just output a carrier with a binary value encoded on it in a super-simple modulation. Even with an RT device, you've got to keep transmissions very short and include a clock-synch section at the beginning.
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.
engine management units, camera flashes, LED lights, servo motors and brushless motors to name a few.
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.
I had an temperature and humidity sensor that uses one wire to read and write data from and to it. It has libraries in both Arduino and raspberry pi. The raspberry pi one does much worse and reads data wrong all the times - and given the library was written by ladyada, which is generally high quality code. It is none to her fault - Linux doesn't guarantee the timings - the best that someone could do is to crank the priority to max to get the timings right but even then it is still iffy. Interesting to see, given the raspberry pi has a way higher clock compared to the Arduino.
# 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!
Another specific example would be something like an IRIG-B (DC) timecode decoder where you need to provide a PPS signal that's phase locked to the P0 rising edge or maybe even just display the time. This would be accomplished by implementing a state machine to lock on to the IRIG frame and essentially run a PLL to synchronize one of the local timers. Decoding the IRIG frame would require you to be able to catch every transition of the signal. With a good implementation, you can achieve PPS accuracies to within a few clock cycles (with it being deterministic too).
Yes, but even with rt-linux, you've got a jitter of potentially several dozen microseconds, and each interrupt routine will vary. With an AVR, your delay is 4 clock cycles every time, which comes out to .2 microseconds at 20 Mhz. This is the kind of guarantee you can get with being on an intimate level with the chip which you can't get with any OS.
It's not just about the OS, it's about the platform (hardware). Even with a fully-optimized RTOS on a standard PC platform, you might run into millisecond-latency due to non-maskable interrupts, cache misses or bus contention (DMA bus-mastering kills any real-time guarantees). That's not even considering the stalls introduced by SMM or TPM instructions.
I would think it would be difficult to achieve the low jitter of a simple, fixed # of cycles / instruction, architecture like AVR in a superscalar, cached, speculative architecture like modern X86 CPUs. A hard RTOS is necessary, but perhaps not sufficient with most X86 microarchs. Maybe you can disable some of that dynamic behavior via MSRs but probably not all.
I think that's confusing liability with speed. Running interrupt-free code on an ARM or AVR is incredibly reliable. I would argue much more reliable than going to the length of patching the kernel.
Just because it's slow doesn't mean you can't predict what's going to happen, they're two separate issues.
Couldn't you write a really simple kernel[1] or bootstrapping program, and effectively run your program without an OS?
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.)
There's no such thing as bare metal any more. https://en.wikipedia.org/wiki/System_Management_Mode - the CPU itself may at times spend some time doing "other things" such as changing the spin speed of the cooling fans, or interpreting the signals from the USB keyboard. The OS (running in ring 0) has no control over this - the CPU effectively just pauses for a little bit every now and again.
TrustZone. It is "one level deeper" just like any other hypervisor or monitor. As far as I know, it is quite common in Android phones for HSM and DRM purposes. Yay? =\
Generally there is a trade-off between latency and throughput. Embedded Linux is generally geared towards more throughput than latency. Microcontrollers have less throughput-oriented features (threads, for instance), which makes them very well suited for latency-critical real time stuff.
If I prototype something with an Arduino, I can easily switch to directly sourcing ATmegas and spin my own boards.
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."
after the initial batch all manufacturing resource was supposedly moved to the pi 3 so they're still tricky to come by. I'm sure they'll be back though. There's an interview in https://www.raspberrypi.org/magpi/issues/43/ that explains this I think.
I have one pi zero and (like 99% of raspberry pis - or is it raspberries pi? - in the wild) I have not done anything useful with it yet.
Can you build one? Can you even source a Broadcom SoC? While Arduino-compatible MCUs can be trivially dropped into your own PCB designs. Some can even run dead-bugged with little to no effort, due to a much higher degree of integration.
Congratulations on being a person of the sort I mentioned, who managed to get a few of them. If I build one into a product can I buy 100 of them? 1000 of them? Can I source the SoC to make my own board based on the design?
For me, the Arduino's appeal and value is in not having an operating system, and just how directly you are dealing with the hardware. Your C code is the only thing running, and it talks directly to the pins. It's crazy easy to get started, it has a ton of potential for cool projects, but is so limited that your projects are manageable and you're forced to be creative. You only get a few K, so you get to be clever and kludgy and do whatever it takes as fast as you can make it.
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.
In addition to what others have said, Arduino has 8 built-in ADCs, which are essential for some physical computing applications. Pi (Zero or otherwise) has no built-in analog input capabilities.
ESP8266s go for $1 SE Asia, and down to 0.50, or less in quantity.
Different sleep modes can be programmed and the thing can run off a very small solar cell or a coin battery for a year or two depending on WiFi usage, etc...
You can program to the metal too, if you want low-latency.
Except ESP8266 is not usable unless you're somewhat proficient with electronics. Basic Arduinos you can hook up via USB. Yes, there's NodeMCU (which I very much like), but unfortunately it's not $1.
What's not $1, the arduino or NodeMCU (opensource)? The price I quoted was for board with power regulator, breakout of GPIO, and WiFi (of course). You can run the Arduino IDE and serve web pages from it. Someone has created a Lisp/scheme running on it.
I've been tinkering with the ESP8266 since it came out and best board I've found so far for hobbyists is the WeMos D1 Mini. It's based on an ESP8266EX but is mounted (everything except headers are soldered) on an Arduino style breakout board with a USB-serial converter. It's $4 at retail prices from AliExpress which includes shipping.
What do you mean 'not as deep as the arduinos'? There are definitely issues with coordinating WiFi and low-power usage requirements, but it offers several low-power states, that I have not had issue with so far.
From what I've seen, the USB->serial chip on the inexpensive Chinese Arduino compatibles on AliExpress generally is not an FTDI knockoff. They usually seem to use a CH340 or CH341. This does not try to emulate or pretend to be an FTDI. It has a different interface and needs a separate driver.
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.
I think there will always be applications where an OS is not needed, but 32-bit micros with floating point like the STM32-F4 (~168 MHz ARM) can do a lot of cool stuff that's impossible with Arduinos. Nontrivial robot state estimation and control, for example.
What about porting the Arduino code to the esp8266/esp32 ? powerful chip + huge network.
Altough as a prototyping platform, i can understand how javascript would be more appealing. And for production, even by startup, the Arduino is far from ideal, mbed is much better.
shameless plug: portable JavaScript+C programming environment for esp8266/esp32/cc3200/RPi https://github.com/cesanta/smart.js. Supports over the air updates (OTA) both and rapid development and updating your device fleet.
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.
At first I wasn't impressed, because Arduinos are all bloat, an AVR can run directly off a battery. Then I realized they've found a clever way to use reuse a battery holder as an enclosure!
This is great. I have used one LiFePO4 batteries (3.2 V) and a copper rod to replace two 1.5v batteries in a few electronic. This would be even better then a copper rod.
Search for "lifepo4 14500" It does need a specific charger. I bought my charger from batteryspace.com. I found the following linked from their site.
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.
This seems to be a great way to stick a small wifi-tracking device (skyhook based, report location whenever it finds open wifi network) in any AA powered device. You'd have to figure out how to put a 1.5v battery on the board so the overall voltage of the battery pack would be correct.
Do you (or does anyone) know how much power something like that would use? I've been wanting to make a tiny tracking device (using 2G instead of Wifi), but I didn't pay very good attention in my high school physics class, so I don't know if a tiny cell chip + tiny gps chip could last long without power.
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).
The GPS tracking collars researchers use on wolves last something like a year or even two. Their batteries are more powerful than a couple AA's, of course, but that should at least give a starting point for some back of the envelope estimates as to what you could do with a smaller power budget.
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.
Using LoRaWan, etc would be enough to power it for months. Also it could probably be disguised as an actual battery and has enough space left to hide high density lithium-polymer battery inside.
Lol. It's a great idea, but I would hate to go through airport security with that board tucked into a battery holder. The entire package just screams "secondary inspection".
I carried my Raspberry Pi cluster (www.pidramble.com) through the airport four times. All but one time I had to do a slight bit of extra explanation that the hardware and mini rack that held it all together was just a computer. People aren't used to seeing exposed circuit boards anymore.
There used to be a comment thread here regarding the Pi Zero and how it's impossible to buy one through any of the distributors. Somebody (else?) provided a link regarding Broadcom, and how they might not want the Pi Zero to become a success...
Everything seems to have disappeared. What happened?
For those interested, Kanflo wasn't the first to create an Arduino like clone in this form factor. For instance there is the the Jeenode and its sibblings developed by Jean-Claude Wippler.
The JeeNode is way bigger than an AA (with the upper pins bent outwards nearly double the size).
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 :)
Definitely. I used to build my own cables back in the early 2000s and barely broke even due to radio shacks pricing. Currently have a Boe bot laying around somewhere in the lab. Might have to dust it off.
The Arduino is an Atmel chip on a small board with a few components for simplifying the power supply and USB communication, plus an IDE and a few libraries for simplifying the development.
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.
When I'm doing my hobby projects, I'll often prototype on an Arduino UNO with breadboard. Then in "production" I'll buy a stock ATMega328 and a couple supporting components and build it right onto my perfboard.
The microcontroller on most arduinos is a normal atmel microcontroller. The build output of the arduino compiler is no different from traditional embedded compilers. It's still just machine instructions.
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.
If you're at the point where the overhead for running Arduino starts becoming an issue, you would have long moved on to better platforms that are more optimized for your purpose.
Production-ready examples that are so much more capable than Arduino:
TI MSP430/43X
Cypress PSoC 4/5/whatever (these guys are pretty schmick)
I like the idea of the form factor as it makes it easy to source a compact case. If it wasn't the case, but rather the compactness, that was particularly useful then it's worth pointing out that smaller Arduino-compatible boards exist. For example...
I don't understand what the author is trying to say with "wiring it in backwards" in the last paragraph. Well, of course you power it with the batteries right next to it; otherwise, what would be the point? From what I can gather from the original blog post, linked by asimuvPR, there's just one way to put it in and you'll probably fry some components if swapping polarity.
Am I missing something, or is this just your average TC article?
> I don't understand what the author is trying to say with "wiring it in backwards" in the last paragraph.
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.
Arduino has become a generic term referring to anything that can be programmed by the arduino ide.
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.
Is there any guide/introduction to the hardware architecture of Arduino in layman terms and how it was built? I am really interested in studying this aspect of Arduino since I finished the first half of nand2tetris a couple of weeks ago.
More von Neumann-propagating propaganda! Just kidding, I just embarked on nand2tetris this week. Great stuff! However, I feel have betrayed my Lisp Machine lust in the process. I was reading Peter Kogge's 1992 book, "The Architecture of Symbolic Computers" (fantastic book, Lisp, or not), and hoping to implement my own LM in simple hardware, no Symbolics machine here ;)
I have Pilos (PicoLisp on bare metal) running in a VM on my Windows 8 box[1], and I am about to buy a chip that was made especially for running miniPicoLisp [2,3].
All that being said, I am looking into the Propeller chip, the 8x32bit core chip from Parallax. They released the Verilog files a few years back for the hardware, and the software (Propeller Assembler, and Spin, a Python-like programming language for it) years before that [4]. I'd like to see if I can use it somehow. I like the non-von-Neumann architecture of it. Interrupts are not needed in the same sense. Also, each 'cog' (1 of the 8x32bit cores on the Propeller) can modify the main code, thereby allowing for self-modifying code on the microcontroller. That and Lisp's 'code as data' should make for a helluva an adaptable system.
Fuck BTLE. It's a nightmare to work with. Complex, extremely sparsely documented, and the Linux bluetooth stack is a PITA - not to mention that the BTLE part of BlueZ is ENTIRELY undocumented and you have to be really lucky to catch a bluez dev on IRC.
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...
I do embedded development, and BLE is just another stack. It's actually very well documented in the official Bluetooth Core Specification. It's thousands of pages long, but it's a big stack with lots of layers and protocol.
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.
You should seek out a primer of the general architecture. Its definitely a departure from IP networking. Here's a brief overview:
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.
I just started a little BLE work to get into things. I've found it really odd there's a definitive list[1] of services that can be advertised. Why is it not just a specified key/value to advertise?
Go to www.bluez.org and try to figure out how to use BLE. Like how to scan for BLE devices, connect to one and read its GATT, interact with characteristics, etc. Bonus points try to figure out how to do it using their APIs and not command line tools. Good luck! (here's a hint, I hope you like dbus)
Although this is pretty far away from the Arduino-style boards, you may want to have a look at the Sensortag from Texas Instruments: http://www.ti.com/sensortag
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.
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 :(
Any suggestions? I've gotten into arduino recently and am looking to simulate some projects if possible (2 year old leaves less time for bread boarding)
It would be awesome if HN automatically created a archived version using https://archive.org/ and added a archive link below the post like the web link.
It seems like the blog post stays accessible as long as it isn't the URL at the top of HN, so we've reverted to what you had originally. Sorry for the distraction.
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? :)