It is official! FTDI launches a USB 2.0 module to replace DB9 RS232 connector on legacy boards.
I was given a sneak preview of this module during the Embedded World show at Nuremberg (see here) and immediately felt that this was going to be a killer product.
The module features a standard USB “mini-B” type connector in a module that fits the PCB footprint of a standard 9-pin DB9 connector. The module offers a fast and simple method to add USB 2.0 connectivity to any existing PCB board that has a DB9 RS232 connector.
Two modules are available to replace male or female DB9 connectors. They contain all the electronics needed to carry out the conversion between RS232 and USB. The modules are based on the popular FT232R USB 2.0 to serial UART converter IC from FTDI, which handles the USB protocol conversion. The FT232R device converts from USB to a serial UART interface, which is then level-shifted into RS232 signal levels, within the module. Power to the module is supplied by the USB connection. The modules support a maximum transfer rate of 1 Mbits/s on the RS232 interface.
The DB9-USB-RS232 modules are supplied complete with FTDI's royalty free drivers, which enable a device to be integrated as an additional, (virtual) COM port into an existing software application. The range of drivers includes Microsoft WHQL certified drivers for Windows based operating systems, drivers for Linux and Mac OS operating systems.
Pricing for DB9-USB-M (male) and DB9-USB-F (female) starts at $22.04 for single quantities.
Further information on the DB9-USB-RS232 modules is available on the FTDI website.
Tipped off by my friend Gregory I recently bought an LED panel with 32x64 two-color pixels (that is a total of 4096 LEDs!, ref. DE-DP100 from Sure Electronics). I wanted to make some sort of message board out of it, but I was not sure what would be the easiest way. And then suddenly it struck me: why not use an mbed module? The mbed module would offer me programming in C/C++ and a USB file system that would be perfect for storing message files written on a PC. mbed is for fast prototyping and this would be a nice project to see if mbed’s promises would hold true.
Although the LED panel is supposed to run from 5 V and an mbed module from 3V3, studying the LED panel’s PCB revealed that it was built with HC logic only and so it should be possible to run it from 3V3. That was one problem out of the way, no level shifters needed, and I hooked up the mbed to the LED panel with just 12 wires. Note that the mbed module itself is powered from the USB port.
The LED panel has an SPI-like interface and is rather easy (albeit a bit bizarre) to control. It took me some time to figure out that the datasheet provided by the vendor had the CLK and the LATCH lines swapped, but after that I was able to put pixels where I wanted them and in the color of my choice (red, green, orange and black).
The next step was to add a font so that I could write text. If you have ever bitmapped a font you know how tedious a work that is, so I turned to the web. A quick search found me a freeware utility called The Dot Factory and 10 minutes later I had a C source file ready with all the printable characters from an 8-point Arial font (but that could have been any of the fonts available on my PC). That is so much faster than doing it by hand! Another 15 minutes of coding later I was able to print a string on the display anywhere I wanted.
Now I needed a way to get text from a file on the display, together with some commands to control the way the text would be shown. This meant adding an mbed file system object to my code (1 line). Of course I wanted text scrolling, color & position control so I decided to use an INI file for this. A new search on the internet found me a neat little C library named inih that turned out to be very ergonomic: importing and integrating it into my mbed project took a mere 5 minutes; I am definitely going to keep this library!
The final task now was to implement text scrolling properly. This was actually not too difficult using a cheat and thanks to the way the font was implemented. About one hour later I had it all working the way I wanted.
This is the point where features started creeping in. It would be nice to have several pages of text, scrolling should be possible in both directions, scroll speed per line, etc., etc. This is also the point where I started wasting time. Add feature, compile, check, change, compile, check, change, … After some hours of this I decided to stop and freeze the project; you have to draw the line somewhere.
The result is pretty satisfying. The message board can now display seven pages of four lines of text. For each line you can specify a color, an (x,y) position and a scroll speed and direction. Two global parameters allow you to control overall scrolling speed and display brightness, but these are not so useful. I added a push button to browse the pages. Watch this short video to see the result.
The mbed environment really helped to finish this project quickly, the hardware is ridiculously simple and the software is pretty small. The executable is 51 KB and needs 5.5 KB of RAM (mainly for message storage). All in all I think I spend about one day cooking this up, that’s not too bad, isn’t it?
Writing portable code is more than just sticking to strict ANSI-C. If you look at the sources of programs or libraries that compile on different platforms, you will find lots of ifdef statements that provide the portability. It is actually pretty difficult to write portable code.
Currently I am into ARM development and I try to target just one OS: mine, on one platform: mine. But I want to use different compilers. I try to write code as portable as possible, without adding compiler specific things, but that just isn’t possible, especially when you target an embedded platform.
Initially I developped some code for GCC. Then I decided that it would be nice if I could use the Keil uVision tools as well. Getting my GCC code to compile with the RealView compiler (used by the uVision tools) was not too difficult, but getting it to work, was.
The problems were caused by, as always, the interrupts. In my code a timer and a UART use interrupts. With the GCC tools both worked fine, with the Keil tools only the UART worked. Uh oh... long debug hours ahead...
I remembered that the GCC code had an interrupt wrapper in the startup code, so all I had to do was to replace the Keil startup code with the GCC startup code. Easier said than done, because it turned out that the Keil assembler did not like the GCC assembly code. This code was definitely not tool-portable (even though the origin of the code clearly was Keil.).
Right, forget about GCC’s special interrupt code, let’s do it the Keil way. I found a Keil timer example that worked on my platform and I copied the code across to my GCC code and … it did not work. I examined the assembler code generated by the compiler for both cases and noticed that the entry and exit code was not the same depending on if the code was integrated in my GCC code or in the Keil example. Yet it was the same C-code, verbatim, since I copied it across, remember?
Or was it?
After stripping down my GCC code (and many hours of hair tearing) I finally discovered that the GCC code had defined away the __irq keyword! Aaargh! So that’s why I didn’t get the right entry and exit code for my ISR!
OK, so I quickly fixed this and now everything would work, right? Wrong!
Obviously there was another problem. My code was now working a bit, but it hung in a delay function. This delay function waited for the timer to reach a certain value before continuing. After some debugging I found that the problem was not so much the delay function itself, but returning from it, it made the program crash. Hmm, that smelled like stack problems.
To make a long story short, the hanging was caused by a function call from within the timer ISR to update a 10 ms timer. After many more debugging I finally found the reason: it was the example code that I had copied! The example proudly mentioned that it handled nested interrupts and I thought that that was mighty fine. But as it turned out, the way the example handled nested interrupts it could not handle function calls from within an ISR... Once the nested interrupts disabled, my Keil code finally worked as my GCC code.
In the end I did not have to make a lot of changes to my original code to port it to a different compiler. It was enough to set the include paths right, define away a GCC __extension__ keyword, add a wint_t typedef, re-allow the __irq keyword and disable nested interrupts, but these last two took me many hours to figure out. At least I now finally understand why the GCC startup code has this special interrupt handling code...
It has been a busy period the last few weeks and I did not have the time to update this blog. Although it is still a rather busy time, I decided to write something anyway because I started working on the prototype of the InterSceptre.
Click for a better view. Notice the valid data on the LCD.
I received the PCB and the parts last Tuesday and I assembled the board. Even though the board is not very complicated, there are a lot of things to test. The first tests are promising. The power supply is fine and the board runs from 3V3 or 5V. There are three different 5V entry points (2x USB & one external power supply) and switch over between these inputs works without resetting the Sceptre board (or the PC).
Also working is the I2C port with discrete level shifter. It is discrete because I tried to avoid SMD parts on this board and through-hole integrated level shifters are hard to find. To test it I use the Pocket Terminal which is part of Elektor project 080253 Running-in bench. This terminal is supposed to run from 5V, but the Sceptre runs from 3V3, so I2C communication is incompatible. The level shifter fixes this and the fact that I can write to the terminal and read its keys means that all is working fine.
The four multiplexed DAC outputs are working, which is cool. I can control them with the rotary encoder on the terminal.
Not tested yet are the RS232 & RS485/DMX512 ports, the MIDI interface, the JTAG port, the SPI port and the digital I/O. The SPI port is particularly interesting as the board has space for a WIZnet WIZ812MJ internet module (not mounted for the photo, it should go next to the power connector). The digital I/O is hanging from the I2C bus and some direct from the processor. This is also true for the ADC inputs, so I suppose they will work.
As you can see from the photo, the InterSceptre was designed to fit a standard box from Teko. I did this because this way you can use the Sceptre-InterSceptre combination as a nice stand-alone device. You could only mount the interfaces you need and away you go.
This blog will also be used to inform you about the Sceptre, the open source & hardware ARM7-based 32-bit fast prototyping platform as published in Elektor. In the Pages box on the right of this article you will find a link to a special Sceptre page. All information about updates will be posted there; it is sort of the project’s home page.
The Sceptre is my baby and (for the moment) I do all the development for it. Currently I am working on an extension I/O board on which you can plug a Sceptre so that it can talk to the rest of the world. At the same time my goal is to make this board as universal as possible so that it can also be used with other microcontrollers. Except for its name, InterSceptre, and some component print this I/O board will not be Sceptre specific.
The InterSceptre is due for the June issue of Elektor and I am almost done with the circuit diagram. The board will feature lots of communication interfaces: 2x RS-232, 2x RS-485 (so RS-422 is possible too), MIDI in/out, DMX-512 (OK, that’s just RS-485 with a different connector), a WIZnet module for Internet connection, SPI, PS/2 and I2C. USB is available on the Sceptre itself, but a dedicated USB connector for ISP/serial comms will be on the InterSceptre. I also added a JTAG connector and a 4-way multiplexed DAC (the LPC2148 used on the Sceptre has a 10-bit DAC). To stay flexible the board will have a 25-pin DB connector to give access to the ADC inputs and PWM outputs, and some other GPIO.
All of this can of course (unfortunately) not be used at the same time, but I am confident that it will be useful anyway for many applications.
The universal side of the board is also emphasized by its power supply and it will work with 5V and 3V3 systems. The Sceptre is a 3V3 system but 5V tolerant and I will soon show you how you can use it with a 5V I2C controller.
Contrary to the Sceptre, the InterSceptre will only use easy to solder (change/replace/remove) through-hole parts so mounting it will be possible for anyone capable of holding a soldering iron.
Last week I visited Embedded World 2010 in Nuremberg in Germany. Nuremberg is a nice city with a mediaeval city center and even though I had a hotel room right on the main market place, I did not see much of the town because of the show. The show was pretty big, more than 700 exhibitors spread out over three halls and allthough I spent two full days there, I did not have enough time to see everything.
The main theme of the show was green electronics. Lots of companies showed off green products, low-power boards and microcontrollers. Although low power electronics is very important, there were not many real green novelties. Microamps per megahertz is the most common term now and several manufacturers claim that their products have the lowest number. Unfortunately these numbers are difficult to compare, because one manufacturer talks about a 32-bit controller whereas another is talking about an 8-bit controller. Actually uA/Mhz is not a good measure, it would be better to use something like uA/MIPS or so. Energy Micro, a company that I didn't know before, won the Embedded World award in the category Hardware. Their EFM32 32-bit MCU (ARM Cortex-M3) consumes 180 uA/MHz (running at 32 MHz and 3V).
Another big thing these days is touch technology. In the coming years everything will be tactile, if we can believe the Embedded World exhibitors. Personally I am a bit weary of touch interfaces. At the end of the seventies touch keys were hot too. Being a poor student I had recovered a third-hand color TV with touch keys for the channel selection. These keys were very sensible to weather conditions and my TV changed station randomly, especially when humidity was high or when I really wanted to see something. One day this TV caught spontaneously fire and I finally got rid of it, but that's another story.
Now I have a monitor with touch keys. I also have a cat. It has happened several times that the cat changed the settings of my monitor in a completely random way just by striking the tactile surface of the monitor. I guess I’ll just have to wait until the touch craze has passed before I buy any new kit.
This one is organised by Lantronix to promote their XPort Pro, world’s smallest Linux computer (according to Lantronix).
The contest is open to all individuals with interest in network technology, including businesses, university faculty, students, research labs, engineers and design contractors. There is no limit to the number of entries per person or organisation. Prizes of $6,000 and $3,000 will be awarded to the two top entries for Best Linux Design, and a separate prize of $3,000 for the Best Student Linux Design.
To enter you have to buy an XPort Pro evaluation kit for $99. This is bearable, but will probably limit the number of participants.
I started life embedded in my mother and I’ve been an embedded system ever since. In this blog I will share my experiences, opinions & questions related to embedded systems & microcontrollers. Enjoy and feel free to join in.
