Embedded Linux Day 2

Stuffs HW1 posted today – Shooting for 1-2 hours. – Review scheduling stuff & licensing. HW0 in lab Sign up for group meetings for next Thursday posted today.

Review I got a number of questions yesterday which led me to believe there are some fundamental misunderstandings. – I think I dove in too deep without looking around first. – So we’ll address that. About Linux, but also about the larger picture.

In this class, we are exploring a number of environments we could use on an embedded processor. One is “barebones” – In the context of this class, this means that you are just writing C or assembly and not using any library support (or at least no significant library support). – This is what we did in 373 – To do I/O, you need to read the processor specification and figure out which memory-mapped I/O locations you want to use and how to use them. – Advantages: Code can be really small (only have what you want) and efficient. You have complete control. – Disadvantages: Lots of work (reading, programming) Error prone

Environments… One is a set of libraries that you can call. – This is generally “just” a set of hardware interface functions that have been written for you. – Advantages: Don’t need to do as much reading. Hopefully the interface is the same across different boards/chips. – Makes porting so much easier. – Disadvantages Libraries might not support what you want to do. – Maybe no support for a 10-bit SPI device for example… Libraries might be ineffiecent as they are trying to do more than you want. Still need to handle scheduling yourself (which may be trivial, but might not be…)

Environments… One is an RTOS – Basically a bunch of libraries with a scheduler. Can be more than this (shell support, memory management, file system, all kinds of things) – FreeRTOS is an example of a fairly simple one of these. Supports memory management and even a FAT file system if you want it, but not hugely featureful support. – Advantages All the advantages of the libraries, but with a scheduler and other things. – Win! – Disadvantages More to learn about the software. – Can be hard to justify if you can’t amortize it over more than one project. Porting to new boards/chips tends to be harder, so often the port options are more limited. More “bloat” (code you don’t need) that could take up space. Might be doing things you don’t want (using timers, wanting control of interrupts, wanting control of memory layout, etc.)

RTOS (some more) Again, RTOSes can be huge or quite small; complex or very simple. – Linux can be an RTOS with work. WinCE is one too. All that’s needed is real-time support. But in here I’m talking about RTOSes similar to FreeRTOS – Small, modular, and fairly easy to understand. – Doesn’t try to (say) support every I/O device on the planet (which Windows and Linux does). Means less “bureaucratic overhead” than one might find in those OSes. – Smaller means less features, but what you can do is often faster and easier. “Make the common case fast”.

“user OS” that’s real-time (or not) Taking a full-fledged OS designed to deal with logged in users – Simultaneous Multi-user support, graphics, support for big applications (e.g. Word, Matlab), etc. Advantages – Familiar environment. – Support for applications. Want to do vision work, just use OpenCV. Want to do motion planning? Can do it in Matlab. – Abstracts nearly all hardware issues away. – Often highly portable. Given enough memory/CPU Disadvantages – Often huge bloat – May not be real-time; may not have control of scheduling as much as you’d like – While it effectively has massive library hardware support, if it doesn’t support what you want to do, it can be a pain to figure out how to do it yourself.

So… Much of the first half of this class is about exposing you to these different options. – 373 did barebones – Arduino is a library (with a bit more—the loop) – FreeRTOS lets you see a fairly basic (and good) RTOS – Lab 4, Linux device drivers, will let you see some of the difficulties of using a “user” OS in an embedded system. The win is pretty large (OpenCV for example) But there is a cost. Lab 4 (and this lecture) – Get you to see how to deal with one of the problems with such an OS How to write (and use…) a device driver in Linux. You’re on your own for Windows…

What we did last time I tried to get you some idea of what you might see on a minimal Linux install – File system, busybox, boot process, flash drive, etc. – If you are dealing with a very small version of Linux (often the case with embedded systems) you’ll be exposed to a lot of that.

Today Jump back to slides from last time – Cover device drivers in Linux at a high level…

Two devices crw-r--r-- 1 root root 60, :36 /dev/mem2 crw-rw-rw- 1 root root 60, :32 /dev/memory Created two devices, each with different minor numbers – But same driver – Recall that we print the minor number to the log on open. After a cat to /dev/memory and /dev/mem2 Nov 1 11:34:37 admin373-desktop kernel: [ ] Minor: 0 Nov 1 11:43:00 admin373-desktop kernel: [ ] Minor: 3 Modules: Some thinky stuff

Notes: One important note is that module stuff is written in kernel space. – That means you can’t do a lot of things you might want to! File I/O is a really bad idea – See next slide. Talking to memory-mapped I/O devices requires effort – Still have virtual memory Things like malloc don’t quite work – Thus kmalloc, kprint, etc. – Can be an unpleasant place to live… Modules: Some thinky stuff

A rant from on-line (Dick Johnson) The kernel is not a process. A file-descriptor needs a process-context for it to mean anything. Otherwise how would the kernel keep your STDIN_FILENO separate from somebody else's STDIN_FILENO? Coding a kernel module is not like coding a user-mode program. You should never write a module that requires reading or writing to any logical device. The kernel is the thing that translates physical I/O to logical I/O. Attempting to perform logical I/O in the kernel is effectively going backwards. If you need to get "outside world" information into your module, it's easy. Your module can have code for open(), read(), write(), ioctl(), and close(). A user-mode program can open() the device and perform any kind of device-specific ioctl() (or read or write or whatever) that it wants. This means that there is never, never, ever, never any real reason to attempt to perform logical (like file) I/O within the kernel at all. That said, it is possible to do file I/O in the kernel, but doing so is a severe violation of standard practice. It is also complicated and can lead to races and crashes if, for instance, a file is removed while your module has it open. You can readily code a kernel module so that it can be controlled from a user-mode script such as: – insmod my-thing.o my_device < parameters Until you understand this, you should not attempt to write a kernel module. If you need human input for your module, it works the same way. Modules: Some thinky stuff

Sources [1] – Very useful overview on drivers, a fair bit of text and many figures come from here. [2] Wikipedia – – [3] – Nice overview covering modules in general. A bit out of date?