* [ECOS] pid_serial driver @ 2000-02-18 10:11 Grant Edwards 2000-02-18 11:21 ` Grant Edwards 2000-03-07 8:20 ` Grant Edwards 0 siblings, 2 replies; 10+ messages in thread From: Grant Edwards @ 2000-02-18 10:11 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-18 10:11 [ECOS] pid_serial driver Grant Edwards @ 2000-02-18 11:21 ` Grant Edwards 2000-02-19 3:08 ` Jesper Skov 2000-03-07 8:20 ` Grant Edwards 1 sibling, 1 reply; 10+ messages in thread From: Grant Edwards @ 2000-02-18 11:21 UTC (permalink / raw) To: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-18 11:21 ` Grant Edwards @ 2000-02-19 3:08 ` Jesper Skov 2000-02-21 13:14 ` Grant Edwards 0 siblings, 1 reply; 10+ messages in thread From: Jesper Skov @ 2000-02-19 3:08 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-19 3:08 ` Jesper Skov @ 2000-02-21 13:14 ` Grant Edwards 2000-02-21 14:01 ` Gary Thomas 0 siblings, 1 reply; 10+ messages in thread From: Grant Edwards @ 2000-02-21 13:14 UTC (permalink / raw) To: Jesper Skov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-21 13:14 ` Grant Edwards @ 2000-02-21 14:01 ` Gary Thomas 2000-02-21 20:33 ` Grant Edwards 0 siblings, 1 reply; 10+ messages in thread From: Gary Thomas @ 2000-02-21 14:01 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss, Jesper Skov 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-21 14:01 ` Gary Thomas @ 2000-02-21 20:33 ` Grant Edwards 2000-02-22 4:55 ` Gary Thomas 0 siblings, 1 reply; 10+ messages in thread From: Grant Edwards @ 2000-02-21 20:33 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss, Jesper Skov > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-21 20:33 ` Grant Edwards @ 2000-02-22 4:55 ` Gary Thomas 0 siblings, 0 replies; 10+ messages in thread From: Gary Thomas @ 2000-02-22 4:55 UTC (permalink / raw) To: Grant Edwards; +Cc: Jesper Skov, ecos-discuss 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-02-18 10:11 [ECOS] pid_serial driver Grant Edwards 2000-02-18 11:21 ` Grant Edwards @ 2000-03-07 8:20 ` Grant Edwards 2000-03-07 9:07 ` Patrick O'Grady 1 sibling, 1 reply; 10+ messages in thread From: Grant Edwards @ 2000-03-07 8:20 UTC (permalink / raw) To: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-03-07 8:20 ` Grant Edwards @ 2000-03-07 9:07 ` Patrick O'Grady 2000-03-07 9:35 ` Grant Edwards 0 siblings, 1 reply; 10+ messages in thread From: Patrick O'Grady @ 2000-03-07 9:07 UTC (permalink / raw) To: ecos-discuss 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] pid_serial driver 2000-03-07 9:07 ` Patrick O'Grady @ 2000-03-07 9:35 ` Grant Edwards 0 siblings, 0 replies; 10+ messages in thread From: Grant Edwards @ 2000-03-07 9:35 UTC (permalink / raw) To: Patrick O'Grady; +Cc: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2000-03-07 9:35 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-02-18 10:11 [ECOS] pid_serial driver Grant Edwards 2000-02-18 11:21 ` Grant Edwards 2000-02-19 3:08 ` Jesper Skov 2000-02-21 13:14 ` Grant Edwards 2000-02-21 14:01 ` Gary Thomas 2000-02-21 20:33 ` Grant Edwards 2000-02-22 4:55 ` Gary Thomas 2000-03-07 8:20 ` Grant Edwards 2000-03-07 9:07 ` Patrick O'Grady 2000-03-07 9:35 ` Grant Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).