hardware

1772 Articles

Is Baking A Raspberry Pi The Recipe For Magic Smoke?

January 10, 2019 by 35 Comments

No, Hackaday hasn’t become a baking blog. We’re just here to give you a bit of advice: if [MickMake] ever offers you one of his fresh-baked Pis, proceed with caution. While we have no doubt that there will be some interesting smells wafting out of his kitchen, these aren’t the tasty pies you’re looking for. There’s no delicious home-baked treat when that timer dings, just a handful of Raspberry Pis that have had an exceptionally hard day.

To properly explain the odd sight of some Raspberry Pis laid out on a cookie sheet, we need to take a step back. [MickMake] originally set out to see how everyone’s favorite Linux SBC would handle the harsh Australian heat, and thought that setting them up on his car’s dashboard would be a suitable torture test. But as luck would have it, a storm rolled in while he was making the video which brought temperatures down to a “cool” 30 C (86 F); basically jacket weather at the bottom of the world. So naturally, he decided to put them in his oven instead.

Placed on an insulating sheet and with a thermocouple between them to get an accurate idea of the temperature they were experiencing, an original Pi, a Pi 2, and a pair of Pi 3s were sent on the ride of their lives. In addition to monitoring them over the network, he also added a “heartbeat” LED to each Pi so he’d be able to tell at a glance if any of them had given up the ghost. As if these poor little Pis didn’t have it bad enough already, [MickMake] decided to take things a step farther and run sysbench on them while they took their trip through Hades.

The Pis are actually rated for temperatures up to 85C, and all the participants of the experiment hit that point without any issues. At 87.3 C (~190 F) the original Pi dropped off the network, but its LED was seen bravely blinking on. At 105.7 C (~222 F) it finally breathed its last, followed by the pair of Pi 3s tapping out at 112 C (233 F). The Pi 2 fought on, but it fell right at the 119 C (246 F) mark.

But what about when they cooled off? Somewhat surprisingly, [MickMake] successfully powered all four back up and was unable to find any damage to the Pis, either physically or operationally. Even the SD cards survived, and the Pis popped right back onto the network and were ready for another round of Silicon Chef. Not bad considering they were subjected to temperatures three times higher than the official limit.

Testing electronics in your home oven might seem a bit suspect, and admittedly we’d probably turn down a slice of the next few frozen pizza’s [MickMake] runs through it, but it’s not really so far removed from how proper reliability testing is performed.

Continue reading “Is Baking A Raspberry Pi The Recipe For Magic Smoke?” →

Vintage Programmer Gets Modern Chip Adapter

January 8, 2019 by 8 Comments

While trying to revive a Donkey Kong Jr arcade board, [Jelmer Bruijn] found himself in the market for an EPROM programmer and became the proud owner of a 1990’s era Dataman S4. Despite its age, it’s a fairly nice tool which allows you to read and write a laundry list of different EPROM types, all without being tied to a computer. The only catch is that a few types of chips need an adapter to work in the Dataman S4, some of which are unsurprisingly no longer available.

After some above and beyond support from the current crew at Dataman set him on the right track, [Jelmer] decided to try his hand at reverse engineering how the old adapters worked so he could build his own. His ultimate goal was to read 40 pin EPROMs on the 32 pin Dataman S4, but in the end he says the information he gathered should be applicable for building other adapters if you ever find yourself in need of such things.

As you might expect, there’s a bit more to the project than a simple pin adapter. [Jelmer] assumed some kind of shift register or latching arrangement would be required to make up for the shortage of pins on the Dataman S4’s ZIF socket. It was just a matter of figuring out how it all went together.

Luckily, [Jelmer] found that the programmer would happily attempt to perform operations on a 16 bit EPROM even though no adapter was physically present. This gave him a chance to probe around with a logic analyzer to figure out what it was trying to accomplish. The trick turned out to be splitting the 16 bit bus into two 8 bit buses which are requested sequentially.

With careful observation, close studying of 16 bit chip datasheets, and much brow furrowing, he was eventually able to come up a design that used five 74xx573 latches and put a schematic together in Eagle. There were a few kinks to iron out when the boards finally arrived, but ultimately the design worked on the first try. [Jelmer] says the same technique should work for 42 pin EPROMs, but as Dataman still actually sell adapters for those he decided not to supply schematics for it.

[Jelmer] tells us that he was inspired to send this success story our way after reading how our very own [Elliot Williams] took the long away around to erase a couple UV EPROMs recently While this isn’t the first time we’ve seen somebody have to hack support for 16 bit EPROMs into their programmer, it’s good to see that the manufacturer at least had the customer’s back in this case.

Being An SPI Slave Can Be Trickier Than It Appears

January 8, 2019 by 10 Comments

Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.

The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.

But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.

Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.

Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption

January 3, 2019 by 7 Comments

When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.

I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.

About seven weeks ago, support for the libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.

However, my preferred automated build tool for NodeMCU wasn’t available on the ESP32 yet. Compiling the firmware was required – this turned out to be a surprisingly user-friendly experience, so I thought I’d share it with you. If I had known it would be so quick, this chip wouldn’t have sat on my desk unused quite so long!  Continue reading “Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption” →

Fail Of The Week: EPROMs, Rats’ Nests, Tanning Lamps, And Cardboard On Fire

January 2, 2019 by 87 Comments

It all started when I bought a late-1990s synthesizer that needed a firmware upgrade. One could simply pull the ROM chip, ship it off to Yamaha for a free replacement, and swap in the new one — in 2003. Lacking a time machine, a sensible option is to buy a pre-programmed aftermarket EPROM on eBay for $10, and if you just want a single pre-flashed EPROM that’s probably the right way to go. But I wanted an adventure.

Spoiler alert: I did manage to flash a few EPROMs and the RM1X is happily running OS 1.13 and pumping out the jams. That’s not the adventure. The adventure is trying to erase UV-erasable EPROMS.

And that’s how I ended up with a small cardboard fire and a scorched tanning lamp, and why I bought a $5 LED, and why I left EPROMs out in the sun for four days. And why, in the end, I gave up and ordered a $15 EPROM eraser from China. Along the way, I learned a ton about old-school UV-erasable EPROMs, and now I have a stack of obsolete silicon that’s looking for a new project like a hammer looks for a nail — just as soon as that UV eraser arrives in the mail.

Continue reading “Fail Of The Week: EPROMs, Rats’ Nests, Tanning Lamps, And Cardboard On Fire” →

Bottom Of The Barrel Connector: Tell Us Your Socket Hacks

December 26, 2018 by 37 Comments

Sometimes you get an epiphany for a project that will change the world. A simple device, on a custom circuit board with inexpensive parts that will disrupt the status quo and make you a billion dollars in no time. Then there are the times where you need to throw scraps of copper at a prototyping board and strangle nine-volts out by any means necessary.

This is about the latter. In one of our Hack Chats, [Morning.Star] shared a couple of images wherein a barrel connector was needed, but there was no time to wait for one in the mail. Necessity birthed the most straightforward solution which did not involve shredding a power adapter’s plug. There is no link, [Stuart Longland] aka [Redhatter] screen-capped the image exchange and reminded us on the tip line.

Chances are you’ve faced this problem yourself. Everyone has a box of old wall warts somewhere, exhibiting a wide range of barrel connector sizes. If you can’t take the easy route of cutting off the connectors, what’s your go-to trick? Alligator clips are a horrid approach, and there aren’t really any clear winners that come to mind. [Morning.Star’s] hack is actually quite respectable! It appears to be a roll of copper (perhaps from tubing?) bent for a bit of spring tension on the outside of the barrel. The inside is contacted by thick copper wire with a kink to again provide spring action.

So, spill the beans. What’s your barrel connector trick and does it work reliably?

Bonanza Of Keyswitch Datasheets Fills Our Decks With Clack

December 26, 2018 by 8 Comments

Mechanical keyboards use switches of a few different types. But even those types include myriad variations. How’s a hacker to know just exactly what equipment is out there?

For example, if you grab a fellow cube-farmer’s mechanical keyboard (possibly because they clacked on their Cherry Blue’s just one too many times) and angrily rip off a few keycaps to show you’re serious, what do you see? In most cases you expect to see the familiar color and stem shape of a Cherry MX switch or one of its various clones. But you may find a square box around it like a Kailh Box switch. Or the entire stem is a box (with no +) like a Matias switch. Or sometimes it looks like a little pig snout, making it a Kailh Choc.

There is a fairly wide variety of companies which make key switches suitable for use in a keyboard. Many hew to the electrical and mechanical standards implicitly created by the dominant Cherry GmbH’s common switches but not all. So if you’re designing a PCB for such a keyboard and want to use odd switches, you need to check out the Keyboardio keyswitch_documentation repo!

The keyswitch_documentation repo is an absolute treasure trove of hard to find keyswitch datasheets. Finding official information on Cherry MX switches isn’t too hard (keyswitch_documentation has 22 data sheets for MX series switches, and four for ML). But those Kailh Choc’s? Good luck (here it is in keyswitch_documentation). Did you know Tai-Hao made Matias-esque switches as well as weird rubber keycaps? Well they do, and here’s the datasheet.

We’re keeping this one handy until the next time we need data sheets for weird switches. Make sure to send a note if you find something interesting in here that’s worth noting!