Posts with «hackaday columns» label

Hackaday Links: April 26, 2020

Gosh, what a shame: it turns out that perhaps 2 billion phones won’t be capable of COVID-19 contact-tracing using the API that Google and Apple are jointly developing. The problem is that the scheme the two tech giants have concocted, which Elliot Williams expertly dissected recently, is based on Bluetooth LE. If a phone lacks a BLE chipset, then it won’t work with apps built on the contact-tracing API, which uses the limited range of BLE signals as a proxy for the physical proximity of any two people. If a user is reported to be COVID-19 positive, all the people whose BLE beacons were received by the infected user’s phone within a defined time period can be anonymously notified of their contact. As Elliot points out, numerous questions loom around this scheme, not least of which is privacy, but for now, something like a third of phones in mature smartphone markets won’t be able to participate, and perhaps two-thirds of the phones in developing markets are not compatible. For those who don’t like the privacy-threatening aspects of this scheme, pulling an old phone out and dusting it off might not be a bad idea.

We occasionally cover stories where engineers in industrial settings use an Arduino for a quick-and-dirty automation solution. This is uniformly met with much teeth-gnashing and hair-rending in the comments asserting that Arduinos are not appropriate for industrial use. Whether true or not, such comments miss the point that the Arduino solution is usually a stop-gap or proof-of-concept deal. But now the purists and pedants can relax, because Automation Direct is offering Arduino-compatible, industrial-grade programmable controllers. Their ProductivityOpen line is compatible with the Arduino IDE while having industrial certifications and hardening against harsh conditions, with a rich line of shields available to piece together complete automation controllers. For the home-gamer, an Arduino in an enclosure that can withstand harsh conditions and only cost $49 might fill a niche.

Speaking of Arduinos and Arduino accessories, better watch out if you’ve got any modules and you come under the scrutiny of an authoritarian regime, because you could be accused of being a bomb maker. Police in Hong Kong allegedly arrested a 20-year-old student and posted a picture of parts he used to manufacture a “remote detonated bomb”. The BOM for the bomb was strangely devoid of anything with wireless capabilities or, you know, actual explosives, and instead looks pretty much like the stuff found on any of our workbenches or junk bins. Pretty scary stuff.

If you’ve run through every binge-worthy series on Netflix and are looking for a bit of space-nerd entertainment, have we got one for you. Scott Manley has a new video that goes into detail on the four different computers used for each Apollo mission. We knew about the Apollo Guidance Computers that guided the Command Module and the Lunar Module, and the Launch Vehicle Digital Computer that got the whole stack into orbit and on the way to the Moon, but we’d never heard of the Abort Guidance System, a backup to the Lunar Module AGC intended to get the astronauts back into lunar orbit in the event of an emergency. And we’d also never heard that there wasn’t a common architecture for these machines, to the point where each had its own word length. The bit about infighting between MIT and IBM was entertaining too.

And finally, if you still find yourself with time on your hands, why not try your hand at pen-testing a military satellite in orbit? That’s the offer on the table to hackers from the US Air Force, proprietor of some of the tippy-toppest secret hardware in orbit. The Hack-A-Sat Space Security Challenge is aimed at exposing weaknesses that have been inadvertantly baked into space hardware during decades of closed development and secrecy, vulnerabilities that may pose risks to billions of dollars worth of irreplaceable assets. The qualification round requires teams to hack a grounded test satellite before moving on to attacking an orbiting platform during DEFCON in August, with prizes going to the winning teams. Get paid to hack government assets and not get arrested? Maybe 2020 isn’t so bad after all.

P-51 Cockpit Recreated with Help of Local Makerspace

It’s surprisingly easy to misjudge tips that come into the Hackaday tip line. After filtering out the omnipresent spam, a quick scan of tip titles will often form a quick impression that turns out to be completely wrong. Such was the case with a recent tip that seemed from the subject line to be a flight simulator cockpit. The mental picture I had was of a model cockpit hooked to Flight Simulator or some other off-the-shelf flying game, many of which we’ve seen over the years.

I couldn’t have been more wrong about the project that Grant Hobbs undertook. His cockpit simulator turned out to be so much more than what I thought, and after trading a few emails with him to get all the details, I felt like I had to share the series of hacks that led to the short video below and the story about how he somehow managed to build the set despite having no previous experience with the usual tools of the trade.

A Novel and a Film

Grant has been making short films for a while, mainly in collaboration with John Dwyer, an author of historical novels. Grant’s shorts are used as promos for John’s books, and nicely capture the period and settings of John’s novels. Most of these films required little in the way of special sets, relying instead on stock footage and vintage costumes to achieve their look and feel. John’s latest novel would change all that.

Called Mustang, the novel centers on a hotshot fighter pilot in WWII. Grant’s vision for the short to promote the book was inspired by the recent Christopher Nolan film Dunkirk, which featured intricate sequences filmed in the cockpit of a Spitfire. Granted wanted a similar look, and began arranging to use a real P-51 Mustang for filming. That presented immediate problems. First, there aren’t that many of the vintage aircraft left, and those that are still flying usually have anachronistic instruments in the cockpit, like GPS. Also, Grant wanted the instruments to respond as if the plane were airborne, and to have the shadows cast by the canopy into the cockpit suggest aerial maneuvers. Such an effect would be difficult to achieve with a plane stuck on a runway.

That’s when Grant realized that a gimballed cockpit simulator was needed. It could have a period-accurate dashboard, be positioned outdoors to take advantage of natural daylight and real backgrounds rather than CGI, and could be pitched, rolled and yawed to simulate flight. It would be perfect, and it would save the project. There was just one problem: he had no idea how to build it.

Helping Hands

Wisely, Grant turned to his local hackerspace, Dallas Maker Space, for help. There he found not only the tools he lacked, but kindred spirits with the necessary skills and the willingness to share them. They started working on the cockpit instrument panel, which ended up including a combination of actual flight hardware and mocked-up instruments. The fake instruments used steppers and an Arduino to drive the needles, which were controlled by a custom iPad app that was used to animate them live during filming. The real instruments, like the artificial horizon and turn-and-slip indicator, were powered by a vacuum pump and responded to the movements of the simulator on its gimbals.

The gimballed cockpit set for exterior shots. The wide horizon and natural lighting combined with the 3-DOF gimbal make for a very realistic effect.

Mounting this convincing panel into something was an entirely different undertaking. Grant relied heavily on the experience of DMS members to design a structure strong enough to support the actor and allow for the motion needed to create a convincing effect. The cockpit mockup, made from plasma-cut sheet metal and plywood, is mounted to a heavy-duty three-axis gimbal, including a massive bearing from a pallet jack for the yaw axis.

Set and talent, ready for action.

Grant had originally planned to place the mockup on a mountaintop for shooting, much as the Spitfire mockup from Dunkirk was placed on the edge of a cliff to give an unobstructed horizon to simulate flying over the English Channel. When that proved logistically challenging, he set up on an airport runway and used clever camera blocking to avoid shooting the horizon. Grips manually moved the simulator while Grant manipulated the fake instruments and filmed the results, which I think speak for themselves. If only the budget – and on-set safety – would have supported simulating the massive four-blade Mustang propeller, the illusion would have been complete.

I really enjoyed digging into this project and all the hacks that it entailed. Movie magic is as much about hacking as anything else, at least behind the cameras, and it’s good to see what’s possible with a limited budget. We recently featured a low-budget but high-style sci-fi movie set build, and we’ve gone in-depth with a playback designer for the Netflix series Lost in Space, both in these pages and as a Hack Chat.

 

 

New Part Day: Arduino Goes Pro with the Portenta H7

The Consumer Electronics Show in Las Vegas is traditionally where the big names in tech show off their upcoming products, and the 2020 show was no different. There were new smartphones, TVs, and home automation devices from all the usual suspects. Even a few electric vehicles snuck in there. But mixed in among flashy presentations from the electronics giants was a considerably more restrained announcement from a company near and dear to the readers of Hackaday: Arduino is going pro.

While Arduino has been focused on the DIY and educational market since their inception, the newly unveiled Portenta H7 is designed for professional users who want to rapidly develop robust hardware suitable for industrial applications. With built-in wireless hardware and the ability to run Python and JavaScript out of the box, the powerful dual-core board comes with a similarly professional price tag; currently for preorder at $99 USD a pop, the Portenta is priced well outside of the company’s traditional DIY and educational markets. With increased competition from other low-cost microcontrollers, it seems that Arduino is looking to expand out of its comfort zone and find new revenue streams.

That’s a Lot of Pins

The Portenta H7 is obviously a far cry from the relatively dinky 8-bit Arduinos that we’ve all got filling up our parts drawers. Developed for high performance edge computing applications, the new board is powered by a 32-bit STM32H747XI that utilizes both an ARM Cortex M7 and an M4 running at 480 MHz and 240 MHz respectively. The two cores can work independently, allowing for example one core to run interpreted Python while the other runs code compiled in the Arduino IDE. When they need to work together, the cores can communicate with each other via a Remote Procedure Call (RPC) mechanism.

The new 80-pin connectors on the Portenta

Outwardly, the new board doesn’t look far removed from the modern Arduino form factor we’re used to. The USB connector has been upgraded to a Type-C, but the Portenta still retains the dual rows of pads ready for hand-soldered headers — that’s their more recent pinout that they call the Arduino MKR form factor.

If you look on the back of the board however, you’ll see that they’ve added two 80-pin high density connectors. According to the product page, these are intended to allow the Portenta to simply be plugged into a device as a removable module. The idea being that devices in the field can easily have their Portenta swapped out for an upgraded model. Some digging into the product page documentation section turns up a schematic that lists the connectors as Hirose DF40C-80DP-0.4V(51).

The base model Portenta features 8 MB SDRAM and 16 MB NOR flash, but it can be custom ordered with up to 64 MB of memory and 128 MB of flash should you need it. It’s also possible to delete various interfaces from the board when ordering, so if you don’t want network connectivity or the NXP SE050C2 crypto chip, they can simply be left off. However as of this writing it is unclear as to what minimum order quantity is necessary to unlock this level of customization, or or how much these modifications will change the unit cost.

Year of the Arduino Desktop?

The Portenta Carrier Board

The Portenta H7 is an impressive enough piece of hardware on its own, but when it’s plugged into the optional Carrier Board, things really start to get interesting. The Carrier Board provides full size connectors for all of the onboard peripherals, and according to documentation, turns the Portenta into an eNUC-class embedded computer. There’s even support for DisplayPort to connect a monitor, and miniPCI for expansion cards.

With a fully loaded Portenta H7 slotted into the Carrier Board, it would seem you have the makings of a low-power ARM “desktop” computer. Albeit one that wouldn’t outperform the Raspberry Pi Zero, and which costs several times more.

The Arduino press release and product page doesn’t make any mention of what kind of software or operating system said computer would run, so presumably that’s left as an exercise for the customer. While not particularly well suited to it, the ARM Cortex-M family of processors is capable of running the Linux kernel, so spinning up a “real” OS image for it should be possible. Of course with a maximum of just 64 MB of RAM, you’ll want to keep your performance expectations fairly low.

Where Does Portenta Fit?

We can’t even speculate what a maxed out Portenta would cost, and there’s no pricing or release date for the Carrier Board. But even at $99, the base model Portenta H7 would be a tough sell for hackers and makers who are used to buying dual-core ESP32 boards at 1/10 of the price, or the Teensy 4.0 which has a 600 MHz Cortex-M7 at 1/4 of the price. Which is fine, since this board isn’t intended for the traditional core Arduino audience.

Seeing the carrier board, we can’t help but notice some parallels here with the Raspberry Pi Compute Module. With connections broken out to a SODIMM header, the idea of the Computer Module was to help bridge the gap between the DIY community and the commercial one by offering up a Raspberry Pi in a more rugged form factor that would be easier to integrate into end-user products. But since it wasn’t any cheaper than the stock Pi, there wasn’t a whole lot of incentive to switch over. We haven’t seen consumer products advertising “Raspberry Pi Inside!” so it’s hard to tell if there has been any meaningful adoption from industry.

One has to wonder why any company that has the resources to integrate such an expensive board into their products wouldn’t just come up with their own custom design around the Portenta’s STM32H747XI chip, which even in single quantities, can currently be had for less than $15. The difference may end up coming down to the world-renowned community that surrounds the Arduino brand, and the company’s efforts to modernize their toolchain.

Review: OSEPP STEM Kit 1, a Beginner’s All-in-One Board Found in the Discount Aisle

As the name implies, the OSEP STEM board is an embedded project board primarily aimed at education. You use jumper wires to connect components and a visual block coding language to make it go.

I have fond memories of kits from companies like Radio Shack that had dozens of parts on a board, with spring terminals to connect them with jumper wires. Advertised with clickbait titles like “200 in 1”, you’d get a book showing how to wire the parts to make a radio, or an alarm, or a light blinker, or whatever.

The STEM Kit 1 is sort of a modern arduino-powered version of these kits. The board hosts a stand-alone Arduino UNO clone (included with the kit) and also has a host of things you might want to hook to it. Things like the speakers and stepper motors have drivers on board so you can easily drive them from the arduino. You get a bunch of jumper wires to make the connections, too. Most things that need to be connected to something permanently (like ground) are prewired on the PCB. The other connections use a single pin. You can see this arrangement with the three rotary pots which have a single pin next to the label (“POT1”, etc.).

I’m a sucker for a sale, so when I saw a local store had OSEPP’s STEM board for about $30, I had to pick one up. The suggested price for these boards is $150, but most of the time I see them listed for about $100. At the deeply discounted price I couldn’t resist checking it out.

So does an embedded many-in-one project kit like this one live up to that legacy? I spent some time with the board. Bottom line, if you can find a deal on the price I think it’s worth it. At full price, perhaps not. Join me after the break as I walk through what the OSEPP has to offer.

What’s Onboard?

There are plenty of input and output devices:

  • 7 Push Buttons
  • Potentiometers (3 rotary and 1 slide)
  • Passive Infrared Sensor (PIR)
  • Light Sensor
  • Sound Sensor
  • LM35 Temperature Sensor
  • 10 LEDs (various colors)
  • Servo Motor
  • Stepper Motor
  • DC Motor
  • LCD Display
  • Buzzer
  • Speaker
  • RGB LED

In addition, the kit comes with an ultrasonic distance sensor in a little bracket that can connect to the stepper motor. That’s the only part that needs power and ground that isn’t already wired up.

Because the heart of the board is an Arduino UNO clone, you can do anything you like to program it. However, OSEPP touts their visual block diagram language that is basically Scratch. You can use it for free on most platforms and there is even a Web-based version although it can’t download code. It looks like Scratch or other block-oriented systems you’ve seen before.

I’m not usually fond of the visual block languages, but this one at least shows you the actual Arduino code it generates, so that isn’t bad. But you can still use any other method you like such as the standard IDE or PlatformIO.

You can see a video about the board, below.

The Good and the Bad

The board feels substantial and able to withstand a good bit of abuse. There’s a good range of components, and I like that the arduino is a real daughter board and not just built onto the PCB. Despite using the block language, I do like the tutorial booklet. It is very slick and has projects ranging from an IR doorbell to a mini piano. You can see a page below — very colorful and clear.

Of course, the suggested retail price of $150 is a bit offputting. You might think a breadboard with a handful of LEDs and other parts would be a much lower-cost option but just look around for arduino kits for beginners and you’ll find prices are all over the place. On the other hand, with a parts kit you would have to know how to wire up things like stepper motors or DC motors, so there is some value to having it already done for you. There’s also value in not having a bag of parts to misplace.

The jumper wires in the kit have pins on one side and sockets on the other. The pins go into the Arduino’s connector and the sockets go over pins on the components. These aren’t quite as reliable as a spring clip and not as versatile either.

In my mind the worst part of the kit design is that the pins are right next to each of the components. That’s good for understanding, but it makes a mess of wiring. For instance, there are ten LEDs, and connecting them all means stretching jumper wires to both edges of the board The jumpers aren’t very long either, so any complex project is going to have wires crisscrossing the sensors and LCD.

Granted, in this image I could have removed some of the wires from the bundles but that wouldn’t help that much, either. If you need to hook up more than a few of the available components you will have a mess. I would have put some sort of spring clip or even screw terminals and put them all on the top and bottom of the board with clear color-coded marking about where they connect. Then the wiring would all be out of the way. There are probably a few other ways they could have gone, and at this price, they could afford the few extra inches on the PCB.

There are a few other things that would have been nice touches to finish off this kit. I would have enjoyed a short chapter in the booklet about using the Arduino IDE directly so that people know it exists. And having even a small breadboard attached for your own exploration would make sense, but would then call for a different type of jumper wire.

Short Example Using the Distance Sensor

I wanted to do something with the board so I decided to play with the distance sensor and the servo. The distance sensor is a bit annoying both because you have to wire it all up and it has a tendency to fall off when you transport the board.

The demo (you can find it online) won’t win any originality prizes. The program moves the servo to scan from 0 to 180 degrees in 5 degree increments. It measures the distance of what’s in front of it. When it completes a scan, if it saw something close (you could adjust the sensitivity), it moves the sensor back to that position and waits 30 seconds. Otherwise, it keeps scanning.

Really, this is no different from any other Arduino program. That’s kind of the point. Despite the emphasis in the book on the point-and-click language, this is really just an Arduino.

In Summary

For the deep sale price I found, the board will work well for its intended audience of students or anyone starting out with Arduino or microcontrollers. Even a more advanced audience who just wants a way to hammer out a quick prototype might find it worth the $30 or $40 you can sometimes pay. But at full price, it is hard to imagine this makes sense because of the mess of wire routing and limited expansion options.

Ask Hackaday Answered: The Tale of the Top-Octave Generator

We got a question from [DC Darsen], who apparently has a broken electronic organ from the mid-70s that needs a new top-octave generator. A top-octave generator is essentially an IC with twelve or thirteen logic counters or dividers on-board that produces an octave’s worth of notes for the cheesy organ in question, and then a string of divide-by-two logic counters divide these down to cover the rest of the keyboard. With the sound board making every pitch all the time, the keyboard is just a simple set of switches that let the sound through or not. Easy-peasy, as long as you have a working TOG.

I bravely, and/or naïvely, said that I could whip one up on an AVR-based Arduino, tried, and failed. The timing requirements were just too tight for the obvious approach, so I turned it over to the Hackaday community because I had this nagging feeling that surely someone could rise to the challenge.

The community delivered! Or, particularly, [Ag Prismatic]. With a clever approach to the problem, some assembly language programming, and an optional Arduino crystalectomy, [AP]’s solution is rock-solid and glitch-free, and you could build one right now if you wanted to. We expect a proliferation of cheesy synth sounds will result. This is some tight code. Hat tip!

Squeezing Cycles Out of a Microcontroller

Let’s take a look at [AP]’s code. The approach that [AP] used is tremendously useful whenever you have a microcontroller that has to do many things at once, on a rigid schedule, and there’s not enough CPU time between the smallest time increments to do much. Maybe you’d like to control twelve servo motors with no glitching? Or drive many LEDs with binary code modulation instead of primitive pulse-width modulation? Then you’re going to want to read on.

There are two additional tricks that [AP] uses: one to fake cycles with a non-integer number of counts, and one to make the AVR’s ISR timing absolutely jitter-free. Finally, [Ag] ended up writing everything in AVR assembly language to make the timing work out, but was nice enough to also include a C listing. So if you’d like to get your feet wet with assembly, this is a good start.

In short, if you’re doing anything with hard timing requirements on limited microcontroller resources, especially an AVR, read on!

Taking Time to Think

The goal of the top-octave generator is to take an input clock and divide it down into twelve simultaneous sub-clocks that all run independently of each other. Just to be clear, this means updating between zero and twelve GPIO pins at a frequency of 1 MHz or so — updating every twenty clock cycles at the AVR’s maximum CPU speed. If you thought you could loop through twelve counters and decide which pins to flip in twenty cycles, you’d be mistaken.

But recognizing the problem is the first step to solving it. Although the tightest schedule might require flipping one pin exactly twenty clocks after flipping another, most of the time there are more cycles between pin updates — hundreds up to a few thousand. So the solution is to recognize when there is time to think, and use this time to pre-calculate a buffer full of next states.

[Ag]’s solution uses a few different loops that run exactly 20, 40, and 60 cycles each — the longer versions being just the 20-cycle one padded out with NOPs. These loops run inside an interrupt-service routine (ISR). When there are 80 or more cycles of thinking time until the next scheduled pin change, control is returned to the main loop and the next interrupt is set to re-enter the tight loops at the next necessary update time.

All the fast loop has to do is read two bytes, write them out to the GPIO pins, increment the pointer to the next row of data, and figure out if it needs to stall for 20 or 40 additional cycles, or set the ISR timer for longer delays and return to calculations. And this it can do in just twelve of the twenty cycles! Slick.

Buffers

Taking a step back from the particulars of the top-octave generator, this is a classic problem and a classic solution. It’s worth your time to internalize it, because you’ll run into this situation any time you have real-time constraints. The problem is that on average there’s more than enough time to complete the calculations, but that in the worst cases it’s impossible. So you split the problem in two parts: one that runs as fast as possible, and one that does the calculations that the fast section will need. And connecting together fast and slow processes is exactly why computer science gave us the buffer.

In [AP]’s code, this buffer is a table where each entry has two bytes for the state of the twelve GPIO pins, and one byte to store the number of clock cycles to delay until the next update. One other byte is left empty, yielding 64 entries or 256 bytes for the whole table. Why 256 bytes? Because the AVR has an 8-bit unsigned integer, wrapping around from the end of the table back to the beginning is automatic, saving a few cycles of wasteful if statements.

But even with this fast/slow division of labor, there is not much time left over for doing the pre-calculation. Sounding the highest C on a piano keyboard (4186 Hz) with a 20 MHz CPU clock requires toggling a GPIO pin every 2,390 cycles, so that’s the most time that the CPU will ever see. When the virtual oscillators are out of phase, this can be a lot shorter. By running the AVR at its full 20 MHz, and coding everything in assembly, [AP] can run the calculations fast enough to support twelve oscillators. At 16 MHz, there’s only time for ten, so every small optimization counts.

Some Optimization Required

Perhaps one of the cleverest optimizations that [AP] made is the one that makes this possible at all. The original top-octave chips divide down a 2 MHz square wave by a set of carefully chosen integer divisors. Running the AVR equivalent at 2 MHz resolution would mean just ten clocks per update and [AP]’s fast routine needed twelve, so the update rate would have to be halved. But that means that some odd divisors on the original IC would end up non-integral in the AVR code. For example, the highest C is reproduced in silicon as 2 MHz / 239, so to pull this off at 1 MHz requires counting up to 119.5 on an integer CPU. How to cope?

You could imagine counting to 119 half of the time, and 120 the other. Nobody will notice the tiny difference in duty cycle, and the pitch will still be spot on. The C programmer in me would want to code something like this:

uint8_t counter[12] = { 0, ... };
uint8_t counter_top[12] = { 119, ... };
uint8_t is_counter_fractional[12] = { 1, 0, ... };
uint8_t is_low_this_time[12] = { 0, ... };

// and then loop
for ( i=0 ; i<12; ++i){
  if ( counter[i] == 0 ){
    if ( is_counter_fractional[i] ){
      if ( is_low_this_time[i] ){
        counter[i] = counter_top[i];
    is_low_this_time = 0;
      else {
        counter[i] = counter_top[i] + 1;
    is_low_this_time = 1;
      }
    }
  }
}

That will work, but the ifs costs evaluation time. Instead, [AP] did the equivalent of this:

uint8_t counter[12] = { 0, ... };
uint8_t counter_top[12] = { 119, ... };
uint8_t phase[12] = { 1, 0, ... };

for ( i=0 ; i<12; ++i){
  if ( counter[i] == 0 ){
    counter[i] = counter_top[i] + phase[i];
    counter_top[i] = counter[i];
    phase[i] = -phase[i];
  }
}

What’s particularly clever about this construction is that it doesn’t need to distinguish between the integer and non-integer delays in code. Alternately adding and subtracting one from the non-integer values gets us around the “half” problem, while setting the phase variable to 0 means that the integer-valued divisors run unmodified, with no ifs.

The final optimization shows just how far [AP] went to make this AVR top-octave generator work like the real IC. When setting the timer to re-enter the fast loop in the ISR, there’s the possibility for one cycle’s worth of jitter. Because AVR instructions run in either one or two clock cycles, it’s possible that a two-cycle instruction could be running when the ISR timer comes due. Depending on luck, then, the interrupt will run four or five clocks later: see the section “Interrupt Response Time” in the AVR data sheet for details.

In a prologue to the ISR, [AP]’s code double-checks the hardware timer to see if it has entered on a one-cycle instruction, and adds in an extra NOP to compensate. This makes the resulting oscillator nearly jitter free, pushing out a possible source of 50 ns (one cycle at 20 MHz) slop. I don’t think you’d be able to hear this jitter, but the result surely looks pretty on the oscilloscope, and this might be a useful trick to know if you’re ever doing ultra-precise timing with ISRs.

The Proof of the Pudding

Naturally, I had to test out this code on real hardware. The first step was to pull a random Arduino-clone out of the closet and flash it in. Because “Arduinos” run at 16 MHz with the stock crystal, the result is that a nominal 440 Hz concert A plays more like a slightly sharp F, a musical third down. It sounds fine on its own, but you won’t be able to play along with any other instruments that are tuned to 440 Hz.

[AP]’s preferred solution is to run the AVR chip at 20 MHz. Since the hardware requirements are very modest, you could use a $0.50 ATTiny816 coupled with a 20 MHz crystal and you’d have a top-octave generator for literal pocket change — certainly cheaper than buying even an Arduino clone. I tested it out with an ATMega48P and a 20 MHz crystal on a breadboard because it’s what I had. Or you could perform crystalectomy on your Arduino to get it running at full speed.

We went back and forth via e-mail about all the other (firmware) options. [AP] had tried them all. You could trim the ISR down to 16 cycles and run at 16 MHz, but then there’s only enough CPU time in the main loop to support ten notes, two shy of a full octave. You could try other update rates than 1 MHz, but the divisors end up being pretty wonky. To quote [AP] from our e-mail discussion on the topic:

“After playing with the divider values from the original top octave generator IC and trying different base frequencies, it appears that the 2 MHz update rate is a “sweet spot” for getting reasonable integer divisors with < +/-2 cents of error. The original designers of the chip must have done the same calculations.”

To make a full organ out of this setup, you’ll also need twelve binary counter chips to divide down each note to fill up the lower registers of the keyboard, but these are easy to design with and cost only a few tens of cents apiece. All in all, thanks to [AP]’s extremely clever coding, you can build a fully-polyphonic noisemaker that spits out 96 simultaneous pitches, all in tune, for under $10. That’s pretty amazing.

And of course, I’ve already built a small device based on this code, but that’s a topic for another post. To be continued.

Hands-On with New Arduino FPGA Board: MKR Vidor 4000

Hackaday brought you a first look the Arduino MKR Vidor 4000 when it announced. Arduino sent over one of the first boards so now we finally have our hands on one! It’s early and the documentation is still a bit sparse, but we did get it up and running to take the board through some hello world exercises. This article will go over what we’ve been able to figure out about the FPGA system so far to help get you up and running with the new hardware.

Just to refresh your memory, here’s what is on the Vidor board:

  • 8 MB SRAM
  • A 2 MB QSPI Flash chip — 1 MB allocated for user applications
  • A Micro HDMI connector
  • An MIPI camera connector
  • Wi-Fi and BLE powered by a U-BLOX NINA W10 Series device
  • MKR interface on which all pins are driven both by SAMD21 (32-bit ARM CPU) and FPGA
  • Mini PCI Express connector with up to 25 user programmable pins
  • The FPGA (an Intel/Altera Cyclone 10CL016) contains 16K Logic Elements, 504 KB of embedded RAM, and 56 18×18 bit HW multipliers

Sounds good. You can get more gory technical details over at Arduino and there’s even a schematic (.zip).

Documentation

Documentation is — so far — very hard to come by but the team is working to change that by the day. Here are the resources we’ve used so far (in addition to the schematic):

In addition, Arduino just released an example FPGA project for Quartus. I’ll explain what that means in a bit.

Get Up and Running with the Arduino Desktop IDE

Despite the getting started guide, it doesn’t appear the libraries are usable from the cloud-based IDE, so we followed the instructions to load the beta board support for the MKR 4000 into our desktop IDE. Be aware that the instructions show the “normal” SAMD board package, but you actually want the beta which says it is for the MKR 4000. If you search for SAMD in the Boards Manager dialog, you’ll find it (see the second entry in the image below).

 

The libraries we grabbed as ZIP files from GitHub and used the install library from ZIP file option with no problems.

What’s the Code Look Like?

The most interesting part of this board is of course the inclusion of the FPGA which left us wondering what the code for the device would look like. Browsing the code, we were a bit dismayed at the lack of comments in all but the JTAG code. We decided to focus first on the VidorPeripherals repository and dug into the header file for some clues on how everything works.

Looking at VidorPeripherals.h, you can see that there’s a few interesting I/O devices include SPI, I2C, UART, reading a quadrature encoder, and NeoPixel. There’s also a few headers that don’t exist (and presumably won’t get the define to turn them on) so don’t get too excited by some of the header file names until you make sure they are really there.

Then we decided to try the example test code. The library provides a global FPGA object that you need to set up:

// Let's start by initializing the FPGA
if (!FPGA.begin()) {
    Serial.println("Initialization failed!");
    while (1) {}
}

// Let's discover which version we are running
int version = FPGA.version();
Serial.print("Vidor bitstream version: ");
Serial.println(version, HEX);

// Let's also ask which IPs are included in this bitstream
FPGA.printConfig();

The output of this bit of code looks like this:

Vidor bitstream version: 1020107
number of devices 9
1 01000000 MB_DEV_SF
1 02000000 MB_DEV_GPIO
4 04000000 MB_DEV_I2C
6 05000000 MB_DEV_SPI
8 06000000 MB_DEV_UART
1 08000000 MB_DEV_SDRAM
4 09000000 MB_DEV_NP
11 0A000000 MB_DEV_ENC
0 0B000000 MB_DEV_REG

In many cases, the devices provided by the FPGA are pretty transparent. For example, here’s another snip from the example code:

// Ok, so we know now that the FPGA contains the extended GPIO IP
// The GPIO pins controlled by the FPGA start from 100
// Please refer to the online documentation for the actual pin assignment
// Let's configure pin A0 to be an output, controlled by the FPGA
FPGA.pinMode(33, OUTPUT);
FPGA.digitalWrite(33, HIGH);

// The same pin can be read by the SAMD processor :)
pinMode(A0, INPUT);
Serial.print("Pin A0 is ");
Serial.println(digitalRead(A0) == LOW ? "LOW" : "HIGH");

FPGA.digitalWrite(33, LOW);
Serial.print("Pin A0 is ");
Serial.println(digitalRead(A0) == LOW ? "LOW" : "HIGH");

That’s easy enough and it is nice that the pins are usable from the CPU and FPGA. We couldn’t find the documentation mapping the pins, but we assume it is coming.

Using, say, an extra serial interface is easy, too:

SerialFPGA1.begin(115200);
while (!SerialFPGA1);
SerialFPGA1.println("test");

Bitstream

So where’s the FPGA code? As far as you can tell, this is just a new Arduino with a lot of extra devices that connect through this mysterious FPGA object. The trick is that the FPGA code is in the library. To see how it works, let’s talk a little about how an FPGA operates.

When you write a program in C, that’s not really what the computer looks at, right? The compiler converts it into a bunch of numbers that tell the CPU to do things. An FPGA is both the same and different from that. You write your program — usually in a hardware design language like Verilog or VHDL. You compile it to numbers, but those numbers don’t get executed like a CPU does.

The best analogy I’ve been able to think of is that an FPGA is like one of those old Radio Shack 100-in-1 electronic kits. There are a bunch of parts on a board and some way to connect them with wires. Put the wires one way and you have a radio. Put them another way and you have a burglar alarm. Rewire it again and you have a metal detector. The numbers correspond to wires. They make connections and configure options in the FPGA’s circuitry. Unless you’ve built a CPU, there’s nothing in there examining and acting on the numbers like there would be with a CPU.

The numbers that come out of an FPGA tool is usually called a bitstream. Someone has to send that bitstream to an FPGA like the Cyclone onboard the Arduino every time it powers up. That someone is usually a memory device on the board, although the CPU can do it, too.

So that leads to two questions: Where is the bitstream? How does it get to the FPGA?

The answer to the first question is easy. If you look on Github, you’ll see in the library there is a file called VidorBase.cpp. It has the following lines:

__attribute__ ((used, section(".fpga_bitstream")))
const unsigned char bitstream[] = {
    #include "app.ttf"
};

What this means if there is an array called bitstream that the linker will put it in a specially marked section of memory. That array gets initialized with app.ttf which is just an ASCII file full of numbers. Despite the name, it is not a TrueType font. What do the numbers mean? Hard to say, although, in theory, you could reverse engineer it just like you can disassemble binary code for a CPU. However, it is the configuration required to make all the library calls we just talked about work.

The second question about how it gets to the FPGA configuration is a bit of a mystery. As far as we can tell, the bootloader understands that data in that section should get copied over to the FPGA configuration memory and does the copying for you. It isn’t clear if there’s a copy in the main flash and a copy in the configuration flash but it seems to work transparently in any event.

There’s a checksum defined in the code but we changed it and everything still worked. Presumably, at some point, the IDE or the bootloader will complain if you have the wrong checksum, but that doesn’t appear to be the case now.

By the way, according to the Arduino forum, there are actually two bitstreams. One that loads on power-up that you would rarely (if ever) change. Then there is another that is the one included with the library. You can double-click the reset button to enter bootloader mode and we suspect that leaves the FPGA initialized with the first bitstream, but we don’t know that for sure. In bootloader mode, though, the red LED onboard has a breathing effect so you can tell the double click works.

What about my FPGA Code?

This isn’t great news if you were hoping for an easy Arduino-like way to do your own FPGA development in Verilog or VHDL. Intel will give you a copy of Quartus Prime which will generate bitstreams all day for you. We think — but we aren’t sure — that the ASCII format is just a raw conversion from binary of the bitstream files.

Very recently, Arduino provided a Quartus project that would create a bitstream. This provides a few key pieces of the puzzle, like the constraint file that lets the FPGA compiler find the different parts on the board.

However, even with that project, you still have some reverse engineering to do if you want to get started. Why? Here’s what Arduino says about loading your own FPGA code (we added the emphasis):

Quartus will produce a set of files under the output_files directory in the project folder. In order to incorporate the FPGA in the Arduino code you need to create a library and preprocess the ttf file generated by Quartus so that it contains the appropriate headers required by the software infrastructure. Details of this process will be disclosed as soon as the flow is stable.

Programming the FPGA is possible in various ways:

  • Flashing the image along with Arduino code creating a library which incorporates the ttf file
  • Programming the image in RAM through USB Blaster (this requires mounting the FPGA JTAG header). this can be done safely only when SAM D21 is in bootloader mode as in other conditions it may access JTAG and cause a contention
  • Programming the image in RAM through the emulated USB Blaster via SAM D21 (this component is pending release)

In addition, the repository itself says that some key pieces are missing until they can work out licensing or clean up the code. So this gets us closer, but you’d still need to reverse engineer the header from the examples and/or figure out how to force the processor off the JTAG bus. The good news is it sounds like this information is coming, it just isn’t here yet.

Of course, you are going to need to understand a lot more to do anything significant. We know the FPGA is set in the AS configuration mode. We also asked Arduino about the clock architecture of the board and they told us:

[The CPU] has its own clock which is used to generate a 48 MHz reference clock that is fed to the FPGA (and that can be removed at any time to “freeze” fpga). In addition to this reference clock, [the] FPGA has an internal RC oscillator which can’t be used as [a] precise timing reference for tolerance issues but can be used in case you don’t want [the CPU] to produce the reference clock.

Of course, the FPGA has a number of PLLs onboard that can take any valid clock and produce other frequencies. For example, in the vision application, Arduino demonstrated, the 48 MHz clock is converted into 24 MHz, 60 MHz, 100 MHz, and 120 MHz clocks by PLLs.

Mix and Match?

One thing that is disappointing is that — at least for now — you won’t be able to mix and match different FPGA libraries. There is exactly one bitstream and you can’t just jam them together.  Although FPGAs can often be partially configured, that’s a difficult technique. But we were a little surprised that the IDE didn’t understand how to take libraries with, for example, EDIF design files for IP that would all get compiled together. That way I could pick the Arduino UART and mix it with the Hackaday PWM output module along with my own Verilog or VHDL.

The way things are structured now you will have one bitstream that is precompiled by another tool (probably Quartus for the foreseeable future). It will match up with a particular C++ library. And that’s it. Doesn’t matter how much of the FPGA is left over or how much of it you really use, you will use it all for the one library.

Of course, you can load another library but it is going to replace the first one. So you only get one set of functions at a time and someone else gets to decide what’s in that set. If you roll your own, you are going to have to roll your own all the way.

What’s Next?

It is still early for the Arduino Vidor. We are hopeful we’ll get the tools and procedures necessary to drop our own FPGA configurations in. It would be great, too, if the stock libraries were available in source format including the Verilog HDL. The recent GitHub release shows quite a bit, although it isn’t all of the examples, it is probably enough if we get the rest of the information.

As for a more intuitive interface, we don’t know if that’s in the cards or not. We don’t see much evidence of it, although posts on the Arduino forum indicate they will eventually supply an “IP Assembler” that will let you compose different modules into one bitstream. We don’t know if that will only work with “official” modules or not. However, we know the Arduino community is very resourceful so if we don’t get a good ecosystem it will not surprise us if someone else makes it happen. Eventually.

For now, we will continue to play with the existing bitstreams that become available. There are some neat new features on the CPU, too. For example, you can map two of the unused serial modules.  There’s a hardware-based cooperative multitasking capability. As more details on the FPGA emerge, we’ll keep you posted and if you learn something, be sure to leave word in the comments so everyone can benefit.

Entropy and The Arduino: When Clock Jitter is Useful

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

A shift register configured as a pseudo-random
number generator. [by KCAuXy4p CC0 1.0]
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the  shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The not-very-random result of a thousand analogRead() calls.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The significantly more random result of a thousand Arduino Entropy Library calls.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]


Filed under: Arduino Hacks, Hackaday Columns, Microcontrollers, Skills

KIM-1 to COSMAC Elf Conversion — Sort Of

In the mid-1970s, if you had your own computer, you probably built it. If you had a lot of money and considerable building skill, you could make an Altair 8800 for about $395 — better than the $650 to have it built. However, cheaper alternatives were not far behind.

In 1976, Popular Electronics published plans for a computer called the COSMAC Elf which you could build for under $100, and much less if you had a good junk box. The design was simple enough that you could build it on a piece of perf board or using wire wrap. We featured the online archive of the entire Popular Electronics collection, but hit up page 33 of this PDF if you want to jump right to the article that started it all. The COSMAC Elf is a great little machine built around a 40-pin RCA 1802 processor, and for many was the first computer they owned. I lost my original 1802 computer in a storm and my recent rebuild in another completely different kind of storm. But there is a way to reclaim those glory days without starting from scratch.  I’m going to repurpose another retro-computing recreation; the KIM-1.

I’ll admit it, Rewiring a real KIM-1 to take an 1802 CPU would be difficult and unnecessary and that’s not what this article is about. However, I did have a KIM UNO — [Oscar’s] respin of the classic computer using an Arduino mini pro. Looking at the keyboard, it occurred to me that the Arduino could just as easily simulate an 1802 as it could a 6502. Heck, that’s only two digits different, right?

The result is pretty pleasing. A “real” Elf had 8 toggle switches, but there were several variations that did have keypads, so it isn’t that far off. Most Elf computers had 256 bytes of memory (without an upgrade) but the 1802 UNO (as I’m calling it) has 1K. There’s also a host of other features, including a ROM and a monitor for loading and debugging programs that doesn’t require any space in the emulated 1802.

Repurpose

The KIM UNO has 24 switches. There are 16 for the hex digits, of course. The top two rows mimic functions from the original KIM-1. A real Elf had a way to input a byte (usually 8 toggle switches), a load switch, a run switch, a memory protect switch, and a push button wired to a CPU pin. That means the hardware has more than enough switches.

On the display side, a normal Elf had a single-byte hex display although some clones had more. There was also the Q LED that a program could light or extinguish. The KIM UNO hardware has many 7-segment displays so it is possible to put those digits to use like an Elf clone. There isn’t an LED, however, except for the Arduino’s built in LED which is not normally visible in operation. However, the digital displays have decimal points and they are connected to the Arduino. So if you don’t mind using those, you have plenty of LEDs, too.

The hardware is open source and easy to duplicate. [Oscar] sometimes has kits as well and they are very inexpensive (about $20).

The KIM UNO software is open source, so I started there. I first stripped all the code out of the main file other than the parts that drove the display and the keyboard, then built up everything need to suppot 1802 emulation. You can find all the code in my 1802UNO GitHub repository.

Inside the 1802

The 1802 instruction set is very regular and quite simple. Most instructions use the top 4 bits as an op code and the bottom 4 bits to select one of sixteen 16-bit registers. So 0x12 increments register 2 and 0x15 increments register 5. There are only a handful of op codes that don’t follow this pattern. There’s also an 8-bit accumulator called “D” (not to be confused with register D).

One unique feature in the 1802 architecture is the program counter. There isn’t one. Well, more precisely, there are up to 16. Any of the registers can be the program counter and a subroutine call can be as simple as switching the program counter. Unfortunately, that isn’t very reentrant (or good for recursion). If you want a proper subroutine call, you had to code it yourself. RCA provided the “standard call and return technique” that had the unfortunate downside of destroying the accumulator.

With so few instructions, the emulator turns out to be a few switch statements and some pretty simple code. Although it is made to run with the KIM UNO hardware, like the KIM UNO, you should be able to use it with just about any Arduino via the serial port. It isn’t quite as fun as having the real hardware, but it is simpler.

Unreal

The emulator is reasonably accurate except it doesn’t simulate interrupts (since there is no source of them). However, it doesn’t faithfully reproduce the 1802’s load mode which used DMA. Instead, load mode is just completely custom code that enters data into memory. It does not simulate the cycle and register manipulations that go on in a real 1802 using DMA in load mode.

In addition to loading a program with the ersatz load mode, you can also move RAM back and forth to EEPROM or a PC via the serial port.

Serial and Push Buttons

The serial port is just the usual Arduino serial port set for 9600 baud. By default, the serial input will mimic the hardware keys. However, you can use the pipe character (‘|’) to shift the serial port into terminal mode. Then the 1802 code can read data from the serial port. You lose the front panel functions and there’s no way to go back until you cycle the power unless you make the 1802 code release the port.

A few of the push buttons have special functions if you hold them down for more than one second. For example, the AD button writes the EEPROM data into RAM. This is useful for storing a self-contained demo, for example.

You can find a summary of the keyboard and serial commands on the GitHub site. The serial port can do things you can’t do from the front panel, like set a trace mode, dump the CPU registers, and more.

Building

The hardware doesn’t require any changes to the stock KIM UNO kit. There’s a lot to solder and once you solder the displays on, it would be hard to get the Arduino back off the board.

You could probably build the software using the Arduino IDE, but I used Platform IO. That lets me use the editor of my choice, but you ought to be able to get the code to work in the IDE, as well. There is enough memory to make the RAM slightly bigger, but I didn’t do it. Since one way to save and load the RAM is to EEPROM, I didn’t want the RAM to be larger than the EEPROM. In addition, the RAM “maps” like a real Elf (that is, RAM at location 0x0 also appears at 0x4000, 0x8000, etc). This would be more difficult if you added a little bit more than 1K of RAM.

There are a few other options at the top of 1802config.h. You can select how often the screen and keyboard refresh. Higher values are slower to refresh but faster to execute code. You can change the I/O ports associated with the keyboard, displays, and serial port. You can also change the serial escape character.

Examples

There are some examples provided that blink the LEDs and manipulate the serial port. If you look around, there’s a lot of 1802 code on the web. However, be aware that most 1802s don’t have a hardware UART. They emulate serial ports using the Q output and one of the EF inputs. That’s fine for a real device even though it takes lots of code, but for this virtual device, it isn’t practical. You’ll need to rip out any code that does serial I/O and replace it with single I/O instructions.

If you have a binary file (or a format you can convert to binary) I have a converter written in C included on GitHub. You can compile it on nearly any platform and use it to convert. It always assumes address. If that’s not right, you can always open the output in a text editor and adjust.

In addition, there are three ROMs included that you can try. By default, there is a simple high-low game. There are also two monitors, one for use with the built-in keyboard and another for use with a serial port. To select a ROM, edit 1802rom.h and change the comments so the ROM you want is not commented and the others are.

Practical?

Emulators are fun, but as the song goes, there’s nothing like the real thing. If that’s not authentic enough for you, it is possible to build a very authentic looking Elf, even today. The reason real 1802s are still around is they had several desirable characteristics, namely low power consumption and resistance to radiation.

The Arduino simulation has neither of those features. However, it is a fun retrocomputing toy, inexpensive, and a great learning tool. The CPU is simple enough to program directly in machine code and the portability is better than most other old school computers.

If you want to learn more about the 1802 there are several sites dedicated to it and a very helpful Yahoo group. One site has a very prolific software author, but most of the code won’t fit in the 1802 UNO’s 1K RAM. Maybe a version with more memory is in the future.


Filed under: Arduino Hacks, classic hacks, computer hacks, Hackaday Columns

First Look at ABC: Basic Connections

[Alberto Piganti], aka [pighixxx] has been making circuit diagram art for a few years now, and has just come out with a book that’s available on Kickstarter. He sent us a copy to review, and we spent an hour or so with a refreshing beverage and a binder full of beautiful circuit diagrams. It doesn’t get better than that!

[pighixxx] started out making very pretty and functional pinout diagrams for a number of microcontrollers, and then branched out to modules and development boards like the Arduino and ESP8266. They’re great, and we’ll admit to having a printout of his SMD ATMega328 and the ESP-12 on our wall. His graphical style has been widely copied, which truly is the sincerest form of flattery.

But after pinouts, what’s next? Fully elaborated circuit diagrams, done in the same style, of course. “ABC: Basic Connections” started out life as a compendium of frequently used sub-circuits in Arduino projects. But you can take “Arduino” with a grain of salt — these are all useful for generic microcontroller-based projects. So whether you want to drive a 12 V solenoid from a low-voltage microcontroller, drive many LEDs with shift registers, or decode a rotary encoder, there is a circuit snippet here for you.

One of the things that we like most about the graphics in “ABC” is that they’re not dumbed down — they’re fundamentally just well-done circuit diagrams, but with graphic touches and extra detail where it actually helps to clarify things. This is a middle ground between the kind of schematic you use in a PCB layout program and the kind of diagram you get from Fritzing. In the former, every part has a symbol but multifunction parts like microcontrollers are just represented as squares bristling with pin numbers. In the latter, wiring up an IC is easy because the parts and pins are represented graphically, but you quickly run out of colors for the different wires, and the “breadboard” turns into a rat’s nest with a circuit of any complexity.

“ABC” takes the middle road, using standard circuit diagram style overall, but also the nice graphic representations of the ICs and modules that [pighixxx] is good at. Is a 2N2222 pinned EBC or BCE? You don’t have to look that up, because it’s sketched out for you here. We’d guess that this attractive, but information-rich, style is a great fit for the target audience — people with some electronics experience who do not yet have their favorite transistor symbol tattooed on their forearm. [pighixxx]’s diagrams are simple, easy to understand, easy to use, and pretty to boot.

There is a planned online counterpart to the book, with further elaborations of all of the circuit setups. They’re not finished yet, but they have a lot more of the flavor of the Fritzing-style, this-wire-goes-to-that-hole diagrams. This style does work better in an online format than in a physical book, because you can build up the rat’s nest in bite-sized steps, none of which are too overwhelming. But honestly, for an advanced beginner or intermediate electronics hacker, the book can be treated as stand-alone. The web content may help the rank newbie when they get stuck.

Tee-hee.

The breadth of circuits in “ABC” is fairly wide, covering most of the microcontroller-interfacing problems that we’ve ever encountered. None of the circuits are revolutionary — they’re the tried-and-true, correct solutions to the various problems, rather than anything too hacky or clever. We weren’t surprised by any of the circuits, but we didn’t find anything that we wouldn’t use ourselves either. These are basic connections after all, and a darn solid collection of them.

To sum up, “ABC” is an attractive book in a handy binder format that would make a great collection of solutions for anyone who’s just getting started in the whole “Arduino” scene but who gets hung up on interfacing the chips with the real world. It’s a handy reference for the pinouts of a number of frequently used parts, combined with the resistors, flyback diodes, level-shifting circuits, and whatever else that you’d need to make them work. It’s what we wish our simple circuit diagrams looked like. We like it.


Filed under: Hackaday Columns, reviews

Friday Hack Chat: Tenaya Hurst From Arduino

Join us this Friday at noon PDT for a Hack Chat with Tenaya Hurst of Arduino. If you’ve been one of the big Maker Faires over the last few years (or innumerable other live events) and stopped by the Arduino area you’ve probably met Tenaya. She is the Education Accounts Manager for Arduino and loves working with wearable electronics.

Come and discuss maker education and the role Arduino is playing in getting our students excited about electronics, and STEAM education in general. Tenaya will also be discussing a new wearable tech kit she’s been working on. We hope to see the gear in person at Bay Area Maker Faire next week.

Here’s How To Take Part:

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging.

Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.


Filed under: Arduino Hacks, Hackaday Columns, wearable hacks