The language C++ is big. There is no doubting that. One reason C++ is big is to allow flexibility in the technique used to solve a problem. If you have a really small system you can stick to procedural code encapsulated by classes. A project with a number of similar but slightly different entities might be best addressed through inheritance and polymorphism.
A third technique is using generics, which are implemented in C++ using templates. Templates have some similarities with #define macros but they are a great deal safer. The compiler does not see the code inserted by a macro until after it has been inserted into the source. If the code is bad the error messages can be very confusing since all the developer sees is the macro name. A template is checked for basic syntax errors by the compiler when it is first seen, and again later when the code is instantiated. That first step eliminates a lot of confusion since error messages appear at the location of the problem.
Continue reading “Code Craft – Embedding C++: Templates”
The Arduino is a popular microcontroller platform for getting stuff done quickly: it’s widely available, there’s a wealth of online resources, and it’s a ready-to-use prototyping platform. On the opposite end of the spectrum, if you want to enjoy programming every bit of the microcontroller’s flash ROM, you can start with an arbitrarily tight resource constraint and see how far you can push it.
[lucas][Radical Brad]’s demo that can output VGA and stereo audio on an eight-pin DIP microcontroller is a little bit more amazing than just blinking an LED.
[lucas][RB] is using an ATtiny85, the larger of the ATtiny series of microcontrollers. After connecting the required clock signal to the microcontroller to get the 25.175 Mhz signal required by VGA, he was left with only four pins to handle the four-colors and stereo audio. This is accomplished essentially by sending audio out at a time when the VGA monitor wouldn’t be expecting a signal (and [lucas][Rad Brad] does a great job explaining this process on his project page). He programmed the video core in assembly which helps to optimize the program, and only used passive components aside from the clock and the microcontroller.
Be sure to check out the video after the break to see how a processor with only 512 bytes of RAM can output an image that would require over 40 KB. It’s a true testament to how far you can push these processors if you’re determined. We’ve also seen these chips do over-the-air NTSC, bluetooth, and even Ethernet.
Continue reading “ATtiny Does 170×240 VGA With 8 Colors”
With the ability to run a full Linux operating system, the Intel Edison board has more than enough computing power for real-time digital audio processing. [Navin] used the Atom based module to build Effecter: a digital effects processor.
Effecter is written in C, and makes use of two libraries. The MRAA library from Intel provides an API for accessing the I/O ports on the Edison module. PortAudio is the library used for capturing and playing back audio samples.
To allow for audio input and output, a sound card is needed. A cheap USB sound card takes care of this, since the Edison does not have built-in hardware for audio. The Edison itself is mounted on the Edison Arduino Breakout Board, and combined with a Grove shield from Seeed. Using the Grove system, a button, potentiometer, and LCD were added for control.
The code is available on Github, and is pretty easy to follow. PortAudio calls the
audioCallback function in effecter.cc when it needs samples to play. This function takes samples from the input buffer, runs them through an effect’s function, and spits the resulting samples into the output buffer. All of the effect code can be found in the ‘effects’ folder.
You can check out a demo Effecter applying effects to a keyboard after the break. If you want to build your own, an Instructable gives all the steps.
Continue reading “Audio Effects on the Intel Edison”
What is an embedded system? The general definition is a computer system dedicated to a specific purpose, i.e. not a general purpose system usable for different tasks. That is a very broad definition. I was just skimming the C++ coding guidelines for the Joint Strike Fighter. That’s a pretty big embedded system and the first DOD project that allowed C++! When you use an ATM to get money you’re using an embedded system. Those are basically hardened PCs. Then at the small end we have all the Internet of Things (IoT) gadgets.
The previous articles about embedding C++ discussing classes, virtual functions, and macros garnered many comments. I find both the positive and critical comments rewarding. More importantly, the critical comments point me toward issues or questions that need to be addressed, which is what got me onto the topic for this article. So thank you, all.
Let’s take a look at when embedded systems should or should not use C++, taking a hard look at the claim that there may be hidden activities ripe to upset your carefully planned code execution.
Continue reading “Code Craft-Embedding C++: Hidden Activities?”
On a desktop computer, you think of an operating system as a big piece of complex software. For small systems (like an Arduino) you might want something a lot simpler. Object Oriented State Machine Operating System (OOSMOS) is a single-file and highly portable operating system, and it recently went open source.
OOSMOS has a unique approach because it is threadless, which makes it easy to use in memory constrained systems because there is no stack required for threads that don’t exist. The unit of execution is a C++ object (although you can use C) that contains a state machine.
You can read the API documentation online. Just remember that this is not an end user OS like Windows or Linux, but an operating environment for managing multiple tasks. You can, though, use OOSMOS under Windows or Linux as well as many other host systems.
Continue reading “Object Oriented State Machine Operating System Goes Open Source”
Embedded C developers shy away from C++ out of concern for performance. The class construct is one of their main concerns. My previous article Code Craft – Embedding C++: Classes explored whether classes cause code bloat. There was little or no bloat and what is there assures that initialization occurs.
Using classes, and C++ overall, is advantageous because it produces cleaner looking code, in part, by organizing data and the operations on the data into one programming structure. This simple use of classes isn’t the raison d’etre for them but to provide inheritance, or more specifically polymorphism, (from Greek polys, “many, much” and morphē, “form, shape”).
Skeptics feel inheritance simply must introduce nasty increases in timing. Here I once more bravely assert that no such increases occur, and will offer side-by-side comparison as proof.
Continue reading “Code Craft – Embedding C++: Timing Virtual Functions”
For many embedded C developers the most predominate and questionable feature of C++ is the class. The concern is that classes are complex and therefore will introduce code bloat and increase runtimes in systems where timing is critical. Those concerns implicate C++ as not suitable for embedded systems. I’ll bravely assert up front that these concerns are unfounded.
When [Bjarne Stroustrup] created C++ he built it upon C to continue that language’s heritage of performance. Additionally, he added features in a way that if you don’t use them, you don’t pay for them.
Continue reading “Code Craft – Embedding C++: Classes”