Posts Tagged 'navit'

Navit Update

It’s been a while since I’ve done much with Navit. My regular week doesn’t include much travelling and I’ve just not had that much time to devote to it. When push comes to shove, my wood turning normally wins when competeing for my free time.

However, I had a chance to play again this week with the latest SVN-2173. I also had an idea of something to try. I downloaded a map of a much smaller area. Normally I get most of the united kingdom, which amounts to about 80MB map. But I decided to try capturing just around about the county I live in. This got me a map of just 17MB.

It’s dificult to quantify the differences, as there is no benchmark mode to try. However, my feeling is that the smaller map led to a more responsive UI once I had a route planned. Normally having a route planned causes my n810 to become largely unusable, However with the smaller map it seemed to be better. Not great, just better.

Today I tried a back to back comparison, as I had previously been going on memory of last use, on a different build. And Lots has changed since then. (Look right, there is an rss of the changes going on, and there is normally a lot of activity)
So I setup with a short route planned and tried both my regular size of map and a smaller size of map, one after the other. I also used maps cut on the same day, so no diffference in content for the area I’m in.

The main thing I notice is that tapping to go into the menu system seemed to take much less time, I counted something like 10/11 seconds with the large map, and more like 2/3 with the smaller map. (Still not blistering by any standards, but deffinately better).
My caviat to this is that I really can’t be sure that equivilent provessing was going on each time. GPS signals can be a little wild, and a couple of ‘off’ readings could of had the unit attempting to replot routes in one test and not the other. However my *feeling* is that the size of map does effect it’s performance. Even when showing the same sized area of the map, and plotting the same and similar length routes.

I’d love for other people to try the test and see what they think, am I imagining it? If anyone else tries please let me know what size of maps you compared, and what country etc.
In the meantime I’ll go chat in #navit and see if the guys there have any idea why it should make a difference. And if they have any ideas for a more scientific test.

Getting call stack tracing out of navit (or any C application)

This evening I’ve been working on something I’d been thinking about for a little while. As part of my trying to get involved in navit I discovered that I understand fairly little able C and very little about how navit works. Before I could be any real use I needed to be able to get more understanding on both counts.

Initially I turned to looking through the source trying to understand bits and pieces. But it can be quite difficult to follow what code is going to do without a good grasp of what gets called when. So I turned to the runtime debug that can be enabled in the config file.

This debug is a good start, but what I found was the output is flat, it’s impossible to tell which calls are even from the same method let alone at what level they are being called. Having mused outlound on the active and friendly IRC channel #navit, Gerrit picked up on my talk of instrumenting the code and wrote a blog post about what he found.

Basically a built in capability of GCC allows you to instrument start and end of function calls. It is used in the example to generate a cool image that represents the logic flow of the application.

However this just show what calls what and how often. It still doesn’t really show me what I was after… which brings me to this evening. I figured out how to use the technique to do a couple of useful things. Firstly I wanted to just output Entry:> function pointer and Exit > function pointer,  inline with Navit’s debug. Fortunately for me this defaults to stderr. And being lazy I could just write to stderr also and get the information inlined.

The second thing I wanted to achieve was to indent the debug as it went into methods, and unindent (?) when exiting. So I patched the debug.c source file to have an indent value. Whenever it writes a log statement it checks if this value is other than 0 (the default) if it is then it first prints that number of ‘-’s before outputting  the debug line.

Similarly the Function entry and function exit output is also indented. This means that instead of this:

      navit:attr_new_from_text:enter name='name' value='timestamps'
     navit:attr_new_from_text:enter name='level' value='1'
     navit:convert_to_attrs:ret=0x500f0
     navit:attr_search:enter attrs=0x500f0
     navit:attr_search:*attrs=0x4fe48
     navit:attr_search:enter attrs=0x500f0
     navit:attr_search:*attrs=0x4fe48
     navit:attr_search:*attrs=0x50dc8
     19:29:05.884|navit:attr_new_from_text:enter name='center' value='4808 N 1134 E'
     19:29:05.884|navit:coord_parse:enter('4808 N 1134 E',1,0xbee102e0)

You get something like this:

-Entering E0x1110c
--Entering E0x334e8
---Entering E0x1ca68
--Exiting X0x1ca68
-Exiting X0x334e8
--Entering E0x11874
-Exiting X0x11874
--Entering E0x14b24
---Entering E0x36cec
--Exiting X0x36cec
---Entering E0x139fc
--Exiting X0x139fc
---Entering E0x14950
--Exiting X0x14950
---Entering E0x11d4c
--Exiting X0x11d4c
--navit:main_init:Warning: LC_ALL is set, this might lead to problems
-Exiting X0x14b24

That’s starting to look pretty good, but pointers aren’t much good to people in understanding what’s going on. This is were the clever/hacky bit comes it.

There is a tool called addr2line which uses a map file that can be gereated at compile/link time to take in a function pointer and tell you which file,function and line it comes from

After considerable messing about I came up with a long and hacky command that would find all the function pointers in my log file, perform an addr2line on them to generate a long sed script

which is then run to substitute those values in the log.

the result of which is something that looks like this:

-Entering Emain start.c:72
--Entering Eevent_glib_init event_glib.c:194
---Entering Eplugin_register_event_type plugin_def.h:31
--Exiting Xplugin_register_event_type plugin_def.h:31
-Exiting Xevent_glib_init event_glib.c:194
--Entering Eatom_init atom.c:25
-Exiting Xatom_init atom.c:25
--Entering Emain_init main.c:218
---Entering Ecallback_list_new callback.c:40
--Exiting Xcallback_list_new callback.c:40
---Entering Efile_exists file.c:236
--Exiting Xfile_exists file.c:236
---Entering Emain_setup_environment main.c:189
--Exiting Xmain_setup_environment main.c:189
---Entering Edebug_level_get debug.c:119
--Exiting Xdebug_level_get debug.c:119
--navit:main_init:Warning: LC_ALL is set, this might lead to problems
-Exiting Xmain_init main.c:218
--Entering Emain_init_nls main.c:289
-Exiting Xmain_init_nls main.c:289

Now we’re talking, now it looks something like serious trace.

So how do you do it?

first you need to apply my patch to debug.c and debug.h (who knows sometime it might even get checked into the normal version)

Then you need to run configure with something like the following:

./configure CFLAGS=”-g -finstrument-functions” –disable-samplemap LDFLAGS=”-Wl,-Map=navit.map”

Then make as normal

this compiles the code with instrumentation in place. It also creates lots of navit.map files in the source tree that are required to do the mapping to function names etc.

With this verison of navit configure the xml file to turn on the level of debug you want, I like to set timestamps=1 to give me some idea of elapsed time between debug statements.

Then execute navit like:

navit 2> debug.log

Navit will run slower with debug output runnig obviously.

Do what ever you’re trying to do, then when you close navit you have a debug.log file tha tlooks like my second example above.

Now you need to take this log file back to your source tree. (if you’re pulling it back from a device like I do from my n810 I’d advice gzip’ing it before transmitting text compresses nicely)

once back in your source tree in the same folder as the navit executable got built, you now need my hacky script UpdateLog.sh

Make it executable and run:

./UpdateLog debug.log

This will take a while to run, at the end it will of spat out a couple of files you can ignore (sedscr and sedscr2)

and it will of produced newTrace.log which should be complete with switched out function names and line numbers.

Of course the same technique applies to any C application.

If you look in the DebugPatch the code added is pretty standalone :-

/* Output trace file pointer */
static FILE *fp;  /*used in the constructor methods*/
int debugptr = &debug_timestamp;  /*used to identify pointer to static method debug_timestamp so we can exclude it from entry/exit logging*/

void main_constructor( void )
{

  fp =stderr;    /*At the moment we put all instrumented output to stderr */
    indent=0; /*set indent to 0*/
  if (fp == NULL) exit(-1); /*If we had any trouble getting a pointer to stderr then FAIL*/
}
/*Close file handle after main is finished*/
void main_destructor( void )
{
  fclose( fp );
}
/*instrumentation function that gets called on entry into any function if you compile with -finstrument-functions*/
void __cyg_profile_func_enter( void *this, void *callsite )
{
  /* Function Entry Address */
  int i=0;  /*define iterator int for use in for loop*/
 if ((int *) this == (int *) debugptr){  /*check if this function is debug_timestamp since that's a sub function within the debug statement
                                the output gets werid if you trace it's entry/exit*/
    /*don't do entry/exit for timestamp function*/
 }else{     
        indent++;     /*we've entered a function so increment the indent*/
    if (indent > 0){ /*if indent is more than 0*/
        for (i=0; i<indent; i++){
            fprintf(fp,"-");    /*prefix out output with one - for each indent level*/
        }
    }   
  fprintf(fp, "Entering E%p\n", (int *)this);  /*output a log statement showing Entering EfunctionPointer*/
 }   
}

/*instrumentation function that gets called on exit from any function if you compile with -finstrument-functions*/
void __cyg_profile_func_exit( void *this, void *callsite )
{
  /* Function Exit Address */
  /*dbg_decrement_indent();*/
     int i=0;  /*define iterator int for use in for loop*/
    if ((int *) this == (int *) debugptr){/*check if this function is debug_timestamp since that's a sub function within the debug statement
                                the output gets werid if you trace it's entry/exit*/
    /*don't do entry/exit for timestamp function*/
 }else{   
 indent--;    /*we've entered a function so increment the indent*/
    if (indent > 0){  /*if indent is more than 0*/
        for (i=0; i<indent; i++){
            fprintf(fp,"-");  /*prefix out output with one - for each indent level*/
        }
    }   
  fprintf(fp, "Exiting X%p\n", (int *)this);  /*output a log statement showing Exiting XfunctionPointer*/
}
}

The only other code I added was to make the navit projects debug output methods pay heed to the indent level in the same way as these entry/exit trace points.
the beuty of this is that you can simply compile without -finstrument-functions and it all goes away! unlike actually adding real debug statements to entry/exit of every single method

Participating in OSS

Fairly recently I went through the process of being allowed to participate in an open source project ‘Navit
Working for a big company I have to just make sure there are no potential contamination issues. Very boring, but done now.

Anyhow as it happens I’ve not done much more than look at the source and realise I don’t know enough about C to be able to do much. Particulalry given the code has basically no comments. However I was able to figure out how to do the main thing I wanted, which was to set up the On-Screen-Display settings to be appropriate to the n810. That involved figuring out how to set position, width and heigh of the box and the font size to use. Having figured out that much I decided the most helpful thing I could do for the project, or at least for the n810 community, was to add the information to the project Wiki.

In doing this I found a couple of the OSD items were not working, and quickly after I posted about it to Internet tablet talk, Gerrit provided a fix.
He obviously understands the code way better than I and it feels like maybe I’m better off trying to help by trying to document things and help others get going. Rather than attempting to get good enough to contribute code.

That said there are things I’m still tempted to change. At the moment all config comes from a single xml config file. And everyone needs to edit this file to even get things working. I’d be tempted to split things up a little to allow people to get going and updating with community contribution easier.
So I’d have map location in the main file, but all the graphic config in another. That way the community could create various pre-canned layouts that could be dropped in place with no hand editing required.

Likewise for vehicle schemas, that dictate what is drawn on the map at what scale. And what colour. Whilst the ability to modify these things is cool, it would be nice to have an eaiser time of sharing created profiles without having to hand merge files.

However I’m not sure where I’d start in terms of altering the code to allow for split up config. And even if I knew how to code it, I don’t know anyone would agree it’s the right thing to do.

Since starting to play with navit its already come on a long way. I can now have a 3d view whilst driving. It looks very cool. BUT… It’s still too slow to keep up when driving. And has a tendancy to crash if it has to recalculate a long route. And, for the moment at least, the routing does a poor job compared to a comercial solution. However, it’s FREE! It’s improving fast, and it is the most promising option to be able to ditch proprietary maps.
My main concern is that maybe the n810 simply isn’t fast enough to do a good job. Of course that can soon be remedied when Nokia launch the next generation internet tablet. But it would be nice to think that maybe some tweaks can be applied, some optimizations made, that would give it that boost required to really replace my old tom-tom.

Of course all this is competing for my hobby time with my main hobby of wood turning, and I get much more joy from that than I get from feeling stupid looking at C. But maybe in time I’ll gain enough understanding to contribute in more meaningful ways. Until then I’ll enjoy keeping up with the latest and seeing it improve.

Christmas goodies

Nearly the end of 2008, and I’ve had a great Christmas.
I’ve had some nice times visiting family, playing silly games, and drinking generally too much. And I’ve apparently been a very good boy this year as I’ve been treated to lots of things I really wanted.

One early Christmas present came for my geek side. I’ve been looking for some time at Navit on the n810. It has great potential but had not received an update for the n810 for most of the year.

Just before Christmas Gerrit responded to some forum posts I’d made and provided a new build. As well as updating the source to make it easier to build for maemo.

This was very good news, and I’m keen to have a go myself and see if I can tinker with the source. However first I must wait to return to work to get appropriate approvals in place (sometimes working for big corp is restrictive)

Additional updates from relatively recently were the new alpha 2 of fennec, mozilla’s mobile browser. Which is getting much better. But is still very much alpha. Looking forward to its development in 2009 I’m sure it will be able to overtake the built in browser.

And most recently an update to Mediabox media player
This has been my music player of choice on the n810 for some time. So it’s nice to see an update. However I’m not sure what to make of that update so far. Firstly it seems to be more buggy. I’ve had it crash on me a couple of times already. And secondly they appear to have removed the clock view which I really liked. I tend to use this as a bed side music player at night. Set something playing then switch to the big clock view.
I am hoping that further updates will be forth coming to improve stability, and maybe return the clock. Of course I should probably get off my arse and give them proper feed back.

So that has been my geek haul of Christmas presents.
But that all pales next to the great things the wood turner in me got.

First and foremost… my awesome girlfriend, light of my life, bought me a bandsaw. :-) I’ve been after one for sometime. Anyone that knows woodworking will understand the deep joy I have at finally having a bandsaw in my workshop. I’ve had it up and running for not much more than a day, and already I feel the benefit. This means in 2009 I can spend less time sawing (badly) by hand, and more time getting things done. I’ve particularly looking forward to being able avoid having to rough stock down from square on the lathe.

My family also obliged me with various things I’ve been after. A whole slew of new jigs for my tormek, allowing me to now do a perfect sharpening job on all my chisels. I’ve come to understand just how big of a difference it makes to have properly sharp tools to work with. And these will again mean I spend less time faffing about, and more time with sharp tools doing the fun part of turning.

And if that wasn’t all enough, I also got a few items for the lathe itself: a new bowl turning rest, a drill chuck for the tail stock, and, at long last, a live centre tail stock set.
This of course means I now have no excuses for a whole range of challenging projects. Until now I’ve been able to excuse my amateurish attempts by saying ‘ but I don’t have a live centre’.

Now my only problem is that my garage is rather cold at this time of year. and there is a limit to how long I can spend out there before my feet need recuperate in the warm. I’m currently considering whether it’s worth the effort to insulate the roof. Or just man it up, and know that the weather will soon get warmer.

It should now be clear why I’ve not blogged for a while, and if I don’t again for some time you know where I’ll be… in fact I’m heading there now.


RSS Navit SVN Feed

  • Revision 2866 by martin-s - Fix:Android:Corrected and added keycodes December 11, 2009
  • Revision 2865 by martin-s - Fix:map_binfile:Don't crash on search December 10, 2009
  • Revision 2864 by martin-s - Fix:Core:Better callback for osd initialisation December 10, 2009
  • Revision 2863 by martin-s - Add:Core:New POI vehicle December 10, 2009
  • Revision 2862 by martin-s - Fix:binfile:Don't crash on non-existing files December 10, 2009
  • Revision 2861 by martin-s - Fix:Core:Correct parameters December 8, 2009
  • Revision 2860 by martin-s - Fix:Core:Don't crash with empty displaylist December 8, 2009
  • Revision 2859 by martin-s - Add:Core:Made selection more flexible December 8, 2009
  • Revision 2858 by martin-s - Add:Android:Callback on activity change December 8, 2009
  • Revision 2857 by martin-s - Fix:Core:Avoid overwriting of attribute December 8, 2009

My Twitter

Error: Please make sure the Twitter account is public.

blog Archieve

 

December 2009
M T W T F S S
« Nov    
 123456
78910111213
14151617181920
21222324252627
28293031