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: cyg_flag_setbits() question


Hi Nick,
>>
>> I've two quick questions:
>>
>> Is it save to call cyg_flag_setbits() from an IRQ or should i
>> better use a
>> DSR?

> So use a DSR.
>
>> Is there a save way to transmit information from IRQ to DSR? As far >> as i
>> know the DSR's are queue's, so i need to transmit maybe which was
>> the IRQ
>> cause of the IRQ to the DSR's.
>
> Later in the same page it says:
>
> void
> dsr_function(cyg_vector_t vector,
> cyg_ucount32 count,
> cyg_addrword_t data)
> {
> }
>
> vector is the source of the interrupts which caused the DSR to
> trigger.
>
> You can also use data as a pointer to an information block if you
> want.
>


Imagine i got two quick interrupts before dsr could be called. I know
it from windows wdm, where i can transmit a value from every interrupt
to the dpc routine. A pointer to a data array for both irq and dsr
wouldn't do it. So i could write some kind of list, but it would need
a protection like a spinlock or so. I'm not really happy with this....

And that is exactly how you should do it. Define a circular buffer and a couple of indexes and pass any data through that. Use cyg_drv_isr_lock() and cyg_drv_isr_unlock() to protect updates to the buffer and indexes. With a little care you could probably implement it without any locks at all -- at least on a non-SMP platform.

Note that if the ISR is called more than once before the DSR is
called, the DSR will still be called only once, but with a count
argument greater than 1. If all you need to do is to specify which of
a set of flag bits the DSR should set, then a single shared location
that the ISR ORs the bits into and which the DSR reads and clears is
really all that you need.

Oh, that's an inportant information. I'll surely find a good solution for all that.



eCos is an embedded operating system, not an elaborately featured desktop OS, and provides direct support only for the most common cases. In this case, most ISRs do not need to pass a value to the DSR, so it would be wasteful to over-complicate the implementation to provide this. The principle has always been that if the user needs a more complex mechanism than eCos provides, then he is at liberty to provide it himself.

No problem. The dsr count explains a lot. I really love the way eCos works, it's quite easy to handle, but you have to know how it works.


Bye...


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