Dual Brushed Motor Controller Doesn’t Care How It Receives Commands

July 18, 2018 by Ben James 3 Comments

The simple DC brushed motor is at the heart of many a robotics project. For making little toy bots that zip around the house, you can’t beat the price and simplicity of a pair of brushed motors. They’re also easy to control; you could roll your own H-bridge out of discrete transistors, or pick up one of the commonly used ICs like the L298N or L9110S.

But what if you want an all-in-one solution? Something that will deliver enough current for most applications, drive dual motors, and deal with a wide range of input voltages. Most importantly, something that will talk to any kind of input source. For his Hackaday prize entry, [Praveen Kumar] is creating a dual brushed motor controller which can handle a multitude of input types. Whether you’re using an IR remote, a Pi communicating over I2C, an analog output or Bluetooth receiver, this driver can handle them all and will automatically select the correct input source.

The board has an ATmega328p brain, so Arduino compatibility is there for easy reprogramming if needed. The mounting holes and header locations are also positioned to allow easy stacking with a Pi, and there’s a status LED too. It’s a great module that could easily find a place in a lot of builds.

If you need even more control over your brushed motor, you can soup up its capabilities by adding a PID loop for extra smarts.

A Crash Course In Reliable Communication

June 14, 2018 by Tom Nardi 21 Comments

It’s probably fair to say that anyone reading these words understands conceptually how physically connected devices communicate with each other. In the most basic configuration, one wire establishes a common ground as a shared reference point and then the “signal” is sent over a second wire. But what actually is a signal, how do the devices stay synchronized, and what happens when a dodgy link causes some data to go missing?

All of these questions, and more, are addressed by [Ben Eater] in his fascinating series on data transmission. He takes a very low-level approach to explaining the basics of communication, starting with the concept of non-return-to-zero encoding and working his way to a shared clock signal to make sure all of the devices in the network are in step. Most of us are familiar with the data and clock wires used in serial communications protocols like I2C, but rarely do you get to see such a clear and detailed explanation of how it all works.

He demonstrates the challenge of getting two independent devices to communicate, trying in vain to adjust the delays on the receiving and transmitting Arduinos to try to establish a reliable link at a leisurely five bits per second. But even at this digital snail’s pace, errors pop up within a few seconds. [Ben] goes on to show that the oscillators used in consumer electronics simply aren’t consistent enough between devices to stay synchronized for more than a few hundred bits. Until atomic clocks come standard on the Arduino, it’s just not an option.

[Ben] then explains the concept of a dedicated clock signal, and how it can be used to make sure the devices are in sync even if their local clocks drift around. As he shows, as long as the data signal and the clock signal are hitting at the same time, the actual timing doesn’t matter much. Even within the confines of this basic demo, some drift in the clock signal is observed, but it has no detrimental effect on communication.

In the next part of the series, [Ben] will tackle error correction techniques. Until then, you might want to check out the fantastic piece [Elliot Williams] put together on I2C.

[Thanks to George Graves for the tip.]

Continue reading “A Crash Course In Reliable Communication” →

General Purpose I/O: How To Get More

June 14, 2018 by Inderpreet Singh 28 Comments

The first program anyone writes for a microcontroller is the blinking LED which involves toggling a general-purpose input/output (GPIO) on and off. Consequently, the same GPIO can be used to read digital bits as well. A traditional microcontroller like the 8051 is available in DIP packages ranging from 20 pins to 40 pins. Some trade the number of GPIOs for compactness while other devices offer a larger number of GPIOs at the cost of complexity in fitting the part into your design. In this article, we take a quick look at applications that require a larger number of GPIOs and traditional solutions for the problem.

A GPIO is a generic pin on an integrated circuit or computer board whose behavior, including whether it is an input or output pin, is controllable by the user at runtime. See the internal diagram of the GPIO circuit for the ATmega328 for reference.

Simply put, each GPIO has a latch connected to a drive circuit with transistors for the output part and another latch for the input part. In the case of the ATmega328, there is a direction register as well, whereas, in the case of the 8051, the output register serves as the direction register where writing a 1 to it sets it in output mode.

The important thing to note here is that since all the circuits are on the same piece of silicon, the operations are relatively fast. Having all the latches and registers on the same bus means it takes just one instruction to write or read a byte from any GPIO register.
Continue reading “General Purpose I/O: How To Get More” →

Automatic I2C Address Allocation For Daisy-Chained Sensors

May 23, 2018 by Jenny List 23 Comments

Many readers will be familiar with interfacing I2C peripherals. A serial line joins a string of individual I2C devices, and each of the devices has its own address on that line. In most cases when connecting a single device or multiple different ones there is no problem in ensuring that they have different addresses.

What happens though when multiple identical devices share an I2C bus? This was the problem facing [Sam Evans] at Mindtribe, and his solution is both elegant and simple. The temperature sensors he was using across multiple identical boards have three pins upon which can be set a binary address, and his challenge was to differentiate between them without the manufacturing overhead of a set of DIP switches, jumpers, or individual pull-up resistors. Through a clever combination of sense lines between the boards he was able to create a system in which the address would be set depending upon whether the board had a neighbour on one side, the other, or both. A particularly clever hack allows two side-by-side boards that have two neighbours to alternate their least significant bit, allowing four identical boards each with two sensors to be daisy-chained for a total of eight sensors with automatic address allocation.

We aren’t told what the product was in this case, however it’s irrelevant. This is a hardware hack in its purest sense, one of those which readers will take note of and remember when it is their turn to deal with a well-populated I2C bus. Of course, if this method doesn’t appeal, you can always try an LTC4316.

Push It To The Limit: SSD1306 At 150 FPS

May 8, 2018 by Tom Nardi 38 Comments

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Larry Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Larry] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Larry] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.

Motion-Controlled KVM Switch

April 16, 2018 by James Hobson 7 Comments

Once upon a time, [hardwarecoder] acquired a Gen8 HP microserver that he began to toy around with. It started with ‘trying out’ some visualization before spiraling off the rails and fully setting up FreeBSD with ZFS as a QEMU-KVM virtual machine. While wondering what to do next, he happened to be lamenting how he couldn’t also fit his laptop on his desk, so he built himself a slick, motion-sensing KVM switch to solve his space problem.

At its heart, this device injects DCC code via the I2C pins on his monitors’ VGA cables to swap inputs while a relay ‘replugs’ the keyboard and mouse from the server to the laptop — and vice-versa — at the same time. On the completely custom PCB are a pair of infrared diodes and a receiver that detects Jedi-like hand waves which activate the swap. It’s a little more complex than some methods, but arguably much cooler.

Using an adapter, the pcb plugs into his keyboard, and the monitor data connections and keyboard/mouse output to the laptop and server stream out from there. There is a slight potential issue with cables torquing on the PCB, but with it being so conveniently close, [hardwarecoder] doesn’t need to handle it much.

Continue reading “Motion-Controlled KVM Switch” →

Rotary Encoders Become I2C Devices

April 15, 2018 by Brian Benchoff 42 Comments

Rotary encoders are the bee’s knees. Not only do you get absolute positioning, you can also use a rotary encoder (with a fancy tact button underneath) for an easy UI for any electronics project. There’s a problem with rotary encoders, though: it’s going to use Gray code or something weird, and getting a rotary encoder to work with your code isn’t as easy as a simple button.

For his Hackaday Prize project, [fattore.saimon] has come up with the solution for using multiple rotary encoders in any project. It’s a board that turns a rotary encoder into an I2C device. Now, instead of counting rising and falling edges, adding a rotary encoder to a project is as easy as connecting four wires.

The project is built around the PIC16F18344, a small but surprisingly capable microcontroller that reads a rotary encoder and spits data out as an I2C slave device. Also on board are a few pins for an RGB LED, general purpose pins, the ability to set all seven bits of the I2C address (who wants 127 rotary encoders?), and castellated holes for connecting several boards together.

This project is an update of [fattore]’s earlier I2C Encoder, and there are a lot of improvements in the current version. It’s slightly smaller, has better connectors, and uses a more powerful microcontroller. That’s just what you need if you want a ton of rotary encoders for all those cool interactive projects.