This is the mail archive of the 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]

Re: Generic 8250 serial diagnostics.

>>>>> "David" == David Vrabel <> writes:

    David> Bart Veer wrote:
    >> It should go into a new devs/serial/generic/16x5x-haldiag package.

That is some rather selective quoting, since what I actually wrote is:

  It should go into either the existing devs/serial/generic/16x5x,
  thus keeping all the 16x5x quirks in one package, or into a new
  devs/serial/generic/16x5x-haldiag package. I have a slight
  preference for the former but there may be too many existing CDL
  active_if constraints in the way.

    David> A few Qs:

    David> What should the parent of the new package be?

I think there are two main possibilities. The simplest would be to
just parent it under CYGPKG_HAL. Since currently it does not contain
any useful configuration options its location does not matter. An
alternative and probably better approach is to require every platform
that uses the shared 16x5x HAL diag routines to provide a
cdl_component CYGPKG_HAL_DIAG and parent under that. If the platform
provides other diagnostic channels, e.g. the PC's screen and keyboard,
those could also be parented under CYGPKG_HAL_DIAG.

Unfortunately there is no easy way to make this flexible. The parent
property takes the name of another configuration option rather than an
expression. If it was an expression then bits of the hierarchy could
move around as the configuration was modified, and that would require
non-trivial surgery to the graphical configtool. 

Ideally the 16x5x HAL diag component would provide more
configurability, e.g. allowing users to use only COM1 or only COM2 as
the diag channel, and perhaps the baud rate options would go there as
well. A platform HAL's CDL would only specify how many 16x5x UARTs are
available, and plf_io.h would define the base address, ISR vector, and
clock frequency. That may be too big a change at this point.

    David> Is there a better way of handling the
    David> interface that doesn't require you to create the interface
    David> in every package that wants to implement the interface?

If you are putting the code into a separate package I am not sure why
it is needed. If the target definition includes the package then there
must be one or more 16x5x UARTs suitable for HAL diagnostics. Why
define a separate interface which provides exactly the same


Bart Veer                       eCos Configuration Architect     The eCos and RedBoot experts
 Besuchen Sie uns vom 14.-16.02.06 auf der Embedded World 2006, Stand 11-222
 Visit us at Embedded World 2006, Nurnberg, Germany, 14-16 Feb, Stand 11-222

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