It’s that special time of year—time for the parade of student projects from [Bruce Land]’s embedded microcontroller design course at Cornell. [Timothy], [Dhruv], and [Shaurya] are all into remote sensing and control applications, so they built a smart station that combines audiovisual entertainment with environmental sensing.
As with the other projects in this course, the smart station is built on a PIC32 dev board. It does Bluetooth audio playback via RN-52 module and has a beat-matching light show in the form of a NeoPixel ring mounted atop the 3D-printed enclosure. But those blinkenlights aren’t just there to party. They also provide visual feedback about the environment, which comes from user-adjustable high and low trigger values for the mic, an accelerometer, a temperature and humidity sensor, and a luminosity sensor.
The group wanted to add an ultrasonic wake-up feature, but it refused to work with the 3.3V from the PIC. The NeoPixel ring wanted 5V too, but isn’t as picky. It looks to be plenty bright at 3.3V. Another challenge came from combining I²C, UART, analog inputs, and digital outputs. They had to go to the chip’s errata to verify it, but it’s there: whenever I²C1 is enabled, the first two analog pins are compromised, and there’s no official solution. The team got around it by using a single analog pin and a multiplexer. You can check out those blinkenlights after the break.
Maybe you prefer working in wood. If so, you might like this hexagonal take on audio-visualization.
I was enthusiastically reading the article, until I read “PIC32″…
Why would an instructor burden his students with THAT????
“If you can dodge a wrench, you can dodge a ball!”
B^)
I almost wonder if the professor picked an oddball platform so that the students couldn’t leverage the substantial community surrounding AVR or ARM, or HALs like mbed or arduino.
I can see the appeal of keeping them from just stringing together existing solutions, but making these people ignore so much prior art, when each of them probably has five other classes demanding their time, seems almost punitive.
For example, the paper says that they had to reverse-engineer the WS2812B protocol with just the datasheet and a logic analyzer. Even an experienced engineer could easily spend a week of evenings on that one subsystem.
Oh wow. I’m looking at their WS2812 driver code, and they’re timing their bitbanging by repeatedly NOPping. Apparently the exact number of NOPs required to get the timing right was determined experimentally. If the goal of the platform restriction was to get the students to write their own product-ready code, it’s failed.
That’s how adafruit does it. And it offers solid timing. Any other suggestions ?
I’m surprised that works, since I’ve used the Adafruit libs on many different platforms with various clock speeds. I’ll have to look into what they’re doing in there.
The FastLED clockless controller loops it’s NOPs, based on how long a tick should take for the current clock speed.
The project code, however, looks like this:
asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);
asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);
asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);
asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);asm(“nop”);
asm(“nop”);asm(“nop”);
Timer? ISR? DMA?
NOPs are NEVER a solution!
Well duh. It runs at one clockspeed and was made in a couple weeks. Why put more effort to make a modular linear. ISR and Timers are far too much overhead. Give it a try and see if it works out. DMA requires more effort than you give in a couple of weeks on a PIC. I doubt either of you took a moment to think about what you wrote before you posted. Instead of pretending you’re better because you know buzzwords. Try and adding constructive comments
I wrote (from scratch, with only datasheet and a scope) a driver for the WS2812s two nights ago. It took 30 minutes, including testing. I’ve used them before, and looked at other library code, so maybe it’s cheating, but this is the sort of thing an advanced undergrad should be able to hammer out in an afternoon.
The timings, and their slop, are listed in the datasheet — you just have to make them. Long-short vs short-long, with gaps less than 50 microseconds or whatever. Honestly, understanding the bad translation job on the datasheet is half the battle. Otherwise, it’s just following directions and checking the timings on a scope to verify.
NOPs vs DMA, code reuse: Most libraries use NOPs with architecture-dependent ifdefs. That’s some ugly code to begin with. Porting it to a different architecture or language is essentially the same as re-writing from scratch anyway. But one should certainly look at other approaches before writing their own. Code reuse is overrated for small things like this, and even for slightly larger problems it’s the idea reuse that’s the real time saver. The typing isn’t the coding.