PRD object fields question.

I believe the PRD function will be called every 100 ticks after the first 50 ticks has expired.

Note that PRD_start() and PRD_stop() are meant to be invoked on PRD objects configured for 'one-shot' operation.

Alan

Thank you.

Do you mean this is clearly legal to modify the PRD objects's fileds dynamically?

If so, I have noticed that nticks field never resets on one-shot mode after entering the callback. Is it legal to reset it dynamically in my code? (as well as kount field)

Don't these changes have any kind of side effects on bios functionality?

Although not recommended, it is OK to modify the 'period' field of the PRD object within the context of the PRD function since it is only read by the PRD service routines.

The other fields: 'nticks' and 'kount' are read from and written to by the PRD service routines so it is a very bad idea to modify them.

Alan

What do you mean 'within the context of the PRD function' ?

Anatoly,

It means from within the function that is configured for the PRD object (that will be invoked periodically, based upon the ‘period’ configured for the PRD object).

Scott

Is it legal to modify the period and other fields of the PRD object outside the context of the PRD function? And what side effects can it cause if it does?

Anatoly.

Anatoly,

As Alan said earlier in the thread, it is not recommended to modify the fields.  Personally I’d say *NOT* recommended. 

There are some optimizations in the PRD design to minimize the posting of the SWI that actually invokes the functions of the PRD objects.  So, the SWI won’t be posted every time PRD_F_tick() is called.  How often to actually post the SWI is computed statically at program configuration time, depending upon the periods of all the statically configured PRD objects.  Depending upon the configured PRDs, this can significantly improve efficiency, and reduce unnecessary SWI context switching.

If you are modifying the period of a PRD object dynamically, depending upon the other PRD objects that were statically configured, you may end up with a situation where the PRD object’s function doesn’t get invoked when you want it to be invoked.  

If you *really* want to do this, I think it would be OK if you configure the PRD with a given period, and then when you change it at runtime, make sure the new period value is a multiple of the original period configured for that PRD.  If you do this, I think the PRD will run when you want it to, but you may be getting a bit more SWI context switching than you would have if the PRD had originally been configured for the larger period.  And if you do this, you should probably bracket your change to the PRD object’s period with calls to HWI_disable()/HWI_restore().

Scott

Should I bracket the dynamic change of the PRD object's period with HWI_disable()/HWI_restore() only for smaller periods than the original configured statically? I ask this, because I have a number of HWI's in my application, that I don't want to loose, I need to get them in proper time in other words.

Anatoly.

You should do the disable/restore whenever you are modifying a PRD object outside of the context of the PRD function.  

It should be a small number of cycles to disable, modify the period, and then restore interrupt state.  If an interrupt hits while in this atomic section there may be a small number of cycles additional delay to servicing the HWI, but this is similar to other points in the application and BIOS where interrupts can be momentarily disabled.

If you are setting smaller periods than the configured period for the PRD, then even with the above protection, you can easily get into a situation where the PRD will not run when you expect it to.  Even if you have only a single PRD configured, depending upon the period values chosen, setting the period to a smaller value at runtime can result in unexpected timing.

Scott

Is there a way to prevent this unexpected timing?

Thank you very much, Anatoly.