Learning Verilog For FPGAs: The Tools And Building An Adder

Over the last year we’ve had several posts about the Lattice Semiconductor iCEstick which is shown below. The board looks like an overgrown USB stick with no case, but it is really an FPGA development board. The specs are modest and there is a limited amount of I/O, but the price (about $22, depending on where you shop) is right. I’ve wanted to do a Verilog walk through video series for awhile, and decided this would be the right target platform. You can experiment with a real FPGA without breaking the bank.

In reality, you can learn a lot about FPGAs without ever using real hardware. As you’ll see, a lot of FPGA development occurs with simulated FPGAs that run on your PC. But if you are like me, blinking a virtual LED just isn’t as exciting as making a real one glow. However, for the first two examples I cover you don’t need any hardware beyond your computer. If you want to get ready, you can order an iCEstick and maybe it’ll arrive before Part III of this series if published.

Continue reading “Learning Verilog For FPGAs: The Tools And Building An Adder”

The EM Drive Might Not Work, But We Get Helicarriers If It Does

There is a device under test out there that promises to take humans to another star in a single lifetime. It means vacations on the moon, retiring at Saturn, and hovercars. If it turns out to be real, it’s the greatest invention of the 21st century. If not, it will be relegated to the history of terrible science right underneath the cold fusion fiasco. It is the EM drive, the electromagnetic drive, a reactionless thruster that operates only on RF energy. It supposedly violates the laws of conservation of momentum, but multiple independent lab tests have shown that it produces thrust. What’s the real story? That’s a little more complicated.

The EM Drive is a device that turns RF energy — radio waves — directly into thrust. This has obvious applications for spacecraft, enabling vacations on Mars, manned explorations of Saturn, and serious consideration of human colonization of other solar systems. The EM drive, if proven successful, would be one of the greatest inventions of all time. Despite the amazing amount of innovation the EM drive would enable, it’s actually a fairly simple device, and something that can be built out of a few copper sheets.

Continue reading “The EM Drive Might Not Work, But We Get Helicarriers If It Does”

Embed With Elliot: The Volatile Keyword

Last time on Embed with Elliot we covered the static keyword, which you can use while declaring a variable or function to increase the duration of the variable without enlarging the scope as you would with a global variable. This piqued the curiosity of a couple of our readers, and we thought we’d run over another (sometimes misunderstood) variable declaration option, namely the volatile keyword.

On its face, volatile is very simple. You use it to tell the compiler that the declared variable can change without notice, and this changes the way that the compiler optimizes with respect to this variable. In big-computer programming, you almost never end up using volatile in C. But in the embedded world, we end up using volatile in one trivial and two very important circumstances, so it’s worth taking a look.

Continue reading “Embed With Elliot: The Volatile Keyword”

You Can Have My TIPs When You Pry Them From My Cold, Dead Hands

We’ve seen a growing number of posts and recommendations around the net regarding components, specifically transistors. “Don’t use old parts” they cry,  “Go with newer components.”  You can often find these recommendations on Arduino forums. This all came to a head with a page called “Do Not TIP,” which was linked in the Arduino subreddit.  This page belongs to [Tom Jennings], creator of Fidonet, and one of the early authors of what would become Phoenix BIOS. [Tom] and a few others have been calling for everyone to send their old parts to the landfill – not use them, nor gift them to new experimenters. Get them out of the food chain. No offense to [Tom], but we have to disagree. These parts are still perfectly usable for experienced designers, and have a lot to offer new hardware hackers.

TIP is the part number prefix for a series of power transistors created by Texas Instruments.  In fact, “TIP” stands for Texas Instruments Power. The series was originally released in 1969. Yes, that’s right, 1969. Why are we still using parts designed when man first walked on the moon? The same reason people are still using the 555 timer: they’re simple, they’re easily available, they’re robust, and most of all, they get the job done. The TIP series has been used in thousands of classes, tutorials both online and off, and millions of projects over the years. Much of that documentation is already out there on the internet. The TIP series is also out in the distribution channel – they’ve been used for 40 years. Any retail shop that stocks a few electronics parts will have at least one of the TIP series.

The TIP series aren’t always the best transistors for the job. However, for most hobbyist-designed circuits, we don’t need the best performance, nor the best price – we’re going to use the parts we have on hand. There is always room to improve once you get the basic circuit working.

Continue reading “You Can Have My TIPs When You Pry Them From My Cold, Dead Hands”

Mechanical Watch Hacker Gets An Apple Watch

Mechanical watch enthusiasts see the Apple watch as a threat to the traditional gear train. It does not tick, requires frequent re-charging, and it’s certainly not the most attractive of watches. But it can direct you to the local coffee shop, allow you to communicate with friends anywhere in the world, get you onto an airplane after the most awkward of arm gestures, and keep you apprised of the latest NCAA basketball scores. Is the advent of the smart watch the end to the mechanical watch?
Continue reading “Mechanical Watch Hacker Gets An Apple Watch”

Becoming A State Machine Design Mastermind

Imagine a robot with an all-around bump sensor. The response to the bump sensor activating depends on the previous state of the robot. If it had been going forward, a bump will send it backwards and vice versa. This robot exhibits behavior that is easy to model as a state machine. That is, the outputs of the machine (motor drive) depend not only on the inputs (the bump sensor) but also on the current state of the machine (going forward or backward).

As state machines go, that’s not an especially complicated one. Many state machines have lots of states with complex conditions. For example, consider a phone switchboard. The reaction to a phone going off hook depends on the state of the line. If the state is ringing, picking up the phone makes a connection. If the state is idle, the phone gets a dial tone. The switchboard also has to have states for timeouts, connection failures, three way calling, and more.

If you master state machines your design and debug cycles will both move along faster. Part of this is understanding and part is knowing about the tools you can choose to use. I’ll cover both below.

Continue reading “Becoming A State Machine Design Mastermind”

I2C Bus Splitting With A More Professional Touch

Last week, I covered some of the bitter details of an interesting hack that lets us split up the I²C clock line into multiple outputs with a demultiplexer, effectively giving us “Chip Selects” for devices with the same address.

This week, I figured it’d be best to layout a slightly more practical method for solving the same problem of talking to I²C devices that each have the same address.

I actually had a great collection of comments mention the same family of chips I’m using to tackle this issue, and I’m glad that we’re jumping off the same lead as we explore the design space.

Recalling the Work of Our Predecessors

Before figuring out a clever way of hacking together our own solution, it’s best to see if someone before us has already gone through all of the trouble to solve that problem. In this case–we’re in luck–so much that the exact bus-splitting behavior we want is embedded into a discrete IC, known as the PCA9547.

chip_reverence

It’s worth remembering that our predecessors have labored tirelessly to create such a commodity piece of silicon.

The PCA9547 (PDF) is an octal, I²C bus multiplexer, and I daresay, it’s probably the most practical solution for this scenario. Not only does the chip provide 8 separate buses, up to seven more additional PCA9547s can be connected to enable communication with up to 64 identical devices! What’s more, the PCA9547 comes with the additional benefit of being compatible with both 3.3V and 5V logic-level devices on separate buses. Finally, as opposed to last week’s “hack,” each bus is bidirectional, which means the PCA9547 is fully compliant with the I²C spec.

Selecting one of the eight I²C buses is done via a transfer on the I²C bus itself. It’s worth mentioning that this method does introduce a small amount of latency compared to the previous clock-splitter solution from last week. Nevertheless, if you’re planning to read multiple devices sequentially from a single bus anyway, then getting as close-as-possible to a simultaneous read/write from each device isn’t likely a constraint on your system.

 

With a breakout board to expose the pads, I mocked up a quick-n-dirty Arduino Library to get the conversation started and duplicated last week’s demo.

Happily enough, with a single function to change the bus address, the PCA9547 is pretty much a drop-in solution that “just works.” It’s definitely reassuring that we can stand on the shoulders of our chip designers to get the job done quickly. (They’ve also likely done quite a bit more testing to ensure their device performs as promised.) Just like last week, feel free to check out the demo source code up on Github.

Until next time–cheers!