Geert's FoxBoard Blog

It's been a while...

2008-04-28T19:36:00.041+02:00

I know it's been a while since I updated my blog. But I've been struggling with a couple of things, both personally as well as on my domotics.

On personal level, it's been a sad time for me. Two weeks back, my beloved Father passed away. Knowing my Mother passed away hardly 20 months before, one can imagine I've known happier times....

This is the site I created to commemorate my beloved Parents...

Anyway, life goes on and I will have to live with all the good memories I have of both my parents (and I can assure you there are many, many of them...).

Another issue I was struggling with, was the amount of threads in my system. I'm not even halfway my development, and I had already 20+ threads running.
This was too much and the reason was quite simple: every object that represented hardware that needed polling, was running in its own thread.

For instance, for my IO expanders, I had one thread per instance. This is of course very expensive and I was looking to a solution that would bring down the amount of threads to one per functionality.

So, one thread for all my IO tasks, one thread for my temperature measurements, etc...

I've been thinking hard on how to solve this and found a good solution in the usage of STL and polymorphism, using callback functions.

The only precondition was that the prototype of my callback functions all had to be the same. But that was not an issue: it perfectly fitted into one another.

The goal was to fill an array with pointers to callback functions and then scan that array at regular times (every 10ms, since I wanted to have a granularity of 10ms to poll my IO pins).

Registering the callback functions happens in the class that maintains a thread. That thread is running every 10ms and completely scans the array (I used a vector array for that). The callback function was called every 10ms and inside the callback function, a decision was taken if a certain pin of a certain IO expander had to be checked or not (depending on the polling time that was set for that particular pin).

So, I first started by creating a virtual class with only one function: class CSubThread().

#include "iostream" using std::cout; using std::endl; class CSubThread { public: virtual void RunOnce( void ) { cout << " I ran once... " << endl; }; };

Note: "iostream" should in fact be in between left and right triangle characters, but Blogger has problems printing those characters. It thinks it's an HTML ta issue...

CSubThread() has one function, RunOnce(), that does not take any parameter and also doesn't return anything. You can't have something simpler, I guess...

The purpose is now that other classes will inherit the class CSubThread() and implement the function RunOnce().

The classes that need the polling mechanism, will implement RunOnce() as follows:

void C8575Io::RunOnce( void ) { Execute(); } /* RunOnce */

Since RunOnce() is declared virtual in the base class, other classes can redefine the content of the function according their own needs.

In the above example, RunOnce()--which is a public member of the class C8575Io()-- simply calls a private class Execute() which will do the necessary things to poll the corresponding IO expander.

As you can see, very simple... The public function RunOnce() is simply calling a private function Execute(), which will see if one or more pins of a IO expander has to be polled or not.

How is the function RunOnce() connected to the callback array?

As said before, I wanted to have one thread per "activity", so, one thread for the IO polling, one thread for the temperature polling etc...

The first thing the class C8575Io() must do, is connecting to the IO thread. Now, there are two situations:

The thread for the IO polling is already there
The thread for the IO polling still has to be created.

This is not the concern of the class C8575IO(). This class simply does a call to the message queue class using the following command:

pMsgQueue = CMqMgr::QueueInstance();

Need for debugging? Well, there is...

2008-02-09T16:37:00.000+01:00

When writing programs, ideally spoken you should think hard enough and your code should be "first time right". But as I said, ideally spoken...

Reality is in (can I say) 100% of the cases different: one simply needs at some moment(s) in time a debugger.

For the FoxBoard, that's not so obvious. Ok, I know, there's GDB and you can activate gdbdebugger on the FoxBoard, but still, debugging on the GDB command line is only for the "happy few"...

I myself prefer to have something more graphical.

I've searched quite a bit to find what I was looking for. I've used Eclipse, NetBeans, KDevelop and other exotic applications, but none of them could convince me to used it together with the FoxBoard to debug.

I then found DDD, a graphical debugger that can be connected to the FoxBoard. This one is good, very good even. For those interested, I wrote an article on my Wiki website, which can be read here.

But I was still looking for something more "intuitive", something which looks more to the (sorry Linux guys) Windows debuggers, like there are Visual Studio/Visual Express (why always taking Micro$oft as a reference???). Am I spoiled? Yes, for sure, I am spoiled. At least regarding debug environments...

I finally found Insight, a debugger GUI made by RedHat. This looks very much to what I am used to see on Windows environments.

However, like DDD, Insight is not "right out of the box" useable. The reason is that this debugger is very "versatile": a lot of targets are supported, among them the CRIS one!

You have to download the sources and compile it yourself. But don't worry, I also wrote an article on how to do this on my Wiki pages.
As usual, for the ones interested, they can read the article here.

Overall, I'm quite satisfied about this debugger. Of course, this one too has its advantages and disadvantages, but on a scale of 10, I would give it a 7.

For sure, better than all the rest I've looked into.

Have fun reading the article, building the debugger and applying it on the FoxBoard!

Auto log-in? Sure!!!

2008-02-05T19:44:00.000+01:00

Hi again,

For the lazy ones among us (I'm definitely adding myself to this group of people...), there's a nice way to log in to the FoxBoard without having to retype the user name (root) and password (pass) over and over again.

This so-called auto log-in can be done from Windows (using Putty), Linux and also CygWin (running under, yep, Windows)

To avoid writing twice the same article (I'm lazy, remember?), I already wrote a complete article on how to set up such construction using a private/public key exchange between the FoxBoard on the one hand and Linux/Windows/CygWin on the other hand.

If you're interested, pls. feel free to read this article on my Wiki.

In case of questions/problems, you can always contact me.

Enjoy!

Dynamic or static?

2008-01-24T18:53:00.000+01:00

A Linux driver is always assigned a major and minor device number. You can see this when you do a ls -als. Go to the /dev directory on your Linux system and execute the before mentioned command.

An example is given below:

[root@axis-00408c012351 /dev]192# ls -als
0 cr--r--r--    1 root     root      61,   0 Jan 20  2008 cam0
0 cr--r--r--    1 root     root      61,   1 Jan 20  2008 cam1
0 cr--r--r--    1 root     root      61,   2 Jan 20  2008 cam2
0 cr--r--r--    1 root     root      61,   3 Jan 20  2008 cam3
0 cr--r--r--    1 root     root      61,  32 Jan 20  2008 camquad
0 crw-rw-rw-    1 root     root      91,   0 Jan 20  2008 can0
0 crw-rw-rw-    1 root     root      91,   1 Jan 20  2008 can1
0 crw-rw-rw-    1 root     root      91,   2 Jan 20  2008 can2
0 crw-r--r--    1 root     root      90,   0 Jan 20  2008 cflash0
0 crw-r--r--    1 root     root      90,   2 Jan 20  2008 cflash1
0 crw-r--r--    1 root     root      90,   4 Jan 20  2008 cflash2
0 crw-r--r--    1 root     root      90,   6 Jan 20  2008 cflash3
0 crw-r--r--    1 root     root      90,   8 Jan 20  2008 cflash4
0 crw-r--r--    1 root     root      90,  10 Jan 20  2008 cflash5
0 crw-------    1 root     tty        5,   1 Jan  1 00:00 console
0 crw-r--r--    1 root     root     122,   0 Jan 20  2008 eeprom
0 crw-rw----    1 root     root     193,   0 Jan 20  2008 event

When you look to column 6 and 7 in the above given table, you will see that column 6 represents the major device number and column 7 represents the minor device number.

Since I'm working mainly on the I2C driver on the FoxBoard, I was interested in how this driver was set up.

At the same time, I was reading the (very interesting) book Linux Device Drivers and while reading it, I was especially interested in the chapter handling the devices major and minor numbers.

There was a very interesting statement done, which said to use dynamic device number allocation, in stead of doing it statically.

It was not only the direction to go, it also has the following benefits:

The system will take care of the major and minor number allocated at runtime
You will not "clash" with a driver which has the same major and minor number
You're safe for the future

For me, those were reasons enough to go and see if I could change the major and minor device number allocation of the I2C driver from static to dynamic.

I wrote a whole chapter on my Wiki pages, explaining what I have done to achieve this. Not only was it a challenge, it forced me to learn the mechanisms which were (and still are) used to build the flash images for the FoxBoard.

I don't want to fall into repetition, you can read the whole story here.

After you've done all necessary changes, you will see the effect when restarting the FoxBoard. At a certain moment, you will see that a dynamic major and minor number is requested to the Linux kernel for the device.

You will see that not the number 123 is given as major device number (as is the case with the static situation in the FoxBoard I2C code), but the number 254.

Here's the output when performing an ls -als in the directory /var/dev:

[root@axis-00408c012351 /var/dev]132# ls -als
   0 drwxr-xr-x    2 root     root           60 Jan  1 00:00 .
   0 drwxr-xr-x   10 root     root          200 Jan  1 00:00 ..
   0 crw-r--r--    1 root     root     254,   0 Jan  1 00:00 i2c

This way, you are sure you won't "clash" with some other driver using the same major and minor numbers and you're sure you're following the advice of authorities in the Linux domain (writers of the Linux Device Driver book).

What the... * Error -d is not a supported platform

2008-01-20T12:49:00.001+01:00

Back again with some news.

As already mentioned in a previous blog, I had to re-install my Kubuntu on VmWare.

Once this was done, I also re-installed the FoxBoard SDK from scratch. However, when running the initial compilation, I quickly got the following error message on the screen, after which the installation ended:

install -p -d     /home/fb/devboard-R2_01/tools/build-R2_12_4/bin
    * Error -d is not a supported platform

I couldn't get any further, also the command ./configure was facing the same problem.

After several tries and a lot of thinking (that hurts, you know!), I decided to analyse the whole installation script (install_svn_sdk.sh).

It took me a bit of time, but I got quite quickly an "eagle's view" on how the installation worked.

I executed the commands step by step on the command line and I saw the error I gave above, appeared when I executed the following command:

A=`yes n | \`make oldconfig 2&> install.log\``

The result I got, was the following:

make tools
make[1]: Entering directory `/home/foxboard/devboard-R2_01'
make -C tools/build install
make[2]: Entering directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4'
make -C ccdv install BINDIR="/home/foxboard/devboard-R2_01/tools/build-R2_12_4/bin" LIBDIR="/home/foxboard/devboard-R2_01/tools/build-R2_12_4/lib"
make[3]: Entering directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4/ccdv'
gcc -Wall -Wshadow -I/home/foxboard/devboard-R2_01/target/host/include -O0 -g -fno-omit-frame-pointer    -L/home/foxboard/devboard-R2_01/target/host/lib -Wl,-rpath-link,/home/foxboard/devboard-R2_01/target/host/lib  ccdv.c   -o ccdv
install -p -d /home/foxboard/devboard-R2_01/tools/build-R2_12_4/bin
* Error -p is not a supported platform
make[3]: *** [install] Error 1
make[3]: Leaving directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4/ccdv'
make[2]: *** [ccdv] Error 2
make[2]: Leaving directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4'
make[1]: *** [tools] Error 2
make[1]: Leaving directory `/home/foxboard/devboard-R2_01'
make: *** [/home/foxboard/devboard-R2_01/tools/build/bin/aconf] Error 2

Then the search started to find out where the error could come from.

As a last exit, I tried to run the installation as root and to my surprise, I was able to install everything. Only later, it was clear to me as to why that was possible (see further).

Reverting back to a regular user, I tried over and over again, going bit by bit deeper into the problem.

I followed the call to make oldconfig (the one that failed) and when looking to the makefile in ./devboard-R2.01-1, I found out that the target oldconfig was defined as follows:

## oldconfig - Updates the product configuration.
##
.PHONY: oldconfig
oldconfig:      $(AXIS_TOP_DIR)/tools/build/bin/aconf
@$(AXIS_TOP_DIR)/tools/build/bin/aconf -o configure-files/common/AC_common
@touch Makefile

So, first the target $(AXIS_TOP_DIR)/tools/build/bin/aconf in the same makefile was executed. This target was defined as follows:

$(AXIS_TOP_DIR)/tools/build/bin/aconf $(AXIS_TOP_DIR)/tools/build/bin/amconf:
$(MAKE) tools

Here I saw the same makefile was called again, with the target tools. The following was defined for that target:

## tools - Builds and installs all tools on this host.
##
.PHONY: tools
tools:
$(MAKE) -C tools/build install

So, I saw the makefile in /tools/build was called, with target install.

Going to that makefile, I saw the target install was defined as follows:

install:        $(ISUBDIRS) install_e100boot install_fsboot
@echo "Installation of build tools complete."

That means, I had to look for the content of variable $(ISUBDIRS). This was defined as follows:

ISUBDIRS :=
    ccdv \
    scripts \
    aconfig \
    filepp \
    genromfs \
    imgsum \
    mkcramfs \
    mkfs.jffs \
    mkfs.jffs2
    profile \
    sermon \
    sortdir \
    tcptest \

Now I knew what command was filling ./devboard-R2.01-1/tools/build/bin!

When looking close into the makefile, I saw at the beginning the following definition:

INSTALL ?= install -p
export INSTALL

So, here the Linux command install -p was put under the variable INSTALL and then exported to the whole FoxBoard SDK.

That means, everywhere where there was a call to $(INSTALL), it was replaced by install -p.

Finally, I found where the install -p came from!!!

Now, when I executed the command "which install", I saw to my big surprise I was not getting the executable install, located in /usr/bin, but the script install instead, located in ./devboard-R2.01-1!!!

The picture was clear to me now. For one reason or another, the incorrect install was called!
I started digging into the paths and what I see was the following:

- I had extended the standard PATH variable with a couple of paths I'm frequently using, among others, the path ./devboard-R2.01-1.

- But more important: I'd added my personal paths in front of the system paths! So, when looking for the command install, the OS found one in the ./devboard-R2.01-1 directory, so there was no reason to go further along the path to look for another install!

It was clear now: in stead of calling the executable install, all FoxBoard SDK's were in fact calling the script install. Needless to say that a "target" -p indeed resulted in the error given at the top of that article.

Since I knew the real cause, I simply solved it by changing the order the PATH environment variable was build up: first the system directories/paths and only then adding my own paths!!!

This solved the issue, but still I think it's not wise to have a script having the same name as an executable. Therefore, I requested to AcmeSystems if they're willing to change the script install into installfoxsdk (or something like that).

Let's see what the outcome is!

What I've learned is, especially here, that it's very important to know the way the directory structure is traversed, if the OS is looking for an executable.

Also, having a script the same name as an executable isn't a wise choice, but that's my humble opinion.

And finally, why was I able to run the scripts as a root? Well, simply because for the user root, the paths were not "polluted" with the FoxBoard paths. That is, install was really the executable install, not the script install!!!

Learning all the time...

Small disaster happened

2008-01-09T19:22:00.000+01:00

First off, a happy and prosperous new year for the people reading this blog!

The day before Christmas, I was working again (of course) on my domotics system. While doing an update of my Kubuntu 6.10 virtual machine, I was told I could upgrade to Kubuntu 7.10.

Since I'm always quite eager to do this (being up-to-date with my applications/OS), I took the risk to start the upgrade.

All went fine, until the moment I lost my internet connection on my virtual machine. Shortly after, I got the message that the system could not download any more the remaining parts of the upgrade.

And there I stood... A system which was half-half upgraded but that could not access the internet any more. Even worse, my samba connection was gone too, so I could not even reach my virtual machine from my Windows environment any more. Sad, sad, sad...

I've been looking on the internet, asked for some advice, but nobody that could help me get my internet connection back on my virtual machine.

Luckily, I'm taking a weekly backup of the software I've written for my domotics system, so I was quite confident I was not going to loose the most important thing.

In the end, the only thing I could do was buying a new harddisk and install Kubuntu 7.10 from scratch. I definitely didn't want to re-install what I still had, because one day or another there might be things I need on my new installation that are still only available on my, well, call it from now onwards "back-up".

The biggest problem now will be to have the state of the new virtual machine equal to the state of the old one.

Since I installed quite a bit of apps (going from FoxBoard stuff to debugging tools to editing tools to Kubuntu tools), it will take me still a lot of time to get on the same level again. This has been 14 days now, so I lost quite a bit of time.

In the mean time, I've re-installed the FoxBoard SDK on the new distro and bit by bit I will try to get to the level I had on my old distro.

Conclusion: be very careful with upgrades. If I want to do an upgrade in the (near) future, I will definitely start from scratch and as long as the new situation has not reached the level of the old situation, I won't change anything any more to the stable environment.

I've learned my lessons, I would say. So, be warned... ;-)

Problems with P0.7 of PCF8575

2007-11-18T11:51:00.001+01:00

I recently discovered I have problems when controlling the PCF8575 (16-bit I²C controlled IO expander) in such a way, that P0.7 is put as input (so, P0.7 is high).
Whenever P0.7 is put high, all other pins (P0.0 - P0.6 as well as P1.0 - P1.7) are becoming inputs too, whatever their previous state (input or output).
Also, the PCF8575 does not detect any input changes any more...

I still have no clue at all as to why this IO expander is behaving so strange.

The moment I switch P0.7 as output, all my other pins behave correct again (as input as well as output).

Still looking for a possible cause...

3V to 5V I2C translation problem

2007-11-09T19:07:00.000+01:00

Knowing the FoxBoard is running on 3V3, this means the levels of my I²C output are between 0V and 3V3.

However, I want to power my own devices with 5V, if possible. This is because most devices I'm going to use, are working just fine at 5V (some of them are also capable of working at lower voltages, but for simplicity I will stick to one supply of 5V).

Luckily, nowadays lots of IC's are available, which are able to do very nice things. Such IC is the PCA9518 from NXP (formerly known as Philips), an expandable 5-channel I²C hub.

This device is mainly developed to solve the capacitance load an I²C bus is allowed to have (max. 400pF). It has one "main" I²C input, while it can have up to 4 extra I²C outputs, completely isolated one from the other. So, the main I²C input doesn't see neither of the output loads. Each output load individually also doesn't "see" the capacitance load of the other outputs.
This way, you can have multiple I²C paths while adhering the max. bus capacitance of 400pF.

Next, this device has 5V tolerant I²C lines. That means, the device itself is powered with 3V3 (so, can be connected to the power supply of the FoxBoard), but the pins can "communicate" with I²C levels that go till 5V. Result: device can be used as a 3V3 to 5V translator, without having to have complex voltage levelling circuitry in between. This is a very important input for me, since that will solve my voltage level problem.

Another nice thing about the PCA9518 is that it can be "cascaded" with other PCA9518 chips, extending your I²C bus almost infinitely.

More information about the PCA9518 can be found here.

If you check the application note on page 10, then you will see that in the example given there are two PCA9518 devices, cascaded one to the other. Bpth PCA9518 devices are powered with 3V3, together with the I2C bus master.
But all the other I²C devices are powered with 5V, showing you it's simple doable to "convert" the levels from 3V3 to 5V.

Putting my application on a USB stick...

2007-11-08T20:17:00.000+01:00

In case the 4MB of FRAM of the FoxBoard type MCM would not be sufficient, I can/will put my application on a USB stick and when the FoxBoard starts up, I can run my application from the USB stick.

This way, I can make bigger applications (there's 16MB of RAM available in the MCM version) and I don't have to flash the application in FRAM all the time too.

That's a time gainer and it will also prevent my FoxBoard FRAM from wearing out (although there are tens of thousands of writes that can be done).

Activating the USB feature during boot-up of the Linux kernel was/is quite easy. A small script must be put in a writeable FRAM location (see my Wiki pages for more details about this.

For the newer board I have, an FS version, this will be even more luxurious, since that board has 8MB of FRAM and 32MB of SDRAM...

Queue is fully operational!

2007-11-08T20:04:00.000+01:00

The queue mechanism I was working on, is fully operational! Nice to see it smoothless working...

As a test case, I've written the following software:

When I press and release a button, the time is measured. That info is sent to the message queue and when it arrives in the message queue manager, the data is analysed.

First, the message type is representing the IO expander which has caused that message. Next, I know the pin which has changed and I also know the time that pin has been low (so, the time the button has been pressed).

If the time is less than 1 sec, I'm lighting up a certain LED from an IO expander which has been configured as OUTPUT.
When the time is equal or more than 1 sec, another LED of the same IO expander is activated.

This way, I know my queue mechanism is working and I know I can measure the time a button has been pressed. Out of this, I can decide if I want to give a second (and in extreme conditions even a third) function to that button.

I still have to clean up a bit, but that's another part of my domotics system which is already working.

I'm satisfied about the progress

Oh, I love the FoxBoard!!! It's working so smooth!!!

Queueing, queueing, queueing...

2007-11-07T20:31:00.000+01:00

I'm currently busy making a mechanism whereby my IO expanders, used as inputs, are polling their inputs at a rate of a multiple of 10ms.

Each input pin can be polled independently at different times (but always a multiple of 10ms, with 10ms as a minimum poll time). For instance, if I take the PCF8575 IO expander, all 16 pins can have an individual polling time.

Polling is done on a separate thread. The thread is made as a "while ( 1 )" loop, with a "sleep" condition of 10ms. That sleep is accomplished using the function "select()", which normally is doing some IO to external devices.
However, you can set a time-out time and that's what I'm "misusing" for the moment. All other parameters are 0 or NULL, while the time-out is set to 10ms.

Every 10ms, a check is done to see if for (a) certain pin(s) the polling time has elapsed.

For instance, suppose the polling time for pin 1 is every 40ms and for pin 3 every 60ms, then at 40, 80 and 120ms pin 1 will be checked and at 60 and 120ms pin 3 will be checked. You see that every 120ms both pins 1 and 3 are checked!

When I have the result, I should of course do something with it. The IO pins are checking if a connected button is pressed or not. Since I'm checking at regular times, I can know when the button has been pressed, but also when the button has been released. So, I can measure the time the button has been pressed.

This is very interesting: this way, I can give multiple functions to one and the same button. For instance, if a button is pressed less than 500ms, it has a "normal" function (e.g. switching on/off a certain light), but if it has been pressed for more than, say, 2 seconds, I can for instance start dimming up/down that certain light!

All this info is gathered at the level of the IO expander class, but it has also to be sent to another IO expander which is used as output (for instance, to control a relays).

Since more than one IO expander is used as input, I needed a mechanism to not loose any information (which button is pressed, how long has it been pressed, to which IO expander is the button connected, etc.)

Therefore, I've created a structure which contains all that data. Next to this, I've created a message queue (in the same process, so not an IPC message queue). That message queue is bringing all that information into a queue manager.

That queue manager has a blocking receive call on the message queue and the moment a message arrives, the queue manager will analyse that message and see which destination it has to addressed it to.

I'm currently implementing that queue mechanism and the last thing I have to do, is to allow the queue manager (messages are already sent from the IO input expanders via the message queue to the queue manager, that already works great) to distribute the received data.

My development set-up

2007-11-04T13:44:00.000+01:00

To develop my software for/on the FoxBoard, I've chosen to use the following set-up:

My PC is a Pentium 4, 3.2GHz with 1GB RAM and two internal harddisks of 160GB each.
Next to this, there are another two external harddisks of 160GB each. Both external harddisks are connected using a FireWire connection (aka 1394).
You can see my set-up below:

On the left, you see the monitor for my Linux sessions (and occasionally also some Windows applications if the right monitor gets too busy).
Yes, I'm an animal lover,hence the wolf as a background picture (but in fact, tigers are my favourite ones...).

Next to this monitor, the monitor for my Windows applications.

If you click the picture, you will also see the two external harddisks (while a third one is waiting to be build into a harddisk case).
My main OS is (sorry, Linux freaks) WinXP Home Edition SP2. But I do like Linux more... See further.
On my PC, I've installed VmWare, so that I'm able to run Linux in a virtual machine (here you go, Linux freaks, I'm one of them too...)
I've done this to avoid having to use a second PC to run Linux. This way of working not only saves space on my desk, it also is much less power consuming
Taking care of the environment is one of my hobbit horses and I'm doing whatever I can to save as much as possible resources...
I'm running Kubuntu Gutsy Gibbon as Linux OS, where I've installed the SDK of Axis (with lots of modifications done by John Crispin).
I recently re-installed the SDK (due to a crash with Kubuntu while upgrading from verions 6.10 to 7.10, see another article in this blog...), using the SVN installation script as explained on the Acme Website.
I've also installed Samba on my Linux machine, to be able to see the content of certain directories under Windows too.
I also have two LCD monitors: one for my Windows applications and one for my Linux applications.

"But, you idiot, if the environment is so important to you, why do you use two monitors then", one can ask? Well, let me try to "defend" myself:
1. Both monitors are of the LCD type, so together they're consuming less than one "classic" monitor
2. It's very unhandy if you have to "control" the screens of two different operating systems on one monitor
Next to this, I'm trying to do as much as possible from within my Windows environment (NotePad++ is a God's Blessing to do those things, see just below), so I don't really need much my Linux monitor, which I switch off then of course...

To edit my files, I'm using NotePad++ (visit http://notepad-plus.sourceforge.net/uk/site.htm for more info about this wonderful editor).
This editor is running under Windows.
But why did I choose again for a Windows application to develop Linux stuff??? Well, see below:
- I'm spoiled by the Windows GUI for more than 15 years now, so kicking the habbit is quite "heavy"
- I didn't find any decent and competitive editor running under Linux. I've tried Eclipse, NetBeans, KDevelop, Kate,...
  All have their own pro's and con's, but none of them could compete with the ease of use of NotePad++
- I'm able to in fact do almost everything from my Windows environment (even running Linux tasks), so why would I switch constantly between Linux and Windows?
The only reason I really need to see my Linux OS on my monitor, is when I need the debugger (see further), since this one is solely running under Linux. And also (but very occasionally) when I have to restart my Linux virtual machine (but that's mostly because I've made a mistake...)
To compile my FoxBoard software, I'm using (of course) the compiler/linker which is part of the SDK provided by AcmeSystems (http://www.acmesystems.it). This one is (for sure) running on my Linux virtual machine.
To debug my FoxBoard software (yes, I indeed need a debugger from time to time), I'm using Insight from RedHat (visit http://sources.redhat.com/insight to know more about this debugger).
I've found a way to start my makes on the Linux machine from within NotePad++. This is extremely handy, since I really like this editor and now I can even start my builds on the Linux machine and see the feedback in a console window of NotPad++.
To acomplish this "trick", I wrote a small parametrised shell script that I'm calling from NotePad++.
But there's more to it: to be able to call a Linux script from Windows, you need a tool like plink to "bridge" the gap between Linux and Windows. The whole Putty suite (including plink) can be found here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
Plink needs a private/public key to see if it's allowed to run a script on a Linux machine, coming from a Windows environment.
Once plink is installed correctly (create a private/public key using puttygen, part of the Putty suite, for this), I can call this application with the necessary parameters to run the build on my Linux environment.
To be able to do that in NotePad++, you need to install a plug-in (NotePad++ has an open architecture, that is, you can create plug-ins for NotePad++ yourself) called NppExec. This plug-in is written by Vitaliy Dovgan and can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=189927&package_id=224034.
The image below shows my NotePad++ editor with the console window showing the compilation steps of a build:
At the end of every compilation, I've a script running that automatically downloads the new program to the FoxBoard, using FTP (file transfer protocol).
The FoxBoard is connected to my Linux machine via my router (so, using ethernet connections).
I've created a special directory on the FoxBoard root file system in RAM, to which I FTP my new executable after every build. As said before, this is done automatically.
So, very frequently downloading the application for testing purposes in that memory area cannot harm the life span of the FoxBoard memory, since it's RAM.
Once the application is more or less ready for another test phase, I'm copying the application in a USB memory stick, connect that stick to the FoxBoard, restart the FoxBoard and automatically this application is read out while booting up the FoxBoard.
The application starts automatically to run.

Easier than this is to change code, recompile and reprogram in the FoxBoard, is next to impossible, I think...

For those interested: I also have a Wiki page explaining some stuff much more in detail.
Pls. visit http://www.gevawebsolutions.com/wiki/index.php?title=Main_Page to read more.

What I'm currently doing (Nov. 2007)

2007-11-04T12:37:00.002+01:00

After having improved the I2C driver for the FoxBoard, I started to develop different component classes for I2C devices.

As already said in a previous post, my whole domotics system is based on components capable of handling the I2C protocol.

This protocol is very simple and yet, very powerful. There are only two wires involved: one data line, called SDA (serial data) and one clock line, called SCL (serial clock).

The clock line is mainly there for synchronisation purposes between a master (the one who sends out the I2C commands, mostly a [micro]processor such as the FoxBoard) and the slave (the one who reacts upon the commands sent by the master).

A complete description of the I2C protocol can be found on the NXP (formerly known as Philips) website:

http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf

This spec dates from January 2000, but I recently found a (very recent) update of that spec here:

http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf

The fact there are only two communication wires involved, makes it very interesting wrt PCB space, when developing the hardware.

That said, I'm currently developing a C++ based hardware abstraction layer. The purpose of this layer is to hide the peculiarities one can have when a direct Linux kernel call is to be made. It's quite cumbersome and error prone to do so, hence one of the main reasons I developed that HAL.
Calling I2C functions is now very easy and very transparent: understandable calls can be made, which "under the hood" do all the dirty work, away from the user.

The HAL is next to finished, so I'm going one step higher in the creation of component classes for I2C devices: classes for the I2C devices themselves.

Those classes are all communicating to the I2C driver in the kernel, through the HAL. So, I immediately benefit from my own HAL class... ;-)

The components I am/will using/use for my domotics system, are (all I2C controlled):

PCF8574: an Input/Output expander (short: IO expander) which can detect changes at its input pins (when used as input) or control the status of the output pins (when used as outputs).
The advantage of such device is:
1. I2C controlled
2. Each pin can individually be set as input (to measure) or output (to control) at any moment in time
PCF8575: Similar to the PCF8574, but this one has 16 IO pins iso "only" 8 IO pins.
PCF8591: an ADC device (analogue to digital converter) capable of measuring analogue signals (light, temperature, movement) and translate it in digital information.
TDA8444: a DAC device (digital to analogue converter), which does just the opposite of a PCF8591. It converts digital information to analogue values.
This device will be used to control dimmers etc. Mostly, dimmers can be controlled by applying an analogue voltage between 0 and (mostly) 5 to 10 V. This corresponds with no power at all at the output of the dimmer (when applying 0V) to maximum power (when applying 5 or 10V, depending on the type used).
Those dimmers will be used to create different atmospheres in some rooms (for instance, when watching television, you want another light compared to reading the newspaper in a seat in the living room).
PCF8563: a RTC device (real time counter) which is necessary to keep track of the time in the system. This device has a high level of accuracy and can be used to synchronise the clock of the Linux system, after -for instance- the system comes out of stand-by.
24C32: a NVM device (non-volatile memory) which is needed to store values that will be needed again at a later time (for instance, store the intensity of a certain dimmer at a certain moment, store the reference temperature for the different rooms,...).
LM75A: a temperature measuring device. Such device will be placed in every room to be able to measure/control the temperature individually.
Also, this device will be used to measure the outgoing and incoming water temperature of the floor heating system and to measure the temperature in the hot water boilers.
Maybe others will be added...

For all of the above, I'm busy creating and testing C++ classes to be able to reuse the code when more than one such component is needed.

Classes which are already more or less complete (well... what is complete anyway...):

PCF8563
PCF8574
PCF8575

Here's a picture of my current test set-up (didn't develop PCB's yet):

On the picture above, you can see a close-up of my "test environment". On the image, there are (click on the image to see the big version):

Two PCF8575-IO expander components (the two greenish parts)
One PCF8574-IO expander (top left of the white breadboard)
One PCF8583-RTC (bottom left of the white breadboard)
Another PCF8563-RTC (small green PCB on the left of the white breadboard)

The great discovery: FoxBoard

2007-11-04T09:16:00.000+01:00

While looking for a decent processor for my domotics system, I initially started with a good old 8051 derivative (Philips 89C668 version).

However, soon it appeared this processor was way to "small" to fulfil the needs I had. Small in the sense that it had too few memory (both ROM as well as RAM).
Also, there was no basic functionality available, such as a robust OS, USB functionality, ethernet functionality, web server, etc. etc.

Pure by luck, I met a colleague at the office who was experimenting with a couple of 8051 alternatives, to extent their automatic test cases environment (testing high quality Philips televisions). One of their test cases was the FoxBoard.

Honesty obeys me to say I'd never heard of it before. But since I heard it was running embedded Linux (waaawww!!!!), I was immediately triggered (read: very much interested).

I got some information from this colleague and one of the first things I did, was surfing on the inet to find more information about this small device.

I must say: when I read the specs of that device, I was really astonished! So much on such small board, running Linux!!!
There was USB, RS232, Ethernet, FTP, SSH, WebServer, Telnet,... Next to complete!

I immediately got me such board and ever since, I'm working on it to develop my home automation system (aka. domotics).

This is how the board I currently use, looks like:

This is the famous MCM Classic Red FoxBoard.
MCM means multi components module, since this chip contains next to the processor, also the RAM and FLASH chips (and maybe more), all in one.

I must say, I'm very satisfied about the board and have spent already many, many hours developing software on it.

One of the first things I needed, was a decently working I2C driver. The original one was not really performing the way I wanted it to perform, so I decided to rewrite most of the existing driver.
That resulted in a stable, reliable and fast I2C driver which I made freely available under the GPL license to the FoxBoard community. You can find it here: Tuned I²C driver

Since my whole system is running on the I2C protocol, I don't have to worry about this one any more. At least, my basic protocol is working fine, the rest of the software/hardware is based on this protocol.

In the mean time, there's a newer version available, which has more FRAM and RAM. Here's a picture of the new version:

This new board has 16MB of FRAM and 32MB or RAM! More than enough to do wonderful things with it...

You can find lots of information on the AcmeSystems web site:

http://www.acmesystems.it

There's also a newsgroup about the FoxBoard, which you can find here:

http://tech.groups.yahoo.com/group/foxboard/

Attention: a Yahoo account is needed to be able to actively participate in this newsgroup.

--Geert