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.
Despite concerted efforts to kill them, serial ports are alive and well, especially in embedded system. True, most of them end in a USB port, these days, but there’s still a lot of gear with a DE-9 (it isn’t a DB-9, despite the common use of the word) or a TTL-serial port lurking around. [James Fowkes] got tired of managing a bunch of USB to serial adapters, so he decided to build his own FT4232 breakout board that would provide four serial ports from a USB connection.
The small board has transmit and receive LEDs for each port along with EMI and ESD protection on the USB port. The ports are all TTL serial, serving the modern hacker, and the 3.3V pins are 5V tolerant.
Continue reading “Quad Serial Adapter”
[Jason Jones] has always wanted a curve tracer for his home shop. When he was starting out in electronics he fell in love with a machine called a Huntron Tracker 2000. This machine would feed a sine wave into a circuit on one side and plot a XY graph on the other.
[Jason] figured that with a modern microcontroller such a device could be build simply and cheaply for around $15 dollars. With that requirement in mind he set out to build it. He selected a PIC24F16KM202 for the brain and got to work.
The write-up is really great. It’s rare that someone puts every step of their development and design thinking into writing. Some have argued that this is the only true way to have an OSHW hardware project. The series covers everything from the initial requirements and parts selection to the software development and eventual testing of the device.
[Jason] managed to build a pretty capable little curve tracer in the end. We really enjoyed it when he used the tracer to debug the tracer.
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.
I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master to wait. It sounds perfect.
In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.
But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.
Continue reading “What Could Go Wrong? I2C Edition”
$32 billion USD doesn’t buy as much as it used to. Unless you convert it into British Pounds, battered by the UK’s decision to leave the European Union, and make an offer for ARM Holdings. In that case, it will buy you our favorite fabless chip-design company.
The company putting up 32 Really Big Ones is Japan’s SoftBank, a diversified technology conglomerate. SoftBank is most visible as a mobile phone operator in Japan, but their business strategy lately has been latching on to emerging technology and making very good investments. (With the notable exception of purchasing the US’s Sprint Telecom, which they say is turning around.) Recently, they’ve focused on wireless and IoT. And now, they’re going to buy ARM.
We suspect that this won’t mean much for ARM in the long term. SoftBank isn’t a semiconductor firm, they just want a piece of the action. With the Japanese economy relatively stagnant, a strong Yen and a weak Pound, ARM became a bargain. (SoftBank said in a press release that the Brexit didn’t affect their decision, and that they would have bought ARM anyway. Still, you can’t blame them for waiting until after the vote, and the fallout, to make the purchase.) It certainly won’t hurt SoftBank’s robotics, IoT, or AI strategies to have a leading processor design firm in their stable, but we predict business as usual for those of us way downstream in the ARM ecosystem.
Thanks [Jaromir] for the tip!
Summer is now in full swing, which means that mowing the lawn once a week is starting to get old. So why not build a robot do it for you? That’s what [Blake Hodgson] did, and he’s never been happier. It only took him a couple of weeks of quality time at one of the local makerspaces.
[Blake] was showing off Lawn da Vinci at this year’s Kansas City Maker Faire. He had his own booth around the corner from Hammerspace, the shop where it all came together. [Blake] started with a standard push mower from a garage sale and designed a frame around it using OnShape. The frame is made from angle iron, so it’s strong enough that he can ride on the thing. To each his own, we say. The wheels and motors came from a mobility scooter and match the beefiness of the frame. These are powered by two 12v car batteries wired in series. He drives it around his yard with an R/C airplane controller.
Lawn da Vinci’s brainpower comes from two Arduino Pro Minis and a Raspberry Pi. One Arduino controls the motors and the R/C signal from the remote. The other runs some extra kill switches that keep the Lawn da Vinci out of trouble.
So what’s the Raspi for? Right now, it’s for streaming video from the webcam attached to a mast on the frame back to his phone. [Blake] says he has had some latency issues with the webcam, so there could be a pair of drone racing goggles in his future. He also plans to add a GPS logger and to automate part of the mowing.
Now, about those kill switches: there are several of them. You probably can’t have too many of these on a remote control spinning suburban death machine. Lawn da Vinci will stop grazing if it goes out of range of the remote or if the remote is turned off. [Blake] also wired up a dedicated kill switch to a button on the remote and a fourth one on a separate key fob.
The Lawn da Vinci is one of many example projects that [Blake] uses to showcase the possibilities of KC Proto, a company he started to help local businesses realize their ideas by offering design solutions and assistance with prototyping. Between mowings, [Blake] puts the batteries on a trickle charger. If you make your own robot lawn mower, you might consider building a gas and solar hybrid.