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.
The world of hobby electronics have only started putting USB in projects for the last few years, and right now, pushing 1.5 Mbps down a USB port is good enough for most cases. This isn’t true for all cases; that’s a terrible data rate, really, and to get the most out of a USB connection, you can at least move up to USB Full Speed and 12 Mbps.
[Linas] is using the STM32F4 microcontroller for this example, an extremely large and very capable chip. [Linas] is using FTDI’s FT2232D USB UART to send data from an SPI port over USB. This chip does support 12 Mbps, but only after a few additions; an external EEPROM must be connected to the FTDI chip to provide a USB 2.0 device descriptor, otherwise the connection between the microcontroller and a computer is limited to 1.5 Mbps. Even using the USB on the STM32 would be a bottleneck in this case; [Linas] is moving data out of the processor using only the DMA controller – using the USB on the STM32 would eat up processor cycles in the microcontroller.
Thanks to the DMA controller inside the STM32, the microcontroller is capable of sending and receiving data through SPI at the same time. The STM32 is capable of reading and writing to the Tx and Rx buffer at the same time, but the computer is only capable of half-duplex operation – it can only read or write at any one time. [Linas] is setting up the DMA controller on the STM32 as a circular mode, putting everything in the buffer into the FTDI chip, and reading everything sent from the computer back into the STM32’s memory. After counting off the correct number of packets. the controller resets everything, moves the circular buffer back to the beginning, and starts the whole process over again.
The circuit was prototyped with an STM Discovery board. With Labview, [Linas] can see the bits coming out of the microcontroller, and send some bits back to the micro over USB. [Linas] has an extraordinarily detailed video tutorial on this project. You can check that out below.
Continue reading “12 Mbps Communication Between A PC and MCU”