Monday, 28 April 2008

It's been a while...

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:
  1. The thread for the IO polling is already there
  2. 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();

Saturday, 9 February 2008

Need for debugging? Well, there is...

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!

Tuesday, 5 February 2008

Auto log-in? Sure!!!

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!