The 6502 is a classic piece of computing history. Versions of this CPU were found in everything from the Apple ][, to the Nintendo Entertainment System, and the Commodore 64. The history of the 6502 doesn’t end with video games; for the last forty years, this CPU has found its way into industrial equipment, medical devices, and everything else that doesn’t need to be redesigned every two years. Combine the longevity of the 6502 with the fact an entire generation of developers first cut their teeth on 6502 assembly, and you have the makings of a classic microprocessor that will, I’m sure, still be relevant in another forty years.
The folks at WDC recently contacted me to see if I would give their hardware a close look, and after providing a few boards, this hardware proved to be both excellent. They’re great for educators adventurous enough to deviate from the Arduino, Processing, and Fritzing zeitgeist, and for anyone who wants to dip their toes into the world of 65xx development.
I’m not getting any younger, in fact I’m getting older by the day. This fact along with the fact that this year is the 30th anniversary of the Commodore C-128 and the original Commodore Amiga prompted me to attend this year’s CommVEx in Las Vegas lest I not be around for the next significant anniversary. For those that don’t know me, I designed the C-128 at the ripe old age of 25 back in 1984-85, though I would ask that you not hold that against me as it was a very long time ago.
Also this year Dr. Leonard Tramiel, son of Commodore’s founder Jack Tramiel, was able to swing by which was an unprecedented and unforgettable event.
There comes a time when you need to wire up three, four, or more identical i2c devices to a common microcontroller. Maybe you’re thinking about driving 128 seven-segment displays with eight of those MAX6955 16-way digit drivers, or maybe you have a robot full of joints–each of which needs a BNO055 inertial sensor for angle estimation. (See above.) Crikey! In both of those cases, you’re best bet might be a schnazzy I²C device that can do most of the work for you. The problem? With a single I²C bus, there’s no standard way defined in the protocol for connecting two or more devices with the same address. Shoot! It would’ve been handy to wire up three BNO055 IMUs or eight MAX6955s and call it a day. Luckily, there’s a workaround.
We’ve seen some clever tricks in the past for solving this problem. [Marv G‘s] method involves toggling between a device’s default and alternate address with an external pin. This method, while clever, assumes that the device (a) has an alternate I²C address and (b) features an external pin for toggling that address.
I’ll introduce two additional methods for getting the conversation started between your micro’ and your suite of identical sensors. The first is “a neat trick,” but somewhat impractical for widespread use. The second is far more production-worthy–something you could gloat over and show off to your boss! Without further ado, let’s get started with Method 1.
Lastly, if you’d like to follow along, feel free to check out the source code on Github.
In both methods, I’m using the same sensor setup to check that each circuit behaves correctly. I happened to have a bunch of extra BMA180s on the bench, so I rolled out an example based on these chips. Back in the day, the BMA180 was a pretty common three-axis digital accelerometer. It has an I²C interface with two optional addresses. For the purpose of this example, I’m fixing them all with the same address. I’ve mounted three of these guys on mutually perpendicular axes of my acrylic “test cube,” and I’m reading each chip’s Z-axis. In this configuration I can easily pick out the gravity vector from the corresponding sensor as the data goes flying by my serial port window. If I can uniquely address each sensor and read the data, I’ve got a working circuit.
Method 1: Splicing Clocks into Chip-Selects
This method tips its hat towards SPI in that it behaves in an oddly similar fashion. If you’re feeling rusty on SPI, here’s a quick recap.
A Quick SPI Refreshment:
SPI, like I²C, is another protocol that shares both its clock and data lines with multiple slave devices. The difference, though, lies in the addressing scheme to talk to these devices that share the same bus. With SPI, while clock and data lines are shared, devices are addressed with separate chip-select (CS) lines.
The master microcontroller dedicates a unique output pin to each device (~SS1, ~SS2, and ~SS3 in this illustration). When the master micro’ wants to talk to a device, it asserts that device’s chip-select input pin by pulling it to logic LOW, and the conversation begins over the data bus. With the chip select LOW, the corresponding slave listens to the data on the bus. Meanwhile, all other devices ignore the conversation between the master and it’s chosen slave by keeping their bus pins in a high impedance state.
Giving I²C Its Own Chip-Selects:
With I²C, Clock (SCL) and Data (SDA) lines are still shared between all I2C slave devices, but the addressing scheme happens by sending a message heard by all devices on the bus. To single out one device on the shared bus, the master first passes down the address of the slave device it wants to talk to, after which that slave replies with an ACKnowledge, and all other slaves ignore the data that follows until both data transmission is complete and the bus is “released.”
Because we have the problem of multiple devices with shared addresses, in theory, all of these devices would reply when the master passes down their shared address, and there’s no way for the master to single out a single device. In reality, this behavior is undefined on the I²C protocol.
Yikes! Anything goes when we wander away from defined behavior, so we try to avoid these things in practice.
The solution?
According to the I²C spec, It just so happens that an I²C slave device will ignore changes on the data line (SDA) provided that the clock line (SCL) is held high. In this method, I’ll “split” the SCL line into multiple SCL lines such that each shared I²C device gets its own SCL. By selectively rerouting the clock to each I²C device one-at-a-time, I’ve essentially turned the SCL line into a “chip select.”
To chop up that clock line, I’ll need a demultiplexer. A demultiplexer (or decoder) takes a logical input and reroutes it to one of several outputs based on the binary select lines.
I’ve dropped in the 74AC11138 eight-way demultiplexer for this task. It’s fast, capable of switching at megahertz rates, and its outputs default to logic HIGH. That second note is handy since idle SCL lines also default to logic HIGH.
The setup is shown in a simplified schematic above. In it, I’m using a Teensy 3.0 posing as the I²C bus master. To the right of the Teensy is the collection of identical chips, BMA180 accelerometers in this case. In the middle is the 74AC11138 eight-way demultiplexer.
Cons of this Method:
There’s a minor drawback with this technique, though, in that it doesn’t support I²C’s clock-stretching feature. Taking a step back, this method assumes that the SCL line is inherently unidirectional, controlled by only the I²C bus master. In other words, we’re making the assumption that data on the SCL line is only sent from master to slave and never the other way around. If your I²C slave devices implement clock-stretching, however, this assumption breaks down.
What is Clock Stretching?
Clock stretching is a method defined by the I²C protocol where the chip needs to “buy itself more time” and holds the SCL line low, hence, signalling to the master that it’s not ready for the upcoming data. In this scenario, the slave actively controls the SCL line, and it happens to be the only case where data moves up the SCL line from slave to master. In a setup with our demultiplexer between the master and our set of identical slaves, these slaves won’t be able to send back the clock-stretching signal to the master to indicate that they aren’t ready for data, if they happen to implement clock stretching. That said, clock stretching is a pretty rare feature among I²C-compatible devices, so this method is likely to work among a number of chips out now.
More Next Week
That’s all for Method 1. Thanks for tuning in, and check back next week for a slightly-more-professional method of tackling this same problem.
When it comes to manufacturing, no place in the world has the same kind of allure as the Pearl River Delta region of China. Within just an hour-long train ride, two vastly different cultures co-exist, each with its unique appeal that keeps attracting engineers, entrepreneurs, and hustlers alike. On the mainland side, cities like Shenzhen and Guangzhou bring the promise of cheap components, low-cost contract work, and the street cred of “having done the Shenzhen thing.” And on the island, the capitalist utopia called Hong Kong glows with all of its high finance and stories of lavish expat lifestyles.
As the “new” China evolves, it seems like it’s exactly the convergence of these two cultures that will bring the biggest change—and not just to the area but to the whole world. Still, understanding what exactly is going on and what the place is really all about remains a mystery to many. So, this June, we jumped on the bandwagon and headed east, trying to get our own feel for the whole thing.
We’re in Boston this week and my first stop was at MITERS last night. This is the MIT Electronics Research Society, which started as a way to provide free access to computers for all students. Since those humble beginnings the organization has grown to include a slew of fabrication and test hardware, as well as a vibrant community that makes the group a great place to hang out.
Doors leading to MITERS
Ah, the comfort of a hackerspace
Batteries on the bench
High-five bot
Funds are generated by Swapfest
Walking into the building you’re greeted with double doors strewn with interesting electronics and many examples of fabrication in the form of the word MITERS. The group, which is pushing 60-years of existence, feels immediately like a hackerspace where creativity and anarchy duke it out in a wild dance of experimentation. On this particular Wednesday evening we encountered a room of about 10 people working feverishly to fabricate electric racers for the PRS racing circuit in Detroit this Saturday.
Like a hackerspace, MITERS is completely member (read: student) run. There is a board that helps keep things on the rails. There is no membership fee; funding for the organization is sourced from Swapfest, a weekly flea market during the summer.
Machinist’s tool kit
Machine shop
CNC machine tools
Argh-argh-argh-argh
There is a strong slant toward machine shop at this hackerspace. In addition to a respectable Bridgeport CNC Mill, the machine tools and hand tools provide for almost all your fabrication needs.
Uni-balancer and it’s creator
Unibalancer
Black strip is the deadman switch
What can be built in this space? How about a unibalancer? This is a single-wheeled, human-ridable vehicle that has a 7-mile cruise radius between charges. For me the most interesting feature is the deadman’s switch. You know those black rubber strips on public buses that you press for the next stop? This unibalancer has one that you need to stand on to make it go.
Impressive PRS Build
Twin Ryobi electric chainsaw motors
Chainsaw using chain drives
Original Chainsaw batteries not used in racer
Wireless statistics on tablet
Another PRS build
Motorized shopping cart hangs from ceiling
Tiny electric racer
The hackers at MITERS excel when it comes to electric vehicles and this time of year that means the Power (Wheels) Racing Series. There are restrictions on size, and power output so the teams squeeze every bit that they can. For me, the most interesting build is based off of a pair of Ryobi electric chainsaws. The 40V batteries for these are themselves quite formidable but not used at all in the build. The team has reverse-engineered the driver circuits and written their own firmware for the STM8 microcontrollers on the boards. The chainsaws use chains to drive the two rear wheels. The entire system is monitored with XBEE-based wireless data which is displayed on a tablet.
This isn’t the only PRS build. The MITERS plan to take three different vehicles with them this weekend. The one they can’t bring is the huge electric shopping cart (with mandatory wheelie bar) which hangs from the ceiling of the space.
Best sounding musical Tesla I’ve seen
Top coil of massive tesla coil
Huge subwoofer
In addition to the formidable fabrication projects, there are a multitude of electronic projects to be seen. There is a musical tesla coil which is the best I’ve ever heard. It could easily be mistaken as a proper speaker. If you need more bass there’s a massive ceiling-mounted sub-woofer for that. And if you want a more formidable tesla coil, the parts are there.
Battle-bot
Underbot
Look hard enough and you’ll even find battle robots. This one had diamond plate that spins with a variety of nasty accoutrements intended for maximum damage of its foe. On the underside you’ll see a brushless motor used the opposite of how you might think. The shaft is attached to the locomotion frame of the bot. The underside of the spinning diamond plate has a ring of antistatic mat against which this brushless motor body spins.
Thanks to the MITERS for welcoming us in. It was a blast seeing all of the projects they’re working on!
Meetup at Artisan’s Asylum Tonight
If you’re in the Boston area, head on over to Artisan’s Asylum tonight starting at 6. They were gracious enough to open their doors for a Hackaday Meetup. Bring some hardware to show off if you can, if you can’t that’s fine as well. We’ll have a few lightning talks, some social time, and maybe an afterbar!
To wrap things up, we have covered a few projects from MITERS already, like this Power Wheels Racing build, and an electric go kart done the right way. Now that we’ve met them in person we’ll be on the lookout for a lot more awesome hacks from them.
Recently we had the opportunity to sit down and interview Arduino SRL’s CEO, [Federico Musto], over a nice dinner. His company is one half of the Arduino vs Arduino debacle which has pitted Arduino.cc against Arduino.org in a battle over the trademark on “Arduino”.
Given the tremendous amount of press coverage of [Massimo Banzi] and the Arduino LLC side of the story (Arduino.cc), we were very interested in hearing how the whole situation looks where [Frederico Musto] sit (Arduino.org). In the end, we came away with what we feel is a more balanced and complete picture of the situation, as well as interesting news about future products from the Arduino SRL camp. [Musto’s] take on the legal proceedings, both past and present, is nothing short of fascinating.
Microchip has unveiled a new dev board called the Curiosity Development Board. I had my first look at this at Bay Area Maker Faire back in May but was asked not to publicize the hardware since it wasn’t officially released yet. Yesterday I got my hands on one of the first “pilot program” demo units and spent some time working with it.
I requested a sample board out of my own curiosity. As you may know, Microchip is one of the sponsors of the 2015 Hackaday Prize, but that partnership does not include this review. However, since we do have this relationship we asked if they would throw in a few extra boards that we could give away and they obliged. More about that at the end of the post.
I’ve dropped in the 74AC11138 eight-way demultiplexer for this task. It’s fast, capable of switching at megahertz rates, and its outputs default to logic HIGH. That second note is handy since idle SCL lines also default to logic HIGH.
