Sometimes there’s just no substitute for the right diagnostic tool. [Ankit] was trying to port some I2C code from an Arduino platform to an ARM chip. When the latter code wasn’t working, he got clever and wrote a small sketch for the Arduino which would echo each byte that came across I2C out to the serial line. The bytes all looked right, yet the OLED still wasn’t working.
Time to bring out the right tool for the job: a logic analyzer or oscilloscope. Once he did that, the problem was obvious (see banner image — Arduino on top, ARM on bottom): he misunderstood what the ARM code was doing and was accidentally sending an I2C stop/start signal between two bytes. With that figured, he was on the right track in no time.
We just ran an epic post on troubleshooting I2C, and we’ll absolutely attest to the utility of having a scope or logic analyzer on hand when debugging communications. If you suspect that the bits aren’t going where they’re supposed to, there’s one way to find out. It’s conceivable that [Ankit] could have dug his way through the AVR’s hardware I2C peripheral documentation and managed to find the status codes that would have also given him the same insight, but it’s often the case that putting a scope on it is the quick and easy way out.
Atmel put out some new, small microcontroller chips early this year, and we’re just now starting to think about how we’d use them. The ATtiny102 and ATtiny104 (datasheet) sell for about a buck (US) and come in manageable SOIC packages with eight and fourteen pins respectively. It’s a strange chip though, with capabilities that fit somewhere between the grain-of-rice-sized ATtiny10 and the hacker-staple ATtiny25-45-85 series.
The ATtiny104 has a bunch of pins for not much money. It’s got a real hardware USART, which none of the other low-end AVRs do, and it’s capable of SPI in master mode. It has only one counter, but it’s a 16-bit counter, and it’s got the full AVR 10-bit ADC instead of the ATtiny10’s limited 8-bit ADC. The biggest limitation, that it shares with the ATtiny10, is that it has only 1 KB of program flash memory and 32 bytes (!) of RAM. You’re probably going to want to program this beast in assembler.
Read on for more reviews, and check out [kodera2t]’s video review at the end.
[Bruce Land] switched his microprocessor programming class over from Atmel parts to Microchip’s PIC32 series, and that means that he’s got a slightly different set of peripherals to play with. One thing that both chips lack, however is a digital-to-analog converter (DAC). Or do they? (Dun-dun-dun-duuuuhnnnn!)
The PIC part has a programmable, sixteen-level voltage reference. And what is a
Vref if not a calibrated DAC? With that in mind, [Bruce] took to documenting its performance and starting to push it far beyond the manufacturer’s intentions. Turns out that the
Vref has around 200 kHz of bandwidth. (Who would update a voltage reference 200,000 times per second?)
Anyway, [Bruce] being [Bruce], he noticed that the bits weren’t changing very often in anything more than the least significant bit: audio waveforms, sampled fast enough, are fairly continuous. This suggests using a differential PCM encoding, which knocks the bitrate down by 50% and saves a lot on storage. (Links to all the code for this experiment is inline with his writeup.)
The audio hacks that come out of [Bruce]’s Cornell ECE classes are always a treat. From the lock that you have to sing to open, to chiptunes programmed into an FPGA, there’s something for music fans of all inclinations.
If you’re an active shopper on RC websites, you’ll find tiny motors spec’ed at hundreds of watts while weighing just a few grams, like this one. Sadly, their complementary motor controllers are designed to drive them at a high speed, which means we can only hit that “520-watt” power spec by operating in a max-speed-minimum-torque configuration. Sure, that configuration is just fine for rc plane and multicopter enthusiasts, but for roboticists looking to drive these bldc motors in a low-speed-high-torque configuration, the searches come up blank.
The days in the dust are coming to an end though! [Cameron] has been hard at work at a low cost, closed-loop controller for the robotics community that will take a conventional BLDC airplane motor and transform it into a high end servo motor. Best of all, the entire package will only run you about $20 in parts–including the position sensor!
“Another BLDC motor controller?” you might think. “Surely, I’ve seen this before“. Fear not, faithful readers; [Cameron’s] solution will get even the grumpiest of engineers to crack a smile. For starters, he’s closing the loop with a Melexis MLX90363 hall effect sensor to locate the rotor position. Simply glue a small magnet to the shaft, calibrate the magnetic field with one revolution, and–poof–a wild 14-bit encoder has appeared! Best of all, this solution costs a mere $5 to $10 in parts.
Next off, [Cameron] uncovered a little-known secret of the ATMEGA32u4, better known as the chip inside the Arduino Leonardo. It turns out that this chip’s TIMER4 peripheral contains a feature designed exclusively for 3-phase brushless motor control. Complementary PWM outputs are built into 3 pairs of pins with configurable dead time built into the chip hardware. Finally, [Cameron] is pulsing the FETs at a clean 32-Khz — well beyond the audible range, which means we won’t hear that piercing 8-Khz whine that’s so characteristic of cheap BLDC motor controllers.
Of course, there are caveats. [Cameron’s] magnetic encoder solution has a few milliseconds of lag that needs to be characterized. We also need to glue a magnet to the shaft of our motor, which won’t fly in all of our projects that have major space constraints. Finally, there’s just plain old physics. In the real world, motor torque is directly proportional to current, so stalling an off-the-shelf bldc motor at max torque will burn them out since no propeller is pushing air through them to cool them off. Nevertheless, [Cameron’s] closed loop controller, at long last, can give the homebrew robotics community the chance to explore these limits.
Near the end of the lifecycle of mass-market commercial product development, an engineering team may come in and make a design for manufacturability (DFM) pass. The goal is to make the device easy, cheap, and reliable to build and actually improve reliability at the same time. We hackers don’t usually take this last step, because when you’re producing just a couple of any given device, it hardly makes sense. But when you release an open-source hardware design to the world, if a lot of people re-build your widget, it might be worth it to consider DFM, or at least a hardware hacker’s version of DFM.
If you want people to make their own versions of your project, make it easy and cheap for them to do so and don’t forget to also make it hackable. This isn’t the same as industrial DFM: rather than designing for 100,000s of boards to be put together by robot assembly machines, you are designing for an audience of penny-pinching hackers, each building your project only once. But thinking about how buildable your design is will still be worthwhile.
In this article, I’m going to touch on a couple of Design for Hackers (DFH) best practices. I really want to hear your experience and desires in the comments. What would you like to see in someone else’s open designs? What drives you nuts when replicating a project? What tricks do you know to make a project easily and cheaply buildable by the average hacker?
It probably doesn’t matter much for the hacker who sleeps with a bag of various microcontroller flash programmers under the pillow, but for an end-user to apply a firmware upgrade, convenience is king. These days that means using USB, and there are a few good AVR USB bootloaders out there.
But [Dmitry Grinberg] wanted more: the ability to encrypt the ROM images and verify that they haven’t been tampered with or otherwise messed up in transit. Combined with the USB requirement, that meant writing his own bootloader and PC-side tools. His bootloader will take unencrypted uploads if it doesn’t have a password, but if it’s compiled with a key, it will only accept (correctly) encrypted hex files.
Since the bootloader, including the USB firmware, is on the hefty side at 3.3 kB, [Dmitry] included hooks to re-use the bootloader’s USB code from within the target application. So if you were going to use V-USB in your program anyway, it doesn’t actually take up that much extra space. It’s a cute trick, but it ties the bootloader and user program together in a way that gives us the willies, without specifically knowing why. Perhaps we can debate this in the comments.
If you need an AVR USB bootloader, but you don’t need the encryption, we like Micronucleus. But if you need to deliver updates to users without them being able to modify (or screw up) the code in the middle, give [Dmitry]’s setup a try.