Portable Pi Teensy Thumboard

January 7, 2019 by Brian McEvoy 12 Comments

Even on the go, there is no substitute for a physical keyboard with buttons that move and click. Sure, you could solder a bunch of tactile switches to some perfboard, but how about going all out and making something robust as [Anthony DiGirolamo] did for his Teensy Thumboard. Everything is insertion-mount so it is an approachable project for anyone who knows the dangerous end of a soldering iron, and that also makes it easy to hack on.

Each pin of the Teensy has an adjacent empty hole tied to it for easy access, and the serial data pins are exposed at the top of the board. All the holes use standard 0.1″ (2.54mm) spacing. The I/O points used by the keyboard are labeled, and the rest of them can use the space under the controller where proto-board style holes add some extra space for an IMU or whatever sensors suit your slant.

Most impressive is the shell, which is freely available on Thingiverse, where you can also find a bill of materials with links to everything you will need in case you don’t have drawers full of those tactile switches.

If this looks familiar, you have probably seen the PocketCHIP, and it is no secret that this project is an homage to that versatile pocket computer. We appreciate this kind of love for PocketCHIP, especially since they are now a limited commodity.

Machine Learning On Tiny Platforms Like Raspberry Pi And Arduino

December 25, 2018 by Bryan Cockfield 25 Comments

Machine learning is starting to come online in all kinds of arenas lately, and the trend is likely to continue for the forseeable future. What was once only available for operators of supercomputers has found use among anyone with a reasonably powerful desktop computer. The downsizing isn’t stopping there, though, as Microsoft is pushing development of machine learning for embedded systems now.

The Embedded Learning Library (ELL) is a set of tools for allowing Arduinos, Raspberry Pis, and the like to take advantage of machine learning algorithms despite their small size and reduced capability. Microsoft intended this library to be useful for anyone, and has examples available for things like computer vision, audio keyword recognition, and a small handful of other implementations. The library should be expandable to any application where machine learning would be beneficial for a small embedded system, though, so it’s not limited to these example applications.

There is one small speed bump to running a machine learning algorithm on your Raspberry Pi, though. The high processor load tends to cause small SoCs to overheat. But adding a heatsink and fan is something we’ve certainly seen before. Don’t let your lack of a supercomputer keep you from exploring machine learning if you see a benefit to it, and if you need more power than just one Raspberry Pi you can always build a cluster to get your task done just a little bit faster, too.

Thanks to [Baldpower] for the tip!

“DB” = Abbreviated Microcontroller Debugging

December 20, 2018 by Drew Risinger 19 Comments

We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.

[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging” →

A Scratch Instrument For Ants

December 20, 2018 by Bryan Cockfield 2 Comments

If you think that this scratch instrument looks as though it should be at least… three times larger in order to be useful, you’d be wrong. This mighty pocket-sized instrument can really get the club hopping despite its diminuitive size. Despite that, the quality of the build as well as its use of off-the-shelf components for almost every part means that if you need a small, portable turntable there’s finally one you can build on your own.

[rasteri] built the SC1000 digital scratch instrument as a member of the portabilist scene, focusing on downsizing the equipment needed for a proper DJ setup. This instrument uses as Olimex A13-SOM-256 system-on-module, an ARM microprocessor, and can use a USB stick in order to load beats to the system. The scratch wheel itself uses a magnetic rotary encoder to sense position, and the slider is miniaturized as well.

If you want to learn to scratch good and learn to do other things good too, there’s a demo below showing a demonstration of the instrument, as well as a how-to video on the project page. All of the build files and software are open-source, so it won’t be too difficult to get one for yourself as long as you have some experience printing PCBs. If you need the rest of the equipment for a DJ booth, of course that’s also something you can build.

Continue reading “A Scratch Instrument For Ants” →

From SPIDriver To I2CDriver

December 9, 2018 by Bryan Cockfield 30 Comments

Communicating with microcontrollers and other embedded systems requires a communications standard. SPI is a great one, and is commonly used, but it’s not the only one available. There’s also I2C which has some advantages and disadvantages compared to SPI. The problem with both standards, however, is that modern computers don’t come with either built-in. To solve that problem and allow easier access to debugging in SPI, [James Bowman] built the SPIDriver a few months ago, and is now back by popular demand with a similar device for I2C, the I2CDriver.

Much like the SPIDriver, the I2C driver is a debugging tool that can be used at your computer with a USB interface. Working with I2C is often a hassle, with many things going on all at once that need to sync up just right in order to work at all, and this device allows the user to set up I2C devices in a fraction of the time. To start, it has a screen built in that shows information about the current device, like the signal lines and a graphical decoding of the current traffic. It also shows an address space map, and has programmable pullup resistors built in, and can send data about the I2C traffic back to its host PC for analysis.

The I2CDriver is also completely open source, from the hardware to the software, meaning you could build one from scratch if you have the will and the parts, or make changes to the code on your own to suit your specific needs. If you’re stuck using SPI still, though, you can still find the original SPIDriver tool to help you with your debugging needs with that protocol as well.

Low-energy ESP8266-based Board Sleeps Like A Log Until Triggered

November 13, 2018 by Brian Boucheron 32 Comments

Given the popularity of hacking and repurposing Amazon Dash buttons, there appears to be a real need amongst tinkerers for a simple “do something interesting on the internet when a button is pressed” device. If you have this need but don’t feel like fighting to bend a Dash device to your will, take a look at [Kevin Darrah]’s trigBoard instead.

The trigBoard is a battery-powered, ESP8266-based board that includes some clever circuitry to help it barely sip power (less than one microamp!) while waiting to be triggered by a digital input. This input could be a magnetic reed switch, push button, or similar, and you can configure the board for either normally open or normally closed switches.

The clever hardware bits that allow for such low power consumption are explained in [Kevin]’s YouTube video, which we’ve also embedded after the break. To summarize: the EPS8266 spends most of it’s time completely unpowered. A Texas Instruments TPL5111 power timer chip burns 35 nanoamps and wakes the ESP8266 up every hour to check on the battery. This chip also has a manual wake pin, and it’s this pin – along with more power-saving circuitry – that’s used to trigger actions based on the external input.

Apparently the microcontroller can somehow distinguish between being woken up for a battery check versus a button press, so you needn’t worry about accidentally sending yourself an alert every hour. The default firmware is set up to use Pushbullet to send notifications, but of course you could do anything an EPS8266 is capable of. The code is available on the project’s wiki page.

The board also includes a standard micro-JST connector for a LiPo battery, and can charge said battery through a micro-USB port. The trigBoard’s full schematic is on the wiki, and pre-built devices are available on Tindie.

[Kevin]’s hardware walkthrough video is embedded after the break.

Continue reading “Low-energy ESP8266-based Board Sleeps Like A Log Until Triggered” →

Trials And Tribulations In Sending Data With Wires

September 25, 2018 by Kerry Scharfglass 14 Comments

When working on a project that needs to send data from place to place the distances involved often dictate the method of sending. Are the two chunks of the system on one PCB? A “vanilla” communication protocol like i2c or SPI is probably fine unless there are more exotic requirements. Are the two components mechanically separated? Do they move around? Do they need to be far apart? Reconfigurable? A trendy answer might be to add Bluetooth Low Energy or WiFi to everything but that obviously comes with a set of costs and drawbacks. What about just using really long wires? [Pat] needed to connect six boards to a central node over distances of several feet and learned a few tricks in the process.

When connecting two nodes together via wires it seems like choosing a protocol and plugging everything in is all that’s required, right? [Pat]’s first set of learnings is about the problems that happen when you try that. It turns out that “long wire” is another way to spell “antenna”, and if you happen to be unlucky enough to catch a passing wave that particular property can fry pins on your micro.

Plus it turns out wires have resistance proportional to their length (who would have though!) so those sharp square clock signals turn into gently rolling hills. Even getting to the point where those rolling hills travel between the two devices requires driving drive the lines harder than the average micro can manage. The solution? A differential pair. Check out the post to learn about one way to do that.

It looks like [Pat] needed to add USB to this witches brew and ended up choosing a pretty strange part from FTDI, the Vinculum II. The VNC2 seemed like a great choice with a rich set of peripherals and two configurable USB Host/Peripheral controllers but it turned out to be a nightmare for development. [Pat]’s writeup of the related troubles is a fun and familiar read. The workaround for an incredible set of undocumented bad behaviors in the SPI peripheral was to add a thick layer of reliability related messaging on top of the physical communication layer. Check out the state machine for a taste, and the original post for a detailed description.