Needing an RPM based distro, I fired up Fedora on a VM. I was never a fan of Fedora and 15 felt right at home – half baked cutting edge features shoved into your face, leaving you struggling to find the equivalent of even the basic interaction. Still, I needed to connect to windows shares on a FreeNAS and google was of little to no help. Here’s what worked for me.

First install samba and samba-client

sudo yum install -y samba
sudo yum install -y samba-client

Then install the “places” gnome menu. It will appear as an icon on the right rather than a drop-down menu on the left.

sudo yum install -y gnome-shell-extensions-places-menu

Now you need to play around with your security policies. I run with SELinux disabled so I’m not sure what it would take to get a specific samba-friendly policy – you’ll have to google that. In addition, you’ll need to turn off your firewall or enable samba through it (I run without it). Now logout or reboot.

You can now use the familiar Places -> connect to dialogue to connect to the share.

This is probably not what you think it is. It is not an application that controls ICD2, PicKit2 or any form of custom LPT PIC programmer for a PC (you can use MPLAB X for that). What lpicp does is provide a user space application and kernel driver to perform the functionality of a PIC programmer on embedded systems running Linux. After deploying these modules onto such a system (and assuming the hardware is layed out properly), you can run something like:

lpicp -x write -d /dev/icsp0 -f my-pic-program.hex

and have your embedded system program a Microchip PIC microcontroller via an ICSP bus.

Implementing the ICSP protocol and bus

• Read
• Write
• Execute instruction

To implement a high level operation like reading a device requires a mixture of commands, spanning across all the three groups; simplisticly you’d have to execute instructions to prepare the PIC, write the address pointer and read data. You really must read the flash programming spec to understand the specifics, but the jist is the same for all high level operations (erase/read/write).

To do this, I offloaded all bus transactions to a platform driver (mc_icsp) using callbacks to the platform (which toggles the GPIOs). All timing is configured when registering the platform driver and user space interacts with it via /dev using 4 ioctls:

• transmit: send 4 bit command and write 16 bits of data
• receive: send 4 bit command and read 16 bits of data
• send command only: send only the 4 bit command with a configurable waveform
• send data only: send only 16 bits of data

Userland

The application is built using cmake, which outputs liblpicp.a and an lpicp executable. The executable adds a command line layer, but you can just as well link to liblpicp.a to integrate PIC programming into your application. The lpicp executable can be run with the following arguments:

-x, –exec: r, read | w, write | e, erase | devid
-d, –dev: ICSP device name (e.g. /dev/icsp0)
-f, –file: Path to Intel HEX file
-o, –offset: Read from offset, Write to offset
-s, –size: Size for operation, in bytes
-v, –verbose: Verbose operation

The application uses libGIS‘s ihex.c module to parse the Intel HEX record file outputted by PIC compilers. The files contain data records to be written to program, configuration and eeprom memory. The application knows where to burn each record according to its address.

Getting the source

You can get the lpicp code @ the lpicp github repo and the driver can be found here.

This post hosts a few blurbs about issues I ran into when developing for Embedded Linux and did not find decent documentation on google. It will update as I plow through more stuff.

Getting the telnet server (telnetd) to accept connections when using DENX SELF

The solution is to run menuconfig (or xconfig) and include the Legacy PTY device support in the kernel (under Device Drivers -> Character Devices). After you’ve deployed your kernel, telnet should be able to connect. Make sure to create a user with a shell for telnet, otherwise you won’t be able to log in.

Setting up the FTP server for upload support when using DENX SELF

• Change the “no” just right of chmod, delete, overwrite to “yes”
• Add “upload / * yes” with no quotation marks just below this list

Some images segfault before main

I thought perhaps the kernel was not configured properly for ELF files but it was. I then rebuilt binutils (so that I will have the latest and greatest) and ran readelf on my Ubuntu station on both dropbear and dropbearkey – it showed everything was great. However, I then cross-compiled readelf and tried running it on the target’s dropbear and dropbearkey – it showed the dropbear ELF was corrupt (bad section header offsets).

After more investigation i saw an offset of 1 byte when reading the section headers – but only on the target. Looking manually at the hex dump for the dropbear image on my PC showed it was perfect. I then looked at the sizes of the images – dropbear on the target was 3 bytes smaller than dropbear on my PC, even though they’re the same file…

To make a long story short – it turns out that FileZilla (my FTP client) did some CR/LF manipulation when sending the file to the target. Setting the transfer mode from “Auto” to “Binary” did the trick. D’oh!

Using Eclipse to debug the kernel with Abatron BDI3000

To actually perform debugging, I attach the GDB only after Linux has initialized the MMU (I chose to break at __start_here). To do this, I telnet to the BDI and perform:

reset
bi {__start_here offset, taken from the System.map file, e.g. bi 0xc00021e0}
go

The target should stop at __start_here. At this point I can set breakpoints to debug the kernel boot process and start debugging in Eclipse. To debug again, terminate the GDB process by clicking the red button or Ctrl+F2 and re-enter the BDI commands above. There is no need to do the clear/set breakpoint dance with Eclipse – it will remember your breakpoint settings and reapply them every time you connect. The BDI does not do this, however, so you need to always re-perform bi.

Debugging U-Boot (after relocation) in Eclipse

• You need to obtain the address to which U-Boot relocates to in RAM. This can either be done the DENX way or by adding a printf to board_init_f, printing out the last argument, addr, to relocate_code
• You’ll also need the address of board_init_r, which is called immediately after relocation to RAM. Just find it in u-boot.map and add its value to the relocation address you obtained in the first step. This will give you the absolute RAM address at which board_init_r resides after relocation
• In the Main tab, instead of vmlinux you’ll need to point to the u-boot file in your U-Boot root directory
• In the Commands tab, set ‘Initialize’ to:
  • target remote {bdi-ip}:2001
  • symbol-file
  • add-symbol-file {u-boot-dir}/u-boot {u-boot-ram-relocation-address}
• In the BDI telnet session, follow the same thing as Linux debugging only break on board_init_r’s absolute RAM address

The rest should behave just like Linux debugging – reset in BDI, set the breakpoint, go; target will stop, attach via Eclipse.

Applying a patch from GMail

To create a working patch, I simply click on the little blue drop down icon on the upper-right corner of the message holding the patch and select “Show original”. You can safely copy/paste this into a text file and apply.

About three years ago I developed a real-time operating system aimed at the new generation of 32 bit microcontrollers. Seeing how I am a devotee of developing/testing embedded software on a PC and only then porting/testing to the target, one of my goals was to get a working simulation environment under Windows. I had thought at the time that I would have a lot of reference, seeing how most real-time operating systems (FreeRTOS, for example) have Windows ports. To my surprise no port implemented true preemption, instead opting for simply wrapping the Windows API with the equivalent RTOS API (for example, creating an RTOS thread would call Windows’ CreateThread).

Functionally this allows users to develop under Windows, calling the RTOS API as they would on the target and testing their application under Windows. However, there are two drawbacks to this:

1. The result of such a simulation, while usually sufficient, is quite synthetic. A lot of behavior is due to change when porting back to the target because Windows cannot be (easily) made to behave like an RTOS – especially in the aspect of predictable scheduling
2. As an RTOS developer you can’t write and test kernel code under Windows and as an application developer you cannot familiarize yourself with the underlying kernel state at a given time, seeing how no such state exists

It is therefore beneficial to have as much of the RTOS kernel as possible running under Windows and for the most part this is quite straightforward. Most context switches occur when the application calls an OS API – like sleep() or giving a semaphore. Let’s assume we have a single Windows thread and we implement the following piece of code:

// the first thread entry
first_thread()
{
    unsigned int counter = 0;
 
    // forever
    while (TRUE)
    {
        // increment counter
        counter++;
 
        // sleep for a period of 0 (yield the scheduler)
        rtos_sleep(0);
    }
}
 
// the second thread entry
second_thread()
{
    unsigned int counter = 0xFFFFFFFF;
 
    // forever
    while (TRUE)
    {
        // decrement counter
        counter--;
 
        // same as first_thread
        rtos_sleep(0);
    }
}

In this simple scenario, we create two RTOS threads and expect them to work concurrently. Seeing how we only have one Windows thread, we need to be able to switch between the two contexts (each thread has a stack and different register states). In this case, actual context switch will occur on the call to rtos_sleep(). If we were to follow the trace of execution (remember – we have only one Windows thread) we will see that it starts by entering first_thread, having the stack pointer pointing to the first thread’s stack. It will then increment the counter on first_thread’s stack and enter rtos_sleep. This kernel function will revoke the first_thread’s right to continue and then load the second_thread’s context (its stack and registers). The Windows thread will then continue to execute and, seeing how it loaded second_thread’s instruction pointer register, start running second_thread.

Such behavior can allow for simulating a LOT of functionality – thread priority, thread state, waitable objects like semaphores, and the like – but all of the context switches can only be made when the user calls an RTOS API. Effectively, we have simulated a cooperative kernel, in which the user must call the kernel every so often to enable other threads to run. There are so many examples of implementing a cooperative context switching mechanism in Windows out there that I am not going to go into the details of how we actually do the magic behind this example (creating the thread, swapping contexts and the like). I’m sure Google can provide many excellent sources.

From cooperative to preemptive

We start by spawning a second Windows thread – this thread will serve as the interrupt thread. Overall, we will only need two Windows threads: the interrupt thread (running in high Windows priority) and the kernel thread (running in normal Windows priority), which will run the RTOS threads, however many they may be. Whenever we’d like interrupted rescheduling to be performed we post a message into the interrupt thread’s Windows message queue. This will be either periodically (using an auto-renewing timer) or deferred (using a one-shot timer).

The magic occurs once the interrupt thread receives the request to interrupt. At this point in time, the interrupt thread will simply hi-jack the kernel thread – changing its current point of execution to a block of code that performs saving the current context and loading the next one. This is done by using GetThreadContext and SetThreadContext.

// hijack the windows thread running our kernel - once
// it becomes ready it will jump to wcs_isr_reschedule
void wcs_intsim_do_interrupt()
{
	// initialize context flags 
	CONTEXT ctx;
		memset(&ctx, 0, sizeof(ctx));
		ctx.ContextFlags = CONTEXT_FULL;
 
	// suspend the kernel thread
	SuspendThread(wcs_intsim_thread_to_interrupt_handle);
 
	// get its windows thread context
	GetThreadContext(wcs_intsim_thread_to_interrupt_handle, &ctx);
 
	// push the address we want to return to (which is wherever the RTOS thread is now)
	// after our simulated ISR to the RTOS thread's stack
	ctx.Esp -= sizeof(unsigned int *);
	*(unsigned int *)ctx.Esp = ctx.Eip;
 
	// set the instruction pointer of the kernel thread to that of the ISR routine
	ctx.Eip = (DWORD)wcs_tick_isr;
 
	// set context of the kernel thread, effectively overriding the instruction ptr
	SetThreadContext(wcs_intsim_thread_to_interrupt_handle, &ctx);
 
	// resume the kernel thread
	ResumeThread(wcs_intsim_thread_to_interrupt_handle);
}

We push the current kernel thread’s instruction pointer register to the top of its stack (so that the current RTOS thread can resume execution once its ready again) and then override it with a pointer to our (naked) routine performing the save and switch context. Once the interrupt thread goes back to pending on its message queue, the kernel thread will resume and effectively handle the interrupt (again, by saving current context and loading the next RTOS thread).

And now some code

Download example (winContextSwitch.cpp, ~360 lines of commented code)

Here’s a small code snippet that may be useful to the 20 or so VxWorks programmers left on the planet. I thought this would be much easier than it turned out to be, but after gathering code examples from here and there in the VxWorks source tree, I was able to query the routing table as to which interface is used for a certain egress IP address.

VxWorks 5.x doesn’t really have a “user” and “kernel” space, so you’re kind of inclined to directly access the routing table (like how routeShow does it) should you need routing information. Looking at the code for rtalloc, rtalloc1 and ipRouteGet shows that this is a recipe for pain. Since a lot of BSD code found its way into the VxWorks networking stack, you can use standard route sockets to get routing information from your application, without worrying about tripping over locks and such.

In the attached example, I have a routine to get the egress interface by destination IP address. I only look at the interface information in the response, but this should serve as a good example as to how to get more information from the routing table.

You can download the code here.

I was recently requested to get SNMPv3 up and running on a PPC board running Linux. It needed to support hardcoded views, creation/deletion of V3 USM users in runtime and allow for three security profiles: none, MD5 authentication and MD5 authentication with DES encryption. The obvious choice is to base this on Net-SNMP, but I first tried to use the version precompiled and included in the ELDK. By simply loading the appropriate binaries on to the target, I quickly got an SNMP agent functioning. There were two issues:

1. The version was compiled in a certain way that took up a lot of flash space (openssl was required as an external shared library)
2. The version was pretty old – based on the 5.4.x branch

For fun, I downloaded the ELDK source RPMs, unpackaged, tailored the RPM spec, rebuilt and installed it on to my ELDK library. Sure enough, I got a much smaller agent but decided I want to use the latest and greatest Net-SNMP, 5.6.1 at the time of writing. The build process below assumes you have ELDK 4.2 installed on Ubuntu. You can check out a recent post of mine for detailed installation instructions.

Start by downloading the latest source packages from the Net-SNMP site. Extract it to a directory and open it in a terminal. We then start by setting CROSS_COMPILE, required for running ppc-linux-gcc (in my case, ppc_8xx).

CROSS_COMPILE=ppc_8xx
export CROSS_COMPILE

Now we can simply go ahead and configure Net-SNMP for our needs:

./configure --host=ppc-linux --build=i386-pc-linux-gnu --target=ppc-denx-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include/net-snmp --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-endianness=big --enable-privacy --enable-des --enable-internal-md5 --disable-snmpv1 --without-rpm --with-openssl=internal --enable-mini-agent --with-out-transports="TCP Callback Unix Alias" --with-default-snmp-version="3" --enable-shared --with-cflags="-O2 -fsigned-char" --with-ldflags= --with-sys-location=Unknown --with-logfile=/var/log/snmpd.log --with-persistent-directory=/var/net-snmp --with-out-mib-modules=examples/ucdDemoPublic --sysconfdir=/etc --with-libwrap --with-pic --disable-embedded-perl --with-perl-modules=no --with-sys-contact=root@localhost --disable-manuals --disable-scripts --disable-mibs --disable-mib-loading --disable-deprecated

There are a few important options here:

• host, target, build: To be honest, I’m not exactly sure why these are the required settings for these variables, but I went through a lot of trial and error and this is what generated a working output
• enable-privacy, enable-des, enable-internal-md5: For authentication and encryption we need this. I am using “internal” MD5, hoping it will save a bit of space
• with-openssl=internal: Here’s the big one. If you need to support authentication and encryption, you will need the 1.3MB OpenSSL shared object (by setting with-openssl to yes or with no value). By setting this to “internal” you compile the required functionality into the agent and do not need to have the OpenSSL shared object present on your target
• enable-mini-agent: This seems to build less MIB support into the agent. Perhaps it does more things, but I’m not sure

You can see the help for the rest of the options by running ./configure –help. After we configured the agent we simply need to build it:

make

And then install it to a temporary location

make install INSTALL_PREFIX=/tmp/net-snmp-5.6.1

We then copy the following files to the target

• /tmp/net-snmp-5.6.1/usr/lib/libnetsnmp.so.25 to /usr/libs
• /tmp/net-snmp-5.6.1/usr/lib/libnetsnmpagent.so.25 to /usr/libs
• /tmp/net-snmp-5.6.1/usr/lib/libnetsnmphelpers.so.25 to /usr/libs
• /tmp/net-snmp-5.6.1/usr/lib/libnetsnmpmibs.so.25 to /usr/libs
• /tmp/net-snmp-5.6.1/usr/sbin/snmpd to /usr/sbin (and chmod +x it)

On the target, we create /usr/etc/snmp and upload an snmpd.conf file. This configuration file allows you to specify V2 communities, views, V3 users and much more. See this custom snmpd.conf i made for a simple V2/V3 example.

Now we’re ready to run the SNMP agent on the target:

snmpd

All in all, this requires ~1 MB of flash. Be aware that the apps directory holds all the Net-SNMP applications (snmpget, snmpset, snmptrap, etc) – they are very small and useful (~30k).

For reasons beyond me, I have a storage server set up with FreeNAS. I find it convenient to have all of my movies/music/TV shows on a PC that sees no action besides reading and writing to its drives. This weekend, while streaming a show from my storage server, the power went out. The server is connected directly to mains, so it went down – hard. To be fair, my Ubuntu based media center PC also died, never to recover. After a bit of troubleshooting and an annoying secondary problem, it seems to be up and stable.

My FreeNAS server is based on a 4 year old AMD 3200+ PC. Before setting everything up I made sure to clean the motherboard and CPU mount, applied new thermal grease on the CPU heatsink and upgraded the PSU to a Thermaltake 480W PSU – I really wanted to reduce chance of having any electrical/heat related issues that would take out the system. FreeNAS was loaded on a USB drive and a single 1.5TB drive was attached to the SATA bus. The server sat alone in a closet, connected via Gigabit ethernet to my home LAN and remained there. Headless, keyboard-less and monitor-less.

After the outage, the server did not respond to pings. I hooked it up to my monitor and attached a keyboard. It seemed like the BIOS did not even attempt to load an OS. I checked the BIOS settings and it seemed to revert to booting from HDD. Triumphantly I changed it to boot from USB and rebooted. Nothing. I then went ahead and restored BIOS defaults and again changed to boot from USB, just to start from a clean slate seeing as something freaky went on with the BIOS settings. No dice.

I tried yanking the USB key holding FreeNAS but that showed nothing. I then yanked the SATA cable from the HDD and finally something – the BIOS seemed to print something about Nvidia boot loader agent, but again hung. I knew something had shifted so I replugged the USB drive and voila – FreeNAS loaded. I let it load again with the HDD connected and it seemed I was successful.

Plot twist: FreeNAS reboots itself every 20 minutes

panic: ffs_blkfree: freeing free block

So it’s a file system issue, methinks. I then performed the following:

1. Via the FreeNAS shell I ran “mount” to see which partition my storage mount was on (it was /dev/ad4p1)
2. Via the FreeNAS web interface, I deleted the shares on the drive and deleted it from the drive management (this does not destroy the data on the drive, just detaches it apparently). Reboot
3. Manually unmount mount in /mnt (in my case, “umount /mnt/storage1″ – this depends on your setup). Reboot. At this point the partition should not be in use by FreeNAS
4. Time to fix the partition. I ran “fsck -t ufs -y /dev/ad4p1″ several times, until no errors appeared. Reboot
5. Via the FreeNAS web interface, added the drive (making sure pre-formatted was set to UFS). Re-added the share

That’s it. FreeNAS is up, running and stable… until the next power outage that is.

This post describes the steps required for setting up an Ubuntu based compilation and debugging environment for U-Boot and Linux 2.6 w/a JFFS2 filesystem on a custom PPC board, using an Abatron BDI3000. It mostly discusses the environment and doesn’t dive too much as to how to customize the packages for your specific board (this is the hard part, but also extremely board specific). While you will probably not follow this guide from start to finish, it serves as a reference for what is the minimal amount of work required to build U-Boot and Linux for a PPC8xx board and a supplement to the DENX DULG, which is a must read.

It assumes that Ubuntu is already installed on the station, but nothing else. On the host side we mostly need the ELDK – a single package that contains all the cross tools needed (compiler, linker, debugger, tools to generate a file system, etc.).

A basic U-Boot/Linux target requires four things:

• A U-Boot binary (u-boot.bin) generated by customizing the U-Boot sources for your board, compiled using a cross-compiler (ppc_8xx-gcc in our case) and burned to the correct offset in the flash
• Linux image (uImage) generated by compiling the untouched Linux sources
• A Flat Device Tree BLOB (.dtb file), generated by compiling (using a specialized compiler) a textual DTS file which describes busses, offsets and devices of the target board
• A Root file system containing all the files we’d like to appear on the target once it’s up, packed into a single file. This file is generated by packaging up a directory from the ELDK which contains all the tools compiled for the architecture using the appropriate file system maker (in our case, mkfs.jffs2).

Step 1: Getting the sources

In this step we install git (the source control system), eldk (the development environment), U-Boot (the bootloader) and Linux (the OS). Start by getting eldk 4.2 for PPC (iso) from here (The file is under /pub/eldk/4.2/ppc-linux-x86/ppc-2008-04-01.iso). Keep in mind that this may be very slow as the file is 1.9 GB; I used GetRight on windows to pull the file from all the mirrors concurrently.

Create a working directory in your home directory:

mkdir ~/dev
cd ~/dev

Get git:

sudo apt-get install git-core

Get U-Boot sources:

git clone git://git.denx.de/u-boot.git u-boot/

Get Linux sources:

git clone git://git.denx.de/linux-2.6-denx.git linux-2.6-denx/

Step 2: Installing the ELDK

mkdir eldk
cd eldk

Create a mount point for the ELDK installation CD and mount it (prepend the path of the iso to the file):

sudo mkdir /mnt/eldk-inst
sudo mount -o loop,exec ppc-2008-04-01.iso /mnt/eldk-inst/

Install the eldk for the ppc8xx architecture

/mnt/eldk-inst/install ppc_8xx

Add eldk to path by appending the following in ~/.bashrc using a text editor of choice (make sure to show hidden files). After this is done, make sure to re-open a terminal window for the next steps:
PATH=$PATH:~/dev/eldk/usr/bin:~/dev/eldk/bin
export PATH

Test this by running the following in your dev directory:

ppc_8xx-gcc

You should see the standard gcc “no input files” error.

Step 3: Preparing a JFFS2 filesystem

Strip the prepared ramdisk of its 64 byte header, revealing a gzipped file. Unzip it to receive ramdisk_image

cd ~/dev/eldk/ppc_8xx/images
dd if=uRamdisk bs=64 skip=1 of=ramdisk.gz

Mount the image and give everyone access/execute permissions to it

sudo mkdir /mnt/rootfs-inst
sudo mount -o loop ramdisk_image /mnt/rootfs-inst
sudo chmod -R 777 /mnt/rootfs-inst/

Generate the JFFS2 image assuming a sector size of 128KB (0×20000), in this case

mkfs.jffs2 -b -r /mnt/rootfs-inst -e 0x20000 -o image.jffs2

Step 4: Finishing up environment installation

First, we’ll install atftpd:

sudo apt-get install atftpd
sudo gedit /etc/default/atftpd (modify to USE_INETD=FALSE)
sudo invoke-rc.d atftpd start
sudo chmod 777 /srv/tftp

We then create three directories @ /srv/tftp:

mkdir /srv/tftpd/u-boot
mkdir /srv/tftpd/linux
mkdir /srv/tftpd/bdi3000

Configure the BDI’s server IP address. See BDI documentation for more info how to do this.

Step 5: Compiling U-Boot to receive a burnable u-boot.bin

• Create a directory under /board/my_board and have a Makefile, config.mk, u-boot.lds and my_board.c. You can copy these files from the standard ep8xx board
• my_board.c implemented the following functions:
  • checkboard: Just printed a banner
  • initdram: Initialize the SDRAM
  • board_poweroff: Reboot hook (didn’t implement anything here)
  • ft_board_setup: Fixed up the FTD BLOB passed to Linux with information gathered by U-Boot
• Add a header file under include/configs/my_board.h with all the preprocessor directives. Again, you can reference the standard ep8xx board, but make sure to define CONFIG_OF_LIBFDT and CONFIG_OF_BOARD_SETUP. Otherwise Linux will not boot because it doesn’t receive the FDT BLOB
• Add the board to the main Makefile (you should be able to easily understand using ep8xx as an example)

Clean, just to make sure

make distclean
make clean

And then compile it

make my_board
make

Step 6: Compiling Linux

sudo apt-get libncurses5-dev

At this point you will have to customize Linux. For PPC this mostly means creating a compilable device tree file (with a .dts extension) which describes the offsets of the core peripherals and such (instead of instantiating drivers in code). This is not trivial and is yet another syntax/structure to learn, but at least you have examples in the form of dts files for existing boards. In addition, you will also have to create a default configuration in arch/powerpc/configs, a custom platform in arch/powerpc/platforms (which will, at least, initialize I/O pins) and modify arch/powerpc/platforms/Kconfig + arch/powerpc/platforms/Makefile to support your new platform. Simply go by example of existing boards and check out this PDF.

Build Linux and the FDT BLOB (DTB file)

make ARCH=powerpc CROSS_COMPILE=ppc_8xx- my_board_defconfig
make ARCH=powerpc CROSS_COMPILE=ppc_8xx- uImage
make ARCH=powerpc CROSS_COMPILE=ppc_8xx- my_board.dtb

Step 7: Burning and configuring U-Boot

The following sections assume the following offsets: Flash starts at 0xFF800000 which is where the Linux kernel resides (until 0xFF9DFFFF), the DTB file resides at 0xFF9E0000 until 0xFF9FFFFF, the JFFS2 filesystem image resides at 0xFFA00000. Finally, U-Boot resides at 0xFFF00000.

Set up your BDI with a configuration script that will allow you to attach to the board and erase its flash. Define the sectors on which u-boot will reside so that the erase command will know what to delete. Copy u-boot.bin (from ~/dev/u-boot) to /srv/tftp/u-boot and then telnet to the bdi.

reset
erase
prog 0xfff00000

Open a serial connection to the target. Setup u-boot to auto-load the kernel at 0xFF800000 and pass the DTB @ 0xFF9E0000.

setenv ethaddr 00:e0:6f:00:00:01
setenv ipaddr [target-ip-address]
setenv serverip [your-pc-ip-address]
setenv bootargs root=/dev/mtdblock2 rw rootfstype=jffs2
setenv bootcmd bootm 0xff800000 - 0xff9e0000
setenv bootdelay 3
saveenv

Step 8: Burning Linux, the DTB and the Root filesystem

Using the U-Boot console, download the images to RAM via tftp. After each download, note the size printed by u-boot in hex: Bytes transferred = 1284822 (139ad6 hex). You will need this for the next step.

tftp 0x100000 /linux/image.jffs2
tftpboot 0x400000 /linux/uImage
tftpboot 0x800000 /linux/my_board.dtb

Burn the images to the flash

erase 0xffa00000 0xffcfffff
erase 0xff800000 0xff9fffff
cp.b 0x400000 0xff800000 [linux-size-in-hex, e.g. 139ad6]
cp.b 0x800000 0xff9e0000 [dtb-size-in-hex]
cp.b 0x100000 0xffa00000 [jffs2-size-in-hex]

Power cycle the board – Linux should be up.

Continuing my experimentations with cooking timer user interfaces, I stumbled upon a cute little rotary encoder on Sparkfun. It immediately looked like a good match for the project. The thing is that all cooking timers I’ve seen have either a simplistic interface requiring many clicks to set the time (like clicking the “minutes” button 50 times) or a complex keypad with way too many buttons.

At first I thought I’d need 2 axes (axis 1 would increment by 1 minute and the other axis by 15 minutes) but fiddling around with the trackball showed me that it was not necessary; that I’d just need one axis with tactile feedback (that is, a clicky switch rather than a smooth flowing motion of the controller) and some selection mechanism to switch between 1 and 15 minutes.

The Sparkfun rotary encoder fit the bill – 12 steps for full rotation and clickable! Perfect. I wired up the encoder on the breadboard, wrote the software and then fabricated two one layer PCBs.

The Hardware

4 digit Seven segment display

Another Sparkfun gem is the integrated 4 digit seven segment display. The 4 digits are internally connected and there’s even a colon in there – we save a LOT of nets and do not need to flip the 3rd digit to create a colon as there is a dedicated colon segment. The display isn’t huge, measuring in at 4 centimeters across, but will suffice for this test project. Hooking this up to the uC is very standard so I won’t dive into details. The only thing worth noting is that we need to wire up the colon anode to VCC and the cathode to the uC for controlling, holding it at logic high. When we want to light it up we sink the current on the uC by setting the cathode to logic low. You could and should ramp up/PWM this line so as to have consistent brightness with the multiplexed digits (i don’t do it in this project).

Clickable rotary encoder

The rotary encoder from Sparkfun gives two inputs: rotation (CW/CCW) and button click. The rotation interfaces takes the form of a standard gray code output: two channels connected to the uC input pins (w/external or internal pull ups) and ground. The difference between this encoder and the trackball from my previous project is that this is a purely mechanical interface, as opposed to a digital interface with the ALPS trackball. This means that while we received a perfectly filtered gray code signal from the IC on the ALPS, here we receive gray code directly from the mechanical rotation. Each rotation simply connects the channels to ground shifted by a quarter phase. In 99% of the cases we receive a good signal, but those extra 1% bounces need handling. We will see the waveforms in a bit.

The Software

Rotary encoder state machine

In my previous trackball project I needed to receive an event whenever the trackball moved. This was achieved very easily by simply analyzing the gray code and detecting valid gray code transitions. The difference here is that we don’t want to react whenever a bit change occurs, rather when a complete, valid cycle occurs. This cycle indicates that the user has performed one “click” on the control (there are 12 such clicks in a complete rotation). By detecting such valid cycles we filter out two unwanted events:

Normally, both channels are pulled up and sit there at logic 1. The CW flow starts by the first channel going to 0 followed by the second channel. The first channel then goes back up to 1 and so does the second. Any deviation of this flow should be filtered out, but mechanical bounces need not cause the motion to be ignored. To fulfill these requirements, I implement this using a two 3 bit “shift register” variables and a simple state machine.

The 3 bit shift registers hold the last 3 polled values of each channel. The polling rate must be fast enough such that 3 polls indicate a stable logic value (you can calculate the polling time required by measuring the shortest bit cycle you can and then diving this by at least 5 – for example if the channel bit is 1ms long when you turn the knob as fast as you can, you should set your polling to at most 200uS). The shift register value is then fed into a pattern matcher – this simply compares the value to either 111 (stable 1) or 000 (stable 0) at any given time. If a match occurs, a bit is appended to the value of the shift register – 0 for channel 0 and 1 for channel 1 (for example, if channel 1 has detected a transition to 0, the new value will be 1000, uniquely identifying an event that channel 1 has transitioned to 0). This new value is then fed into a state machine looking for a 4 consecutive values indicating the 4 step valid flow.

Let’s understand this by looking at how I detect the CW flow above. At first both channels are at 1 so the shift register value is always 111 for both channels. Since we want to detect a stable transition to 0, we set the search pattern for both channels to 000. 3 consecutive polls equal to 0 satisfy the requirements of debouncing mechanical spikes. Once channel 0 goes to 0 for more than 3 polling cycles, the pattern match occurs and the value is fed to the appending mechanism which appends 0 (for channel 0). This value is then fed into the state machine which sees that it indicates the first step of the 4 step flow (channel 0 went down to zero).

The pattern matching for channel 0 is then set to 111 (we want to know when the channel goes back to 1) and the state machine is set to expect the next step: 1000 (channel 1 goes down to 0). In a valid flow channel 1 goes down to zero, the pattern match occurs, 1 is appended to the shift register and the value is fed to the state machine. The search pattern for channel 1 is then changed to 111 and the state machine is set to expect the next step: channel 1 goes back up to 1.

This flow continues until the entire flow occurs correctly. If at any point something is done in the wrong order, the entire state machine and pattern matching resets. This mechanism filters out any “half cycles” performed by the user. Only when the user clicks the rotary to the next notch will the above flow occur. This state machine is written in quadenc.c: quadenc_isr().

Seven segment display

Operating the 4 digit SSD is exactly the same as operating 4 separate seven segments – you select a digit via a transistor, illuminate the desired segments, pause, select next digit and repeat. There are tons of tutorials on seven segments out there so I won’t dive into details. The only thing worth mentioning here is that in my implementation I do two obvious things:

1. Whenever I want to display a number I modify a RAM array containing 4 bytes – each byte representing a digit and each bit representing the appropriate segment (the position into the byte is the position of the segment in the I/O port). Doing this does not affect the value displayed to the user – it’s all done in RAM – see sseg.c: sseg_setDisplay().
2. A timer interrupt (shared with the rotary encoder polling mechanism) is set to occur ever X interval (a few milliseconds is fine). When the interrupt is raised I load the next byte (of the 4 bytes modified by the application) into the port. Can’t get any shorter than that. See sseg.c: sseg_isr().

The user interface is a standard state machine driven user interface. The video below has a short walkthrough of the interface. As such, I’ll focus on the button event handling mechanism because this is somewhat reusable over projects.

Just like for every mechanical button, software debouncing is required. This is done by polling the input pin every X ms and shifting this into a 3 bit shift register (no interrupt is used). Once a stable pattern is detected (either 000 for button down, 111 for button up) we can handle this event. However, our timer exports a few cases for the user:

Single click: pausing an active timer or switching between 1 and 15 minute intervals

Double click: Reseting the timer

Long press: Start a timer

Press and turn: Select a timer

This requires some code to handle, done in a state machine separate from the user state machine (see ui.c: ui_checkButtonEvent()). The outputted events from this button handling machine are fed into user interface to actually perform the desired event.

Video demonstration and waveform explanation

---

The following video gives an overview of the timer user interface (interesting unto itself) and then at just over five minutes in shows waveforms for working with the rotary encoder.

Related Downloads

---

• Schematics in Eagle and images (main board schematic, display mezzanine board schematic)
• Corrected Sparkfun 4 digit seven segment display eagle part (not part of the Sparkfun library, but imported from a Sparkfun project and fixed package)
• Full source
• Hex file

]]> http://www.pavius.net/2010/02/rotary-encoder-based-cooking-timer/feed/ 31 http://www.pavius.net/2010/02/dremel-220-vs-proxxon-mb140s/ http://www.pavius.net/2010/02/dremel-220-vs-proxxon-mb140s/#comments Mon, 15 Feb 2010 18:35:29 +0000 Eran Duchan http://pavius.dreamhosters.com/?p=4

Started fabricating PCBs at home using the toner transfer method and needed to find a way to drill them, as I am still mostly using through hole parts. Since I was pleased with my Dad’s dremel 300, I thought it would be a good idea to get one for myself along with a Dremel 220-01 (220) drill stand. It took me a few minutes of painful work with the stand to realize just how bad it is for the job – it flexes, it’s plasticy and it’s an insult to Dremel users.

I got a tip to check out the Proxxon Micromot MB 140/s and IB/E, which costed me dearly. I was blown away by how stable it was – felt like I was working with a surgical tool. To make a long winded youtube video short – the Dremel is bad for drilling PCBs and the Proxxon Micromot MB 140/S and IB/E are good. I got my solid carbide bits from BitGuy1 and was very pleased with the service and the bits themselves (they are used, but plentiful – good for amateurs like myself). He has many bits unlisted – just ask him if you can’t see what you’re looking for.

Double click the video above to see in glorious HD.