Hi --
--- In Alexander Clouter <> wrote:
>
> As a author who definitely understands nothing and its just
tinkering to
> have fun... :)
>
> [snip]
> >
> I'm now starting to look at how best to deal with the ADC/AVR
McWhatsit and
> how to present this to the user; mainly as it's the next most
interesting
> thing to add support for next.
Most full-blown A/D cards in linux have drivers that conform to the
comedi interface, but that may be a little over-engineered for an
embedded system with only an A/D, no gain settings, etc. But it may
be worth a look, if only to get interface ideas:
http://www.comedi.org/
This topic (where to place increasingly common non-sensor A/D) has
recently come up on LKML too. May be worth a look for future direction:
http://marc.info/?l=linux-kernel&m=121127840626414&w=2
See especially here, regarding the work already done by the
handhelds.org guys on this:
http://marc.info/?l=linux-kernel&m=121190685900869&w=2
Finally, take a look at Phil's MAX197 driver for some interface ideas
(in the file area of the group).
> I'm definitely going to make it a kernel land driver that lets you
set the
> channels you wish to sample via sysfs (/sys) and then when you say
"record"
> it will spit out from some /dev device the sampled data.
>
> Hopefully all you will need to do is write a few values to /sys to
say what
> it is you want to sample, tell the kernel "go" and then start
reading in the
> data with a select() loop on the /dev device.
>
> Is this an okay interface for you guys? I trying to figure out how
best to
> deal with the following problems:
> * userland tool might prefer to mmap() and be 'poked' when there is
data
Userland tool will use whatever method your driver does, if he wants data!
> * I was thinking that we might want some DMA support, then we are only
> dealing with 2000 16bit samples a second, so probably not to bother?
I agree, at least not at first.
> * when you turn off the 'record' flag the /dev input will finish
gracefully
> with the last batch(es) of data followed by an EOF or something
> * what to do if the user does not pull the data fast enough.
Should I dump
> the data to get lost in the ether, store in a buffer in kernel land
> until the user gets around to their job (how large should I let the
> buffer grow?). Again as we are not talking about a lot of data we
> could probably happily store ten seconds worth of sampling and still
> sit less than 64kiB?
Circular buffer, size set by module load parameter?
> * any failure conditions I cannot think of
> * as I do not use this type of functionality I have no idea how
people like
> to use this type of thing
> * should I be interweaving the /dev stream with timestamps when the
samples
> were taken?
Depends ... Is there any support for other sampling rates with this HW?
Regards, ....... Charlie
>
> Suggestions welcome. From my perspective having the kernel deal
with all
> this (including the reblating of the FPGA memory with 0xffffffff) is a
> Good Thing(tm).
>
> Again the disadvantage of using my code, no SD card support. You
could call
> upon a USB key though to store data or some data storage logger that
lives
> off a serial port...
>
> Cheers
>
> Alex
>
> [1] <smugness>
http://git.eu.kernel.org/?p=linux/kernel/git/nico/orion.git;a=commit;h=7171d8672bb0bcb744935bd2c6108378b5c6c6ad
</smugness>
>
> --
> ______________________________________
> / He who makes a beast of himself gets \
> | rid of the pain of being a man. |
> | |
> \ -- Dr. Johnson /
> --------------------------------------
> \ ^__^
> \ (oo)\_______
> (__)\ )\/\
> ||----w |
> || ||
>
------------------------------------
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/
|