“Instead of an Arduino, he could have done that with a 555 timer.” “Instead of a 555 he could have done that with two transistors.” “Instead of a few transistors, he could have done that with butterflies.” These are quotes from various Hackaday comment threads throughout the years. It seems simplicity is the name of the game here, and if you need a timer chip, how about an 8-pin DIP? This, of course, means an I2C programmable oscillator in the form of an LPC810.
[kodera2t] built this circuit after reaching for a 555 timer a few too many times. It’s a one-chip solution with an ARM core that’s able to generate square waves with 1Hz resolution up to 65536Hz.
The source for this chip is a lot of C, but once it’s in the Flash of the LPC810, this chip becomes a programmable oscillator with an I2C interface. Yes, it’s a one-component solution, no, it’s not a twenty cent chip, but try programming a 555 over I2C.
The videos below show [kodera] playing around with this I2C oscillator, sweeping the frequency from zero to inaudible teenage angst.
Continue reading “A Simple Programmable 555″
[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.
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”
When an air quality display project needed a display, [Inderpreet] looked into small character-based LCDs. [Inderpreet’s] chosen LCD used an I2C interface, which was new to him. Rather than shy away, [Inderpreet] grabbed his Bus Pirate and dove in!
I2C or Inter-Integrated Circuit serial interfaces are often mentioned here on Hackaday. They generally are easy to use, but as with all things, there are little gotchas which can make the road a bit more bumpy the first time you travel it. One of those things is voltage interfacing – I2C uses bidirectional open drain lines, so interfacing 3.3 V and 5V circuits requires a voltage level shifter circuit designed to handle that requirement. Thankfully in [Inderpreet’s] case, both his TI launchpad target devboard and the LCD used 3.3 volt logic levels.
Before using the TI though, [Inderpreet] wanted to test with the Bus Pirate first. This would allow him to verify the hardware, and to make sure he was correctly using the I2C bus. The Bus Pirate can operate at 3.3V or 5V logic levels, and has on-board programming specific to the I2C bus. Controlling the Bus Pirate is as easy as hooking up a serial terminal program and plugging in a USB cable.
The I2C bus protocol is relatively simple, but can still be confusing to a new user. Each transaction needs an address, read/write bit, and a start command sent in the proper sequence before the data bytes can begin flowing. There are also acknowledge bits which prove that the data bytes are actually being received by the LCD. The Bus Pirate made all this easy, allowing [Inderpreet] to quickly display “Hello” on his LCD module.
The I2C bus is just the tip of the iceberg for the Bus Pirate. If you’re interested in learning more, check it out over at The Hackaday Store!
[via Dangerous Prototypes]
Put aside all of the projects that use an Arduino to blink a few LEDs or drive one servo motor. [IngGaro]’s latest project uses the full range of features available in this versatile microcontroller and has turned an Arduino Mega into a fully-functional home alarm system.
The alarm can read RFID cards for activation and control of the device. It communicates with the front panel via an I2C bus, and it can control the opening and closing of windows or blinds. There is also an integrated GSM antenna for communicating any emergencies over the cell network. The device also keeps track of temperature and humidity.
The entire system can be controlled via a web interface. The Arduino serves a web page that allows the user full control over the alarm. With all of that, it’s hard to think of any more functionality to get out of this tiny microcontroller, unless you wanted to add a frickin’ laser to REALLY trip up the burglars!
It seems as though [Nathan] has taken some serious inspiration from the Warthog. The iconic armored buggy from Halo video games has a turret mounted to the roof. Although [Nathan]’s buggy only shoots paintballs from its turret.
Mounting paintball markers (guns) to various objects such as vehicles, robots, or other machines isn’t quite as straightforward as it seems. Vibrations from anything can transfer through a clamping system and cause paintballs to break. This, of course, inhibits the functionality of the marker and is a messy cleanup to boot. Then there has to be a way to fire the paintballs, which is usually handled by soldering to the electrical connections in the marker. And the entire rig has to stand up to the normal jostling and sudden turns from the buggy.
[Nathan] has solved these problems first by creating a custom fast-change mount that allows any malfunctioning markers to be changed rapidly. The electronic firing mechanism is handled by an ATtiny microcontroller and there is a custom electrical connection that is automatically made when the marker is bolted to the mount.
The new system allows markers to be changed in about 30 seconds, much better than any other system. Maybe in the future [Nathan] can upgrade the buggy’s turret to accommodate a paintball minigun.