Posts | Comments

Planet Arduino

Archive for the ‘microcontrollers’ Category

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Laurence Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Laurence] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Laurence] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.

Debugging with printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.

The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.

He’s got additional tips on using serial print debugging as a process, and he’s done a followup where he stress-tests the reliability of a 5.3 MBit/sec serial stream from an ATMega2560 at 16 MHz in his 3D printer, and found no missed packets. That certainly covers using printf as a debugger, so how about a method of using the debugger as printf?

There’s no question that you can get a lot done with the classic multimeter; it’s arguably the single most capable tool on your bench. But the farther down the rabbit hole of hacking and reverse engineering you go, the more extravagant your testing and diagnostic gear tends to get. For some of us that’s just an annoying reality of the game. For others it’s an excuse to buy, and maybe even build, some highly specialized equipment. We’ll give you one guess as to which group we fall into here at Hackaday.

[Akshay Baweja] is clearly a member of the second group. He’s recently published a guide on building a very slick intelligent Integrated Circuit tester with a total cost of under $25 USD. Whether you’re trying to identify an unknown chip or verifying your latest parts off the slow-boat from China actually work before installing them in your finished product, this $25 tool could end up saving you a lot of time and aggravation.

[Akshay] walks readers through the components and assembly of his IC tester, which takes the form of a Shield for the Arduino Mega 2560. The custom PCB he designed and had manufactured holds the 20 Pin ZIF Socket as well as the 2.4 inch TFT touch screen. The screen features an integrated micro SD slot which is important as you need the SD card to hold the chip database.

With an IC to test inserted into the ZIF socket, the user can have the tester attempt to automatically ID the chip or can manually enter in a part number to lookup. The source code for the Arduino as well as the chip ID database is up on GitHub for anyone looking to add some more hardware to the device’s testing repertoire.

The importance of good test equipment simply cannot be overstated. Between highly specialized gear like this IC tester to classic instruments such as the oscilloscope, your bench is going to be full of weird and wonderful pieces of equipment before too long.

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.
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 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 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

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.

RedBoard PCB layout

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.

With as cheap and plentiful as the miniITX and microATX cases are, it’s no surprise people seem intent on cramming hardware into them. We’ve covered a number of attempts to drag other pieces of hardware kicking and screaming into that ubiquitous beige-box form factor.


Filed under: Arduino Hacks, computer hacks, Microcontrollers

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.

[Jake] and [Jonah] have found a way to bridge the gap between pushing candy colored buttons and developing fireproof calluses and enough grip strength to crush a tin can. For their final project in [Bruce Land]’s embedded microcontroller design class, they made a guitar video game and a controller that’s much closer to the experience of actually playing a guitar. Whether you’re learning to play for real or just want to have fun, the game is a good introduction to the coordination required to make more than just noise.

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.

If you’d like to get into playing, but don’t want to spend a lot of money to get started, don’t pass up those $30-$40 acoustics for kids, or even a $25 ukulele from a toy store. You could wind your own pickup and go electric, or add a percussive solenoid to keep the beat.


Filed under: Arduino Hacks, Microcontrollers, Musical Hacks

I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.

So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.

Not only do I get to watch my mistakes in near real time, I get to make a video about it also.

Getting Data Out of a Vehicle

I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).

To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.

At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.

Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.

The Hardware

I revised the board since the last video and removed the support for the various protocols other than CAN, which is the non-obsolete protocol of the bunch. By removing a bunch of parts I was able to change the package style to through-hole which is easier for many home hobbyists, so you can leave the solder-paste in the ‘fridge.

The “Other Connector” on your Arduino

Unlike the Arduino which is ready to talk to your USB port when you take it out of the box, the ATmega chips arrive without any knowledge of how to go and download code, in other words it doesn’t have a boot loader. Consequently I have the In-Circuit-Serial-Programming (ICSP) pins routed to a pin header on my board so that I can program the part directly.

On this connector you’ll find the Reset line, which means with this header I can use a true ICE utilizing the debugWIRE protocol. Since the vast majority of designs that use an AVR chip do not repurpose the reset pin for GPIO, it is a perfect pin to use for ICE. All of the communications during the debug process will take place on the reset pin.

Enter the ICE

When designing a computer from scratch there is always the stage where nothing yet works. Simply put, a microprocessor circuit cannot work until almost every part of the design works; RAM, ROM, and the underlying buses all need to (mostly) work before simple things can be done. As a hardware engineer by trade I would always reach for an ICE to kick off the implementation; only after the Beta release would the ICE start to gather dust in the corner.

In the case of the ATmega, the debugging capabilities are built into the microcontroller itself. This is a much more straightforward implementation than the early days when we had to have a second isolated processor running off-board with its own local RAM/ROM.

One note mentioned in the video is that a standard Arduino’ish board needs to have the filter capacitors removed from the RESET line to allow the high speed data on the line for its debugWIRE usage.

The ICE I am using here is the one made by Atmel, and is compatible with Atmel Studio, there are also other models available such as the AVR Dragon.

ICEyness

The ICE allows us to download and single step our code while being able to observe and overwrite RAM and I/O Registers from the keyboard. We are able to watch the program step by step or look underneath at the actual assembly code generated by the compiler. We can watch variables and locations directly in RAM or watch the C language counterparts. It’s also possible to jump over a sub-routine call in the instance of just wanting to see the result without all of the processing.

It’s worth your time to see even a glimpse of the capabilities of an ICE in action. I recommend that you watch the video where the debugging begin.

Final Words

This video was really about finishing the OBDII circuit so I didn’t really have the time to go over everything an ICE can do, maybe I will do a post dedicated to just the ICE and development environment next time.


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

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.


Filed under: Arduino Hacks, Microcontrollers

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
include ../../sduino/sduino.mk

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.

Support for the STM8 version of the Discovery board is supposedly forthcoming.


Filed under: Arduino Hacks, Microcontrollers

It’s the most wonderful time of the year! No, we’re not talking about the holiday season, although that certainly has its merits. What we mean is that it’s time for the final projects from [Bruce Land]’s ECE4760 class. With the giving spirit and their mothers in mind, [Adarsh], [Timon], and [Cameron] made a programmable lock box with four-factor authentication. That’s three factors more secure than your average Las Vegas hotel room safe, and with a display to boot.

Getting into this box starts with a four-digit code on a number pad. If it’s incorrect, the display will say so. Put in the right code and the system will wait four seconds for the next step, which involves three potentiometers. These are tuned to the correct value with a leeway of +/- 30. After another four-second wait, it’s on to the piezo-based knock detector, which listens for the right pattern. Finally, a fingerprint scanner makes sure that anyone who wants into this box had better plan ahead.

This project is based on Microchip’s PIC32-based Microstick II, which [Professor Land] starting teaching in 2015. It also uses an Arduino Uno to handle the fingerprint scanner. The team has marketability in mind for this project, and in the video after the break, they walk through the factory settings and user customization.

We have seen many ways to secure a lock box. How about a laser-cut combination safe or a box with a matching NFC ring?


Filed under: Arduino Hacks, Microcontrollers, security hacks


  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook