A cool little project came our way, which we thought might be of interest to some of you vintage computer buffs. [Joerg Hoppe] wrote in to share a DEC VT100 terminal he resurrected in a novel fashion.
His “DECBox” system was created with a Beaglebone, which he uses to run a wide array of PDP11/VAX terminal emulators, thanks to the SIMH project. [Joerg] constructed an expansion shield for the Beaglebone that provides several UART connections, enabling him to connect it to his DEC terminal over a serial interface. Since he added several serial plugs to the Beaglebone, he can even run multiple emulator installations in parallel on different terminals without too much trouble.
[Joerg’s] efforts are mainly for a vintage computer display he is constructing, but setting up such a system of your own should be no problem. If you happen to have one (or more) of these boxes sitting around collecting dust, this would be an easy way to get them all up and running without bulky external hardware, since the Beaglebone tucks nicely into the rear expansion slot on a VT100.
Be sure to check out his site for more details on how his DECBox software package works as well as for more pictures of vintage terminal goodness.
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.
[Rajendra] found an easy way to make a USB temperature logger. He already had a USB to UART adapter that takes care of the heavy lifting. On one end it’s got the USB plug, on the other a set of pins provide a ground connection, 3.3V and 5V feed, as well as RX/TX lines.
To get the hardware up and running all he needed was something to read a temperature sensor and push that data over the serial connection. An 8-pin microcontroller in the form of a PIC 12F1822 does the trick. It runs off of the 5V pin on the USB-UART, and uses the ADC to get temperature data from an MCP9701A sensor.
The sample rate is hard-coded into to the PIC’s firmware, but adding a button, or coding some serial monitoring could easily make that configurable. [Rajendra] used Processing to write an app which displays the incoming temperature info and uses the computer to time-stamp and log the inputs. We could see this as a quick solution to tracking wort temperature during fermentation to make sure your beer comes out just right.
[Dane] bought a reasonably cheap ($17) Hobbyking Echo-6 battery charger and wanted to see what sort of information he could pull from the unit. Since the charger is designed for a variety of battery chemistries and sports an LCD screen, he figured that it contained a fairly decent microcontroller which he could tap into for some useful data.
He disassembled the unit and started looking around for any useful items. He discovered that it used an ATMega32 microcontroller and had quite a few unpopulated areas on the PCB, which led [Dane] to believe that the Echo-6 shared its main board with a more robust charger. He tapped into the ATMega’s UART and began seeing data immediately. Once he figured out what was coming over the serial line, he piped the data into LogView, resulting in some nice graphs showing off the charge/discharge processes in detail.
Tapping into the Echo-6 seems easy enough for any skill level, and we assume that just about anyone would benefit from getting kind of information out of their battery charger.
[Bill Porter] has a tip for designing circuits that have multiple connections to a single microcontroller UART. This stemmed from a review of a friend’s circuit design that used the UART in the project, but also called for an FTDI chip in order to reprogram via USB and a bootloader. Unlike the schematic above, the circuit called for straight connections without any resistors. With that design, a conflict will occur if two devices are connected and attempting to communicate at the same time.
The fix is easy. [Bill] discusses how to prioritize the connection by adding the pair of current limiting resistors seen above. This helps to ensure that damage will not occur, and that the FTDI chip will take precedence. Now the external hardware will not preclude the FTDI chip from accessing and programming via the bootloader. The tutorial is intended for those rolling their own boards out of an Arduino-based prototype, but it will work in any situation where you need multiple connections to a single set of UART pins.
[Owen] got down and dirty by adding a touchscreen to his TI-84 graphing calculator. The dirty part is the z80 assembly code he wrote to use the linkport as a UART (assembly always makes us feel queasy). Once that was working he implemented some commands using an Arduino and then hooked up an Nintendo DS touch screen. Now he’s got this proof of concept video where he draws on the screen, that input is interpreted by the Arduino, commands are sent through the UART, and the calculator program draws on the screen. Adding a touch screen to something is a lot more impressive when you have to go to these lengths to get it working. Nice job!
[Humberto] is at it again with a NerdKits video detailing the use of an SPI bus to communicate between microcontrollers. He started with a previous LED marquee project which was limited to a 5×24 LED Matrix and developed a modular solution to increase the size limitation.
The writeup and video embedded after the break do a great job of detailing the important differences between a stand-alone and a modular system. The good news is that the ATmega168 chips being used have a built-in interrupt based SPI protocol. Once wired correctly, a master control chip addresses each module separately, adding data to their buffer until a full frame has been transferred, then moves onto the next module.
Some of the caveats to this system such as digital transmission over long distances are discussed. We do wonder about power limitations if all LED’s in the marquee are illuminated at once. But that concern aside, if you’re thinking of playing around with an LED display don’t forget that there’s usually a huge price break for orders of 500 or 1000 LEDs!
Continue reading “Modular systems using SPI”