Quick, how do you wire up an SPI bus between a microcontroller and a peripheral? SCK goes to SCK, MISO goes to MISO, and MOSI goes to MOSI, right? Yeah. You’ll need to throw in a chip select pin, but that’s pretty much it. Just wires, and it’ll most likely work. Now add a second device. The naïve solution found in thousands of Arduino tutorials do the same thing; just wires, and it’ll probably work. It’s not that simple, and Mr. Teensy himself, [Paul Stoffregen] is here to show you why.
When using multiple SPI devices, a pullup resistor on the chip select lines are a really great idea. Without a pullup, devices will work great when used alone, but will inexplicably fail when used together. It’s not magic; both devices are listening to the bus when only one should be. Putting a pullup on the CS lines keeps everything at the right logic level until a device is actually needed.
How about the MISO line? Most peripherals will disconnect their pins when the chip select signal is active, but there are exceptions. Good luck finding them. There is an easy way to check, though: just connect two resistors so the MISO line floats to a non-logic level when the CS pin is high, and check with a voltmeter. If MISO is driven high or low, you should put a small tri-state buffer in there.
That just covers hardware, and there are a few things you can do in software to reduce the number of conflicts when using more than one SPI device. One of these methods is transactions, or defining the clock rate, setting MSB or LSB first, and the polarity of the clock. Newer versions of the Arduino SPI library support transactions and the setup is very easy. In fact, transaction support in the Arduino library is something [Paul] worked on himself, and gets around the problem of having SPI-related code happening in both the main loop of a program and whenever an interrupt hits. Awesome work, and a boon to the Arduino makers around the world.
Power meters like the Kill-A-Watt are great for keeping track of energy usage, and are also very hackable. The Kill-a-Watt in particular puts out analog signals proportional to current and voltage, which makes it easy to interface with a microcontroller.
Although reading analog voltages is easy enough, [Kalle] found a cheap Chinese power meter that is even more hackable. These inexpensive power meters cost about the same as a first-generation Kill-a-Watt, but they directly stream out digital data. The power meter [Kalle] hacked has a non-US plug, but the meter is available from the usual suppliers (eBay, Aliexpress, etc) with a 3-prong US plug and 120v rating.
After breaking out a logic analyzer, [Kalle] discovered that the meter constantly streams voltage, current, and power data from the measurement board to the display board on a SPI-like bus. The ribbon cable inside the meter even has the clock and data bus lines clearly labelled. [Kalle] went on to reverse-engineer the protocol and write an Arduino sketch that parses the stream, making it even easier to integrate this meter into your next power monitoring project.
If you want to take a photograph with a professional look, proper lighting is going to be critical. [Richard] has been using a commercial lighting solution in his studio. His Lencarta UltraPro 300 studio strobes provide adequate lighting and also have the ability to have various settings adjusted remotely. A single remote can control different lights setting each to its own parameters. [Richard] likes to automate as much as possible in his studio, so he thought that maybe he would be able to reverse engineer the remote control so he can more easily control his lighting.
[Richard] started by opening up the remote and taking a look at the radio circuitry. He discovered the circuit uses a nRF24L01+ chip. He had previously picked up a couple of these on eBay, so his first thought was to just promiscuously snoop on the communications over the air. Unfortunately the chips can only listen in on up to six addresses at a time, and with a 40-bit address, this approach may have taken a while.
Not one to give up easily, [Richard] chose a new method of attack. First, he knew that the radio chip communicates to a master microcontroller via SPI. Second, he knew that the radio chip had no built-in memory. Therefore, the microcontroller must save the address in its own memory and then send it to the radio chip via the SPI bus. [Richard] figured if he could snoop on the SPI bus, he could find the address of the remote. With that information, he would be able to build another radio circuit to listen in over the air.
Using an Open Logic Sniffer, [Richard] was able to capture some of the SPI communications. Then, using the datasheet as a reference, he was able to isolate the communications that stored information int the radio chip’s address register. This same technique was used to decipher the radio channel. There was a bit more trial and error involved, as [Richard] later discovered that there were a few other important registers. He also discovered that the remote changed the address when actually transmitting data, so he had to update his receiver code to reflect this.
The receiver was built using another nRF24L01+ chip and an Arduino. Once the address and other registers were configured properly, [Richard’s] custom radio was able to pick up the radio commands being sent from the lighting remote. All [Richard] had to do at this point was press each button and record the communications data which resulted. The Arduino code for the receiver is available on the project page.
[Richard] took it an extra step and wrote his own library to talk to the flashes. He has made his library available on github for anyone who is interested.
Typically bit-banging an I/O line is the common method of driving the WS2812B (WS2811) RGB LEDs. However, this ties up precious microcontroller cycles while it waits around to flip a bit. A less processor intensive method is to use one of the built-in Serial Peripheral Interface (SPI) modules. This is done using specially crafted data and baud rate settings, that when shifted out over the Serial Data Out (SDO) pin, recreate the needed WS2812B signal timing. Even when running in SPI mode, your hardware TX buffer size will limit how many pixels you can update without CPU intervention.
[Henrik] gets around this limitation by using peripheral DMA (Direct Memory Access) to the SPI module in the Microchip PIC32MX250F128B microcontroller. Once properly configured, the DMA controller will auto increment through the defined section of DMA RAM, sending the pixel data over to the SPI module. Since the DMA controller takes care of the transfer, the micro is free to do other things. This makes all of DMA memory your display buffer. And leaves plenty of precious microcontroller cycles available to calculate what patterns you want the RGB LEDs to display.
Source code is available at the above link for those who would like to peruse, or try it out. This is part of [Henrik’s] Pixel Art Project. Video of DMA based SPI pixels after the break:
[Paul Stoffregen], known as father of the Teensy, has leveraged the Teensy 3.1’s hardware to obtain some serious speed gains with SPI driven TFT LCDs. Low cost serial TFT LCDs have become commonplace these days. Many of us have used Adafruit’s TFT LCD library to drive these displays on an Arduino. The Adafruit library gives us a simple API to work with these LCDs, and saves us from having to learn the intricacies of various driver chips.
[Paul] has turbocharged the library by using hardware available on Teensy 3.1’s 32 Freescale Kinetis K20 microcontroller. The first bump is raw speed. The Arduino’s ATmega328 can drive the SPI bus at 8MHz, while the Teensy’s Kinetis can ramp things up to 24MHz.
Speed isn’t everything though. [Paul] also used the Freescale’s 4 level FIFO to buffer transfers. By using a “Write first, then block until the FIFO isn’t full” algorithm, [Paul] ensured that new data always gets to the LCD as fast as possible.
Another huge bump was SPI chip select. The Kinetis can drive up to 5 SPI chip select pins from hardware. The ATmega328 doesn’t support chip selects. so they must be implemented with GPIO pins, which takes even more time.
The final result is rather impressive. Click past the break to see the ATmega based Arduno race against the Kinetis K20 powered Teensy 3.1.
To prevent data corruption when using multiple SPI devices on the same bus, care must be taken to ensure that they are only accessed from within the main loop, or from the interrupt routine, never both. Data corruption can happen when one device is chip selected in the main loop, and then during that transfer an interrupt occurs, chip selecting another device. The original device now gets incorrect data.
For the last several weeks, [Paul] has been working on a new Arduino SPI library, to solve these types of conflicts. In the above scenario, the new library will generate a blocking SPI transaction, thus allowing the first main loop SPI transfer to complete, before attempting the second transfer. This is illustrated in the picture above, the blue trace rising edge is when the interrupt occurred, during the green trace chip select. The best part, it only affects SPI, your other interrupts will still happen on time. No servo jitter!
This is just one of the new library features, check out the link above for the rest. [Paul] sums it up best: “protects your SPI access from other interrupt-based libraries, and guarantees correct setting while you use the SPI bus”.
Most of [Necromancer]’s work involves flashing routers and the like, and he found the Bus Pirate was far too slow for his liking – he was spending the better part of four minutes to write a 2 MiB SPI Flash. Figuring he couldn’t do much worse, he wrote two firmwares for the uISP to put some data on a Flash chip, one a serial programmer, the other a much more optimized version.
Although the ATMega in the uISP is running at about half the speed as the PIC in the Bus Pirate, [Necromancer] found the optimized firmware takes nearly half the time to write to an 8 MiB Flash chip than the Bus Pirate.
It’s an impressive accomplishment, considering the Bus Pirate has a dedicated USB to serial chip, the uISP is bitbanging its USB connection, and the BP is running with a much faster clock. [Necro] thinks the problem with the Bus Pirate is the fact the bandwidth is capped to 115200 bps, or a maximum throughput of 14 kiB/s. Getting rid of this handicap and optimizing the delay loop makes the cheaper device faster.