dave_w_hawkins wrote:
> Recode your driver to implement additional device nodes
> for the I/Os you plan to independently control in user
> space.
>
> Locking access to the pins can be done in two ways;
> - spinlock between the ISR and the read/write
> routines of the other nodes, or
>
> - kernel thread and semaphores
Thanks for the suggestion. I haven't done any of that before at the kernel
level. It sounds a bit overly complex for what I need to do.
Triffid Hunter wrote:
> This solution only has the illusion of being simple - at the very least,
> it would cause jitter in your output from where interrupts are disabled
> when the timer fires, and at worst you could mess up a whole host of
> kernel timing and other services.
I thought I could probably have gotten away with it unless the enable/disable
interrupts instruction was priveleged. Jitter wouldn't be big a problem. The
frequency range for the output lines is in the range of 1kHz +/- 500 Hz. The
interrupts would only need to be disabled long enough for a couple of ands and
ors.
> I'd add a character device to /dev or /proc which accepts bytes, stores
> them in your kernel module somewhere and mask+ors them to the output every
> interrupt. Avoids anything complex in userspace, allows all the bit
> masking and whatnot to happen in one place, but also puts a <=500uS delay
> on output from userspace apps.
This sounded like a much simpler approach. I spent most of Saturday reworking
my kernel driver to create a couple of extra /proc nodes. I created three
nodes under /proc/sensors. One for the flow rate sensor (read only device) and
two for the two sensors for which I need to control range setting bits.
From a command prompt I am now able to cat the nodes to see their current
settings and I can use echo to set the range bits. The 500uS delay between
writing to the /proc device and the change in the range bits is not a problem.
I only read the A/D's once a second and it takes 1mS to read each A/D channel.
The range bits are only read/changed after the A/D readings have been taken.
There is plenty of time for the range bit changes to take effect before the
next cycle.
> In theory, you could grow such a system into a generic port driver which
> can allocate different bits to different drivers/processes in either
> kernel or userspace and a generic timer driver which would be incredibly
> useful to many people on this mailing list. Simply posting the code you
> have now could easily allow someone else to do it for us :)
In theory I could make the module more generic to handle what you are
suggesting. I don't have the time now and don't expect to have the board for
long once the project has been delivered to the client.
If someone is keen to generalize what I have (if they really thing it would be
useful) I could post the current version of my kernel module.
--
Cheers!
Kevin.
http://www.ve3syb.ca/ |"What are we going to do today, Borg?"
Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus:
| Try to assimilate the world!"
#include <disclaimer/favourite> | -Pinkutus & the Borg
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|