embedded_python.otl

Designing Embedded Linux Systems for Python Programmers
by Mark Kohler

Act 1: Set up the Story
	: The story so far
	Setting: Hardware is cheap.
	: The price difference between 8-bit and 32-bit processors is small and
	: dwindling. (Raspberry Pi slide)
	:
	: That means there are more and more places we can use Python.
	:
	: There are a wide variety of embedded systems, with great differences
	: between them. To try and cover this range, I'm going to use 3 examples.
	: 3 embedded system examples Imagine:
	: 	kiosk, like an ATM
	: 	home router
	: 	thermostat
	:
	: 	Those are the three example embedded systems I will use throughout
	: 	this talk.
	Protagonist: My premise is that programmers develop faster with Linux and
	Python than a micro-controller operating systems and C.
	: better tools, better documentation (the source!), and a higher-level
	: language
	Imbalance: The problem is, Linux distributions are not designed for embedded systems.
	Balance: We want to develop in Python and create flexible software quickly.
	Solution: Use what you can from the distribution and use Python to build the rest.
Act 2: Develop the action - How and Why?
	Choose the right distribution.
		For a kiosk, choose Ubuntu.
			A kiosk is the almost most like a desktop.
			: CPU: amd64, i386, arm
			: Storage: 15GB
			: 	There's a screen, an x86 processor, and a pointing device.
			: Some differences:
			: 	only one application
			: 	no administrator - all configuration must be automatic
			: 	no user login
			Ubuntu is the quickest path to a working kiosk.
			: Ubuntu has great support for Linux desktops.
			: Chrome and Firefox have kiosk modes.
			: You can write your user interface software for a browser, or you
			: have a wide choice of desktop toolkits like Qt and GTK.
			Why not Fedora?
			: Ubuntu is based on Debian and the Debian project has packaged a
			: lot more software than Fedora. So it is more likely that the
			: software you want is already packaged.
			:
			: Further, Debian packages are more granular, so if you are tight on
			: space, it is much easier to slim down your storage requirements,
			: by just removing packages.
		Example 2: For a home router, choose Debian.
			Debian supports more processors than Ubuntu
			: CPUs amd64, armel, i386, ia64, mips, mipsel, powerpc, s390, sparc
			Debian requires less storage.
			: Storage: 1GB
			Debian supports cross-compilation with the Emdebian project.
			:
			Why not Ubuntu?
			: Ubuntu is always shipping core components (kernel, boot and
			: early userspace, filesystems, C libraries) that are on the
			: ragged edge, usually to support something shiny for desktop users.
			:
			: The best example of this is the effort that has gone into
			: supporting compositing window managers.
			:
			: All of the fancy desktop features from Ubuntu aren't going to
			: help, might get in the way, and reduce stability.
		For a thermostat, start with BusyBox and Linux from Scratch.
			: For this class of device, your design must be very low cost,
			: very low resources.  You might need to use a less common
			: processor and you definitely have much less storage.
			:
			: In this environment, you have fewer resources, and you are
			: likely to do a lot more customization of system code.
			:
			: BusyBox and Linux from Scratch are a great way to start.
		
			What is BusyBox?
			: BusyBox is a very small user-space implementation for Linux
			:
			: People often use it with a scaled-down C library for very small
			: systems.
			:
			What is Linux from Scratch?
			: Linux from Scratch and its companion Cross Linux from Scratch
			: are book-based distributions that explain issues like:
			: 	creating and use a cross-compilation gcc toolchain
			: 	building custom kernels
			:	using unusual boot loaders
			:	customizing the boot process
	Eliminate desktop assumptions
		: After you have chosen your distribution...
	
		: For BusyBox, this has either been done for you, or you've created
		: everything yourself.
		:
		: For the otheris Find these assumptions, and code around them in Python.
		Handle upgrades automatically.
			Simplest approach: upgrades are distributed as filesystem images
			: Ideal for small systems that run out of RAM.
			: step 1 - running system downloads a script
			: step 2 - script downloads a filesytem image and writes it to
			: secondary storage
			: step 3 - reboot
			: step 4 - new image is loaded from secondary storage to RAM and
			: your upgrade is done.
			: details - migrate local settings forward, configuration partition
			Ping-Pong
			: for systems that run off of secondary storage
			: You have two partitions that each contain a complete system.
			: boot from 1 partition, upgrade the other, toggle the bootloader,
			: so that on the next boot, you boot the upgraded partition.
			:
			: This is called Ping-pong, because every time you upgrade, the
			: boot loader toggles which partition is booted.
			:
			: downsides
			: 	need enough space for two system images.
			: 	need to be able to download a complete system image
			Using Debian's package manager, apt
			: Most complicated approach because of inherent desktop assumptions of apt
			:
			: 	If an package doesn't know what to do, it can appeal to a
			: 	human for help.
			:
			: 	The human administrator is responsible for configuration,
			: 	and only with the administrator's approval can packages change
			: 	the configuration.
			:
			: Advantage:
			: 	Only download the packages that need upgrading.
			:
			: Disadvantages:
			: 	Packaging scripts may call out to the user interface to ask questions
			: 	Changing files in /etc is a problem.
			: 	Debian packages don't support downgrades
			: 	Will need careful testing.
			:
			: Good news
			: 	Automate using python-apt library.
			: 	Pre-answer questions that you know packaging scripts will ask.
			General Principle: Upgrading software should control the process.
			: Difficult to foresee which software you will need to upgrade.
			:
			: For that reason, make sure that the software you are upgrading
			: *to* controls the upgrade process.
		Add a review of where we are. (11 minutes in)
		
		Be wary of code related to dates and times.
			This is an area notorious for bugs but it is especially true when
			you adapting desktop code to an embedded system.
			: This year, Microsoft's cloud computing platform had an unusal
			: amount of downtime on...Feb 29.
			Avoid time zones, if possible. Wristwatches do.
			: There are a huge number of time zones, and they are
			: constantly changing.
			GPS time vs UTC time
			: GPS time does not use leap seconds - currently different by 15 seconds
			Linux: elapsed time vs. clock time
			: Linux does not direct support for elapsed time. Applications get the
			: system time and do their own calculations. The problem is, there
			: is a system called settimeofday. As a result:
			:
			: Applications expect to be able to do
			: 	t1 = gettimeofday()
			:   t2 = gettimeofday()
			:
			: T2 - T1 does not equal elapsed time
			:
			: Depending on how how the time is adjusted by, different
			: assumptions break.
			:
			Seconds are not constant
			: For adjustments under half a second, time is slewed and seconds are made longer
			: or shorter. See adjtimex(2)
			Time is not monotonically increasing.
			: For adjustment of more than a half a second, system time
			: immediately jumps forward or back. This affects timeouts and
			: cron jobs, even filesystem checks on the next boot.
			:
			: Time can be quite off depending on whether you have been taking
			: good care of the hwclock. On many Linux systems, the hw clock is
			: only set on shutdown. If you shutdown uncleanly, the clock
			: doesn't get set, and you will have a big time jump in your
			: future.
			Avoid time changes except at startup and shutdown.
		15 minutes in
		Don't manage NetworkManager.
			: Desktop systems use NetworkManager to control a set of network
			: interfaces, choosing the best one as connectivity changes over
			: time.
			:
			: This approach may work if your embedded system roams also roams
			: across networks, e.g. phones, ebook readers.
			:
			: However, many embedded systems (home routers, thermostats,
			: set-top boxes) act more like servers than clients, and it is not
			: appropriate to bring up and down
			: network interfaces every time their is a brief connectivity
			: outage.
			:
			: My recommendation is to only use NetworkManager if it is
			: really appropriate to your product. Otherwise, use the
			: interfaces that NetworkManager uses, directly.
		sudo is the new setuid
			: Right or wrong, if you are using Ubuntu or Debian, you have
			: inherited the Linux desktop security model.
			:
			: As a result, as your automating away administrative
			: configuration changes, you will need root privileges.
			:
			: sudo can be configured to automatically give root privileges to
			: a select list of commands, and this is often the easiest way to
			: handle the privilege escalation that is required when you are
			: automating changes in configuration.
	Write portable code.
		What is portable code? Isn't Python portable?
			: We talked about Linux. Now we can talk about Python.
			:
			: And I want to talk about a particular aspect of program design that
			: is especially important to embedded systems software.
			:
			: ISn't Python portable?
			:
			: I want everyone to write portable code in Python.
			: I've never seen endian macros in Python code.
			: I haven't seen near and far pointers.
			: I haven't seen 36-bit words.
			:
			: Yes, Python is portable across *processors*.
			: There is more than one type of portability.
		Types of portability
			: The kind of portability I'm talking about is using one source base
			: across a range of products, which is very common in embedded
			: systems.
			:
			: You need to support a common core of functionality, but with
			: somewhat varying features, and varying hardware platforms.
			:
			: Hardware: Different sensors, different network interfaces, etc.
			: On the feature side, marketing says there should be a a basic model, and a
			: luxury or professional model.
		if considered harmful
			: Python has support for this. It is called the if statement. You
			: just write your code and when you get to a difference between
			: the models you write:
			:
			: if model == PRODUCT_A:
			: 	do_this()
			: elif model == PRODUCT_B:
			: 	do_that()
			: elif PRODUCT_C do something else
			:
			: That works. So what's the problem? Why I am talking about this?
			:
			: The problem with this approach is that the number of code paths
			: increases with each product.
			:
			: The complexity increases.
			:
			: And when you're working on the software, regardless of which
			: product you are working on, you see the complexity of the sum
			: total of all the products.
			:
			: Another problem is that the differences between products are
			: hidden in the leaves of your code.
			:
			: Stop and talk about trunk vs. leaves.
			:
			: By that, I mean, the core or trunk is the main body of common
			: code. The leaves are code which don't call other code you've
			: written. They use libraries or system calls to control hardware.
			:
			: NEEDS TRANSITION
			:
			: If any of you have programmed in C, C has two different
			: kinds of if statements: the kind that evaluate at compile-time
			: and the kind that evaluate at run-time.
			:
			: See #ifdef Considered Harmful by Henry Spencer
			:
			: Is a program written this way modular? Let's come back to that.
		Separate common and model-specific code.
			: So we're using this "if" statement, and we're starting to
			: feel like we're losing.
			:
			: We'd really like to be able to work on the core code, without
			: seeing the complexity of all of the product varieties.
			:
			: TRANSITION
			:
			: I can use abstraction. Draw a circle around the leaves.
			: This is Better
			: But let's ask again, is this program modular?
			:
			: We have these leaves of code that contain 
			:
			: We contained the complexity, but we're not reducing it:
			: The common parts of the software depends on these leaves that
			: keep getting more and more complex.
			:
			: In 1972, David Parnas wrote a paper called "On the Criteria To
			: Be Used in Decomposing Systems into Modules". And he said:
			:
			: "We propose instead that one begins with a list of difficult
			: design decisions or design decisions which are likely to change.
			: Each module is then designed to hide such a decision from the
			: others."
			:
			: In our program, what are we hiding?
			:
			: We are hiding the model-specific code from the core code, and
			: that's good. But the model-specific code is all mixed together.
			:
			: We want to *hide* the differences, the parts of the program that
			: have changed before, and thus are likely to change again, from
			: the other parts of the software.
			:
			: Another problem. We have these interfaces between the core code
			: and the model-specific code. Are they stable? By that, I mean,
			: do they remain the same over time? Or do we need to
			: change them every time we add a new model?
			:
			: Question for the audience: Who likes frameworks? Who prefers libraries?
		Turn the call-graph inside out.
			Don't depend on details. Depend on commonalities.
			: Differences are often in setup and teardown. So let the
			: model-specific code call the common code.
			:
			: Ports should depend on common code
			:
			: Don't have lots of conditionals in the leaves of your code.
			: Keep the leaves simple.
			Explain why it is better:
			: Details of strange hardware are hidden.
			Better for testing.
			: Differences between hardware are easy to see.
Act 3: Frame the Resolution
	Crisis: Developing embedded systems with C is slow.
	Solution: Use Linux where you can, and use Python for the rest.
	Climax: Writer better embedded systems faster.
	Resolution: Questions?

	Use Linux where you can, and use Python for the rest.
	Write better embedded systems faster.
	Questions?



python modules, cmd, xml.sax
GUI event loops