Can you spot the serial port in the pic above? You can probably see the potential pads, but how do you figure out which ones to connect to? [Craig] over at devttys0 put together an excellent tutorial on how to find serial ports. Using some extreme close-ups, [Craig] guides us through his thought process as he examines a board. He discusses some of the basics every hobbyist should know, such as how to make an educated guess about which ports are ground and VCC. He also explains the process to guessing the transmit/receive pins, although that is less straightforward.
Once you’ve identified the pins, you need to actually communicate with the device. Although there’s no easy way to guess the data, parity, and stop bits except for using the standard 8N1 and hoping for the best, [Craig] simplifies the process a bit with some software that helps to quickly identify the baud rate. Hopefully you’ll share [Craig's] good fortune if you reach this point, greeted by boot messages that allow you further access.
It’s pretty common to have at least a couple of meters around to measure different values of a circuit at the same time. Where [Emilio P.G. Ficara] ran into a problem was logging the data from both at once. These
Fluke meters have a serial-out, but his computer only has a single serial-in port. He cracked open one of the meters and figured out how to log data from both at the same time.
A lot of folks would look to a microcontroller to solve this problem. You use the chip to pull from each meter simultaneously and report back to a computer (or just dump the values onto an SD card). But this solution is a simple mechanical connector and a bit of creative programming. The way the serial output is set up on these meters they won’t interfere with each other as long as they’re read one at a time. [Emilio] wired them up as seen above, using his own software to manage the pins of the serial port. The example output he posted shows readings from the meters taken within about a tenth of second from each other. That should be good enough for most applications.
If you’ve ever looked into low-level parallel port access you may have learned that it only works with actual parallel port hardware, and not with USB parallel port adapters. But here’s a solution that will change your thinking. It borrows from the way printers communicate to allow USB to parallel port bit banging without a microcontroller.
Sure, adding a microcontroller would make this dead simple. All you need to do is program the chip to emulate the printer’s end of the communications scheme. But that’s not the approach taken here. Instead the USB to RS232 (serial) converter also pictured above is used as a reset signal. The strobe pin on the parallel port drives an inverter which triggers a thyristor connected to the busy pin. Thyristors are bistable switches so this solution alone will never clear the busy pin. That’s where the serial connection comes into play. By alternating the data transmitted from the computer between the bit-bang values sent to LP0 and 0xF0 sent to the serial connector the eight parallel data bits become fully addressable. See the project in action in the clip after the break.
Since most of us are long past the days of hardware serial ports, the USB to serial adapter has become a mainstay on the hacker’s tool belt. While they’re cheap and convenient, USB to serial adapters aren’t always the easiest thing to use: there’s always the issue of what COM port Windows is calling your USB to serial adapter, or what TTY device it is in Linux/OS X.
[Avishay] has a very, very cool solution to this problem: put a display on a USB to serial converter to tell the user what COM port the OS labeled it as.
The prototype runs on a PIC 18F2553 dev board. When plugged into a Windows box, the serial adapter sets up two USB devices. The first device is a Communications Device Class that handles the grunt work of the USB to Serial connection. The second USB device is a proprietary piece of software that grabs the current COM port number. This number is displayed on an LCD thanks to a host application on the Windows PC that reports the COM port of the Serial adapter.
It’s one of those ideas where you didn’t know you needed it until it was presented to you. An excellent tool from [Avishay], although maybe a pair of 7-segment LEDs would make it a more manufacturable device.
Unhappy with the performance of his U-verse modem [Jordan] decided to dig in and see if a bit of hacking could improve the situation. Motorola makes this exclusively for AT&T and there are no other modems on the market which can used instead. Luckily he was able to fix almost everything that was causing him grief. This can be done in one of two ways. The first is a hardware hack that gains access to a shell though the UART. The second is a method of rooting the device from its stock web interface.
We think the biggest improvement gained by hacking this router is true bridge mode. The hardware is more than capable of behaving this way but AT&T has disabled the feature with no option for an unmodified device to use it. By enabling it the modem does what a modem is supposed to do: translate between WAN and LAN. This allows routing to be handled by a router (novel idea huh?).
The usual way send data from a microcontroller is either over RS-232 with MAX232 serial ICs, crystals, and a relatively ancient computer, or by bit-banging the USB protocol and worrying about driver issues. Not content with these solutions, [Scott] came up with sound card μC/PC communication that doesn’t require any extra components.
[Scott] bought a cheap USB sound card dongle on eBay (although a built-in sound card will do) and wired up the tip and ring of the plug to the microcontroller. The data is sent from the microcontroller a lot like Morse code – a short gap between pulses is a zero, a long gap is a one. This is parsed by a Python script using PyAudio. Synchronization, timing, and calibration is automatic because of a 10-bit ‘packet header’ explained in this video.
Continue reading “Sound card microcontroller/PC communication”
If you’re planning to do some hacking with CPLD or FPGA chips you’ll need a way to program them. JTAG is one of the options and here’s a cheap method that uses the serial port (translated).
This method requires only four signals (TDI, TMS, TCK and TDO) plus ground. But the problem is that an RS232 serial port operates with 12V logic levels and the JTAG side of the programmer needs to operate with the logic levels native to the device you’re programming. Commercial programmers use a level convert IC to take care of this for you, but that doesn’t mesh with the cheap goal of this project. Instead, [Nicholas] uses Zener diodes and voltage dividers to make the conversion. There is also an LED for each data signal to give some feedback if you’re having trouble.
You can use this along with a programming application that [Nicholas] whipped up using Visual Studio. It works well via the serial port, but he did try programming with a USB-to-Serial dongle. He found that this method slows the process down to an unbearable 5-minutes. Take a look, maybe you can help to get that sloth-like programming up to a manageable speed.