This is the mail archive of the ecos-discuss@sourceware.org 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]

creating serial driver


Hello all,

I am having a x86 PC board with running redboot in
it.I have to add around 16 serial ports to my x86 PC
board using PCI bus. But as a rookie i am first trying
to make a driver for  a single port.So what i did, i
created a driver by using the generic driver of 16x5x.
But i didn't place it inside the ecos tree. I made it
as an application in which i used all those macros
DEVTAB_ENTRY, SERIAL_CHANNEL_USING_INTERRUPTS,
SERIAL_FUNS and then filled the api's with reference
to the pattern of 16x5x driver.

Then i made one more application to test this driver
using the ?ecos-2.0\examples\serial.c? (i replaced the
?/dev/haldiag? by ?/dev/FT_ser_drv?), FT_ser_drv is
the string name that i given to my driver.

Now how i am building my last output file (srec).
Actually i found this method in ecos discuss archives,
i am pasting that part here:

-------------------------------------

>Anyway, build your device driver library just like an
eCos
>application, but instead of linking it to eCos just
use ar to create a
>library from the object file. There is nothing
special needed, so just
>look at normal examples for building libraries.
>
>To link the libarary to the application and eCos just
add -lmylib to
>the command line when linking. ie nothing special or
magical needed.
>
>OK, now the thing to be careful of. When building a
device driver
>within the eCos tree there is normally a cdl option: 
>
>  compile       -library=libextras.a   foobar.c
>
>ie the object file is put into the library
libextras.a not the normal
>libtarget.a. At the end of the build process
libextras.a is linked to
>extras.o and this is then linked to your application,
not
>libextras.a. This is becasue the linker throws away
any symbols not
>referenced in libraries. Normally there is no
reference to a device
>driver because of the use of linker tables. So if the
device driver
>was inside a library it would not be pulled into the
final application
>executable. 
>
>For your device driver in your library you cannot use
the same
>trick. So instead your application must reference
something in the
>device driver so that it is pulled in. Typically a
device driver has a
>DEVTAB_ENTRY, eg
>
>DEVTAB_ENTRY(ebsa285_serial_io,
>            
CYGDAT_IO_SERIAL_ARM_EBSA285_SERIAL_NAME,
>             0,                     // Does not
depend on a lower level interface
>             &cyg_io_serial_devio,
>             ebsa285_serial_init,
>             ebsa285_serial_lookup,     // Serial
driver may need initializing
>             &ebsa285_serial_channel
>    );
>
>Doing something like:
>
>  extern cyg_devtab_entry_t *ebsa285_serial_io;
>  ebsa285_serial_io = ebsa285_serial_io;
>
>will probably be enought.
-----------------------------------------------


in my case i am using ?FT_ser_ent? in place of
?ebsa285_serial_io? & FT_SER_DRV_NAME in place of
CYGDAT_IO_SERIAL_ARM_EBSA285_SERIAL_NAME.

Where as FT_SER_DRV_NAME is defined as:

#define FT_SER_DRV_NAME	"\"/dev/FT_ser_drv\""



and also i have added this in my application file  :
------------------------------------------
 extern cyg_devtab_entry_t *FT_ser_ent
 FT_ser_ent = FT_ser_ent;
------------------------------------------

then i made my make file in the above defined method
(the driver file name is ?serial.c? and application
file name is ?serial_app.c?):

------------------------------------------------
serial_app.srec: serial_app

i386-elf-objcopy -O srec serial_app serial_app.srec


serial_app: serial_app.o
$(CC) -c -o ../drv/serial.o $(CFLAGS) ../drv/serial.c
	i386-elf-ar -crv ../drv/libserial.a ../drv/serial.o
	$(LD) $(LDFLAGS) -o serial_app serial_app.o $(LIBS)
-L../drv -lserial 


serial_app.o: serial_app.c
	
$(CC) -c -o serial_app.o $(CFLAGS) serial_app.c 

--------------------------------------------
but while make i was getting this message in cygwin:

-------------------------------------------------


serial_app.c:80: warning: type defaults to `int' in
declaration of `FT_ser_ent'
serial_app.c:80: conflicting types for `FT_ser_ent'
serial_app.c:79: previous declaration of `FT_ser_ent'
serial_app.c:80: initializer element is not constant
serial_app.c:80: warning: data definition has no type
or storage class
make: *** [serial_app.o] Error 1

-------------------------------------------------

then to come out of this error i commented the
statement: ?FT_ser_ent = FT_ser_ent;?.

After that my file compiled and i got
?serial_app.srec?. Then i loaded it into the x86 board
using redboot through tftp. But on 'go' command  it
didn't get the expected output (message on
hyperterminal). Here in my driver i have given the
base address ?0x3F8? (com1), its like i am using a
driver to control the com1.

I am having one doubt, while creating the entry of my
driver using DEVTAB_ENTRY, i have to give a "C" string
name for the device. And there i am giving
?FT_SER_DRV_NAME? which is equal to
"\"/dev/FT_ser_drv\"". Where as this label is normally
defined in CDL script of any driver in ecos tree, i am
defining it seperatly in my driver code. So the way
which i am using to define this label is correct?,
another doubt as there is already an in built driver
for com1 in ecos tree, will it effect to any other
driver who wish to use the same com port for his
purpose? 

Please give suggestions.

Regards,
VENKAT



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


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