[Ralph Doncaster], aka Nerdralph, seems to be absolutely driven to see how few resources he can use on a microcontroller to get the job done. In this post on his blog, [Ralph] writes some custom bit-banged SPI code to cut the number of SPI lines necessary to drive an nRF24L01+ radio module from four down to two. That really helps if you’re using a micro with only six free pins, like an ATtiny85.
If you’re going to say, “why don’t you just buy a bigger microcontroller?”, you’re missing the point. This exercise strikes us as optimization for optimization’s sake and a dirty hack, both of which are points in its favor. There are also a couple of techniques here for your mental toolbox. We thought it was interesting enough to look at in depth.
Continue reading “Embed with Elliot: Multiplexing SPI Uses Few Pins”
A while ago, [Paul Stoffregen], the creator of the Teensy family of microcontrollers dug into the most popular Arduino library for driving TFT LCDs. The Teensy isn’t an Arduino – it’s much faster – but [Paul]’s library does everything more efficiently.
Even when using a standard Arduino, there are still speed and efficiency gains to be made when driving a TFT. [Xark] recently released his re-mix of the Adafruit GFX library and LCD drivers. It’s several times faster than the Adafruit library, so just in case you haven’t moved on the Teensy platform yet, this is the way to use one of these repurposed cell phone displays.
After reading about [Paul]’s experience with improving the TFT library for the Teensy, [Xark] grabbed an Arduino, an LCD, and an Open Workbench Logic Sniffer to see where the inefficiencies in the Adafruit library were. These displays are driven via SPI, where the clock signal goes low for every byte shifted out over the data line. With the Adafruit library, there was a lot of wasted time in between each clock signal, and with the right code the performance could be improved dramatically.
The writeup on how [Xark] improved the code for these displays is fantastic, and the results are impressive; he can fill a screen with pixels at about 13FPS, making games that don’t redraw too much of the screen at any one time a real possibility.
Does your dog or cat wake you up every morning, demanding to be fed? Maybe you feed Sparky in the evenings instead. But doesn’t that limit your spontaneity? It sure limited [Jorge]’s after-work plans. He has two dogs that eat the same type of food, but in different quantities. This was a big factor in the design and execution of his dual pet food dispenser.
[Jorge] started by modeling his requirements in 3D. Dispensing takes place in two stages as food moves from the storage hopper to the bowls. A 12V printer motor turns the 3D-printed auger, which transports the nuggets to the staging area. Here, a servo controls a ramp in a see-saw motion, sending the food sliding sideways into one bowl or the other.
The dispenser is designed around a PIC18F2420. Although this micro was [Jorge] ‘s second choice, it ticks all the boxes in the design. His acrylic enclosure features four push buttons for navigation and selection through the 16×2 LCD. [Jorge] has an issue with the food getting stuck in the first stage. A friend suggested that he use vibration to agitate the food, but that didn’t work. [Jorge] ultimately added a stirring shaft with spokes that helps keep the morsels moving. Take the tour after the break.
If you want to dispense single doses of food on a timer, check out this automatic cat feeder made from scavenged parts.
Continue reading “Dual Pet Food Dispenser is Doubly Convenient”
The ESP8266 is an incredible piece of hardware; it’s a WiFi module controllable over a serial port, it’s five freaking dollars, and if that’s not enough, there’s a microcontroller on board. Until there’s a new radio standard, this is the Internet Of Things module.
The most common version of the ESP, the -01 version, only has a 2×4 row of pins for serial, power, configuration, and two lines of GPIO. It’s a shame that module only has two GPIOs, but if you’re good enough with a soldering iron you can get a few more. It took a lot of careful soldering, but [Hugatry] managed to break out two more GPIOs on this tiny module.
According to [Hugatry] a lot of patience to solder those wires onto those tiny pads, but after finishing this little proof of concept he discovered a Russian hacker managed to tap into four extra GPIOs on the ESP8266-01 module (Google Translatrix).
As a proof of concept, it’s great, but there’s more than one ESP module out there. If you’re looking for a cheap WiFi module, check out the ESP-03, -04, or -07; they have nice castellated pins that are exceptionally easy to solder to.
Continue reading “More GPIOs For The ESP8266″
A lot of projects get made because someone just has the parts lying around. In this case, [Ed Nisley] got given a nice 8×8 RGB LED matrix, and needed something to display. [Ed] details the transformation of stuff-lying-on-the-desk into a unique matrix display for a Geiger counter (which he also presumably had sitting around somewhere). The result is a lightshow that’s as random as radioactive decay, and that’s pretty darn random.
The first post covers the hardware layout. It’s build on protoboard, but ends up looking a lot nicer than our projects because [Ed] spent some time hiding the shift-register ICs and row-driver transistors underneath the matrix itself, which was nicely socketed above. A sweet touch is the use of SMT resistors soldered upright underneath the board to save space. Cute.
The second post covers the circuit design, and is worth a look if you’re new to driving many LEDs from a minimum number of microcontroller pins. There are eight rows, and three colors each for eight LEDs per row. Without using shift registers, this would require 8*8*8*8 = way too many pins to control. If you want a worked example of how to do this with just four microcontroller pins, have a look. (Spoiler: cascaded shift registers driven by the AVR’s hardware SPI peripheral.)
The third post starts to flesh out the software. [Ed] settled on seven colors (and off) for the display, so the matrix’s total state can be crammed into just 32 bytes, which fits nicely in even a tiny microcontroller, much less the gargantuan ATmega328. Wrapping this all up in an array of structs and providing a couple of helper functions makes quick work of the software side. The addition of a sync pulse to trigger an oscilloscope at the end of a row is a nice touch.
Next up is the Geiger counter interface software post. When a radioactive decay event is detected, the code reads out the time in milliseconds and uses that as the source of randomness. To whiten the noise, the times are run through a simple hash function: the Jenkins hash (link). This hash function was new to us and seems pretty useful for quick-and-dirty microcontroller applications.
The last post details pre-loading the matrix on startup and running a test sequence that blinks each LED to make sure they’re all working. Using a single random value to seed a software pseudo-random number generator ensures that it will (almost) never start off with the same display twice.
Phswew! That’s a lot of well-documented writeup of a well-polished project! Hope it inspires you to dig out something cool from your junk drawer and build.
Instead of going the usual route and determining the future of Tessel through market research and the apparent pragmatism of whoever happens to be in charge, this week Technical Machines did something wonderful: the ownership and direction of the Tessel Project is now independent of Technical Machine. This makes Tessel a completely open source and community driven platform for I0T, robots, and whatever else would benefit from an open source community disconnected from hardware.
The Tessel project is completely disconnected from manufacturers, something the Arduino project has been struggling with for the last few years, unbeknownst to most of the founders for most of that time. It’s a boon for the open source community, and something that should see an incredible uptake in the next few months.
As smartphones continue to get bigger and bigger, the race to have the smallest chip running Unix (or Linux, as the case may be) is still on. A new contender in this arena is [Serge] who has crammed RetroBSD on a Fubarino microcontroller for a powerful breadboard-friendly device.
The device uses a PIC32MX795 processor to run version 2.11BSD Unix for microcontrollers. It uses only 128 kbytes of RAM which is great for the limited space available, but it doesn’t skimp on software. It has a C compiler, assembler, and a whole host of other utilities that you’d expect to find in something much more powerful. All of this comes in a package that has breadboard-compatible pins so you can interface your Unix with the real world.
There’s a video below that shows the device in action, and a whole host of instructions that’ll get you up and running in no time if you have the hardware available. [Serge] mentioned that this would run on other architectures but is looking for others to join the project to port it to those processors. This isn’t the first time we’ve seen *nix installed on a microcontroller, but it is one of the more useful ones!
Continue reading “Unix On Your Breadboard”