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

Re: Serial driver for ARM s3c4510


On Freitag, 24. Oktober 2003 06:25, Jonathan Larmour wrote:
> Roland Caßebohm wrote:
> > On Mittwoch, 22. Oktober 2003 16:40, Bart Veer wrote:
> >>Regarding something like CYGPRI_SER_TEST_SER_DEV, that is really a
> >>characteristic of the testing infrastructure. Turn it into a booldata,
> >>disabled by default. For manual testing the user should decide
> >>explicitly which port(s) should be tested, enable the option and set
> >>the value. For automated testing the testing infrastructure should be
> >>smart enough to know which port(s) are actually connected to something
> >>that can handle serial tests and manipulate the appropriate
> >>configuration options.
>
> However this would be a regressive step in that current testing
> assumptions would stop working. Granted with the automated testing things
> can be munged, but right now one of the good things about eCos testing is
> that for manual testing users can run through the tests and check for
> failures. Right now, at least they'll get a test failure if a serial
> device is not configured correctly with ser_filter magic on the other end.
>
> Perhaps we need a something that has "requires { CYGPRI_SER_TEST_SER_DEV
> != 0 }", but that would mean having new clean configurations that don't
> work by default (or if an #ifndef in the test file itself, that doesn't
> compile by default). That's something we didn't want to do as a policy
> decision. The alternative would be the user not knowing that serial is not
> being testing, unless they look in the serial driver configuration each
> time they create a new configuration. If this principle was applied to all
> devices (not that they're tested much at present :-|), that would be a lot
> for a user to configure before they could even manage to do a proper test
> run.
>
> > ...
> > 
> > Maybe it is also possible to have this in the serial io package
> >
> > cdl_interface CYGINT_IO_SERIAL_TEST_DEV {
> >     display     "Serial testing device"
> > }
> >
> > and cdl_option CYGPRI_SER_TEST_SER_DEV implements it if enabled?
>
> I don't see an interface helps any. 

Sorry, I have a little bit switched the topic, I thought if the are two 
packages which could define the option CYGPRI_SER_TEST_SER_DEV the interface 
would help avoid conflicts, because both could be enabled.

> I imagine whatever solution is used
> for CYGPRI_SER_TEST_SER_DEV should also be used for
> CYGPRI_SER_TEST_TTY_DEV.

I agree.

But for now, to have a solution for me, I will make one platform specific 
serial driver package which will include the two drivers generic 16x5x and 
arm s3c4510. This package will only one time implement 
CYGINT_IO_SERIAL_TEST_DEV and related things. Doing like this the package 
behaves like all the other platforms. But I will left it as three cdl files 
to be more clear.

My directory structure will look like this:

aim711
aim711/current
aim711/current/cdl
aim711/current/cdl/ser_arm_aim711.cdl
aim711/current/cdl/ser_arm_aim711_16x5x.cdl
aim711/current/cdl/ser_arm_aim711_s3c4510.cdl
aim711/current/include/ser_arm_aim711_16x5x.inl
aim711/current/include/ser_arm_aim711_s3c4510.inl
aim711/current/ChangeLog

If there would be a semilar platform but with only one serial interface it 
must have its own platform specific serial driver package.

Do you think this would be good at the moment?

Roland
-- 

___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland Caßebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
Mail: roland.cassebohm@visionsystems.de
http://www.visionsystems.de
___________________________________________________


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