It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.
In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.
Continue reading “What Could Go Wrong: Asynchronous Serial Edition”
It is just amazing how small the boards are for some really powerful smart phones. For instance, the diminutive size of this Meizu MX Android phone’s board is only outshone by the intricate packaging the phone arrived in. [Adam Outler] did an unboxing of the device. But for him that mean tearing down all of the components and using a Bus Pirate to root the device.
In the video after the break he gives us a candid look at what it takes to exploit this piece of hardware. You might be a little spooked by the commands, which he reads aloud character by character, but watch closely and you’ll see they’re really quite common functions.
His rooting quest began by reading the datasheet for the main processor to find the USART parameters. With that information he hooked his Bus Pirate to ground, then probed around various test points on the board while it was rebooting until serial data started scrolling on the screen. He had found the USART lines and soldered a breakout connector onto them so that he had access after reassembling the phone.
From there he used the Bus Pirate to merge with the board’s terminal, then rebooted the phone using the Android Debug Bridge. Once it fires up, the Bus Pirate terminal window is sitting at a root prompt (many companies disable this but [Adam] was lucky). He remounts the internal file system to be rewritable, then uses the ADB to push the Linux substitute user (su) command onto the device as it will be needed by the Superuser.apk program. That is the next thing to be installed and once it is he officially has root.
Continue reading “Meizu MX rooted using the Bus Pirate”
So let’s say your using an Arduino in your project. You already have the hardware-based serial interface working with one portion of the project and need a second serial port for unrelated hardware. The obvious solution is to write one in software. But this is a place where working in the Arduino environment gets really hairy. Since there’s a layer of abstraction between the code and the hardware interrupts, it can be difficult to know if you are going to have timing problems. But there’s a new library available which seeks to reduce the latency of software-based serial communications so that you don’t have to worry about it.
It’s named AltSoftSerial because it is a software-based serial library that is an alternative to the NewSoftSerial package. The former can function with just 2-3 microseconds of latency, while the latter has as much as a 174 microsecond hit. If it functions as advertised that’s quite an improvement. It’s not hard to put together a hardware test platform, and the example program is only about a dozen lines of code (which is the beauty of working in this environment) so give it a try if you have a free hour here or there.
We find it interesting that PIC and AVR programming is very common in hobby electronics but ARM doesn’t have nearly the same foothold. This is partly because there’s a knowledge barrier involved with making the transition (the other part is probably the lack of DIP packaged chips). But if you’ve worked with 8-bit microcontrollers you can certainly make the jump into the 32-bit realm. Here’s a great opportunity to get your feet wet. This guide will show you how to get the USART on an STM32 Discovery Board working, which makes it easy to get feedback about what’s going on in your program.
One difference you’ll notice when moving to ARM microcontrollers is that there is almost always a library bundle available from the manufacturer which includes all of the functions you need for hardware control (USART, USB, Ethernet, ADC, etc.). That’s the case here, so simply including the USART library makes it a snap to finish the rest of the program. Once you hook up your communications hardware (an FTDI cable in this case) just use the library initialization functions, followed by the send and receive commands and you’ll be pushing messages to a computer terminal in no time.
If you’re trying to use the STM32 Discovery Board with a Linux box here’s a shove in the right direction.