When writing code for a new hardware platform, the last thing you want to do is bother with the minutiae of I/O routines, string handling and other similarly tedious details that have nothing to do with the actual project. On bigger systems, this is where the C standard library would traditionally come into play.
For small embedded platforms like microcontrollers, resources are often tight enough that a full-blown stdlib won’t fit, which is why Newlib exists: to bring the portability benefits of a standard library to microcontrollers.
Whether you use C, C++ or MicroPython to program an MCU, Newlib is likely there under the hood. Yet how exactly does it integrate with the hardware, and how are system calls (syscalls) for e.g. file and input/output handling implemented? Continue reading “The Newlib Embedded C Standard Library And How To Use It”→
Just a few weeks before Atlantis embarked on the final flight of the Space Shuttle program in 2011, a small Mexican company by the name of Squad quietly released Kerbal Space Program (KSP) onto an unsuspecting world. Until that point the company had only developed websites and multi-media installations. Kerbal wasn’t even an official company initiative, it started as a side project by one of their employees, Felipe Falanghe. The sandbox game allowed players to cobble together rockets from an inventory of modular components and attempt to put them into orbit around the planet Kerbin. It was immediately addictive.
There was no story to follow, or enemies to battle. The closest thing to a score counter was the altimeter that showed how far your craft was above the planet’s surface, and the only way to “win” was to put its little green occupant, the titular Kerbal, back on the ground in one piece. The game’s challenge came not from puzzles or scripted events, but from the game’s accurate (if slightly simplified) application of orbital mechanics and Newtonian dynamics. Building a rocket and getting it into orbit in KSP isn’t difficult because the developers baked some arbitrary limitations into their virtual world; the game is hard for the same reasons putting a rocket into orbit around the Earth is hard.
One of my early rockets, circa 2013.
Over the years official updates added new components for players to build with and planets to explore, and an incredible array of community developed add-ons and modifications expanded the scope of the game even further. KSP would go on to be played by millions, and seeing a valuable opportunity to connect with future engineers, both NASA and the ESA helped develop expansions for the game that allowed players to recreate their real-world vehicles and missions.
But now after a decade of continuous development, with ports to multiple operating systems and game consoles, Squad is bringing this chapter of the KSP adventure to a close. To celebrate the game’s 10th anniversary on June 24th, they released “On Final Approach”, the game’s last official update. Attention will now be focused on the game’s ambitious sequel, which will expand the basic formula with the addition of interstellar travel and planetary colonies, currently slated for release in 2022.
Of course, this isn’t the end. Millions of “classic” KSP players will still be slinging their Kerbals into Hohmann transfer orbits for years to come, and the talented community of mod developers will undoubtedly help keep the game fresh with unofficial updates. But the end of official support is a major turning point, and it seems a perfect time to reminisce on the impact this revolutionary game has had on the engineering and space communities.
Hackaday editors Mike Szczys and Elliot Williams help you get caught up on a week of wonder hacks. We don’t remember seeing a floppy drive headline the demoscene, but sure enough, there’s a C64 demo that performs after the computer is disconnected. What causes bench tools to have unreliable measurements? Sometimes a poor crystal choice lets AC ruin the party. We dive into the ongoing saga of the Audacity open source project’s change of ownership, and talk about generator exciter circuits — specifically their role in starting grid-scale generators from shutdown.
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Gripped as we are at the time of this writing by a historic heatwave, it’s hard for those of us in the western United States to picture a time when cold and ice reigned across the land. But really, it was only about four months back that another bit of freakish weather was visited across most of the country, including places ill-equipped to deal with the consequences. The now-fabled “February Freeze” left millions, mostly in Texas, scrabbling about in the dark and cold as a series of cascading engineering failures took apart their electrical grid, piece by piece, county by county.
The event has been much discussed and dissected, as an event with such far-reaching impact should be. Like much discussion these days, precious little of it is either informed or civil, and that’s not good news for those seeking to understand what happened and how to prevent it from happening again, or at least to mitigate the effects somewhat. Part of that is understandable, given the life-disrupting and often life-threatening situations the disaster forced people to suddenly face. It’s also difficult for people to discuss an event so widespread in its scope and impact — there’s just too much for anyone to wrap their head around.
To make the present discussion a little easier, we’ll be focusing on one aspect of the February grid crash that’s often bandied about but rarely explained: that the Texas grid was mere minutes away from collapsing completely, and that it would have taken weeks or months to restore had it been able to slip away. Is that really possible? Can the power grid just “go away” completely and suddenly? The answer, sadly, is yes, but thankfully a lot of thought has been put into not only preventing it from happening but also how to restart everything if it does happen, by performing what’s known as a “Black Start.”
There’s a lot happening in the world of Pi. Just when we thought the Raspberry Pi Foundation were going to take a break, they announced a new PoE+ HAT (Hardware Attached on Top) for the Pi B3+ and Pi 4, and just as soon as preorders opened up I placed my order.
Now I know what you’re thinking, don’t we already have PoE HATs for the Pis that support it? Well yes, the Pi PoE HAT was released back in 2018, and while there were some problems with it, those issues got cleared up through a recall and minor redesign. Since then, we’ve all happily used those HATs to provide up to 2.5 amps at 5 volts to the Pi, with the caveat that the USB ports are limited to a combined 1.2 amps of current.
$20 for either of them. Choose wisely.
The Raspberry Pi 4 came along, and suddenly the board itself can pull over 7 watts at load. Combined with 6 watts of power for a hungry USB device or two, and we’ve exceeded the nominal 12.5 watt power budget. As a result, a handful of users that were trying to use the Pi 4 with POE were hitting power issues when powering something like dual SSD drives over USB. The obvious solution is to make the PoE HAT provide more power, but the original HAT was already at the limit of 802.3af PoE could provide, with a maximum power output of 12.95 watts.
The solution the Raspberry Pi Foundation came up with was to produce a new product, the PoE+ HAT, and sell it along side the older HAT for the same $20. The common name for 802.3at is “PoE+”, which was designed specifically for higher power devices, maxing out at 30 watts. The PoE+ HAT is officially rated to output 20 watts of power, 5 volts at 4 amps. These are the output stats, so the efficiency numbers don’t count against your power budget, and neither does the built-in fan.
Between the 1930s and the 1950s, something sort of strange happened in the United States. The infant mortality rate went into decline, but the number of babies that died within 24 hours of birth didn’t budge at all. It sounds terrible, but back then, many babies who weren’t breathing well or showed other signs of a failure to thrive were usually left to die and recorded as stillborn.
As an obstetrical anesthesiologist, physician, and medical researcher, Virginia Apgar was in a great position to observe fresh newborns and study the care given to them by doctors. She is best known for inventing the Apgar Score, which is is used to quickly rate the viability of newborn babies outside the uterus. Using the Apgar Score, a newborn is evaluated based on heart rate, reflex irritability, muscle tone, respiratory effort, and skin color and given a score between zero and two for each category. Depending on the score, the baby would be rated every five minutes to assess improvement. Virginia’s method is still used today, and has saved many babies from being declared stillborn.
Virginia wanted to be a doctor from a young age, specifically a surgeon. Despite having graduated fourth in her class from Columbia University College of Physicians and Surgeons, Virginia was discouraged from becoming a surgeon by a chairman of surgery and encouraged to go to school a little bit longer and study anesthesiology instead. As unfortunate as that may be, she probably would have never have created the Apgar Score with a surgeon’s schedule. Continue reading “Virginia Apgar May Have Saved Your Life”→
When we last checked in on the Audacity community, privacy-minded users of the free and open source audio editor were concerned over proposed plans to add telemetry reporting to the decades old open source audio editing software. More than 1,000 comments were left on the GitHub pull request that would have implemented this “phone home” capability, with many individuals arguing that the best course of action was to create a new fork of Audacity that removed any current or future tracking code that was implemented upstream.
For their part, the project’s new owners, Muse Group, argued that the ability for Audacity to report on the user’s software environment would allow them to track down some particularly tricky bugs. The tabulation of anonymous usage information, such as which audio filters are most commonly applied, would similarly be used to determine where development time and money would best be spent. New project leader Martin “Tantacrul” Keary personally stepped in to explain that the whole situation was simply a misunderstanding, and that Muse Group had no ill intent for the venerable program. They simply wanted to get a better idea of how the software was being used in the real-world, but after seeing how vocal the community was about the subject, the decision was made to hold off on any changes until a more broadly acceptable approach could be developed.
Our last post on the subject ended on a high note, as it seemed like the situation was on the mend. While there was still a segment of the Audacity userbase that was skeptical about remote analytics being added into a program that never needed it before, representatives from the Muse Group seemed to be listening to the feedback they were receiving. Keary assured users that plans to implement telemetry had been dropped, and that should they be reintroduced in the future, it would be done with the appropriate transparency.
Unfortunately, things have only gotten worse in the intervening months. Not only is telemetry back on the menu for a program that’s never needed an Internet connection since its initial release in 2000, but this time it has brought with it a troubling Privacy Policy that details who can access the collected data. Worse, Muse Group has made it clear they intend to move Audacity away from its current GPLv2 license, even if it means muscling out long-time contributors who won’t agree to the switch. The company argues this will give them more flexibility to list the software with a wider array of package repositories, a claim that’s been met with great skepticism by those well versed in open source licensing.
