Rust is quite similar to C++ in terms of syntax, however Rust does not allow for null or dangling pointers which makes for more reliable code in the hands of a newbie. With this new initiative, embedded development across different microcontroller architectures could see a more consistent and standardized experience which will result in code portability out of the box. The proposed improvements include IDE and CLI tools for development and setup code generation. There is also talk of RTOS implementations and protocol stack integration which would take community involvement to a whole new level.
This is something to be really excited about because Rust has the potential to be an alternative to C++ for embedded development as rust code runs with a very minimal runtime. Before Arduino many were afraid of the outcome of a simple piece of code but with rust, it would be possible to write memory-safe code without a significant performance hit. With a little community support, Rust could be a more efficient alternative. We have seen some Rust based efforts on ARM controllers and have covered the basics of Rust programming in the past if you want to get started. Good times ahead for hardware hackers.
Programming C without variables is like, well, programming C without variables. They are so essential to the language that it doesn’t even require an analogy here. We can declare and use them as wildly as we please, but it often makes sense to have a little bit more structure, and combine data that belongs together in a common collection. Arrays are a good start to bundle data of the same type, especially when there is no specific meaning of the array’s index other than the value’s position, but as soon as you want a more meaningful association of each value, arrays will become limiting. And they’re useless if you want to combine different data types together. Luckily, C provides us with proper alternatives out of the box.
This write-up will introduce structures and unions in C, how to declare and use them, and how unions can be (ab)used as an alternative approach for pointer and bitwise operations.
When I got my first computer, a second hand 386 running MS-DOS 6.22, I didn’t have an Internet connection. But I did have QuickBASIC installed and a stack of programming magazines the local library was throwing out, so I had plenty to keep myself busy. At the time, I thought QuickBASIC was more or less indistinguishable from magic. I could write simple code and compile it into an .exe, put it on a floppy, and give it to somebody else to run on their own machine. It seemed too good to be true, how could this technology possibly be improved upon?
Of course, that was many years ago, and things are very different now. The programming languages du jour are worlds more capable than the plodding BASIC variants of the 80’s and 90’s. But still, when I found a floppy full of programs I wrote decades ago, I couldn’t help but wonder about getting them running again. With something like DOSBox I reasoned I should be able to install the QuickBASIC IDE and run them like I was back on my trusty 386.
Unfortunately, that was not to be. Maybe I’m just not well versed enough in DOSBox, but I couldn’t get the IDE to actually run any of the source code I pulled off the floppy. This was disappointing, but then it occured to me that modern BASIC interpreters are probably being developed in some corner of the Internet, and perhaps I could find a way to run my nearly 30 year old code without having to rely on 30 year old software to do it. Continue reading “QuickBASIC Lives On with QB64”→
Debuggers come in all shapes and sizes, offering a variety of options to track down your software problems and inspecting internal states at any given time. Yet some developers have a hard time breaking the habit of simply adding print statements into their code instead, performing manual work their tools could do for them. We say, to each their own — the best tools won’t be of much help if they are out of your comfort zone or work against your natural flow. Sometimes, a retrospective analysis using your custom-tailored debug output is just what you need to tackle an issue.
If the last part sounds familiar and your language of choice happens to be Python, [Alex Hall] created the Bird’s Eye Python debugger that records every expression inside a function and displays them interactively in a web browser. Every result, both partial and completed, and every value can then be inspected at any point inside each individual function call, turning this debugger into an educational tool along the way.
With a little bit of tweaking, the web interface can be made remote accessible, and for example, analyze code running on a Raspberry Pi. However, taking it further and using Bird’s Eye with MicroPython or CircuitPython would require more than just a little bit of tweaking, assuming there will be enough memory for it. Although it wouldn’t be first time that someone got creative and ran Python on a memory limited microcontroller.
Websites used to be uglier than they are now. Sure, you can still find a few disasters, but back in the early days of the Web you’d have found blinking banners, spinning text, music backgrounds, and bizarre navigation themes. Practices evolve, and now there’s much less variation between professionally-designed sites.
In a mirror of the world of hypertext, the same thing is going to happen with voice user interfaces (or VUIs). As products like Google Home and Amazon Echo get more users, developing VUIs will become a big deal. We are also starting to see hacker projects that use VUIs either by leveraging the big guys, using local code on a Raspberry Pi, or even using dedicated speech hardware. So what are the best practices for a VUI? [Frederik Goossens] shares his thoughts on the subject in a recent post.
Truthfully, a lot of the design process [Frederik] suggests mimics conventional user interface design in defining the use case and mapping out the flow. However, there are some unique issues surrounding usable voice interactions.
As every Hackaday reader knows, and tells us at every opportunity in the comments, adding an Arduino to your project instantly makes it twice as cool. But what if, in the course of adding an Arduino to your project, you run into a problem and need to debug the code? What if you could use a second Arduino to debug the first? That would bring your project up to two Arduinos, instantly making it four times as awesome as before you started! Who could say no to such exponential gains?
Not [Wayne Holder], that’s for sure. He writes in to let us know about a project he’s been working on for a while that allows you to debug the execution of code on an Arduino with a second Arduino. In fact, the target chip could even be another AVR series microcontroller such as a the ATTiny85. With his software you can single-step through the code, view and modify values in memory, set breakpoints, and even disassemble the code. Not everything is working fully yet, but what he has so far is very impressive.
The trick is exploiting a feature known as “debugWIRE” that’s included in many AVR microcontrollers. Unfortunately documentation on this feature is hard to come by, but with some work [Wayne] has managed to figure out how most of it works and create an Arduino Sketch that lets the user interact with the target chip using a simple menu system over the serial monitor, similar to the Bus Pirate.
[Wayne] goes into plenty of detail on his site and in the video included after the break, showing many of the functions he’s got working so far in his software against an ATTiny85. If you spend a lot of time working on AVR projects, this looks like something you might want to keep installed on an Arduino in your tool bag for the future.
As hackers, we occasionally forget that not everyone is enamored with the same nerdy minutia that we are. Configuring hardware by changing some lines in the code and compiling a new firmware doesn’t sound like that big of a deal to those of us who’ve been around the block a few times, but might as well be ancient Sanskrit to the average person. As long as your projects are for personal use this isn’t really a concern, but what if you plan on distributing the code for a project or perhaps even selling finished products? Shipping it out with hard-coded variables simply isn’t an option.
With the setup demonstrated in the video below by [Proto G], you don’t need anything more exotic than a web browser to configure the device. The end user simply searches for the device’s WiFi network, connects to it, and is presented with an easy to understand dialog which has them select a WiFi network to configure against along with some fields to enter in custom variables. All this information is then stored to a file on the SPI flash. When the ESP32 reboots, it reads the configuration from the saved file and applies the requested settings.
This is very similar to how many consumer devices are now configured, and even the less technically-inclined recipients of such a device should be able to work through the setup with a bit of hand-holding. If you plan on handing one of your ESP32 projects to John Q. Public, this is the kind of configuration you should be aiming for.