Stephen's Weblog

So, you’d like to write a Windows kernel mode driver? No? Well, run along then.

Curious though? Then read on.

I’ve always loved system programming – for some reason the interface to hardware is just so much more exciting and appealing than pure software API interfaces. You have a complex machine at your disposal, which can only be directed by an arcane sequence of carefully executed reads and writes to its control bits. Of course some hardware can be really exciting and fun to use (e.g. Nintendo Gameboy Advance was an excellent platform), and other interfaces can be pretty grueling and boring (My least favorite so far is the I2C hardware on the NXP LPC1342), but it’s always a great feeling to write a bunch of commands and have the hardware smoothly execute the complex maneuver you have prepared. Most of my experience in system programming has been on embedded platforms, microcontrollers, game consoles. The hardware in modern PCs is actually surprisingly similar, though because of the architecture differences, devices use DMA more often for efficient access.

It’s actually really simple to get going with a new driver on Windows – not that the system is simple, Windows drivers are very complex – they can run on multiple versions of the Windows kernel and are required to participate in some level of the system’s power management system, so there’s a lot of arcane details at play – However, there are various driver frameworks which handle all of these details for you, allowing you to focus on just the functionality you care about.

In this multi-part series I’m going to walk through the process of building a new driver (using WDF/KMDF), getting it to load on hardware (a PCI Express device), and receiving usermode requests and programming the hardware to do something. Eventually I’ll repeat this with some other frameworks (I have NDIS and Storport in mind)
This isn’t hard, but it is obscure and a bit arcane so it’s not a path that I believe is visible to new driver developers. The documentation is pretty thorough but the massive breadth of detail in Windows kernel driver development can be daunting for a newcomer.

Note also that I don’t intend to showcase all the pitfalls of driver development here, but I’ll mention some of them as they’re relevant.

One final side detail is that I’m currently employed by Microsoft. To be clear, though, this series is the product of my own time using publicly available information which I’ll try to link extensively. I’m fortunate to have had a lot of opportunities to learn these details in my work and I’m eager to make it easier for others to get started. There’s a daunting amount of information available, often written with the assumption that you’re familiar with the space (which you soon will be, given a few early steps into driver development)

So, without further delay, this is Part 1: Building and loading a driver.
(more…)

So, this hasn’t worked out quite how I anticipated so far, I’ll have to give it another go later.

You might have seen the hrv_monitor board in a picture I linked a while back – It is intended to be a simple reflective heart rate monitor. At the moment I’m unclear if I’ve badly underestimated how much accuracy I need, or if there’s some other problem with what I did that is more fixable in software…

I built a simple software stack hoping to get some data demonstrating that the device works; and what I’ve found is that the device makes a great near-range reflective rangefinder, but it’s not showing any trace of a heartbeat in my data.

So far what has been done is:

• There’s code for the microcontroller which runs on a timer and collects ADC data 100 times a second. If the PC software is connected, it will send that data over USB.
• I built a simple demo app which indicates its presence to the uC, and receives and graphs the data, image below. The black trace is the “dark” measurement value with no LEDs on, and the other 4 lines are the ADC values measured with each of the LEDs lit, in turn.

So well, not everything works on the first try, I certainly don’t claim to be an expert in this kind of biometric sensor and this was a very quickly thrown together side project based on assumptions and not research. Maybe I’ll still get it working though, another time – Too many other projects need attention for now.

In case anyone else is interested, the code and design files related to this project are here: https://github.com/sgstair/random/tree/master/hrv_monitor

I received my Kickstarter RigidBot in the mail yesterday and I’m attempting to put it together. Below are my notes from the process (this will change a bit until I’m done). I’m just using the documentation, may go back over the videos if I can’t figure something out

• Direction the wires should face when assembling the motors is not specified. This always worries me, having assembled printers where this is vitally important.
• Eventually it does cause problems: The extruder assembly needs relatively specific wire orientation; The wires for the thermistor and heater should come out on the fan side, and the motor wires must not come out of the bottom face. I also rotated the PCB from their diagram just in order to be able to connect the thermistor, and the thermistor wire is still a really tight fit.
• The extruder assembly instructions not great: definitely don’t follow the steps in the order shown. I put the hobbed drive gear on backwards from their diagram so the lock screw can benefit from the keyed shaft, it seems like it will work.
• I’m now trying to infer which of the 2 lengths of unmarked steel rods are for X and which are for Y. They only differ by about an inch in length.
• It looks like the longest rods are used in the Gantry assembly (X axis, I assume)
• Most everything else went together pretty simply. It’s the most straightforward 3D printer I’ve assembled so far (took less time than the printrbot simple, much less time than the mini Kossel that’s not done yet, and I never finished the QU-BD after a lot of time, it became the mini Kossel)
• There are some gaps in the instructions. They’re possible to reason out logically/mechanically or by experimenting.
• Reversing the extruder drive gear did cause me trouble later; I took a file to the middle of the heatsink to make things fit. Then I also filed out the attachment holes a bit further out to make them fit better.
• I think the extruder calibration is off, and the PID values are way incorrect for the amount of power they’re applying (24V 17A supply, sheesh)
• Most everything is working now though, will test print soon.
• It doesn’t look like the extruder calibration is off, and it looks like the printer’s characteristics are hardcoded in the firmware
• Test print seems to be working pretty well. The machine appears to be able to print at higher speeds than I’m used to (useful, for trying to fill that giant build volume) – I’ll have to play with settings to see what it can do.

A few more notes now that I’ve had it running for a bit:

• I’m not using any special print settings, just the relatively optimized defaults I was using on the printrbot. About 70mm/s max, 204C PLA, 60C bed - It’s printing surprisingly well on just the aluminum surface (I couldn’t get the printrbot to do that when I first got its heated bed working, but haven’t tried since.)
• The fan must be forced on, or the extruder will fail horribly. I think the firmware detects the jam somehow and slows down printing? Not enough data, but neat if so.
• The firmware seems to have a lower (than I’m used to) maximum acceleration, and there’s a lot of acceleration/deceleration ramping as a result.
• I removed the fan grille on the extruder and replaced it with some washers, because it was blocking the fan (probably due to overtightening). The heatsink really needs to be tight against the aluminum mounting/feed block.

Well! It’s been another year since I posted anything; not the first time I suppose.
I’ve come up with an idea for something I want to do though, which will result in a lot of blog posts in about a month or so. I don’t want to say too much about what it is yet, but keep an eye out for it :)

Well, when I initially pushed myself into writing on a schedule, I thought having to write about something periodically would be an interesting challenge; I’ve learned a few things since then, one of which is that when I don’t have anything specific to talk about, I don’t really have anything to say either; So I’m changing the format of this blog once again to just post about project completion & milestones when they happen, rather than on a fixed schedule. Looking back the updates I’ve made are interesting from the perspective of seeing how things were going over time, but I think it will be more interesting if I’m just writing about the stuff that excites me :)

With that said, there’s nothing to  show for this week besides minor progress on a few fronts; so here’s a picture of my desk as it stands pretty recently:

Projects have been moving more slowly than I anticipated, and I don’t really have time to write much, so I’ll defer this update; Will post about what I’ve been doing in (just under) 2 weeks.

Happy new year, all.

Nothing really big to show off, but a few things are moving along:

First, I’ve started a Flickr page! Pictures I take (typically of stuff I’m working on or taking apart) will be auto-uploaded to http://www.flickr.com/photos/sgstair/

I don’t always update the descriptions but any questions posted in the comments will be answered :)

Second, there has been some progress on bitbox; After some early failures, I now have the bitbox_test board working! I misread the datasheet for the LPC134x chips initially – The USB bootloader requires an external crystal; I’m not quite sure why I thought otherwise. For the bitbox I am attempting to do USB without a crystal even though the internal RC OSC might be slightly out of spec. Maybe I’ll need to revise it.

Next I’ll be writing some initial firmware for this board and then all things bitbox should start to move along.

I also ordered some laser cut acrylic for the test fixture, and should get that back in a bit over a week – this test fixture has been interesting to design – it’s a little overengineered in hindsight, I’ve since designed another fixture (for another project) that’s far simpler. Below is my laser cutting pattern with a few designs:

I’m using Ponoko to have this produced – will have to talk more about it next time.

Still nothing to speak of, but a few things are in the pipeline for next time :)

Still nothing major to report on.

Several of my projects are still making progress, though incremental at best; I may just need to rethink the set of things I’m working on in order to move more quickly again. Or just somehow become less lazy ;)

Well, I’ll say more later.

I’m still off doing a number of other random things, and haven’t done anything interesting enough to post about it yet.

• Limited progress on the PCI Express firmware… Should get back to that. Have learned a lot about high speed serial, and a lot of related fields.
• I have obtained some cheap wired 3d shutter glasses and a 120Hz projector… this may be interesting.
• Also been reading books, this one has been really interesting.
• And, dealing with some failing hardware :\ one of my RAID cards died recently.
• Been dabbling in high speed video, but nothing interesting here yet…
• Have a few PCB projects staring at me waiting for me to complete them :)
• …And a growing collection of other projects doing the same.

Well, maybe next time I’ll have more to say, wish me luck.