[Pziz] wrote in with one of his projects. He created a linux kernel driver for the PIC 18F*55* series based on some available development tools. Continue reading for his (slightly edited) writeup.
I think Hack-a-day readers might be interested by a project I did, as a french (…) engineering school project. The goal was to provide a way to do Linux-only USB communications with the PIC18F4550 (the “linux” part was actually my idea ;-) ). While most projects seen on the internet involving this chip end up with some kind of MS windows driver, this one shows how to make a kernel module that will create simple /dev/ interfaces and sysfs attributes.
It’s actually a modified version of the PIC USB Framework, which didn’t provide for data transfer code in the firmware (except for the bootloader), and no kernel module, but it includes everything needed to get you started with the PIC18F*55* series: (a compiler (sdcc), programmer, firmware and a USB bootloader.
The transfer speed is not huge (you should be able to reach something like 300kB/s, and I used some tricks to get that speed with that chip), but that’s not what the 18F4550 was made for anyway.
That driver was made without any feedback from “experts” in kernel modules, and there’s probably a lot of bugs, so if you have any remarks, you can contact me at psizzz+hackaday at gmail.com.
Possible developments with this firmware and driver include “proprietary” protocols for any low/full speed application, but you can also modify the firmware to make it behave as a HID for example (low speed inputs (as a keyboard, mouse, …) / outputs (as keyboard leds, etc.)), or a mass storage device, which means no driver development, and the ability to use it on any OS.
May the Hack be with you.
Why not use libusb instead of a kernel driver? AFAIK libusb supports any USB transfer mode except isochronous. It’s much safer to do this kind of thing in user-space.
Actually when I did that module, I had thought about using isochronous instead of bulk at some point, but the main reason is simply because that was a way to learn very basic kernel programming for me (you have to start somewhere :) ).
Also I find it cleaner to have a working kernel-space backend then do the less-low-level stuff that doesn’t know anything about the hardware protocol in user space.
And BTW, the bootloader uploader in the original package already uses the libusb, so that would not have been as fun as trying to write a small kernel driver :)
I forgot to mention another “real” reason actually, if you don’t use a special /dev interface but want to replace it by a ttyS or parport emulation for example, its much more difficult, if it is even possible, to do that without being in kernel space
alternatives:
linux driver:
http://osrfx2.sourceforge.net/
windows driver:
http://www.codeproject.com/KB/system/kmdf_osr_usb_fx2.aspx
uses: Cypress Semiconductor USB FX2 chipset