Wednesday, August 25, 2010

Rayson BTM222 & BTM112 Bluetooth modules

The Sceptre has a Bluetooth module; in fact it was designed for using a BTM222 or BTM112 Bluetooth module from Rayson. These modules are cheap and easy to find on the internet. They do have one problem though and that is the lack of documentation. The official datasheet only shows one table with AT commands and that’s it. When I did my initial experiments with the modules, I managed to get them going, but I was never quite satisfied with how they were working. A few days ago I decided to give them another go and improve my driver. I spent quite some time googling and I did find some new information. The official documentation is still limited to the single table, but now I know that it is incomplete too!

The BTM222 & BTM112 are part of a large family of modules that are all very similar. Differences are mainly in TX power and integrated antennas or not. It is possible to find some more information by studying the datasheets of the related modules.

Commands not listed in the BTM112/BTM222 dataheet I know of so far are:

+++ – Switch from data mode to command mode (valid only when connected)
AT – Doesn’t do anything but should return “OK”
ATCx, x = [0,1,?] – Flow control (RTS/CTS) disable (0) or enable (1, default)
ATH – Drop current connection (valid only when connected)
ATIx, x = [0,1,2,?] – Information, 0: firmware version, 1: current settings, 2: RSSI (valid only when connected)
(Strictly speaking the ATI command was not undocumented completely, but it was partly lost when the PDF was made.)
ATLx, x = [#,*,8] – Baud rate, #: 1200, *: 2400, 8: 921.6k (0-7 were already documented)
ATO – Switch from command mode to data mode (valid only when connected)
ATSx, x = [0,1,?] – RS232 powerdown disable (0) or enable (1, default)
ATXx, x = [0,1,?] – Escape sequence disable (0) or enable (1, default)

Sparkfun sells the BTM182 which is supposed to have the same firmware as the BTM112. The accompanying documents on their web site list most of the above commands.

A delay of at least 50 ms is needed after each command before the module will accept a new one. This delay is much longer for the commands that reboot the module; after ATR0 for instance the module needs at least 3.5 seconds to recover. Several other commands cause module reboots too: ATC(0,1), ATH(0,1), ATO(0,1), ATZ0.

It is possible that the module gets stuck in some undefined state (try ATZ1) or that the serial port parameters are wrong and you do not know them. The only way to get the module out of there is to pull pin PIO4 high for at least three seconds.
My BTM112 gets stuck in master mode when the connection is broken and it will only respond to the AT command. The only way to get it going again quickly is to restore the connection or to use the PIO4 reset. It seems to become available again after a pretty long wait too. I did not observe this behaviour on the BTM222 even though both modules have the same firmware version 4.22 (which doesn't mean that they have the same firmware).

A typical master mode sequence for a virgin device could look like this (I’ve set de waits a bit long):

ATN=my device (16 characters max, space is allowed)
Wait 100 ms
ATP=6587 (set a PIN code of 4 to 8 digits)
Wait 100 ms
ATR0 – switch to master mode
Wait 3500 ms
ATO1 – disable autoconnect (only available in master mode)
Wait 3500 ms
ATF? – scan for remote devices (this only works when autoconnect is off)
Wait at least 60 s or until you receive "Inquiry End."
ATA1 – connect to the first device found
Wait until you receive “CONNECT 'xxxx-xx-xxxxxx'”
Do data transfer
+++ – switch to command mode
Wait 100 ms
ATI2 – get RSSI for remote device
Wait 100 ms
ATO – switch back to data mode
Wait 100 ms
Do data transfer
+++ – switch to command mode
ATH – disconnect
Wait until you receive “DISCONNECT 'xxxx-xx-xxxxxx'”
Etc.

Note that when you are in autoconnect mode (ATO0) the module may reconnect to the same remote device almost immediately after disconnecting with ATH.


This photo shows two Sceptre boards, one with a BTM112, the other with a BTM222. They are connected (both PIO7 LEDs are on continuously) and the BTM112 is the master. I connected a push button to PIO4 for reset testing.


ATZ0 does not reset all parameters, it resets only C, E, H, O, Q, R & X (I did not check the serial port parameters). RS232 powerdown, remote device addresses, friendly name & PIN code remain unchanged. They also survive power cycles, meaning that if the last used slave device has the same PIN code as the master and autoconnect is on then the master will connect automatically to the last used slave device. No commands to issue at all. This will also work if the modules swapped roles.

PIO5 pulses high when data is being transmitted, it is fixed high during reception. PIO7 provides status information. An LED may be used to visualize the status, but it may also be useful to connect them to your processor. Issuing an ATZ0 will make PIO5 & PIO 7 flash three times, but PIO8 only two before resuming normal operation. PIO8 seems to remain high during normal operation. This is what I observed for PIO7:

- Master idle (autoconnect on) – toggling at about 0.4 Hz (BTM222) or 0.5 Hz (BTM112)
- Master idle (autoconnect off) – fixed low
- Slave idle – toggling at 1.7 Hz (BTM222) or 4.6 Hz (BTM112)
- Connected – fixed high

Besides restoring the factory defaults (3 s press) PIO4 can also be used to reset/reboot the module with a short pulse. An even shorter pulse (6 ms) on PIO4 will cause a disconnect.

If you have any information not listed here, please let me know!

Wednesday, August 11, 2010

Forget about the hardware and learn C

Many people are afraid of 32-bit microcontrollers, or even 16-bit ones. Why? Because they have lots of pins? Lots of registers? If you are an 8-bit PIC assembly language programmer, why do you think it would be more difficult to program a 32-bit controller in assembler? Or is it that the more powerful controllers are meant to be programmed in C instead of assembler? Many people are afraid of C (let’s not even talk about C++). I have been programming in C for too long now to understand why you would be afraid of C, but I do know that it scares many 8-bit developers and newbie programmers.

This is a shame because new controllers nowadays always come with a free C-compiler. It may be limited in some way, but it is free and gets you started. Also, these new controllers come with evaluation kits that are cheaper and cheaper. The MSP-EXP430G2 kit from Texas Instruments for instance costs only $4.30 and includes two (2) 16-bit RISC processors, a PCB with programmer/debugger and a USB cable. Now that’s value for money. Or what about the STM8S-Discovery kit from STMicroelectronics. True, that is a kit for an 8-bit controller, but it costs less than $10 and includes a programmer and a breakaway controller board with capacitive touch sensor.



Hardware is becoming so cheap that it is becoming much like the paper you write on. Unless you’re an artist, you hardly ever care about your paper, the back of an envelope is often good enough. And it will be the same with hardware. You should no longer care about the platform you are working on as long as you can get your application to work. If you learn a language that is supported by all platforms, you can use whatever processor you like instantly and you’re application will be ready much sooner. The language is the pen, write your article and when it is ready send it off to the printer. They will then reproduce your design in the best and cheapest way. They may even decide to change the microcontroller, which is not a problem as your code was written to be portable.

Thursday, July 29, 2010

Add a smartphone to your application

One of the biggest hypes of the moment is of course (or should I say still?) the Apple iPhone. I do not have one, so I do not have an opinion about it, but it seems that many users are crazy about it. This is due to all the non-phone things you can do with it. Recently several electronics related apps have come to my attention but I have my doubts about the usefulness of those. Reading a datasheet on a smartphone? Usually when I need a datasheet I also have a proper computer nearby so why bother using a smartphone for that? I must be missing something here.

But now I heard about an electronics app for iPhone that seems pretty cool, even to me. It is more than an app as it needs a piece of hardware to function. Actually, it is the other way around: it is a piece of hardware that needs the iPhone app to function. Now that is not exactly right either as it is a piece of hardware that can be controlled by the app. Let me rephrase this properly: it is a small computer module that uses the iPhone as a display.

That’s right, the DIL/NetPC DNP/9265 from SSV is an embeddable ARM9-module (Atmel AT91SAM9263) with 32 MB flash and RAM. If you need more, just add an SD card. To connect the module to its environment 3 UARTs, an I2C, an SPI, a CAN, a USB Host interface and several GPIOs are available. Smartphone access is over a 10/100 Mbps Ethernet port. The board runs embedded Linux with extensions developed by SSV.



The smartphone app is developed as a web application using only established Web standards such as HTML, CSS, JavaScript and AJAX. The Apple iPhone SDK based on (proprietary) Objective-C is not needed, meaning that the app can also work on smartphones running Android. Furthermore, installing the app on the phone does not involve Apple’s App Store, but uses simply the on-board Web server. This of course makes life much easier.

An OEM integration kit including the DNP/9265 with lots of tools and documentation is available for application developers. An example application that visualizes system resources and that lets you play with configuration data is preloaded. Communication between the module and the phone is over a 2.4 GHz Wi-Fi connection. In case you didn’t have one already, a WLAN access point is included in the kit.

I can’t wait to get one of these kits for evaluation. Ho, wait a minute, I don’t have an iPhone…

Thursday, July 15, 2010

Microchip Application Library: GOL trouble

In a previous article I discussed the PIC32 Multi Media Board (MMB) from Mikroelektronika. Looking around a bit on the web searching for PIC32 related projects I came across the PIC32 Audio spectrum analyzer project by Andrei Mehiläinen. He used a PIC32MX360F512L on a TechToys PIC24 evaluation board (PIC24-Eval-Board, this board supports 100-pin PIC24 & PIC32) with an additional 320x240 TFT display board with resistive touchscreen and an SSD1928 graphics driver. Andrei’s system is very close to the MMB, the main differences are the processor (the MMB has a 460F512L), the graphics chip (an HX8347D on the MMB) and the way the pins are used. I therefore decided to port Andrei’s code to the MMB. This would be a good summer holiday project (being a nerd I always take a development system to the beach). This summer was going to be dedicated to PIC32 projects.

Studying Andrei’s code I soon felt the urge to improve it a bit, especially the user interface as Andrei’s system didn’t really have one. I first started drawing a grid based on MMB example code and then became serious about it by deciding to develop some generic user interface for measurement systems in the style of modern oscilloscopes. So I downloaded and installed the latest Microchip Applications Library (MAL) (v2010-04-28). Having never used them before, I also watched the web seminar about the GUI architecture of the graphics library. In the help files I found a tutorial explaining how to start a new graphics project and off I went.

In the beginning all went well, but when I wanted to add the library C-source files to the project I discovered that I was apparently not doing things the right way as the project would only accept assembler files. So I started all over again but this time using MPLAB’s Project Wizard and now I could go all the way up to trying to build the project. This is where things started to go really wrong: the tutorial code would not compile at all. Of course this was to be expected as the tutorial is for a PIC24 on an Explorer 16 board (yes it is, read the last sentence of the tutorial) and I had modified it a bit to use with a third party PIC32 board.

The first step to glory would be to get the Hardware Profile right. That was easy enough as I used one from the MMB example code. As mentioned before the MMB has an HX8347D (note the D) graphics chip and the Microchip library seems to support it (it knows the A and D version). It won’t compile however as brackets are missing all over the place (DeviceSelect/DeviceDeselect). Clearly this part of the graphics library was not tested properly before releasing it. I fixed this, but only to find out that I was now missing a definition somewhere and compilation would therefore still not complete. Comparing the new library to the (working) one that came with the MMB I noticed that the new library had some changes that required a definition that has something to do with GFX(E)PMP (now what is that again?). There are two possibilities that I tried both, and both gave me other (but different) errors. This is where I gave up (for the moment, I will continue since my holidays aren’t over yet).

Microchip has put a lot of effort in developing their Applications Library, but it is a shame that I am to dumb to use it. It would have been nice if they would have tested it better and if they had provided a working tutorial. Now I have wasted lots of time without getting anywhere. I now know the ins and outs of the graphics driver selection and other low-level GOL details, but I still haven’t been able to draw a single button. Surely it is all very easy, but why didn’t they explain it a bit better? Or maybe it only works properly on Microchip evaluation boards?

At the time of writing I have not figured it out yet, so if you know what I am doing wrong, please let me know. Also, if you happen to know where the API description is that is mentioned in the web seminar, drop me a line.

Thursday, June 3, 2010

PIC32 MultiMedia Board (MMB)

You may know MikroElektronika from their big development boards for PIC, AVR and ARM microcontrollers; you may even own one. I have one of those boards too, the EasyPIC4 that measures about 19 by 23 cm. This is pretty big and not something that you would use in a project. You can develop your project on it, but you have to build your own hardware if you want to actually use it in an application.

They also do some smaller boards. One particular interesting one is the PIC32 MultiMedia board (MMB) and I managed to get one to play with. For some reason the PIC32 does not get a lot of attention, but maybe this board will change that? It is about 9 by 12 cm and well thought out. On the solder side it has a 320x240 pixel TFT display with touch screen, a mini joystick, 6 LEDs and a temperature sensor. On the component side live all the other parts: the PIC32, the power supply and connectors. It has a power socket, a 9-pin RS-232 connector, an SD-card connector, a mini-USB male and a full-size USB host connector, a microphone input (mono) and a stereo headphones output. There is also an ICD programming port and there is room for an MRF24J40MA ZigBee module from Microchip. All the connectors are on the two sides (top & bottom) of the board, the left & right edges have each a row of holes for pin headers so that you can piggyback another board in case you need one.

When you power the board (with a USB cable f.i.), it does a slideshow of some nice photographs. That is all that it does, but it is pretty hypnotizing: butterfly, flower, tree, chameleon, city, oh… butterly again.

The CDROM labeled “software” does not contain development tools. It has a large amount of examples and documentation, but not only for this board, but for all the MirkoE boards. As I happen to have an ICD3 pod I decided to reprogram the board with the Mandelbrot demo. Loading the precompiled HEX file into the board was easy once the ICD3 pod was done reconfiguring itself. Manipulating the joystick now starts the Mandelbrot demo. With the joystick you can scroll in four directions and pushing it zooms in. It is reasonably fast.


Loading the example code in MPLAB was a bit more problematic as the example makes use of some libraries that were not where they were supposed to be. However, after a bit of relocating files I managed to compile the Mandelbrot demo.

The demo is actually a Microchip demo and a well informed source told me that the reason for this is that the board was originally designed by Microchip, but was outsourced to MikroElektronika due to a lack of resources at Microchip. I have seen a Microchip movie demo on this board, but I do not have the code yet.

There is also a test program on the CDROM. Loading this will light up all the LEDs and fiddling with the joystick you can skip, pass and fail certain tests.

More demos are available on the web page for this board. They let you play Rubik's cube or listen to Boney M and Freddy Mercury. BTW, make sure that the two jumpers behind the headphones socket are in the "UP" position, i.e. closest to de board edge, otherwise you will not hear anything. (See the manual if in doubt.)

One negative point: when I tried to insert the headphones with a jack of the right (3.5 mm) diameter in the headphones socket, the whole thing came off. Luckily it didn't cause any damage to the parts behind it, but it was clearly a case of bad joints. Before inserting anything, check the joints and resolder if necessary. This is probably also a good idea for the microphone socket.

I have tried most of the other demo's too and they are pretty nice. One demo showing off the Microchip graphics object layer gives a good impression of the possibilities of the graphics library.

Conclusion: if you want to give the PIC32 a go, this is definitely a good starting point. The board is reasonably priced ($150) and you could do some nice things with it. I do not really see why you would want to make an MP3 or MP4 player out of it, but transforming it into a DSO or a logic analyzer would sure be an interesting project. The touchscreen with the graphics library allows for very slick user interfaces.

Thursday, May 20, 2010

USB 2.0 drop-in for legacy DB9 RS232 connector

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.

Tuesday, May 4, 2010

Fast prototyping with mbed

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?

You can download the source code from here.