> Are these fast enough for sampling bits from CTS and putting a clock onto
> DTR at 100.200 Hz?
>From userspace, you can generate about 50Hz. From a kernel driver, you
can do 100Hz. Unless you compile your kernel to use a higher HZ value.
while (!told_to_stop) {
data = 0;
for (i=0;i<8;i++) {
set_dtr (1);
usleep (1);
set_dtr (0);
usleep (1);
data <<= 1;
data |= read_cts ();
}
printf ("Got data: %d.\n", data);
}
The "usleep 1" will wait for about 20 ms. That's the way it works on
Linux. What's the max? You could implement your own udelay. If it's
reasonably fast, and the hardware allows "random delays", you could
replace the usleeps by udelays.
int bogomips = 400; /* Adjust for your machine, calibrate! */
void udelay (int usecs)
{
int t = usecs * bogomips/2;
for (;t;t--);
return;
}
Then change the usleeps to udelays, and live with the CPU usage that
this generates.
> Will switching to the data lines (without having any kind of protocol or
> stop bits or something) do any good? I can probably convince the hardware
> guys to use a different pin on the RS232...
No. DCF decoding works with the data-pin, this doesn't.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* "I didn't say it was your fault. I said I was going to blame it on you."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/