Writing code for embedded applications can be difficult. There are all sorts of problems you can run into – race conditions, conflicting peripherals, unexpected program flow – any of these can cause havoc with your project. One thing that can really mess things up is if your microcontroller is getting stuck on a routine – without the right debugging hardware and software, this can be a tricky one to spot. [Terry] developed a microcontroller load meter just for this purpose.
It’s a simple setup – a routine named loadmeter-task on the microcontroller sends a train of pulses to a mechanical ammeter. The ammeter is then adjusted with a trimpot to read “0” when the chip is unloaded. As other tasks steal CPU time, there’s less time for loadmeter-task to send its pulses, so the meter falls to the left.
Overall it’s a quick and easy bit of code you could add to any project with a spare GPIO pin, that might help you debug. Plus it’s cool to know how hard your project is pushing the silicon.
If you’d like to know more about what your chip is doing, check out this post about the usefulness of in-circuit debugging, or read about Bil Herd’s experiments with ICE and OBD-II.
C++ has been quickly modernizing itself over the last few years. Starting with the introduction of C++11, the language has made a huge step forward and things have changed under the hood. To the average Arduino user, some of this is irrelevant, maybe most of it, but the language still gives us some nice features that we can take advantage of as we program our microcontrollers.
Modern C++ allows us to write cleaner, more concise code, and make the code we write more reusable. The following are some techniques using new features of C++ that don’t add memory overhead, reduce speed, or increase size because they’re all handled by the compiler. Using these features of the language you no longer have to worry about specifying a 16-bit variable, calling the wrong function with NULL, or peppering your constructors with initializations. The old ways are still available and you can still use them, but at the very least, after reading this you’ll be more aware of the newer features as we start to see them roll out in Arduino code.
Continue reading “Using Modern C++ Techniques with Arduino”
By now, most of us have had some experience getting ROMs from classic video games to run on new hardware. Whether that’s just on a personal computer with the keyboard as a controller, or if it’s a more refined RetrioPie in a custom-built cabinet, it has become relatively mainstream. What isn’t mainstream, however, is building custom hardware that can run classic video games on the original console (translated). The finished project looks amazing, but the prototype blows us away with it’s beauty and complexity.
[phanick]’s project is a cartridge that is able to run games on the Polish Famicon clone called the Pegasus. The games are stored on an SD card but rather than run in an emulator, an FPGA loads the ROMs and presents the data through the normal edge-connector in the cartridge slot of the console. The game is played from the retro hardware itself. It takes a few seconds to load in each ROM, but after that the Pegasus can’t tell any difference between this and an original cartridge.
The original prototype shown here was built back in 2012. Since then it’s been through a few iterations that have reduced the size. PCBs were designed and built in-house, and the latest revision also includes a 3D-printed case that is closer to the size of the original Famicon cartridges.
Even if you don’t have an interest in classic video games or emulation, the video below is worth checking out. (Be sure to turn on the subtitles if you don’t speak Polish.) [phanick] has put in a huge amount of time getting all of the details exactly right, and the level of polish shows in the final product. In fact, we’ve featured him before for building his own Famicom clone.
Continue reading “FPGA Emulates NES Cart; Prototype So Cyberpunk”
Linear voltage regulators are pretty easy to throw into a project if something in it needs a specific voltage that’s lower than the supply. If it needs a higher voltage, it’s almost just as easy to grab a boost converter of some sort to satisfy the power requirements. But if you’re on a mission to save some money for a large production run, or you just like the challenge of building something as simply as possible, there are ways of getting voltages greater than the supply voltage without using anything as non-minimalistic as a boost converter. [Josh] shows us exactly how this can be done using a circuit known as a charge pump to drive a blue LED.
One of the cool things about AVR microcontrollers is that they can run easily on a coin cell battery and source enough current to drive LEDs directly from the output pins. Obviously enough, if the LED voltage is greater than the voltage of the power supply, this won’t work. That is, unless you have a spare diode and capacitor around to build a charge pump.
The negative charge pump works by charging up a capacitor that is connected to an AVR pin, with the other side between the LED and a garden-variety diode to ground. That results in a roughly (VCC – 0.7) volt difference across the capacitor’s plates. When the AVR pin goes low, the other side of the capacitor goes negative by this same amount, and this makes the voltage across the LED high enough to light up. Not only is this simpler than a boost converter, but it doesn’t need any bulky inductors to work properly.
Will this work for any load? Am I going to start any fires by overdriving the LED? Luckily, [josh] answers all of these questions and more on the project page, and goes into some detail on the circuit theory as well. Granted, the charge pump doesn’t have the fine control over the power supply that you can get out of a buck or boost converter (or any switch-mode power supply). But it does have good bang-for-the-buck.
[Sami Pietikäinen] was working on an embedded Linux device based on an Atmel SAMA5D3x ARM-A5 processor. Normally, embedded Linux boxes will boot up off of flash memory or an SD card. But if you’re messing around, or just want to sidestep normal operation for any reason, you could conceivably want to bypass the normal boot procedure. Digging around in the chip’s datasheet, there’s a way to enter boot mode by soldering a wire to pull the BMS pin. As [Sami] demonstrates, there’s also a software way in, and it makes use of
mmap, a ridiculously powerful Linux function that you should know about.
Continue reading “Flashing An ARM With No Soldering”
Hackaday readers (and writers) are an odd bunch. While the rest of the tech press falls over for the newest, shiniest CPU on the market, we’re the type who’s more interested the unexplored dark corners of metaphorical Silicon Alley. So when someone comes to us with a good writeup of a chip that we’d never heard about, we’re all ears.
[Remy]’s writeup of the CoolRISC 816 microcontroller CPU makes it obvious that he shares our taste for the esoteric. It has a 22-bit “RISC” instruction set. It has a dedicated 8-to-16 bit multiplier. Some of the instructions are so un-reduced that [Remy] calls bunk on its RISC claims. All of the operations, including the un-RISC ones, run in a single cycle. And the CoolRISC does this by cheating — the last stages of the pipeline run not on every clock tick, but on the rising and falling flanks of the clock respectively.
Why all these odd bits? They make the job of the assembly programmer, or compiler designer, a lot easier. With all single-cycle instructions, counting cycles is the same as counting lines of code. The not-really-RISC instructions are great for compiling C into. So what happened? [Remy] speculates that the MSP430, another not-really-RISC microcontroller that came out about the same time, ate the CoolRISC’s lunch. The MSP430 is a 16-bit machine, and chances are good that you’ve heard of TI. The same may not be true of Xemics, maker of the CoolRISC.
But still it’s nice to have someone saying the eulogy for this strange little chip. Or maybe the reports of the CR816’s death are premature — it seems to be inside TI’s bq20x80 chip that’s used in a number of battery power monitors. Oh, the irony! Indeed, watch [Charlie Miller] tear into a battery and find a CR816.
Have any of you used a CR816? What’s the strangest microcontroller architecture that you’ve ever seen?
One of the most challenging projects you could ever do with an 8-bit microcontroller is generating VGA signals. Sending pixels to a screen requires a lot of bandwidth, and despite thousands of hackers working for decades, generating VGA on an 8-bit microcontroller is rarely as good as a low-end video card from twenty years ago.
Instead of futzing around with microcontrollers, [Marcel] had a better idea: why not skip the microcontroller entirely? He’s generating VGA frames from standard logic chips and big ‘ol EEPROMs. It works, and it looks good, too.
VGA signals are just lines and frames, with RGB pixel values stuffed in between horizontal sync pulses, and frames stuffed between vertical sync pulses. If you already know what you want to display, all you have to do is pump the right bits out through a VGA connector fast enough. [Marcel] is doing this by saving images on two parallel EEPROMs, sending the output through a buffer, through a simple resistor DAC, and out through a VGA connector. The timing is handled by a few 74-series four-bit counters, and the clock is a standard 25.175 MHz crystal.
There’s not much to this build, and the entire circuit was assembled on a breadboard. Still, with the clever application of Python to generate the contents of the ROM, [Marcel] was able to build something that displays eight separate images without using a microcontroller.