OpenCV Running On A Tiny Microcontroller

May 19, 2022 by Bryan Cockfield 10 Comments

At first blush, it might seem like projects that make extensive use of computer vision or machine learning would need to be based on powerful computing platforms with plenty of clock cycles and memory to handle this type of application. While there is some truth to this, as the field progresses it becomes possible to experiment with these tools on low-power devices as well. Take this OpenCV project which is built entirely on an ESP32 for example.

With that being said, there are some modifications that need to be made to the ESP32 in order to use OpenCV in any meaningful way. The most important of these is the use of the ESP32-DOWDQ6 module which increases the available memory of the ESP32 to allow it to make better use of camera functions. Even then, the ESP32 can’t run the entire OpenCV application, so a shrunken version of OpenCV is required before the device can run it natively. Once those two obstacles are out of the way, though, doing things like edge detection, as this project demonstrates, are well in the realm of possibility.

If running OpenCV on something as small as an ESP32 is possible, it is even easier to run on something orders of magnitude more powerful and yet still inexpensive, such as the Raspberry Pi. While the project’s code is available on its GitHub page for those interested, there are plenty of other OpenCV projects that we have featured on more powerful platforms as well, like this clock which falls off of the wall whenever someone looks at it.

Continue reading “OpenCV Running On A Tiny Microcontroller” →

Hard(er) Drives: Impractical, Slow, Amazing, And Incredible

April 22, 2022 by Ryan Flowers 19 Comments

Computer memory is a problem that has been solved for many years. But early on, it was more than just a small problem. We’ve many of the different kinds at Hackaday over the years, and we’ll link to some of them later on. But one of the original types of memory was called Delay Line memory, which worked by waiting for a signal to propagate slow enough through a device that it was essentially stored in the device. This was highly inefficient, but still a neat concept- one that [Tom7] has taken to entirely new levels of amazing and impractical as seen in the video below the break.

Such factors as “harm to society” are artfully considered

Starting with a demonstration of orbiting chainsaws, he then moves on to explaining how radio propagation waves could be used to temporarily store data while it’s in transit. He missed the opportunity to call it cloud storage, but we’ll forgive him. Extrapolating that further, he decided to use the Entire Internet to store data without its permission, utilizing large ICMP packets and even making it available as block storage in Linux.

Not content to use the entire Internet to store a few kb of data, he moved on to several thousand virtualized NES game systems which are all playing “an inventory management survival horror game” commonly known as Tetris. [Tom7] deconstructs Tetris, analyzing its Random Number Generator, gaming the system to store data in virtual NES consoles by the thousands. What data did he store? The source code to Tetris for the NES. And what did he do with it? Well, he mounted it and ran the program, of course!

The last Harder Drive we’ll leave for those who want to watch the video, because it’s a bit on the “ewww gross!” side of things but is also a bit less successful due to some magic smoke being released.

If none of these things we’ve mentioned were enough, then watch the video for an excellent breakdown of the cost, efficiency, and even the harm to society. For fun, he also tosses blockchain into the mix to see how it fares against the Harder Drives. There’s also at least one easter egg in the video, and the whimsical discussion of engineering is both entertaining and inspiring. How would you implement a Harder Drive?

[Tom7] also gives you the opportunity to follow along with the fun and mayhem by making much of the code available for your perusal. For more fun reading, check out this walk down computer memory lane that we covered last year, as well as a look into Acoustic Delay Line memory.

Continue reading “Hard(er) Drives: Impractical, Slow, Amazing, And Incredible” →

Glow In The Dark Computer Memory Illuminates The Fundamentals

April 11, 2022 by Chris Wilkinson 22 Comments

Computer memory has taken on many forms over the years, from mercury-based delay-line tubes to handwoven magnetic core. These days, volatile storage using semiconductors has become ubiquitous with computing, but what if there was a better way? [Michael Kohn] has been working on a new standard for computer memory that uses glow in the dark stickers.

Clearly we jest, however we’re still mighty impressed by the demonstration. Eight delightful star-shaped phosphorescent stickers represent eight bits of memory, totaling one byte. The glow in the dark material is stuck to the inside of short cylinders, each of which contains a white LED and a phototransistor. The memory array is wired up to an iceFUN FPGA board, which is then connected via level shifters to a Western Design Center MENSCH single board computer.

Continue reading “Glow In The Dark Computer Memory Illuminates The Fundamentals” →

Stress-Testing An Arduino’s EEPROM

April 7, 2022 by Bryan Cockfield 29 Comments

Every time one of us flashes an Arduino’s internal memory, a nagging thought in the backs of our minds reminds us that, although everything in life is impermanent, nonvolatile re-writable memory is even more temporary. With a fixed number of writes until any EEPROM module fails, are we wasting writes every time we upload code with a mistake? The short answer is that most of us shouldn’t really be concerned with this unless we do what [AnotherMaker] has done and continually write data until the memory in an Arduino finally fails.

The software for this is fairly simple. He simply writes the first 256 ints with all zeros, reads them to make sure they are all there, and then repeats the process with ones. After iterating this for literally millions of times continuously over the course of about a month he was finally able to get his first read failure. Further writes past this point only accelerated the demise of the memory module. With this method he was able to get nearly three million writes before the device failed, which is far beyond the tens or hundreds of thousands typically estimated for a device of this type.

To prove this wasn’t an outlier, [AnotherMaker] repeated the test, and did a few others while writing to a much smaller amount of memory. With this he was able to push the number of cycles to over five million. Assuming the Arduino Nano clone isn’t using an amazingly high-quality EEPROM we can safely assume that most of us have nothing to worry about and our Arduinos will be functional for decades to come. Unless a bad Windows driver accidentally bricks your device.

Continue reading “Stress-Testing An Arduino’s EEPROM” →

Hackaday Links: February 20, 2022

February 20, 2022 by Dan Maloney 23 Comments

Sounds like somebody had a really bad day at work, as Western Digital reports that “factory contamination” caused a batch of flash memory chips to be spoiled. How much, you ask? Oh, only about 7 billion gigabytes! For those of you fond of SI prefixes, that’s 7 exabytes of storage; to put that into perspective, it’s seven times what Google used for Gmail storage in 2012, and enough to store approximately 1.69 trillion copies of Project Gutenberg’s ASCII King James Version Bible. Very few details were available other than the unspecified contamination of two factories, but this stands poised to cause problems with everything from flash drives to phones to SSDs, and will probably only worsen the ongoing chip shortage. And while we hate to be cynical, it’ll probably be prudent to watch out for any “too good to be true” deals on memory that pop up on eBay and Ali in the coming months.

Continue reading “Hackaday Links: February 20, 2022” →

Keynote Video: Elecia White Finds Treasure In The Memory Map

December 16, 2021 by Elliot Williams 9 Comments

If you dig microcontrollers, and you like to dig into how they work, Elecia White wants to help you navigate their innermost secrets with the help of memory map files. In this refreshingly funny, but very deep keynote talk from the 2021 Hackaday Remoticon, Elecia guides us through one of the most intimidating artifacts of compilation — a file that lists where everything is being put in the microcontroller’s memory — and points out landmarks that help to make it more navigable.

And when you need to look into the map file, you probably really need to look into the map file. When your embedded widget mysteriously stops working, memory problems are some of the usual suspects. Maybe you ran out of RAM or flash storage space, maybe you have some odd hard fault and you want to know what part of the program is causing the trouble, or maybe you need to do some speed profiling to make it all run faster. In all of these cases, you get an absolute memory address. What lives there? Look it up in the memory map!

Continue reading “Keynote Video: Elecia White Finds Treasure In The Memory Map” →

Reballing And A Steady Hand Makes A Raspberry Pi 800

November 8, 2021 by Jenny List 41 Comments

The all-in-one Raspberry Pi 400 computer is a capable device, but those seeking its maximum power may be disappointed by its 4 GB of memory. When the Pi 4 and Compute Module 4 have double that figure, surely the Pi 400 could catch up! A reddit user called [Pi800] rose to the challenge by replacing the 4 GB chip from the Pi 400 with the 8 GB chip from a Pi Compute Module, resulting in the so-called Pi 800, a working 8 GB all-in-one Pi.

As a piece of work it’s a deceptively straightforward yet extremely fiddly piece of soldering that requires a steady hand for even the most skilled of solderers. What takes it beyond the norm though is the reballing process. A ball-grid-array chip has a grid of small balls of solder on its underside that make the contacts, and these melt when it is soldered so require replacement before reworking. This is normally done with a template of carefully aligned holes to line up balls of solder in a stream of hot air, but lacking the template in this case the job was done by hand, laboriously ball by ball. A soldering task we’d hesitate to take on ourselves, so we’re impressed.

The result is an 8 GB all-in-one Pi, and it’s honestly not beyond the realms of possibility that an official version of this mod could be a future Raspberry Pi product. Perhaps we’ll wait for that, but should you be impatient then at least it’s possible to roll your own. It’s certainly not the first BGA memory swap we’ve brought you.