[W8BH] attended a talk by another ham, [W8TEE] that showed a microcontroller sending and receiving Morse code. He decided to build his own, and documented his results in an 8 part tutorial. He’s using the Blue Pill board and the resulting device sends code with paddles, sends canned text, provides an LCD with a rotary knob menu interface, and even has an SD card for data storage.

All the code is on GitHub. If you are interested in Morse code or in learning how to write a pretty substantial application using the Blue Pill and the Arduino IDE (or any other similar processor), this is a great exposition that is also a practical tool.

[W8BH] takes good advantage of breakout boards with things such as the displays and jacks on them. Of course, you don’t absolutely have to use those, but it does make life easier. You can see [W8TEE’s] version posted in an online forum.

The parts of the tutorial all build on each other, so you start out simple and get deeper and deeper. The tutorials are PDF files, but they are well organized and easy to read.

We’ve done our tutorials and videos on the Blue Pill. If you don’t want to rely on the Arduino IDE, there are ways around that, too.

Blue Pill header pic: Popolon [CC BY-SA 4.0]

In concept, an everyday sewing machine could make embroidery a snap: the operator would move the fabric around in any direction they wish while the sewing machine would take care of slapping down stitches of colored thread to create designs and filled areas. In practice though, getting good results in this way is quite a bit more complex. To aid and automate this process, [sausagePaws] has been using CNC to take care of all the necessary motion control. The result is the DIY Embroidery Machine V2 which leverages 3D printed parts and common components such as an Arduino and stepper drivers for an economical DIY solution.

It’s not shown in the photo here, but we particularly like the 3D printed sockets that are screwed into the tabletop. These hold the sewing machine’s “feet”, and allow it to be treated like a modular component that can easily be removed and used normally when needed.

The system consists of a UI running on an Android tablet, communicating over Bluetooth to an Arduino. The Arduino controls the gantry which moves the hoop (a frame that holds a section of fabric taut while it is being embroidered), while the sewing machine lays down the stitches.

[sausagePaws]’s first version worked well, but this new design really takes advantage of 3D printing as well as the increased availability of cheap and effective CNC components. It’s still a work in progress that is a bit light on design details, but you can see it all in action in the video embedded below.

Paul Stoffregen did it again: the Teensy 4.0 has been released. The latest in the Teensy microcontroller development board line, the 4.0 returns to the smaller form-factor last seen with the 3.2, as opposed to the larger 3.5 and 3.6 boards.

Don’t let the smaller size fool you; the 4.0 is based on an ARM Cortex M7 running at 600 MHz (!), the fastest microcontroller you can get in 2019, and testing on real-world examples shows it executing code more than five times faster than the Teensy 3.6, and fifteen times faster than the Teensy 3.2. Of course, the new board is also packed with periperals, including two 480 Mbps USB ports, 3 digital audio interfaces, 3 CAN busses, and multiple SPI/I2C/serial interfaces backed with integrated FIFOs. Programming? Easy: there’s an add-on to the Arduino IDE called Teensyduino that “just works”. And it rings up at an MSRP of just $19.95; a welcomed price point, but not unexpected for a microcontroller breakout board.

The board launches today, but I had a chance to test drive a couple of them in one of the East Coast Hackaday labs over the past few days. So, let’s have a closer look.

First Impressions

The board looks superficially similar to the older 3.2, at least from the top. There’s the usual dual row of pin headers you can plug into a breadboard, a micro-USB connector, and reset button. A new red LED near the USB connector gives you some status information, while the traditional “Arduino LED” is orange. Flip the board over, and you start to see some of the extra power this board wields. Besides ten more GPIO pins, there are pads for an SD card interface using 4-bit SDIO, and D+ and D- lines for the second 480 Mbps USB interface. The unmarked round pads are test points used in manufacturing and are no-connects from the end-user’s perspective.

Teensy 3.2 Everything Killer?

When doing hardware reviews it’s crucial to choose the right comparison hardware. I think the best comparison in this case is between the two boards that share the same form factor; the Teensy 4.0 and the 3.2. I’ve chosen not to make the comparison with the Teensy 3.5 and 3.6, which are priced a little higher, in a larger form factor, and have SD card slots soldered on.

Incredibly, the Teensy 4.0 is priced at $19.95, as opposed to the $19.80 Teensy 3.2. What does that extra fifteen cents buy? First, there’s performance. The 4.0’s 600 MHz clock vs the 72 MHz on the 3.2 doesn’t tell the whole story. The Cortex M7 on the 4.0 is a dual-issue superscalar processor capable of executing up to two 32-bit instructions per clock cycle; initial tests showed this happening between 40-50% of the time on Arduino-compiled code. Additionally, the Cortex-M7 is the first ARM microcontroller with branch prediction. While on the Cortex M4, a branch always takes 3 clock cycles, after a few passes through a loop, for instance, the Cortex M7 can begin executing correctly-predicted branches in a single clock. This is technology originally pioneered in supercomputers that you can use in your next Halloween costume.

Then, there’s floating-point. Veteran embedded programmers may have a bias against floating-point code, and with good reason. Without native floating-point instructions, these operations must be emulated, and run very slowly. The same thing happens with double-precision operations on a processor which only supports single-precision instructions. While Cortex-M4 processors support single-precision floating-point, the Cortex-M7’s include native double-precision instructions, so if you need the extra precision afforded by doubles, you’re not going to take a huge performance hit: basically, doubles seem to execute in only twice as many cycles as floats.

The Cortex-M7 on this board also supports tightly-coupled memory (TCM), which provides fast access like a cache, but without the non-determinism that can complicate hard real-time applications — one of the problems with other high-power microcontrollers. The 64-bit ITCM bus can fetch 64-bits, while two dedicated 32-bit buses (DTCM) can fetch up to two instructions from the TCM each cycle – these buses are separate from the main AXI bus used to communicate with other memory and peripherals. The Teensyduino environment automatically allocates code and statically allocated memory into the DTCM area, which can be up to 512K in size, although you can override the default behavior with some command-line switches. Memory that isn’t accessed by the tightly-coupled buses is optimized for access by the peripherals using DMA.

Spec Sheet

Despite its size, there’s a lot to this board and the chip it carries, so here’s condensed spec list:

• ARM Cortex-M7 at 600 MHz
• 1024K RAM (512K is tightly coupled)
• 2048K Flash (64K reserved for recovery & EEPROM emulation)
• 2 USB ports, both 480 MBit/sec
• 3 CAN Bus (1 with CAN FD)
• 2 I2S Digital Audio
• 1 S/PDIF Digital Audio
• 1 SDIO (4 bit) native SD
• 3 SPI, all with 16 word FIFO
• 3 I2C, all with 4 byte FIFO
• 7 Serial, all with 4 byte FIFO
• 32 general purpose DMA channels
• 31 PWM pins
• 40 digital pins, all interrupt capable
• 14 analog pins, 2 ADCs on chip
• Cryptographic Acceleration
• Random Number Generator
• RTC for date/time
• Programmable FlexIO
• Pixel Processing Pipeline
• Peripheral cross triggering
• Power On/Off management

The board consumes around 100 mA with a 600 MHz clock. Although I didn’t try it myself with the evaluation boards I have here, Paul notes that it can be overclocked for a performance boost. It also supports dynamic clock scaling: the instruction clock speed is decoupled from the peripherals, so that baud rates, audio sample rates, and timing functions continue to function properly if you change the CPU speed.

For the ultimate in power savings, you can shut the board off by adding a pushbutton to the On/Off pin. Pressing the button for more than five seconds disables the 3.3 V supply; a subsequent brief press will turn it back on. This doesn’t affect the real-time-clock (RTC) functionality, however: connecting a coin cell to the VBAT terminal will keep the time and date counter going.

Hands-On Benchmarks

To see how fast this thing really is, Paul ported the CoreMark embedded-processor benchmark to the Arduino environment. (Note that CoreMark seems to be a registered trademark of the Embedded Microprocessor Benchmark Consortium (EEMBC)). This synthetic benchmark tests performance managing linked lists, doing matrix multiplies, and executing state machine code. He reports the following scores for a number of boards (larger numbers are better).

I was able to verify the Teensy 4.0 and 3.2 numbers; my 3.6 must have sprouted legs and walked off somewhere, and I didn’t have any of the other boards handy for testing. Using my numbers (nearly identical to those above), the 4.0 is around ten times as fast as the 3.2.

Since the CoreMark code is a “synthetic” benchmark, Paul wanted to test the new board in a more realistic scenario. In another GitHub repo, he has some code to do an RSA signature with a 2048-bit key. This is a processor-intensive operation, believe me — I had to implement it once in Lua (don’t ask!). Here are the scores for the same boards (lower numbers are better).

Again, I was able to verify the numbers for the Teensy 3.2 and 4.0 boards. In this case, the 4.0 is around fifteen times as fast as the 3.2.

If you have any of these, or other Arduino-compatible boards lying around, clone one or both of these repos, open the respective *.ino file from either one, and test them out. Feel free to report results in the comments below.

15 Seconds to Sanity

One of the new features of the Teensy 4.0 is the automatic recovery process, which restores the board to a known good state without the need for a PC connection. If you press and hold the reset button for 15 seconds, the red LED will flash to indicate you’ve entered restore mode. Once you release the button, the red LED will illuminate while the flash memory is erased and re-written with the traditional Arduino “blink” program. Once the re-write is complete, the blink program is run and the orange LED begins blinking, just like on every Arduino-compatible for the past decade and a half. It’s DFU mode without the need for host computer or known-working binary. These used to be key components for hardware-based restore and now they’re part of the board itself.

Why would you want to do this? In a nutshell, because USB itself is a train-wreck. On top of an insanely sprawling and complex protocol, there are charge-only cables sans data pins lurking in your junk box, operating system bugs waiting to trip you up (looking at you, Windows 7), and a whole host of other issues that cause serious head-scratching when things stop working. This can be especially confusing with native-USB boards like the Teensy 4.0; while the built-in USB functionality is amazingly powerful, and can be used in a wide variety of ways, when something stops working, you’re not always sure how to get back on track. Now, you are – just press the button.

What Can You Do with a 600 MHz Microcontroller?

Paul envisions this Teensy 4.0 being used for polyphonic audio synthesis, running moderately complex machine learning algorithms, and real-time audio analysis. In many cases, the first level of processing on data-intensive input devices can now be moved from a host computer to the external microcontroller, narrowing the bandwidth required to the host system. And for projects driving a display, the built-in pixel processing pipeline can also accelerate graphics operations, offloading this work from the CPU.

There will be some fraction of hackers that will still wonder why we need a 600 MHz microcontroller; another fraction will have already needed it yesterday. In between, most users will take some time to figure out what doors this opens up. The reality is that our tools constrain not only our current designs, but also, to some extent, our imagination. A 15x performance improvement over the current tiny development board you may be using could enable some new and exciting applications, and you, dear reader, are the one who makes them happen. So, drive home a different way from work tonight, sleep on the sofa instead of the bed, or use whatever other tricks you have to shock your brain into creativity and figure out what you could really do with this thing. It’s a lot more than you can do with a 555. For that matter, it’s a lot more than most computers could do in the 90s.

While energy consumption is an important concern in our modern world, you might have noticed that energy in the form of light shines down on us every day from the sun. Solar panels can be utilized to harvest this and turn it into useful electricity, and if your panels can track the sun throughout the day, you can see an efficiency bump of 15-40%.

In order to experiment with this concept, Frank Migge has, after several iterations, come up with a beautiful display called “SunTracker2 Revision 2.”

The device uses stored sun data fed to an Arduino MKR Zero via its SD card reader, and controls 32 LEDs that show the sun’s position, sunset/sunrise, and magnetic north. Automatic alignment is handled by an onboard magnetometer, and a stepper is even implemented to simulate future panel movement.

You can check out the demo below, and find more info over on GitHub.

Marcelo Ávila de Oliveira likes to practice basketball, and while most of us would be content to shoot and hopefully improve, he actually tracks his workouts. While figuring out the number of made baskets, misses, times, etc. is useful, it’s also quite boring and difficult, so he came up with a real-time scoreboard system to take care of this for him. 

The device is mounted to an enclosure under the hoop, and uses an IR proximity sensor poking through Jerry West’s head to know when a ball has gone through. It also employs a vibration sensor to detect if the ball has hit the rim, and if the IR sensor isn’t triggered within three seconds, a miss is counted. 

The setup’s Arduino Mega communicates with a custom smartphone app over Bluetooth, and displays statistics on the practice session. It even plays notification sounds for scores and misses, as shown in the video below.

Somehow [hvde] wound up with a CB radio that does AM and SSB on the 11 meter band. The problem was that the radio isn’t legal where he lives. So he decided to change the radio over to work on the 6 meter band, instead.

We were a little surprised to hear this at first. Most radio circuits are tuned to pretty close tolerances and going from 27 MHz to 50 MHz seemed like quite a leap. The answer? An Arduino and a few other choice pieces of circuitry.

In particular, [hvde] removed much of the RF portion of the radio, leaving just the parts that dealt with the intermediate frequency at 7.8 MHz. Even the transmitter generates this frequency because it is easier to create an SSB signal at a fixed frequency. The Arduino drives a frequency synthesizer and an OLED display. A mixer combines the IF signal with the frequency the Arduino commands.

The radio had a “clarifier” which acts as a fine tuning control. With the new setup, the Arduino has to read this, also, and make small adjustments to the frequency. The RF circuits in the radio took some modifications, too. It is all documented, although we will admit this probably isn’t a project for the faint of heart.

As much as we admired this project, we think we will just stick with SDR. If you want to learn more about the digital synthesis of signals, check out [Bil Herd’s] post.

If you treat your Pi as a wearable or a tablet, you will already have a battery. If you treat your Pi as a desktop you will already have a plug-in power supply, but how about if you live where mains power is unreliable? Like [jwhart1], you may consider building an uninterruptible power supply into a USB cable. UPSs became a staple of office workers when one-too-many IT headaches were traced back to power outages. The idea is that a battery will keep your computer running while the power gets its legs back. In the case of a commercial UPS, most generate an AC waveform which your computer’s power supply converts it back to DC, but if you can create the right DC voltage right to the board, you skip the inverting and converting steps.

Cheap batteries develop a memory if they’re drained often, but if you have enough space consider supercapacitors which can take that abuse. They have a lower energy density rating than lithium batteries, but that should not be an issue for short power losses. According to [jwhart1], this quick-and-dirty approach will power a full-sized Pi, keyboard, and mouse for over a minute. If power is restored, you get to keep on trucking. If your power doesn’t come back, you have time to save your work and shut down. Spending an afternoon on a power cable could save a weekend’s worth of work, not a bad time-gamble.

We see what a supercap UPS looks like, but what about one built into a lightbulb or a feature-rich programmable UPS?

After obtaining an industrial distance sensor, TUENHIDIY decided to use it as the basis for an interesting visual indicator.

The device communicates with an Arduino Uno via an RS-485 module, and outputs distance values in the form of a 9 x 14 pixel display made out of discreet LEDs soldered onto an LoL Shield.

As shown in the video be low, it does a good job of sensing how far an object is from it on a table, and the 126 LEDs provide a nice brilliant display. 

Code for the build can be found on GitHub if you’d like to make something similar. Seeing as though the sensor used here will set you back close to $1,000, you may want to also consider alternatives like an HC-SR04 ultrasonic module instead! 

When you buy—or even salvage—limit switches for electronics projects, you expect them to work again and again, producing normally open (NO) and normally closed (NC) signals as needed. Generally, they do work quite well, but if you want to test this functionality for extra assurance, you might want to check out this project by Mr Innovative.

The automated device spins a NEMA17 stepper motor however many times you choose with a rotary encoder, registering the NO and NC signals that are sent to its Arduino Nano controller in response. The unit then gives a pass or fail output via a small OLED screen to let you know if things are operating properly.

There are usually two ways to go about any task: the easy way and the hard way. Sometimes we might not know there are two options, but once we see someone else’s solution we might feel differently. When running a greenhouse or small farm, for example, we might decide to set up dozens of sensors to measure temperature, humidity, soil moisture, dew point, sunlight, or any number of other variables. That’s the hard way. The easy way is to use the Arduino-powered Norman climate simulator from [934Virginia].

Rather than relying on an array of sensors, any of which could fail or provide erroneous data for any number of reasons, Norman relies on a simple input of data about the current location – target coordinates, specified date ranges, and minimum/maximum values for temperature and humidity – in order to learn and predict the weather conditions in that location. It makes extensive use of the Dusk2Dawn library, and models other atmospheric conditions using mathematical modeling methods in order to make relatively accurate estimates of the climate it is installed in. There are some simulations on the project’s Plotly page which show its successes as well.

Presumably anyone using this device could run a greenhouse relatively well on only $10 worth of electronics rather than relying on a suite of sensors and input data, which is helpful for anyone strapped for cash (especially in developing areas of the world). The project is named after Norman Borlaug, a famous soil scientist and someone worth reading about. The first (and possibly only) sensor we might want to add to this project is a soil moisture sensor, since yearly estimates won’t tell us whether it has just rained or not.

Images courtesy of Wikimedia Commons.