Hi,
Anouk Ahamitet <> [20080623 12:29:34 -0000]:
>
> [snipped]
>
> And, FWIW, when I said "they ignorantly use usleep" I was referring to the
> lack of any comments indicating awareness that usleep() could take as long
> as 10,000 microseconds to return. As a long time maintenance programmer,
> that's the kind of code that makes one wonder how the hardware really
> works, and if the author understood the functions being used.
>
As a author who definitely understands nothing and its just tinkering to
have fun... :)
I thought it would be worth just throwing in what I'm planning on next doing
with my TS-7800->orion5x[1] work. I want some input from the TS7xxx folk as:
1. I have no need to do sampling
2. I have nothing to sample, not even a signal generator to hand
3. you guys *are* using this, or at least trying to
> In other words, a prime example of the source code providing very little
> trustworthy information, since it looks like it generally works by luck.
> And generally is a very deliberate choice of words, because, at least on
> our board, ts7800ctl doesn't work 100% of the time. Sometimes it gets (and
> doesn't handle, but that's expected in a demo, I guess) errors selecting,
> reading or writing. And a couple times it just kinda hung until we killedi
> it. Hopefully that helps explain why we're reluctant to attempt to learn
> anything from that particular source...
>
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.
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
* 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?
* 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?
* 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?
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/
|