[ECOS] Confusion on serial port usage

[ECOS] Confusion on serial port usage

[Mike Sweeney]

I have an ARM based port that I am working with and am using the
Generic 16X5X serial drivers. I am a little confused on diag_printf,
HAL_DIAG_WRITE_CHAR, and how the serial device driver routines all
play together. My board only has 1 serial port so everything has to
share 1 output. My question is, if I include the serial port drivers
(Generic 16X5X), should diag_printf() be using HAL_DIAG_WRITE_CHAR()
or should it be transmitting characters via the serial port driver?

In my configuration diag_printf() is transmitting characters via
HAL_DIAG_WRITE_CHAR() through the virtual vector table. I have my
configuration set so that eCos claims the virtual vector table and
there are no monitor services used. Can someone help me straighten
this out?

Thanks.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Confusion on serial port usage

[Gary Thomas]

Mike Sweeney wrote:
> I have an ARM based port that I am working with and am using the
> Generic 16X5X serial drivers. I am a little confused on diag_printf,
> HAL_DIAG_WRITE_CHAR, and how the serial device driver routines all
> play together. My board only has 1 serial port so everything has to
> share 1 output. My question is, if I include the serial port drivers
> (Generic 16X5X), should diag_printf() be using HAL_DIAG_WRITE_CHAR()
> or should it be transmitting characters via the serial port driver?

The diagnostic routines (e.g. diag_printf()) always use HAL_DIAG_WRITE_CHAR
Your interrupt driven serial driver should play nice with this - we've
taken care to make it work properly on "supported" platforms.

> In my configuration diag_printf() is transmitting characters via
> HAL_DIAG_WRITE_CHAR() through the virtual vector table. I have my
> configuration set so that eCos claims the virtual vector table and
> there are no monitor services used. Can someone help me straighten
> this out?

This shouldn't be necessary if you have a working RedBoot.

As mentioned, this should "just work".  If it doesn't, maybe
we can help if you describe the failures/difficulties in detail.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Confusion on serial port usage

[Mike Sweeney]

On 8/6/07, Gary Thomas <gary@mlbassoc.com> wrote:
> Mike Sweeney wrote:
> > I have an ARM based port that I am working with and am using the
> > Generic 16X5X serial drivers. I am a little confused on diag_printf,
> > HAL_DIAG_WRITE_CHAR, and how the serial device driver routines all
> > play together. My board only has 1 serial port so everything has to
> > share 1 output. My question is, if I include the serial port drivers
> > (Generic 16X5X), should diag_printf() be using HAL_DIAG_WRITE_CHAR()
> > or should it be transmitting characters via the serial port driver?
>
> The diagnostic routines (e.g. diag_printf()) always use HAL_DIAG_WRITE_CHAR
> Your interrupt driven serial driver should play nice with this - we've
> taken care to make it work properly on "supported" platforms.
>

I am using the NMI ue250 hardware template. As I was debugging I
realized what the problem was - I had to define the
CYGPRI_IO_SERIAL_GENERIC_16X5X_PLF_INIT_HOOK since the processor
apparently doesn't have a fully standard UART. I searched the
mailing-list and sure enough the platform I am using is what led to
the addition of this hook! Oddly enough the hook is not defined in the
serial driver code for my platform, but it's just a few lines anyways.

> > In my configuration diag_printf() is transmitting characters via
> > HAL_DIAG_WRITE_CHAR() through the virtual vector table. I have my
> > configuration set so that eCos claims the virtual vector table and
> > there are no monitor services used. Can someone help me straighten
> > this out?
>
> This shouldn't be necessary if you have a working RedBoot.
>
> As mentioned, this should "just work".  If it doesn't, maybe
> we can help if you describe the failures/difficulties in detail.
>

I am using my own bootloader and do not want eCos to interact with it
so that is why I am claiming the virtual vector table. Therefore, in
my case, the routines in my variant HAL are called for doing serial
I/O for diagnostics.

I am still slightly confused by the way the serial I/O is configured
because there are so many configuration options in the CDL scripts for
different packages that seem redundant, but I am sure they really
aren't redundant. There are baud rate options for the diagnostic port,
debug port, and then under the serial device driver component. If my
platform only has 1 serial port then it seems odd that I get to choose
the baud rate in 3 places.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss