ElektorEmbedded

KwikStik? KwikStuk!

2011-12-13T06:44:00.000-08:00

During a recent electronics show my attention was drawn by a strange small orange device on display at the Freescale booth. It turned out to be the Kinetis KwikStik and a very enthusiastic Freescale employee immediately showed me its features and explained that it was fully compatible with the Tower system, Freescale’s reconfigurable development platform, but it can also be used stand-alone. When I asked for a KwikStik to review, no problem, he would send me one after the show. Only five days later (including a weekend) I received the kit.

The KwikStik comes packed in a nice box and you can see that Freescale has spent some time and effort to deliver an attractive product. In the box you will find a KwikStik in its bizarre orange silicone jacket, a DVD, a USB cable and some instructions. Included also is a warranty card, the first one I get with a dev kit. If the kit is broken, you can send it back.

Looking closely at the KwikStik you may notice the logo of Pounce Consulting in several places. Looking up this company on the internet you will find an electronics outsourcing company that probably did this kit for Freescale.

The box promises “the fastest way to realize your design potential”. Now that got me interested as this seemed to be a great candidate for the MCU dev kit benchmark that I presented in a previous post.

When you open the booklet you will see two photographs of the board with arrows indicating its special features. There are many: an LCD, a microphone, a micro USB socket (two actually, the other is for the Segger J-Link connection), an audio output, a buzzer, six touch buttons, a micro SD socket, a battery, an IrDA port, a switch, extension connectors (one as a PCI-like edge connector), and, almost forgot to mention it, a Kinetis K40X256VLQ100 ARM Cortex-M4 MCU. This 100 MHz hot rod sports 512 KB Flash memory, 64 KB RAM and 4 KB EEPROM. A large range of integrated peripherals is available and since it is Cortex-M4 based, it also has an additional 32-bit integer DSP (which is completely ignored in the K40 Sub-Family Reference Manual).

On the next two pages of the booklet information is provided about the demo software preloaded on the kit and also step-by-step installation instructions. Step 1 is connecting the board to the PC to power it. Step 2 is navigating through the demo applications. Step 3: select an application, step 4 go to the Freescale web site. Strange. Nothing to install? I mean, what about the DVD? Next page of the booklet: J-Link and additional features. Last page: nothing.

Oh? OK. Well, let’s do step one: connect the board to the PC. Windows detects the board without any problems and I see the text “KWIKSTIK” scrolling from right to left, hear a beep and then see “LFT” followed by “RGT”, then “SEL.” (with dot) and finally scrolling again “SOUND RECORDER”. Pushing the touch pads is not very reliable and results in a kind of random behaviour, I don’t feel that I have any control over what is happening. So I remove the board from its silicon jacket and this makes things somewhat better. I can now navigate a bit easier, but it is still not very reliable.

The options available are Sound recorder, Remote control, USB mouse and Fretris. Trying the sound recorder I manage to record 2 seconds of data. The recording played back over headphones is barely audible and hidden by some loud interfering sound. I cannot try the remote control because I do not have a Sony TV. The USB mouse suddenly makes me understand the acronyms LFT, RGT & SEL. Why on earth didn’t they write it out? The display is large enough. Anyway, the USB mouse doesn’t work very well. Pressing LFT does random things on my PC like jumping to the left or selecting a block of text, the RGT pad opens the context menu. Actually LFT seems to do a double or triple left mouse button click; RGT does a mere single right mouse button click. Finally, Fretris is a simple Tetris game that is very hard to control as the touch pads do not work well.

The Kinetis KwikStik indicates all by itself its helloWorld score. It is even more severe than I am.

So, then, what’s on the DVD? Well, a flash animation that let’s you click some links to open documents or install software. Included on the DVD are Freescale’s MQX RTOS (free), IAR’s Embedded Workbench for ARM (30-day evaluation and a 32 KB limited kickstart edition), Green Hills’ Multi IDE and Keil’s MDK for Freescale Kinetis (32 KB limited edition). Other tools (Segger, CodeWarrior, etc.) are available on-line. Unfortunately, there are no instructions on what you should do next.

At random I pick Green Hills’ Multi IDE. Wrong choice. You have to unzip this, and then install 1 GB before getting tangled in a license request net. In the world of fastest ways to realize your design potential this is very bad and results in an immediate uninstall. Unfortunately there is no uninstall provided for this package, which makes it even worse. Let’s hope deleting the folder is enough to get rid of this stuff. Probably not, because a dongle driver was installed too.

[24 hours later: I am still waiting for an evaluation license from Green Hills.]

[Monday 19 December, a week later: I finally received a message from Green Hills about my licence request. More questions, but still no evaluation license. How intimate do you have to be with this company before they let you have a glance at their products? This sure takes the pace out of the fastest way to realize my design potential.]

Because I do not give up easily, I now try the IAR EW 32 KB kickstart edition. First, get a license by filling in a form and answering all kinds of questions. Contrary to Green Hills license delivery is immediate. Then install 2 GB of tools to discover that no examples are included for the KwikStik. I have now reached the point of saturation and give up.

After two hours of fiddling with the hardware, installing software and filling in license request forms I am still not able to flash an LED on the board. I haven’t even addressed the J-Link needed to program the board for which separate drivers have to be installed from some conveniently unspecified location. The fastest way to realize your design potential, yeah right. What a bummer. The KwikStik receives an helloWorld score of 1. You cannot get any lower than 1 because I will always give 1 to compensate for the time & effort to design, build and send me the kit.

It is really a shame to see how all the effort to design a nice and fun looking kit with an extremely powerful MCU is annihilated by a total lack of interest for the end user. Is it really that difficult to add a few lines of instructions to help the user on his way? Many hours went in the design of this board but apparently the budget was used when the DVD still had to be done.

Disclaimer
The reviewed board may be great once you get the tools set-up correctly, but being an impatient person I did not manage to get that far. I have other things to do too.

A benchmark for development and evaluation kits

2011-11-28T06:18:00.000-08:00

The other day a colleague asked me if I was interested in reviewing the TMS570 MCU Development Kit. This is a kit for playing with the TMS570LS20216 ARM Cortex-R4F microcontroller and when I looked at the picture of the kit available on the product page on TI web site I immediately became interested. It is a big main board with a TFT display and many connectors on which a smaller board sits. The TMS570 microcontroller is designed for use in safety critical systems and as such it includes [quote TI website] dual CPUs in lockstep, CPU and Memory Built-In Self Test (BIST) logic, ECC on both the Flash and the data SRAM, parity on peripheral memories, and loop back capability on peripheral I/O. The Floating Point CPU offers 1.6 DMIPS/MHz, and it has configurations which can run up to 160 MHz providing more than 250 DMIPS. [quote end] The TMS570LS20216 has 2 MB Flash memory and 160 KB SRAM. One might be tempted to say that this is a pretty powerful MCU.

When the kit to review arrived it turned out to be not exactly what I expected, as it was just a large USB stick. The stick is so large because otherwise the MCU in its 144LQFP package wouldn’t fit on it. It came in one of those CD/DVD boxes that we know from TI and that included besides the stick a little flash light, a DVD, a USB extension cable and a flyer with installation instructions. The installation instructions are simple: insert the DVD and do a full install. So I did.

I wrote down the amount of free disk space before launching the install and the time: 9h20. More than 30 minutes and 95 (really!) mouse clicks later the installation was complete. Looking at the free disk space left over I noticed that this demo had used a whopping 7 GB! As a comparison, my Windows XP Pro folder contains 9 GB. To be totally honest, I did this installation twice, the first time I just ran it while trying to do other things. But when the number of mouse clicks and the amazing amount of pop-up windows started bugging me I decided to redo the installation and count and measure the above mentioned parameters.

Naturally I now was pressed to see the demo's, curious to discover what a USB stick with only a few LEDs and a 5 square cm MCU on it supported by 7 GB of software had to offer. Connecting the stick to my PC worked fine, it was recognized immediately, and I started the Safety Demo Software as indicated in step 3 of the installation notes. A window with six large buttons came up and I clicked on the left upper one labelled “Safety Features”. The tool now first programmed the MCU before showing a block diagram of the chip and a list of small buttons on the left that let you generate an error event in the MCU. The error is graphically illustrated in the block diagram and a little red LED is lighted on the board.

You will have little trouble to understand that I was deeply impressed by this convincing demo so I quickly went on to try the others. I clicked the Ambient Light button and a little window with a vertical bar graph showing ambient light intensity came up. A light sensor included on the stick makes this demo possible. If you keep your hand over the stick the bar drops to a few percent and when you shine the flash light on the sensor you can get it up to 100%.

Again, Wow.

So quickly on to the next demo: the Temperature Sensor. Clicking the button opens a small window showing a graph of the temperature. According to the demo the temperature was over 30 degrees Celsius, at least 7 degrees higher than the ambient temperature, but maybe it measured closely to the MCU or the PC? Anyway, this demo was as convincing as the others.

What about the LED Light Show? Again a little window pops up and this time you can start the preprogrammed light show or toggle the six blue LEDs manually. To not spoil the surprise in case you want to buy this development stick yourself I will not tell you what happened but I can assure you that I was again deeply impressed.

If I remember correctly TI was the first to introduce the concept of USB development and evaluation sticks, but where the first one featured an MSP430 MCU that you could break off after programming and then use in your own application, this USB stick seems to be a pure product of marketing. Only 22 of the 144 pins (called “test points”) are brought out to two pin headers although a CAN bus is available too. You get a compiler too, so you can write some code for the MCU but do you really need 7 GB and 95+ mouse clicks for that?

Let us now define a benchmark for MCU development / evaluation kits so we can quickly compare the ease of use and system impact of those kits: the helloWorld (hW). The helloWorld is calculated as mds/(ds*(mc+i)) where “mds” is the highest capacity hard disk available in the year of release of the dev kit (see Wikipedia, in 2011 msb = 4 TB), “ds” stands for disk space needed by the dev kit and mc means mouse clicks needed to get an LED flashing on the dev kit and finally “i” is the number of icons & short-cuts created on the desktop (8 for this kit). With such a benchmark the flash light included in the kit would get a score of infinity because it does not occupy any disk space. The mds parameter is included to introduce an element of time in the benchmark so that it would be possible to compare helloWorld benchmarks over time. You might argue that including Eclipse in a dev kit should be a separate parameter pulling the score down, but Eclipse in itself consumes enough disk space to ensure a low benchmark anyway.

The TMS570 Microcontroller Development Stick presented here scores a value of 4 TB / 7 GB x (95 mouse clicks + 8 icons) = 5.68 helloWorld [hW].

If you have any suggestions of benchmark scores for other dev and or eval (evil?) kits, please do not hesitate to send them to me so I can publish them here.

Reverse engineering? The new Wiring S board

2011-10-27T06:55:00.000-07:00

In the fall of 2008 I started researching Arduino for an introductory article for Elektor. In that article I wrote that Arduino can be seen as a simplification of Wiring. The Arduino environment is very much like Wiring but slightly simplified and the Arduino Diecimila, the board of choice in 2008, was much simpler than the Wiring microcontroller board that had more I/O ports available. It is difficult to prove that the huge success of Arduino is due to this simplification, but the fact is that the current estimate is that more than 300,000 Arduino boards have been sold world-wide, which is pretty impressive.

The people behind Wiring must have been a bit jealous of this success achieved by others with their work so they started simplifying too. The result is the brand new Wiring S board that is almost the same size as an Arduino Uno. The Wiring S team apparently decided that they wanted to do things slightly different than the Arduino team, so the board looks a lot like an Arduino, but it is not compatible. Where Arduino uses mostly ATmegaXX8 controllers, the Wiring S board is based on an ATmegaXX4 controller (ATmega644 on my 1.0 board). The connectors look very similar, and are positioned in a similar way, but there are 5 instead of 4 and the pin-out is different. Also the project is open hardware, but the design files are in KiCAD instead of Eagle.

Seeeduino (left) and Wiring S (right)

It is rather interesting to see how Arduino is becoming more and more complex with programmable USB interface chips, all kinds of different processors and more connectors whereas the Wiring S board is almost like an old Arduino Diecimila but with a bigger processor. The board even offers the possibility to replace the FTDI USB/serial converter chip by an FTDI cable which brings it very close to the even older Arduino Serial. The two teams seem to be working in opposite directions.

For the people who would like to have the best of both worlds, they should use Wiring because the Wiring environment is capable of handling Arduino boards, whereas the Arduino environment does not handle Wiring boards and a Wring Play Shield is available that allows you to stick Arduino shields on the Wiring S board.

The Wiring S board is simply rectangular with its extension connectors on a 0,1” grid and 4 mounting holes placed in a logical manner. I do not like the position or the shape of the reset button; it is too hard & difficult to press. The solder side of my board was not cleansed properly and this seemed to be true for the whole batch received by my distributor. Maybe this is a pre-series problem?

Retro yellow LEDs!

Will the Wiring S meet with the same success as Arduino? Hard to say, I guess not, it is probably too late now.

RS Components presents new website

2011-09-30T06:04:00.000-07:00

If you design your own electronics circuits you have to select the best parts for your design. This can be very time consuming especially if you do not know where to look for them. For me problem parts are electromechanical parts, connectors, push-buttons, that sort of thing. What I do in those cases is look through a component distributor catalog and see if I can find something to my likes. Unfortunately these catalogs no longer reflect very well the full offering of the distributor’s products as they prefer to present them on-line.

On-line component browsing on a distributor site just is not very practical. When Digikey decided to stop distributing their paper catalog we did a little reader’s survey of which the outcome was unanimous: No!!!
If you do a search on a part you will get many useless results, but you will also miss many because the search engine didn’t find them. Typical is the table refinement option where you can tick the specifications you want. You cannot simply tick one because often the same specification is listed several times with different wording so you have to tick ‘em all. Also ticking an option will remove the parts for which this particular parameter was not specified in the first place. “Number of ways” or “polarity” can mean the same thing for a switch, but the filter only knows one of them. Voltage regulators are one example of hard to select parts. Input voltage range, output voltage range, type, etc. all parameters that can be (and are) specified in different ways making them difficult to compare.

RS Components just launched their new improved website where they put a lot of effort in improving the search engine. They told me that they now remove much more irrelevant results and they return harder to find results, but they didn’t say anything about addressing the issue of parameter homogeneity.

So is it any better now? Let’s try to pick a low-dropout voltage regulator. The RS website returns 58 results (September 30, 2011, 14:00 h CET). Filtering on “Input Voltage” only shows 19 possibilities; strange, what happened to the other 39 parts? They have no specified input voltage? I find that hard to believe for a voltage regulator.

There are three parts with an input voltage range from -1 to 40V that turn out to be three versions of the same device (UC3836/2836 from TI). There is only one device with a range of 3.5 to 36V (LTC1624 from Linear Technology) but it is not the same as the TI one although the input voltage range is inside the -1 to 40V range, so the TI part would be an option too.

The filter proposes four devices with an input voltage of 40V without a minimum value. The result is again four similar devices, again from TI, but this time the UC3834/2834. Looking up the device on the TI website I discover that TI specifies an input voltage range of 5 to 35V for this device, not 40V. So what do they specify for the UC3836 on its product page? 6 to 40V! Eh? But RS said -1 to 40V, right? Yes, but actually that is the absolute maximum range. Duh! In that case, why didn’t they use -0.3 to 36V for the LTC1624? Pears and apples, that’s what this is.

Now you may think that I spend a day or so on finding this example, but no, I didn’t. I found it while typing up this post. It was that easy, meaning that it is the same for other parts. It is still very hard to use a distributor’s website for selecting parts for a design. The new RS site does look slicker and maybe the search engine is better, but I am not sure if I will notice the difference.

BTW, did I mention that the filter button doesn’t work in Firefox? I suppose (for now) that’s just my Firefox being incorrectly set up.

Open World Forum 2011

2011-09-30T04:15:00.000-07:00

Saturday 24 September I joined two of my colleagues at the Experiment Day of the Open World Forum in Paris. Since it took place not far from the Crazy Horse I had no difficulties in finding the venue. My colleagues had come the day before by car because they had to bring books and magazines and especially the OSPV1, our open-source auto-balancing two-wheeled vehicle that we were to present.

The OSPV1 self balancing vehicle

The Forum was held in a rather high-class venue that had been paid for by a very impressive collection of sponsors in one of those rich “quartiers” of Paris where you get more easily run over by a Ferrari then by a Peugeot. The Open World Forum is all about Open Source; here the first question people ask you about a product is what license it is released under. I tend to associate Open Source with financially impaired people (i.e. students) with beards and spectacles hacking away in poorly furnished rooms and so it seems strange to actually meet these people (who came indeed pretty close to how I always had imagined them) in such a high-end place. Free lunch & drinks for everybody, all you can eat sushi in the pressroom, a real “we don’t care about money we only care about Open Source” attitude.

The ambiance was quite arty and inspiring with many great projects being showed off. It was interesting to meet so many people working with electronics without having a formal electronics education. They simply define an objective and then see what they can do with plug ‘n’ play electronics like Arduino to achieve it. These are electronics users (or should I say consumers) that embed ready-made building blocks in their projects.

I was a bit disappointed by the number of visitors. For some reason too few interested people made it on this sunny day to avenue George V. Maybe they didn’t have the money for a metro ticket? Make sure you visit next time, it is definitely worth skipping a lunch to save some money to pay for the trip.

Everything you always wanted to know about klystrons and traveling wave tubes (but were afraid to ask)

2011-08-26T03:43:00.000-07:00

Most of the time this blog is about embedded electronics, but if I come across something interesting that is electronic but not directly related I will talk about it here too. Therefore, this time I will write about a book with the impressive title: Klystrons, Traveling Wave Tubes, Magnetrons, Crossed-Field Amplifiers, and Gyrotrons It is written by A.S. Gilmour, Jr. of the State University of New York, Buffalo and the book is edited by Artech House. The editor presents it as: The culmination of the author’s 50 years of industry experience, this authoritative resource offers engineers a thorough understanding of the operations and major classes of microwave tubes.

This field of electronics definitely has the coolest named devices of the industry and I sure would like to use a gyro-twystron once in my life, just so that I can say I did. Controlled by an Arduino maybe? Anyway, I’ve read this book and found it, to my surprise, quite fascinating. 800 pages about electron guns, exotic materials to make cathodes with, magnetic and electric fields and incredible amounts of power, actually this book is more about physics than about electronics. What I really liked about it was the mix of well established theory and experimental physics. The author does a pretty good job, as far as I can judge, at relating the complete history of magnetrons and the like. From the initial idea to the many tweaks that took the devices to where they are now, everything is described and it all feels very hands-on and experimental.

For the people that have to really study this material the book contains a wealth of drawings, diagrams, formulas and equations with derivations. I don’t think you will be able to actually construct a working megawatt gyrotron just by reading this book, it lacks the electronics, but it definitely will get you started. If you don’t care for the math, you can skip it all. Since the book introduces many terms the reader may be unfamiliar with it includes a glossary at the end. Your knowledge of vacuum pumps is a bit rusty? Read appendix B on vacuum technology. Appendix C gets you up to speed with magnetics.

I have only one negative comment about this book: the illustration the text is talking about is almost always on the back side of the page you are reading. Since there are many drawings you keep flipping back and forth between the drawing and its description.

This book does not introduce new theory but it is bound to become a standard reference for the serious high-power RF/radar engineer who has always a klystron lying around on his desk.

Wireless audio over 2.4 GHz

2011-08-16T08:35:00.000-07:00

Just before the summer my contact at Texas Instruments had the excellent idea to sent me a CC85XXDK-HEADSET development kit. This is a PurePath Wireless Headset Development Kit to evaluate the new wireless audio products from TI based on the CC85xx family of RF micro-controllers. Due to a lack of time I didn't have the opportunity to write about it earlier, but I did give it a try and was impressed.

The kit contains two identical cards, one of which is configured as a master, the other as a slave. Both contain a 2.4 GHz radio and once paired (a simple operation) you can stream high quality stereo audio from the master to the slave. This works exceptionally well according to my non audiophile ears. The cards are each powered from one 1.72 Wh rechargeable li-ion battery, so it is a totally portable system. Charging the batteries is done by hooking the boards up to a USB port. TI claims a continues operation of 22 hours for this system.

I gave it a try in my garden and managed a Line of sight (LOS) distance of some 45+ meters (then I ran out of garden). It will probably go a bit further when the master is higher up from the ground. Occasionally the receiver has drop-outs, then it suddenly goes from full quality audio to complete silence, but this happens only at greater distances or when the data path becomes obstructed. Never did I hear any garbage out of the headphones.

Included in the kit is a little CC Debugger pod (with a funny rubbery feel) that you can use to reprogram the boards. This pod lets you reprogram and configure the boards using a tool called PurePath Wireless Configurator. The purpose of this tool is a bit unclear to me as there doesn't seem to be a whole lot that you can configure, but it is probably useful when you develop your own systems.

If you need a high quality wireless audio link in your system, the CC85xx is definitely worth a look!

Chasing tornadoes

2011-08-04T09:06:00.000-07:00

This is my last post live from NIWeek 2011, my plane leaves in a few hours and the show is finished now anyway. Looking back I had a good show with many interesting and exciting! encounters, technical as well as human. Look, I even made a friend.

He is great because he plays soccer and he is as good at it as I am. I bet he dances like me too.

Today was the last keynote during which several impressive student projects were presented including the world-wide winning (www) project in the student project competition. This was a 3D display that you can actually build at home thanks to its extraordinary simplicity.

The keynote ended with a presentation by Tim Samaras who chases tornadoes for a living. Tim showed some very spectacular footage of tornadoes but also of lightning, because that is his second hobby. He and his team film lightning with very high-speed cameras so that you can actually see how the lightning makes its way down to earth. Wow.

With a bit of luck I will be back here in Austin, Texas next year. If so, maybe see you then or there!

LabVIEW, Arduino & Android

2011-08-03T20:10:00.000-07:00

During lunch today I picked up the words LabVIEW and Arduino. Now that got me interested (or excited, as they would say here) and it turned out that a technical session about hacking Arduino with LabVIEW would take place later in the afternoon. So I attended and learned some very interesting things indeed.

First of all that it was not only about Arduino. To be totally honest, Arduino was a bit of a minor topic, the more important topics concerned interfacing to the Kinect, the Wiimote, iRobot, Neato and Android systems. Nevertheless they did do Arduino too. NI uses interns to develop all sorts of fun applications with their products. Waterloo Labs - who earned their fifteen minutes of fame about a year ago when they drove a car using an iPhone and posted a video about it on YouTube - is in it too.

So how do you interface Arduino to LabVIEW? It is pretty simple. You load Arduino with a special sketch to create an I/O server. Then in LabVIEW you install some VIs for Arduino. You should also install the NI-VISA serial port drivers if you don't have them allready. That's about it. And the great thing about this is that it is all free and open source!

Let's be clear about this, you cannot create a program in LabVIEW and then run it on the Arduino. In this setup Arduino is merely an input/output device, but a very cheap and hackable one for which many shields are available and you can use all the power of LabVIEW to control it or process the data. And if you replace the serial cable by a wireless link (Bluetooth f.i.), it is almost if Arduino is running stand alone.

This is all excellent news, because now you too can interface your project to LabVIEW as long as it has a serial port. All you have to do is port the sketch to your hardware and adapt the VI.

All this stuff and much more, like how to hack the Kinect or the Wiimote, is on LabVIEW hacker dot com

25 years of LabVIEW

2011-08-03T11:49:00.000-07:00

The second day of NIWeek started with the second keynote presentation. Jeff Kodosky, the father of LabVIEW, opened the session during which he looked back on 25 years of LabVIEW.

Jeff K was followed by the part that I like most of the NI events: the user applications. Often a few interesting and sometimes quite spectacular real-life applications of NI equipment are presented and demonstrated. This year were on display a portable real-time optical coherence tomography (OCT) device, a structure health monitoring system that is being used for real-time bridge surveillance, the smart grid in Rajasthan, India (did you know that 400 million people in India do not have access to electricity?), a system to control the plasma position in a tokamak (we are talking nuclear fusion here), a couple of robots, an XBox Kinect interface for LabVIEW and a water display that uses water drops as pixels (see photo, can you see "NI" written in droplets?).

The company who made this told me that they have no practical use for such a display.

The keynotes closed with some philosophing about how LabVIEW may evolve during the next 25 years. According to Xilinx, their new Zync platform will play a role here in the near future.

That's all for now folks, I am going to attend a presentation about Arduino, Android & LabVIEW.

P.S. Thanks Greg, I received your text.

Geek power

2011-08-02T21:11:00.000-07:00

After a long day of presentations, interviews and normal editorial work (if you think I am on holidays, you are mistaken. BTW, Greg, I need your article.) tonight was the night of National Instrument's Graphical System Design Achievement Awards. This is a yearly invitation-only event for which you are supposed to dress up, which I did, sort of. NI offers awards in eight categories for the best applications using NI products. There are, in my opinion, three interesting things about this event.

The first is the presentation with as main attraction Dave Wilson, the companies director of academic and corporate marketing who, in about one hour, manages to use as many words as I use in an average week.

The second thing is the exoticness of the project subjects. From non-invasive cancer diagnostic to bridge structure testing to quantum mechanics, the geekier the better seems to be the devise.

Finally, it is the international character of the project that amazes me. The projects are literally sent in from all over the world and no part of the world seems to be favorized.

The winner of the grand prize, an entry in NI's hall of fame, was this year the paper "FPGA-Based Feedback Control of a Single Atom Trajectory". You can find it on NI's web site.

To improve your chances to win next year make sure to use at least a Kalman filter, a couple of Hall effect sensors and PWM in your system. Dave will love it!

Graphical system design

2011-08-02T11:26:00.000-07:00

This morning NIWeek really started with the first keynote introduced, as always, by Dr. T. himself (one of the three cofounders of NI). The keynotes are rather impressive events with an audience of several thousands. It is used to introduce the most important new products for the year to come. Demos have been very carefully prepared and are presented by the people who were actually involved in the development of the product, which I think is good.

I was a bit disappointed by today's keynote. It was less spectacular than last year and I found Dr. T's introduction not very inspired. The main theme to retain is NI's objective to use software to solve problems so that the client can profit from Moore's law. This was illustrated by some demos of very high performance instruments.

The fun part of the presentation was a variation of the game Angry Birds coded in LabVIEW. In Angry Eagles (as it is called) the player launches the bird with a real catapult instead of a virtual one.

Oh yeah, I almost forgot, LabVIEW 2011 was announced.

Getting ready for tomorrow

2011-08-01T17:28:00.000-07:00

OK, the first day of NIWeek, or to be more precise, of pre-NIWeek just came to an end with the Kick-off Happy Hour. Before that I attended the Exclusive Show Floor Preview. This tour took the international press - except for the Chinese/Japanese who had their own group - along the major attractions of mainly NI. Since I was also present at NIWeek 2010, I was able to separate the upgrades and evolutions from the real novelties. Of course, the really spectacular demos will only start tomorrow during the keynotes of the Grand Opening.

I will talk more about interesting applications and products in the days to come when I will have more time to talk to the people presenting them. Yet I would like to mention one of the most impressive things on display: the Hermes Spacecraft. This is a project a guy started alone in his garage, now he is being helped by engineers from Intel who have too much spare time on their hands. The goal is nothing less than commercial space travel!

Check out Sensational Susan online.

USRP update: as it turns out, the USRP-2920 is not 100% identical to the USRP N210, but I did not yet have the opportunity to find out what the differences are exactly.

SDR soon playing at a university near you

2011-08-01T12:29:00.000-07:00

Two years ago I assisted at a meeting at Elektor during which Software Defined Radio (SDR), GNU radio and its hardware platform the Universal Software Radio Peripheral (USRP) were discussed. The GNU radio people were really convincing and I liked the concept, but since then I didn't hear much of it. One of the reasons, I thought, was that the USRP (version 2 at the time) was quite an expensive platform.

During the visit of the University of Texas (UT) this morning a wireless class was presented that was based on SDR. The hardware platform was a PXI from National Instruments and the programming was done, of course, in LabVIEW. The goal of the course is to familiarise students with wireless concepts and instead of treating the subject only in a theoretical way, the UT decided to use an SDR hardware platform so that students can easily implement and try out the concepts in the real world. An excellent concept if you ask me.

Instead of keeping it a UT-only course they went a step further and developed an educational package that other schools and universities can buy from the UT. This package includes two now-where-did-I-see-you-before? USRPs (on the left in the photo). Actually, the USRP is now an NI product because NI bought Ettus Research in February 2010. I am afraid this will not really help to lower the price of the USRP.

I don't know if there is a difference between the USRP N210 that you can buy from Ettus and which looks identical to the USRP-2920 from NI, but maybe I can find that out this afternoon during the special USRP session?

In Texas everything is bigger

2011-08-01T05:51:00.000-07:00

After having spent the sunday to get used to the what they allready call here the hottest summer ever (over 40 degrees Celsius for more than 50 days) today I will start attending NIWeek 2011. The show opens in less than one hour, but since it is just across the street I just have time to open the blog now.

My day will begin with a visit of the University of Texas (UT), the largest university of the USA as they say here in Austin with some 80,000 students. However, according to the internet, the UT is only the fifth university of the USA with just over 50,000 students. "In Texas everything is bigger" is another thing they like to say here. Apparently this holds true for claims too.

Stay tuned as there will be more to come.

Smart phone, stupid protection

2011-07-30T22:30:00.000-07:00

This morning (29/7) I took off from Schiphol (Amsterdam airport) for Austin, Texas to assist at the 17th NIWeek. During the flight I kept my phone switched off in a pocket of my pants. Now, when my phone is switched off the key lock function does not work because it is a function of the operating system of the phone, not a hardware feature. So, without me noticing, my phone got switched on in my pocket while I was looking out of the window (I had a window seat) and apparently I unknowingly sort of "punched" in (with my thigh or handkerchief) several wrong PIN codes which resulted in a blocked SIM card when I took my phone out again in Houston (where I had to change planes). To unblock the PIN code my phone now first wanted a Personal Unblocking Code (PUK) code, which off course I didn't know. A helpful girl in a phone shop on the airport told me that this code is often printed on the SIM card itself. So I examined my SIM card and indeed discovered a 17-digit code of which the first 8 digits turned out to be the PUK code for my SIM card. Great!

Or is it? Thanks to the missing hardware key lock feature my SIM card got blocked, but thanks to the PUK code conveniently printed on my SIM card, I can unblock it again. And if I can do this, anyone who gets hold of my phone can do this. How's that for anti-theft protection?

So, problem solved? Well... no. Entering the PUK code gave me the right to choose a new PIN code that I had to confirm by typing it again, which I did without errors. 1234 is not so difficult to get right, right? Wrong! According to my phone my new PIN code is incorrect (???) and I am back to the PUK code. I would now be stuck in an endless loop if it weren't for the cleverly built-in hang protection (they did think of that): the number of tries is limited to 8. I still have 3 left...

Tomorrow I will buy a prepaid local SIM card.

Vanity chips

2011-07-20T13:30:00.000-07:00

Have you ever heard of the company Valens Semiconductor? I hadn't either, until last night.

In 2009 Valens Semiconductor together with LG, Samsung and Sony announced their intention to launch a cross-industry alliance to promote and standardize the HDBaseT technology for whole-home distribution of uncompressed HD multimedia content. A few days later Valens announced the availability of an HDBaseT-compliant chipset: the VS100, consisting of the VS100TX transmitter and the VS100RX (receiver). This chipset enables the convergence of uncompressed full HD digital video, audio, 100BaseT Ethernet, power and control through a single, standard 100m/328ft LAN cable.
(I got this from their website)

To me this sounds like an interesting chipset (although a bit out of my league) for more than one reason. One of those reasons is the printing on the chip. Why?

Well, you may not know it, but my name is Valens. Before the era of internet my family and me knew of very few other people named Valens. There was of course Richie Valens, but that is not his real name, and there were some roman emperors named Valens (I have a coin to prove it). Now that the world population is massively coming on line more and more people and companies named Valens surface.

If you are an electronics engineer and your name happens to be National, Renesas or Avago you can easily find chips with your name on it, but for most other people such an opportunity is pretty rare. And I just came across one!

I want this chipset. Not for building something with it, but to keep on my desk. I want a vanity chip(set). Of course I have contacted the company and asked for a sample. If I get hold of one of these chips I will of course post it here.

Control a robot with a watch

2011-07-06T08:36:00.000-07:00

Some six months ago Texas Instruments announced the Evalbot, a development platform for their Stellaris ARM Cortex-M3 microcontrollers in the shape of a little robot. It took me a while to get hold of one, but now I have one driving happily around in my living room. It is actually a pretty neat and cleverly engineered kit that you have to assemble yourself. Most parts are made out of PCB material – the two wheels for instance are each made of three disks and a rubber ring – the rest are mainly nuts & bolts. Two little motors with gears drive the wheels and everything is powered from three AA batteries.

The Evalbot is not a gadget; it is a powerful development board with wheels. In the center off the disk-shaped board sits an LM3S9B92 ARM Cortex-M3 controller (256 KB flash, 96 KB RAM and more peripherals than you will probably ever need) assisted by a tiny 96 x 16 blue OLED display, 6 push-buttons (including the on/reset and the off buttons), an Ethernet connector, a USB host port, a USB device port, a USB debugger/programmer port (ICDI), a micro-SD card connector, a speaker, power supply, JTAG, two LEDs and probably more that I am overlooking now; and two motor drivers. Thanks to the battery holders (with batteries) on the bottom of the board the whole thing is pretty heavy and the rubber “tires” prevent sliding it off your desk when you hook the board up to a computer with a USB cable that wants to unwind the wrong way around.

A special wireless expansion port is available too on which you can plug a CC1101EM sub-1 GHz transceiver, which will get you an 868 or 915 MHz radio link. The James Bond part of this setup is a third kit from TI, the eZ430-Chronos based on the CC430F6137 sub-1 GHz RF SoC. This is a combination of a biggish but stylish black watch with a large character display and a USB access point for your PC. Once connected you can control your PC with the watch, although it takes some exercise to do it properly. But... you can also use the watch to control the Evalbot! An integrated accelerometer lets you influence the driving direction of the robot by tilting and rotating the watch. Cool huh? The watch in itself is actually a dev kit and you can reprogram it with your own application.

Programming the dev kits is done with Code Composer Studio 4, the Eclipse-based dev environment from TI. A license file is included with the Evalbot kit, but what exactly this enables is not clear to me. I did read something somewhere about code sizes & limits, but I forgot where. Anyway, all the source code for the Chronos controlled Evalbot is available, it compiles without warnings and errors and programs fine. This really is a fine (but strange) development kit.

Intelligent simple peripherals

2011-05-19T05:49:00.000-07:00

This week I once again wrote an interrupt service routine for a UART to do some serial communication. Actually I didn’t have to write a whole lot, because the receiver part had already been done by someone else, but the code for transmitting data under interrupt control was missing. I already had this code in another project and porting it was easy and quick, but then I started thinking.

Like me, probably thousands of programmers all over the world are doing this every day, which is a waste of time and resources. Of course we all try to reuse code as much as possible, but with micro-controllers getting more and more advanced, why don’t the silicon vendors simply implement the driver in the peripheral, in silicon? I mean, how many people do use the UART for other things than simply sending and receiving data? OK, we see more and more 16550 compatible UARTs, so drivers are easily found, but then again, why not put it in a ROM for the programmer’s convenience? All it has to do is to read data from a buffer and write data to it, all under interrupt control of course. An intelligent peripheral like that would save some code space, but most importantly, it would save lots of programmer’s time.

Such an intelligent peripheral would have a pretty simple interface: some registers to set up circular rx & tx buffers and the communication parameters, registers to read/write a block of data and some status registers to check for errors. The user only has to supply a block of RAM for the buffers. This is what most of us implement in our code anyway. For backward compatibility they should keep the traditional interface too, that way everything is possible.

Similar peripherals for other protocols could be integrated as well, like I2C or SPI.

The typical ISR for I2C is rather complicated and big, and is therefore prone to many bugs. Many software developers are struggling to get it working properly, so it would be a great service to them if the driver was already in the chip. I am not pleading for a full blown on-chip operating system, but some simple drivers that will take care of the most common tasks sure would be nice.

So you silicon vendors reading this please do give it a thought. I appreciate the integrated USB drivers, but don’t stop there. Why don’t you make things even better by adding hardcoded drivers for “simple” peripherals too?

FRAM - true unified memory

2011-05-04T08:52:00.000-07:00

Somewhere in the beginning of 2007 I won in a lottery held by EPN magazine an evaluation board from Ramtron sporting their most powerful 8051 clone, the VRS51L3074, which could be programmed and debugged with a small USB piggyback board. The very special thing of the Ramtron controller was the 8 KB of non-volatile ferroelectric memory (F-RAM) it included.
Instead of putting the board in a box, I actually used it in a project. I used the F-RAM to store some parameters in. The evaluation board also had several other F-RAM chips on it, but I did not use those. Once the project finished (it was published in the January 2009 issue of Circuit Cellar) I (almost) forgot about F-RAM and never heard from Ramtron again.

This year at the Embedded World show in Nuremberg I again came across F-RAM, now spelled FRAM, at the Fujitsu stand. It turned out that they started licensing the technology from Ramtron and that they had put some of it in their MB95R family of 8-bit MCUs. Fujitsu also offers stand-alone FRAM devices up to 4 Mbit.

This week Texas Instruments announced their brand-new MSP430FR57xx family that includes up to 16 KB of FRAM, licensed at the same source. The people at TI are very excited about it and have high expectations for the future.

So what exactly is FRAM and why would you be excited about it?

The F in FRAM stands for ferroelectric (and not ferromagnetic nor Fujitsu) because it “uses ferroelectric film as a capacitor for storing data. Possessing characteristics of both ROM and RAM devices, FRAM features high speed access, high endurance in write mode, low power consumption, non-volatility, and excellent tamper resistance.” (Source: Fujitsu)
How it all works at the atomic level is not so important here, let’s jump to the bits interesting for people wanting to use FRAM in a design.

First there is speed. Compared to flash memory FRAM is way faster, TI claims a 100 times faster. According to Fujitsu, FRAM is 30,000 times faster than EEPROM.
Secondly, there is power consumption. FRAM uses very little power, 250 (TI) to 400 (Fujitsu) times less than flash or EEPROM. This is active power. Interestingly enough FRAM has a slightly higher leakage current than flash memory, so power consumption in sleep mode is slightly worse.
Less energy and higher speed means cost savings, not only on the power budget, but also on the production budget for the high-volume people that measure the time it takes to program a device on the production line.

Then there is endurance. Flash & EEPROM memory cells are specified for some 10,000 write cycles, whereas a FRAM memory cell can be rewritten more than a trillion times! (Fujitsu is a bit conservative here, TI rather optimistic.) This kind of endurance combined with the higher speed means that FRAM can be used in place of SRAM.

FRAM works with low programming voltages down to 1.5 V. Replacing a block of flash memory by a block of FRAM of the same density then saves die space because FRAM doesn’t need a charge pump. Smaller means cheaper. Also, because of the low programming voltage new applications become possible where the higher flash programming voltages are currently considered dangerous.

Finally, FRAM is less sensitive to external fields and alpha particles than flash memory because the memory cell capacitor’s dielectric is much thinner than the one of a flash memory cell. The thinner the dielectric the less distance there is to develop a dV over and the smaller are the chances to (accidentally) modify a bit.

All these advantages were known from the start, so why did it take so long before FRAM made its way into non-Ramtron MCUs? Well, I don’t know about Fujitsu, but according to TI the main reason was the incompatibility of the technology. Five years ago FRAM was done in 350 nm technology, which was too big to use it in TI’s chips. Now they brought it down to 130 nm, which is a perfect fit.

This is a picture of a demo board showing off the low-power capabilities of the new MSP430 family, targeted at energy harvesting applications. Battery backed SRAM, flahs or EEPROM can all be replaced by FRAM, the speed and low power requirements of FRAM make external super caps unnecessary. Higher speed equates to shorter up times so ultra-super-low-power applications seem to be ideal.

Since anyone can license this technology from Ramtron, we can expect other parts from other manufacturers to appear in the next months or years.

Jeez, why didn’t I buy Ramtron stock at the time when nobody cared?

New kit on the blog

2011-04-14T07:12:00.000-07:00

At the last Embedded World show it was Cortex-M3 everywhere and I discovered that Fujitsu (now?) also sells cheapish development kits for their Cortex-M3 products. I obtained one of these kits, the SK-FM3-100PMC, to check out. The kit contains an SK-FM3-100PMC board, an AB type USB cable, a CDROM and a sheet with additional information. It does not contain the promised CD/DVD with Softune Workbench mentioned in the additional information.

On the board you’ll find an MB9BF506N processor (100 pins, 80 MHz, 512 KB flash, 64 KB RAM, 8 multifunction serial ports, 2 CAN ports & USB host & device, plus of course the usual timers and PWM-like peripherals, DMA and what not). Available connectors are UART-A RS-232 (9-pin female subd), UART-B USB (type A), CAN (9-pin male subd), USB host, USB device (type A), 20-pin JTAG (as usual the wrong way around for my Keil pod, Keil even gets this wrong on their own boards. Actually the cable is upside down on the pod) & Trace and headers for all the processor’s pins. On-board gadgets are two 7-segment LED displays (I always like that) and two square white push buttons.

The board can be powered from a multitude of sources: externally feeding a 1117 5V regulator, JTAG and both USB-A connectors. The processor itself will work from 2.7V up to 5.5V, meaning that this is one of the rare Cortex-M3 devices that can run directly from 5V.

Lets go!
Insert the CDROM and connect the board to the PC using the UART-B connector. A pretty well written Readme file pops up that guides you through the process of setting up a development environment for the kit. Driver installation is very easy, Windows can do it all alone (except for the usual “Do you really want to do this?” nagging). When the board is powered the 7-segment display starts counting up to 99 and then stops. Pressing the INT0 push-button makes it count down to 00, pressing INT1 makes it count up again.

The readme also describes how everything should be packed in the box, which is cool if you want to put it away properly.

The board has a reset LED, interesting. It lights up when you press the (square blue) reset button. Such an LED is maybe helpful to detect situations where the board is kept in reset without you wanting to?

The CDROM contains a free serial port terminal program SKwizard. This utility only knows about four COM ports, when my board is on COM20… Luckily the flash programming tool FM3 can handle COM ports up to nr. 20 (phew…). Yes, I know you can assign a different number to a virtual COM port, but this is poor/old school programming. The other flash programming tool (there are two) allows port numbers up to 255.

To test ease of (re)programming the board I first tried the FM3 flash tool. This one uses the serial port for programming and is pretty straightforward to use. The only weird thing (besides the COM port numbers) is that the file picker wants an S-record file, but only knows the extensions MHX, CNV & AHX, and not the SREC files that come with the kit.

The second tool for direct USB programming over the USB device port is a bit more difficult to get started, because it needs a driver that is not on the CDROM and I could not find it on the Fujitsu website either. Contacting Fujitsu taught me that the driver is hidden in the installation folder of the Flash USB Direct tool (on my PC: c:\Program Files\Fujitsu\FUJITSU USB DIRECT Programmer\driver\). I was also told that no drivers are available yet for Windows 7, but they are coming. Once the driver installed (COM 22!), I could reprogram the board. To my surprise direct USB programming turned out to be as slow (or fast, but I prefer slow in this case) as serial port programming. However, I did like the friendly message after successful programming: “It ended normally completely”. (Probably to be pronounced with a Japanese accent.)

Example code is provided for IAR and Keil compilers. I did have Keil uVision 3 with a ULINK2 pod, but you need version 4 to open the project files, so I downloaded & installed an upgrade of 312 MB. Now with my brand new version 4 I could indeed open the example projects.

What the people at Fujitsu forgot to mention is that you have to copy the examples to your hard disk otherwise uVision will not be able to build them as it tries to create files in the project folder. More annoying is that they also did not mention that you have to manually select the device - for some reason the project does not include the device – otherwise you cannot flash the board after a build and you receive confusing error messages. So, before building a project, select the device: Project -> Options for Target, click on the Device tab and select the MB9BF506N. This will also load the correct flash algorithm file. Now build the project and load it in the processor with your ULINK2, ME or PRO pod.

If you look closely at the project files you will see a file named FLASH_DEBUG_README.txt. This file says that you should copy an FLM file from the project to the Keil environment, but it seems that uVision 4 already contains usable flash files that get loaded when you select the target device.

I could not try trace recording, because you need a ULINK Pro for that.

The board in a Keil uVision 4 / ULINK2 environment.

Now that I am finally ready to start developing for this board it is a shame to discover that there doesn’t seem to be a nice Fujitsu library encapsulating all the peripherals of the chip and the board; some sort of a BSP as people like to call it nowadays. The best they have come up with is an empty template project, a bit meager.

Documentation includes full schematics of the board, but it is lacking a mechanical drawing with the positions of the break-out connectors that seem to be placed on a convenient 0.1 inch grid. So measure carefully when you design an extension card for it.

Open4 EvoPrimer

2011-04-05T06:21:00.000-07:00

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!

2011 OpenWorld Design Contest

2011-03-18T02:22:00.000-07:00

OpenWorld is an interesting design contest launched this week by STMicroelectronics and a bunch of industrial and research partners. The OpenWorld application design contest is a “technology promotion engaged by the Autonomie project” with as goal the development of “advanced navigation and augmented reality applications to assist the handicapped”.

The contest is based on the EvoPrimer tools that target especially portable applications. On the Embedded World show I saw a nifty extension card for the EvoPrimer that should allow for some pretty impressive personal in-house dead reckoning. The board was not only capable of tracking horizontal movements, but it also measures vertical displacements so it can help track a person going up and down the stairs. With such hardware some cool augmented reality (I should say this more often: augmented reality, augmented reality) applications should be possible.

To enter the contest and win some of the $ 20.000 cash awards you have to submit a proposition on the theme of Technology for Human Assistance. The best application concepts win EvoPrimer tools and enter the second phase to actually transform the concept into a working prototype.

Meet the people behind LPCXpresso

2011-03-11T01:43:00.000-08:00

OK, I admit it, I have been talking quite a lot about LPCXpresso lately. Why? Because I like NXP's concept of handing out free tools (did you know that they did it again? Get a board for free just by answering some questions on their website), but I also have become a fan of the little LPC Cortex-M0 and M3 devices. At the Embedded World 2011 show I visited of course the NXP booth and there I was introduced to the brains behind the LPCXpresson concept. My boss, who came with me, always carries a photo camera and immediately took some pictures, so now you too can meet the LPCXpresso team.

On the left we have Jan Jaap Bezemer who tries to sell (or should I say "give away") the NXP microcontrollers. Second from the left, Rob Cosaro, and the man on the right, Joe Yu, are the people that came up with LPCXpresso. A chuckling Rob told me that he was very much amused by the fact that people are indeed cutting of the LPC-Link part of the board, something that was never really intended. Apparently some people cloning the board add a V-groove to make separating the parts easier.

Embedded World 2011 - Cortex-M3 everywhere

2011-03-08T05:38:00.000-08:00

This year I renewed my visit to the Embedded World show in Nuremburg, Germany. Walking around the four halls that make up this big show it was simply impossible not to notice the ARM Cortex-M3 based controllers all around. Most chip manufacturers showed off boards with Cortex M3 devices, including ARM itself with their mbed board and other dev boards. There were also some Cortex-M4 demo's around from f.i. NXP (LPC4300) and Freescale (Kinetis).

This show was also rich in free kits; especially ST was very generously handing out STM32 and STM8 kits. I did not accept all of them, because I have no idea what to do with ‘em. Yet I did leave with (amongst others) a BeagleBoard-xM (thank you TI!), an FTDI Vinculo that I will review later on this blog and a ZigBee kit from ST. Fujitsu promised me to send me a Cortex-M3 kit by mail, I wonder if it will ever arrive.

Update 18/3: I received today a Fujitsu SK-FM3-100PMC kit, nicely boxed. More about it, hopefully soon, on this blog.

Due to a rather large amount of business meetings I did not see a whole lot of new or exciting things this year. However, I did get a demo of the very impressive new PIC32 compiler from MikroElektronika. These guys are definitely setting the new comfort standards for embedded software development. Wow! I always liked Microsoft’s Visual Studio, but this is way, way better. And the good news is that they are planning an ARM compiler too! At just under $300 (or $200 if you buy a board too) this is a bargain.

While I’m on compilers, Atmel too presented a new one: AVR Studio 5. This is a great tool too, and toujours completely free. V5 brings together AVR Studio 4 and AVR32 Studio into one IDE. It also integrates the AVR Software Framework (ASF) and over 400 example projects that used to be all over their website. Now you just pick your board and then the example that comes closest to what you want to do and off you go.

From the chip front I would like to mention the new ultra low-power 32-bit micro-controller family from Renesas, the RL78. Besides being low-power, this family is also ultra low-dollar. With an operating current of only 70 µA/MHz this is a direct competitor for the MSP430 from TI. But TI told me that they will announce an ultra-ultra-low-power MSP family later this year that will blow away the competition.
Microchip proudly announced their new PIC18F K80 micro. This is an 8-bit device that costs over one dollar, even at high quantities. This nicely illustrates the 8/32 bit paradox, but both Atmel and Microchip expect that the 8-bit market will continue to grow.

That is was not only Cortex-M3 all around proved Digi who had on display their pretty impressive ConnectCore Wi-i.MX51. As Digi's website says: "This module is a highly integrated and future-proof System-on-Module (SoM) solution based on the Freescale i.MX51 application processor with a high performance 600/800 MHz ARM Cortex-A8 core, powerful multimedia capabilities and a complete set of peripherals.".

The kit on the left is running Android, the kit at the right runs Ubuntu.
Digi's latest board, the ConnectCore Wi-i.MX53, was on display at the Freescale stand.
Rabbit 6000 modules are now available too.

Analog Devices showed me their new MEMS gyroscopes that have extremely low drift. So, I guess this is good news for the dead reckoning people.

FTDI presented a rather mysterious device, the FT1248. Although they did make it clear that this device communicates over a 1, 2, 4 or 8 bit wide bus of which the width can be adjusted on the fly, I did not grasp the reason of being of this chip. It is probably very useful or they wouldn’t have spent any time on it, but useful for what exactly? I guess that it is a bus extender of some sort, but I can’t find the data-sheet. Oh well, I am sure someone will figure this out for me.

I really like this show; I can hardly wait for next year.

Free cup of LPCXpresso!

2011-02-24T04:51:00.000-08:00

A bit over two weeks ago I told you how to get a free LPCXpresso board by making a short video or a photograph of how you got rid of your 8/16 bits micro-controller. I suspect/suppose that NXP will honor every participant.

Here is a picture I received from Antoine Broussal. Note how he did the can and the peanuts.

Just to show you that it is not bogus, here is a picture of the board with its accompanying letter that I received this morning by UPS. It is, as I expected, an LPC1114 board.

Denis Xavier wrote me to tell me that his contribution was accepted too, so Denis, you want to share a cup of LPCXpresso code?

The campaign is still running and the submission stream seems to have slowed down a bit, so go give it a shot yourself!

Embedded World 2011 update: NXP ran out of stock. Please be patient.

BTW, while I was writing this, I received a press release from NXP announcing the LPC1200 series. Compared to the other LPC Cortex-M0 devices these new Cortex-M0 controllers offer up to 128 KB of flash memory, DMA, a real-time clock (RTC) and a CRC engine.

CodeLite & GDB for ARM

2011-02-09T12:20:00.000-08:00

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.

Break the 8/16-bit habit

2011-02-07T01:58:00.000-08:00

Most people, including me, like to get stuff for free. Electronic component manufacturers know this and often they offer free samples in the hope that their parts get designed in. Microcontroller manufacturers have started doing design contests and other campaigns to get new users for their products. One of the latests campaigns was launched by NXP for their ARM Cortex-M0 parts.

NXP already did do a design contest (or challenge as they called it) for their LPC1100 parts and now they are giving away LPCXpresso boards that contain a Cortex device. To get one, all you have to do is to show how you plan to stop using 8 and 16-bit devices. You can do this by sending in a picture or a video and if accepted it will be posted here.

Here is the video I sent in.

NXP's website does not mention which LPCXpresso board you will get, but I suppose it will be the board with the LPC1114.

Here are some photos & videos I received in response to this article. Feel free to share your way of breaking the 8/16 bit habit by sending me your photo and/or video and I will put them up here too.

L. Francey prefers to use his obsolete microcontrollers to create arty objects.

Marc will eat anything that has legs.

Jonathan likes Aciiid!

Denis combines his passions for nature and electronics.

Test driving DesignSpark PCB

2011-01-17T04:36:00.000-08:00

In the summer of 2010 RS Components launched DesignSpark, an online community for electronics engineers. It is a similar community as Element14 from Farnell that was launched a year before. Like Element14, DesignSpark also offers a free circuit drawing and PCB design tool. Unlike the tool from Farnell that has some limitations - notably board size - the tool from RS is totally unlimited (meaning that there are no artificial limitations). Eagle Freemium, the tool from Farnell, in its free but limited version is allready used by many hobbyists, so would it be interesting for those users to switch to DesignSpark PCB?

Since I have been using (the professional version of) Eagle for a while now, I decided to try out DesignSpark PCB. I installed the latest version, which is 1.0.3. I had no PCB to design so I followed the tutorial that is included with the software. The tutorial is clearly written and pretty straightforward. A circuit diagram is quickly drawn thanks to the many libraries included, but the tutorial only uses some standard parts. If you follow the tutorial closely you will end up with a routed PCB in 45 minutes or so.

I noticed three problems in the tutorial text. The first one is a wrong connector specification. The text mentions a 5WP model, but you need a D9F. The second problem is more serious as I could not find the solution without the help from RS. The tutorial wants you to place a label on a net using the Display Net Name option that is supposed to be available from the right-click context menu, but I did not have this option. Looking through all the menus I could not find it either. The trick is that you have to select the _pin_ of the output symbol, not the symbol itself. The pin is the little cross that disappears as soon as you connect a wire to it. To select it you have to click on the extremity of the symbol. Actually it is much easier to right-click the wire to display the net name.
The third problem was the missing Spoke 10 option for the copper pour. This is a technology file issue, I probably did not load the right one.

I also tried importing an existing Eagle project. DesignSpark PCB includes a few Eagle macros that seem to work rather well, but not 100 %. In the schematic some junction symbols (the dots) were lost. Maybe these were the manually placed junctions in the Eagle file? Texts did not keep their sizes and the outlines of the page frames (or borders as the tutorial calls them) were gone. I also ended up with some labeled wires that were red, but not all.

On the imported PCB the texts not only had the wrong size, but they were rotated incorrectly too. A real problem was the fact that the Eagle project used a copper pour for connecting all the ground connections and these were not recognized by DesignSpark PCB even though the signal pads & vias had the right net names and were in the pour. Autorouting the PCB with or without grid did not solve the problem, and I am stuck at this point.

My quick test drive of DesignSpark PCB showed me that it is a very usable tool of at least the same quality as Eagle, but without the limitations of the Freemium version. I have used quite a lot of different PCB CAD packages and I found DesignSpark PCB easy enough to learn, but this may be different for other people. Switching to DesignSpark PCB may be interesting if you are not afraid of gerber files, because the PCB pooling guys, except for PCB Pool, do not (yet?) support uploading of complete DesignSpark PCB projects as they do for Eagle.

DesignSpark PCB seems a bit more production oriented than Eagle and you have easier control over the BOM. I also found the generation of the fab files easier. The technology files will probably confuse Eagle users (line widths f.i. have to be specified in the technology file first) and data entry is more work as is checking the PCB with all the different reports.

The most important difference between the two tools is definitely the design flow. DesignSpark PCB uses the classic capture-netlist-pcb flow

repeat until finished
{
draw/modify schematic;
generate netlist;
draw/modify PCB;
}

whereas Eagle has this automated. If you delete a part in an Eagle schematic, it is also deleted from the PCB. In DesignSpark PCB you have to initiate the update manually. Both ways of doing have their pros and cons and as long as you are used to it you will stay out of trouble, but if you aren’t, you will be in for some (unpleasant) surprises.

Another difference is in the separation of components and circuits. In Eagle, once you’ve defined a part you can only modify it in the library editor. DesignSpark PCB lets you edit a part up to some extent during capture. You can move pin names and numbers and add fields to parts that would be text comments in Eagle.

Let me finish this article with some remarks about DesignSpark PCB particularities:

Schematic capture
- Setting the component value of parts that do not have the value field is tedious, but can be done without editing the part in the library editor.
- Setting the component value is a bit tedious too as it involves at least two double clicks and two OKs.
- When two nets are merged, you cannot choose the name of the merged net.
- Block dragging is a bit strange and will move wire segments that you probably did not want to move.
- I had grid problems. Wires and parts placed on the grid somehow were moved off the grid, probably after a block move even though I never changed the grid or switched it off.

PCB
- The autorouter is not very powerful. It works with the tutorial, but I could not get a simple circuit to route except for a few wires. It turns out that you have to set the intertrack and track-pad spacings properly in the Design Technology window depending on the component lead pitch to get it going. You may also want to reduce the via size. I finally managed to get a very simple design to complete, but I was not impressed with the result. Then again, I always route manually so I don’t really care about the autorouter.
- You can generate reports for lots of things. These are displayed in Notepad and before you know it you have lots of Notepad windows open. If you rerun a report it will get a new window instead of overwriting the old one.
- Don’t forget to activate the Show nearest node on net if you route manually, otherwise you have absolutely no idea where you are going.
- I liked the single doc PDF that you can produce and that will hold all the plots. You should include the board outline in at least one plot, otherwise the paper size will wrong.
- I also like the plot preview option and the simple checkbox to cover vias with solder resist.
- Nice also is the auto place function to put parts on the board, allthough the result may not be exactly like how you would do things.

Projects
- You cannot rename a sheet? The only way I managed to do this was to save the project in a new location.

Dreams,dreams, dreams...

2010-12-07T04:58:00.000-08:00

Every once in a while I come across a component that gets me dreaming. This morning I received a press release about such a component: a wireless EEPROM from STMicroelectronics. The M24LR64-R is a 64 Kbit EEPROM with password protection and a dual interface. It has a standard 400 kHz I2C bus for reading and writing the device, but it also has an ISO 15693 compatible 13.56 MHz contactless interface. You can actually read and write this chip using RFID and near field communications (NFC) techniques without needing to power it. I think that is pretty cool.

Every time when I had to draw a PCB with memory, especially the kind with lots of address and data pins, interfacing in parallel to a processor, I started dreaming about wireless memory. Wouldn’t it be great if you only had to plunk a memory chip on a board, somewhere in the vicinity of the processor and not wire anything? Instead of transmitting over the air you could probably use a copper or some other metal plane as a better communication medium. Or you could make the PCB out of wood or paper and stick the components on it with ecological glue.

Maybe some day wireless will be so cheap that you can have intelligent wireless resistors, capacitors and other parts that could be mesh-networked to build a circuit. You simply put the components in a bag or box, like rice or sugar, and it all would work without wires and soldering. OK, that is a bit far fetched, but who knows what we will have 50 years from now? This RFID EEPROM is definitely a step in the right direction.

This kind of dreaming reminds me of the time when I was a kid and a friend of mine had a Tandy electronics experimentation kit with resistors, transistors and other parts. It used springs for wiring. We would wire at random the parts together while fantasizing about the amazing things our circuit would do. Of course nothing ever happened (and somehow we never smoked anything), but it kept us busy after school. Being nerds we had not yet discovered girls, but I did get a glimpse of his mum naked. Maybe one of our random circuits did work after all…

PSoC 5 Design Challenge

2010-11-23T12:37:00.000-08:00

Here is yet another design contest:

Cypress Semiconductor announced the ARM Cortex-M3/ PSoC 5 Design Challenge, a contest to find the most innovative and useful designs from the millions of possibilities available to designers using the Cypress PSoC 5 architecture powered by the ARM Cortex-M3 processor. The contest is presented in conjunction with EE Times and ARM with the Grand Prize to be awarded in May, 2011. A total of over $10,000 in cash and prizes will be awarded throughout the contest, including the $2,500 Grand Prize. More information, including how to enter the contest and how to become a judge, as well as lively interaction from participants and the engineering community is available here.

Sceptre library update

2010-11-15T08:53:00.000-08:00

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.

Renesas RX Design Contest

2010-11-02T09:38:00.000-07:00

The Design Contest seems to be the new weapon of choice for microcontroller manufacturers to get attention for their products. NXP is currently running the mbed Design Challenge and two weeks ago Renesas announced their RX Design Contest. Over $110,000 worth of prizes will be distributed amongst the participants.

The Design Contest is also a good way for electronics enthusiasts to get a nice piece of hardware for free. NXP is handing out LPC1768 Cortex-M3 mbed modules for free and the first 1,000 participants of the Renesas contest get a complimentary RX62NRDK development board.

This board supports most flavors of USB, has a color graphics display, LEDs, buttons, SD-card connector and whatever you may need in a project. Random particpants will also get a full licence for Micrium uC/Probe together with the book uC/OS-III RTOS for the Renesas RX.

The contest finalists will be announced on March 13, 2011. The final judging will be at the ESC in San Jose, California on May 3, 2011.

(See also here and here for other contests.)

Eagle switches to XML

2010-10-20T08:50:00.000-07:00

Last week a rumor started spreading about Eagle, the popular schematic capture and PCB drawing package used by thousands of electronics enthusiasts, switching to a text-based file format. We at Elektor asked CadSoft, the editor of Eagle, about this rumour and got it confirmed. Somewhere in the hopefully near future Eagle will start using an XML-based file format for storing its drawings. The reason for this change is, according to CadSoft, that the binary format has reached its limits.

I find this reason a bit strange. Why would a text format be more flexible than a binary format? I mean, text is just limited binary, right?

Of course a text-based format is human readable, which is an advantage when trying to debug a broken file. But will this help in real life with a multi-megabyte sized file? (BTW, I have never yet had to debug a PCB file.)
A text-based format will be cross-platform as it avoids byte ordering issues, a good thing. Using XML is probably a good idea too, because it is a well known format and many tools & libraries for fiddling with XML files are readily available.
For the user a text-based format is interesting as it may help speed up certain repetitive tasks like net labeling or copying blocks. Users will start writing utilities for manipulating Eagle files.

Will they? Probably. They always do.

But Eagle already offers a powerful scripting language that lets you do lots of things without learning the file format first, so why bother? By writing a script you can already export everything yourself to a human readable format. And that is exactly what RS did for DesignSpark, the competitor of Eagle Freemium by Farnell (who bought CadSoft some time ago). RS offers scripts that allow you to export Eagle files as ASCII data. This is what it looks like:

EAGLE_INTERMEDIATE_ASCII "my_board.brd"

(asciiHeader
(fileUnits IN)
)
(library Library_1
(padStyleDef "Oval1"
(holeDiam 0.0314961)
(padShape (layerNumRef 1) (padShapeType Oval) (shapeWidth 0.0514961) (shapeHeight 0.102992))
)
(padStyleDef "Round1"
(holeDiam 0.125984)
(padShape (layerNumRef 1) (padShapeType Ellipse) (shapeWidth 0.133984) (shapeHeight 0.133984))
)
(padStyleDef "Rectangle1"
(holeDiam 0)
(padShape (layerNumRef 1) (padShapeType Rect) (shapeWidth 0.07) (shapeHeight 0.1))
(padShape (layerNumRef 16) (padShapeType Ellipse) (shapeWidth 0) (shapeHeight 0))
)
…

That is not so different from XML, is it?

The only reason I can think of why Farnell/CadSoft wants to switch to XML is that they hope that the heavyweights like Cadence or Pads will start writing Eagle import filters for their products. These products already know XML, it would be easy enough to add Eagle support. And that would be a good sales argument for Eagle. Start simple and low-budget with Eagle and when you’re ready to move on to something more serious you won’t lose your work.

It is all about compatibility.

Build a dishwashing surveillance system

2010-10-07T05:11:00.000-07:00

Every once in while I spend an afternoon or evening just browsing eBay. I do some searches on keywords concerning things that may interest me and I look through the results. When I find something interesting I click on the item for more details. Often I come across items that are sold by Chinese companies that sell lots of other things too. These are my favorite sellers. There are many Chinese eBay shops that sell exactly the same products, they probably are all related, but every once in a while I discover a new “family” of shops with different products.

My latest find is a series of cheap microcontroller boards equipped with a small camera and a 2.8” color TFT display. The camera, 640x320 pixels, is actually a small module that is plugged on top of the board, while the display (320x240 pixels, 262K colors) sits on the other side. You can make a camcorder out of it, because it has a micro SD card connector for storage.

I bought the ATmega32 board including a USBasp ISP programming cable for less than 35 euros (shipping included). It is a complete development system with full documentation and source code in C (with comments in garbage characters, probably Chinese). When it arrived I discovered that the display even has a resistive touchpad on it.

Here is a sneak preview of my killer app for this board: a dishwashing surveillance system that checks my dishwashing qualities. It will detect dirt on the dishes and sound an alarm when everything is dry. Pretty cool, huh?

So, what will you do with it?

RFID made simple

2010-09-13T05:42:00.000-07:00

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

2010-08-25T03:33:00.000-07:00

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!

Forget about the hardware and learn C

2010-08-11T03:25:00.000-07:00

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.

Add a smartphone to your application

2010-07-29T00:57:00.000-07:00

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…

Microchip Application Library: GOL trouble

2010-07-15T07:33:00.000-07:00

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.

PIC32 MultiMedia Board (MMB)

2010-06-03T07:10:00.000-07:00

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.

USB 2.0 drop-in for legacy DB9 RS232 connector

2010-05-20T02:53:00.001-07:00

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.

Fast prototyping with mbed

2010-05-04T07:11:00.000-07:00

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.

Porting code...

2010-04-18T12:09:00.000-07:00

...or how to waste lots of time.

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...

The InterSceptre is almost ready!

2010-04-08T06:41:00.000-07:00

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

2010-03-19T01:34:00.000-07:00

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.

It's a tactile green embedded world

2010-03-11T03:30:00.000-08:00

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.

YADC - Yet Another Design Contest

2010-02-18T06:21:00.000-08:00

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.

Become a beta tester and win

2010-02-16T07:51:00.000-08:00

It is contest time. I allready mentioned the Luminary, sorry, I mean Stellaris ARM contest from Texas Instruments together with Circuit Cellar and a week later the LPCXpresso ARM contest by NXP. Now it is Freescale who organises a contest. OK, this is not a very difficult contest and you don't have to design anything, but you can win some smart prizes.

To participate you only have to enter the CodeWarrior Development Studio 10.0 beta test program. Free access to the beta release, including full documentation and task-based videos are available for a limited time at www.freescale.com/cwmcu10. CodeWarrior integrates the development tools for the RS08, HCS08 and ColdFire architectures into a single product based on the Eclipse open development platform. Since this is a beta release, it cannot be used for the development of production products. However, you are encouraged to explore the functionality of this new development environment.

To recognize your participation, on April 12, 2010 Freescale will be drawing names from the pool of beta testers for three exciting prize packages:

- Canon Rebel digital single-lens reflex (SLR) camera
- Wii game console by Nintendo
- Garmin handheld GPS

So, go get that 500+ MB download and win that camera!

P.S. You have to submit feedback through a Freescale Service Request to really enter. Alternatively, participants may send an email with name, address (including zip code), home and work telephone numbers (including area codes) to r63076@freescale.com.

LPCXpresso design contest

2010-02-07T06:05:00.000-08:00

Last week I received two LPCXpresso boards designed by Embedded Artists for evaluation. An LPCXpresso board is a small but longish 35 by 140 mm board split in two parts. One part has an ARM Cortex (M0 or M3) processor from NXP (LPC1114 or LPC1343) on it, together with a 12 MHz crystal and a small prototyping area. The other part of the board is the LPC-Link, which is a real JTAG programmer/debugger. This part is a sort of detachable JTAG pod and if you cut the connections between the two rows of JTAG connector pads you can connect it to other compatible hardware, your own ARM board for instance.

Why is this interesting? Well, first of all because of the price, since Embedded Artists sells it for only 20 euros. This means that you can get yourself a JTAG debugger for a very good price.

Then there are the development tools (Windows only, but should also work on virtual platforms with USB support on other operating systems). The boards are supported by a free enhanced Eclipse-based IDE developed by Code Red. This software lets you compile programs of unlimited size, but program and debug only up to 128 KB. The NXP web site has a list of compatible processors which is unfortunately missing the LPC2148, but according to NXP it should work with unlisted controllers too, as long as you respect the 128 KB limit. I have yet see this as the IDE does not allow picking an incompatible controller and an LPC2142 is not an LPC2148.

LPCXpresso LPC1114 together with an mbed module and the mbed pin-out card. Everything on the left of the pin-out card is the LPC-link JTAG pod.

Note that the LPCXpresso is pin compatible with an mbed board. That may seem strange as an mbed module only has 40 pins whereas an LPCXpresso has 54, but pin 1 to 20 and pin 28 to 47 of the LPCXpresso module have (where possible) the same functionality as the mbed pins. One problem though, the mbed processors (LPC1768 and LPC2368) are not supported by the LPCXpresso IDE. I have been told though that a Cortex-M0 mbed is coming soon.

Also interesting is that NXP has launched a design contest. Anyone entering a valid design concept before the 8th of March 2010 will receive a free LPCXpresso development kit and then has about one month to actually build it and show that it works. Check out all the details here.

Will the new Bill Gates please stand up?

2010-01-28T01:41:00.000-08:00

Circuit Cellar together with Texas Instruments have launched a design contest around the Stellaris LM3S9B96 microcontroller. This 100 pin controller is based on a 32-bit ARM Cortex–M3 core with 256 KB flash memory, 96 KB RAM and it sports many interesting features like CAN, USB 2.0 OTG/Host/Device, 10/100 Ethernet MAC and PHY, I2C, I2S, SSI, UART, PWM, ADC and some other peripherals. Although this is more or less what you would expect from a modern 32-bit microcontroller, it is not all: the device also has a built-in library with almost 400 functions to access its peripherals. This BIOS (Basic Input Output System) provides a nice hardware abstraction layer for almost all of the registers and makes life of the programmer much easier.

To top thing off, the device also has a built in real time operating system (RTOS)! According to the datasheet the controller has a copy of SafeRTOS inside, a secure version of FreeRTOS edited by Wittenstein. Unfortunately, the datasheet isn’t very verbose about it, but it is there.

Now what do you call a processor with peripherals, a BIOS and an operating system? A computer! Indeed, this microcontroller is pretty much like a computer on a chip (CoC) and the only thing missing is a graphical interface, but that is probably just a matter of time and/or pin count.

Are we entering a new era of microcontrollers? Will this be the new standard architecture for the next generation of microcontrollers? What about code portability? Will the user get access to the source code of the built-in BIOS and RTOS? Will ARM, TI & Wittenstein be the next Intel, AMD and Microsoft?

At the end of 2008 I assisted at an ARM conference in Paris. The buzz word then was "code portability". If only everybody would be using ARM-based processors, then code would be easily portable from one device to another. Luminary, the developper and former owner of the Stellaris processors, was present too. But is the BIOS & RTOS they now put in their devices good for code portability? Will other ARM-based microcontroller manufacturers too integrate a compatible BIOS & RTOS in their devices or provide compatible libraries? Or are we going to have to deal with tens of different BIOS-es and RTOS-es in the future, supported by code bloating tests to figure out what the heck the platform actually used is capable off?

Devices will get bigger and will integrate more and more. Within a couple of years they will be as powerfull as a modern PC is now, with built-in BIOS and OS. This all smells so much of Microsoft and the OS wars from the past years.

NOOOOOOOoooo!!!!!

Please, not again!

Worldwide Serial Web

2010-01-23T09:14:00.000-08:00

You may have heard of WIZnet, the Korean company that makes several embedded Ethernet controllers with an integrated hardwired TCP/IP stack. Their flagship, the W7100, also has an 8051 compatible processor inside. They not only make & sell chips, they also sell modules, evaluation boards and even complete products that use their chips. These modules allow you to add Ether- & Internet connectivity to your project without much headache. WIZnet now also offers a great free (you have to register to get a serial number) software tool that lets you connect to serial ports over a network.

This tool called WIZ VSP (for Virtual Serial Port) is pretty cool indeed. It lets you install up to 99 real or virtual COM ports (the documentation talks about 255, but the software doesn’t let you go higher then COM99), as a server, a client or a shared port. A server will wait for clients to connect to it. A client connects to a server. The shared port uses UDP instead of TCP and will talk to one remote host and listen on a port.

A server supports multiple clients. This means that you can distribute data received on the server COM port to multiple clients that can all talk to the server. Such a configuration can be useful as a serial port concentrator, for instance.

The shared port over UDP can do the same thing as a server, except that it is connectionless. It also only talks to one other host (but listens to anyone talking to him), unless you specify a broadcast address.

I’ve tried the tool and it works remarkably well. The documentation is a bit cryptic at some points and the fact that I used one PC under Windows Vista complicated matters a bit, but in the end I managed to transmit serial data between two PCs in al three configurations. Here is how to do it:

First download the software and the manual (separate download!) and install the program. Then request a serial number by sending an email to the indicated address. When you get the serial (you may have to answer some questions) enter it when the program asks for it (without serial it will NOT work). Now you can start creating serial servers and clients.

On the “Create Connection” tab select the type of connection and the number of the serial port. Note that if the serial port exists in hardware, i.e. is real (can be a USB type or Bluetooth) you can clear the checkbox “Create as virtual serial port”. This way the software will use the real port and you can specify the serial port parameters (baudrate, data bits, etc.) on the “Connection prefs” tab. Depending on the connection type you will have to specify a host IP and a port number. You can configure some more on the other tabs and once you’re done, click the “Create connection” button. If the port did not yet exist you will now hear the typical Windows add-new-hardware sound and the port shows up in the tree display. To edit a created port you have to use the “Edit connection” tab.

This shows the server setup on a Vista PC.

On another PC you do the same thing, but complementary. If you created a server on the first, create a client on the second. If you created a UDP connection on the first PC, you should create also a UDP connection on the second. Make sure to specify the right host IP numbers and to use the same port numbers on both PCs. Also better switch of any firewalls. I had to do that on the Vista PC before my XP PC would receive any data even though Vista did receive without any problem.

BTW, as host IP it is also possible to specify “localhost”. This way you can make serial ports on the same PC talk to each other.

Here is the XP client that talks to the Vista PC.

To familiarize yourself with the tool I suggest to first only use virtual ports and a terminal program. This way you can type and see what happens.

Once you know how to properly setup WIZ VSP, your application can use a serial port on another PC, anywhere in the world! Or a serial device (f.i. a GPS) can transmit data to multiple hosts. I am sure you can come up with some other useful configuration. This is a very powerful tool and anyone using serial ports should get a copy of it. Now!

Oh, one more thing. Once the connections are established you can close the program without killing them.

Energy harvesting power supply

2010-01-15T01:31:00.000-08:00

This week I came across an interesting new product from Linear Technology: the LTC3588 energy harvesting power supply intended for powering remote microcontroller systems. According to the product description this chip is a complete energy harvesting solution optimized for low energy sources, including piezoelectric transducers.

A buzzer?

The LTC3588 datasheet does mention some manufacturers of piezoelectric transducers that can be used with the chip. I looked one up: the T220-A4-503X from Piezo Systems. As I allready suspected, it is not really a buzzer. It is also more expensive than a buzzer: $125. You can buy a lot of batteries for that money, but it is probably cheaper than to send out a maintenance engineer to replace a dead battery. This particular transducer can deliver 5.4 mW RMS when it vibrates ±1.57 mm at 80 Hz. It comes as a 0.5 mm thick card of 31.8 x 63.5 mm (1.25" x 2.5") that has to be soldered with special solder (the transducer has nickel electrodes).

OK, so this kind of piezoelectric transducers is probably not for me, but the LTC3588 datasheet shows other ways of using the chip: with a solar panel or a thermoelectric transducer or as an electric field harvester.

I like the last one. It uses two 30 x 60 cm (12" x 24") sheets of copper at about 15 cm (6") from a 60 x 120 cm (2' x 4') fluorescent light fixture. At such a short distance you might as well wire the chip directly to the light fixture supply, right? Luckily the datasheet also shows you how to do that.

Yet the LTC3588 seems like a pretty interesting chip and I ordered some samples. I will let you know if I get them and if I did, what I managed to do with them.

LTC3588 datasheet
Piezo Systems
A nice introduction to piezoelectric transducers

Accelerometers

2010-01-07T07:52:00.000-08:00

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

Do you know MIPS?

2009-12-30T08:29:00.000-08:00

You probably have heard about ARM processors. ARM seems to be everywhere and we are flooded by press announcements about new ARM-based products. This might make you think that ARM is currently the most successful processor around, especially if we think about 32 bit processors. But did you know that there exists another 32 bit processor for embedded applications? Well, yes, of course, there are other 32 bit microcontrollers that are not ARM, but there is one particular brand that you probably have as a brain for at least one of your electronic gadgets: the MIPS processor.

Like ARM, MIPS Technologies does not make silicon, but only so-called soft cores, a piece of software that describes a processor core. To use a soft core you have to licence it and put it in a chip yourself. There are many MIPS cores, not only 32 bit but also 64 bit, and there are many companies that use one of those in their products. To name a few (in random order): Sony, Realtek, Broadcom, Pioneer, Motorola, Cisco, Microchip, Hewlett-Packard, Philips, Toshiba, Canon, Samsung, JVC, Pentax, Casio, Minolta, NEC, Fujifilm, Ikanos, etc., etc. That is quite an impressive list for a processor that we hardly ever hear about, isn't it?

As you can see from the list of MIPS users, these are all big well-known companies that make many types of consumer products, which explains why you probably own at least one MIPS processor. Digital camera's, network routers, Wi-Fi access points, DSL modems, printers, netbooks, digital photo frames, DVD players, GPS receivers, game consoles and even cars, many of them contain a MIPS core. Unlike ARM, MIPS Technologies does not make a lot of noise, yet their products are everywhere.

But there is one major product in which you will not likely find a MIPS: the mobile phone. This market is almost completely dominated by ARM, but MIPS is hoping to get in thanks to Google's Android, the open source smart phone operating system. Android, developed for ARM processors, is a platform that current MIPS users might want to use too, so MIPS Technologies started porting it to their products. And then, with a bit of luck, MIPS users will start building smart phones with MIPS cores.

For the electronics hobbyist the easiest way to get started with MIPS is probably to buy a PIC32 processor from Microchip. The PIC32 is based on the MIPS32 M4K family and according to Microchip they perform better than an ARM7 clocked at 100 MHz.
If you look hard enough you can also find single board computers with MIPS processors and run for instance Linux-MIPS on it. Or hack a router and play with OpenWRT.

Share your MIPS experiences!

Take the time to learn your system

2009-12-18T10:42:00.000-08:00

I’ve always been fascinated by microcontroller systems and the process of making them come to life.

It all starts by designing the system, a controller with some peripheral hardware. Once I finally have a prototype of my design the first thing I do is to see if I can talk to the processor. This is always an exciting moment. Will it respond? Will it program?

I prepare a small hello-world type of program and try to load it into the controller (or in its external memory, depending on what I am working on). Suppose all went well and the controller accepted the program (what a deception if it didn’t). Usually the hello-world program is flawed and doesn’t work as intended. Maybe I was too brave and tried to put too much in it, maybe I didn’t understand some functionality? I modify the program and try again, but still nothing. So I hook up the oscilloscope and start probing around. Aha! found a signal, but on the wrong pin. Back to the code, locate the bug this time and now the hello-world program works. Great! Little by little I start adding functions to the code, first to test the peripherals and then to get fancy. And then suddenly it all stops working…

Oops. Now what exactly did I change the last time? Ehmm…

So I start taking bits of code out, but that doesn’t help. I remove more, change this and that, decide that some parts could be coded more elegantly and I end up spending many hours coding without much success.

And then, as suddenly as it stopped working, the program starts working again. Hallelujah! From this moment on, I know from experience, it will never stop working again. No matter what I do, the program will run. There will be a bug every once in a while, but I know I will fix it quickly and I just can’t seem to mess it up anymore. My baby is alive! I master the system without really knowing what went wrong, where and why. Now my prototype can and will grow into a fully functional system.

Fascinating, isn’t it? No? Oh well, I guess you had to be there.

So what’s the point? Well, the fact that I spend many hours fiddling around trying to figure out what and why made me into an expert. The experience gained from debugging and rewriting code helped me understand my system. Since this has happened often to me, I now know that I have to go through this phase to be able to finish the job.

So don’t despair when you can’t find out why your system doesn’t work. Keep patient. You will get there if you are willing to spend the time to learn your system. Once you are the expert, your system will listen to you and obey.

Do you recognise any of this? Let me know how you work, how do you learn your system? Please share your experiences.

And the winner is…

2009-12-10T02:38:00.000-08:00

Last week I did a small survey of microcontroller preferences. Although I had an idea what to expect, there were some surprises in the responses. First of all I received much more reactions than I had hoped for. I would like to say thank you very much to all of you who took the time and effort to reply to this survey! The people that posted a reply (in English!) directly to the blog will find it added to my original post. Those that sent me an email, well, I am very sorry, I am not going to add them all to this blog as there were way, way too many. However, I did spend a few hours reading all the messages and a summary follows here.
What we all want to know now is of course: who won?

But before I will tell you, you will have to read through the following advertisement.

Just joking: the winner is… AVR! Yes, the AVRs received 43% of the votes, while the PIC family lagged behind with 35%. The rest of the votes went to other families of which the MSP430 and the Propeller were mentioned quite often. 8051/2 clones are also reasonably popular.

The main reason for the AVR domination was the available tools. Although free tools exist for many microcontrollers, BASCOM for AVR was mentioned several times and also Arduino. Now this survey originated at Elektor and was read mostly by Elektor readers, so it is biased as Elektor has published quite some projects using BASCOM-AVR, but in general it was felt that the free tools (BASCOM is free only for small executables) for AVR are better than those for PIC. Also the AVR seems to be more easily available and cheaper than a PIC (even more so since Microchip restricted their sampling program), especially important outside the US and Western Europe.

In favour of the PIC was the abundant documentation, examples and free libraries. It is true that Microchip puts a lot of effort in that. On a pure technical level, some people felt that the PIC is less sensitive to noise than the AVR.

Other processors were of course mentioned, but as the survey mainly spoke about PIC and AVR, most people restricted themselves to these two families. However, as stated by several people, if the MSP430 would exist in more DIP packages (only the smallest ones are available in DIP packages), they would definitely prefer it over both PIC and AVR. Surprisingly to me the Propeller from Parallax was mentioned a few times too. Personally I think of this processor more as a sort of freak processor and I would not easily invest time and money in it. Maybe the future proves me wrong, what do I know?

Several people liked the Stellaris, now from TI, others love Freescale.

What is very clear from all the responses and which didn’t surprise me much: architectural reasons clearly do not dominate the choice of a controller family. Once people have learned to use a certain microcontroller family and have invested in tools, they are not very likely to switch to another family from another manufacturer just for the fun of it.

So, my next question is: what does it take to make you switch to a competing microcontroller?

Are you a PIC fanatic or an AVR lover?

2009-11-25T08:13:00.000-08:00

Twenty years ago life was easy. Nobody really used the term embedded yet and there were only a few microprocessors to choose from. The choice was roughly limited to Intel’s 8051, the 6809 from Motorola, MOS Technology’s 6502, the Z80 by Zilog and maybe the H8 from Hitachi. These were all 8 bit processors. Personally I was a fan of the 6502 and I did not like the 8051. As a hobbyist building a computer system was rather a challenge because of the complicated board design due to the external memory and peripherals, but soldering was easy.
The integration of memory and peripherals into the chip turned the microprocessor into a microcontroller and made board design much simpler. The PIC that was introduced by Microchip somewhere in the early nineties was simple, some had EPROM on-board, and was cheap and easy to come by, which made it a good choice for hobbyists. The AVR introduced by Atmel a bit later was one of the first to include flash program memory which made it a good choice for hobbyists too.
Nowadays embedded has become a buzz word thanks to the thousands of different microcontrollers on the market. 8 bit, 16 bit, 24 bit, 32 bit, you name it, and it can be had. Some of the oldies are still around, like the 8051 in many incarnations, or the Z80 (by Rabbit Semiconductor). They are now faster of course and come with more options, but they are essentially the same as 20 years ago. Today building a microcontroller system is easy and within reach of most hobbyists, although the soldering has become somewhat more difficult.
Choosing a microcontroller on the other hand has become complicated. If we stick to the hobbyists we see two large user groups: PIC users and AVR users. Of course lots of hobbyists use other controllers, but these two families are probably the most popular. Now which family do you use? Are you a PIC fanatic or an AVR lover? Both families have flash memory and free development tools, both are cheap and easy to get. So how did you get into AVR or PIC? I have not been able to choose between the two, maybe you can help me? You can post your comments on this blog.