PIO testing

read http://www.nioswiki.com/operatingsystems/uclinux (http://www.nioswiki.com/operatingsystems/uclinux) and some of the links provided there.

If you are doing your own harwdare, you indeed will need to create a hardware port for LEDs and buttons. The SOPC-Builder provides modules and instructions.

The "proper" way to access custom hardware in Linux indeed is writing device drivers. AFAIK the already is a "PIO" (or GIO) driver that allows for accessing the Altera Avalon PIO. For non-.standard hardware, again, see the Wiki. In simple cases, you can avoid doing drivers by "uio" (I did not try yet).

-Michael

got it (or at least I hope so)

thanks mschnell, I'll give it a try

OK, now I'm sure I'm stuck

I did everything they wrote on nioswiki

I wrote a driver to my leds ip, gave it the base address from SOPC builder

gave it a major number and the neccesery functions

added the neccesery adjustments to the kconfig and makefile files

when I config my kernel I can see my driver in devices driver --> misc (where I put it)

but when try to insmod my driver it says the my driver's .ko file does not exist

and now I&#39;m stuck :<

does anyone have an example of a driver module?

and also, how do I use a device file in an app after opening it?

thanks,

Asaf

most likely: insmod needs the complete path of the ko file, which might be quite complex. modprobe kust needs trhe module name.

If this is not the cause:

Did you configure the Kernel to be able to deal with loadable modules ?

Did you create the appropriate Makefile for your driver ?

Did you "include" your Makefile in the general Makefile ?

-Michael

I followed these instructions

http://www.nioswiki.com/operatingsystems/u...duleprogramming (http://www.nioswiki.com/operatingsystems/uclinux/moduleprogramming)

did I miss anything?

does the ko file exist after all (in the correct directory).

-Michael

hmmm no. I don&#39;t think it&#39;s created in the same folder

I made a simple "hello world" kernel module

it worked but I didn&#39;t see it&#39;s .ko file in the same folder either

btw, if I have a kernel module for pio (assuming it works)

do I use "fopen"/"fclose" in my app to open/close a device file (like /dev/pio_buttons)?

is it that simple? :huh:

The ko file should end up in a directory similar to this: ~/nios/uClinux-dist/romfs/lib/modules/2.6.30-00471-g2e1b9d6/kernel

>do I use "fopen"/"fclose" in my app to open/close a device file (like /dev/pio_buttons)?

In Linux, a character device is just a (virtual) file. The device code needs to provide handlers for the different user space actions like open, close, read, write, ioctl, mmap, select, ... . (IIRC, fopen is a user space wrapper for open, You can use fprintf with a device that just provide a write handler.)

-Michael

oh, I get it (I think)

you mean I need to use "mknod" to create the virtual device file?

then I can use fopen/fclose to write/read from my module? (assuming the driver allows it, of course :))

<div class='quotetop'>QUOTE (asafvm @ Aug 1 2009, 08:10 PM) <{post_snapback}> (index.php?act=findpost&pid=23365)</div>

--- Quote Start ---

you mean I need to use "mknod" to create the virtual device file?[/b]

--- Quote End ---

Not really. Either you can activate the device file system and provide a hook in the driver and the device node is created automatically, or you can have the uCLinux make process create the device node in romfs and thus it is already available at boot time.

<div class='quotetop'>QUOTE (asafvm @ Aug 1 2009, 08:10 PM) <{post_snapback}> (index.php?act=findpost&pid=23365)</div>

--- Quote Start ---

then I can use fopen/fclose to write/read from my module? (assuming the driver allows it, of course :))[/b]

--- Quote End ---

yep. The driver would need to provide the appropriate open, close, read and write handler functions. The read and write handler need to use the copy form/to user function provided by the Kernel to access the memory the userland process holds.

BTW.: it might be sensible to e.g. have the driver provide a blocking read so that the user program can do a non-busy wait if the driver needs to wait or some hardware action to complete. If you want to allow the user land program to wait for multiple drivers at the same time, you would use select() or something similar and the driver would need to provide a handler for that, as well.

-Michael