dietmar.dreyer schreef: > Hi all, > > I'm working on a project where I need to periodically poll several > input pins with at least 5 kHz frequency as I need to be able to > detect the correct sequence of binary input signals. > I tried to use the timer1 interrupt from a kernel module, after > compiling a 2.4 kernel without the > fasttimer api, but I am not able to get it right. > After configuring and starting the timer, the interrupt handler is > called once and after that the system > seems to hang (all LEDs flashing simultaneously). > I am neither sure if I am configuring the timer appropriately, nor do > I know precisely whether it is actually possible to use timer1 from a > kernel module without breaking internal kernel operation. > Any help on this topic will be appreciated. Thanks a lot! > > Dietmar >
Polling for state-change is never a good idea (you might miss stuff if your cpu is busy doing something else) This is why interrupts where invented I think. I guess I would decouple (in a logical Object Oriented sense) the change detection from the processing. My first try would be like this. Use a PCF8574 i2c I/O extender and connect the interrupt to a pin that handles the interrupt in the kernel. Your driver can then pull the data from the device (which automatically resets the interrupt) and you are done. Read this PDF and look at picture 7 http://ece-www.colorado.edu/~mcclurel/Philips_I2C_IO_Expander_PCF8574_4.pdf It works like this : 0) initialize the i2c device for inputs by sending all outputs to '1' 1) you enable interrupt on your IO pin and you are idle 2) you get an interrupt (any change in input will trigger interrupt, either low-> high or high->low) (you can see how this trick works when you look at picture seven, the D-flipflop and the XOR port) 3) you service the interrupt by reading the 8 bits (using i2c) from the device 3a) push the data to user-space 4) goto 1 I talked to Geert van Compernolle about this something because he is doing something complicated with his i2c home control project. As far as I know he is still polling the IO extenders... ;-( Concerns about speed : none, you can service the interrupt directly and talk at 400 K bps (i2c speed) which means that reading the data will take at least 25 micro seconds (us) but a more conservative estimate would be 100 us (which means you can do it like 10000 times a second if needed) When you need more IO pins to look at, no problem add more IO-extenders : you can connect the ~INT pins together since they are open collector (or drain) and so you can easily watch about 128 pins for changes with 3 IO pins from your microcontroller (Data/Clock/Int). I love the simplicity of it, don't you? The good thing about this is that you are not busy waiting for something that happens once every 64 million years. Best regards, Edwin van den Oetelaar
