Kernel driver for the PIC18F4550 microcontroller


[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.

Comments

  1. bertrik says:

    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.

  2. PsiZ says:

    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 :)

  3. PsiZ says:

    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

  4. 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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 94,591 other followers