Writing image data to serially connected (SPI/I2C) displays from a microcontroller is easy enough these days, courtesy of standards defined by the MIPI Alliance, yet there are some gotchas in it which may catch someone using it unaware. [Larry Bank] wrote up a good summary of how one can get maximum performance out of such a display link.
At the core is the distinction between pixel data and command transmissions. The change from command to pixel data mode requires signaling, which takes precious clock cycles away from transferring pixel data between the MCU and display. The common MIPI DCS instruction set allows for a big reduction in needed data transfers by allowing parts of the display to be addressed instead of requiring a full refresh. Yet by not properly segmenting command and data transfers, one ends up unnecessarily slowing down the process.
The result is that one can run something like a Pac-Man emulator on an AVR MCU with a sluggish 320×480 SPI LCD at 60 FPS, as one can see in the video that is embedded after the break. Check the article for another demo video as well.
Continue reading “Speeding Up Drawing To MCU-Connected Serial Displays”
Watchdog timers are an often overlooked feature of microcontrollers. They function as failsafes to reset the device in case of a software failure. If your code somehow ends up in an infinite loop, the watchdog will trigger. This is a necessity for safety critical devices. If the firmware in a pacemaker or a aircraft’s avionics system gets stuck, it isn’t going to end well.
In this oldie-but-goodie, [Jack Ganssle] provides us with a great write up on watchdog timers. This tells the story of a failed Clementine spacecraft mission that could have been saved by a watchdog, and elaborates on the design and implementation of watchdog techniques.
If you’re designing a device that needs to be able to handle unexpected failures, this article is definitely worth a read. [Jack] explains a lot of traps of using these devices, including why internal watchdogs can’t always be trusted and what features make for a great watchdog.
Thanks to [Jan] for the tip!
We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.
[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging”
If we say that a hacker is somebody who looks at a “solved” problem and can still come up with multiple alternative solutions, then [Charles Ouweland] absolutely meets the grade. Not that we needed more evidence of his hacker cred given what we’ve seen from him before, but he recently wrote in to tell us about an interesting bit of problem solving which we think is a perfect example of the principle. He wanted to drive a salvaged seven segment LED display with an AVR microcontroller, but there was only one problem: the display needs 15V but the AVR is only capable of 5V. So what to do?
As it turns out, the first step to solving the problem was verifying there was actually a problem to begin with. [Charles] did some experimentation and found that the display didn’t actually need 15V to operate, and in fact would light up well enough at just 6.5V. This lowered the bar quite a bit, but it was still too high to power directly from the chip.
There were a few common ways to solve this problem, which no doubt the Hackaday reader is well aware of. But [Charles] wanted to take the path less traveled. More specifically, the path with the least amount of additional components he had to put on his PCB. He set out to find the absolute easiest way to make his 5V AVR light up a 6.5V LED, and ended up coming with a very clever solution that some may not even know is possible.
He reasoned that if he connected the source pins of two BS170 MOSFETs to a voltage of -1.5V, even when the AVR pin was 0V, they would be still be receiving 1.5V. This virtual “step ladder” meant that once the AVR’s pin goes high (5V), the relative voltage would actually be 6.5V and enough to drive his LEDs. Of course the only problem with that is that you need to have a source for -1.5V.
Getting a negative voltage would normally require adding more components to the design (which he set out to avoid in the first place), but then he came up with another clever idea. To pull the trick off, he actually feeds the AVR 6.5V, but raises the ground voltage by 1.5V with the addition of two 1N4007 diodes. This way the AVR gets a voltage within its capabilities and still can provide a relative 6.5V to the LEDs.
One might say [Charles] took the Kobayashi Maru approach, and simply redefined the rules of the game. But such is the power of the confounding negative voltage.
Why bother interconnecting 40 Propeller microcontrollers one on top of the other? For the power that comes from parallel processing of course! [Humanoido] put the setup together for a total of 1280 ports, 640 counters, and more all running at 6.4 billion instructions per second for the low low price of 300-500$ by our count. The “skyscraper” even comes complete with software and schematics, promising developers the ability to expand or adapt for any venture. Why would we need such a setup in the first place? For any of the following: vision tracking/modification, artificial intelligence, advanced robotic control, or more.
Related: [Humanoido] loves putting MCUs together, check out one of his other creations the Basic Stamp supercomputer.
[MicroMinded] took us way back to our childhoods with his experiments and subsequent YMstream music player based on the Yamaha YM2149 sound generator used in old arcade systems, computers, and even phones (think chiptune). This reminds us of the Chipophone, only this time the sound is achieved from ICs used back in the day, rather than MCU waveforms.
There is still some work to be done to make the music player have a bit more functionality, but for now source is available if you want to make your own. Of course you might come across a small problem; finding an SSG is a tad bit more difficult than say, an Arduino. If a good resource is found, please share it in the comments!
[Thank you Andrew Kretschmer for sending in the chiptune mp3s]
We’ve seen our fair share of AVR projects, but this one’s pretty cool. AVGA is a color video game development platform based on the Atmel AVR family of microcontrollers. As seen in the picture above, one of the AVRs that the project uses is the popular ATMega168. There were several technical hurdles to using the AVRs to run color video games; one of the most difficult problems was figuring out a way to display detailed graphics from AVRs limited onboard RAM. Eventually, the developers figured out a way to display detailed graphics using a TILE-based driver. The TILE driver works by dividing the screen into X and Y coordinates, dividing the graphics into tiles. Then, when a graphic is needed it’s addressed from a reference table that’s stored in the AVR’s onboard RAM, allowing the bitmap graphic to be loaded from a game’s ROM. Currently, the only games available for the platform are a Super Mario clone, a Pacman clone, and a Snake clone. While there are only a few games available, the platform definitely looks promising. If anything, this project serves as a great example for what off the shelf microcontrollers are capable of.