I can't recall how I stumbled on this but it looks like a fun past-time: EZone: Electric Flight. Check out Fred's lunch break.

• info
  • comment?
  • permanent link
  • email this

Zeke is doing better, thanks for the emails. He's still favoring the leg but his spirits are higher and he looks much better. He's confused: no one at the office will throw the frisbee for him.

• info
  • comment?
  • permanent link
  • email this

• info
  • comment?
  • permanent link
  • email this

The project I'm working on uses Windows CE .NET. Windows CE is Microsoft's embedded operating system. It is somewhat similar to that used on the Pocket PCs out there. The Pocket PC group, being a "customer" of the Windows CE group, modifies Windows CE to match their platform specifications. That is exactly what I'm doing. We are building hardware and need to teach WinCE to run on it.

An embedded system is something of an autonomous, and hopefully stabler, version of your home computer. Usually it has a smaller form factor and cpu, less input and output, and does one or two things and does them really well. Factory floor robots, onboard car control computers, handheld GPS, and even cell phones are all considered embedded systems. They are most often associated with real-time operation. Certain tasks must happen when they are scheduled. A flight controller or medical equipment can't afford to go off and "examine its belly button" for a few seconds like our desktop computers tend to do.

I'm working on the code that first fires our system up. Microsoft calls it the OEM Abstraction Layer, the chunk of code that sits between WinCE and the hardware. It starts off in assembly code, turning on/off features of the CPU and hardware, getting everything in a known state before invoking the CE kernel and really getting things rolling. There is a lot to learn. Some days I am in heaven just from the simple act of turning on an LED.

One cool feature of CE is that they abstracted debugging communications into an independent transport layer. That means that you can use practically anything to hook the hardware to the development machine. Out of the box it supports serial, parallel, and ethernet. Ethernet is the way to go since it is fast and we can use the same connection to download system images.

This week I've been bringing up the kernel's ethernet support on the hardware (using a working serial debug port). Yesterday it reached the point where DHCP packets were going out, response packets were coming in, but nothing else was happening. It looked like I was going to have to write more code to decode and dump packets out the serial port. That was when I remembered the Unix sniffing programs I'd used at another job.

A sniffer is a bit of software that sits and listens to traffic on an ethernet interface. The whole internet isn't routed through your local network so your sniffing is limited to what the other machines around you are doing. It's good to remember that anything and everything you do on an office network can pretty much be seen by anyone else in the company. I searched the web and found a sniffer for windows called Ethereal. It worked great! I could see the DHCP packets my little board was sending out and the response from the router. Within a few minutes I figured out the problem and fixed it.

I know this stuff is probably boring as hell for 99.9% of my readers. I've been thinking of creating a side-weblog to chronicle my Win CE learning experience. Kind of like my electric car log but in this one I can blame everything on Microsoft. ":^)

• info
  • 3 comments
  • permanent link
  • email this