The MSP430 is a popular microcontroller, and on board is a neat little clock source, a digitally controlled oscillator, or DCO. This oscillator can be used for everything from setting baud rates for a UART or for setting the clock for a VGA output.
While the DCO is precise – once you set it, it’ll keep ticking off at the correct rate – it’s not accurate. Without a bit of code, it’s difficult to set the DCO to the rate you want, and the code to set that rate will be different between different chips.
When [Mike] tried to set up a UART between an MSP430 and a Bluetooth module, he ran into a problem. Setting the MSP to the correct baud rate was difficult. Luckily, there’s a way around that.
There’s an easy way to set the DCO on the MSP programatically; just set two timers – one that interrupts every 512 cycles, with its clock source set to the DCO, and another that interrupts every 32768 cycles that gets its clock from a 32.768kHz crystal. The first timer clicks off every second, and by multiplying the first timer by 512, the real speed of the DCO can be deduced.
After playing around with this technique and testing the same code on two different chips, [Mike] found there can be a difference of almost 1MHz between the DCOs from chip to chip. That’s something that would have been helpful to know when he was playing around with VGA on the ‘430. Back then he just used a crystal.
The 1-Wire protocol is usually found in temperature sensors, but you’ll also find it in chips ranging from load sensors, a battery sensor and LED driver that is oddly yet officially called a ‘gas gauge’, and iButtons. It’s a protocol that has its niche, and there are a few interesting application notes for implementing the 1-wire protocol with a UART. Application notes are best practices, but [rawe] has figured out an even easier way to do this.
The standard way of reading 1-Wire sensors with a UART is to plop a pair of transistors and resistors on the Tx and Rx lines of the UART and connect them to the… one… wire on the 1-Wire device. [rawe]’s simplification of this is to get rid of the transistors and just plop a single 1N4148 diode in there.
This would of course be useless without the software to communicate with 1-Wire devices, and [rawe] has you covered there, too. There’s a small little command line tool that will talk to the usual 1-Wire temperature sensors. Both the circuit and the tool work with the most common USB to UART adapters.
The ESP8266 Internet of Things module is the latest and greatest thing to come out of China. It’s ideal for turning plastic Minecraft blocks into Minecraft servers, making your toilet tweet, or for some bizarre home automation scheme. This WiFi module is not, however, certified by the FCC. The chipset, on the other hand, is.
Having a single module that’s able to run code, act as a UART to WiFi transceiver, peek and poke a few GPIOs, all priced at about $4 is a game changer, and all your favorite silicon companies are freaking out wondering how they’re going to beat the ESP8266. Now the chipset is FCC certified, the first step to turning these modules into products.
This announcement does come with a few caveats: the chipset is certified, not the module. Each version of the module must be certified by itself, and there are versions that will never be certified by the FCC. Right now, we’re looking at the ESP8266-06, -07, -08, and -12 modules – the ones with a metal shield – as being the only ones that could potentially pass an FCC cert. Yes, those modules already have an FCC logo on them, but you’re looking at something sold for under $5 in China, here.
Anyone wanting to build a product with the ESP will, of course, also need to certify it with the FCC. This announcement hasn’t broken down any walls, but it has cracked a window.
FTDI-gate wasn’t great for anybody, and now with hardware hobbyists and technological tinkerers moving away from the most popular USB to serial adapter, some other chip has to fill the void. The cheapest USB to serial chip on the market appears to be the CH340G, available for 20-40 cents apiece from the usual retailers. There is, however, almost no English documentation, and the datasheet for the CH340 family doesn’t include this chip. [Ian]’s here to help you out. He got his mitts on a few of these chips and managed to figure out the pinout and a few reference schematics. He even made an Eagle part for you. Isn’t that nice?
The CH340 series of chips do exactly what you would expect them to do: a full-speed USB device that emulates a standard serial interface, with speeds from 50bps to 2Mpbs. The chip supports 5V and 3.3V, and all the weird modem lines are supported. This chip even has an IrDA mode, because wireless communication in the 90s was exactly as rad as you remember.
With [Ian]’s help, we now have a cheap source of USB to serial chips. If you need the datasheet, here you go. The driver is a bit more difficult to find, but what you’re looking for is the CH341 family of chips. That can be found with a little bit of Google fu.
8-bit AVRs and 32-bit ARMs do one thing, and one thing well: controlling other electronics and sensors while sipping power. The Internet of Things is upon us and with that comes the need for connecting to WiFi networks. Already, a lot of chips are using repackaged System on Chips to provide an easy way to connect to WiFi, and the USR-WIFI232-T is the latest of the bunch. It’s yet another UART to WiFi bridge, and as [2XOD], it’s pretty easy to connect to an AVR.
The module in question can be had through the usual channels for about $11, shipped straight from China, and the only purpose of this device is to provide a bridge between a serial port and a wireless network. They’re not that powerful, and are only meant for simple tasks,
[2XOD] got his hands on one of these modules and tested them out. They’re actually somewhat interesting, with all the configuration happening over a webpage served from the device. Of course the standard AT commands are available for setting everything up, just like the ESP8266.
With a month of testing, [2XOD] has found this to be a very reliable device, logging temperatures every minute for two weeks. There’s also a breakout board available to make connection easy, and depending on what project you’re building, these could be a reasonable stand-in for some other popular UART -> WiFi chips.
This technique can be expanded to provide bidriectional communication between a microcontroller and a computer. On the project Github, [Gordon] used the microphone pin on a TRRS jack to sent data to a computer. It needs two more resistors, but other than that, it’s as simple as the one-way communications setup.
[Gordon] put together a few demos of the program, including one that will change the color of some RGB LEDs in response to input on a webpage.
Continue reading “Using a Headphone Jack as a UART”
A few days ago we learned chip maker FTDI was doing some rather shady things with a new driver released on Windows Update. The new driver worked perfectly for real FTDI chips, but for counterfeit chips – and there are a lot of them – the USB PID was set to 0, rendering them inoperable with any computer. Now, a few days later, we know exactly what happened, and FTDI is backing down; the driver has been removed from Windows Update, and an updated driver will be released next week. A PC won’t be able to communicate with a counterfeit chip with the new driver, but at least it won’t soft-brick the chip.
Microsoft has since released a statement and rolled back two versions of the FTDI driver to prevent counterfeit chips from being bricked. The affected versions of the FTDI driver are 2.11.0 and 2.12.0, released on August 26, 2014. The latest version of the driver that does not have this chip bricking functionality is 220.127.116.11, released on January 27th. If you’re affected by the latest driver, rolling back the driver through the Device Manager to 18.104.22.168 will prevent counterfeit chips from being bricked. You might want to find a copy of the 2.10.0 driver; this will likely be the last version of the FTDI driver to work with counterfeit chips.
Thanks to the efforts of [marcan] over on the EEVblog forums, we know exactly how the earlier FTDI driver worked to brick counterfeit devices:
[marcan] disassembled the FTDI driver and found the source of the brick and some clever coding. The coding exploits differences found in the silicon of counterfeit chips compared to the legit ones. In the small snippet of code decompiled by [marcan], the FTDI driver does nothing for legit chips, but writes 0 and value to make the EEPROM checksum match to counterfeit chips. It’s an extremely clever bit of code, but also clear evidence FTDI is intentionally bricking counterfeit devices.
A new FTDI driver, presumably one that will tell you a chip is fake without bricking it, will be released next week. While not an ideal outcome for everyone, at least the problem of drivers intentionally bricking devices is behind us.