Being An SPI Slave Can Be Trickier Than It Appears

January 8, 2019 by Kerry Scharfglass 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 Sean Boyce 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 Elliot Williams 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 Brian McEvoy 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 Kerry Scharfglass 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!

Automatic Soap Dispenser Hides Arduino Board

December 25, 2018 by Tom Nardi 46 Comments

If you’ve been hanging out here at Hackaday for awhile, you’ve certainly seen projects that were based around the concept of putting a miniature computer inside the carcass of some other piece of electronics. In fact at this point it’s something of a running joke, certainly we must have seen an Arduino or Raspberry Pi shoehorned into every type of consumer gadget ever built by this point. But if you thought this would be another example of that common trope by the headline, you might be in for something of a surprise.

[zapta] didn’t put an Arduino inside this GOJO LTX-7 soap dispenser, it was already in there to begin with. That’s right, apparently we’ve hit the point that even cheap soap dispensers are now running on programmable microcontrollers. While we can’t blame those of you who are no doubt groaning and/or rolling their eyes thanks to this particular case of computational gluttony, it does mean we’re able to report with a straight face something which frankly would have passed as an April Fool’s joke in previous years: the development of an open source soap dispensing firmware.

So how does one upload a new Arduino sketch to their GOJO soap dispenser? It’s not like the thing has a USB port on the side for convenient hacking. As explained by [zapta], it involves stripping the dispenser all the way down until the electronics board is free, and then adding in a programming header to make subsequent firmware fiddling a bit easier. Writing a new firmware to the ATTiny48 powered board will require an external ISP (the Atmel AVRISP MKII was used for this hack, though any should work), but it’s otherwise pretty painless.

[zapta] has done an excellent job documenting the different components on the board, and reverse engineered enough of the critical aspects (such as the motor controller and proximity sensor) to write a new open source firmware which can be flashed to the GOJO LTX-7. Beyond allowing you to “Open Source All the Things”, using this new firmware does have some practical advantage in that you can configure how much soap is dispensed per activation. Going further, we’d be exceptionally interested in hearing about anyone who manages to come up with a firmware that enables some hitherto impossible soap dispensing trickery.

We’ve seen hacks involving dispensers of all types, from Halloween games that spit out candy to gadgets which let dogs get their own treats, but a soap dispenser hack is something truly new for us. More proof that there’s still plenty of hardware out there just waiting to be hacked!

GoPro Factory Goes Nomad To Dodge Tariff Threat

December 19, 2018 by Tom Nardi 71 Comments

Despite the fact that the United States and China are currently in the middle of a 90-day “cease fire” in their ongoing trade war, with new tariffs on hold until March 2019 while the two countries try to reach agreement, not everyone is waiting around to see who comes out on top. In a recent press release, action camera manufacturer GoPro has announced their intention to move some production out of China in the face of potential tariff expansions; which many analysts fear will be the result of the current stalemate. That’s right, only some of their production is moving.

“We’re proactively addressing tariff concerns by moving most of our US-bound camera production out of China,” says GoPro CFO Brian McGee. “We believe this diversified approach to production can benefit our business regardless of tariff implications.” Reading his words carefully, the key phrase here is “diversified approach”. GoPro doesn’t intend to move their entire production capability out of China, but only the production of the cameras which are designated for importation into the United States. GoPro models which are to be sold to other parts of the world will still be made in China.

This might seem an extravagant move just to avoid US tariffs, but with better than 40% of GoPro’s revenue for the third quarter of 2018 coming from the Americas, the company stands to be hit hard by the proposed 25% tax. Combined with the fact they shuttered their drone division last year citing “an extremely competitive aerial market”, and the proliferation of “GoPro clones” available for pennies on the dollar, it seems pretty clear that belt-tightening is the name of the game for the company that was once synonymous with action cameras.

Continue reading “GoPro Factory Goes Nomad To Dodge Tariff Threat” →