When you take a microcontroller class in university, one of the early labs they have you drudge through on your way to, promised, mastery over all things embedded, is a tiny music generator.
It’s a more challenging lab than one would expect. It takes understanding the clock of the microcontroller and its sometimes temperamental nature. It takes a clear mental picture of interrupts, and is likely one of the first experiences a burgeoning designer will have worrying about the execution time of one of their loops. Also tables, data structures, and more. It even requires them to go out of their comfort zone a learn about an unrelated field, a challenge often faced in practicing engineering.
Luckily [Łukasz Podkalicki] has done a great job of documenting the adventure. He’s got everything from the schematic and code to the PWM traces on the oscilloscope.
It’s also worth mentioning that he’s got a few other really nice tutorials for the ATtiny13 microcontroller on his blog. A tiny party light generator and a IR receiver among them.
I’ve had the fortune or misfortune of interviewing a lot of job candidates over the years. It amazes me how often someone will claim to know something, sound reasonable, but then if you quiz them on it, it becomes really obvious that they don’t know much. To flush this out, we had a three-question test that would tell you a lot. People who got the right answer were ahead of the game, of course, but even looking at how people approached the answer (right or wrong) would tell you a lot, too.
I remember one case where the answer involved casting a value. A candidate had impressed me until faced with the question to which he said (more or less): “Well, there’s this function. I think it is called ‘cast’…” I think the look on my face told him that I actually knew the answer (not surprising, since I was giving the test) and that wasn’t it.
[Oleksandr Kaleniuk] has a C quiz of only five simple questions. They reminded me of at least one of my old company’s three-question quiz. I don’t want to say too much about the character of the test because I don’t want to give away the answers, but if you think you are a C wizard, go check it out. Then come back in the comments and tell us how you did. Just try to avoid posting spoilers (although you should probably avoid the comment section until you come back).
Continue reading “Think You Know C? Find Out”
[Bisqwit] has feelings about games that use exclamation points in his idiosyncratic walkthrough of all the nuances of the passwords in the famous Punch Out Bang Bang.
As he states in his deeply weird (though in no way wrong) channel intro, when he’s not driving a bus or teaching Israeli dance, he works hard to understand the things around him. Naturally, a mysterious phone number shaped set of digits in a favorite game was a secret worth extracting.
The digits can represent every possible state in the game. It uses a pretty simple decoding and encoding scheme, which he walks through. As he says, it all becomes clear when you can see the source code.
After working through all the quirks he is able to arbitrarily generate any state in the game and handle the exceptions (such as Nintendo USA’s phone number). You can see all his code here and try it out for yourself. Video after the break.
We’ve grown to respect [Bisqwit] as the explainer of all things console games. You will like his explanation of how to write a code emulator for an NES CPU.
Continue reading “Crack Mike Tyson’s Punch Out Bang Bang Passwords”
We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.
[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?
When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.
So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.
[Nurgak] shows how one can use some of the great robotic tools out there to simulate a robot before you even build it. To drive this point home he builds the tutorial off of the easily 3D printable and buildable Robopoly platform.
The robot runs on Robot Operating System at its core. ROS is interesting because of its decentralized and input/output agnostic messaging system. For example, if you leave everything alone but swap out the motor output from actual motors to a simulator, you can see how the robot would respond to any arbitrary input.
[Nurgak] uses another piece of software called V-REP to demonstrate this. V-REP is a simulation suite for robotics and has a few ROS nodes built in. So in order to make a simulated line-following robot, [Nurgak] tells V-REP to send a simulated camera image to the decision making node of the robot in ROS. It then sends the movement messages back to V-REP which drives the pretend robot around.
He runs through a few more examples, proving that it’s entirely possible to become if not a roboticist, at least a really good AI programmer without ever dropping the big money on parts to build a robot.
If you haven’t jumped on the ESP8266 bandwagon yet, it might be a good time to get started. If you can program an Arduino you have pretty much all of the skills you’ll need to get an ESP8266 up and running. And, if you need a good idea for a project to build with one of these WiFi miracle chips, look no further than [Ben Buxton]’s dated, but awesome, NTP clock.
Continue reading “Simple Clock from Tiny Chip”
We’re quite used to multitasking computer systems today. Our desktops run email, a couple of browsers in different workspaces, a word processor, and a few other applications, apparently all at once. Looking behind the scenes using a system monitor or task manager program reveals a multitude of other programs running in support of our activities. Of course, any given CPU is running a maximum of one program at a time. Multitasking is simply the practice of switching between active processes fast enough to give the illusion of simultaneity.
The roots of multiasking go way back. In the early days, when computers cost tons of money, the thought of an idle system was anathema. Teletype IO was slow compared to the processor, and leaving the processor waiting idle for a card reader to slurp in the next card was outrageous. The gurus of the time worked to fill that idle time with productive work. That eventually led to systems that would run multiple programs at one time, and eventually to more finely grained multitasking within a program.
Modern multitasking depends on support from the underlying API of an operating system. Each OS uses its own techniques, making it difficult to write portable code. The C++ 2011 standard increased the portability of the language by adding concurrency routines to the Standard Template Library (STL). These routines use the API of the OS. For instance, the Linux version uses the POSIX threading library, pthread. The result is a minimal, but useful, capability for building upon in later standards. The C++ 2017 standard development activities include work on parallelism and concurrency.
In this article, I’ll work through some of the facilities for and pitfalls in writing threaded code in C++.
Continue reading “Code Craft – Embedding C++: Multitasking”