Better LEDs Through DMA

June 19, 2017 by Brian Benchoff 15 Comments

While regular Hackaday readers already know how to blink a LED with a microcontroller and have moved onto slightly more challenging projects such as solving the Navier-Stokes equations in 6502 assembly, that doesn’t mean there’s not space for newbies. [Rik] has published a great tutorial on abusing DMA for blinkier glowy things. Why would anyone want to learn about DMA techniques? For blinkier glowy things, of course.

This tutorial assumes knowledge of LED multiplexing and LED matrices, or basically a bunch of LEDs connected together on an XY grid. The naive way to drive an 8×8 grid of LEDs is attaching eight cathodes to GPIO pins on a microcontroller, attaching the eight anodes to another set of GPIO pins, and sourcing and sinking current as required. The pin count can be reduced with shift registers, and LED dimming can be implemented with PWM. This concludes our intensive eight-week Arduino course.

Thanks to microcontrollers that aren’t trapped in the 1980s, new techniques can be used to drive these LED matrices. Most of the more powerful ARM microcontrollers come with DMA, a peripheral for direct memory access. Instead of having the CPU do all the work, the DMA controller can simply shuffle around bits between memory and pins. This means blinker projects and glowier LEDs.

[Rik]’s method for DMAing LEDs includes setting up a big ‘ol array in the code, correctly initializing the DMA peripheral, and wiring up the LED matrix to a few of the pins. This technique can be expanded to animations with 64 levels of brightness, something that would take an incredible amount of processing power (for a microcontroller, at least) if it weren’t for the DMA controller.

The setup used in these experiments is an STM32F103 Nucleo board along with the OpenSTM32 IDE. [Rik] has released all the code over on GitHub, and you are, of course, encouraged to play around.

8-bit Computer For On-The-Go Programming

June 16, 2017 by Bryan Cockfield 13 Comments

If there was one downside to 8-bit computers like the Commodore 64, it’s that they weren’t exactly portable. Even ignoring their physical size, the power requirements would likely have required a prohibitively large power bank of some sort to lug around as well. The problem of portability has been solved since the late ’70s, but if you still want that 8-bit goodness in a more modern package you’ll have to look at something like retrocomputing madman [Jack Eisenmann]’s DUO Travel computer.

The computer is based around the ubiquitous ATmega328 which should make the ease at which it is programmable apparent. Even so, its 14-button keypad makes it programmable even without another computer. While it has slightly less memory than a standard C-64, it’s still enough for most tasks. And, since its powered by a 9-volt battery it doesn’t require any external power sources either.

The most impressive part of the build, however, is the custom programming language specifically tailored for this platform. After all, a 14-button keypad wouldn’t be a great choice if you had to program in Perl or C all the time. There is some example code on the project page for anyone interested in this specific implementation. While it’s not the most minimal computer [Jack] has ever built, it’s certain to be much more practical.

Continue reading “8-bit Computer For On-The-Go Programming” →

Reading Bingo Balls With Microcontrollers

June 7, 2017 by Voja Antonic 38 Comments

Every once in a while a project comes along with that magical power to consume your time and attention for many months. When you finally complete it, you feel sorry that you don’t have to do anything more.

What is so special about this Bingo ball reader? It may seem like an ordinary OCR project at first glance; a camera captures the image and OCR software recognizes the number. Simple as that. And it works without problems, like every simple gadget should.

But then again, maybe it’s not that simple. Numbers are scattered all over the ball, so they have to be located first, and the best candidate for reading must be selected. Then, numbers are painted onto a sphere rather than a flat surface, sometimes making them deformed to the point where their shape has to be recovered first. Also, the angle of reading is not fixed but somewhere on a 360° scale. And then we have the glare problem to boot, as Bingo balls are so shiny that every light source reflects as a saturated bright spot.

So, is that all of it? Well, almost. The task is supposed to be performed by an embedded microcontroller, with limited speed and memory, yet the recognition process for one ball has to be fast — 500 ms at worst. But that’s just one part of the process. The project includes the pipelined mechanism which accepts the ball, transports it to be scanned by the OCR and then shot by the public broadcast camera before it gets dumped. And finally, if the reading was not reliable enough, the ball has to be subtly rotated so that the numbers would be repositioned for another reading attempt.

Despite these challenges I did manage to build this system. It’s fast and reliable, and I discovered some very interesting tricks along the way. Take a look at the quick demo video below to get a feel for the speed, and what the system “sees”. Then join me after the break to dive into the details of this interesting embedded build.

Continue reading “Reading Bingo Balls With Microcontrollers” →

Microchip’s PIC32MZ DA — The Microcontroller With A GPU

May 30, 2017 by Brian Benchoff 63 Comments

When it comes to displays, there is a gap between a traditional microcontroller and a Linux system-on-a-chip (SoC). The SoC that lives in a smartphone will always have enough RAM for a framebuffer and usually has a few pins dedicated to an LCD interface. Today, Microchip has announced a microcontroller that blurs the lines between what can be done with an SoC and what can be done with a microcontroller. The PIC32MZ ‘DA’ family of microcontrollers is designed for graphics applications and comes with a boatload of RAM and a dedicated GPU.

The key feature for this chip is a boatload of RAM for a framebuffer and a 2D GPU. The PIC32MZ DA family includes packages with 32 MB of integrated DRAM designed to be used as framebuffers. Support for 24-bit color on SXGA (1280 x 1024) panels is included. There’s also a 2D GPU in there with support for sprites, blitting, alpha blending, line drawing, and filling rectangles. No, it can’t play Crysis — just to get that meme out of the way — but it is an excellent platform for GUIs.

Continue reading “Microchip’s PIC32MZ DA — The Microcontroller With A GPU” →

Hackaday Prize Entry: ESP32 Monster And Getting Started Quickly

May 28, 2017 by Elliot Williams 19 Comments

Prolific hacker [kodera2t] is working on his own “ESP32 monster board” dev board for the still-newish ESP32 WiFi module. His board has everything: Ethernet, OLED, LiPo, and even CAN-bus. But all that peripheral connectivity is worth nothing if you can’t program the microcontroller to use it.

The Arduino environment for the ESP32 is coming along quite nicely, but it’s not yet fully featured enough to run all of [kodera2t]’s hardware. To take advantage of all that, he needs to use Espressif’s SDK — called the “IoT Development Framework” or IDF for short. In his latest project log, [kodera2t] goes through everything necessary to get the IDF up and compiling on OSX. (It’s strangely similar to the Linux procedure.) Read through the official instructions here, if you want more, but we think [kodera2t] hits all the high points.

While we’re tooting [kodera2t]’s horn, check out his old project — an Arduino shoehorned into an SD card — or watch his alter-ego [Toshiro Kodera] give a serious talk about his day job, engineering radio-frequency meta-materials.

Use The Force To Turn On This Lamp

May 27, 2017 by Rich Hawkes 8 Comments

Holocrons are holographic data storage devices used in the Star Wars universe by both Jedi and Sith as teaching devices or for storing valuable information. After the fall of the Jedi, they became rare and closely guarded artifacts. [DaveClarke] built one to light the room.

[DaveClarke] built the lamp around a Particle Photon – a STM32 ARM-M0 based microcontroller with a Cypress wifi chip. All [Dave] needed for the workings were an IR proximity sensor, a servo and a bunch of super-bright white LEDs. When the sensor detects something, it starts up the system. The servo rotates a gear which raises the lamp and fades in the LEDs. The next time the sensor detects something, the servo lowers the lamp and the lights begin to fade out. And since the Photon is connected to the cloud, the system can be accessed with a web interface as well.

Okay, so it’s just an IR sensor detecting reflected infrared light and not the Force that’s used to turn it on, but it’s still pretty cool. There are plenty of pictures and videos at [DaveClarke]’s site, along with a schematic, 3D printer designs, and the source code. The whole thing was designed using Autodesk Fusion 360 and 3D printed in about 30 hours and press-fits together. A very simple yet clever design. There have been some other great lamps on the site, like this blossoming flower lamp or this laser cut lamp with which also has a unique switch.

Continue reading “Use The Force To Turn On This Lamp” →

Embed With Elliot: LIN Is For Hackers

May 26, 2017 by Elliot Williams 18 Comments

A car is a rolling pile of hundreds of microcontrollers these days — just ask any greybeard mechanic and he’ll start his “carburetor” rant. All of these systems and sub-systems need to talk to each other in an electrically hostile environment, and it’s not an exaggeration to say that miscommunication, or even delayed communication, can have serious consequences. In-car networking is serious business. Mass production of cars makes many of the relevant transceiver ICs cheap for the non-automotive hardware hacker. So why don’t we see more hacker projects that leverage this tremendous resource base?

The backbone of a car’s network is the Controller Area Network (CAN). Hackaday’s own [Eric Evenchick] is a car-hacker extraordinaire, and wrote up most everything you’d want to know about the CAN bus in a multipart series that you’ll definitely want to bookmark for reading later. The engine, brakes, doors, and all instrumentation data goes over (differential) CAN. It’s fast and high reliability. It’s also complicated and a bit expensive to implement.

In the late 1990, many manufacturers had their own proprietary bus protocols running alongside CAN for the non-critical parts of the automotive network: how a door-mounted console speaks to the door-lock driver and window motors, for instance. It isn’t worth cluttering up the main CAN bus with non-critical and local communications like that, so sub-networks were spun off the main CAN. These didn’t need the speed or reliability guarantees of the main network, and for cost reasons they had to be simple to implement. The smallest microcontroller should suffice to roll a window up and down, right?

In the early 2000s, the Local Interconnect Network (LIN) specification standardized one approach to these sub-networks, focusing on low cost of implementation, medium speed, reconfigurability, and predictable behavior for communication between one master microcontroller and a small number of slaves in a cluster. Cheap, simple, implementable on small microcontrollers, and just right for medium-scale projects? A hacker’s dream! Why are you not using LIN in your multiple-micro projects? Let’s dig in and you can see if any of this is useful for you. Continue reading “Embed With Elliot: LIN Is For Hackers” →