Last time, I showed you a simple PWM block and an open source UART core. This time, I’ll put these parts together to create a PC PWM output peripheral.
I like to think that there are four different ways people use FPGAs:
- Use the FPGA as a CPU which allows you to add predefined I/O blocks
- Build custom peripherals for an external CPU from predefined I/O blocks
- Build custom logic circuitry from scratch
- Projects that don’t need an FPGA, but help you learn
I’d bet the majority of FPGA use falls into categories one and two. Some FPGAs even have CPUs already built-in. Even without an onboard CPU, you can usually put a CPU “core” (think reusable library) into the chip. Either way, you can always add other cores to create UARTs, USB, Ethernet, PWM, or whatever other I/O you happen to need. You either connect them to a CPU on the chip, or an external one. With today’s tools, you often pick what you want from a list and then your entire project becomes a software development effort.
[esot.eric] was trying to drive a motor and naturally thought of using pulse width modulation (PWM) to control the motor speed. However, he found that even with a large capacitor, his underpowered power supply would droop before the PWM cycles were complete. So instead of PWM he decided to experiment with pulse density modulation.
The idea is to use smaller pulses over a longer period of time and make the average power equal to the percentage motor speed desired. With a PWM system, for example, if the time period is T, a 50% PWM drive would have the drive high for T/2 and low for the other half of the cycle. With pulse density, each pulse might be T/10 (as an example) and then the output would be on for 1/10, off for 1/10, on for 1/10 and so on, until by time T you’d still get to 50%. The advantage is the output capacitor gets a kick more often and has less opportunity to droop.
Many CPU-usage widgets have stylistically borrowed from vehicles, displaying something mimicking the tachometer found in the dashboard. [Pat] took it a step further and tried his hand at re-borrowing this style. He figured, why not use an actual physical tachometer to display how hard the CPU on his Raspberry Pi was revving?
With the goal of tuning 0-100% CPU usage to 0-8000 RPM on the tach, the first step was diagnosing the range of PWM input frequencies that moved the needle across the tach’s full arc. Using his Tektronix 3252C function generator he quickly determined 0-440 Hz would be needed and graphed a handful of intermediate points. The response curve was not linear, so he drew up some fudging guidelines to make all the datapoints match.
Next, he wrote a few lines of Python (he shared) to make the Pi to poll its CPU usage and translate it to the proper frequency. The Pi makes outputting easy, GPIO pin 11 carried the signal to a 7404 for buffering, then out to the tach. The automotive tach itself ran on 12V, but its input signal required only 5V so he pulled a 7805 from his parts bin.
See the video after the break of the tach twitching even when the mouse moved, and pegging the red when opening a browser. No more need to use up valuable screen real-estate (or use a screen at all) if you want to see at a glance when your Pi is putting in work.
Sometimes when a project is coming together, you need to cobble a tool together to get it completed. Whether it’s something very involved, like building a 3D printer to fabricate custom parts, or something relatively simple, like wiring a lightbulb and a battery together to create a simple continuity checker, we’ve all had to come up with something on the fly. Despite having access to an oscilloscope, [Brian] aka [schoolie] has come up with his own method for measuring PWM period and duty cycle without a scope, just in case there’s ever a PWM emergency!
The system he has come up with is so simple it’s borderline genius. The PWM signal in question is fed through a piezo speaker in parallel with a resistor. The output from the speaker is then sent to an FFT (fast fourier transform) app for Android devices, which produces a picture of a waveform. [schoolie] then opens the picture in MS Paint and uses the coordinates of the cursor and a little arithmetic to compute the period and the duty cycle.
For not using a scope, this method is pretty accurate, and only uses two discrete circuit components (the resistor and the speaker). If you’re ever in a pinch with PWM, this is sure to help, and be a whole lot cheaper than finding an oscilloscope!
While most embedded development is still done in C and/or assembly, some people are working with more modern languages. The team over at Gobot has successfully managed to get Go running on the Intel Edison.
The Go programming language, which has been around for about five years, compiles to machine code like C. It has a number of modern features including concurrency, garbage collection, and packages.
Getting Go to work on the Edison hardware wasn’t particularly difficult, since it supports the Pentium instruction set and MMX. However, a library was needed to interface with the Edison’s peripherals. The Gobot team whipped up gobot-intel-iot, which makes it easy to work with GPIO, I2C, and PWM.
After the break, the team demos PWM on the Edison using Go.
Continue reading “Running Golang on the Intel Edison”
For his entry to The Hackady Prize, [Sean] is building a haptic vest for gamers and the visually impaired. It’s exactly what you think it is: a vest with proximity sensors and motors that wrap around the wearer, providing haptic feedback of nearby obstacles. Actually building a vest with a few dozen motors is a bit of a challenge, and that’s why this project is in the running for The Hackaday Prize.
Each of the 48 motors are individually controllable with PWM. In any other project, this would require a few dozen microcontrollers or one with a whole lot of pins. [Sean], however, is using LED drivers. They do exactly what [Sean] needs them to do – an easy to interface way of a whole bunch of PWM lines – and they do it cheaper than any other solution.
For detecting objects surrounding the vest, [Sean] is using the depth sensor on a 1st gen Microsoft Kinect. In testing, [Sean] blindfolded a volunteer and had a few friends move around with cardboard ‘obstacles.’ The volunteer successfully avoided all the obstacles, as seen in the video below.
The project featured in this post is a quarterfinalist in The Hackaday Prize.