--- In wrote:
>
> >Since all other mice seem to be accessible through devfs I assumed
> >this was also the case for serials.
> >
> >Damn , I was hoping this was going be followed in kernel space to
> >guarantee not missing any pulses. Well there's other ways around
that
> >problem.
>
> You already have a buffering kernel driver for the serial port.
> A serial mouse is usually sending data at 1200 bps. Assuming a
clean
> signal from the mouse, you would have to work pretty hard to find a
way
> to miss mouse events.
>
>
> The major areas I would watch out for are:
>
> 1. Some mouse devices have real rs232 drivers, but most of them
were
> designed to be sure the signal is just good enough to make it a
whole 1
> or 2 meters from the mouse to the computer. Some of them do not
bother
> to do the full +12/-12 volt swing of rs232. Check it out carefully
if
> using long wires from the mouse to your computer.
>
> 2. If the meter can turn faster than the mouse can send the motion
events,
> you have a problem. I would also check that the mouse really does
send
> a motion event every time you think it should. You might not notice
> if a mouse fails to report a motion event now and then, so I
wouldn't
> have any high expectations that the guy who did the firmware paid
close
> attention to that aspect of the firmware. (On the other hand, a
mouse
> that loses button events is quite visibly broken.)
>
> 3. If you have a single process that tries to do a lot of other
> things in addition to reading the data, you could have problems.
> As a really extreme example, if you read a mouse event then print
"Saw
> mouse event. Continue?" and wait for the user to say "yes", you
would
> have a problem. :) Of course, you aren't going to do that, but if
your
> program does a lot of computation or i/o, it might prevent your
process
> from keeping up with the data stream. You have plenty of time to
mess
> around, though. 1200 baud is only 120 bytes per second, and it
takes
> several bytes to report a mouse event.
>
> Fortunately, the kernel driver isn't going to make a difference to
any
> of these problems, so you do not need to worry about it. Regular
> serial port programming is sufficient.
>
> Mark S.
>
Mark, thanks a lot for your comments.
much of the problem was that I had not realised that init was still
spawning getty on ttyAM0 once I had pulled J2 off to prevent it being
used at boot time.
Now I've removed that from inittab I get the usual odd chars to the
screen when I cat the device so that's half way there.
I know MS mouse is pretty sloppy RS232 but I think my usage will be
very close to classic mouse usage in both distance and event flow.
Thanks for pointing out those caveats though.
I will be able to plot my flow rate. Any dropped data should show up
pretty clearly as glitches in an otherwise stable flow, so I will be
able to verify that it is reliable.
I was hoping for something like gpm to preprocess the data for me but
looking into it it would be just as quick to read the comm port as
you suggest. Looks like I'll just have to roll up my sleaves.
This looks like a good starting point:
http://www.embeddedlinuxinterfacing.com/chapters/06/
Thanks for you help in getting my ideas straight.
/jacques.
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/
|