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]

RE: DSRs and scheduling thread-context work


Hi Sergei,

By the driver API, I mean the set of functions whose names are prefixed with 'cyg_drv_*'. It seems quite minimal, and not enough for a serious driver. It seems to me, an eCOS newbie, that a real driver for a random piece of hardware probably has to use some of the functions from other eCOS packages, which defeats any modularity or isolation benefits one might have from having a designated set of functions ('cyg_drv_*') for use by drivers. But maybe I am misunderstanding something.

I agree that from an application's point of view, the 'cyg_io_*' functions are OK. I was wondering how our existing client API of 30 or so functions (each with several parameters) that we have on other platforms could fit neatly into the paradigm presented by the 'cyg_io_*' functions. Are saying it is reasonable to invent my own functions where 'cyg_io_*' is not sufficient, and not worry about trying to funnel all of those API calls (with several arguments each) through 'cyg_io_*' ?

Anyway, I think I do not need to take up any more of your time (for the moment :) ). Thanks for the answers. I have a better idea about the philosophy of eCOS now.

best regards
Tomas

-----Original Message-----
From: Sergei Gavrikov [mailto:sergei.gavrikov@gmail.com] 
Sent: 28 October 2010 20:09
To: Tomas Whitlock
Cc: eCos Discuss
Subject: RE: [ECOS] DSRs and scheduling thread-context work

On Thu, 28 Oct 2010, Tomas Whitlock wrote:
> Hi Sergei,
> 
> Apologies for not replying for a few days. Thank you for your reply, 
> particularly for the information about ISRs.
> 
> Do you mean that a general mechanism (i.e. not tied to ISRs) for 
> scheduling thread-context work is planned for a future release, and 
> will be part of the driver API?

Hi

I'm afraid I do not understand why this issue has arisen. In my opinion eCos has neat and complete driver API. Well, perhaps, I misunderstood the question.

> I had read most of the documentation that you pointed to. One thing 
> that is not explained by the docs or source code (as far as I could
> tell) is what eCOS functions drivers are supposed to use. Are they 
> supposed to restrict themselves to just the driver API as described in 
> chapter 13? Or are they supposed to use the driver API plus any other 
> eCOS functions as necessary (e.g. for starting a worker thread)?

I would rather recalled chapter 11 from 5th section: V. I/O Package (Device Drivers), those cyg_io_* API. Be sure that the set of functions for a driver is not limited by cyg_io_ "namespace".

Regarding the driver's thread (if I understand the question). A driver can call own service thread on its start. Wait a minute... well that's here, for example: devs/kbd/arm/aaed2000/current/src/aaed2000_kbd.c.

Generally speaking, I would not refer to specific chapter of the documentation. I would say, at first, read all the documentation, well, at least across and you begin understand how to implement own driver.
Because, the eCos watchdog driver is not similar to the eCos serial driver and so on.  But keep it simple, do not develop /dev/ledX device driver, if you can manage the LEDs directly.

IMO, driver for mesuaring temperature and voltage is a good example of how to develop a specific driver on top of generic eCos I/O driver. Of course, that interface to the driver can not complete a set of the
cyg_io_* fuctions (though this is a good start and in common cases that's enough), for higher-level aplications it can be SNMP interface to the its OID values, but nevertheless, the interface must be implemented on top of the eCos I/O driver model. In short, after reading the documentation it would be good then look at the different approaches and implementations of the eCos drivers under eCos packages directory (see
sources: io/* and devs/*).

Sergei

> thanks
> Tomas
> 
> -----Original Message-----
> From: Sergei Gavrikov [mailto:sergei.gavrikov@gmail.com]
> Sent: Fri 10/22/2010 21:03
> To: Tomas Whitlock
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] DSRs and scheduling thread-context work
> 
> On Fri, 22 Oct 2010, Tomas Whitlock wrote:
> > Dear all,
> >
> > I have been tasked with porting a driver for a PCI device from 
> > VxWorks / Linux to eCOS 3.0. While most things look reasonably 
> > straight-forward, I have a few queries relating to how a driver can 
> > schedule work to be done in a thread context.
> 
> Hi Tomas,
> 
> Only in brief
> 
> > The ISR of this driver must handle interrupts that originate from 
> > several distinct sources inside the device being controlled. These 
> > sources are in reality DMA channels that can run independently of 
> > one another, but share the same physical interrupt pin for 
> > signalling completion of DMA. I'd like to be sure that my proposed 
> > interrupt handling scheme won't lose interrupts.
> >
> > First:
> >
> > Will the following logic work?
> >
> > ISR:
> > 1. Read interrupt status register in device to sample what interrupt 
> > sources are currently active. If nothing active, call 
> > cyg_drv_interrupt_acknowledge and return 0.
> > 2. For each active interrupt source set an "active flag" somewhere 
> > in the device context structure (for use in the DSR).
> > 3. Write to the device's interrupt status register to clear the 
> > interrupt sources that we sampled in step 1.
> > 4. Acknowledge the hardware interrupt using 
> > cyg_drv_interrupt_acknowledge.
> > 5. Return CYG_ISR_HANDLED | CYG_ISR_CALL_DSR.
> >
> > DSR:
> > 1. If active flag 0 is set,
> >???? clear active flag 0
> >???? do any necessary processing
> > 2. If active flag 1 is set,
> >???? clear active flag 1
> >???? do any necessary processing
> > 3. ... other sources ...
> > n. Return.
> >
> > (assume that by design of the driver and hardware, an active flag 
> > can never transition to "set" while the corresponding DSR processing 
> > is
> > happening)
> >
> > Now my question is: suppose the DSR is executing any of steps 2 to 
> > n-1, interrupt source 0 becomes active and the ISR runs to 
> > completion. Is the DSR guaranteed to be rescheduled even though it is still executing?
> >
> > If the answer is 'yes' then everything should be fine.
> 
> - Yes
> 
> Of course, if that won't be some king of ISR storm, although DSRs have 
> been planned (=pended) at the least.
> 
> See, please,
> 
> ?? http://ecos.sourceware.org/docs-latest/ref/kernel-overview.html
> 
> Sections:
> 
> ?? * Threads and Interrupt Handling
> ?? * Calling Contexts
> 
> > If the answer is 'no', then it seems that even masking the hardware 
> > interrupt in the ISR and unmasking it right at the end of the DSR 
> > isn't 100% guaranteed to work correctly...
> >
> > Alternatively, maybe I could create multiple interrupt objects using 
> > the same vector / priority parameters, so that we have one ISR and 
> > one DSR for each interrupt source in the device. That seems like an 
> > odd way to do things, though. Is it legal?
> >
> > Second:
> >
> > I'm a bit confused about the need for cyg_drv_interrupt_acknowledge. 
> > If my ISR is called as part of a chain of ISRs because our interrupt 
> > vector is shared by other devices, shouldn't whoever traverses the chain (i.e.
> > not me) call cyg_drv_interrupt_acknowledge? If everyone in the chain 
> > including me calls it, then the interrupt gets acknowledged multiple 
> > times, which may be a bad thing. Or is cyg_drv_interrupt_acknowledge 
> > smart enough to be a no-op in that situation?
> 
> This depends on the implementation details in a HAL as the 
> driver's/kernel's interrupt acknowledge functions in fact call 
> HAL_INTERRUPT_ACKNOWLEDGE macro.
> 
> ?? hal/common/v3_0/src/drv_api.c:
> ?? externC void cyg_drv_interrupt_acknowledge
> 
> ?? kernel/v3_0/src/intr/intr.cxx:
> ?? Cyg_Interrupt::acknowledge_interrupt
> 
> > Third:
> 
> > It's quite common that a driver has to perform some periodic work in 
> > a thread context, much like a DSR function. In our case, we want to 
> > read a hardware monitoring chip periodically, to get temperatures 
> > and voltages etc.
> >
> > It looks like there has been some effort to "wall off" drivers from 
> > everything else with their own API, as can be seen from the 
> > cyg_drv_* functions. However, that API doesn't seem to have 
> > generalised timer and work-scheduling functionality. So a driver has 
> > to use non-cyg_drv_* functions. For example, the driver could call 
> > cyg_thread_create to create a worker thread and have that thread wait on something in a loop.
> >
> > If one were coming from Linux or Windows land, one might argue that 
> > it's a job for a user-mode daemon that periodically makes a special 
> > call to the driver, but that adds the complexity of having to create 
> > a special user-mode interface.
> 
> From eCos islet that is a job for an eCos thread.
> 
> > I guess I'm wondering why there is this set of cyg_drv_* functions 
> > that seem to be insufficient for nontrivial drivers. Are there some 
> > guidelines on what non-cyg_drv_* functions a driver can/should use? 
> > Is this API going to be expanded in the future? In any case, the 
> > distinction between a "driver" and any other eCOS module seems a bit 
> > artificial to me...
> 
> I hope you will find answers here as well:
> 
> ?? http://ecos.sourceware.org/docs-latest/ref/kernel-overview.html
> 
> ?? * Calling Contexts
> 
> and here (eCos driver "Big picture"):
> 
> ??
> http://ecos.sourceware.org/docs-latest/ref/devapi-device-driver-interf
> ace-t
> o-the-kernel.html
> 
> ?? * Synchronization Levels
> 
> I hope my "come-off" will help a bit.
> 
> Sergei
> 
> > Thanks in advance for any answers / advice Tom
> 
> This message has been delivered to Alpha Data by MessageLabs Virus 
> Scanning Service.
> 
> 
>

This message has been delivered to Alpha Data by MessageLabs Virus Scanning Service.

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