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.
When a Lexmark inkjet printer stopped working, [Mojobobo] was able to claim it as his own. He quickly realized that the machine was flooded with ink and not worth repairing, but that didn’t mean he couldn’t still find a use for it. When he learned that the printer’s firmware was not only upgradable but also unprotected, he knew he should be able to get the printer to do his own bidding.
[Mojobobo] started his journey with the motherboard. The unit still powered up, but it was asking to insert a “duplex module” before it would boot any further. [Mojobobo] first tried to find a way to trick the duplex module sensor, but was unsuccessful. His next step was to search for some kind of serial communications port. He didn’t have an oscilloscope, so instead he used a speaker with a wire probe. In theory, if the wire was pressed against an active serial port, he would be able to hear varying tones through the speaker. Sure enough, he found some interesting tones after probing around some ports next to a “JTAG” label. He looked up some information about the nearby chip and found that it included an SPI bus.
After some internet research, [Mojobobo] learned enough about SPI to have a rough idea of how to use it. Having limited tools available to him, he decided to use his Arduino to try to communicate with the motherboard. After wiring up a simple circuit, (and then re-wiring it) he was able to dump the first 4096 bytes of the motherboard’s boot loader to the Arduino via the SPI interface.
[Mojobobo’s] next steps will be to find a faster way to dump the boot loader. At 9600 baud, he grew tired of waiting after three hours. Once he has the full boot loader he intends to search for a way to bypass the duplex sensor and get the board to finish booting. Then he may just use the printer for its scanning functions, or he might find other interesting uses for it.
The WS28xx offerings place a microcontroller inside an RGB LED, allowing them to be individually addressed in very long chains or large matrices (still a chain but different layout). But the timing scheme used to address them doesn’t play well with traditionally available microcontroller peripherals. [Brett] had been intrigued by some of the attempts to bend hardware SPI to the will of the WS2811 — notably [Cunning_Fellow’s] work featured in this post. He took it a great step forward by simplifying the driver to just one transistor, three resistors, and a capacitor.
Click through the link above for his step-by-step description of how the circuit works (it’s not worth re-explaining here as he does a very concise job himself). The oscilloscope above shows the SPI signal on top and the resulting timing signal below. You will notice the edges aren’t very clean, which requires the first pixel to be very close to the driver or risk further degradation. But, since the WS28xx drivers feature a repeater which cleans up signals like this, it’s smooth sailing after the first pixel.
Although it’s still a prototype, [Russell] tipped us off to his battery-powered device for storing your contacts list: ContactKey. (Warning: Loud sound @ beginning). Sure, paper can back up your contact information, but paper isn’t nearly as cool to show off, nor can it receive updates directly from your Android. The ContactKey displays a contact’s information on an OLED screen, which you can pluck through by pressing a few buttons: either ‘Up,’ ‘Down,’ or ‘Reset’. Although the up/down button can advance one contact at a time, holding one down will fly through the list at lightning speed. A few seconds of inactivity causes a timeout and puts the ContactKey to sleep to conserve battery life.
This build uses an ATMega328 microcontroller and an external EEPROM to store the actual list. [Russell] wrote an Android app that will sync your contact list to the ContactKey over USB via an FTDI chip. The microcontroller uses I2C to talk to the EEPROM, while an OLED display interfaces to the ATMega through SPI. We’re looking forward to seeing how compact [Russell] can make the ContactKey once it’s off the breadboard; the battery life for most smartphones isn’t particularly stellar. Phones of the future will eventually live longer, but we bet it won’t be this one.
A few days ago, one of [Severin]’s SD cards died on him, Instead of trashing the card, he decided to investigate what was actually wrong with the card and ended up recovering most of the data using an Arduino and an immense amount of cleverness.
SD cards can be accessed with two modes. The first is the SDIO mode, which is what cameras, laptops, and other card readers use. The second mode is SPI mode. SPI is slower, but much, much simpler. It turned out the SDIO mode on [Severin]’s card was broken, but accessing it with an Arduino and SPI mode worked. There was finally hope to get files off this damaged card.
[Severin] used a few sketches to dump the data on the SD card to his computer. The first looked at the file system and grabbed a list of files contained on the card. The second iterated over the file system and output all the files in hex over the serial port. With a bit of Python, [Severin] was able to reconstruct a few files that were previously lost forever.
Even though the SD card was completely inaccessible with a normal card reader, [Severin] was able to get a few files off the card. All the sketches and Python scripts are available on the Githubs, ready to recover files from your broken SD cards.
Cheap routers such a s the TP-LINK 703n and the TP-LINK MR3020 (seen above) can be used for much more than just connecting your laptop to your cable modem. They’re actually very small Linux boxes and with OpenWRT, you can control every aspect of these tiny pocket-sized computers. It’s frequently been suggested that these routers are awesome substitutes for the usual methods of getting Internet on a microcontroller, but how do you actually do that? The onboard serial port is a great start, but this also dumps output from the Linux console. What you need here is an SPI connection, and [ramcoderdude] has just the solution for you.
Linux already has a few SPI modules, but these are only accessible with kernel drivers. Traditionally, the only way to access SPI is to recompile the kernel, but [coderdude] created a kernel module that allows any device running the Attitude Adjustment OpenWRT image to dynamically allocate SPI busses.
He’s already submitted this patch to the OpenWRT devs, and hopefully it will be included in future updates. Very cool, we think, and something that can open a whole lot of doors for hacking up routers very easily.