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.
[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.
Sometimes you start a project with every intention of using it in a specific way, or maybe your plan is to have a very well-defined set of features. Often, though, our projects go in a completely different direction than we might have intended. That seems to be the case with [Dave] and his Pips. These tiny devices were originally intended to be used by people with disabilities, but it turns out that they’re a perfect platform for this “Internet of Things” thing that we’ve been hearing so much about.
Built around the Bright Blue Bean microcontroller platform to take advantage of its low energy requirements, the Pips were originally intended to be placed around the house where they would light up to remind the user to perform some task. Once the button was pushed, the next Pip in the sequence would activate. While they are quite useful for people with cognitive or sensory impairments, they can also be used in a similar way to the Amazon Dash button or any other simple internet-enabled device. Especially when used in conjunction with a home automation setup, this device could be used in novel ways, such as automating your morning routine without having to add a weight sensor to your bed.
We are also pleased to see that all of the project files are available on GitHub for anyone looking to try this out. Its interesting when something that was originally intended to help out anyone with a disability finds a use somewhere else that it might not have originally been intended for. After all, though, the principle of using things in novel ways is kind of the entire basis of this community.
Microcontrollers are getting faster and faster, as is most of the rest of the computing world. Just like you can play Nintendo console games on the newest Nintendo handhelds, it seems that modern microcontrollers can replace CPUs on personal computers from the 80s. At least, that’s what [Dave] has shown with his latest project: an Atmel microcontroller that directly attaches to the CPU slot on a Commodore PET.
Essentially, the project started out as a test rig of sorts for the Commodore. [Dave] wanted to see if some of the hardware on the Commodore was still functional and behaving properly. From there, it somewhat snowballed. The address bus was easy enough to investigate, but adding only a few more pins on the microcontroller he was already using would be enough to access the databus too. A character table was soon added, a test algorithm, and more useful insights. It’s a masterful manipulation of this older hardware with modern technology and is definitely worth a look.
There’s a lot more going on in the retrocomputing world than meets the eye. One might think these old computers were all in landfills by now, but there is a devoted fanbase that does everything from building new hard drives for old computers or investigating their true audio-visual potential.
Thanks to [Mike w] for the tip!
Home automation seems to be working its way to a computer-controlled future in which humans will be little more than an afterthought. Eventually they will take over Skynet-style, but until then, we will enjoy the relative comfort that a good home automation project provides. The latest from [Clement] certainly goes a long way towards this goal by automating his bed (Google Translate from French).
With four load cells and a microcontroller, [Clement]’s bed can tell whether or not he is sleeping. After taking a weight reading, the bed can send commands to the rest of his home automation system and tell it to turn off his stereo and turn the lights off in the house (or change them to a different color). And it doesn’t stop with just going to bed, but when he wakes up as well. The system can begin turning on lights, starting the coffee machine, and opening the blinds without any interaction from him at all.
This project goes well beyond simple home automation. With a little configuration and extrapolation, [Clement] can tell where in the bed he slept at night, what stages of sleep he was in at specific times, and the overall quality of his sleep. This could go a long way for someone who has a hard time sleeping and needs a little more information on how to correct the problem.
While we’ve seen various takes on tying a bed into one’s home automation system, this one goes above and beyond with the amount of data collected. You could even go one step further and have it turn on some Barry White if the normal weight in the bed suddenly doubles, for whatever reason. Maybe that will be a feature in Version 2.
If you’ve read through the comments on Hackaday, you’ve doubtless felt the fires of one of our classic flame-wars. Any project done with a 32-bit chip could have been done on something smaller and cheaper, if only the developer weren’t so lazy. And any project that’s squeezes the last cycles of performance out of an 8-bit processor could have been done faster and more appropriately with a 32-bit chip.
Of course, the reality for any given project is between these two comic-book extremes. There’s a range of capabilities in both camps. (And of course, there are 16-bit chips…) The 32-bit chips tend to have richer peripherals and run at higher speeds — anything you can do with an 8-bitter can be done with its fancier cousin. Conversely, comparatively few microcontroller applications outgrow even the cheapest 8-bitters out there. So, which to choose, and when?
Eight Bits are Great Bits
The case that [Mike] makes for an 8-bit microcontroller is that it’s masterable because it’s a limited playground. It’s a lot easier to get through the whole toolchain because it’s a lot shorter. In terms of debugging, there’s (often) a lot less that can go wrong, letting you learn the easy debugging lessons first before moving on to the truly devilish. You can understand the hardware peripherals because they’re limited.
And then there’s the datasheets. The datasheet for a chip like the Atmel ATMega168 is not something you’d want to print out, at around 660 pages long. But it’s complete. [Mike] contrasts with the STM32F405 which has a datasheet that’s only 200 pages long, but that’s just going over the functions in principle. To actually get down to the registers, you need to look at the programming manual, which is 1,731 pages long. (And that doesn’t even cover the various support libraries that you might want to use, which add even more to the documentation burden.) The point is, simpler is simpler. And if you’re getting started, simpler is better.