[ECOS] Is eCosPro a fork of eCos?

[ECOS] Is eCosPro a fork of eCos?

[Liam Knight]

Apologies for the wide distribution. Unfortunately the owner of the
eCos group on the social media website I belong to does not believe in
free speech and has censured my responses to the group. It appears
that if you express an opinion that differs to his, he would classify
it as off topic or abusive, as so moderate and censure it. Fortunately
we live in a world of free speech so I would appreciate that members
of this particular group on this list point the group to this email
which shoould get archived somewhere here:
http://ecos.sourceware.org/ml/ecos-discuss/2013-03/

As I am bringing in a new audience, some backgroup. The owner of the
group is John Dallaway, an eCos maintainer, and the group is closed to
anyone who works for eCosCentric (stand up now anyone else who was
refused entry to the group and be counted). John started a discussion
topic about eCosCentric and whether eCosPro is a fork of eCos, which
he maintains it is, and claims to have verified this with eCosCentric.
 He has also excluded members of eCosCentric from joining the group
because he maintains that the group is for discussion about eCos and
not eCosPro, and thereby insists that the members of eCosCentric are
unable to contribute to the group on topics regarding eCos.

Does anyone spot the first inconsistency? John maintains the group is
for discussion about eCos and not eCosPro, but yet starts a
conversation about eCosCentric and eCosPro. Further, he makes a number
of statements and claims, either inferred or direct, about both but
prohibits eCosCentric from being able to respond. In addition, the
moment somebody expresses an opinion that differs from his in support
of eCosCentric, he censors them.  China, North Korea, here I come...

So sadly I have to resort to media where free speech is allowed, which
is why I am making my response to him public and on this list. I
believe that other members of the list need to know the kind of person
he really is, as well as me of course (2x divorced, no kids, described
as volatile). The remainder of this email is directed towards John,
but intended for public scrutiny, comment and opinion.

John, first of all I do not take kindly to being bullied, threatened
or censured. I was brought up in England where we have something
called "free speech", which you do not appear to be familiar with.

From your response to me on the group you appear to be saying you have
excluded members of eCosCentric from membership of the group because
eCosCentric have forked eCos and because they have a business model
and marketing position that you disagree with. eCosCentric have been
firm supporters of the free version, contributing BSPs, functionality,
toolchains, fixes etc and are clearly still users of the eCos RTOS.
They continue to support it (by your own admission through advice-line
support) and contribute to it, as well as continue to market it along
with eCosPro as a commercial alternative. Given this, I don't believe
that having a commercial alternative that is based on eCos can have
any bearing on whether their members are entitled to join this group.

Whether eCosCentric have forked eCos or not may in dispute, but lets
say for argument's sake they have forked.  They are still users of the
eCos RTOS because surely at the point that eCosCentric forked eCos it
was still eCos?  If not, at what point did the eCos source code no
longer become eCos?  Does your definition of what the eCos RTOS is
move along with the tip of the CVS source tree, or is it the moment
you build on it without your work going into the main source tree? Or
is it the moment you start charging for your extensions or
implementation or the use of them? Or charging others to provide
commercial support?   Surely all this means their members are in a
position to contribute to the group, whatever narrow definition you
declare the eCos RTOS to be? Or does your definition of what entitles
someone someone to join the group conveniently move so that you can
exclude members of eCosCentric from it?

In addition, you are insinuating that the forking of eCos is a bad
thing. Why? I recently read in the British press that forking of a
free project is often seen as the highest form of flattery in the free
open source world. If it's a bad thing, why have your forked the eCos
configuration tool in your own product within Eclipse? Or does the
configuration tool that resides in the eCos CVS repository and the
libcdl technology on which the eCos runtime system depends for
compilation not come into your definition of what is or is not part of
the eCos RTOS?

You also have implied that eCosCentric have forked eCos because there
are alternative implementations of various things (HALs, packages,
etc) in both eCosPro and eCos. That implies that the features you
pointed out existed in eCos before eCosCentric developed their
implementation which is not the case for at least a couple of the
features. For example, their libstdc++ support was developed in 2003,
uSTL was only recently contributed.

I don't see that any addition to eCos that is not contributed to the
original project constitutes a fork. A fork implies a parting of ways
between eCosCentric and the other maintainers, yet eCosCentric are
still an active part of the eCos community and both contribute to and
support it. Also, you infer from your last response to me on the group
that you have spoken to eCosCentric and that they confirm your
position that eCosPro is a fork is correct. I too spoke with the CEO
of eCosCentric last night as your statement that you have discussed
eCosCentric's business model and market positioning made no sense to
me. While he would not be drawn on the apparent sour relationship
between eCosCentric and yourself, he did verify to me their position
which is considerably different from your inference. I can only assume
from both his refusal to be drawn further on you and your comments
that your departure from eCosCentric was not amicable. If this is
true, and that is the real reason for your exclusion of members of
eCosCentric from the group, I would find your behaviour unprofessional
and distasteful and question your impartiality as both owner of the
group and eCos maintainer, as well as your effectiveness as eCos
maintainer.

I am also personally very uncomfortable about making statements or
comments about any person or company without giving them recourse to
back up my comments, respond or defend their position. So while the
eCosCentric CEO has so far refused to comment on the dispute to me
personally, I hope that he now has a platform to refute or support
your claims and uses it!!!

IMHO this group is poorer without their input and eCos would be worse
off without their support and contributions.

From your definition and response of what entitles anyone to belong to
the group, I believe you would have to exclude EVERYONE in the group
who has:
  1) developed a product using eCos (one assumes they are making money
on their product), or
  2) modified or built on eCos and not had their modifications or
additions put into the main source tree, yourself included
  3) used eCosPro.

Or will your definition of what entitles anyone membership to the
group again simply morph into whatever argument you can use to exclude
members of eCosCentric from it?

My point is that members of eCosCentric are just as able to contribute
to the group just as any other user of the eCos RTOS, probably more so
given that they employ the original architect of eCos.

Which raises another question. This thread. By your own "standard" you
have stated the group is for users of the eCos RTOS. So why would you
start a thread or discussion about eCosPro? That contradicts your
argument as to what can and cannot be discussed in this group, unless
of course you are confused yourself as to what the eCos RTOS is. You
have after all prohibited members of eCosCentric from joining the
group and being able to put forward their own viewpoint on what
eCosPro is, or is not. Is it that they have a viewpoint that differs
from you that bothers you, in which case when can I expected to be
excluded from the group? I am silenced anyway now on the group, so all
I can do is listen. Thank goodness for free speech.

If you do choose to exclude me from the group, let it be known that I
am not nor have I ever been a user of eCosCentric's products, I just
don't care for your position on the exclusion of eCosCentric members
and definitely don't agree with your reasoning. This one-sidedness
smacks of someone who is attempting to discredit or undermine
eCosCentric, which is a bad thing. You should be encouraging
eCosCentric members to join this group and to contribute to it, not
exclude them from it. If anyone is attempting to fragment the eCos
marketplace, or force a fork (assuming it was a negative event), your
actions alone speaks volumes.

LK

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

[ECOS] Re: Is eCosPro a fork of eCos?

[John Dallaway]

Liam

On 28/03/13 14:40, Liam Knight wrote:

> Apologies for the wide distribution. Unfortunately the owner of the
> eCos group on the social media website I belong to does not believe in
> free speech and has censured my responses to the group. It appears
> that if you express an opinion that differs to his, he would classify
> it as off topic or abusive, as so moderate and censure it. Fortunately
> we live in a world of free speech so I would appreciate that members
> of this particular group on this list point the group to this email
> which shoould get archived somewhere here:
> http://ecos.sourceware.org/ml/ecos-discuss/2013-03/

You obviously feel very strongly about this. The discussion on LinkedIn
was veering off-topic and so I offered to call you and discuss. Many of
the things you are accusing me of are not correct. The LinkedIn forum is
indeed moderated. This is the first time I have ever considered it
appropriate to moderate a discussion.

For the record:

> John started a discussion topic about eCosCentric and whether eCosPro
> is a fork of eCos

In fact, I have responded to a direct question from you. I have not
mentioned forking at all!

> you appear to be saying you have excluded members of eCosCentric from
> membership of the group because eCosCentric have forked eCos

No, I am not saying that at all.

> Also, you infer from your last response to me on the group
> that you have spoken to eCosCentric and that they confirm your
> position that eCosPro is a fork is correct.

Liam, I cannot see how you can possibly infer that. I know for a fact,
that eCosCentric does not consider eCosPro to be a fork.

If you want to discuss whether eCosPro is a fork of eCos or not in a
public forum, go right ahead. But please don't put words into my mouth.

If you want to discuss why I think it is good to provide a networking
forum for professional users of the free and open source eCos RTOS,
let's arrange to talk.

John Dallaway

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

[ECOS] Re: Is eCosPro a fork of eCos?

[Liam Knight]

John,

> You obviously feel very strongly about this. The discussion on LinkedIn
> was veering off-topic and so I offered to call you and discuss. Many of
> the things you are accusing me of are not correct. The LinkedIn forum is
> indeed moderated. This is the first time I have ever considered it
> appropriate to moderate a discussion.

What gave it away that I feel so strongly about being censored:-)
There is little enough discussion in the forum and you should be
encouraging discussion, not censoring it.

I don't see how you can argue that my discussion was off topic. How
can you have a conversation about eCosPro without eCosCentric and
without giving them the opportunity to respond or explain their
position? It is their product and it was after all the topic you
started about eCosPro. Surely you have to give eCosCentric the right
to join? I simply put forward my viewpoint on why I thought this was
unfair, and was censored from providing a response to your comments.
As you guessed, that upset me greatly.


>
> For the record:
>
>> John started a discussion topic about eCosCentric and whether eCosPro
>> is a fork of eCos
>
> In fact, I have responded to a direct question from you. I have not
> mentioned forking at all!

No, I agree you did not say fork explicitly, but that is definitely
what ".. I would *not* describe the eCosPro RTOS as simply a superset
of the eCos RTOS with fixes. " implies. You don't have to say fork -
most people would infer fork from that comment.

You also make a number of statements regarding eCosPro and end with "I
have spoken with eCosCentric at length concerning their business model
and market positioning", thereby attributing the comments through
implication as theirs. Why else did you add that statement? If you
knew eCosCentric's position, why did you not follow up with it. If you
could not say or did not know, that statement is confusing and
misleading.


>
>> you appear to be saying you have excluded members of eCosCentric from
>> membership of the group because eCosCentric have forked eCos
>
> No, I am not saying that at all.
>
>> Also, you infer from your last response to me on the group
>> that you have spoken to eCosCentric and that they confirm your
>> position that eCosPro is a fork is correct.
>
> Liam, I cannot see how you can possibly infer that. I know for a fact,
> that eCosCentric does not consider eCosPro to be a fork.

Then why did you not say it then but say it now? Why did you mention
your discussion with eCosCentric at all if not to put forward their
response?


>
> If you want to discuss whether eCosPro is a fork of eCos or not in a
> public forum, go right ahead. But please don't put words into my mouth.

John, I was under the impression the Linked-In group was a public
forum when I joined. Not a closed one that excludes key members of the
eCos community that you have selectively excluded. You have the right
to respond and defend yourself publicly in this one, a right you have
denied eCosCentric in the Linked-In group.


>
> If you want to discuss why I think it is good to provide a networking
> forum for professional users of the free and open source eCos RTOS,

John, by your own inference above, and by your exclusion of
eCosCentric from the group, you are saying that members of eCosCentric
are not professional users of the free and open source RTOS. If they
are not users of the free and open source RTOS, and if eCosPro is not
a fork, then what are they?  What is eCosPro if not a superset?

I also now know through private email that you have members of your
group who are eCosPro users only. Why are they permitted membership
but not eCosCentric?


> let's arrange to talk.
We are talking now. Why do you want to exclude the other members of
this list or your group by taking this offline? Why would you want to
share your answers with me and not others?

I have one question I am particularly interested in knowing the answer
to, a question you have censored on the group and refused to answer
here as well. It is a question I am sure many of the group members
would also want to know: Why are members of eCosCentric excluded from
the group?

They have done a lot for the community in the past and I believe you
are treating them unfairly. Somebody has to stand up for them if they
will not stand up for themselves. You have a lot of questions to
answer in my opinion, not just a select few.

LK

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

[ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed?

[Randy]

Hi all,
eCos reference tells me that "In order to allow DSRs to run with interrupts enabled, the ISR for a particular interrupt source (or the hardware) must arrange that that interrupt will not recur until the DSR has completed." 
But why? If other interrupt could be enable when processing DSR, why is the same interrupt not  allowed?
Let's image what happened if it comes some interrupt(same interrupt source or not)  when it process DSR, 
1) re-enter "__default_interrupt_vsr ", save registers(context of interrupted DSR), increase cyg_scheduler_sched_lock, disable interrupt, call ISR
2) call interrupt_end which will post dsr into dsr-list, enable interrupt and call pending dsrs and then schedule..
Anything wrong for this work-flow?
Thanks for your advance..

Thanks a lot..
Best regards,
Randy

Re: [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed?

[Stanislav Meduna]

On 31.03.2013 10:10, Randy wrote:

> But why? If other interrupt could be enable when processing DSR, why
> is the same interrupt not allowed?

1) Other interrupt does not need to synchronize access to the hardware
and/or data structures shared between the ISR and corresponding DSR.
Remember, neither the ISR nor DSR can block. Disabling interrupts
outside of interrupt handlers is generally frowned upon.

2) The list of pending DSRs is now upper bounded. With the same
interrupt enabled it would become unbounded.

Regards
-- 
                                       Stano


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

Re: Re: [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed?

[Randy]

Hi Stano,
Thanks for your rapid response.
>On 31.03.2013 10:10, Randy wrote:
>
>> But why? If other interrupt could be enable when processing DSR, why
>> is the same interrupt not allowed?
>
>1) Other interrupt does not need to synchronize access to the hardware
>and/or data structures shared between the ISR and corresponding DSR.
That's right, it should be the reason why we don't allow the interrupt to recur during DSR.
>Remember, neither the ISR nor DSR can block. 
I know this rule, but I'd like to ask you why. 
I think that one DSR interrupted by other interrupt could continue to finish the remainder parts when it reschedule to current thread, then,
why wait-semaphore in DSR which cause to switch to another thread is prevented by scheduler? This maybe because scheduler is locked and it could not work, but why don't we enable this function in DSR?
>Disabling interrupts outside of interrupt handlers is generally frowned upon.
I don't see this, could you please make it more clearly?
>2) The list of pending DSRs is now upper bounded. With the same
>interrupt enabled it would become unbounded.
I'd like to know which case could cause a pending DSR? 
Does one DSR interrupted by other interrupt could become a pending DSR? No, right?
>Regards
>-- 
>                                       Stano
>
>
>-- 
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
Thanks a lot..
Best regards,
Randy

Re: [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed?

[Stanislav Meduna]

On 31.03.2013 16:50, Randy wrote:

>> Remember, neither the ISR nor DSR can block. 
> I know this rule, but I'd like to ask you why.

Well I cannot comment on design choices made by the eCos
developers, but generally:

- an ISR cannot block by definition. It is not a thread, it has
  no state (runnable / blocked / ...), it cannot be scheduled
  by the scheduler, it often gets special handling by the
  hardware itself, ... Its "scheduler" is the hardware, not
  the OS.

- a DSR is basically "the rest of the interrupt handler
  that can run later with interrupts enabled". It is not
  a thread either, it cannot be preempted, it has no
  priority, all pending DSRs are queued and serviced in
  a FIFO manner.

You can find some discussion in a 10 year old thread at
http://www.sourceware.org/ml/ecos-discuss/2003-01/msg00330.html

> I think that one DSR interrupted by other interrupt could continue to
> finish the remainder parts when it reschedule to current thread,
> then, why wait-semaphore in DSR which cause to switch to another
> thread is prevented by scheduler? This maybe because scheduler is
> locked and it could not work, but why don't we enable this function
> in DSR?

Becasue the DSR is not a thread. If you need it to be, you can make
the DSR minimal (just post an event to a normal thread) and do your
processing there. If the processing takes a considerable
amount of time, you should do that anyway. DSR is just a bridge
between the interrupt handler world and a thread world.

>> Disabling interrupts outside of interrupt handlers is generally frowned upon.
> I don't see this, could you please make it more clearly?

Generally in a real-time operating system achieving the best
possible interrupt latency and doing things deterministically
are the main goals, more important than the best possible
general performance. Disabling interrupts adds to the possible
worst-case latency. Having an unbounded number of anything
in some queue or waiting until a thread (possibly low-prio)
is done with some lock breaks determinism.

>> 2) The list of pending DSRs is now upper bounded. With the same
>> interrupt enabled it would become unbounded.
> I'd like to know which case could cause a pending DSR? 

There is a DSR queue. If your DSR could be preempted by the same
interrupt again, that ISR would possibly queue another DSR for
the same interrupt. And again and again.

Now the maximum number of DSRs in the queue basically equals
the number of possible interrupts.

> Does one DSR interrupted by other interrupt could become a pending DSR?
> No, right?

It queues the own DSR which gets processed after all already queued
DSRs. Then the originally interrupted DSR continues.

A real-time operation is not an easy task.

Regards
-- 
                                              Stano


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

Re: Re: [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed?

[Randy]

Hi Stano,
Thanks for your reponse.
I read some eCos code recently but I have one question now:
After one ISR is over, the DSRs in FIFO queue starts to run one by one like A=>B=>C=>...
If one interrupt comes when B is running, then what will happen?
If B is stoped and the new ISR is going to run, then, how and when does the B come back(we may cann't use "reschedule" to describe it)?
Or, could you tell me which code snippet in eCos3.0 shows the handler?
>On 31.03.2013 16:50, Randy wrote:
>
>>> Remember, neither the ISR nor DSR can block. 
>> I know this rule, but I'd like to ask you why.
>
>Well I cannot comment on design choices made by the eCos
>developers, but generally:
>
>- an ISR cannot block by definition. It is not a thread, it has
>  no state (runnable / blocked / ...), it cannot be scheduled
>  by the scheduler, it often gets special handling by the
>  hardware itself, ... Its "scheduler" is the hardware, not
>  the OS.
>
>- a DSR is basically "the rest of the interrupt handler
>  that can run later with interrupts enabled". It is not
>  a thread either, it cannot be preempted, it has no
>  priority, all pending DSRs are queued and serviced in
>  a FIFO manner.
Yes, I agree with you, if one thread holds the scheduler lock, then the DSR will be in FIFO queue and become a pending DSR..

>You can find some discussion in a 10 year old thread at
>http://www.sourceware.org/ml/ecos-discuss/2003-01/msg00330.html
Thanks ,the discussion is interesting..

>> I think that one DSR interrupted by other interrupt could continue to
>> finish the remainder parts when it reschedule to current thread,
>> then, why wait-semaphore in DSR which cause to switch to another
>> thread is prevented by scheduler? This maybe because scheduler is
>> locked and it could not work, but why don't we enable this function
>> in DSR?
>
>Becasue the DSR is not a thread. If you need it to be, you can make
>the DSR minimal (just post an event to a normal thread) and do your
>processing there. If the processing takes a considerable
>amount of time, you should do that anyway. DSR is just a bridge
>between the interrupt handler world and a thread world.
Now, I see the rule of interrupt handler is SIMPLE, so the handler should be NOT too complicate.
>>> Disabling interrupts outside of interrupt handlers is generally frowned upon.
>> I don't see this, could you please make it more clearly?
>
>Generally in a real-time operating system achieving the best
>possible interrupt latency and doing things deterministically
>are the main goals, more important than the best possible
>general performance. Disabling interrupts adds to the possible
>worst-case latency. Having an unbounded number of anything
>in some queue or waiting until a thread (possibly low-prio)
>is done with some lock breaks determinism.
>
>>> 2) The list of pending DSRs is now upper bounded. With the same
>>> interrupt enabled it would become unbounded.
>> I'd like to know which case could cause a pending DSR? 
>
>There is a DSR queue. If your DSR could be preempted by the same
>interrupt again, that ISR would possibly queue another DSR for
>the same interrupt. And again and again.
>
>Now the maximum number of DSRs in the queue basically equals
>the number of possible interrupts.
>
>> Does one DSR interrupted by other interrupt could become a pending DSR?
>> No, right?
>
>It queues the own DSR which gets processed after all already queued
>DSRs. Then the originally interrupted DSR continues.
>
>A real-time operation is not an easy task.
>
>Regards
>-- 
>                                              Stano
>
>
>-- 
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

Re: [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed?

[Stanislav Meduna]

On 07.04.2013 14:06, Randy wrote:

> After one ISR is over, the DSRs in FIFO queue starts to run one by
> one like A=>B=>C=>... If one interrupt comes when B is running, then
> what will happen? If B is stoped and the new ISR is going to run,
> then, how and when does the B come back(we may cann't use
> "reschedule" to describe it)?

The processor detects the interrupt, saves the current program
counter on the stack, looks up the table defining wich handler
is to be run for tha particular interupt source and runs the
handler.

When this handler returns, then whatever the handler interrupted
will continue where it was interrupted, in this case B.

The exact sequence of steps is hardware- and configuration-dependent,
the interrupt and exception handling is where the architectures
differ significantly.

> Or, could you tell me which code snippet in eCos3.0 shows the handler?

This is architecture specific partly assembler code. Look for
vectors.S and other files in your HAL, but you will only
understand it if you have quite detailed knowledge about your
processor. I never needed to go that deep.

Regards
-- 
                                         Stano


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

[ECOS] put unmask in ISR rather than DSR causing interrupt lost

[Randy]

Hi Stano & all,
>On 07.04.2013 14:06, Randy wrote:
>
>> After one ISR is over, the DSRs in FIFO queue starts to run one by
>> one like A=>B=>C=>... If one interrupt comes when B is running, then
>> what will happen?
>> If B is stoped and the new ISR is going to run,
>> then, how and when does the B come back(we may cann't use
>> "reschedule" to describe it)?
In fact, the problem I faced make me think about the interrupt model details like above.
The problem described as this mail title shows,
eCos require that we should unmask interrupt in DSR, but why would we lost any interrupt when I unmask in ISR rather than DSR?
Thanks for your advance..
>
>The processor detects the interrupt, saves the current program
>counter on the stack, looks up the table defining wich handler
>is to be run for tha particular interupt source and runs the
>handler.
>
>When this handler returns, then whatever the handler interrupted
>will continue where it was interrupted, in this case B.
>
>The exact sequence of steps is hardware- and configuration-dependent,
>the interrupt and exception handling is where the architectures
>differ significantly.
>
>> Or, could you tell me which code snippet in eCos3.0 shows the handler?
>
>This is architecture specific partly assembler code. Look for
>vectors.S and other files in your HAL, but you will only
>understand it if you have quite detailed knowledge about your
>processor. I never needed to go that deep.
>
>Regards
>-- 
>                                         Stano
>
>

回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost

[Randy]

Hi all,
sorry that I maybe not very clear to describe my problem..
>Hi Stano & all,
>>On 07.04.2013 14:06, Randy wrote:
>>
>>> After one ISR is over, the DSRs in FIFO queue starts to run one by
>>> one like A=>B=>C=>... If one interrupt comes when B is running, then
>>> what will happen?
>>> If B is stoped and the new ISR is going to run,
>>> then, how and when does the B come back(we may cann't use
>>> "reschedule" to describe it)?
In fact, the problem I faced make me think about the interrupt model details like above.
The problem described as this mail title shows,
eCos require that we should unmask interrupt in DSR, but why would we lost any interrupt when I unmask in ISR rather than DSR?
#######  losing interrupt here means that, sometimes DSR didn't run when I put unmask in ISR rather than DSR.
Thanks for your advance..
>>
>>The processor detects the interrupt, saves the current program
>>counter on the stack, looks up the table defining wich handler
>>is to be run for tha particular interupt source and runs the
>>handler.
>>
>>When this handler returns, then whatever the handler interrupted
>>will continue where it was interrupted, in this case B.
>>
>>The exact sequence of steps is hardware- and configuration-dependent,
>>the interrupt and exception handling is where the architectures
>>differ significantly.
>>
>>> Or, could you tell me which code snippet in eCos3.0 shows the handler?
>>
>>This is architecture specific partly assembler code. Look for
>>vectors.S and other files in your HAL, but you will only
>>understand it if you have quite detailed knowledge about your
>>processor. I never needed to go that deep.
>>
>>Regards
>>-- 
>>                                         Stano
>>
>>

回复: 回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost

[Randy]

Hi all,
I know what's wrong with my understanding..
If I unmask interrupt in ISR, it is possible that the same interrupt recurs just before the OS put its DSR in DSR FIFO_List, then when the ISR is over again, OS finds that the dsr_count is not zero, so it just do "dsr_count++". So, there is only one DSR in FIFO list but keeping dsr_count(>0) for this interrupt, if I don't care "count" parameter in DSR, it seems that I lose one interrupt.
--------------
Thanks a lot..
Best regards,
Randy
>Hi all,
>sorry that I maybe not very clear to describe my problem..
>>Hi Stano & all,
>>>On 07.04.2013 14:06, Randy wrote:
>>>
>>>> After one ISR is over, the DSRs in FIFO queue starts to run one by
>>>> one like A=>B=>C=>... If one interrupt comes when B is running, then
>>>> what will happen?
>>>> If B is stoped and the new ISR is going to run,
>>>> then, how and when does the B come back(we may cann't use
>>>> "reschedule" to describe it)?
>In fact, the problem I faced make me think about the interrupt model details like above.
>The problem described as this mail title shows,
>eCos require that we should unmask interrupt in DSR, but why would we lost any interrupt when I unmask in ISR rather than DSR?
>#######  losing interrupt here means that, sometimes DSR didn't run when I put unmask in ISR rather than DSR.
>Thanks for your advance..
>>>
>>>The processor detects the interrupt, saves the current program
>>>counter on the stack, looks up the table defining wich handler
>>>is to be run for tha particular interupt source and runs the
>>>handler.
>>>
>>>When this handler returns, then whatever the handler interrupted
>>>will continue where it was interrupted, in this case B.
>>>
>>>The exact sequence of steps is hardware- and configuration-dependent,
>>>the interrupt and exception handling is where the architectures
>>>differ significantly.
>>>
>>>> Or, could you tell me which code snippet in eCos3.0 shows the handler?
>>>
>>>This is architecture specific partly assembler code. Look for
>>>vectors.S and other files in your HAL, but you will only
>>>understand it if you have quite detailed knowledge about your
>>>processor. I never needed to go that deep.
>>>
>>>Regards
>>>-- 
>>>                                         Stano
>>>
>>>

[ECOS] why did not enable interrupt before call pending dsr while not use interrupt stack

[Randy]

Hi all,
I see that enable interrupt before call pending dsr while we use interrupt stack, but I don't find anywhere do the same thing if we don't use interrupt stack via MACRO:CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK
If we don't enable interrupt before calling pending dsr, then calling simple synchronization methods like cyg_semaphore_post() in DSR would cause problem since the methods will be scheduling..
Anything wrong with my understanding?

--------------
Thanks a lot..
Best regards,
Randy