There has been two key updates to our flagship training program “Linux Driver & Embedded Developer”, one: the course has been fully updated to the latest 3.15 kernel and the second, most important aspect is that we have added new topics to this program, making it (more…)
Posts Tagged ‘Embedded Linux’
There is a constant increase in the number of participants from the microcontroller programming background enrolling for our Linux Driver and Embedded Developer program. The reason is quite obvious; the growing demand for OS based embedded programmers. However during our discussions with these participants and also during training them we understood some patterns and issues which are really interesting (more…)
Announcing our latest course schedules for you to choose based on your learning convenience. We are also for the first time introducing Instructor led virtual training on Embedded Linux for the convenience of outstation participants.
Schedules for June and July
|Embedded Linux||June 7 & 8- (9:30am to 5:30pm)||2 full days||Weekend Workshop- Classroom (Hyderabad)|
|Embedded Linux (New)||June 16th (7am to 9am)||2 weeks||Instructor led virtual training (Now learn from your home)|
|Linux System and Driver Developer(@ Bangalore)||June 27,28,29 – July 4,5,6 (9:30am to 5:30pm)||Spread over 2 weekends||Classroom @ Bangalore|
|Linux Driver and Embedded Developer||July 14th (7:20 pm to 8:45pm)||3 months||Classroom @ Hyderabad|
For registrations or for any further details regarding the courses please feel free to mail to firstname.lastname@example.org or call 040-66100265
Why this free prerequisite training
- Trains the participants to get a grip on the prerequisites skills needed for enrolling for the Linux Driver and Embedded Developer course
- This is a practical oriented program which gives participants hands-on grip on the Linux platform
- Highly recommended by Raghu Bharadwaj, lead trainer, before enrolling for the Linux Drivers and Embedded Developer course.
“I have seen that some participants who directly enroll for the Linux Driver and Embedded Developer course face issues in understanding the program. The reason is lack of good prerequisite skills and nothing else”
—Raghu Bharadwaj (lead trainer)
We have kept this program free of any cost, as we only intend that participants who are interested to enroll for our embedded systems course, “Linux Driver and Embedded Developer” would undergo this training.
Topics Covered in the free program
Due to continuous requests from working professionals and outstation candidates for conducting our flagship training program “Linux Driver and Embedded Developer” on weekends we are happy to announce the start of this weekend training program from April 26th onwards.
Weekend Program Schedule
This course will be delivered over 6 weekends, the dates are: April 26, 27-Entire weekends of May & June 1 (12 days in total). Training will be held at our premises at Hyderabad from 9:30am to 5:30pm on these days (includes lunch and refreshments).
Linux is one of the few, ever expanding endeavors developed in the 20th century. Obvious or not, it has continuously cranked itself up to reach new horizons since its humble beginnings in 1991. A more than 50 year old market segment, the embedded systems, which encompasses a vast domain of electronic products ranging from little wristwatch cameras, to huge distributed systems like telecom switches, has been charmed by the frills and thrills of Linux and has deeply benefitted from the same.
Of late, especially in the last two weeks I have interacted with a lot of fresh engineers during the career counseling sessions and surprisingly most of them raised a common question or rather had a common concern, ‘Freshers are not eligible for any embedded system jobs’.
A considerable segment of embedded systems are often found in mass-market products and are therefore subjected to hard economic constraints. The basic nature of these systems mandates further constraints on physical size and power consumption. These in turn give rise to resource constraints on the computing platform level, e.g., constraints on computing speed, memory size, and communication bandwidth etc. In spite of the rapid development of computer hardware these constraints are true due to the economic overheads. In most cases it is not economically justified to use a processor with more capacity due to the overall product’s cost limits.
Now coming to the software that goes into these space crunched hardware?
A recent survey conducted on small embedded device manufacturers revealed the following facts.
Most of these vendors avoided using embedded operating systems and the response was a straightforward, “we don’t need one.” More than half of these vendors mentioned a simple lack of need as the sole reason for skipping the operating-system. It’s easy to think of many products that might not need an OS so this response isn’t surprising. Out of those about 30% said an OS will strain their system’s processor and/or memory. Some said an OS was too expensive and the remaining felt that operating systems are too complicated. However the need for an embedded OS was felt considering the fast changing demands of the consumers, who are looking for multi-purpose small embedded devices, which mandates the use of an OS
Now the question, what is the most economical and easy OS solution?
This brings up Linux as a viable option. Let’s explore the reasons behind this choice and most importantly understand how it can be used on these space constrained devices?
•Linux is open source kernel backed by a strong community of developers; members of the community provide bug fixes, enhancements, and even support old devices long after the manufacture has ceased support.
•Linux offers a large library of functionality that can be leveraged to accelerate development. Linux is easy to customize and port even on to MMU less processors. With Linux community’s commitment to support embedded systems and various embedded hardware vendors contributing development tools and support.Linux is the best bet to migrate from hardware specific code to richer software.
Linux kernel is massive collection of sources targeting various architectures and platforms. Linux kernel currently contains around 9.2 million lines of code with a 10% increase every year. With the current version, pattern new stable kernel is available every 3 to 4 months. Linux Currently supports 25 different architectures, 60 Filesystems, 20 net protocols(L2), 50+ ATA Drivers, 300+ pci Drivers, 200+ Ethernet Drivers
“Linux supports more individual types of devices overall than any other kernel” -Greg KH
Default vanilla kernel configuration includes full network support, support for wide variety of input devices, and does not offer fixed boot time (can afford the time delays related to device discovery).
So with all these code buried within Linux, how can we fit it into these small devices?
since Linux kernel sources are available, it allows embedded engineers to customize kernel build by integrating various optimizations that help us keep check on kernel foot-print and reduce boot up-time.
Following is a list of few tweaks , that we could consider.
- Disabling unrequired Device drivers and file systems like Ext2, Ext3 (not required on mass storage less embedded devices)
- Disabling unrequired network protocols and other network services like Net filters, packet forwarding etc…
- Disable SMP Support when not running on dual CPU boards. This reduces the kernel image size and also results in better performance on uniprocessor machines
- Disabling support for other CPU variants for the architecture we have selected would help us reduce kernel image size by stripping out unrequired start up code.
- Disable support for Dynamic configuration of kernel parameters through sysctl’s.
- Reduce the kernel log buffer to 4k (default 16k).
- Support for hotplug events / user space notifications are often not required in Embedded systems kernel so choosing to disable them would help reduce kernel image size
- Enable CONFIG_EMBEDDED which enables a group option to further trim down the kernel. Notable options enabled are the ability to select a different allocator and a selection to optimize for size (CONFIG_CC_OPTIMIZE_FOR_SIZE).
- Enable SLOB Allocator
Current kernels are by default set to SLAB allocator which is more efficient on the large memory desktop machines. So enable SLOB allocator which perfectly suits smaller, resource limited devices.
- Disable Module Support
Modules under Linux allow kernel code to be dynamically installed or removed. However, to accomplish this, each module is loaded onto a fresh page. This has two consequences. On architectures that support large memory pages, modules do not share the large page typically used by the primary kernel code. Consequences of this is another page table entry is needed and page table caches may get thrashed more which may be a potential performance impact. A second consequence is if a module is the page size plus one byte, the total memory consumed is 2 entire pages. This is almost 50% waste. Or in another case if the module is small, a full page has to be allocated. If the page size is 4K and the module is only 1K, this is a 300% waste. If many such modules are loaded, there can be considerable waste of memory.
- Consider UClinux when there are no stringent MMU requirements
- Other issues apart from normal selections include appropriate tagging of disposable code. Custom drivers or even existing drivers should have the initialization code tagged appropriately so memory occupied by them can be freed. This can be done by the use of the GCC __init attribute.
- Developers also need to be aware of performance constraints with XIP(Execute in place) NOR flashes on some custom hardware. XIP allows the kernel to run form the same place that it is stored. This requires the flash to appear as linear memory. On custom hardware (such as certain ARM based systems) the bus for interfacing to NOR flash may be smaller than the native size of the processors for ex: 16bit NOR memory interface requiring two access cycles to load a native size piece of data, 32bits wide. This would result in massive performance bottleneck. In addition, XIP prevents the use of compressed kernel images.
The deeper you go the more clearer it becomes. This is true with system level programming including programming for embedded systems. If you are used to working on proprietary software you should have a hard time in getting the pulse of hard-core programming. It’s not that you cannot but you will always find it difficult to sail through. An embedded operating system can be defined as, a bare software without cosmetics (used to spruce up end- user experience). So most times you are dealing with core programing and its implications and this is where your understanding of an OS like Linux, which is open in nature, will help you rip through the core programming issues at a much faster pace.
Linux with its unmatched flexibility and huge support base is the ideal platform for you to go deeper and understand the finer aspects of programming for the embedded world. In all these years as a trainer I have met several experienced programmers who struggle to make it when dealing with core programming. I have and still recommend developers to start with; understanding the basic architecture of an OS, its interactions with the hardware and so on. This is where the real crux is, once you get hold of these concepts it not only delivers great clarity on the internal working of an OS but also empowers you with great portability skill from one OS to another.
So if you desire to make it big as an embedded developer then get started with Linux kernel.