[ECOS] pid_serial driver

[ECOS] pid_serial driver

[Grant Edwards]

The pid_serial driver appears to be a generic 16c550 driver,
right?  Apart from the addresses of the UARTs being hard-wired
into the source code (grin) I don't see anyting that looks
specific to the PID board or even to the ARM processor.

I'm starting on a driver for the 16c850 (a '550 superset) with
the pid_serial driver as my starting point.  Is there any
reason I should tie this driver to a specific platform?
Assuming you can configure the interrupt-ID and the UART base
address, I don't see why a UART driver needs to be associated
with a particular platform.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] pid_serial driver

[Grant Edwards]

> I'm starting on a driver for the 16c850 (a '550 superset) with
> the pid_serial driver as my starting point.  

OK, I've got a preliminary driver, but can't figure out how to
get it compiled when I do a "make".  I've found lots of good
documentation on how to write a driver, but nothing on what to
do with the source file when you're done.

I've put the source file in packages/io/serial/current/src/arm,
and added arm/16850_serial.c to the EXTRAS_COMPILE list in
packages/io/serial/current/src/PKGconf.mak. Now a "make" tries
to add arm/io_serial_16850_serial.o to libextras.a, but that
object file is never generated.

Anybody have a spare clue?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] pid_serial driver

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> OK, I've got a preliminary driver, but can't figure out how to
Grant> get it compiled when I do a "make".  I've found lots of good
Grant> documentation on how to write a driver, but nothing on what to
Grant> do with the source file when you're done.

Grant> I've put the source file in packages/io/serial/current/src/arm,
Grant> and added arm/16850_serial.c to the EXTRAS_COMPILE list in
Grant> packages/io/serial/current/src/PKGconf.mak. Now a "make" tries
Grant> to add arm/io_serial_16850_serial.o to libextras.a, but that
Grant> object file is never generated.

That should be it. But the problem may be that you try to build from
an existing (old) build directory.  You'll need to run pkgconf again
to have it pick up the new entry. If you don't have any custom
configurations you should be able to just run pkgconf --force in the
existing build directory.

Jesper

Re: [ECOS] pid_serial driver

[Grant Edwards]

On Sat, Feb 19, 2000 at 11:44:19AM +0100, Jesper Skov wrote:
> >>>>> "Grant" == Grant Edwards <grante@visi.com> writes:
> 
> Grant> OK, I've got a preliminary driver, but can't figure out how to
> Grant> get it compiled when I do a "make".  I've found lots of good
> Grant> documentation on how to write a driver, but nothing on what to
> Grant> do with the source file when you're done.
> 
> Grant> I've put the source file in packages/io/serial/current/src/arm,
> Grant> and added arm/16850_serial.c to the EXTRAS_COMPILE list in
> Grant> packages/io/serial/current/src/PKGconf.mak. Now a "make" tries
> Grant> to add arm/io_serial_16850_serial.o to libextras.a, but that
> Grant> object file is never generated.
> 
> That should be it. But the problem may be that you try to build from
> an existing (old) build directory.  You'll need to run pkgconf again
> to have it pick up the new entry. 

Yup, did that. It still doesn't compile my new source file.

> If you don't have any custom configurations you should be able
> to just run pkgconf --force in the existing build directory.

I am using a custom platform called "mustang", if that makes a
difference.  I've created two new source files:

  packages/io/serial/current/src/arm/16c850_serial.h
  packages/io/serial/current/src/arm/16c850_serial.c

Then in packages/io/serial/current/src/PKGconf.mak, I added
lines: 

  ifdef CYGPKG_HAL_ARM_MUSTANG
  EXTRAS_COMPILE  += arm/16850_serial.c
  endif

When I do a "make" the new source file doesn't get compiled,
and the make fails when it tries to build libextras.a:

make[1]: Entering directory /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/io/serial/current/src'
arm-elf-ar rcs /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/install/lib/libextras.a arm/io_serial_16850_serial.o
arm-elf-ar: arm/io_serial_16850_serial.o: No such file or directory
make[1]: *** [/home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/install/lib/libextras.a(arm/io_serial_16850_serial.o)] Error 1
make[1]: Leaving directory /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/io/serial/current/src'
make: *** [/home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/install/lib/libextras.a] Error 2

One thing I've notices is that when I build the standard pidBE
plaform, there is a file:

  packages/ecos-pid/io/serial/current/src/makefile.deps

That doesn't get created for my custom platform.


FWIW, Here's the output from the configuration script:

Generating build tree.
Component repository is /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/..
Build tree is /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial
Install directory is /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/install
Architecture arm, platform mustang, startup ram.
Processing package hal/common/current
Processing package infra/current
Processing package kernel/current
Processing package compat/uitron/current
Processing package language/c/libc/current
Processing package language/c/libm/current
Processing package error/current
Processing package hal/arm/arch/current
Processing package hal/arm/mustang/current
Processing package io/common/current
Processing package io/serial/current
Processing package devs/wallclock/current
Processing package devs/watchdog/current
Generating install directory /home/grante/ecos.new/ecos.custom/packages/ecos-mustang-serial/install
Generating miscellaneous files.
Generating toplevel makefile.
Generating save file.
The Build tree is ready.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] pid_serial driver

[Gary Thomas]

On 21-Feb-00 Grant Edwards wrote:
> I am using a custom platform called "mustang", if that makes a
> difference.  I've created two new source files:
> 
>   packages/io/serial/current/src/arm/16c850_serial.h
>   packages/io/serial/current/src/arm/16c850_serial.c
> 
> Then in packages/io/serial/current/src/PKGconf.mak, I added
> lines: 
> 
>   ifdef CYGPKG_HAL_ARM_MUSTANG
>   EXTRAS_COMPILE  += arm/16850_serial.c
                       ???????????????????
                       arm/16c850_serial.c

Re: [ECOS] pid_serial driver

[Grant Edwards]

> On 21-Feb-00 Grant Edwards wrote:
> > I am using a custom platform called "mustang", if that makes a
> > difference.  I've created two new source files:
> > 
> >   packages/io/serial/current/src/arm/16c850_serial.h
> >   packages/io/serial/current/src/arm/16c850_serial.c
> > 
> > Then in packages/io/serial/current/src/PKGconf.mak, I added
> > lines: 
> > 
> >   ifdef CYGPKG_HAL_ARM_MUSTANG
> >   EXTRAS_COMPILE  += arm/16850_serial.c
>                        ???????????????????
>                        arm/16c850_serial.c

Doh!

I don't know how many times I've looked at that over the past couple
days and never noticed that.

Thanks.

-- 
Grant

Re: [ECOS] pid_serial driver

[Gary Thomas]

On 22-Feb-00 Grant Edwards wrote:
> 
>> On 21-Feb-00 Grant Edwards wrote:
>> > I am using a custom platform called "mustang", if that makes a
>> > difference.  I've created two new source files:
>> > 
>> >   packages/io/serial/current/src/arm/16c850_serial.h
>> >   packages/io/serial/current/src/arm/16c850_serial.c
>> > 
>> > Then in packages/io/serial/current/src/PKGconf.mak, I added
>> > lines: 
>> > 
>> >   ifdef CYGPKG_HAL_ARM_MUSTANG
>> >   EXTRAS_COMPILE  += arm/16850_serial.c
>>                        ???????????????????
>>                        arm/16c850_serial.c
> 
> Doh!
> 
> I don't know how many times I've looked at that over the past couple
> days and never noticed that.
> 

Those are the easiest sort of mistakes to make and sometimes the hardest
to find.  - Not to worry, we've _all_ made similar ones ourselves.

Good luck.  Let us know how you get on and if you have any other problems.

Re: [ECOS] pid_serial driver

[Grant Edwards]

> The pid_serial driver appears to be a generic 16c550 driver,
> right?  Apart from the addresses of the UARTs being hard-wired
> into the source code (grin) I don't see anyting that looks
> specific to the PID board or even to the ARM processor.

FYI,

I've noticed that the 16c550 driver (pid_serial_with_ints.c)
doesn't take advantage of the transmit FIFO.  For each Tx
interrupt it only writes a single byte to the UART.  IIRC, on
the '550 there's no read the Tx FIFO count or tell when the
FIFO is full.  You just have to "know" that when you get an
interrupt you can write 12 bytes.  (I think it's 12...)

With the '850, you can actually read the Tx FIFO count, and use
that instead of the transmitter holding register empty bit in
*_putc() to determine if there's room for another byte.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] pid_serial driver

[Patrick O'Grady]

When I was working on the 16550 drivers for the PC HAL, I started with the
AEB driver and was able to easily add in the FIFO logic.  There are a
couple of things I learned--there seems to be a rumor about how 16550
parts have bugs in the FIFOs but that 16550A devices work properly...  so
while noone really had a description of the symptoms, there were plenty of
code snippets which could detect which device you were talking to.  Since
y'all aren't working with PCs (which have completely unpredictable (and
always *cheap*) components) you may not have to worry about this...

Anyway, the driver isn't too tough:  It turns out that the driver
..._serial_putc function should return true if it's able to send the
character or false if it can't... the OS will call the function with
successive data until it returns false.  Since the '550 is kinda lame and
has neither a FIFO counter or FIFO full indicator, we have to keep a
counter to tell us when we can't store any more data.  I just added it
into the pc_serial_info structure, set it to zero when the transmitter
empty interrupt is received, and make sure that I do 16 ..._serial_putc
calls before returning false.  If the '550 did have a Tx FIFO full
indicator, we could save a bit of interrupt overhead by having the
receiver interrupt also top up the transmitter buffer when possible, but I
think that the interrupt response time is so short compared to the
character transmission time that the savings is really insignificant.

Anyway, this code is already done, so feel free to borrow as much as you
like... there's more information at
ftp://sourceware.cygnus.com/pub/ecos/contrib/hal/i386/hal-i386-pc-20000210.html .
Hope this helps!

-patrick


On Tue, 7 Mar 2000, Grant Edwards wrote:

> 
> > The pid_serial driver appears to be a generic 16c550 driver,
> > right?  Apart from the addresses of the UARTs being hard-wired
> > into the source code (grin) I don't see anyting that looks
> > specific to the PID board or even to the ARM processor.
> 
> FYI,
> 
> I've noticed that the 16c550 driver (pid_serial_with_ints.c)
> doesn't take advantage of the transmit FIFO.  For each Tx
> interrupt it only writes a single byte to the UART.  IIRC, on
> the '550 there's no read the Tx FIFO count or tell when the
> FIFO is full.  You just have to "know" that when you get an
> interrupt you can write 12 bytes.  (I think it's 12...)
> 
> With the '850, you can actually read the Tx FIFO count, and use
> that instead of the transmitter holding register empty bit in
> *_putc() to determine if there's room for another byte.
> 
> -- 
> Grant Edwards
> grante@visi.com
> 

Re: [ECOS] pid_serial driver

[Grant Edwards]

> Anyway, the driver isn't too tough:  It turns out that the driver
> ..._serial_putc function should return true if it's able to send the
> character or false if it can't... the OS will call the function with
> successive data until it returns false.  Since the '550 is kinda lame and
> has neither a FIFO counter or FIFO full indicator, we have to keep a
> counter to tell us when we can't store any more data.  

I'm working on an 850 driver at the moment, and they've kludged
in a way to read the FIFO counter, so serial_putc is pretty
straight forward.

> Anyway, this code is already done, so feel free to borrow as much as you
> like... there's more information at
> ftp://sourceware.cygnus.com/pub/ecos/contrib/hal/i386/hal-i386-pc-20000210.html .

Thanks

-- 
Grant Edwards
grante@visi.com