CortexProg Is A Real ARM-Twister

We’ve got a small box of microcontroller programmers on our desktop. AVR, PIC, and ARM, or at least the STMicro version of ARM. Why? Some program faster, some debug better, some have nicer cables, and others, well, we’re just sentimental about. Don’t judge.

[Dmitry Grinberg], on the other hand, is searching for the One Ring. Or at least the One Ring for ARM microcontrollers. You see, while all ARM chips have the same core, and thus the same SWD debugging interface, they all write to flash differently. So if you do ARM development with offerings from different chip vendors, you need to have a box full of programmers or shell out for an expensive J-Link. Until now.

[Dmitry] keeps his options open by loading up the flash-specific portion of the code as a plugin, which lets the programmer figure out what chip it’s dealing with and then lookup the appropriate block size and flash memory procedures. One Ring. He also implements a fast printf-style debugging aid that he calls “ZeroWire Trace” that we’d like to hear more about. Programming and debugging are scriptable in Lua, and it can do batch programming based on reading chip IDs.

You can build your own CortexProg from an ATtiny85, two diodes, and two current-limiting resistors: the standard V-USB setup. The downside of the DIY? Slow upload speed, but at least it’ll get you going. He’s also developed a number of fancier versions that improve on this. Version four of the hardware is just now up on Kickstarter, if you’re interested.

If you’re just using one vendor’s chips or don’t mind having a drawer full of programmers, you might also look into the Black Magic Probe. It embeds a GDB server in the debugger itself, which is both a cool trick and the reason that you have to re-flash the programmer to work with a different vendor’s chips. Since the BMP firmware is open, you can make your own for the cost of a sacrificial ST-Link clone, about $4.

On the other hand, if you want a programmer that works across chip families, is scriptable, and can do batch uploads, CortexProg looks like a caviar programmer on a fish-bait budget. We’re going to try one out soon.

Oh and if you think [Dmitry Grinberg] sounds familiar, you might like his sweet Dreamcast VRU hack, his investigations into the Cypress PSOCs, or his epic AVR-based Linux machine.

ERRF 18: New Products Make Their Debut

While ostensibly the purpose of the recent East Coast RepRap Festival (ERRF) was to celebrate the 3D printing community and culture, it should come as no surprise that more than a few companies decided to use the event as an opportunity to publicly launch new products. Who can blame them? It’s not as if every day you have a captive audience of 3D printing aficionados; you might as well make the best of it.

Many creations were being shown off for the first time at ERRF, and we surely didn’t get a chance to see them all. There was simply too much going on at any given time to be sure no printed stone was left unturned. But the following printers, filaments, and accessories caught our attention long enough to warrant sharing with the good readers of Hackaday.

Keep in mind that much of this information is tentative at best, and things could easily change between now and when the products actually go on sale. These events serve as much as a sounding board for new products as they do a venue for advertising and selling them, so feedback received from show attendees may very well alter some of these products from what we saw at ERRF.

Continue reading “ERRF 18: New Products Make Their Debut”

Shoehorning A Slick Spotify Remote Into An ESP8266

In 2017 Spotify finally deprecated their public vanilla C SDK library,  libspotify, and officially replaced it with dedicated SDKs for iOS and Android and this new-fangled web thing we’ve all heard so much about. This is probably great for their maintainability but makes writing a native application for a Linux or a hardware device significantly harder, at least without an application process and NDA. Or is it? Instead of using that boring slab of glass and metal in their pocket [Dani] wanted to build a handy “now playing” display and remote control interface but was constrained by the aforementioned SDK limitations. So they came up with a series of clever optimizations resulting in the clearly-named ESP8266 Spotify Remote Control.

The Spotify Remote Control has a color LCD with a touchscreen. Once attached to a Spotify account it will show the album art of the currently playing track (with a loading indicator!) and let you play/pause/skip tracks from its touch screen, all with impressively low latency. To get here [Dani] faced two major challenges: authorizing the ESP to interact with a user’s Spotify account, and low latency LCD drawing.

2 Bit Cover Art

If you’re not on iOS or Android, the Spotify web API is the remaining non-NDA’d interface available. But it’s really designed to be used on relatively rich platforms such as fully featured web browsers, not an embedded device. To that end, gone are the days of asking a user to enter their username and password in a static login box, the newer (better) way is to negotiate for a per-user token (which is individually authorized per application), then to use that to authenticate your interaction. With this regime 3rd party applications (in this case an ESP8266) never see a user’s password. One codified and very common version of this process is called OAuth and the token dance is called a “workflow”. [Dani] has a pretty good writeup of the process in their post if you want more detail about the theory. After banging out the web requests and exception handling (user declines to authorize the device, etc) the final magic ended up being using mDNS to get the user’s browser to redirect itself to the ESP’s local web server without looking up an IP first. So the setup process is this: the ESP boots and displays a URL to go to, the user navigates there on a WiFi connected device and operates the authorization workflow, then tokens are exchanged and the Remote Control is authorized.

The second problem was smooth drawing. By the ESP’s standards the album art for a given track at full color depth is pretty storage-large, meaning slow transfers to the display and large memory requirements. [Dani] used a few tricks here. The first was to try 2 bit color depth which turned out atrociously (see image above). Eventually the solution became to decompress and draw the album art directly to the screen (instead of a frame buffer) only when the track changed, then redraw the transport controls quickly with 2 bit color. The final problem was that network transfers were also slow, requiring manual timesharing between the download code and the display drawing routing to ensure everything was redrawn frequently.

Check out [Dani]’s video after the break, and take a peek at the sources to try building a Spotify Remote Control yourself.

Continue reading “Shoehorning A Slick Spotify Remote Into An ESP8266”

Diode Recovery Time Explained

There are at least two phases to learning about electronics. In the first phase, you learn about how components are supposed to work. In the second phase, you learn about how they really work. Wires have resistance and inductance. Adjacent wires have capacitance. Capacitors leak. Inductors have resistance. All of these things matter. [Learnelectronics] has a recent video that explores recovery time for a diode — a phase two conversation.

If you haven’t run into recovery time before, it is the amount of time the diode takes to shut off after it is conducting. This manifests itself as a little undershoot where the signal that the diode should block leaks through briefly.

Continue reading “Diode Recovery Time Explained”

ERRF 18: Slice Engineering Shows Off The Mosquito

With few exceptions, it seemed like every 3D printer at the first inaugural East Coast RepRap Festival (ERRF) was using a hotend built by E3D. There’s nothing inherently wrong with that; E3D makes solid open source products, and they deserve all the success they can get. But that being said, competition drives innovation, so we’re particularly interested anytime we see a new hotend that isn’t just an E3D V6 clone.

The Mosquito from Slice Enginerring is definitely no E3D clone. In fact, it doesn’t look much like any 3D printer hotend you’ve ever seen before. Tiny and spindly, the look of the hotend certainly invokes its namesake. But despite its fragile appearance, this hotend can ramp up to a monstrous 500 C, making it effectively a bolt-on upgrade for your existing machine that will allow you to print in exotic materials such as PEEK.

We spent a little time talking with Slice Engineering co-founder [Dan], and while there’s probably not much risk it’s going to dethrone E3D as the RepRap community’s favorite hotend, it might be worth considering if you’re thinking of putting together a high-performance printer.

Continue reading “ERRF 18: Slice Engineering Shows Off The Mosquito”

SPIDriver Shows You What’s Going On

When you’re debugging two bits of electronics talking SPI to each other, there’s a lot that can go sideways. Starting from the ground up, the signals can be wrong: data not synced with clocks right, or phase inverted. On top of that, the actual data sent needs to make sense to the receiving device. Are you sending the right commands?

When nothing’s working, you’re fighting simultaneously on these two fronts and you might need different tools to debug each. An oscilloscope works great at the physical layer, while something like a Bus Pirate or fancier logic analyzer works better at the data layer because it can do parsing for you. [James Bowman]’s SPIDriver looks to us like a Bus Pirate with a screen — giving you a fighting chance on both fronts.

SPIDriver also has a couple more tricks up its sleeve: a voltage and current monitor for the device under test, so you don’t even have to break out your multimeter when you’re experiencing random resets. We asked [James] if these additions had a sad history behind them. He included this XKCD.

Everything about SPIDriver is open, so you can check out the hardware design, browse the code, and modify any and all of it to your taste. And speaking of open, [James] is also the man behind the Gameduino and an amazing FPGA Forth soft-CPU.

It’s fully crowd-funded, but it closes in a couple of days so if you want one, get on it soon.

And if you want to learn more about SPI debugging, we’ve written up a crash-course. With the gear and the know-how, you at least stand a fighting chance.

A Peek Into A Weed-Eating Robot’s Test Fixtures

When it comes to production, fast is good! But right the first time is better. Anything that helps prevent rework down the line is worth investing in. Some of the best tools to catch problems are good test fixtures. The folks at Tertill (a solar-powered robot for killing weeds that kickstarted last year) took the time to share two brief videos of DIY test fixtures they use to test components before assembly.

The videos are short, but they demonstrate all the things that make a good test: on the motor tester there are no connectors or wires to fiddle with, the test starts automatically, and there is clear feedback via prominent LEDs. The UI board tester also starts automatically and has unambiguous LED feedback, and sports a custom board holder with a recess just the right shape for the PCB. Once the board is in, the sled is pushed like a drawer to make contact with the test hardware and begin the test. The perfectly formed recesses in both units serve another function as well; they act as a go/no-go test for the physical shape of the components and contacts being tested.

Both videos are embedded below; and while there isn’t much detail on the actual test hardware, we do spy a Raspberry Pi and at least two Adafruit logos among other hacker-familiar elements like laser-cut acrylic, 3D printed plastic, pogo pins, and a PVC junction box.

Continue reading “A Peek Into A Weed-Eating Robot’s Test Fixtures”