next topic »

[Reply #15 on:]

I don't see a real advantage of the slotted delays over what is done with Arduino now.

I don't see slotted delays replacing millis() in Wiring language. I don't even know how to implement it in Wiring as a library, as it needs the array size specified by the user in a header of a library. But in a C language has his advantages over millis(). For every millis() timer (delay), you need a 32bit variable... if, lets say, we use 10 non-blocking delays (well, I don't see how that is needed in a real application but lets pretend that we need them), millis() is using even more Flash and RAM than slotted delays. Even more, at every check, you need to do a subtraction operation. In Wiring language it does not matter too much - at least, not for me, as I use it only for rapid prototyping. But in the industrial and commercial world it matters (but only if you need to move forward).

[Reply #16 on:]

I already saw how slotted timers can work on Arduino and I don't need any library! But... I think the cleanest way would be to modify the Arduino millis() code which gives an opportunity to clean that up a bit --- there was a thread about that earlier this year.

For short intervals I can use unsigned int or byte (unsigned 8 bit) variables instead of unsigned long with either method. But if you want to time longer than 65.535 seconds then you will need 32 bit unsigned or a 16-bit and an 8-bit and more convoluted code.

And there is a small savings in cycles using the slotted method that has the down side of requiring an interrupt that may run longer than I would like and can be delayed by serial print. Consider that in addition to decrementing slot counters there needs to be a zero check first as you don't want a counter to roll back, do you?

When I wrote that I don't think there will be much savings, I did a bit of thinking first.

[Reply #17 on:]

...
And there is a small savings in cycles using the slotted method that has the down side of requiring an interrupt that may run longer than I would like and can be delayed by serial print.

Yeah, it may be practical for a small number of delays...

Consider that in addition to decrementing slot counters there needs to be a zero check first as you don't want a counter to roll back, do you?

Not needed, look at the type of array and at the logic.

[Reply #18 on:]

...
And there is a small savings in cycles using the slotted method that has the down side of requiring an interrupt that may run longer than I would like and can be delayed by serial print.

Yeah, it may be practical for a small number of delays...

I have nothing against the slotted method. I just don't see any significant advantage over using count-up (what's behind the BWD method) by using count-down (what's behind the slotted method) when I take -everything- required into account.

Consider that in addition to decrementing slot counters there needs to be a zero check first as you don't want a counter to roll back, do you?

Not needed, look at the type of array and at the logic.

Then you trade off speed for measurable duration, in this case you halve the maximum interval to 32.767 seconds. For a whole lot of things that is acceptable and you can go to 32 bit signed values and get a bit less than 24 days if need be.

Both ways have applications where they fit better so IMO it's good to know both.

The slotted method is an array-adapted version of single-timer ISR timer solutions I have seen here already so if I don't act like it's big news then please forgive me.

[Reply #19 on:]

...
Both ways have applications where they fit better so IMO it's good to know both.

The slotted method is an array-adapted version of single-timer ISR timer solutions I have seen here already so if I don't act like it's big news then please forgive me.

Perfectly agree with you. I didn't presented like a big news, just the joy of a personal accomplishment and, somehow is a "gypsy wagon" thing: you carry with you your own tools and knowledge to the new territories. Thanks for the discussion, code snippet and technical details! 

[Reply #20 on:]

Hey, bring more what you got and please as you see better fits share those. I do see places that count-down could shave cycles and make a tight loop() even tighter. It could mean running a check at higher frequency but TBH (to be honest) there are competing methods for getting to the same extremes though the code for those is often hard to follow, not like slotted timeouts could be.

I use snippets where logic is more clear than English, and saves typing. It's not always so easy to separate a principle from the mass of detail that many projects require and we don't all have time to do that just for a minor point in a discussion.

One thing I noticed in your first code in this thread is the amount of optimized AVR code that at least some struck me as where it's not needed. I gathered, perhaps incorrectly, that you did that from not knowing what Arduino has brought to the table in the way of simplifying. But the simplify has general use safeguards that are not optimal (sometimes add whole microseconds) so perhaps knowing what you know, you kick the mud off your shoes as it were. I would too    but I'm too old to learn all that for just hobbying.