Mastering Memory For Microcontrollers: Elecia White To Deliver Remoticon Keynote

October 25, 2021 by Mike Szczys 1 Comment

I’m excited to share the news that Elecia White will deliver a keynote talk at the Hackaday Remoticon in just a few short weeks. Get your free ticket now!

Elecia is well-known throughout the embedded engineering world. She literally wrote the book on it — or at least a book on it, one I have had in my bedside table for reference for years: O’Reilly’s Making Embedded Systems: Design Patterns for Great Software. She hosts the weekly Embedded podcast which has published 390 episodes thus far. And of course Elecia is a principal embedded software engineer at Logical Elegance, Inc working on large autonomous off-road vehicles and deep sea science platforms.

Map of a mythical land used as a metaphor for microcontroller memory — Map metaphor used to help visualize microcontroller memory. [Source: embedded.fm]

For her keynote, Elecia plans to unwrap the secrets often overlooked in the memory map file generated when compiling a program for a microcontroller. Anyone who has written code for these mighty little chips has seen the .map files, but how many of us have dared to really dive in?

Elecia will use a nifty metaphor for turning the wall of text and numbers into a true map of the code. That metaphor makes the topic approachable for everyone with at least a rudimentary knowledge of how embedded systems work, and even the grizzliest veteran will walk away with tips that help when optimizing for RAM usage and/or code space, updating firmware (with or without a bootloader), and debugging difficult crash bugs.

This autumn is a busy time for Elecia. She’s been hard at work turning her book into a ten-part massive open online course (MOOC). Over the years she’s been a strong supporter of Hackaday, more than once as a judge for the Hackaday prize (here’s her tell-all following the final round judging of the 2014 Prize). She even took Hackaday on a tour of Xerox Parc.

Final Talk Announcements This Week and Next!

The Call for Proposals closed a few days ago. So far we’ve made two announcements about the accepted talks and we’ll make two more, this Thursday and next. But there’s no reason to wait. With Elecia White, Jeremy Fielding, and Keith Thorne presenting keynotes, and some superb social activities soon to be unveiled, this is an event not to be missed!

Remoticon is free to all, just head over and grab a ticket! If you want something tangible to remember the weekend by you can grab one of the $25 tickets that scores you a shirt, but either option gets you all the info you need to be at every virtual minute of the conference.

Just How Vulnerable To Accidental Erasure Are EPROMs Anyway?

June 29, 2021 by Dan Maloney 45 Comments

On the scale of things worth worrying about, having to consider whether your EPROMs will be accidentally erased by some stray light in the shop is probably pretty low on the list. Still, losing irreplaceable data can make for a bad day, so it might just pay to know what your risks really are.

To address this question, [Adrian] set out to test just how susceptible to accidental erasure some common EPROM chips are. An EPROM, or “erasable programmable read-only memory”, is a non-volatile memory chip that can be programmed electrically and then erased optically, by exposing the die inside the chip to light at a specific wavelength, usually in a special chip erasing tool. But erasure can also happen in daylight (even if it takes a few weeks), so [Adrian] cooked up an experiment to see what the risk really is.

He exposed a selection of EPROMs with known contents to UV and checked their contents. Three of the chips had a simple paper or foil label applied, while one had its quartz window exposed to the UV. As expected, the unprotected chip was erased in just 30 minutes. The covered chips, though, all survived that onslaught, and much more — up to 780 minutes of continuous exposure.

So rest easy — it seems that even a simple paper label is enough to protect your precious retro EPROMs. It’s a good data point, and hats off to [Adrian] for taking a look at this. But now we can’t help but wonder: what would a little sunscreen applied to the quartz window do to erasability? Sounds like a fun experiment, too.

Continue reading “Just How Vulnerable To Accidental Erasure Are EPROMs Anyway?” →

Cloned Memory Module Fixes Broken Scopemeter

June 17, 2021 by Dan Maloney 9 Comments

Finding broken test gear and fixing it up to work again is a time-honored tradition among hackers. If you’re lucky, that eBay buy will end up being DOA because of a popped fuse or a few bad capacitors, and a little work with snips and a soldering iron will earn you a nice piece of test gear and bragging rights to boot.

Some repairs, though, are in a class by themselves, like this memory module transplant for a digital scopemeter. The story began some time ago when [FeedbackLoop] picked up a small lot of broken Fluke 199C scopemeters from eBay. They were listed as “parts only”, which is never a good sign, and indeed the meters were in various states of disassembly and incompleteness.

The subject of the video below was missing several important bits, like a battery and a power connector, but most critically, its memory module. Luckily, the other meter had a good module, making reverse engineering possible. That effort started with liberating the two RAM chips and two flash chips, all of which were in BGA packages, from the PCB. From there each chip went into a memory programmer to read its image, which was then written to new chips. The chip-free board was duplicated — a non-trivial task for a six-layer PCB — and new ones ordered. After soldering on the programmed chips and a few passives, the module was plugged in, making the meter as good as new.

While we love them all, it’s clear that there are many camps of test gear collectors. You’ve got your Fluke fans, your H-P aficionados, the deep-pocketed Keithley crowd — but everyone loves Tektronix.

Continue reading “Cloned Memory Module Fixes Broken Scopemeter” →

Four Servo Fingers Play Simon Better Than You Ever Could

May 10, 2021 by Dan Maloney 10 Comments

Remember Simon? We sure do. Simon — as in “Simon says…” — from the leading edge of electronic games in the 1970s, which used four buttons, colored lights, and simple tones as the basis for a memory game. Players had to remember the specific sequence of lights and replay the pattern in order to advance to the next round. It was surprisingly addictive, at least for the era.

For those who never quite got into the Simon groove, fear not — the classic game has now been fully automated. While there were plenty of approaches that could have taken to interfacing to the game, [ido roseman] went with the obvious — and best, in our opinion — technique and simulated a human player’s finger presses with servo-controlled arms. Each arm carries a light-dependent resistor that registers the light coming from the key it’s poised above; the sequence of lights is sensed and recorded by an Arduino, which then drives the servo fingers’ replay attack. The fingers aren’t exactly snappy in their response, which might cause problems — if we recall correctly, Simon is somewhat picky about the speed with which the keys are pressed, at least at higher levels of play.

On the whole, we really like this one, not least for the nostalgia factor. We’ve had a lot of recreations of Simon over the years, including a Dance Dance Revolution version, but few attempts to automate it. And a crazy idea: wouldn’t it be fun to replace the replay attack with a machine learning system that figures out how to play Simon by randomly pressing keys and observing the results?

Continue reading “Four Servo Fingers Play Simon Better Than You Ever Could” →

Embedded Rust Hack Chat

May 10, 2021 by Dan Maloney 18 Comments

Join us on Wednesday, May 12 at noon Pacific for the Embedded Rust Hack Chat with James Munns!

Programming languages, like fashion, are very much a matter of personal taste. Professional developers often don’t have much say in which language they’ll use for a given project, either for legacy or team reasons, but if they did have a choice, they’d probably choose the language that works best with the way they think. Some languages just “fit” different brains better than others, and when everything is in sync between language and developer, code just seems to flow effortlessly through the keyboard and onto the screen.

One language that consistently scores at the top of developers’ “most loved” lists is Rust. For a language that started as a personal project and has only existed for a little more than a decade, that’s really saying something. The emphasis Rust puts on safety and performance probably has a lot to do with that. And thanks to its safe concurrency, its memory safety, and its interoperability with C and other languages, Rust has made considerable in-roads with the embedded development community.

To learn more about Rust in embedded systems, James Munns will stop by the Hack Chat. James is an embedded systems engineer, with a history of working on software for a wide range of systems, including safety-critical avionics, and rapidly prototyped IoT systems. He’s a founding member of the Rust Embedded Working Group, as well as a founder of Ferrous Systems, a consultancy focused on systems development in Rust, with a specialty in embedded systems development. James also used to write for Hackaday, so he must be a pretty cool guy. So swing by the Hack Chat and find out where Rust might be able to help you out with your next embedded project.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 12 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Continue reading “Embedded Rust Hack Chat” →

Homebrew Relay Computer Looks Like It Could Be A Commercial Product

January 19, 2021 by Dan Maloney 21 Comments

You may not have noticed, but we here at Hackaday really love our clicky stuff. Clicky mechanical keyboards, unnecessarily noisy flip-dot displays, and pretty much anything made with a lot of relays — they all grab our attention, in more ways than one. So it’s with no small surprise that we appear to have entirely missed perhaps the clickiest build of all: a fully operational 8-bit computer using nothing but relays.

What’s even more amazing about our failure to find and feature [Paul Law]’s excellent work is that he has been at it for the better part of a decade now. The first post on his very detailed and very well-crafted blog describing the build dates from 2013, when he was just testing LEDs in the arithmetic-logic unit (ALU). Since then, [Paul] has made incredible progress, building module after module, each containing a small portion of the computer’s functionality. The modules plug into card cages with backplanes to connect them, and the whole thing lives in an enclosure made from aluminum extrusion and glossy black panels for a truly sleek look. The computer is incredibly compact for something that uses 400+ DPDT relays to do its thinking.

In addition to the blog, [Paul] has a criminally undersubscribed YouTube channel with a quite recent series going over the computer in depth. We included the overall tour below, but you should really check out the rest of the videos to appreciate how much work went into this build. We’ve seen relay computers ranging in size from single-board to just plain ludicrous, but this one really takes the prize for fit and finish as well as functionality.

Continue reading “Homebrew Relay Computer Looks Like It Could Be A Commercial Product” →

Squeezing Every Bit From An ATMega

December 26, 2020 by Bryan Cockfield 16 Comments

While the ATMega328 is “mega” for a microcontroller, it’s still a fairly limited platform. It has plenty of I/O and working memory for most tasks, but this Battleship game that [thorlancaster328] has put together really stretches the capabilities of this tiny chip. Normally a Battleship game wouldn’t be that complicated, but this one has audio, an LED display, and can also play a fine rendition of Nyan Cat to boot, which really puts the Atmel chip through its paces.

The audio is played through a 512-byte buffer and an interrupt triggers the microcontroller when to fill the buffer while it works on the other processes. The 12×12 LED display is also fed through a shift register triggered by the same interrupt as the audio, and since the build uses so many shift registers the microcontroller can actually output four separate displays (two players, each with a dispaly for shots and one for ships). It will also eventually support a player-vs-computer mode for the battleship game, and also has a mode where it plays Nyan cat just to demonstrate its own capabilities.

We’re pretty impressed with the amount of work this small microcontroller is doing, largely thanks to code optimization from its creator [thorlancaster328]. If there’s enough interest he also says he will provide the source code too. Until then, be sure to check out this other way of pushing a small microcontroller to its limits.

Thanks to [Thinkerer] for the tip!