"Those who begin building a cross development toolchain often find it a much more difficult undertaking than expected at first thought, even though the basic steps are widely available. In this publication, we discuss some of the idiosyncrasies that can make independent toolchain construction by an embedded project team challenging, some of the external resources available and how these might be evaluated with respect to your embedded project goals."

The publication may be downloaded from here. Also learn more about The Linux Foundation and the training courses.

Bernard Cole is behind this initiative. Check this full blog post for more information.

Chaitannya gave an excellent presentation starting with a video based on open source and then explaining in depth on what Embedded System, open source contribution and the ecosystem is all about.

He concluded the session cum drive by giving insight about Embedded Nirvana and it's activities.

The hacking session started with Chaitannya and me (using Fedora 16) trying to explore how to get things done and test out first program on F4. Both soon figured out that Stlink  has to be compiled on the host.

However things weren't that easy as thought it to be. An error (configure: error: *** Required libusb-1.0 >= 1.0.0 not installed ***  any idea ?? ) was haunting both till Shravan (hhmm, debian he was on!) came and resolved the issue on his host system. Then after a long fight and understanding all were able to flash the F4 and upload the program using Stlink (which uses USB A to Mini USB B , so no JTAG!) which was compiled on Shravan's host.

During the course all learned new things about F4 and also had fun trying to figure out how to get things up. Won't forget to mention the pain (yes the engineering term!) in figuring out hot to get the configure file for Stlink!.

Still the bug (configure: error: *** Required libusb-1.0 >= 1.0.0 not installed ***) hasn't been solved on Fedora 16 and smooth compilation of Stlink is the issue.

Updates about the sessions learning will come on Wiki of EN.

The vision is to come up with a portable Electromyography Device which would help collecting information and later collected data would be used for Analytics. It would be built using open technologies.

A dedicated wiki page for this idea is created here and Embedded Nirvana would encourage interested to contribute. Activities has started on this project already, we hope to continue the same.

This is the simple flow chart presenting the idea :

Very basic block diagram for same can be delineated as :

STM32F4DISCOVERY is the board which Embedded Nirvana is looking forward to, get the basic things up. Toolchain for same has been configured.

Running an open community requires contribution and if one is willing to do so ( Why Should I Contribute To Open Source? ) then take the first step and we contributors at Embedded Nirvana would be glad to exchange and enhance the prowess.

This website has lot of things to get started and if one is looking for more information then do visit :

1) Embedded Nirvana Wiki : Do check Ideas

2) Embedded Nirvana's GitHub Repository

and on social network too :

3) Follow Us On Twitter

4) Like Us On Facebook

If you are totally new to Embedded world then reading wiki pages here would help you get started.

More updates and blog post to follow.

• Do what you like to do.

Everybody wants to work on “cool” technology and products. In reality most of you might be working on some maintenance project.

So what it is that stops you from doing cool things. You can join any opensource project and start committing code to the project. It gives you wonderful opportunity to do something worthwhile on technology of your choice  and interact with the innovators and very insightful people.

• Do the real stuff.

Richard Stallman has brilliantly summarised the GNU project in one single sentence, "Free as in thought" . His brilliance not only lies in writing the gcc compiler and allied utilities, but also in his ability to get a whole community mobilised on this project. His work is even more admirable since he did it when there was no Google and Internet was affordable only to defense research or the universities.

Lot of us write code or test, but the life cycle ends there. In most of the cases there is no interaction with the client. Opensource projects are real deal. When you get involved in some form or the other, there would feedback coming from the community and the users, which decides the course of action.

If you write code in opensource domain, there is a big community which would define the course of action and effectively making a complete product out of your idea.  This process is shapes you as a good engineer.

• Learn from the best:

In high school we were taught human anatomy through a series of experiments on dissecting rats. Same goes for software. If you want to be a great software engineer (not just a programmer), dissecting the code would always be a great learning experience. What better way is there than to start dissecting the opensource code. Some of the opensource projects are the top ranked in their respective domains, like Linux, Apache server, Eclipse, GCC, etc. All this code is available to you for free, you can try it out, make changes, post bugs, get community support. Overall a great learning experience.

Ok ! So why should I be doing this everything for free ?

There are tons of resume which tells the employer about your contact information,  academia, programming expertise, projects you’ve worked on and other such stuff. Well the employer cannot verify any of this unless there is face to face meeting. If you have already done some work in opensource project, it speaks volumes about your skills and eventually reflects in your pay package.

Same logic applies for business or freelancers.

How to contribute to opensource then ?

Contribution to opensource need not mean that you should sit a dark room like Neo and churn out code endlessly.  You can contribute in following ways.

1. You can try out the code the on your machine and point out what problems you faced on the mailing list. There might be some genuine problem in the code, or you might have missed some configuration setting or followed wrong process. In either cases you would be refining the code. Either the authors/ contributors would fix a bug, or a wiki would be posted in detail how to do the stuff correctly.
2. You can add comments to the code. Let say you are scanning the hello world code and you didn't understand what -mabi=aapcs  meant. If you dig in and find out what it actually meant you can add your comments there. They would be helpful for the people who might want to build a layer on top of the code.
3. You can post a wiki on a particular code.
4. You can do some basic editing as a part of good programming practices  like.
   if(this == that)
   {
   if(this == that)
   {
   if(this == that)
   {can be made more readable likeif(this != that) return
   if(this != that) return
   if(this != that) return
5. Fix some bugs, if you come across some interesting challenge.
6. Make the existing code more modular, fast, effective, handsome and what not

Our main repository is located at https://github.com/embeddednirvana/
You don't have to be a registered member of Embedded Nirvana to play around with the code. If you have a gmail id, you can login using your openid account. Alternatively you can register with github.

You can refer to http://help.github.com/ for guidelines on how to use it.
If you have any issues regarding downloading or uploading your code, you can always put that on the mailing list.

A very basic question. Why is the kernel programmed in C language and why not some more high level language like C++ . Also why do we code in C for embedded systems.

Well as a matter of fact there has been an attempt to code the kernel in C++ by Linus Travolds himself and here's what he has to say about it.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

 - the whole C++ exception handling thing is fundamentally broken. It's
   _especially_ broken for kernels.
 - any compiler or language that likes to hide things like memory
   allocations behind your back just isn't a good choice for a kernel.
 - you can write object-oriented code (useful for filesystems etc) in C,
   _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is
either
 (a) looking for problems
 (b) a C++ bigot that can't see what he is writing is really just C anyway
 (c) was given an assignment in CS class to do so.

So in a nutshell unless you have been asked by a nutcase professor to do stuff in C++ only as an assignment, don't use C++ for developing low level applications for Embedded systems.

Embedded Studio (ES) v0.1 has been released recently. We has a semi-official release within the group during the GNUnify 2011 Days.  ES v0.1 is a Fedora 13 flavour Virtual Machine which is preconfigured with all the essentials required to start development in the field of Embedded Linux. We came up with this idea recently so that a developer has to focus more on development rather than put efforts in configuring the Development host machine. The initial version is a Virtual Machine and we hope to create a distribution out of it soon too.

No need of any installation, since it's a vmware Image all the stuff is pre-installed.

Features

• Pre-configured GNU toolchain for ARM architecture
• Qemu installed for simulation of selected ARM architectures. You can simulate GUI applications as well.
• Ready binaries and source code for versatilepb board for emulation of the device.
• Script for compilation and porting of u-boot, Linux kernel and Busybox.

The VMware virtual machine is available on demand in a Dual Layer DVD medium at a price of Rs 300/- Just write a mail to admin@embeddednirvana.org to order your copy.

The presentation contain the guidelines, while the wiki pages associated with it has specific instructions. Some of the code presented in these presentations would be updated on the git. The course content has been packaged in a Fedora VMware image, so that you can get started without any installation hiccups. You can get the DVD here.

Also the videos would be updated soon.

Introduction to Toolchain

Building Systems on Bare Metal - An ARM Perspective

Basics of Linux Kernel Development

Compiling Linux Kernel for Embedded Device

Debugging techniques.

Hardware Emulation Using QEMU

Using Eclipse IDE

You can find a brief description on this on wiki page.

You can  read the wiki page here

You can refer to the wiki article here.

You can download the code  github

Read the wiki page on how to configure Eclipse IDE here

The wiki page here would guide you how to compile gdb and gdbserver for your target device.

This presentations gives an introduction to toolchains and how we can use them for development of embedded systems.

You can find more info on the wiki article here

• Planning for the 26th March session.
• Allocating slots for the speakers.
• Formatting the course content.
• Formatting the guidelines for the session.

• This is a non-commercial activity run completely be volunteers from industry and students

• We meet weekly and churn out some code and release it. Have a look at our vmware Fedora image. We have put all our work there so that you can just jumpstart with your ideas, without any hassles of configuration on the entire development environment.

• Once in a blue moon we have a demo session or a day long educational session , where we demonstrate what we have done so far.

• We take care of arranging the talks, getting speakers, contribute the code & documentation

• Topics are likely to be around current trends in industry like:

"Android or MeeGo Development", "Panda/Beagle/Hawk Board", DSP programming etc, communication protocols , etc.

Agenda for the Embedded Nirvana

Just to summarize the purpose in one sentence it would be "Building industrially viable and resourceful opensource technology"
The word building is very significant here since we necessarily may not create or innovate, but do something which has industrial significance. The goals in descending order of importance would be.

• Primary aim would be to contribute to opensource.

• Deliver value to industry with the opensource contribution, i.e. the outcome of the activity should have a value and must be purpose driven.

• A practical lab where we do designing, coding, documentation, releases, etc and not just talk about OpenSource.

• Common place where ARM-Linux enthusiasts can meet and share hands on knowledge.

• Community based knowledge generation and sharing.

• Lastly explore newer realms of our creativity as engineers.

What's in for me?

• Even if you are James Gosling, there is something you won't know about Java (Said by James Gosling himself). A community based learning would significantly boost knowledge in a very short period of time.

• We are talking about a hands-on-lab and not a blabber-blabber forum, so end of the day what you take home is hands on experience on a technology . This can be helpful in your professional field.

• Sensible contribution to Open Source brings reputation in your tech domain.

Licensing:

• All the code generated would be made Open Source and put on the website under Apache 2.0 License.

• All the articles generated would be shared under Creative Commons CC-BY-SA Licence.

Creating debug environment for the vmware image using gdb, kgdb and qemu.

Last few session we have worked on simulating ARM device on Fedora, by compiling all the tools from scratch so that one single script can be used for all Linux platforms.

Now we plan to create a complete debug environment for the target device. Work on gdb is already complete, we need update gdb on vmware image.

Planning for Gnunify:

As you all might know that GNUnify is scheduled on 11th and 12th of feb and we are aiming to spread the word about our community. There are quite a few things that we have to do before we spread the word.

1. Formulating presentation strategy for GNUnify.
2. Finalizing the DvD that we are planning to distribute at GNUnify.

Venue : COEP embedded systems lab.

Time : 10.30 am - 12.30 pm