A month ago General Motors announced plans to wind down production of several under-performers. At the forefront of news coverage on this are the consequences facing factories making those cars, and the people who work there. The human factor associated with the closing of these plants is real. But there is also another milestone marked by the cancellation of the Volt. Here at Hackaday, we choose to memorialize the soon-to-be-departed Chevrolet Volt. An obituary buried in corporate euphemisms is a whimper of an end for what was once their technological flagship car of the future.
Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.
The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.
But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.
Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.
We don’t think we’d want to trust our fire safety to a robot carrying a few ounces of water, but as a demonstration or science project, [Tinker Guru’s] firefighting robot was an entertaining answer to the question: “What do I do with that flame sensor that came in the big box of Arduino sensors I bought from China?” You can see a video of the device below.
You can see, it is a pretty standard two-wheel robot with the drive wheels to the rear and a skid plate up front. There are a flame sensor and a water pump up forward, as well. You can probably guess, the device notices a flame and rushes to squirt water on it.