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.
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 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 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.
If you’ve been hanging around microcontrollers and electronics for a while, you’re surely familiar with the concept of the breakout board. Instead of straining to connect wires and components to ever-shrinking ICs and MCUs, a breakout board makes it easier to interface with the device by essentially making it bigger. The Arduino itself, arguably, is a breakout board of sorts. It takes the ATmega chip, adds the hardware necessary to get it talking to a computer over USB, and brings all the GPIO pins out with easy to manage header pins.
But what if you wanted an even bigger breakout board for the ATmega? Something that really had some leg room. Well, say no more, as [Nick Poole] has you covered with his insane RedBoard Pro Micro-ATX. Combining an ATmega32u4 microcontroller with standard desktop PC hardware is just as ridiculous as you’d hope, but surprisingly does offer a couple tangible benefits.
The RedBoard is a fully compliant micro-ATX board, and will fit in pretty much any PC case you may have laying around in the junk pile. Everything from the stand-off placement to the alignment of the expansion card slots have been designed so it can drop right into the case of your choice.
That’s right, expansion slots. It’s not using PCI, but it does have a variation of the standard Arduino “shield” concept using 28 pin edge connectors. There’s a rear I/O panel with a USB port and ISP header, and you can even add water cooling if you really want (the board supports standard LGA 1151 socket cooling accessories).
While blowing an Arduino up to ATX size isn’t exactly practical, the RedBoard is not without legitimate advantages. Specifically, the vast amount of free space on the PCB allowed [Nick] to add 2Mbits of storage. There was even some consideration to making removable banks of “RAM” with EEPROM chips, but you’ve got to draw the line somewhere. The RedBoard also supports standard ATX power supplies, which will give you plenty of juice for add-on hardware that may be populating the expansion slots.
There’s a lot more to learning how to play the guitar than just playing the right notes at the right time and in the right order. To produce any sound at all requires learning how to do completely different things with your hands simultaneously, unless maybe you’re a direct descendant of Eddie Van Halen and thus born to do hammer ons. There’s a bunch of other stuff that comes with the territory, like stringing the thing, tuning it, and storing it properly, all of which can be frustrating and discouraging to new players. Add in the calluses, and it’s no wonder people like Guitar Hero so much.
In an interesting departure from standard stringed instrument construction, plucking is isolated from fretting. The player fingers notes on four strings but plucks a special, fifth string with a conductive pick that closes the plucking circuit. By contrast, the fretting strings are normally high. When pressed, they contact the foil-covered fingerboard and the circuit goes low. All five strings are made of carbon-impregnated elastic and wrapped with 30AWG copper wire.
All five strings connect to an Arduino UNO and then a laptop. The laptop sends the signal to a Bluefruit friend to change Bluetooth to UART in order to satisfy the PIC32. From there, it goes out via 2-channel DAC to a pair of PC speakers. One channel has the string tones, which are generated by Karplus-Strong. To fill out the sound, the other DAC channel carries undertones for each note, which are produced by sine tables and direct digital synthesis. There’s no cover charge; just click past the break to check it out.
The Teensy platform is very popular with hackers — and rightly so. Teensys are available in 8-bit and 32-bit versions, the hardware has a bread-board friendly footprint, there are a ton of Teensy libraries available, and they can also run standard Arduino libraries. Want to blink a lot of LED’s? At very fast update rates? How about MIDI? Or USB-HID devices? The Teensy can handle just about anything you throw at it. Driving motors is easy using the standard Arduino libraries such as Stepper, AccelStepper or Arduino Stepper Library.
But if you want to move multiple motors at high micro-stepping speeds, either independently or synchronously and without step loss, these standard libraries become bottlenecks. [Lutz Niggl]’s new TeensyStep fast stepper control library offers a great improvement in performance when driving steppers at high speed. It works with all of the Teensy 3.x boards, and is able to handle accelerated synchronous and independent moves of multiple motors at the high pulse rates required for micro-stepping drivers.
The library can be used to turn motors at up to 300,000 steps/sec which works out to an incredible 5625 rpm at 1/16 th micro-stepping. In the demo video below, you can see him push two motors at 160,000 steps/sec — that’s 3000 rpm — without the two arms colliding. Motors can be moved either independently or synchronously. Synchronous movement uses Bresenham’s line algorithm to plan motor movements based on start and end positions. While doing a synchronous move, it can also run other motors independently. The TeensyStep library uses two class objects. The Stepper class does not require any system resources other than 56 bytes of memory. The StepControl class requires one IntervallTimer and two channels of a FTM (FlexTimer Module) timer. Since all supported Teensys implement four PIT timers and a FTM0 module with eight timer channels, the usage is limited to four StepControl objects existing at the same time. Check out [Lutz]’s project page for some performance figures.
This looks like the end of the road for Intel’s brief foray into the “maker market”. Reader [Chris] sent us in a tip that eventually leads to the discontinuation notice (PCN115582-00, PDF) for the Arduino 101 board. According to Intel forum post, Intel is looking for an alternative manufacturer. We’re not holding our breath.
We previously reported that Intel was discontinuing its Joule, Galileo, and Edison lines, leaving only the Arduino 101 with its Curie chip still standing. At the time, we speculated that the first wave of discontinuations were due to the chips being too fast, too power-hungry, and too expensive for hobbyists. Now that Intel is pulling the plug on the more manageable Arduino 101, the fat lady has sung: they’re giving up on hardware hackers entirely after just a two-year effort.
According to the notice, you’ve got until September 17 to stock up on Arduino 101s. Intel is freezing its Curie community, but will keep it online until 2020, and they’re not cancelling their GitHub account. Arduino software support, being free and open, will continue as long as someone’s willing to port to the platform.
Who will mourn the Arduino 101? Documentation was sub-par, but a tiny bit better than their other hacker efforts, and it wasn’t overpriced. We’re a little misty-eyed, but we’re not crying. You?
Reader [Jasper] writes in with glowing praise for the TFT_eSPI library for the ESP8266 and the various cheap 480×320 TFT displays (ILI9341, ILI9163, ST7735, S6D02A1, etc.) that support SPI mode. It’s a drop-in replacement for the Adafruit GFX and driver libraries, so you don’t need to rework your code to take advantage of it. If you’re looking to drive an LCD screen with an ESP8266 and Arduino, check this out for sure.
As a testbed, [Jasper] ported his Tick Tock Timer project over to the new library. He got a sevenfold increase in draw speed, going from 500 ms to 76 ms. That’s the difference between a refresh that’s visibly slow, and one that looks like it happens instantly. Sweet.
Improving software infrastructure isn’t one of the sexiest or most visible hacks, but it can touch the lives of many hackers. How many projects have we featured with an ESP8266 and a screen? Thanks, [Bodmer] for the good work, and [Jasper] for bringing it to our attention.
The PCB design itself is great. It’s got a gigantic LED array, cutout for a wrist strap, and an onboard USB plug so you can program it just by sticking it in your computer; it shows up as a USB mass storage device when you plug it in. The files that show up on the “drive” are Micropython code that you can edit, save, and then run directly on the device. You can hardly beat that for convenience.
And there’s a full complement of sensors: not one but two temperature and humidity sensors, including our recent favorite BME280, which also reads barometric pressure. (We suspect that makes it a tri-corder.) There’s a real-time clock, a buzzer, and some buttons. Want to add more sensors? I2C ports are broken out for your convenience.
Besides having Star Trek flair, this board would give the various educational platforms a run for their money: Micro:bit, we’re looking at you. Very cool indeed!
Well, honestly, [Michael Mayer’s] STM8 Arduino (called Sduino) isn’t actually much to do with the Arduino, except in spirit. The STM8 is an 8-bit processor. It is dirt cheap and has some special motor control features that are handy. There’s a significant library available for it. However, it can be a pain to use the library and set up the build.
Just like how the Arduino IDE provides libraries and a build system for gcc, Sduino provides similar libraries and a build system for the sdcc compiler that can target the STM8. However, if you are expecting the Arduino’s GUI or a complete knock off of the Arduino library, you won’t get that.
That being said, you do get a lot of compatible libraries. The command line Makefile is simple to set up and use. Why not use a “normal” Arduino? The STM8 is not only inexpensive, but you can make use of the specialized hardware for things like quadrature decoding. In addition, the low power modes are super low.
Don’t let the Makefile put you off. The standard Blink sketch looks identical to an Arduino version. Here’s the required Makefile:
BOARD_TAG = stm8sblue
That’s it. Not too hard.
There’s support for a simple breakout board that is inexpensive, as well as the ESP-14 pictured at the top of this article which has an ESP8266 and an STM8 controller onboard. For about $3 you get an STM8003 CPU and the WiFi capability. Hard to beat that. [Elliot Williams] just gave that board a try and found the ESP-14 to be “weird”. He may be right, but this gives you an easy way to use it.
2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a few silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.
The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.
We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.
Before I dig into this, I must discuss the openness of the HiFive 1, and RISC-V in general. Free Software and Open Hardware is a religion, and it’s significantly more difficult to produce Open Hardware than Free Software. No matter how good or how Open the design is, the production of the first Open Source microcontroller will generate far too many comments from people who use the words ‘moral imperative’ while citing utilitarian examples of why Open and Libre is good. You should ignore these comments, but not just because these people have only read the back cover of the Cliff’s Notes for Philosophy For Dummies.
The Openness of the HiFive 1 and RISC-V
The biggest selling point for RISC-V chips is that there are no licensing fees, and this microcontroller is Open Source. This is huge — your AVRs, PICs, ARMs, and every other microcontroller on the planet is closed hardware. You can’t study the silicon. If we’re ever going to get a completely Open Source computer, it has to start somewhere, and here it is.
With that said, this is an Arduino-compatible board with an FTDI chip providing the USB to serial conversion. If we had a facepalm emoji, we’d use it here. An FTDI chip is not Open Source, and they have designed drivers to break chips that aren’t theirs. The design files for the HiFive 1 were made with Altium, a proprietary and non-Free software.
Will Stallman ever say the HiFive 1 is Free as in speech? Absolutely not. Instead, the HiFive 1 is an incrementally more Free microcontroller compared to a PIC, ARM, or AVR. There will be people who will argue – over the Internet, using late-model Intel processors with Management Engines — this is insufficient to be called Free and Open Source. To them, I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source. Let’s not cut down the idea of an Open Source microcontroller because it’s not perfect on the first release.
Speed: 320+ MHz (the stock frequency seems to be about 256 MHz, this can be changed)
Performance: 1.61 DMIPs/MHz
Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad
Other Features: Hardware Multiply/Divide, Debug Module, Flexible Clock Generation with on-chip oscillators and PLLs
Operating Voltage: 3.3 V and 1.8 V
Input Voltage: 5 V USB or 7-12 VDC Jack
IO Voltages: Both 3.3 V or 5 V supported
Digital I/O Pins: 19
PWM Pins: 9
SPI Controllers/HW CS Pins: 1/3
External Interrupt Pins: 19
External Wakeup Pins: 1
Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)
Host Interface (microUSB): Program, Debug, and Serial Communication
Basically, the HiFive 1 is the SiFive FE310 microcontroller packaged in an Arduino Uno form factor. The pin spacing is just as stupid as it’s always been, and there is support for a few Adafruit shields sitting around in the SDK.
There are no analog pins, but there are two more PWM pins compared to the standard Arduino chip. The Arduino Uno and Leonardo have 32 kilobytes of Flash, while the HiFive 1 has sixteen Megabytes of Flash on an external SOIC chip.
The HiFive 1 supports 3.3 and 5V I/O, thanks to three voltage level translators. The support for 5V logic is huge in my opinion — nearly every dev board manufacturer has already written off 5V I/O as a victim of technological progress. The HiFive doesn’t, even though the FE310 microcontroller is itself only 3.3V tolerant. It should be noted the addition of the voltage level translators add at least a dollar or two to the BOM, and double that to the final cost of the board. It’s a nice touch, but there’s room for cost cutting here.
Other than that, the only other chip of note on the board is the FTDI FT2232HL, a well-supported but most certainly not Free and Open Source USB to UART chip. This is a two-port chip that provides programming, serial, and debug connections simultaneously.
Getting Started With The HiFive 1
The folks at SiFive realize documentation and SDKs are necessary to turn a chip into a development board. To that end, they have a bare-metal SDK and support for the Arduino IDE. The board itself comes with a bootloader, and when you plug the HiFive 1 into a USB you get the equivalent of the Blink sketch from the Arduino. Yes, you too can have Open Source blinkies. What a magical time to be alive.
Right now there are two methods of programming the HiFive 1. The Freedom E SDK, and the Arduino IDE. The Arduino IDE appears to be dependent on the Freedom E SDK, so either way, you’ll have to get the SDK running.
Right now, the SDK only works under Linux (and OS X, and possibly Cygwin), but support for Windows is coming. For Linux users, the getting started guide is more than sufficient, although it will take quite a while (at least 30 minutes) to build all the tools.
Once the Freedom E SDK is installed, support for the Arduino IDE pretty much falls into place. You’ll have to futz around with the Boards Manager, but with a few clicks, you get something fantastic. You can blink an LED with Open Source Hardware.
Actually Programming the Thing
Blinking an LED is proof enough this can be programmed, but what about the vast SDK we had to install before getting the Arduino IDE working? Here, too, it’s pretty easy to get the SDK up and running:
For this example, I simply changed the ‘hello world’ program shipped with the SDK to a ‘hello Hackaday’ program, compiled it, and ran it. Yes, someone as dumb as me can compile and upload a program to the HiFive 1.
This Stuff is Still New, Okay?
Before receiving the HiFive 1, I originally planned to benchmark this dev board against other small, common dev boards. The SDK comes with a Dhrystone program, making this the obvious choice. The results were not good, but this isn’t a reflection of the power of the FE310 microcontroller. Allow me to present the shocking infographic you should not pay attention to:
This test used this Dhrystone Arduino sketch with the Arduino Micro, HiFive 1, and the Teensy 3.6. As you would expect the Arduino Micro performed poorly (but still ten times faster than a mainframe from 1988), and the Teensy 3.6 was extremely fast. According to this benchmark, the HiFive 1 did terribly at barely twice the computing power of the Arduino while running 16 times faster. If this benchmark was accurate, it would immediately spell the end of the RISC-V ISA.
I love this test. Beginning this review, I originally planned to run a few benchmarks on an Arduino, a Teensy, and the HiFive 1, throw together a graph and spend a hundred or so words on the results. I got so much more.
Right off the bat, we can see the HiFive 1 is fast. Really, really fast. Right now, if you want to build a huge RGB LED display, you have one good option: the Teensy 3.6. If you need a microcontroller to pump a lot of data out, the Teensy has the power, the memory, and the libraries to do it easily. In this small but very demanding use case, the HiFive 1 might be better. The HiFive 1 has more Flash (although it’s an SPI Flash), it has DMA, and it has roughly twice the processing power as the Teensy 3.6. This could be very, very cool, and I can’t wait to see the real life examples of how much the HiFive 1 can push out of its pins.
There’s your hundred word review on the performance of the HiFive 1 based on synthetic benchmarks. However, getting this benchmark working revealed far more about the state of the HiFive’s software, and how much support SiFive is throwing at it.
Admittedly, I do have a very early version of this board, and the CrowdSupply campaign for the HiFive 1 was only funded last week. No one would expect one of the three demo apps shipped with a newly released board with a mature architecture to be completely broken (unless it’s an Allwinner chip, but whatever). Very few people would expect the devs to get a patch out in less than 24 hours in response to a random person on a support forum.
All of this circles back to a single observation on the HiFive 1: It’s new. The HiFive 1 and all RISC-V microcontrollers don’t have a vast market share, user base, or decades of work behind them. However, the SiFive team seems to be taking their work seriously. They’re fixing the problems they have, and they’re constantly pushing out new documentation. This is great, and a very good indication of how much support the RISC-V chips from SiFive will have.
The easiest parallel to draw is between SiFive and OSH Park. These companies don’t have their own manufacturing capability; the value is in connecting end users (engineers, startups) to manufacturers. OSH Park connects you to a board house that really knows purple, and SiFive connects you to a chip fab. In the case of the FE310, that’s TSMC.
For anyone who wants silicon you can study, this is great. No, it’s not as simple as sending a board off to a fab house, but it’s a start. The fact that SiFive chose to start with Open Hardware is great, and we can’t wait to see the other hardware made with their sweat and hydrofluoric acid.
It’s a Beginning
At the base level, the HiFive 1 is a powerful microcontroller with a lot of Flash, with support for hundreds of Arduino libraries. That’s great, and alone this might be worth the $60 price of admission.
However, the big story here is the Openness of the HiFive 1. Is it completely open? No. the HiFive 1 itself uses an FTDI chip, and I’ve heard rumor and hearsay the FE310 chip has proprietary bits that are ultimately inconsequential to the function of the chip. A strict interpretation of Open Hardware will not allow this board to be called Open Hardware. Those who advance this interpretation are dumb, and to counter this argument I will quote the man himself:
…We need to distinguish levels in the design of a digital product (and maybe some other kinds of products). The circuit that connects the chips is one level; each chip’s design is another level. In an FPGA, the interconnection of primitive cells is one level, while the primitive cells themselves are another level. In the ideal future we will want the design to be free at all levels. Under present circumstances, just making one level free is a significant advance.
– Richard M. Stallman, Free Hardware And Free Hardware Designs
A design that fails to be completely Open does not deserve to be grouped with designs that are explicitly closed.
Nevertheless, this is the best we have so far, and it is only the beginning. We’re going to have more microcontrollers that are more Open, but until then, the HiFive 1 is actually a pretty cool board.
Sometimes less is more. This is especially true when dealing with microcontrollers with limited I/O pins. Even if you have lots of I/O, sometimes you are need to pack a lot into a little space. [Hugatry] was inspired by the simple interface found on a lot of flashlights: one button. Push it and it turns on. Push it again, and it switches modes. You cycle through the modes until you finally turn it back off. One button provides mutliple functions. The question is how can you use a power switch as an I/O device? After all, when you turn the power off, the microprocessor stops operating, right?
[Hugatry’s] answer is quite simple. He connects a resistor/capacitor network to an I/O pin (or multiple pins). When the processor turns on initially, the pin will read low and the capacitor will charge up. If you turn the power off, the CPU voltage will fall rapidly to zero, but the voltage on the capacitor will discharge slower. If you wait long enough and turn the power on, there’s no difference from that first power on event. But if you turn the power on quickly, the capacitor voltage will still be high enough to read as a logic one.
What that means is that the processor as part of its start up can detect that it was recently turned off and take some action. If it remembers the previous state in nonvolatile memory, you can have the code cycle through multiple states, just like a flashlight. You can see a video of the setup, below.
[Hugatry] included some simple Arduino code that illustrates the concept. However, the technique is simple enough that you can adapt it to other projects easily.
Think one button isn’t enough to do anything interesting? Think again. Then again, Amazon probably has a patent on things with one button.