On Mar 20, 3:35 pm, "Ivanna Pee" <f...@Infectedmail.com> wrote:
> But, the exisiting design has an event queue. I do not understand why
> for such a simple system. The ISRs log the events, the main operating
> loop queues the events to itself, and then deques and makes calls into
> the appropriate sub-state machine. I want to lobby to get rid of this
> queue because the system really cannot process more than one event at
> a time anyway, and the events are so spread out over time.
>
>
> I guess what I am looking for is some documented ammunition for my
> superiors and co-workers that states when use of queue is desirable
> and when it is overkill.  Any good books journals out there?

Having a queue between two asynchronous processes (in this case the
interrupt and your main loop) is always a good idea.
The system may be very simple and not really needing that, but in the
future it may evolve to a more complex one and you will not have to
worry about queueing events.
It is much safer to have that queue. Unless you have some immediate
advantage from taking it off (like reducing the cost or solving speed
issues), leave it there.

On Tue, 20 Mar 2007 17:30:14 -0500, Robert Adsett
<sub2@aeolusdevelopment.com> wrote:

>In article <1174422914.998046.43230@n76g2000hsh.googlegroups.com>, 
>Ivanna Pee says...
>> But, the exisiting design has an event queue. I do not understand why
>> for such a simple system. The ISRs log the events, the main operating
>> loop queues the events to itself, and then deques and makes calls into
>> the appropriate sub-state machine. I want to lobby to get rid of this
>> queue because the system really cannot process more than one event at
>> a time anyway, and the events are so spread out over time.
>> 
>> I contend that the single threaded application should be permitted to
>> run as far as it can before needed an event, at which point it could
>> simply go into low power mode and wait for an event that concerns it
>> to wake the system. The ISR could log what the event was, if pertinent
>> for that state, and wake the processor to handle it.
>> 
>> Now I have tried this arguement with co-workers already; of course I
>> am new here and this is their baby, and everyone is resistent to
>> change. Removal of the queue would significantly simplify the already
>> simple system. Even state changes, state changes not even caused by
>> events, are queued!
>
>Have I got this right, it's been a working product for 20 years and you 
>want to change it because it's generality offends your sensibilities?
>
>Robert

The way i see it. Thye have ported many times, but never really
refactored... That is saying something about the company.

HOWEVER, if it is simply legacy support for an old product, the who
really cares. Leave it alone. Why are you in the code? What are the
business reasons for you to be in the code.What are you trying to
acheive?

In article <1174422914.998046.43230@n76g2000hsh.googlegroups.com>, 
Ivanna Pee says...
> But, the exisiting design has an event queue. I do not understand why
> for such a simple system. The ISRs log the events, the main operating
> loop queues the events to itself, and then deques and makes calls into
> the appropriate sub-state machine. I want to lobby to get rid of this
> queue because the system really cannot process more than one event at
> a time anyway, and the events are so spread out over time.
> 
> I contend that the single threaded application should be permitted to
> run as far as it can before needed an event, at which point it could
> simply go into low power mode and wait for an event that concerns it
> to wake the system. The ISR could log what the event was, if pertinent
> for that state, and wake the processor to handle it.
> 
> Now I have tried this arguement with co-workers already; of course I
> am new here and this is their baby, and everyone is resistent to
> change. Removal of the queue would significantly simplify the already
> simple system. Even state changes, state changes not even caused by
> events, are queued!

Have I got this right, it's been a working product for 20 years and you 
want to change it because it's generality offends your sensibilities?

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

Hey group,
I recently started a new job where the target is a handheld device
with 3 buttons on it and a few other internal interrupts, occurring
maybe only every 125ms when it is in a real processing mode, with
little processing to do to service the interrupts.  The system runs on
a low power controller and goes to low power mode whenever possible.
It is implemented as a state machine, with a bunch of sub-states, so
it is really a single threaded application. This was initially
designed and implemented maybe 20 yrs ago, and ported over the years.

But, the exisiting design has an event queue. I do not understand why
for such a simple system. The ISRs log the events, the main operating
loop queues the events to itself, and then deques and makes calls into
the appropriate sub-state machine. I want to lobby to get rid of this
queue because the system really cannot process more than one event at
a time anyway, and the events are so spread out over time.

I contend that the single threaded application should be permitted to
run as far as it can before needed an event, at which point it could
simply go into low power mode and wait for an event that concerns it
to wake the system. The ISR could log what the event was, if pertinent
for that state, and wake the processor to handle it.

Now I have tried this arguement with co-workers already; of course I
am new here and this is their baby, and everyone is resistent to
change. Removal of the queue would significantly simplify the already
simple system. Even state changes, state changes not even caused by
events, are queued!

I guess what I am looking for is some documented ammunition for my
superiors and co-workers that states when use of queue is desirable
and when it is overkill.  Any good books journals out there?