TICKS_PER_SECOND not behaving

[rhopf1]

MOD5282, NBEclipse release 2.5.3
Changed TICKS_PER_SECOND from 20 to 50 to speed up command processing.
Rebuilt All System Files then project files. Library files used in the link MOD5282.a and NetBurner.a show the current date as build.

Delay times stayed at 50msec tick instead of desired 20msec!?

Changed this back in 2.4.2 release without any problem, not sure what I missed.

[pbreed]

This is used in nburn\mod5282\system\bsp.c...
So unless the nburn\mod5282\system directory gets rebuilt it won't make any difference...

The ticks does not change the task switching time, only the granularity of timeout intervals...
Tasks switch when they should much much faster than the tick rate....

[rhopf1]

1. I changed TICKS_PER_SECOND in nburn\include\constants.h and MOD5282's bsp.c should have been rebuilt with the system files. MOD5282.a had today's date after build.
2. Don't care about task switch time BUT have lots of short brief fast commands from various sources and waiting OSTimeDly(1) between commands can be significant. Rather execute every 20msec than 50msec. To put another way processing 200 commands at 50msec is 10 seconds, along long pause for a user, versus 4 seconds, an almost tolerable delay.
3. Rechecked my 2.4.2 builds and that build does change to 20msec ticks.

[tod]

This is not an answer to your question but a suggestion that you might want to rethink your approach to the problem. I don't know enough about exactly what you're trying to achieve (or your level of experience) but my preferred approach is to have my Main task pend on a mailbox. Other tasks handle incoming requests (the most common is a TCP Listener task - but there can be multiple tasks listening for multiple inputs). Typically all the listening tasks are interrupt driven or pend waiting for input in non-blocking ways. Many of the OS pending waits have timeouts so if you want to do some housekeeping every so many ticks you can without blocking. Then when any of them get data they post to the mailbox and the main event processes the commands. That way you don't have any artificial timing delays in your system and your system would be much more responsive. In more complex instruments I will have multiple tasks that pend and process requests depending upon the type of inputs I'm monitoring. I would go so far as to say that OSTimeDly should only be used during the start up phase of your code. (There might be rare exceptions but I would examine them critically). This is similar to non-embedded programming on PC systems, calls to things like Thread.Sleep() are generally considered a code smell indicating some type of asynchronous code is needed.

And if you haven't seen it, there is a FAQ on How do I generate ticks faster than 50ms that has links to using blocking and non-blocking timer approaches.

[rhopf1]

Tod,
I agree with your approach. Problem I have is the usual of starting with a small project 8 years ago and have it keep expanding, now over 80,000 lines. Have 'N' number of TCP ports and two com ports that can throw commands at my stuff. Started and am still using ZeroWaitSelect inside an OSTimeDly task, go figure obviously can get rid of the OSTimeDly but started with this approach from an example those long years ago and it works very reliably, so reliably I hate to touch it.

Mostly just needed a slight performance tweak vs rewrite to reduce command-to-command granularity keeping the above code intact.

Got impatient and put a ticket into Netburner. Forrest kinda straightened it out, though what happens still is a bit of a mystery. I just re-edited constants.h and built the system files again and used a very simple project to test, worked fine. Went back to my original project that uses my library that includes constants.h and rebuilt both of those, now it works!

Kudos and a plug to Netburner support, excellent! Over the years have gotten fast, accurate response and solutions from Paul, Larry and Forrest.
Thanks guys.