Vintage Programmer Gets Modern Chip Adapter

January 8, 2019 by Tom Nardi 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 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!