Skip to main content

@Germany... Remote Debugging for Embded Systems...

Alsalam alikom wa r7amat Allah wa barakatoh

Hope you are all doing well...

I missed blogging so much... but don't worry, I've prepared two or 3 long posts ;)... wait for them...

For those who don't know already, 3 of 3DEER team managed to travel to Germany in a 1-month scholarship (the remaining 2 has military service)...

I'll speak about Germany Trip in shaa Allah in details sometime later be ezn ellah... because it's not only my memories that I'll speak about.... you know!

So, for now, I'll speak about what we do there (technically)...
During our graduation project development cycle, we encountered one problem several times in which we really wished we can put a break point on the code loaded on any of the robots we have (LEGO or Khepera)... we really wanted to debug that code cuz the behavior was really unexpected. We decided to add this as a future work to our project.. just in case somebody got interested in this topic and decides to extend our work... fortunately, we were those ones who got that chance... I hope we are up to it....

So, let's dig into the topic (after that long introduction)..
The project is called Remote Debugging for Embded Systems (RDES, pronounced 'Ardis').. the aim is to provide an expendable architecture to debug programs on embded systems. How much expendable? to the extreme, that's if we can allow users to add 10 lines of code to add support for a completely different processor to be debugged, we consider this the success...

The architecture is simple, there will be a small source file linked with ur original code running on the robot that we call a Stub, this stub is the backbone of adding support to other micro processors, we intend to keep it as simple/compact as possible, and to provide all the client code (running on the host machine -usually a pc) as portable as possible. We then have build the client code as Service Oriented Architecture to allow two things:
1- Integration with Microsoft Robotics Studio.
2- Extendability, it's much easier to extend our project with multiple services... as you will see later...
So, about the client code, we have 3 main services..
  1. Mapping Service:
    You know about Debugging Information? this is an additional file that the compile generate. This file contains mapping table.. in it's simplest form, it has something like this:
    UserLine# AssemblyLine#
    1 1
    1 2
    2 3
    this means that line one in user code (source code) has generated two assembly lines.. which are 1 and 2 while the second user code has generated only one assembly line...
    the debugging information file contains much more information than just that mapping. It also has a Symbol-like table, that can be used to look up where any symbol is located in the application space.
    Back to Mapping Service, the idea here is to have a generic service (generic to the level of debugging information format), so that anybody decides to add support to another format, would implement a service like this one which hopefully would behave the same.
    The service should provide basic operations on debugging information, like "int GetAssemblyLine(int UserLine)"...
  2. The CommunicationManager Service, this service has some logic of a debugger.. it's made to minimize the need to write code on Stub, instead, we do some more complicated logic. This also has a disadvantage which is, it increases the communication between embedded system and the client PC... you know, every project requires some design decisions, we looked at the benefit of having such a feature and thought, some more milliseconds would not hurt.
So, that's briefly what we decided to do since yesterday's night...

Ah, one thing to remember, it's now August-14, the past 10 days, we've not been playing, we have made a decision to use GDB (GNU DeBugger) which we thought would be a good experience to employ an open source project in a research project -specially that non of us did such a thing before-. But unfortunately, we agreed yesterday that this decision was not the optimum one. As GDB was not elegantly written and it's not easily extended (at least it requires the user to compile the source code for Host & Target machine to be able to debug)... Al 7amd lellah, bad decisions happen, I believe what differs is when do people realize that they made a wrong one and how flexible are they to return to the early basic step of thinking what to start doing tomorrow...

Thanks Allah I've that wonderful team... (Although I miss Mustafa & Kamal... Maybe if they were here, we would have not made that first decision, I believe this is the best for everybody as Allah always do)

That's if for now....

The post seems so technical, but I promise the long posts I spoke about earlier have nothing technical in.

Alsalam alikom wa ra7mat Allah wa barakatoh

Haytham Alaa,
Heinz Nexdorf Institute,
Paderborn University,
Paderborn,
Germany.

Comments

  1. good post, wish u good luck

    ReplyDelete
  2. nice post,
    BTW Amen

    ReplyDelete
  3. u didn't mention the debbugger u used later or u used GDB bardo :D !

    and please .. dont tell me u wrote one on your own..!

    ReplyDelete
  4. Alsalam alikom wa ra7mat Allah wa barakatoh..

    Thanks all for those nice comments :)

    Fouad,
    As we found out, GDB was the only respectable software debugger we found, all other respectable debuggers are hardware ones which either replaces the processor or plugs an additional piece over the processor...
    As we said before, even GDB doesn't provide us the flexibility we are looking for.
    According to this, I'm sorry to tell you what you didn't want me to tell you about.... yes, we wrote one on our own :D... we made the stub and the debugger...
    but this was not done completely cause of two reasons
    1- We had less than 14 days to read, design and implement the debugger
    2- The cross compiler for khepera that everybody uses (gcc for Motorola processors) doesn't generate enough debugging information to allow things like breakpoints, stack dump and such features..

    I know I spoke a lot but I tried to make it clear why we had to so..

    Thanks.

    ReplyDelete
  5. well.. i think that was the only solution as you said..
    and i am not the one who wrote the debugger so its ok with me :P
    ..any way ..i think the RDES as an idea is/was awesome really ..
    and speak alot as u like ..its your blog :D .. your nice blog* :D
    (Y)

    ReplyDelete

Post a Comment

Popular posts from this blog

Windows7 adds Math Input Panel

Alsalam alikom wa ra7mat Allah wa barakatoh… I was reading a windows team post about Input Panels improvements in Windows7 [ here ]. When at the end I saw a very interesting –intuitive if you wish- new thing… which is, as you guessed, the Math Input Panel… Yes, that crappy font is mine… I “drew” that by mouse as I don’t have a tablet pen/pc. You can then paste it directly into word and it’ll recognize it as an editable equation… During my tests, the output panel (the top part) hanged, but I liked that the drawing panel was still responsive and I could still write/erase… till the top one started to respond again… One other thing to know, after you click Insert (that button down there) it copies the equation in MathML [ Wikipedia link ] format.. which is a standard way of representing equations and hence any application that recognizes the format can insert it not as an image but as a nice editable equation… If you think it recognized something wrong, you can click “Sele

Microsoft Web Platform Installer… coming near you

The Microsoft Web Platform Installer 2.0 (Web PI) is a free tool that makes it simple to download, install and keep up-to-date with the latest components of the Microsoft Web Platform, including Internet Information Services (IIS), SQL Server Express, .NET Framework and Visual Web Developer. In addition, install popular open source ASP.NET and PHP web apps with the Web PI. Here is the code snippet if you want to spread the word :) < a href ="http://go.microsoft.com/fwlink/?LinkId=146503" title=" Get the Microsoft Web Platform " > < img src ="http://www.microsoft.com/web/media/badge/get_microsoft_web_platform.png" alt ="Get the Microsoft Web Platform" border ="0" /> </ a >

Visual Studio 2008 Not saving changes or project properties?

Alsalam alikom wa ra7mat Allah wa barakatoh (Peace upon you) I’ve recently ran into problems with VS 2008. Summarized here: When you try to edit the project properties (specially C++ projects) you are faced with a little nice message saying “Exception from HRESULT: 0xF9F0F308”. Sometimes when you are editing a file (specially large ones), VS doesn’t recognize you’ve made changes (ie doesn’t display that ‘*’ in the files tabs) hence, when you save, nothing actually gets saved. For those 2 problems, a friend explained the problem and a work around (till they officially release a fix)… Open up a Visual Studio 2008 Command Prompt Run cd "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE" Make a backup copy of devenv.exe in case something does not work right. ie. copy devenv.exe devenv.exe.bak Run editbin /largeaddressaware:no devenv.exe Happy VSing… :)