Open4 EvoPrimer

In the previous post I mentioned the Open World Design Contest launched by ST and others. The participants who make it into the second round will get free development tools, notably the EvoPrimer platform.

This platform is actually a very interesting set of tools developed by Raisonance under the name of Open4 (read as “Open for …”). The system is very open indeed and schematics and source code can be downloaded for free. A system consists of a base, a kind of multimeter-sized pod, and target boards that slide into the pod. The base offers the human interface like a color touch screen, a joystick, buttons, LEDs, audio I/O, IrDA, accelerometer and a li-ion battery with charger, the target board offers the applications.


Open 4 dissection...

Several target boards are available, with 8-bit and 32-bit processors from ST, but you can also develop your own. When you open the base you get access to a connector for extension cards that can slide through an opening under de joystick (if you remove the cover). This connector is the main way to go for those who want to add something to the system.

Software development is done with the Ride7 IDE, also from Raisonance, using GCC. The free version lets you compile and flash any size of code and debug executables of up to 32 KB. You have to pay for unlimited debugging. The IDE connects directly to the base through a USB port, without the need for additional programming or debugging pods. Ride7 also offers an ARM simulator.

Instead of writing all the GUI code yourself, you should (but you are not obliged to) built your application on CircleOS. It is not clear to me who the owner is of this OS, but the main thing is that it is free and open source software. CircleOS handles the display, the touch screen and all other hardware that is built in the EvoPrimer base. It also calls the user application on a regular basis and it lets the application interact with the OS to obtain button states etc. Applications are stored in a special memory area and there is room for several of them. The OS will allow the user to select the application from a menu. The application memory available depends on the target board you are using.


Ride7 is a nice IDE indeed!

Although Raisonance and their tools seem to concentrate on microcontrollers from ST, the Ride7 IDE can also be used for ARM-based controllers from other brands. It happily supports many NXP and TI (Luminary) models and if you look in the Ride7 installation folders you will find more supported processors than that the IDE lets you choose from. If you don’t like Eclipse (who does?) and if you don’t mind debugging the hard way, this is a very nice IDE for ARM development. My next Sceptre project will probably be done using this IDE.

Oh, did I mention the price of an EvoPrimer kit? About 100 euros for a base with target board!

CodeLite & GDB for ARM

Just after finishing the Elektor article about how to debug the Sceptre (or any other microcontroller that can be debugged over JTAG) using OpenOCD and GDB, I discovered another free IDE that seemed to be good for embedded development: CodeLite. It seemed to have everything needed for this kind of work, so I planned to add a supplement to the article on this blog. I thought that it would be easy to port the setup described in the article to this new IDE, but unfortunately it turned out to be not so. To come straight to the point: I have not succeeded debugging my target using CodeLite with GDB and OpenOCD.

Why? Because CodeLite does not treat GDB well or I am to dumb to figure it out. It seems easy & intuitive enough though. You create a project and then you define a debug setup for the project. You can tell CodeLite where your debugger lives and which commands to execute and CodeLite offers a GDB terminal, so everything is there to make it work. Except that it won't.

There are several issues. One is that it doesn't work always the same way. Sometimes I had to pass through the Quick Debug option to get it more or less going, sometimes this was not necessary. The reset command that I specified to be executed after attaching to the target gets executed several times instead of just once as if CodeLite uses a very short timeout to wait for response and then simply tries again. If it manages to get a connection to OpenOCD it is very difficult to use the GDB terminal that most of the times returns a message "interrupting debugee process: xxxx" where xxxx is a number that corresponds to the PC's process ID of GDB. Very frustrating and in the end I gave up, not succeeding once to execute successfully a step command.

It is a shame, because the IDE is nice. Not as heavy as Eclipse-CDT and easy to set up for embedded software development. It has interesting plugins, like the code formatting option that you can setup the way you like it, or a copyright block inserter. A snippet wizard lets you write quickly and you can hide functions that you don't want to see, it has everything you expect from a modern IDE. Therefore I suggest that you give it a try, maybe you don't care for GDB debugging of embedded platforms, it is definitely worth it.

If by any chance you figure out how to get GDB and OpenOCD working properly in CodeLite, please let me know.

Sceptre library update

The December issue of Elektor (now on sale) includes a 32-page supplement dedicated to microcontroller projects. In this supplement you will find two articles related to the Sceptre.

First of all there is a 4-page article about Oberon-07, a high-level PASCAL-like programming language, but object oriented. If you know MODULA-2 you will quickly find your marks, if you don't, well then it is pretty straightforward too. Oberon-07 has special features for microcontroller programming. It is f.i. very simple to manipulate bits and registers. Oberon-07 compiles very quickly in very efficient code. The Astrobe IDE makes things even easier thanks to its many libraries and comfy editing options. Serial comms, I2C, math & strings, and much more, it is all ready for you. Go check it out.

The second Sceptre article presents an extension card with a Nokia 6100 mobile phone color LCD, a Blackberry trackball and a 16 Mbit flash memory chip on it. All is controlled over an SPI bus, so the card doesn't use a lot of the Sceptre's I/O. Thanks to a nice open-source driver it is easily possible to display images at a framerate of more than 10 per second!

The fun thing of this card is that it doubles as a universal Arduino shield adapter for the Sceptre. A 16-bit I/O expander from Microchip together with some more Sceptre GPIO make the Sceptre compatible with an Arduino. You can now simply plug an Arduino shield on the Sceptre and use it. As there are many shields available, this unlocks a huge playground for Sceptre enthusiasts.

CAD (Eagle) files and software for this project are freely available together with a library update for the Sceptre. New functions (f.i. RFID), new examples (including a real MIDI file player!) and improved modules (better Bluetooth) make new applications easier. Go get your download here.

RFID made simple

More and more people are using the Sceptre ARM7 board from Elektor, which is good. The Sceptre is supported with an open source library in C and I am currently working on adding new functionality to it. As I wrote in a previous article I spent quite some time understanding the BTM222/112 Bluetooth modules and this will soon be included in the library.

I also received a request for RFID support and so I implemented a driver for the EM4095 transceiver (EM Microelectronic) that can read the tags you can buy for cheap on eBay (for instance).

To get me started I bought in Hong-Kong (through eBay of course) for 17.50 euros (shipping included!) a fully functional RFID proximity door entry access system with 10 tags and 5 badges. Only a week later the kit arrived.

This turned out to be a pretty nice product actually; its only downside is its cheap plastic housing that will probably not survive very long outdoors. Rain and intruders will not have a very hard time getting to the electronics.

Top side of PCB

Bottom side of PCB

The antenna is slightly larger than the PCB

Interesting about this unit is that it uses a "discrete" (well, sort of, compared to a single chip solution) radio, built around a 4069 and a 74393. I traced the circuit (see below), but I didn’t measure the capacitors (all SMD) except for C3 which has 2.2 nF (222J) printed on it. It seems hard to believe that this solution is cheaper than using a dedicated chip like the EM4095, but it probably is. Or maybe the design is older?



The processor is a W78E052DDG, a pretty standard 8051-clone by Nuvoton (formerly known as Winbond).

I only used the antenna from the kit (and of course the tags) for my experiments since I had the EM4095 chip on a break-out board and now that I am done, I am looking for an application for my "RFID proximity door entry access system". What about a cat door opener? Hmmm…

P.S. The RFID driver will be included in the Sceptre library. An update is scheduled with the December issue of Elektor (available half of Novembre). If you can't wait that long, just drop me a line.

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!

The InterSceptre is almost ready!

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.

The InterSceptre

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.

That’s all for now folks, I have a PCB to draw.

Accelerometers

Freescale announced this week their latest accelerometer MMA7660FC. This is a 3-axis digital output (I2C), very low power, low profile capacitive micro machined accelerometer featuring a low pass filter, compensation for 0g offset and gain errors, and conversion to 6-bit digital values at a user configurable output data rate. It offers low-power operation of 47 µA at 1 sample per second. The device can be used for sensor data changes, product orientation, and gesture detection through an interrupt pin.

Cool!

The product description ends with: "The device is housed in an extremely small 3 mm x 3 mm x 0.9 mm DFN package."

Bummer...

Elektor will present very soon its mobile 32-bit platform Sceptre which includes, amongst others, a 3D accelerometer from Freescale. For the Sceptre I have spent a lot of time looking for hand-solderable accelerometers but without success. Do easy to solder accelerometers actually exist? I guess not, but maybe someone will know of one and tell me about it. A more useful question is probably:

Do you have a technique for reliably soldering QFN or DFN packages by hand?

This question interests me very much, and, I am sure, many other people as well.

Here is a picture of the Sceptre that I sneaked out of the lab.
Hot, hot, hot!!!



This is one of the first three prototypes and it still works (one died during temperature testing). A second version that fixes some bugs and adds some improvements is on its way.

The accelerometer is the little black square in the left lower corner of the board (its a QFN unfortunately). On the top right is a Bluetooth module and if you look well enough you can see on the left an SD card sticking out from the bottom of the card. It runs from a mobile phone batterie and a charger for it is included on the board.

Stay tuned!

Freescale accelerometer MMA7660FC