Related
As I understand, a BSP (Board Support Package) contains bootloader, kernel and device driver which help OS to work on HW. But I'm confused because OS also contains a kernel. So what is the difference between the kernel in OS and the kernel in BSP?
What a BSP comprises of depends on context; generically it is code or libraries to support a specific board design. That may be provided as generic code from the board supplier for use in a bare-metal system or for integrating with an OS, or it may be specific to a particular OS, or it may even include an OS. In any case it provides board specific support for higher-level software.
A kernel is board agnostic (though often processor architecture specific), and makes no direct access to hardware not intrinsic to the processor architecture on which it runs. Typically an OS or application will require a Hardware Abstraction Layer (HAL); the HAL may well be built using the BSP, or the BSP may in fact be the HAL. A vendor may even package a HAL and OS and refer to that as a BSP.
The term means what it means to whoever is using it - context is everything. For example in VxWorks, WindRiver use the term BSP to refer to the layer that supports the execution of a VxWorks based application on a specific hardware design. A board vendor on the other hand may provide a complete Linux distribution ported to the board and refer to that as a BSP.
However and to what extent a particular vendor or developer chooses to support a board is a board support package regardless of how much or how little it may contain.
BSP definition is broad. It is a supporting software package for a specific board. BSP for a tiny microcontroller probably just contains HW drivers for its peripherals. On the other hand, for an embedded CPU it may contain HW drivers, bootloader and OS kernel and what not.
So the kernel in a BSP (board support package) is just a specific version of an OS kernel that has been ported to your board.
Im probably just saying the same things already said.
You have a chip and/or board product you want to sell to other (software) developers. A reference design (board) with the chip(s) in question are used. The BSP is a vague term to mean the software that is provided to you as a software developer to ideally make your life easier in using that product (chip and/or board) and adding your software to it or developing for it. So if it is a linux or rtos or other operating system capable platform and the vendor (providing the bsp) believes that users want an operating system and a specific operating system, then instead of you having to port the os to that target, they do it for you. If something like linux that is open source, then you either are told which linux sources to download then the patches made by the bsp are added and/or the bsp contains the complete sources for the whole thing already patched. Drivers, applications as deemed necessary by the vendor etc. Multiple operating systems may be supported if the vendor feels that is needed in order to attract customers to buy that board/chip product.
The whole package of software that you get from them to make that chip/board into your own product, is the BSP.
vxWorks kernel which you can run on a Board contains vxWorks core kernel and "other components" which may change from one environment.
Core kernel contains essential programs such as Scheduler, Memory manager, Basic File systems, security features etc.
These "other components" which are part of BSP may be optional or may vary from system to system, and helps the core kernel features.
In simple words, the image dislays the defination of BSP. Please correct me if I'm wrong
I would say for a well structured code base, the application layer should be abstracted from lower layers by the HAL layer. This would allow the app layer to be portable if we want to migrate the system to a new board. If you see you have board/CPU specific logic in your app layer, you know you have broken the portability.
The HAL layer functions' bodies should contain board specific code, here is where the BSP layer code comes into play. When we want to port the system to a new board, code changes should happens in the HAL functions' bodies, while the HAL functions' declaration should not change, which leads to the app layer remains the same.
I am wondering if anyone have any information on development boards where you can utilize ARM TrustZone? I have the BeagleBoard XM which uses TI's OMAP3530 with Cortex-A8 processor that supports trust zone, however TI confirmed that they have disabled the function on the board as it is a general purpose device.
Further research got me to the panda board which uses OMAP4430 but there is no response from TI and very little information on the internet. How do you learn how to use trust zone?
Best Regards
Mr Gigu
As far as I know, all the OMAP processors you can get off-the-shelf are GP devices, i.e. with the TrustZone functions disabled (or else they're processors in production devices such as off-the-shelf mobile phones, for which you don't get the keys). The situation is similar with other SoC manufacturers. Apart from ARM's limited publications (which only cover the common ARM features anyway, and not the chip-specific features such as memory management details, booting and loading trusted code), all documentation about TrustZone features comes under NDA. This is a pity because it precludes independent analysis of these security features or leverage by open-source software.
I'm afraid that if you want to program for a TrustZone device, you'll have to contact a representative of TI or one of their competitors, convince them that your application is something they want to happen, and obtain HS devices, the keys to sign code for your development boards, and the documentation without which you'll have a very hard time.
As of today OP-TEE runs on quite a few devices (see OP-TEE platforms supported) and several of them are development boards readily available. To name a few HiKey, Raspberry Pi3, ARM Juno Board, Freescale i.MX6 variants etc. Either you could pick up one of those or you could simply try it all using QEMU which is very well supported in OP-TEE.
You can get 45 days trial version for ARM fastmodels. RaspberyPI is supposed to support TrustZone too. www.openvirtualization.org has full open source implementation of ARM TrustZone. ARM is moving away from its proprietary TrustZone APIs to globalplatform API. GlobalPlatform also defines the APIs for Inter process communication etc.
There are a few select boards at this time that do allow development with TrustZone. As far as general purpose board, the FriendlyARM board is a good start (http://www.friendlyarm.net). Also, any board with a Cortex A15 processor must have TrustZone available due to the fact that the virtualization extensions can only be utilized from the Normal world. There may still be a question of whether or not the manufacturer has their own code running in the Secure world, but you can always try. The Arndale is a good development board, but unfortunately Samsung already has code running in the Secure world, so by the time you get access, you're running in the Normal world. So if you need Secure world access, look for non-Samsung, Cortex A15 processors. That'd be your best bet.
It's also worth noting the TI did not technically disable TrustZone. Instead, the bootrom code transitions the processor into the Normal world prior to switching execution to U-boot. So it's actually using TrustZone to move to the Normal world, but then doesn't provide a mechanism for moving back to the Secure world. To prove this, just try to read the SCR and you'll get an undefined exception, which is what will typically happen from the Normal world. However, if you perform a SMC call, it will execute just as expected (i.e., it switches to the Secure world, but then just switches right back to the Normal world), so it looks like nothing happened.
regarding openvirtualization, it can be ported to arm development board like the samsung exynos 4XXX.
you will have access to all source code including the secure os if you use openvirtualization.
but if you just want to develop programs that use the trustzone, I wonder if it is necessary. maybe there are standard driver or api that allow you to do it without worrying about compiling your own secure os?
the best thing you can do is contact parties like Gemalto and the people that brought Mobicore. Note that they will indeed ask you to sign an NDA.
Secondly, you can buy the ARM DS5 development suite. This comes with a lot of documentation including some on trustzone.
You should really take a look at the USB armory from Inverse Path: http://www.inversepath.com/usbarmory.html
It's built on open hardware and open source with full access to Trustzone (you can blow in die fuse to enable secure boot): https://github.com/inversepath/usbarmory
They successfully ran Genode within TZ and Linux in the normal world.
I've experience in doing desktop and web programming for a few years. I would like to move onto doing some embed system programming. After asking the initial question, I wonder which hardware / software IDE should I start on...
Arduino + Arduino IDE?
Atmel AVR + AVR Studio 4?
Freescale HCS12 or Coldfire + CodeWarrior?
Microchip PIC+ MPLAB?
ARM Cortex-M3 + ARM RealView / WinARM
Or... doesn't matter?
Which development platform is the easiest to learn and program in (take in consideration of IDE usability)?
Which one is the easiest to debug if something goes wrong?
My goal is to learn about "how IO ports work, memory limitations/requirements incl. possibly paging, interrupt service routines." Is it better to learn one that I'll use later on, or the high level concept should carry over to most micro-controllers?
Thanks!
update: how is this dev kit for a start? Comment? suggestion?
Personally, I'd recommend an ARM Cortex-M3 based microcontroller. The higher-power ARM cores are extremely popular, and these low-power versions could very well take off in a space that is still littered with proprietary 8/16-bit cores. Here is a recent article on the subject: The ARM Cortex-M3 and the convergence of the MCU market.
The Arduino is very popular for hobbyist. Atmel's peripheral library is fairly common across processor types. So, it would smooth a later transition from an AVR to an ARM.
I don't mean to claim that an ARM is better than an AVR or any other core. Choosing an MCU for a commercial product usually comes down to peripherals and price, followed by existing code base and development tools. Besides, microcontrollers are general much much simpler than a desktop PC. So, it's really not that hard to move form one to another after you get the hang of it.
Also, look into FreeRTOS if you are interested in real-time operating system (RTOS) development. It's open source and contains a nice walk through of what an RTOS is and how they have implemented one. In fact, their walk-through example even targets an AVR.
Development tools for embedded systems can be very expensive. However, there are often open source alternatives for the more open cores like ARM and AVR. For example, see the WinARM and WinAVR projects.
Those tool-chains are based on GCC and are thus also available (and easier to use IMHO) on non-Windows platforms. If you are familiar with using GCC, then you know that there are an abundance of "IDE's" to suit your taste from EMACS and vi (my favorite) to Eclipse.
The commercial offerings can save you a lot of headaches getting setup. However, the choice of one will very much depend on your target hardware and budget. Also, Some hardware support direct USB debugging while others may require a pricey JTAG adapter.
Other Links:
Selection Guide of Low Cost Tools for Cortex-M3
Low-Cost Cortex-M3 Boards:
BlueBoard-LPC1768-H ($32.78)
ET-STM32 Stamp Module ($24.90)
New Arduino to utilize an ARM Cortex-M3 instead of an AVR microcontroller.
Given that you already have programming experience, you might want to consider getting an Arduino and wiping out the firmware to do your own stuff with AVR Studio + WinAVR. The Arduino gives you a good starting point in understanding the electronics side of it. Taking out the Arduino bootloader would give you better access to the Atmel's innards.
To get at the goals you're setting out, I would also recommend exploring desktop computers more deeply through x86 programming. You might build an x86 operating system kernel, for instance.
ARM is the most widely used embedded architecture and covers an enormous range of devices from multiple vendors and a wide range of costs. That said there are significant differences between ARM7, 9, 11, and Cortex devices - especially Cortex. However if getting into embedded systems professionally is your aim, ARM experience will serve you well.
8 bit architectures are generally easier to use, but often very limited in both memory capacity and core speeds. Also because they are simple to use, 8-bit skills are relatively easy to acquire, so it is a less attractive skill for a potential employer because it is easy to fulfil internally or with less experienced (and therefore less expensive) staff.
However if this is a hobby rather than a career, the low cost of parts, boards, and tools, and ease of use may make 8 bit attractive. I would suggest AVR simply because it is supported by the free avr-gcc toolchain. Some 8 bit targets are supported by SDCC, another open source C compiler. I believe Zilog make their Z8 compiler available for free, but you may need to pay for the debug hardware (although this is relatively inexpensive). Many commercial tool vendors provide code-size-limited versions of their tools for evaluation and non-commercial use, but beware most debuggers require specialist hardware which may be expensive, although in some cases you can build it yourself if you only need basic functionality and low speeds.
Whatever you do do take a look at www.embedded.com. If you choose ARM, I have used WinARM successfully on commercial projects, although it is not built-for-comfort! A good list of ARM resources is available here. For AVR definitely check out www.avrfreaks.net
I would only recommend Microchip PIC parts (at least the low-end ones) for highly cost sensitive projects where the peripheral mix is a good fit to the application; not for learning embedded systems. PIC is more of a branding than an architecture, the various ranges PIC12, 16, 18, 24, and PIC32 are very different from each other, so learning on one does not necessarily stand you in good stead for using another - often you even need to purchase new tools! That said, the dsPIC which is based on the PIC24 architecture may be a good choice if you wanted to get some simple DSP experience at the same time.
In all cases check out compiler availability (especially if C++ support is a requirement) and cost, and debugger hardware requirements, since often these will be the most expensive parts of your dev-kit, the boards and parts are often the least expensive part.
This is kind of a hard question to answer as your ideal answer very much depends on what it is your interested in learning.
If your goal is just to dive a little deeper into the inner workings of computing systems i would almost recommend you forgo the embedded route and pick up a book on writing a linux kernel module. Write something simple that reads a temperature sensor off the SMbus or something like that.
If your looking at getting into high level (phones, etc) embedded application development, download the Android SDK, you can code in java under eclipse and even has a nice emulator.
If your looking at getting into the "real" microcontroller space and really taking a look at low level system programming, i would recommend you start on a very simple architecture such as an AVR or PIC, something without an MMU.
Diving into the middle ground, for example an ARM with MMU and some sort of OS be it linux or otherwise is going to be a bit of a shock as without a background is both system programming and hardware interfacing i think the transition will be very rough if you plan to do much other than write very simple apps, counting button presses or similar.
Texas Instruments has released a very interesting development kit at a very low price: The eZ430-Chronos Development Tool contains an MSP430 with display and various sensors in a sports watch, including a usb debug programmer and a usb radio access point for 50$
There is also a wiki containing lots and lots of information.
I have already created a stackexchange proposal for the eZ430-Chronos Kit.
No it doesn't matter if you want to learn how to program an embedded device. But you need to know the flow of where to start and where to go next. Cause there are many micro-controllers out there and you don't know which one to choose. So better have a road-map before starting.
In my view you should start with - Any AVR board (atmega 328P- arduino boards or AVR boards)
then you should go to ARM micro-controller - first do ARM CORTEX TDMI
then ARM cortex M3 board.Thus this will give you an overall view after which you can choose any board depending on what kind of project you are working and what are your requirements.
Whatever you do, make sure you get a good development environment. I am not a fan of Microchip's development tools even though I like their microcontrollers (I have been burned too many times by MPLAB + ICD, too much hassle and dysfunction). TI's 2800 series DSPs are pretty good and have an Eclipse-based C++ development environment which you can get into for < US$100 (get one of the "controlCARD"-based experimenter's kits like the one for the 28335) -- the debugger communications link is really solid; the IDE is good although I do occasionally crash it.
Somewhere out there are ICs and boards that are better; I'm not that familiar with the embedded microcontroller landscape, but I don't have much patience for poor IDEs with yet another software tool chain that I have to figure out how to get around all the bugs.
Some recommend the ARM. I'd recommend it, not as a first platform to learn, but as a second platform. ARM is a bit complex as a platform to learn the low-level details of embedded, because its start-up code and initialisation requirements are more complicated than many other micros. But ARM is a big player in the embedded market, so well worth learning. So I'd recommend it as a second platform to learn.
The Atmel AVR would be good for learning many embedded essentials, for 3 main reasons:
Architecture is reasonably straight-forward
Good development kits available, with tutorials
Fan forum with many resources
Other micros with development kits could also be good—such as MSP430—although they may not have such a fan forum. Using a development kit is a good way to go, since they are geared towards quickly getting up-and-running with the micro, and foster effective learning. They are likely to have tutorials oriented towards quickly getting started.
Well, I suppose the development kits and their tutorials are likely to gloss over such things as bootloaders and start-up code, in favour of getting your code to blink the LED as soon as possible. But that could be a good way to get started, and you can explore the chain of events from "power-on" to "code running" at your pace.
I'm no fan of the PICs, at least the PIC16s, due to their architecture. It's not very C-friendly. And memory banks are painful.
It does matter, you need to gradually acquire experience starting with simpler systems. Note that by simpler I dont mean less powerful, I mean ease of use, ease of setup etc. In that vein I would recommend the following (I have no vested interest in a any of the products, I just found them the best):
I've started using one of these (MBED developer board). The big selling points for me were that I could code in C or C++, straightforward connection vis USB and a slick on-line development environment (no local tool installation required at all!).
http://mbed.org/
Five minutes afer opening box I had a sample blinky program (the 'hello world' of the emedded world) running the following:
#include "mbed.h"
DigitalOut myled(LED1);
int main()
{
while(1)
{
myled = 1;
wait(0.2);
myled = 0;
wait(0.2);
}
}
That's it! Above is the complete program!
It's based on ARM Cortex M3, fast and plenty of memory for embedded projects (100mhz, 256k flash & 32k ram). The online dev tools have a very good library and plenty of examples and theres a very active forum. Plenty of help on connecting devices to MBED etc
Even though I have plenty of experience with embedded systems (ARM 7/9, Renases M8/16/32, Coldfire, Zilog, PIC etc) I still found this a refreshingly easy system to get to grips with while having serious capability.
After initially playing with it on a basic breadboard I bought a base board from these guys: http://www.embeddedartists.com/products/lpcxpresso/xpr_base.php?PHPSESSID=lj20urpsh9isa0c8ddcfmmn207. This has a pile of I/O devices (including a miniture OLED and a 3axis accelerometer). From the same site I also bought one of the LCPExpresso processor boards which is cheap, less power/memory than the MBED but perfect for smaller jobs (still hammers the crap out of PIC/Atmega processors). The base board supports both the LCPExpresso and the MBED. Purchasing the LCPExpress processor board also got me me an attached JTAG debugger and an offline dev envoronment (Code Red's GCC/Eclipse based dev kit). This is much more complex than the online MBED dev environment but is a logical progression after you've gained expeience with the MBED.
With reference to my original point noite that the MBED controller is much more capable than the the LPCExpresso controller BUT is much simpler to use and learn with.
I use microchips PIC's, its what I started on, I mainly got going on it due to the 123 microcontroller projects for the evil genius book. I took a Microprocessors class at school for my degree and learned a bit about interrupts and timing and things, this helped a ton with my microcontrollers. I suppose some of the other programmers etc may be better/easier, but for $36 for the PicKit1, I'm too cheap to go buy another one...and frankly without using them I don't know if they are easier/better, I like mine and recommend it every chance I get, and it took me forever to really actually look at it, but I was able to program another chip off board with ICSP finally. I don't know what other programmers do it, but for me that's the nicest thing 5 wire interface and you're programmed. Can't beat that with a stick...
I've only used one of those.
The Freescale is a fine chip. I've used HC-something chips for years for little projects. The only caveat is that I wouldn't touch CodeWarrier embedded with a 10 foot pole. You can find little free C compilers and assemblers (I don't remember the name of the last one I used) that do the job just fine. Codewarrior was big and confusing and regardless of how much I knew about the chip architecture and C programming always seemed to only make things harder. If you've used Codewarrior on the Mac back in the old days and think CW is pretty neat, well, it's not at all like that. CW embedded looks vaguely similar, but it works very differently, and not very well.
A command-line compiler is generally fine. Professionals who can shell out the big bucks get expensive development environments, and I'm sure they make things better, but without that it's still far better than writing assembly code for a desktop PC in 1990, and somehow we managed to do that just fine. :-)
You might consider a RoBoard. Now, this board may not be what you are looking for in terms of a microcontroller, but it does have the advantage of being able to run Windows or DOS and thus you could use the Microsoft .NET or even C/C++ development tools to fiddle around with things like servos or sensors or even, what the heck, build a robot! It's actually kinda fun.
There's also the Axon II, which has the ATmega640 processor.
Either way, both boards should help you achieve your goal.
Sorry for the robotics focus, just something I'm interested in and thought it may help you too.
I use PICs, but would consider Arduino if I chose today. But from your goals:
how IO ports work
memory limitations/requirements
interrupt service routines
I wonder if you best bet is just to hack in the Linux kernel?
BBC Micro Bit
https://en.wikipedia.org/wiki/Micro_Bit
This cheap little board (~20 pounds) was crated by ARM Holdings as an educational device, and 1M units were given out for free to UK students.
It contains an ARM Cortex-M0, the smallest ARM core of all.
I recommend it as a first micro-controller board due to its wide availability, low cost, simplicity, and the fact that it introduces you to the ARM architecture, which has many more advanced boards also available for more serious applications.
I'm a C# developer, I'm interested in embedded development for chips like MSP430. Please suggest some tools and tutorials.
Mono framework is very powerful and customizable, mono specific examples will be more helpful.
Mono requires a 32 bit system, it is not going to work on 16-bit systems.
There is currently no full mono support for the MSP430.
Mono doesn't run in a vacuum - you will need to make a program that exposes the microcontroller functionality to Mono, then link to Mono and program the entire thing on the microcontroller. This program will have to provide some functionality to Mono that is normally provided by an operating system.
The paged igorgue linked to gives you a good starting point for this process: http://www.mono-project.com/Embedding%5FMono
I don't know what the requirements of the Mono VM are, though. It may be easy to compile and use, or you may have to write a lot of supporting code, or dig deep into mono to disable code you won't be using, or can't support on the chosen microcontroller.
Further, Mono isn't gargantuan, but it's complex and designed with larger 32 bit processors in mind. It may or may not fit onto the relatively limited 16 bit MSP430.
However, the MSP430 does have a GCC port, so you don't have to port the mono code to a new compiler, which should make your job easier.
Good luck, and please let us know what you decide to do, and how it works out!
-Adam
The tools to use Mono on an MSP430 just aren't available. Drop all the C# and use C/C++ instead.
MSP devices usually have 8 to 256KB Flash and 256 bytes (!) to 16kBytes of RAM.
Using C# or even c++ is really not an option. Also, complex frameworks are a no-go.
If you really want to start with MSP430 (which are powerful, fast and extremely low-power processors for their area of use), you should look for the MSPGCC toolchain.
http://mspgcc.sourceforge.net/
It contains compiler (GCC3.22 based) along with all necessary tools (make, JTAG programmer etc.). Most MSP processors are supported with code optimisation and support of internal hardware such as the hardware multiplier.
All you need is an editor (yopu can use Eclipse, UltraEdit or even the normal Notepad) and some knowledge about writing a simple makefile.
And you should prepare to write tight code (especially in terms of ram usage).
I think that Netduino can be of some interest for you.
Visit their web site at http://netduino.com/.
It's opensource hardware (like Arduino, http://www.arduino.cc/).
It runs .NET Micro Framework (http://www.microsoft.com/en-us/netmf/default.aspx), the breed oriented to embedded development.
Regards,
Giacomo
I'm just starting to design some embedded devices, and am looking for resources.
What I want to be able to do is to connect a GPS receiver to a lightweight SBC or mini-ITX, x86-based computer, and track a remote-controlled vehicle's location/progress.
Ideally, this could morph into building some hobby, semi-autonomous vehicles.
But what I need to start with is a development board for GPS programming.
What boards/packages have you used, and where can I find [preferably open source] development for them?
OpenEmbedded is a good place to go to get started. A lot of embedded products use ARM and other processors, so cross-compiling is a big deal. Buildroot is another resource for building custom linux kernels for small systems.
You can also find lots of manufacturers with Single Board Computers (SBCs) that have tools to do what you want - do a google search for "SBC Linux" and you should have a gold mine.
LinuxDevices keeps a pulse on the linux embedded community and you should find several good articles there that lead you to products or software to help you.
Debian has an embedded build, but I haven't explored that.
There are several books on embedded linux available if you want to go that route.
The GPS receiver simply connects to a serial or USB port, and present an NMEA stream of data, which you can parse with GPSD and several programs can access it through GPSD. It's a very simple text based format.
I've used regular PC motherboards, and Atmel AT91 processors for embedded systems (with GPS, cellular, etc). There's a lot of information out there right now, and it's not expensive to get into. If I were to start a new project, I'd look at the AVR32 processors from Atmel - they are very hobbyist friendly, and provide a lot of community support for linux on the AVR32 architecture. They provide free GCC compilers and significant framework and examples if you want to go the OS-less route and have a single program running on the processer as well.
Good luck!
-Adam
"NMEA" is the keyword to be searching for when looking for this stuff. While I haven't done anything with this in a long, long time, here is a good source for some boards and other hardware:
http://www.sparkfun.com/commerce/categories.php?c=4
We have had good luck with Holux GPS recievers (designed for samsung q1). A farily simple connect over serial port and you can read the NMEA string.
What OS are you targeting? If it's Linux there are a lot of GPS libraries available (here's a good list). GPSd and GpsDrive are two of the more popular ones I've seen.
I haven't see any GPS devices specifically for lightweight/embedded use, but many of the consumer GPS devices have USB hookups available that could probably work (watch out for low end ones, they usually don't have the computer interface).
I suggest starting with a plain old c project that reads and parses NMEA from a serial port. You can do this in Windows or Linux.
I usually break down any project like this into a set of smaller projects like:
read and parse NMEA from serial
port
establish a serial /
network link from the remote device
to the tracking system server
integrate the components
Wikipedia has a good article on the NMEA protocol. As Adam points out it's actually pretty simple.
Circuit Cellar magazine often has projects like this as well.
Depending on what you want to do, there are various sizes of target to consider. Use Atmel AVR for small low power (battery) stuff. Perhapse use Linux on an old laptop if I just wanted to rough out the concept and needed WiFi (or cellular) for internet.
The laptop Linux prototype then could be trimmed down and ported to an embedded Cinux system for even lower battery usage and portability later on. (not as low as Atmel though).
If you are comfortable with programming in Linux I would recommend the Gumstix range of small computers - http://www.gumstix.com/
You could pair the vedex motherboard with the GPSstix expansion board tp make a tiny GPS receiver with a well supported programming environment.
I suggest GPSBabel to communicate with your GPS receiver.
GPSBabel
Handles waypoints, tracks, and routes,
Knows lots of format (this explains the name Babel),
Runs on Windows, Linux, OSX,
Free.
Some people here have suggested devices like the gumstix - embedded devices which cost $149 without GPS. I don't understand that bit. A off-the-shelf TomTom comes with running Linux on ARM, built-in GPS, lots of flash, battery and screen. It's hard to beat the price advantage that comes with mass production. For your hobby project, the map included is not needed, but who cares?