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]

Using a RedBoot USB driver also in eCos applications


Hello,

we are using eCos/RedBoot on our own built PowerPC 5200 platform quite a time. 
It is equipped with a PLX NET 2272 USB2.0 Chip for USB communication.

For the PLX NET 2272 we are using a third party driver from PLX Technology.
Currently we have added USB download support to the RedBoot 'load' command
simply by adding the USB driver source code files including our USB enumeration
configuration to RedBoot.
I know thats quite a dirty hack but it workes fine for us.

Now we have the challenge to replace the whole RS232 console interface by USB
since the acceptance for RS232 is very low within our customers.
The goal we want to reach is that RedBoot and our "real" application
communicates only over one USB interface.
We think about to put all the Low-Level USB driver source code into a package
in packages/services.
Then initialize the USB driver (using polling mode)
in the very beginning of RedBoot to switch the
console/debug output with CYGACC_CALL_IF_SET_CONSOLE_COMM and
CYGACC_CALL_IF_SET_DEBUG_COMM to the USB driver.
With that all I/O with diag_* is routed to USB (I think that is no problem
since I built something similar with a PCI interface on an other hardware
platform).
We are also thinking about to use a generic USB serial driver for CONSOLE and
DEBUG COMM channel to have the benefit of using any available terminal 
program like minicom or TeraTerm without additional coding effort on the host
side.

But in addition to that our application (which is loaded and started within
Redboot) should simply register some more USB pipes to communicate also with
the host.
Here the problem is that the application cant initialize the USB driver again
since the pipes used by RedBoot for CONSOLE_COMM and DEBUG_COMM would be
deleted.

So we tought about to let the application access the USB driver (which allready
runs in context of RedBoot) only over virtual vector calls to registrate some
more pipes and do all the send/receive functionality over that. The application
should also switch the USB driver to interrupt mode for normal operation.

Use case Summary:
=================
1) Our board is connected only over USB interface to the host.
2) RedBoot can be controlled normaly via RedBoot prompt to download and start
   an application (like it works currently on the RS232 interface).
3) If the application is started it will accesses the USB driver via virtual
   vector calls to registrates some more pipes and do all the communication.

Do you think this will be the right approach?


Freundliche Grüße / Best regards
Martin Schachinger
 
--
Dipl.-Ing.(FH) Martin Schachinger, Senior Software Engineer, Product Development Bus Tools EB - Discover the Experience
Phone: +43 (1) 59983-64, mailto:martin.schachinger@elektrobit.com
Fax: +43 (1) 59983-18, http://www.elektrobit.com

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

-- 
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]