This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: [Fwd: MBX Board]
- To: Jonathan Larmour <jlarmour at redhat dot co dot uk>
- Subject: Re: [ECOS] [Fwd: MBX Board]
- From: Jesper Skov <jskov at redhat dot com>
- Date: 03 Jun 2000 09:12:44 +0200
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <3937FF7A.71E349B7@redhat.co.uk>
>>>>> "amassa" == "amassa@cts.com" <amassa@cts.com> writes:
amassa> I see that there is SMC1 port support in the hal as well as
amassa> with the serial device drivers.
amassa> What is the difference between the two modules?
The one in the HAL is a minimal device driver, only supporting what's
necessary to run the GDB stubs.
The serial device driver is a more complete driver, allowing different
configurations and asynchronous operation (i.e., read/write buffers
with IO being interrupt driven).
amassa> Should both of these be enabled in the ecos configuration to
amassa> use the SMC?
No, disabling the HAL driver is not normally done (but is possible)
since it handles diagnostic output and GDB communication.
But the drivers have been written to share the SMC if they are both
enabled.
amassa> I want to implement a command parser, to interpret incoming
amassa> user commands from the SMC1 port.
amassa> How can I set this up to wake up my code when a complete
amassa> command comes in from the SMC1 port?
Well, I'd probably have the parser run in its own thread and have it
call blocking read() on the device, requesting the length of a command
to be read. As soon as that amount of data has been read, the call
will return and you can do the parsing. Use semaphores to communicate
commands to worker threads.
Jesper