This week Jonathan and Dan chat with Frank Vasquez and Chris Simmonds about Embedded Linux, and the 4th edition of the Mastering Embedded Linux Programming book. How has this space changed in the last 20 years, and what’s the latest in Embedded Linux?
Continue reading “FLOSS Weekly Episode 846: Mastering Embedded Linux Programming”
Keeping track of time is essential, even for microcontrollers, which is why a real-time clock (RTC) peripheral is a common feature in MCUs. In the case of the STM32 family there are three varieties of RTC peripherals, with the newest two creatively called ‘RTC2′ and RTC3’, to contrast them from the very basic and barebones RTC that debuted with the STM32F1 series.
Commonly experienced in the ubiquitous and often cloned STM32F103 MCU, this ‘RTC1’ features little more than a basic 32-bit counter alongside an alarm feature and a collection of battery-backed registers that requires you to do all of the heavy lifting of time and date keeping yourself. This is quite a contrast with the two rather similar successor RTC peripherals, which seem to insist on doing everything possible themselves – except offer you that basic counter – including giving you a full-blown calendar and today’s time with consideration for 12/24 hour format, DST and much more.
With such a wide gulf between RTC1 and its successors, this raises the question of how to best approach these from a low-level perspective.
Continue reading “Bare Metal STM32: The Various Real Time Clock Flavors”
Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.
I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:
You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.
There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.
If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.
Over a year ago, we took a look at importing a .step file of a KiCad PCB into FreeCAD, then placing a sketch and extruding it. It was a small step, but I know it’s enough for most of you all, and that brings me joy. Today, we continue building a case for that PCB – the delay is because I stopped my USB-C work for a fair bit, and lost interest in the case accordingly, but I’m reviving it now.
Since then, FreeCAD has seen its v 1.0 release come to fruition, in particular getting a fair bit of work done to alleviate one of major problems for CAD packages, the “topological naming problem”; we will talk about it later on. The good news is, none of my tutorial appears to have been invalidated by version 1.0 changes. Another good news: since version 1.0, FreeCAD has definitely become a fair bit more stable, and that’s not even including some much-needed major features.
High time to pick the work back up, then! Let’s take a look at what’s in store for today: finishing the case in just a few more extrusions, explaining a few FreeCAD failure modes you might encounter, and giving some advice on how to make FreeCAD for you with minimum effort from your side.
There’s a saying in mine country, the kind that sometimes shows up on bumper stickers: “If it can’t be grown, it has to be mined.” Before mining can ever start, though, there has to be ore in the ground. In the last edition of this series, we learned what counts as ore (anything that can be economically mined) and talked about the ways magma can form ore bodies. The so-called magmatic processes are responsible for only a minority of the mines working today. Much more important, from an economic point of view, are the so-called “hydrothermal” processes.
When you hear the word “hydrothermal” you probably think of hot water; in the context of geology, that might conjure images of Yellowstone and regions like it : Old Faithful geysers and steaming hot springs. Those hot springs might have a role to play in certain processes, but most of the time when a geologist talks about a “hydrothermal fluid” it’s a lot hotter than that.
Is there a point on the phase diagram that we stop calling it water? We’re edging into supercritical fluid territory, here. The fluids in question can be hundreds of degrees centigrade, and can carry things like silica (SiO2) and a metal more famous for not dissolving: gold. Perhaps that’s why we prefer to talk about a “fluid” instead of “water”. It certainly would not behave like water on surface; on the surface it would be superheated steam. Pressure is a wonderful thing.
Let’s return to where we left off last time, into a magma chamber deep underground. Magma isn’t just molten rock– it also contains small amounts of dissolved gasses, like CO2 and H2O. If magma cools quickly, the water gets trapped inside the matrix of the new rock, or even inside the crystal structure of certain minerals. If it cools slowly, however? You can get a hydrothermal fluid within the magma chamber.
Continue reading “Ore Formation Processes, Part Two: Hydrothermal Boogaloo”
Ever want to find your device on the map? Think we all do sometimes. The technology you’ll generally use for that is called Global Positioning System (GPS) – listening to a flock of satellites flying in the orbit, and comparing their chirps to triangulate your position.
The GPS system, built by the United States, was the first to achieve this kind of feat. Since then, new flocks have appeared in the orbit, like the Galileo system from the European Union, GLONASS from Russia, and BeiDou from China. People refer to the concept of global positioning systems and any generic implementation as Global Navigation Satellite System (GNSS), but I’ll call it GPS for the purposes of this article, and most if not all advice here will apply no matter which one you end up relying on. After all, modern GPS modules overwhelmingly support most if not all of these systems!
We’ve had our writers like [Lewin Day] talk in-depth about GPS on our pages before, and we’ve featured a fair few projects showing and shining light on the technology. I’d like to put my own spin on it, and give you a very hands-on introduction to the main way your projects interface with GPS.
Two weeks ago, it was holographic cops. This week, it’s humanoid robot doctors. Or is it? We’re pretty sure it’s not, as MediBot, supposedly a $10,000 medical robot from Tesla, appears to be completely made up. Aside from the one story we came across, we can’t find any other references to it, which we think would make quite a splash in the media if it were legit. The article also has a notable lack of links and no quotes at all, even the kind that reporters obviously pull from press releases to make it seem like they actually interviewed someone.
