[Lewin] wrote in to tell us about a high speed library for Arduino Due that he helped develop which allows interfacing OLED displays that use the SSD1306 display controller, using DMA routines for faster display refresh time.
Typically, displays such as the Monochrome 1.3″ 128×64 OLED graphic display , are interfaced with an Arduino board via the SPI or I2C bus. The Adafruit_SSD1306 library written by [Limor Fried] makes it simple to use these displays with a variety of Arduinos, using either software or hardware SPI. With standard settings using hardware SPI, calls to display() take about 2ms on the Due.
[Lewin] wanted to make it faster, and the SAM3X8E on the Due seemed like it could deliver. He first did a search to find out if this was already done, but came up blank. He did find [Marek Buriak]’s library for ILI9341-based TFT screens. [Marek] used code from [William Greiman], who developed SD card libraries for the Arduino. [William] had taken advantage of the SAM3X8E’s DMA capabilities to enable faster SD card transfers, and [Marek] then adapted this code to allow faster writes to ILI9341-based screens. All [Lewin] had to do was to find the code that sent a buffer out over SPI using DMA in Marek’s code, and adapt that to the Adafruit library for the SSD1306.
There is a caveat though: using this library will likely cause trouble if you are also using SPI to interface to other hardware, since the regular SPI.h library will no longer work in tandem with [Lewin]’s library. He offers some tips on how to overcome these issues, and would welcome any feedback or testing to help improve the code. The speed improvement is substantial. Up to 4 times quicker using standard SPI clock, or 8 times if you increase SPI clock speed. The code is available on his Github repo.
I2C has a seven-bit address space, and you’re thinking “when do I ever need more than 127 devices on a pair of wires?” So you order up some parts only to find that they have one, two, or three user-configurable address pins for any given device type. And you need a bunch more than four or eight capacitive sensor buttons on your project. What do you do?
If you’re reader [Marv G], you think outside the box and realize that you can change the addresses on the fly by toggling address pins high and low with your microcontroller. That is, you can use a single I2C address pin for each device as a chip select signal just like you would have with SPI.
That’s it, really. [Marv G] goes through all of the other possible options in his writeup, and they’re all unsavory: multiple I2C busses, a multiplexer, buying different sensors, or changing micros. None of these are as straightforward as just running some more wires and toggling these with your micro.
We’d even go so far as to suggest that you could fan these chip select lines out with a shift register or one of those 1-of-N decoder chips, depending on how many I2C devices you need to chip-selectify. (We’re thinking 74HC595 or 74HC154.)
Along the way, we found this nice list of the number of address pins for a bunch of common peripherals provided by [LadyAda], in case you don’t believe us about how ubiquitous this problem is. How many devices on that list have one (1!!) address pin?
At the end of his post, [Marv G] asks if anyone else has thought of this chip select trick before. We hadn’t. Here’s your chance to play the smart-ass in the comments.
Generating video signals with a microcontroller or old CPU is hard if you haven’t noticed. If you’re driving even a simple NTSC or PAL display at one bit per pixel, you’re looking at a minimum of around 64kB of RAM being used as a frame buffer. Most microcontrollers don’t have this much RAM on the chip, and the AVR video builds we’ve seen either have terrible color or relatively low resolution.
Here’s something interesting that solves the memory problem and also generates analog video signals. Yes, such a chip exists, and apparently this has been in the works for a very long time. It’s the VLSI VS23s010C-L, and it has 131,072 bytes of SRAM and a video display controller that supports NTSC and PAL output.
There are two chips in the family, one being an LQFP48 package, the other a tiny SMD 8-pin package. From what I can tell from the datasheets, the 8-pin version is only an SPI-based SRAM chip. The larger LQFP package is where the action is, with parallel and SPI interfaces to the memory, an input for the colorburst crystal, and composite video and sync out.
After looking at the datasheet (PDF), it looks like generating video with this chip is simply a matter of connecting an RCA jack, throwing a few commands to the chip over SPI, and pushing bits into the SRAM. That’s it. You’re not getting hardware acceleration, you’re going to have to draw everything pixel by pixel, but this looks like the easiest way to generate relatively high-resolution video with a single part.
Thanks [antibyte] for the tip on this one.
In the last video I demonstrated a Universal Active Filter that I could adjust with a dual-gang potentiometer, here I replace the potentiometer with a processor controlled solid-state potentiometer. For those that are too young to remember, we used to say “solid-state” to differentiate between that and something that used vacuum tubes… mostly we meant you could drop it without it breakage.
Using SPI to set Cutoff of Low Pass Filter
UAF42 Filter with Dual Ganged Pots
The most common way to control the everyday peripheral chips available is through use of one of the common Serial Protocols such as I2C and SPI. In the before-time back when we had only 8 bits and were lucky if 7 of them worked, we used to have to memory map a peripheral or Input/Output (I/O) controller which means we had to take many control and data lines from the microprocessor such as Data, Address, Read/Write, system clocks and several other signals just to write to a couple of control registers buried in a chip.
Nowadays there is a proliferation of microcontrollers that tend to have built-in serial interface capability it is pretty straightforward to control a full range of peripheral functions; digital and analog alike. Rather than map each peripheral using said data and address lines,which is a very parallel approach, the controller communicates with peripherals serially using but a handful of signal lines such as serial data and clock. A major task of old system design, mapping of I/O and peripherals, is no longer needed.
Continue reading “We Assume Control: SPI and a Digital Potentiometer”
[Kalle] is at it again with more hacks on electricity use meters. This time, the meter has been hacked to stream their data over the aether wirelessly. Now, data can be grabbed from multiple devices simultaneously, making the possibilities for home energy monitoring limitless
The first project [Kalle] did involved finding a meter from China with capabilities similar to (and cheaper than) the Kill-a-Watt meters. Unlike the Kill-a-Watt which spits out analog values, the Chinese meter sent digital information out on a ribbon cable with the bus lines labeled. Since the meter was so hackable, [Kalle] took it even further in this hack.
With those pesky wires out of the way, the device now uses an Arduino Pro Mini to sniff the energy meter’s data stream. Then it transmits the data wirelessly with a nRF34L01+ transceiver. As a perk, all of these chips fit inside the case of the energy meter, making this a very tidy hack indeed. The project code an incredible amount of detail is available on the project site, so be sure to check this one out for all of your energy monitoring needs!
There are smaller microcontrollers than the ATtiny13. Some ARM chips will fit on the head of a large pin, and even in Atmel world, the ATtiny10 comes in a tiny SOT-23-6 package – a size normally reserved for surface mount transistors. The ‘tiny13, though, can be programmed with just about any ISP and comes in an 8-pin DIP. It’s the bare minimum if you’re looking to break out of the world of Arduino, and you can do some pretty cool things with it, like playing some holiday audio with an SPI Flash chip.
[Vinod] tried opening up a cheap camera pen, but in the course of disassembly a few traces broke. He was now left with a 4Mbit SPI Flash chip. This was obviously the time to investigate what could be done with a small microcontroller and a huge amount of Flash. and the Attiny13 audio player was born.
The circuit uses one PWM for audio out, and reads audio directly from the Flash chip. The UART on board the ‘tiny13 is used to update the Flash, and there’s also a switch to select between play and record. If you’re counting, that means there are 4 pins for the Flash, 2 pins for the UART, 1 for the switch, one for the audio output, and the power and ground rails, all in an 8-pin package. That’s a pretty cool way to use one pin for two different functions.
You can check out a video of the project in action below.
Continue reading “Holiday Cheer From The ATtiny13”
[Tim] got his hands on some APA102 RGB LEDs, which are similar in function to the common WS2812 addressable LEDs seen in many projects we’ve featured. The advantage of APA102 LEDs is that they don’t have the strict timing requirements of the WS2812. These LEDs are controlled with a SPI bus that can be clocked at any arbitrary rate, making them easy to use with pretty much any microcontroller or embedded system.
After working with the LEDs, [Tim] discovered that the LEDs function a bit differently than the datasheet led him to believe. [Tim] controlled a strand of APA102 LEDs with an ATtiny85 and connected a logic analyzer between some of the LEDs. He discovered that the clock signal of the SPI interface isn’t just passed through each LED, it actually looks like it’s inverted on the output. After some investigation, [Tim] found that the clock signal is delayed by a half period (which looks like an inversion) before it’s passed to the next LED. This gives the next LED in the strand enough time for data on the data line to become valid before latching it in.
Since the clock is delayed, [Tim] discovered that additional bits must be clocked as an “end frame” to generate clock signals which propagate the remaining data to the end of the strand. Although the datasheet specifies a 32-bit end frame, this only works for strings of up to 64 LEDs. More bits must be added to the end frame for longer strands, which the datasheet doesn’t even mention. Check out [Tim]’s post for more information, where he walks you through his logic analysis of the APA102 LEDs.