This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
How do serial port device drivers interact with COMMS drivers?
- From: "Patrick Doyle" <wpd at delcomsys dot com>
- To: "eCos" <ecos-discuss at sourceware dot cygnus dot com>
- Date: Tue, 4 Dec 2001 13:08:26 -0500
- Subject: [ECOS] How do serial port device drivers interact with COMMS drivers?
As I am trying to increase my understanding and appreciation of eCos, I have
recently started to wonder about this. For the two cases I looked at (the
QUICC serial device drivers and the PC), it appears that there are no
mechanisms to avoid conflicts between using the serial port via the device
driver interface and using the serial port via the COMMS interface. Did I
miss something? If I open "/dev/ser1" and change the baud rate to, say
9600, won't that interfere terribly with my debugger session, which happens
to be using serial port 1 at 38,400 baud?
It occurs to me that this is not an issue because folks who use the serial
port device drivers do so because they happen to know exactly what is hooked
up to which serial port for a given embedded application. Therefore, they
would never write code that opened "/dev/ser1" because they know that that
is what they use for the debugger. Is this the case? Or, did I miss
something somewhere?
On a related note, it seems to me that a boot monitor (with the Virtual
Vector support enabled) will support two communication interfaces. One for
"console" I/O and one for "debug I/O" (such as a GDB style debugger). If I
wanted to use any other I/O interfaces, I should do so using the device
driver paradigm (which, presumably is interrupt driven and, therefore, more
friendly to multitasking). Is my understanding correct?
--wpd