Creating a bootable microSD card

In my mind one of the nicer features of the Overo COM computer is it will boot directly from a properly prepared microSD card.  The 'advantage' to having the Overo COM computer boot up from the microSD card first is you do not have to make any modifications to the onboard NAND image - if you trash the installed Operating System on the microSD card you can just remove the card and the Overo COM computer will bootup off the NAND rom code instead - I can think of several situations where this could be a handy feature!

The Overo boot rom sequence checks the microSD slot first to see if there is a device and if one is found it checks to see if there is a boot sector prior to checking the onboard NAND Rom.  If a boot sector is found on an installed microSD card the boot loader will attempt to load and execute the boot sector information.  In order to create a bootable microSD compatible with the OMAP3 boot ROM, you must set the geometry of the microSD card correctly otherwise the boot rom will not recognize the microSD card as a bootable device and pass control on to the code loaded in the NAND memory onboard the Overo COM.

The following instructions are performed on your development system - they are performed in a Linux environment and since your Overo development system is a Linux environment that seems like the logical machine to use (grin).  In order to configure the microSD card for the proper device geometry you use the fdisk "Expert mode".  The following instructions outline how to partition and format a bootable microSD card.

The following information describes the steps for setting up a brand new 2GB microSD card.  Since there are several different sizes of microSD cards I have included the instructions to setup the different sized cards.  The majority of the difference is in the calculation of the number of 'sectors' that you will need to enter when setting up the geometry of the microSD card.

One thing you will need is a flash card reader that is capable of working with microSD HC cards as well as microSD cards.  If the flash card reader cannot read (and write) to microSDHC cards then you will be limited to a maximum of 2-gig microSD card size (maximum size of microSD card - the HC specifications allow for up to 32-Gigs of storage).  If your machine has a SD Card slot check to see if the machine is capable of reading (and writing) to SDHC cards - if not obtain an external USB 2.0 card reader that does.  You will be much happier with the additional storage capacity of the SDHC cards.

Here is one type of microSD card reader that is USB 2.0 capable - it can be found here at Amazon.com - It is a great deal for the price!


Insert the microSD card into the development machine's flash card slot (or the external card reader). You may need to use a microSD to SD card adaptor to fit your slot.  On my Ubuntu 8.04 machine, the newly inserted card shows up as /dev/sdc and that is the device name that I will use for the following instructions. You will need to substitute the proper device name for your machine as I am sure our two machines are not configured the same (grin). You can use 'mount' or 'df' to see where the card mounts on your machine.  If you type 'mount' without anything else it will show you what is mounted where - df, which stands for 'disk files', shows you the information about the different partitions on your machine along with the device names and mount points.

Since your development system probably is configured to 'auto-mount' mountable devices and the microSD cards come formatted with Windows filesystems (seems to be the pervasive standard) the microSD card was most likely mounted to the filesystem automatically.  We do NOT need the card to be mounted at this time as we need to change the storage geometry of the card.  Let's unmount the device's existing file system before we get started with fdisk (type the command listed in blue then press ENTER):

 sudo umount /dev/sdc1

NOTE: Substitute the device name for your microSD card in place of the 'sdc1' listed above.

Partitioning the card

To perform the partitioning steps we need to launch the fdisk application and create an empty partition table on the microSD card. Note that the argument for fdisk is the entire device (/dev/sdc) not just a single partition (i.e. /dev/sdc1):
 sudo fdisk /dev/sdc      <--- be sure to specify your device for the microSD card here

Command (m for help): o

Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Let's first look at the current card information:

Command (m for help): p

Disk /dev/sdc: 2032 MB, 2032664576 bytes
64 heads, 63 sectors/track, 984 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Disk identifier: 0x00aa8e5c
Device Boot Start End Blocks Id System

Note the card size in bytes - I have it listed in RED above but it displays the same as the rest of the information on your development system. Write the information down as we will need it later in the process.  This is also one of the differences I mentioned earlier for creating bootable microSDHC cards.

Now go into fdisk "Expert" mode:

Command (m for help): x

Next we will set the geometry to 255 heads, 63 sectors and a calculated value for the number of cylinders required for the particular microSD card.  The 'calculated number of cylinders' is the difference for the different sized cards and is calculated the same across microSD cards.

There are a couple of methods we can use to calculate the number of cylinders for a specific microSD card:

1.  We can do it the hard way - To calculate the number of cylinders, we take the 2032664576 bytes reported above by fdisk divided by 255 heads, 63 sectors and 512 bytes per sector:
2032664576 / 255 / 63 / 512 = 247.12 which we round down to 247 cylinders.

***OR***

2.  The easy way - divide the size in bytes by 8225280 (which is 255 * 63 * 512) to get the number of whole cylinders (drop the fractional part which is also done in the "hard way" method).
2032664576 / 8225280 = 247.12, drop the fractional part to yield 247 cylinders.

Personally - I prefer the easy way myself!

Now that we have the number of cylinders we need for the specific geometry we are setting up on the microSD card we can proceed to do precisely that:

Expert command (m for help): h

Number of heads (1-256, default 4): 255

Expert command (m for help): s

Number of sectors (1-63, default 62): 63

Warning: setting sector offset for DOS compatiblity

Expert command (m for help): c

Number of cylinders (1-1048576, default 984): 247  <--- our calculated cylinder count

At this point we have configured the settings for the geometry of the microSD card and are finished with the 'expert' mode in fdisk - we need to return to the main mode to finish up the configuration of our microSD card and create a new 32 MB FAT partition to allow the Overo COM boot rom to recognize our boot partition:

Expert command (m for help): r

Command (m for help): n

Command action
e extended
p primary partition (1-4)

p

Partition number (1-4): 1

First cylinder (1-247, default 1): 1

Last cylinder or +size or +sizeM or +sizeK (1-247, default 15): +32M

Change the partition type to FAT32:

Command (m for help): t

Selected partition 1

Hex code (type L to list codes): c

Changed system type of partition 1 to c (W95 FAT32 (LBA))

And mark it bootable:

Command (m for help): a

Partition number (1-4): 1

Next we create an ext3 partition for the rootfs - the 'boot' partition we created is just to allow boot-up of the system - the next partition is where our operating system and filesystem will live:

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p

Partition number (1-4): 2

First cylinder (6-247, default 6): 6

Last cylinder or +size or +sizeM or +sizeK (6-247, default 247): 247

To verify our work, let's print the partition info:

Command (m for help): p

Disk /dev/sdc: 2032 MB, 2032664576 bytes

255 heads, 63 sectors/track, 247 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x00aa8e5c

Device       Boot     Start     End       Blocks       Id         System

/dev/sdc1     *           1         5        40131        c         W95 FAT32 (LBA)
/dev/sdc2                 6      247    1943865       83         Linux

Up to this point no changes have been made to the card itself - all of the changes exist in the partition table located in memory, so our final step is to write the new partition table to the card and then exit:

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.

Syncing disks.

At this point we have exited the fdisk program after it altered the partition table of the microSD card.  We still have some things to do to the microSD card before we can use it with the Overo COM machines...

Formatting the new partitions

As you recall - we created two distinct partitions on the microSD card after we changed its geometry - one partition was a FAT-32 partition of about 23-megs in size and the second partition was a Linux ext3 partition comprised of the rest of the remaining microSD card storage space.

We format the first partition as a FAT file system (the -n parameter gives it a label of FAT, you can change or omit this if you like):

 sudo mkfs.vfat -F 32 /dev/sdc1 -n FAT

mkfs.vfat 2.11 (12 Mar 2005)

NOTE:  If you run into the issue where your development system does not recognize the mkfs.vfat command you need to install the mkfs.vfat application.  Some Linux versions do not install the DOS format program normally as part of their installations.

We format the second partition as an ext3 file system:

 sudo mkfs.ext3 /dev/sdc2

mke2fs 1.40.8 (13-Mar-2008)

Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
121920 inodes, 485966 blocks

24298 blocks (5.00%) reserved for the super user

First data block=0
Maximum filesystem blocks=499122176
15 block groups
32768 blocks per group, 32768 fragments per group
8128 inodes per group

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Writing inode tables: done

Creating journal (8192 blocks): done

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

At this point in the process we now have a microSD card with the proper storage geometry and properly formatted partitions.  Our next objective is to load a bootable operating system on the microSD card.

Installing the boot files

There are three files required on the first (FAT) partition to boot your Overo:

1.  MLO :

The boot-loader loader - this small program is loaded into the OMAP3 processor's static RAM.  It does some minimal configuration of system memory and io pins and then loads the second file.

2.  u-boot.bin :

The boot loader - This low-level application performs so housekeeping and loads the Linux kernel, then transfers control to the Linux kernel.  Probably would be considered the 'grub' of the Overo system.

3.  uImage:

The linux kernel - the actual kernel that will control the operating system operations.

You can build these components of the boot partition yourself or download pre-built images.  The uImage kernel is the one created during the Bitbake/Openembedded build process so would need to be loaded into the boot partition so it matches the rootfs installed in the second partition.  Failure to do this can (and usually does) result in different types of runtime issues from wrong kernel drivers (modules) all the way to kernel panics.  One advantage of building the different components yourself is you know what exactly is in them - if you actually study the source code that is (grin)...  Since the MLO initially configures the Omap processor pin configurations you will NEED to build this file if you need to change the default configurations.

It is very important that these three files have precisely these names and are loaded into the boot partition in a very specific order.  The Overo boot loader does not use the names per-se but instead loads the FIRST installed file on the boot partition (MLO) which does look for specific name 'u-boot.bin' when it is time to load the boot loader.  The boot loader also looks for the specific name uImage to load the Linux kernel.

Given the above information it becomes apparent why the names of the file must match and also the sequence used to load the specific files into the bootable partition on the microSD card.

It is beyond the scope of this posting on "how" to create the above listed files - this is an exercise left up to you (and a later posting - grin).   Once you have completed building or downloading these files, mount the FAT partition of your microSD card. This example will assume that you have mounted it at /media/card:

NOTE: If there is not a /media/card mount-point you will need to create it using the following command:

sudo  mkdir  -p   /media/card

Now mount the microSD card filesystem to the development system's filesystem:
sudo  mount  /dev/sdc1  /media/card  <--- remember to use your device specification here
Due to constraints of the mask boot ROM in the OMAP processor, MLO MUST be written first:
({directory-path} is the directory path to where the MLO-overo file is located on your system)

sudo  cp  {directory-path}/MLO-overo  /media/card/MLO

Then copy u-boot and the linux kernel to the card:
(The order of the copy commands is not important here - just that MLO was copied to the boot partition FIRST)
sudo  cp  {directory-path}/u-boot-overo.bin   /media/card/u-boot.bin

sudo  cp  {directory-path}/uImage-overo.bin   /media/card/uImage

We are done with the construction of the boot partition on the microSD card so you can now unmount the FAT partition:

sudo umount /dev/sdc1

At this point you have a bootable FAT partition.  Pat yourself on the back - grab a beer (if of legal age!) and enjoy!!!  You have accomplished something here today!

We still have one final task to complete in order to have a full-fledged bootable operating system on the microSD card - The final step is to untar your desired rootfs onto the ext3 partition that you created above.  It is outside the scope of these instructions - the rootfs file referenced here is created as part of the build process performed by the Bitbake/Openembedded development system for the Overo COM.  You can download pre-compiled versions from the Overo Development site or create your own using the Bitbake/Openembedded development system.

Note that this step can be dangerous. You do not want to untar your Overo rootfs onto your development machine - be careful!

This example will assume that you have mounted it at /media/card - following step performs this task:

sudo mount /dev/sdc /media/card

Now untar your desired rootfs - very important, you want to be in the partition on the microSD card to perform the untar operation!  Perform the following step!

cd /media/card

VERY IMPORTANT - Be sure to list the full path to the rootfs file in the following instruction...
sudo tar -xvjf   /path/to/omap3-console-image-overo.tar.bz2

Once the system has finished installation of the root filesystem on the second partition of the microSD card you can check it out using the ls command to see the content.  You can also use the df command to see how much of the second partition is used and how much free space there in the microSD card.  Once you are satisfied things look correct you can unmount the microSD second ext3 partition from your development system:

sudo umount /dev/sdc2

Congratulations!!!!!  You have reached that thrilling moment of truth!

You are now the proud owner of a microSD card with a bootable Overo operating system in it. 

If you have done everything correctly and you have a viable MLO, u-boot.bin, uImage and rootfs system installed on the microSD card and the uImage and rootfs cross-compiled correctly (a lot of if's I know!) you should be able to boot up the Overo from the microSD card simply by inserting the microSD card into the Overo microSD card socket and applying power to the Overo COM machine.  Watch the information displayed from the console output of the Overo during bootup to verify it is indeed booting from the microSD card.

Let me know how it goes for you!  Good, bad or indifferent I want to hear from you!!!

A couple of notable items:

1.  You want to use microSD cards that are rated as Class-6 cards.  There are several Class ratings and the lower numbers are slower microSD cards.

2.  You get what you pay for in microSD Cards - if you use a cheap card then you most likely will have issues later - I did not say inexpensive cards as there are some good inexpensive cards out there - I am referring to "cheap" inferior cards that use old flash rom technologies.

3.  If there is an interest I will build pre-configured microSD Cards for a small fee - you supply the cards and I will reset the geometries and perform the partitioning and formatting operations - let me know if this is something of interest to my readers (grin).  For an additional small fee I will load the cards as well with the boot partition and root filesystem.  Contact me here if interested (leave me a comment)...

A second item - I have listed several hardware sites where you can get really good pricing and I make a very small commission from the sale - I realize this seems tacky but I have to do something given the current financial hole I find myself in at the moment.  

Thanks for understanding and a Special Thanks to those who help out!

Time to a Build...

Having been away for a while I decided I needed to just "start over" with the development system.  Since it has been over a year since I have used my development system I figured there 'may' have been some changes and upgrades done to the original bitbake/openembedded development environment and with the actual applications for the Gumstix line.

After configuring a new virtial machine (VMWare) and loading Ubuntu 8.04 Desktop I followed the instructions on the Gumstix WiKi (web link below) to install the bitbake/openembedded development system.  I use VMWare's free server package to allow me to run several different virtual machines on my development home computer.  If I did not use my machine in this fashion it would be a waste of resources (and I can do other things) while the Gumstix development system is performing long cross-compile operations - they can run as long as 18 - 24 hours at times.  I use the Linux Ubuntu 8.04 workstation (also free) as the core development system environment as that is the OS I am comfortable with - others use newer versions of Ubuntu along with other different versions of Linux (Debian, Centos, etc.) and have good success - I just like the Ubuntu 8.04 release and since the compile operations for the Gumstix is performed in a cross-compiler environment running Ubuntu 8.04 has minimal effect on the compiled output.  A Note:  Make sure you have all the tools or equivelent tools installed on your version/flavor of Linux to allow the Bitbake/Openembedded developement system to perform it's job otherwise you will get some errors during a build - sometimes very difficult to debug.

Speaking of installed tools - A couple of items I ran into during the installation and testing of the cross-compiling bitbake/openembedded environment - just some things to watch out for...  The list of additional items needed on the WiKi page left out the 'gettext' application - this is needed for some parts of the tools compilation process near the beginning of the environment build in performing the omap-console-build process.  It seems to me this was forgotten over a year ago - I guess they have some issues keeping track of the little problems but given the complexity of the environment it is understandable.


You can find the environment installation instructions here:  Setting Up a Gumstix Overo Build Environment   To install the 'missing' application just add 'gettext' to the list used for the apt-get installation for Ubuntu otherwise whatever your Linux version requires.  One nice feature of the Bitbake/Openembedded development system is the system will give you fairly accurate error messages so you should be able to determine if there are any tools missing that are required by the development system.

Once I had the development system setup and configured by the instructions listed above I built the omap-console-image package as instructed.  The installation (download of source code, dependency resolution and compiling of the required tools) of the cross-compiler toolsets was performed by the Bitbake/Openembedded system and the omap-console-image package was created as expected.  I have done this several times so know when it works and when it does not.  Only took about 16 hours or so to perform this 'initial' build due to all the tools needing to be compiled the first time through.  If you think you don't need to perform all of the steps in the setting up of the development environment you really do.  The last couple of steps (compiling the omap-console-image) actually installs the bulk of the specific tools you need on your version of Linux as they are tuned to your version.

Now the development system has performed the initial installation of all the software tools needed to build a console version of the Gumstix operating system (actually a version of Debian Linux) I performed the build of the 'omap-desktop-image'.  This image is the GUI version of the console image so uses the console image built components and additionally builds (cross-compiles) the Graphica Interface and a list of applications to install in the image.  Performing this build gets the GUI components compiled for the Gumstix so the next time they are needed they have already gone through the cross-compile process which saves considerable time when you make changes to the installed applications in an image.


Thank you!

Space to play in

Sorry for no postings in the last 6 - 7 months.  I have changed jobs and have been working in a vertical learning curve for the moment.  I now work in the Information Security realm and it is very interesting where Information Security has gone to in the last three or so years - more 'compliance' than 'security' - I guess the suits are looking for ways to 'understand' the concepts (grin) and feel warm fuzzies so they can sleep at night (I know better so I don't!).  As a distraction, hopefully I can now do some more postings and work with the Gumstix that will be of interest to others.  I may even be able to work the Gumstix into a security roll - who knows.

About a year ago I posted information on the use of a MicroSD card to increase the usable storage in a Gumstix system. At that point in time the largest, reasonably priced, microSD card was 8-gigs. Today you can find 16-Gig MicroSD HC (High Capacity) cards at less cost than the 8-Gig MicroSD HC cards of a year ago.  A search on Google for 'microsd card' yields around 4,990,000 hits on the subject.  Most of the median priced MicroSD HC cards of today boost Class-6 (6-MB/sec) data transfer rates.  This is three times faster than the older Class-2 devices.  If your applications run mainly in RAM memory the actual speed of the MicroSD card will only play a part when loading applications or data - in this environment you really don't need the Class-6 devices if cost is the main concern otherwise So what does this have to do with Gumstix computers?  Plenty!  If you are planning to build a Gumstix machine and need more than embedded basic functionality you will need more storage space.  A couple of ways to get more space is to either connected additional external storage through one of the USB ports or to insert a MicroSD card into the Gumstix COM MicroSD receptacle on the board.  Unless you need more than 16-Gigs of storage capacity the MicroSD card method is the better of the two - less hardware and much lower power requirements.  If you need more space then I would suggest a SATA (Serial ATA) solid-state drive, 32-Gigs to 64-Gigs MLC drives are reasonably priced but slower than SLC based drives, with a USB to SATA adaptor.  Of course you will need a USB hub that supplies power as the Gumstix COM does not have enough power capacity on it's USB ports to handle the power needed.

Some microSD cards that work well with the Overo COM computers:



Note - I think these are Class-2 Devices so will read and write at 2-megabytes per second.  Given the cost that is not bad at all.


On a different note - I know this sounds really lame but if you don't mind would you please click on one or two of the ad's liste here???  It does not cost anything to you and it may help offset the cost of hardware to continue working with the Gumstix machines.

 Thank you!

LCD + Touchscreen Interfacing

First - Sorry for the lack of posts here. I was down in the hospital with acute appendicitis (had to remove the appendix and a small part of the large intestine where it attached due to extreme infection!). Needless to say that was not fun!!!

Now - One of the items I am looking to use with the gumstix computer is a LCD display with touchscreen capability. Gumstix sells a Samsung 4.3 inch (diagonal) LCD display (LTE430WQ-FOC) for the gumstix computers. The description and specifications of the LCD display are:

Description
LTE430WQ-F0C is a TMR(Transmissive with Micro Reflective) type color active matrix TFT (Thin Film Transistor) liquid crystal display (LCD) that uses amorphous silicon TFT as a switching devices. This model is composed of a TFT-LCD module, a driver circuit and a back-light unit and a Touch Screen Panel(TSP). The resolution is 480 X 272 X RGB dots and can display up to 16.7M colors.

Features
- Transmissive with Micro Reflective type and back-light with 10 LEDs are available.
- Visible in outdoor & back-light off condition with reflectivity.
- Using the Touch Screen Panel (Film to Film-Glass type).
- VA(Normally black) mode.
- 24-bit RGB Interface (8-bits per color)
- DE(Data Enable) & SYNC mode - DE, Vsync, Hsync, DOTCLK

Applications
- Display terminals for PMP(Portable Multimedia Player) , Portable CNS(P-CNS)
application products.
- Display terminals for AV application products

In order to use the LCD display with the computer you also need the LCD interface board which is also sold by Gumstix. The Palo-43 board contains all the LCD interfacing circuits, the power supply for the LCD and Gumstix Com board and voltage level shifting hardware needed to use the Samsung LCD display with the Gumstix COM computers.

Not only are the basic interfaces on the board to drive the LCD display there are also other interfaces for audio in and out, USB OTG connectivity, USB console connectivity and interface connections that allow access to some of the other interfaces available on the Gumstix COM computers (I2C, SPI, A/D input PWM output and so on). The description and specifications of the LCD display are:

LCD-ready for 4.3" Samsung touch-screen Touchscreen controller Provides 16 bits per pixel USB mini-AB with OTG signals USB mini-B connector with USB Host signals USB console Signals available on 0.100" through-holes at 1.8V logic ---Two (2) two-wire serial ports ---One 1-wire port ---6 PWM lines ---I2C port ---SPI bus 6 A/D input lines and processor control signals.

4V to 5.5V input

(2) 70-pin AVX 5602-24 connectors

118.3mm x 67.25mm

Four (4) x #0 mounting holes for direct connection to an Overo COM Four (4) x #2 mounting holes to secure Palo 43 inside a casing

OK - Great! There is an LCD display and interface board for the Gumstix Overo line! I thought that was wonderful, until I started using it that is. Don't get me wrong - it works as advertised and does a decent job. It's just that I wanted something with a wee bit more resolution than is afforded by the Samsung display. 480 X 272 may be great for a smart-phone but this is a full blown computer system and I want MORE resolution!! (grin).

In my search for a higher resolution LCD display I ran across a question asked by someone else on the Gumstix forum. For those who don't know the Gumstix forums contain a wealth of information about the Gumstix Overo COM line of computers and the expansion boards. This is a meeting place where developers and hardware designers go to bounce questions off each other and where the Gumstix software developers hang out (and answer questions too!). To really glean the benefits of the forums I would strongly suggest using the "search" capabilities of the forums to find answers to questions FIRST! From what I have seen there are more repeat questions because people don't search for the answer first - it probably has already been asked and answered multiple times on the forums!

The question on the forum was about the possible use of a different Samsung LCD display with touchscreen capabilities but this display is 800X480 instead of 480X272. The part number of the display is LMS480KF02 with the following specifications:

Description
LMS480KF02 is a TMR(Transmissive with Micro Reflective) type color active matrix
TFT (Thin Film Transistor) liquid crystal display (LCD) that uses amorphous silicon TFT
as a switching devices. This model is composed of a TFT-LCD module, a driver circuit and a back-light unit. The resolution of a 4.8" contains 800 x 480(RGB) dots and can display up to 16.7M colors.

Features
- Triple-Gate Technology applied
- Transmissive with Micro Reflective type and Back-light with LED is available.
- TN (Twisted Nematic) mode
- 24bit RGB Interface
- Back Light with 14 LEDs (Light Emitting Diode)

Applications
Display terminals for PMP(Portable Multimedia Player) , Portable CNS(P-CNS) ,
AV , UMPC (Ultra Mobile PC) application products.

Hmmm - this may be the answer I am looking for!

Looking at the two display's specifications and drawings indicated they are basically the same in terms of electrical connections - they both use a flexible circuit board with a 45-pin connection for the electrical signals. Both have the same electrical connection layout (with one or two exceptions for the signal definitions but they look equivalent). The biggest exception is the Gumstix Samsung display uses a single string of 10 LED's to provide the LCD back light whereas the possible replacement LCD uses two strings of 7 LED's for the back light. I have not determined if this will be an issue yet or not. The LED back light power supply on the Palo-43 board is rated for up to 40-Volts maximum and up to 1.2-amps of current. I suspect I will need to wire the backlight LED strings in parallel with a ballist resister in each string to run all the back light LED's on the replacement board. I suspect wiring in series will raise the total forward voltage required too high approaching the maximum voltage rating of the PWM Boost-Switching Regulator on the Palo-43 board. Both Blue and White LED's tend to have around a 2.5V - 2.8V forward voltage drop so fourteen LEDs in series would present a 35V to 40V or greater voltage requirement to drive the LED string. This is too high for the boost-voltage regulator to handle. Wiring the LED strings in parallel with a ballist resister in each string would lower to total voltage requiement to approximately half that of the series string. Increasing the total current to drive the two strings is not a problem - all that is required is to replace the 10-ohm feedback resister with something a smaller value resistor - say 5 to 7 ohms which would give around 30 - 40 ma of LED current total. Driving each string at around 20-ma is a good compromise for light intensity vs longivity of the LEDs.

For those interested the regulator is the Micrel MIC2297 and you can find the specification sheets on the Micrel website (gotta love the Internet!). Here are the condensed specifications for the device:

Features:

2.5 to 10V input voltage range
Output voltage up to 40V
1.2A switch current
600KHz PWM operation
Trimmed 200mV feedback voltage
OUtput over voltage protection (fixed or adjustable)
PWM Brightness Control
DAC Brightness Control

The following chart shows the pin out of the LCD display sold by Gumstix along with differences between the 4.3-inch LCD and the 4.8-inch LCD displays.
Note the pins highlighted in RED.

Gumstix 4.3-inch LCD electrical pin out chart

Pin#    Symbol    Function       Remark
1       VSS      Ground
2       VSS      Ground
3       VDD      Power Supply   (2.5 or 3.3V)
4       VDD      Power Supply   (2.5 or 3.3V)
5       R0       Red Data       (LSB)
6       R1       Red Data
7       R2       Red Data
8       R3       Red Data
9       R4       Red Data
10      R5       Red Data
11      R6       Red Data
12      R7       Red Data       (MSB)
13      G0       Green Data     (LSB)
14      G1       Green Data
15      G2       Green Data
16      G3       Green Data
17      G4       Green Data
18      G5       Green Data
19      G6       Green Data
20      G7       Green Data     (MSB)
21      B0       Blue Data      (LSB)
22      B1       Blue Data
23      B2       Blue Data
24      B3       Blue Data
25      B4       Blue Data
26      B5       Blue Data
27      B6       Blue Data
28      B7       Blue Data      (MSB)
29      VSS      Ground
30      PCLK     Pixel Clock
31      PON      Display on/off
32      HSYNC    Horizontal Sync Signal
33      VSYNC    Vertical Sync Signal
34      DE       Data Enable
35      PWRSEL   VDD power select (High:3.3V / Low:2.5V)
36      VSS      Ground
37      Y2       Y_Up
38      X2       X_Left
39      Y1       Y_Bottom
40      X1       X_Right
41      VSS      Ground
42      VLED1-   LED 1 Cathode
43      VLED1+   LED 1 Anode
44      NC       Non Connected
45      NC       Non Connected

The three red highlighted lines in the pin-out listing above are the differences between the two displays. Pin-35 on the Gumstix LCD is used to inform the circuitry on the LCD that the power supply voltage is 2.5 or 3.3VDC - on the 4.8-inch LCD pin-35 is ground! DO NOT CONNECT the 4.8-inch LCD directly to the Palo-43 as this will short out the 3.3-VDC power buss on the Palo-43 board. I am looking into a mod for the board that will allow either LCD display to be connected without causing problems with the 3.3-VDC buss.

As for pins-44 and 45. On the 4.8-inch LCD display these pins are used for the second back light LED string. I have not checked to see if one string will light up the LCD panel - if it will then the use of the second LED string may not be required - otherwise I will need to connect the two pins correctly in parallel with pins-43 and 43 to power the second LCD string on the backpanel. Of course this will require a ballast resister in series with each LCD string to keep a current balance between the LCD strings but this is not a very difficult thing to do.

Stay tuned - more to follow....

Update!

I modified the 4.8-inch LCD display by cutting the copper trace running to pin-35 on the LCD connector (quick fix) to test and see if the LCD display would indeed work. After cutting the copper trace near the connector (end of flex board) I checked for any possible short-circuits I might have caused (.5mm traces are really small!) and after I was curtain I had not inadvertently caused any issues I inserted the 4.8-inch LCD flex board connector into the Overo Palo-43 LCD interface board. I have an Overo Earth COM installed on the Palo-43 board for testing and the original factory firmware is still installed in the NaNd Flash memory on the Overo Earth board.

I powered up the Overo boards using a 5.0-VDC power supply (obtained from Gumstix) and the

4.8-inch LCD panel lite up using just one LED string (there are two in this LCD display) but it could be brighter (grin). After a couple of seconds (about 15 or so) the Overo Earth GUI displays on the LCD panel! Success! This panel works with the Gumstix Palo-43/Overo COM computer modules with minimal modifications! Pin-35 is the only thing that actually has to be modified in order to get this LCD panel to work!

As you can see in the image on the right the display settings within the uboot and kernel have not been changed from the default 1024 X 768 display settings but that is something else to do so the displayed resolution matches the LCD display resolution. One other thing to notice from the images - at the bottom of the display you can make out a slight darkening along the bottom edge of the display. If you look really close you can see there are seven slightly darker areas along the bottom edge. I am thinking these are the un-lite LED's in the second string. For normal operation I don't see it as a problem but if you are in a well lite room you may want the second LED string powered up.

Now, instead of a 480 X 272 LCD display I have a 800 X 480 Display (4X more display info) so can now do many more things with the computer system (better, fine-resolution graphics comes to mind).

Hopefully this blog posting will be useful to others working with the Gumstix Overo line of COM modules!

As a side note for those of you "Green" people (grin) - a Gumstix Overo Earth mounted on the Palo-43 board using the 4.8-inch Samsung LCD display with one LED string lite draws about 2-watts of power at 5-VDC. Not bad at all.

Let me know what you think! Leave a comment (good, bad or indifferent).

Too many Directions!

In working with the Overo COM line I have come to a revelation.... well.... more of an observation really.

My revelation is this:

There are so many more possibilities as to what can be done using the Overo COM line of computers than can be accomplished by one person!

DUH! one might say - that is obvious. What really brings it home for me is looking at the computer itself with all of the different capabilities built into it's design. This machine has so many different interfaces built into it's design Gumstix had to settle on a sub-set of the interfaces to bring out to the outside world! I suspect they would have had to make the COM board bigger if they wanted to bring all of the capabilities out from the OMAP Cortex-8 processor just because there is no physical way to have the interfaces access the outside world through the two 70-pin connectors on the current boards. Too bad as there are other interfacing capabilities on the OMAP processor that are not accessible.

OK - So now you have some idea of the quandray I face - so many possibilities, so little time! the following is a partial list (as I am sure you can come up with ideas I have not even considered) of things I want to do with this machine....

1. Intellegent firewall/router/access point.
There is no reason the machine could not handle this sort of application - it is based on Linux and there are all sorts of applications to implement a firewall/router/wireless access point using the Overo COM computer.

2. Wireless MESH-Based communications data collection & processing system.

This is one neat idea as what I envision is the COM system configured to run wireless communications between multiple COM machines and using a MESH network for redundancy of the network link. Given the computing power of the OMAP-3 processors and using the 3530 gives the ability to perform DSP based processing one should be able to come up with all sorts of monitoring/control system ideas for this computer. Heck, you can even have a display using the machine's video capabilities for such things as process control and monitoring. Talk about inexpensive control systems!

3. Intrusion Protection System.

Hmmm - How about a computer system small enough to fit in a cigarette case but able to detect unauthorized access to a network - maybe even able to thwart a hacker attack on a network too. There are software applications for linux that allow monitoring and intrusion prevention (using firewall controls) that can run on the COM machines. At 600-MHz the COM machines clock is faster than a Cisco PIX-515 firewall if that gives you any idea of the capabilities. I know - this is an ARM based RISC machine - so what - it is still FAST! (grin).

4. Intertial Navigation System.

This is an interesting idea I had. There is enough compute power and interfacing capabilities in the COM machines to build an inertial Navagation system! At first I thought it would cost an arm and leg to build such a device as the cheapest one I could find on the Internet runs more than $4000 USD. Well - a little research reveals you can obtain the hardware for a GPS, 3-Axis Magnatometer capable of very low magnetic field measurements down to 0.015 u-Tesla and a 6-degree of freedom solid-state gyro/accellerometer package for less than around $200 - $250 USD! Given the Earth's magnetic field ranges from around 30 - 60 u-Tesla there is no problem in detecting the direction/orientation of the Earth's magnetic field! With a GPS, Magnatometer and gyro/accellerometer package you can build your own inertial navigation system that rivals most expensive packages for a small fraction of the cost. What can you do with such a system??? How about sailboat autopilot? UAV anyone?

5. Magnatometer Mapping System.
Building upon the inertial Navigation System you could use the 3-axis magnatometer output along with the GPS information to produce a map of the magnetic field in an area - by moving back and forth along a line and sweeping the area and given you know the orientation and direction of movement based on the sensor inputs from all of the sensors and GPS you can draw a "map" of the earth's local magnetic field strength and orientation relative to the sensing system over a given area. Basically you have a method to detect iron/steel objects by the affect they have on the local magnetic field. Buried treasure anyone???

6. Perimeter Monitoring System.

An interesting thought here. Why not use the COM machine as a perimeter monitoring system. Since you can get a LCD display for the COM machine you could actually "draw" the perimeter you are monitoring on the display then change icons/colors to denote where things are happening. By using wireless sensors and coupling back to the COM using wireless communications you could actually deploy a monitoring system rather quickly. I am not delving too much into the details here but there are all sorts of possiblities!

7. Home Entertainment System.
I follow several forums such as the Gumstix and Beagle-Board Forums and I get this idea from the Beagle-Board forum. Seems there is an effort out to build a home entertainment system based on the linux operating system. This would be a natural thing for the COM computer as it runs linux. The really nice thing is the Gumstix Overo line and the Beagle-Board both use the same OMAP processor (at least the OMAP 3530) so the same applications software will run on both boards. Granted there may be some small differences but for the most part there is very little difference as far as applications software is concerned. One such application is a home entertainment system - it is in development on the Beagle-Board so should port directly over to the Overo COM machines too (grin).


8. Home Control/Monitoring System.

This idea is a combination of the perimeter monitoring system and the home entertainment system. Why not combine them to have a total home control and monitoring system - you would use the television as the display for the system when you needed to check on it and then could watch movies played through the COM board or TV from an external source. All you have to do is use your imagination to come up with all sorts of possiblities!

As you can see I am having a great time coming up with ideas - now all I need is the time to work on them! Hopefully in the coming months I will actually have the time to put into implementing some of the ideas mentioned here. As I work my way through them I plan to post the information here so others may follow along and hopefully make some improvements on my initial implementations! That is what public domain software/hardware is all about - improving upon ideas! Everybody comes out ahead!!!

I thought of some more ideas and have listed them below but did not expand on them - see what you can come up with for them and let us know! Who knows - you may come up with the next killer application!!!

9. Network Monitoring System.

10. Communications System.

11. VoIP PBX System.

Your Ideas here.

As you can see - If you can dream it you can do it! All it takes is just some common sense and a will to succeed. It also helps if you have an understanding of the projects and know where to find the parts. Comments??? Ideas??? Let me know!!!

Working on the development side of things

For the last several weeks I have been working on the development side (software implementation) for the Overo series of COM (Computer On Module) units. This has been rather an interesting experience as the Overo line is a rather new (read: bleeding edge) computer system so the software is being created in a very fast pace in terms of development. Unlike a Windows based machine you have to run a development system to implement different applications or make changes to the Linux kernel for different hardware drivers if they are not active in the factory installed version. You can installed pre-compiled applications using an application installation program but if the application is not already built or you are wanting to use a linux hardware driver that is not already factory installed then a development system is a must. Besides, it can be very educational to see how things are done under the hood, so to speak. The development system chosen for the Overo line by Gumstix is called OpenEmbedded which is an open source development system for embedded computer systems (interesting - wonder where they came up with the name?).

Until now I have worked with cross-compiler systems where you were actively involved in the cross-compile process, such things as creating and modifying 'make' files (used to setup dependencies, setup variables used, call the different development applications and so on) to installing the different cross-compiler and library files and compiling the different parts of the development system toolchain. Most of the development systems I have worked with also require "switching" to a virtual filesystem for the actual cross-compilation process to protect the underlying operating system otherwise it is very easy to trash the operating system and crash the development computer system!

In using the OpenEmbedded system that has totally changed! Most of the 'grunt' work is now handled by the OpenEmbedded system itself, from downloading the different parts needed to cross-compile C source code, compiling the cross-compiler tools and software libraries, installing the different parts used in the proper locations within the development computer's filesystem, downloading the different applications and Linux kernels used for creating the operating system and applications, determining the different dependencies (which parts need to be compiled in what order so the different parts and applications can 'find' the needed links and library headers) - then - building the whole operating system and applications along with the filesystem, boot-loaders and startup scripts needed to run the system and applications on the Overo line of computers! Gotta love that! Now - the learning curve for OpenEmbedded is steep (at least it is for me) but is very doable and if you do become accomplished at creating bitbake recipes (recipes are the script files that tell BitBake how to accomplish something) you can build most any application without the laborious task of writing 'make' files.

Now - this is the part most here will find difficult. The OpenEmbedded system runs on Linux systems ONLY! Part of the reason for this is most of the embedded computer systems working with open source are based on Linux so it makes sense to develop in the same environment as the target system operating system is going to be. OpenEmbedded will NOT work in Windows (unless you are running a Linux system on a Windows based machine)! This may change in the future but I would rather stay in the Linux environment so as not to muddy the water too much - just think of the headaches you might encounter trying to run Windows compilers to build Linux operating systems on computers that have a whole different architecture from the machine the target system is targeted to! This is not as bad as it might seem! My home development system IS a Windows based system ( I like gaming and most of the games I play are not written to run in Linux!) but I can run Linux on the system without any issues and still perform other tasks in Windows at the same time.

How can this be you ask?

Simple - in one word - Virtualization!

I use VMWare's free VMWare Server to run different "Virtual" computers on my Windows system. This allows me to have multiple computers exist on the same hardware and I have enough computer resources to run Windows (XP) and three or four virtual machines at the same time on my machine. Of course it can get confusing at times but the capability is there (grin). Now there is a caviat to using a virtual environment... you want to have enough physical resources on your machine to allow the virtual machine to run decently. In other words you want to have at least 1-gig of RAM and at least 100-Gigs of hard drive space available otherwise if you have only minimal RAM in the machine the virtual machine may not have enough memory and will start swapping to the virtual drive (this really bogs things down) and if you don't have enough hard drive space you will "run out" of virtual hard drive space in the virtual machine - this is worse than too little memory! Having said that here is what I did to create a development system for the Overo line.

Here are the (very) generalized steps I used:

• Downloaded the Free VMWare Server and installed it on my computer system. The VMWare server also needs the Java Runtime package so I downloaded that as well then installed it on my machine per the instructions on the Java website.
  
  
• Once I had the VMWare Server installed I opened the VMWare Server application and created a virtual machine for a Linux System. I setup the memory for 512-Megs to start and configured the hard drive storage for 80-Gigs of space. For the 'network' settings I use 'bridged' mode so the virtual machine would use the computer's interface and the virtual operating system would be able to use DHCP to obtain the information needed to connect to my home network automatically. The configuration for the virtual machine is stored on the hard drive a several files (this includes the virtual hard drive image) which makes saving copies very easy - just copy the files and you have a backup!
  
  
• The Linux environment I use is Ubuntu Linux workstation. I downloaded the Ubuntu 9.04 version (latest stable version) as an ISO file (CD image file) and saved it on my machine in the directory where I built the virtual machine for the development system. The reason you save the ISO image in the same location as the virtual machine storage is very simple - in the VMWare Server environment you can only "see" items that are stored in the virtual machine directory!
  
  
• To install the Ubuntu 9.04 Workstation software in the virtual machine you need to configure the CD-Rom drive settings in the VMWare Server settings for the virtual machine to use the ISO image as the CD-Rom. This is very easily done during the configuration of the virtual machine as there is a question during the configuration as to what to use for the CD-Rom - you just select the Image setting and browse to the Ubuntu ISO image file previously saved in the virtual machine directory - this is the only place you can browse from within the VMWare Server which is the reason I saved the ISO file there.
  
  
• Once the virtual machine was configured I started the virtual machine and opened a virtual machine window. The Ubuntu system starts up just like the CD version - I selected the "Install Ubuntu" selection to install the Ubuntu system in the virtual hard drive. After answering a couple of questions (keyboard and mouse type, timezone, user name and password, etc ) the Ubuntu installer fires up and completes the installation of the Linux system into the virtual hard drive and then waits for you to "remove" the CD-Rom media and reboot the virtual machine.
  
  
• To "unmount" the Ubuntu ISO you just edit the CD-Rom settings for the virtual machine in the VMWare Server and set the CD-Rom to either none or the physical one in your machine (personally I set it to the physical one). Ubuntu will complain since it was running from the ISO image but just answer "yes" to the question then reboot the virtual machine. When it comes back up you will be running in Ubuntu 9.04 (or whatever version you are using) Linux in a virtual environment!
  
  
• After Ubuntu was installed on the virtual machine I performed a system update to download any new updates for the system. While this is not a hard requirement I like to have a system that is fully up to date before using it for development.
  
  
• The next step is to install the Openembedded development system in the virtual machine. I used the steps located on the Overo Development Website (Link) but there are a couple of differences for the Ubuntu 9.04 version:
  
  
  1. One has to do with the notes on the webpage where the instructions state to add the following to the sysctl.conf file; 'vm.mmap_min_addr = 0' . The sysctl process does not recognize this command so I left it out where the instructions stated to place the command.
     
     
  2. A second item has to do with the 'way' the development system operates in the current default download of the OpenEmbedded system. BitBake (the MetaData executor) and OpenEmbedded use Python ( a programming language) to implement the development system - the default download configures the system to use "Python" whereas the Ubuntu system uses "Python-2.6". How can that be an issue - it is as the system gets 'confused' as to which version to use - talk about making a mess! Also, it is very difficult (at least for me) to determine exactly what fails during a build when this confusion occurs. The answer to this issue is really simple - just update the OpenEmbedded development system. If you follow the instructions to install the OpenEmbedded system I listed earlier then all you need to do is go into the org.openembedded.dev directory and type the following command: git update which downloads the current updates for the OpenEmbedded system. One of the updates corrects the Python "confusion" issue so things work properly after the updates are done. NOTE: I am being metaphorical here when I say it is a "confusion" issue but it makes it easier to describe (grin).
     
     
  3. When you reach the point where you perform your first build be prepared to wait a while for it to complete! On my system, connected to the Internet at 8-mbit/second it takes about 12 hours for the development system to download all the parts needed and compile the console (CLI) version of Linux for the Overo computers. Once you have performed a successful first build the time is much shorter as all of the development parts have been downloaded and compiled and all of the source files for the console version are on your virtual hard drive.
     
     
• Once the development system has been installed and you have built the first recipe (omap3-console-image) successfully you can build the GUI desktop version for the Overo line by using the 'bitbake omap3-desktop-image' command in the overo-oe directory of the developement system. Of course, if you have not built the development system and are just reading this that last sentence probably will make absolutely no sense what-so-ever! (grin). A note - there are a great many parts to the GUI version that have to be downloaded so this first build also takes a fair amount of time! On my system the combined first build of the console and GUI versions took about 26-hours total to accomplish. Of course, your time will be different based on your computer hardware and your internet connection.
  

If you do decide to setup a development system for the Overo line I would advise you insure you have enough memory and hard drive space! On my system the GUI version of the Linux operating system for the Overo line takes about 22-gigs of space. If I wanted to build ALL of the applications and drivers currently available it would require around 40 - 45 gigs of space to store all of the information needed.

I am thinking if there is some interest I could create a VMWare image of the development system with the OpenEmbedded and BitBake applications installed. The VMWare image would already contain the all of the OpenEmbedded updates at the time of the image build. All you would need to do is download and install the VMWare Server software, install the image then perform the console and GUI bitbake builds to have a Overo development system of your own. Let me know what you think...

New Overo Computer On Module!

Gumstix has come out with the Overo Fire COM - Gumstix now is calling them "Computer on Module" to differentiate what is the motherboard and what is the daughterboard - must have been some confusion between the computer board and expansion boards.

The Overo Fire COM is the top of the line in the Overo series, at least at the moment. It contains not only built-in Wifi 802.11b/g capabilites but also BlueTooth capabilities on board. This feat of magic is provided by a Marvell W2CBW003 integrated circuit (can be seen on the left side of the board in the picture) which connects to an external WiFi and BlueTooth antenna (not supplied) through a u.fl R.F. connector for each one. Even though the WiFi/BlueTooth radio Integrated Circuit package is only 12-mm x 12-mm in size it packs a great deal of capability. For those in the know - this is the same radio integrated circuit that is on the Beta Overo board and all the software drivers already exist in the operating system installed on the Overo boards. Couple the WiFi and Bluetooth capabilites with the TI OMAP-3530 processor on the Overo Fire COM and you have one very capable device in a very small form-factor! The only thing missing is a video out source on-board to make this a completely self-contained computer system! For video and USB access you will need one of the expansion boards mentioned below or build your own custom interface board.

I have discussed some of the capabilities of the TI OMAP-3530 processor in a previous posting so willl not delve into that portion again - I do want to talk a little about the Wi2Fi (Wireless 2 Wireless ) capabilites on this board. The W2CBW003 high-level block diagram is to the right.

Even though the block diagram shows 802.11a/b/g that is not the case with the W2CBW003 - it does not have 802.11a capabilities. I suppose this block diagram is used for a different radio integrated circuit and someone just got lazy! (grin). Not having the 802.11a capability will, in my opinion, limit the usefulness of this combination as more 802.11a access points are becoming prevealent - especially in areas saturated with 802.11 b/g and wireless phones, baby monitors and the like exist. Hopefully Gumstix will realize this fact and talk to Marvell about a WiFi/Bluetooth integrated circuit combination that is pin-to-pin (or should I say "Ball-to-Ball in reference to the methodology of mounting the integrated circuit to the circuit board) compatable so it is a direct replacement for the current 802.11 b/g configuration - I don't believe Marvell has such a device out yet but judging from the block diagram they may be working towards that goal.

The Overo Fire COM is the same physical size and electrical connection specifications as the original Overo Earth board so will work with the Summit Expansion board. Speaking of expansion boards Gumstix has come out with a few more in different configurations for the Overo COM series:

The Summit expansion board:

This is the first expansion board available for the Overo COM series - I have already discussed this board earlier so will not bore with details (grin). One thing I will say is it is the least expensive of the expansion boards and packs a good number of interfaces on-board for general purpose use. The only exception is a built-in ethernet connection but that is now covered by the Tobi board (see below).

The Palo-43 expansion board:

The Palo43 is a new expansion board for the Overo COM series of processor boards and works with all of the Overo COM boards. The Palo43 contains an LCD interface which will drive the Samsung P/N: LTE430WQ-F0C (available from Gumstix at a very reasonable price in single-unit lots) and a touch-screen controller to interface to the touch-screen resistive overlay on the Samsung LCD display. The board also contains most all of the interfaces contained on the Summit board thus it gives you the capabilites of the Summit expansion board with a self-contained LCD Touch-Screen capability. The Palo43 does not have a video output like the Summit expansion board (for obvious reasons). A second difference is the physical locations of the different interface connections - they have been moved to each end of the board to allow the additional circuitry needed to drive a LCD display. Since these systems are targeted at development this is usually not an issue (grin). One interesting note - the description of this board lists it's size as 80-mm X 39-mm but that is not the case given the size of the ports are the same as on the Summit expansion board.

UPDATE: The powers that be at Gumstix have determined there were some errors inadvertently incorporated within the description of this board. The actual size is 118.3 x 67.25mm and is reflected on the Gumstix website as well. Talk about quick response!!! Less than one day! These guys really do care!

The Tobi expansion board:

The Tobi expansion board is the third in the Overo COM series of expansion boards. Like the Summit expansion board it contains Audio Sterio Input and Output connections, High-Speed Version-2 USB-OTG and USB Host ports, a HS Version-2 USB Console port, 5-VDC Power Connector and the 40-pin connector location to access the different interfaces provided. In addition to all of the above interfaces the Tobi also has a 10/100 megabit, full-duplex Ethernet port on board as seen on the right side of the circuit board in the image to the right. You can check out the specifications for the port here: LAN9221 The physical size of the board is: 105 x 40mm.

Update: As of this moment (June 5, 2009) there is an Interference between the Overo Air COM and Fire COM modules with a component on the Tobi board. In other words you can not use a Overo Air COM or Fire COM with the Tobi board until Gumstix resolves this issue. What does this mean? You can not have 802.11b/g and Bluetooth capabilies on the Tobi board. If those are not a problem you still can use the Overo Earth COM and Water COM on the board without any physical component interference issues. In my opinion (for what it is worth) this really blows! I would want ALL capabilities available (wireless, bluetooth and ethernet) on the board for a full fledged computer in a very very small space, but that is just me.

Conclusion

Now - as of the date of this posting the Overo Fire and Overo Air (same as the Overo Fire but uses the TI OMAP-3503 instead of the TI OMAP-3530 processor) are out of stock. I suspect this will be cleared up in short order as I suspect there will be a good demand for the two COM boards as people find out about their capabilities and the fact they have WiFi and Bluetooth hardware already on the boards! Given the Overo Fire COM utilizes the TI OMAP-3530 which has video DSP hardware capabilites and OpenGL built into it things will get very interesting in the upcoming months as programmers start to bring out the capabilites of the Overo Fire COM board! These are indeed exciting times!

Mine is already on order!!!

If you would like to see more about this and the other Gumstix boards checkout this link:

http://www.gumstix.com/

As a matter of interest I have been in contact with the CEO of Gumstix and he is expecting the Overo Air and Fire boards to be available next week (April 13th, 2009) or there abouts.

Now there is an Overo Water board out!

Stop the press! Stop the PRESS! (always wanted to say that)...

There is a new Overo board out - it is called "Overo Water"... Hmmm - seems like there is an Alchemy Theme going here! The Overo Water board is built on the same board as the Overo Earth. This is possible because the difference between the Overo Earth and Overo Water boards is the TI OMAP Computer on Chip integrated circuit which has the same pinouts.

The Overo Earth board comes with the TI OMAP-3503 integrated circuit with the RAM and FLASH memory contained in an integrated circuit mounted on top of the TI integrated circuit, called a "Package on Package" or POP configuration. The Overo Water board comes with the TI OMAP-3530 integrated circuit with the memory in the same configuration.

There are a good deal of similarities between the two TI integrated circuits but there are also some very distinct differences:



To the right is the hi-level block diagram of the TI OMAP-3503 integrated circuit. Most, but not all of the functionality of the integrated circuit is accessible on the Overo Earth or Overo Water board - this is because of the actual physical size constraints of the two boards - there just is not enough real estate to have all the capabilities available external to the TI OMAP integrated circuit. This is really not a limitation to the capabilities of the computer board as most of the really useful functionality is directly or indirectly accessible on the expansion board (Summit Expansion board) and if the Summit board does not make the specific function you are looking for accessible but it is available on one of the two 70-pin connectors on the computer board you can either fly-wire the connection on the summit board (really tricky to do) or have a custom board fabricated with the functionality accessible (pricey but possible).



The hi-level block diagram for the TI OMAP 3530 looks a great deal like the TI OMAP 3503 (after all they are in the same Applications Processor Family) but you will notice there is a dedicated Video processing section in the TI OMAP 3530 that does not exist in the TI OMAP 3503! This difference is BIG as it allows the Overo Water board to perform some video magic the Overo Earth would have problems with!


If you notice on the upper left there is a block that is dedicated to Video processing and Audio processing that does not exist in the previous block diagram of the TI OMAP 3503 processor. This is hardware video acceleration which is completely distinct and separate from the ARM 7 processing core. What this does is allow the video processing to be performed in parallel with the running of applications so speeds up the video capabilities quite a lot! The TI OMAP 3530 has some very impressive capabilities in the video department as compared to most other embedded computer systems:

High Performance Image, Video, Audio (IVA2.2™) Accelerator Subsystem
430-MHz TMS320C64x+™ DSP Core

• Enhanced Direct Memory Access (EDMA) Controller (128 Independent Channels)
• Video Hardware Accelerators

POWERVR SGX™ Graphics Accelerator (OMAP3530 Device Only)

• Tile Based Architecture delivering 10 MPoly/sec
• Universal Scalable Shader Engine: Multi-threaded Engine Incorporating Pixel and Vertex Shader Functionality
• Industry Standard API Support: OpenGLES 1.1 and 2.0, OpenVG1.0
• Fine Grained Task Switching, Load Balancing, and Power Management
• Programmable High Quality Image Anti-Aliasing

Fully Software-Compatible With C64x and ARM9™

Commercial and Extended Temperature Grades
Advanced Very-Long-Instruction-Word (VLIW) TMS320C64x+™ DSP Core

• Eight Highly Independent Functional Units
• +Six ALUs (32-/40-Bit), Each Supports Single 32-Bit, Dual 16-Bit, or Quad 8-Bit Arithmetic per Clock Cycle
• Two Multipliers Support Four 16 x 16-Bit Multiplies (32-Bit Results) per Clock Cycle or Eight 8 x 8-Bit Multiplies (16-Bit Results) per Clock Cycle
• Load-Store Architecture With Non-Aligned Support
• 64 32-Bit General-Purpose Registers
• Instruction Packing Reduces Code Size
• All Instructions Conditional

Additional C64x+™ Enhancements

• Protected Mode Operation
• Exceptions Support for Error Detection and Program Redirection
• Hardware Support for Modulo Loop Operation
• C64x+ L1/L2 Memory Architecture
• 32K-Byte L1P Program RAM/Cache (Direct Mapped)
• 80K-Byte L1D Data RAM/Cache (2-Way Set-Associative)
• 64K-Byte L2 Unified Mapped RAM/Cache (4-Way Set-Associative)
• 32K-Byte L2 Shared SRAM and 16K-Byte L2 ROM
• C64x+ Instruction Set Features
• Byte-Addressable (8-/16-/32-/64-Bit Data)
• 8-Bit Overflow Protection
• Bit-Field Extract, Set, Clear
• Normalization, Saturation. Bit-Counting
• Compact 16-Bit Instructions
• Additional Instructions to Support Complex Multiplies

The above information only "touches" on the capabilities of the TI OMAP 3530 integrated circuit - for a complete list check out the TI site here:

http://focus.ti.com/docs/prod/folders/print/omap3530.html

This thing is Packed for Graphics processing! TI (Texas Instruments) says it best:

"OMAP3530 and OMAP3525 high-performance, applications processors are based on the enhanced OMAP™ 3 architecture. The OMAP™ 3 architecture is designed to provide best-in-class video, image, and graphics processing sufficient to support the following:

• Streaming video
• 2D/3D mobile gaming
• Video conferencing
• High-resolution still image
• Video capture in 2.5G wireless terminals, 3G wireless terminals, and rich multimedia-featured handsets, and high-performance personal digital assistants (PDAs).

The device supports high-level operating systems (OSs), such as:

• Windows CE
• Symbian OS
• Linux
• Palm OS "

Nuff said! Once I have my hands on this puppy (Overo Water), which is on order and on it's way from Gumstix to me, I plan to do some interesting 2D/3D programming to see how well it handles some games - one of which is Quake-1 ( a very FAST FPS game).

More to follow! Stay Tuned! (always wanted to say that too).

Encasement!

One of the things I want to do with this tiny computer system is build a PWCS (Personal Wearable Computer System) [I just made that up - like it?]. In order to do this I needed "something" to mount the actual computer system in and keep it's size down to a minimum. Currently there is no case for the Overo Earth computer as it's original design is for embedded applications, and I don't think they had "embedding within clothing" in mind when it was designed (grin).

I could have used most anything to make a case for the micro-beast (that is the Nickname I have for the machine). At first I thought about building up a case using either brass or thin copper and putting my "Leet" soldering skills to work but then realized that would not only be a little expensive (given the price of brass and copper sheet now days) but would have looked rather "tacky" as well - solder beads along seams just are not the same as welded ones (grin).

Next stop - the local Radio Shack store to see what they might have. That was a rather good choice as they have a 4-inch by 2-inch by 1-inch (10.16 x 5.08 x 2.54-cm for you metric geeks) Plastic Project Enclosure with a choice of aluminum or plastic lid (comes with both) for about $3.00 (USD).

Radio Shack Model: 270-1802 Catalog #: 270-1802

Since the enclosure is made of plastic it was rather easy to 'carve' the connector holes in the case with an X-Acto Knife (just be careful not to slice and dice yourself). Now - while I can solder with the best of them my X-Acto Knife skills leave a "little" to be desired! Who cares! Not me!!! It got the job done!

Here is my Overo Earth/Summit board (micro-beast) mounted in the enclosure. As you can see access to all of the "standard" interfaces is available from outside the case. Even the console USB connection is possible through the cutout in the back of the enclosure. I have not configured anything to access the 40-pin connections (yet) but that is a future project. There was a fair amount of modification to the stock case to mount the board in the enclosure - there are stand-offs in the case in totally the wrong locations that had to be removed and there are "slide-slots" running from the top to the bottom of the enclosure that have to be carved away but I think the effort was worth it - especially since there is not a commercial case for the board.

Now that I have the "computer" mounted within a case to protect it the next order of business will be to build the "world" interfaces for it. That will be the subject of a future blog entry!

Does Size Matter - You Bet It Does!

OK - I guess the title could be read as "something" from a certain type of "Television Commercial" but I could not resist!

The Overo Earth, mounted on the Summit Expansion board is still a very small computer system. If you don't believe this statement then take a look at the picture to the right!

Yes - that is an American Quarter and that is a Double-A (AA) Ni-Cad battery below the board.

If you look real close you can make out the outline of the actual Overo Earth board - it is just below the 40-pin holes under the Quarter and above the audio, HDMI, USB Host connectors on the Summit Expansion board.

The configuration shown in the picture is the most likely one most hobbiests or experimenters will use. You don't have to have "Leet" soldering skills or Microscopic Vision to build and solder the 70-pin connectors to access most of the capabilities of the Overo Earth computer - and - as a bonus you have video, audio, USB and console access directly off the Summit Expansion board - not to mention you don't have to build power conversion circuits for the 3.3-VDC/1.8-VDC power supplies needed to run the Overo Earth computer. For the price the Summit Expansion board is well worth it - just in the reduction of the "frustration factor" alone.

If you decide to access some of the more interesting interfaces, such as the SPI, I2C, 1-wire, PWM, ADC and the rest of the input/output connections brought off the Overo Earth computer you will need to keep the following points in mind:

1. All of the voltages to the different interfaces are 1.8-VDC. If you exceed this by very much you probably will let the "magic smoke" out of the Overo Earth OMAP-3503 integrated circuit as most of the interface connections go directly to the integrated cirtcuit.
   ( I will be describing a method to "translate" the 1.8-VDC logic levels to something more in line with current inexpensive sensor technologies - read: 3.3 - 5.0 VDC in a later blog entry)
   
   
2. You will need to supply the power externally to any interface devices you want to connect to the Overo Earth computer interfaces - the Overo Earth computer does not have the additional power capacity to run very many sensors, if any at all. The on-board power regulator does not have much additional reserve power capacity so it would be wise to power external sensors with an external power source.
   
   
3. If you decide to put a socket in the 40-pin holes on the Summit Expansion board instead of soldering wires directly to the hole locations put the socket on the BOTTOM side of the expansion board. The reason for the bottom placement location is to allow you access to the micro-SD location without requiring the removal of the Overo Earth computer from the Summit Expansion board. The 70-pin connector connections are pretty fragile and each time you remove and insert the Overo Earth on the Summit Expansion board you run a risk of damaging one or both 70-pin connectors. Better safe than sorry!