My First Project

Enough of playing around! Time to see if I can create my own project:
In the menu, Project then New Project seems to be a good place to start.
The interesting thing here is that I am now being asked what MCU I am going to use. This looks like I am using the Device Database again. Selecting LPC2148 asks me if I want to copy the startup code into the project. Sure! I don’t want to have to spend hours going through the data sheet just to write a whole lot of runic startup assembler code to get going.

Actually, the startup code that gets imported into the project doesn’t look too runic. It’s nicely written. But there are over 400 lines of it! (Glad I didn’t have to write that.)

So, I have chosen the LPC2148, but what does that actually mean? Clicking through Project then Options for Target, takes me to a dialog which tells me that my choice has set up the memory map of the LPC for the simulator and linker, set a default clock rate, and configured the tools to build a debug image for the simulator.

The best bit for me is the automatic generation of the scatter file for the linker. “What’s a scatter file?,” you may ask. It’s a text file that contains a description of where you want the linker to place code, constants, data and zero initialized data in the memory map of you application. Easy enough to understand I suppose, but not something I really want to mess around with at this stage. Having the Device Database create the scatter file for me is great! On this part internal ROM is at 0x0… 0x80000 and internal RAM is at 0x40000000… 0x40008000.

Hello Rod (almost)

Tools installed, it’s time for me to try and create the obligatory “Hello Rod” program. uVision is the IDE for the tools and so this seems to be a good place to start. The IDE looks to me pretty much like any other development IDE, and I have used rather lot in my time: Visual Studio, Eclipse, CodeWarrior, Idle, FreerIDE -- my PC is littered with them.

Opening uVision in the RealView Microcontroller Development Kit for the first time, I don’t get a blank project. Instead, I get a pre-built project called Measure which uses the analog inputs of the AT91M55800A to simulate a datalogger. Cool! I am sure I will be able to re-use some of the code here. Pressing the build button is irresistible and the project compiles with no errors. Selecting Debug then takes me to a debugger perspective (a bit like Eclipse). Pressing F5, as always, starts execution and away it goes. It boots up with a simple menu system on the serial port asking me to set the time and interval for logging. I do this and hit D for display and very little seems to happen. The line in the logic analyzer window remains flat. Then I notice some buttons off to the side of the simulation; one is labeled Analog0 0..3.0. (I think it should be Analog 0.0..3.0V). Pressing this button seems to inject values into the analog port AD0 of the simulated MCU. The logic analyzer shows the voltage rising and falling on AD0 and the serial port shows the values on AD0 changing over time.

Tools of the Trade

Now that I have decided on the LPC family it’s time to try out the tools. The Device Database entry for the LPC2148 has a link to Evaluation Software. Clicking on that link takes me to a form that allows me (once I have filled it out) to download an evaluation of ARM’s RealView Microcontroller Development Kit. The eval software is a fully functional toolset. I just can’t build more than 16K of code with it, which certainly doesn’t matter at this stage.

Finalizing Choice

Today, I have decided to try and choose between Philips and the other vendor for my application. The choice for me has to be the Philips LPC part. It’s cheaper, has example code related to USB and is fully simulated in the tools.

BTW, you are probably wondering who the other vendor is. Well, I’m not going to name them here, since coming second isn’t going to make them send me a Christmas card. If you really want to know, just do what I did in the Device Database and you might draw the same conclusions.

What is a Device Database Entry?

Now that I have narrowed my choice down to nine, it is time take a look at each of these entries in the Device Database in a bit more detail. From the results table I get from the parametric search, the Philips parts only seem to differ in the in their Flash size. Two of the other vendors’ parts have Ethernet and two don’t. I don’t want Ethernet so I can discard two chips right away.

Clicking the entry in the results table for LPC2148 takes me to a page all about it. There is a lot of information here, everything from datasheets to example code. There is even a list of consultants who could make the application for me.

As I mentioned in a previous posting I have been burned before when it comes to parts actually existing. Clicking on the Distributors link takes me to a site called findchips.com with a preconfigured search for the LCP2148. The site lists 2 distributors that carry this part. One says “call” for pricing, the other is more up front.

The database behind the curtain

I looked at the Supported Devices page again today, and noted the paragraph at the top of the page which says:

“Following is a list of the ARM chips that are supported by the Keil development tools. If your specific device is not listed, please contact Keil, using the Device Database Problem Report and provide us with details so we may include your chip in a subsequent product release.”

A database! Hmmn….

I then scrolled down to the bottom of the page and saw something I had missed the first time:

A complete list of all supported devices is available at:

http://www.keil.com/dd/

Clicking this link made things worse! Now I had every vendor of every MCU known to mankind! Infinite choice (well almost). This wasn’t Subway for lunch; it was Subway for my future lifestyle!

But... top-left again there was help at hand. A sidebar called the “Device Database”. Perusing these links, I discovered that the list of MCUs that I had stumbled across wasn’t just a static page. It was a dynamically created page from the result of a database search. Wow! Now this was something to play with…

Further down the sidebar I found “Parametric Search”, which took me to a form here:
http://www.keil.com/dd/search_parm.asp

So here was what I wanted: A search engine on a database of over 1000 MCUs from a whole lot of vendors that let me enter my criteria for the MCU of my dreams. I filled out the web form and “Hey Presto!” there was a list of 9 MCUs that fit the bill.

“With a little help from your friends”

My friends in this case being the guys at Keil (which ARM bought last October). Looking down the Google results for ARM Microcontrollers somewhere near the bottom is a reference to http://www.keil.com/arm/ which talks about all of the tools that are available from ARM and Keil for ARM processor-based MCU development.

I clicked “Supported Devices” (http://www.keil.com/arm/chips.asp ) and “Bingo!” there is a list all the ARM MCUs from all of the vendors. Great!

Well perhaps great with a small “g” since it doesn’t immediately give me the kind of compare and contrast I am looking for. I feel like I am in Subway- I can have any kind of sandwich made with any kind of meat, vegetable, cheese, sauce and bread, but there isn’t anyone there to tell me if I’m going to like what I order…

Choosing an MCU- Argh!

This is a little bewildering since there are so many MCUs and each vendor has a different kind of search or table on their website to help me choose the right MCU. There are over 125 ARM processor-based MCUs available, each with its own sets of peripherals, performance and price. The kind of search I want to do is a parametric search, where I can compare and contrast MCUs with my list of requirements. Most MCU vendors’ websites have some kind of table of features or parametric search and that would be fine if I were loyal to one vendor, but I’m not! I want to compare and contrast ARM MCUs across all the vendors to find some that fit the bill. Once I have a sensible subset of the 125+ ARM processor-based MCUs out there I can hone in on the best fit. And then there’s the cost and availability question. In the past, I have had to re-spin entire projects simply because the glossy data sheets for the MCUs don’t tell you that the MCU is way out of the budget or won’t be available until the next millennium!

Not Choosing an MCU

Before I try and choose and MCU, I better try and figure out what I want the MCU to do. Basically, I want it to do as much as possible and I don’t want to have to add a bunch of extra hardware to build the application. From the LogStick requirements in my previous pos, I think I want the following:

• Some A/D to connect up the sensors
• A real-time clock.
• Lots of on-chip Flash to store the software and the logs. I guess want some kind of scalability here, I don’t really know how big the application is going to be so finding an MCU family with different memory sizes would be useful.
• USB connectivity to connect the LogStick up to the PC so it can dump its data
• A sleep or power-down mode when the LogStick isn’t logging
• Some on-chip RAM working area would be desirable
• A watchdog timer. Gotta have one of those for it to be a true embedded application. Well, I don’t write perfect code that deals with every eventuality, so having something that reboots the application if it’s gone bye bye is essential. (Visualize son banging LogStick on the concrete shouting. “It’s stopped working!”)
• JTAG debug, personal preference perhaps, but I think debug monitors and bits of wet string rather archaic these days.

Googling ARM Microcontrollers shows me that there are at least four manufacturers out there with ARM processor-based MCUs. Now which one should I go with?

Thinking about Kids

I thought some more about the LogStick today and thought about the user base—kids!
Hmmm…Not the most patient, careful or sometimes willing users of technology. I sat down and came up with the following set of product requirements:

Key Product Requirements

Simplicity
A child of 9 should be able to use this:

• Easy to handle—like a stick
• Easy to connect—use USB (not MMC cards, not Ethernet)
• 2-button input interface
• Sensors automatically register themselves
• Audio output interface (beeps, bings, boings, etc.) with additional pulsing LED (used in noisy environments or when battery is low)
• Simple 8-segment green, yellow, red representing state of collection: red = no data yet, yellow = reasonable dataset, green = good dataset OR green = buffer empty, yellow = reasonable dataset, red = buffer full (need to decide!)

Instant Gratification
A child of 9 should enjoy using this:

• Simple setup in classroom before children deploy device (may be done by teacher or by children).
• Lots of audio/visual feedback (beeps, bings, boings, computer voices, etc.) with additional pulsing LED (used in noisy environments or when battery low)
• Connect and Display Results! Connect via USB that automatically invokes graphing package on the PC to show results of logging—immediately!
• Running out of power is a major turn-off

Ruggedness
Children between 9 and 14 will use this again and again:

• Drop from > 3 feet and still works
• No parts to break off
• Easy to manipulate with small hands
• Hard to get into! (Even a destructive 11 year old with a multi-tool would find it hard to break it) Easy to add logging sensors in the field
• Rechargeable or uses basic 9 Volt battery. (Could save state during battery replacement, which could potentially lead students to “tend the garden”—replace the battery in situ.) Or is rechargeable using USB (overnight is ok)
• Waterproof or at least drip proof.

Battery Life
Needs to run for over 1 week on a battery charge or on a standard 9V battery. Experiments are unlikely to exceed one week.

• Lesson 1: deploy LogStick in the field.
• Lesson 2: recover LogStick from the field and immediately graph results.

Price
School equipment either needs to be really cheap or subsidized. If not subsidized, the cost should be in the low 10’s of $.

Note: USB memory sticks with ARM processors in them (I think) are really cheap now.

In my next entry, I’ll figure out which MCU to use.

The LogStick Concept

Once I got the idea of blogging my experience using the ARM MCU tools to do an application for an ARM processor-based MCU, I then had to think about what it would be. It seemed rather complicated. If I picked a particular market segment, it wouldn’t exactly have mass appeal. If picked a particular commercial application I would be competing head-on with the guys who do it for real. If I did some kind of complex algorithmic application it might be a turn off to many. And then…
I took my son to school one day and bunch of moments in the past few years slotted together in my mind and I thought of the LogStick.
Here is the idea:
The LogStick is a tool to allow children between the ages of 9 and 14 to conduct experiments that require the collection of small remote sets of data (less than 10,000 entries) that are associated with time. The data sets can then be processed on a host PC system back at their school. The tool is generic, allowing for the following kinds of data to be collected:

• Temperature
• Light level
• Sound level
• Electrical conductance
• User activated snapshot

The tool would support the collection of generally one and in some cases two types of data at the same time.

All data items collected are time stamped against a real-time clock in the LogStick. This is YY:MM:DD, and HH:MM:SS (no further granularity required).
Since I like the name LogStick I have moved this blog under a blog of the same name and used a commercial blogging tool which all in all should make the whole experience better.

DISCLAIMER

The statements, opinions and conclusions outlined on this blog and associated website are those of the author- Rod Crawford. They in no way represent those of my employer or anyone else. They are based on my own studies, research and personal experience. This blog has been developed for the purposes of informing, educating and me having fun. It is not intended to be a comprehensive guide to embedded software development or even necessarily correct! Further, no person should rely on any content on this website/blog or on the opinions or conclusions outlined on this website/blog without first obtaining advice from a suitably qualified professional person. The author expressly disclaims all and any liability and responsibility to any person or corporation, in respect of anything and the consequences of anything, done or omitted to be done by any such person or corporation in reliance, whether wholly or partially, upon the whole or any part of the contents of any of this blog and associated website or any other website referred to on this blog or website.

Why am I doing this?

Well if you Google me (“Rod Crawford ARM” should do it), you should find I am a marketing guy at ARM (not someone who is into spiders). In fact, I’m a marketing guy at ARM who is developing some collateral for ARM’s latest RealView Microcontroller Development Kit–that’s my day job.

So I got to thinking…My thought process went like this:

If I am going to make this collateral really good, I really need to use the tools, rather than play a bit with them and write about that, or record the exploits of someone who might have used the tools, or try and regurgitate the existing things that other collateral has, or believe what the other marketing folk tell me.

After all I am a hands-on kind of guy! I’m a dyed-in-the-wool computer scientist, I spent the 1980s building software development tools for everything from 4-bit to 16-bit micros, and this is a good chance to get back to my roots and spend some time with the new 32-bit ARM MCUs. It’s been about 6 years since I wrote the Forth for my mate Andrew’s Evaluator-7T board. Now that was a lot of fun and I’m starting to getting itchy fingers again.

Maybe I ought to do some kind of real project and base my collateral on my direct experience?

And then I thought: Maybe I ought to blog the experience!

And so here follows the blog of my experience.

Actually, I checked in with “Da Management” at ARM and after a few “Mmmm’s and Er’s?” they blessed my doing this, so long as it was in my spare time and wasn’t some kind of glorified techie ad campaign for them. So here follows my personal experience in using the RealView Microcontroller Development Kit to make a real embedded device.

(The collateral stuff that I hope comes out of this I will write in my work time and it will go on an ARM website.)

Hello!

This is my first entry on the blog about creating an MCU application. This first bit of the blog is about how this blog came about. It covers the past few months and so I make no apology for it being in the past tense. If it hadn’t happened in the past you wouldn’t be reading this blog in the present.