This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]