Re-entrant info Item for every library routine description.

[Megahurts]

Hi mE Team,

I would like to submit a request that all library routines descriptions in the help file have an an
additional information entry to help us avoid some common compiler and run time errors.

The new entry should indicate if that routine can be called on more than once during a programs execution.

Mostly it concerns hardware init routines and software implementations of hardware features.
But it would clear up any confusion about any routines re-usability if all routines had an entry stating such.

Truthfully, I wish some ,(or all that can be), of the init routines could be called again with variable parameters
so different configurations can be set from within a program.

I hit this limitation or get an error for trying a lot. I feel this is a major limitation with current compilers operation.

I know some hardware modules will not accept re-init once up and running, but any that can, should be
allowable and indicated in the help files.

Changing some of the HW routines to accept a variable or a pointer for parameters instead of hard coded
constants would go a long way to removing current limitations also ,if possible on any of them.
Then parameters could be loaded from EEPROM on those devices with EEPROM or from flash ROM on devices
that can write to flash memory from code.

Like I said, I hit this limitation a lot on my designs ,but where I can solve by storing parameter values
in EEPROM or Flash ROM, I usually hit problem with a library not being able to use a variable for a parameter instead.

Changing this would really make the compilers more flexible, powerful and able to accommodate users
advanced hardware controlling.

This would apply to all languages compilers and devices as applicable.

Thanks in advance for consideration, Robert.

[filip]

Hi,

Please, could you state, for example, which routines exactly do you have in mind ?

Regards,
Filip.

[Megahurts]

Hi back Filip,

That is a hard question, as it has been awhile on some of the ones I had design issues with and
I just realized I posted this in the PIC32 zone, where I am just beginning to do projects on.
It might be more of a problem for the PIC18's and lower?

Those were the devices and mBasic Pro for PIC compiler I was using when I encountered some problems for a wanted design.

The PWM library was a big one I remember, needed to be able to change base frequency on demand but could not with that library.

For PIC32's, recently needed to re-initialize TFT_TP library with different calibration values but could not
once it was up and running (locked up MMB trying). Had to resort to reboot and load stored values method.
Still working out issues on that one, or rather I was until Ver. 3.5 of V-TFT came out.

There are a lot of libraries I have not tried yet and was hoping to avoid this issue with them before ever
getting there by getting you guys to clearly indicate any that, (for any reason - hardware, compiler or programming language...), do not allow calling on more than once during run-time.
Mainly, it is hardware Initialization routines that are the source of my problems experienced.

For some reason, either I or a client wants something to be configurable during operation and
I end up finding out it is not easy or impossible to implement.

Some UN-doable attempts turn out to be hardware limitations, but some I think can be done,
if programming would allow.

I would just like a heads up for all persons trying to push the limits of the software and hardware,
where there is danger of attempting to do something not allowed or stupid (I never said I was smart, willing to try almost anything until extreme pain starts).

If you guys do not put up road signs telling us when to turn away, many of us might drive over the cliff.
( Hey look... a short cut.....oh..nooooooooo.....crash#%$)

If not a reasonable request, no big deal, things remain the same and I go cliff jumping once in awhile.... fun sometimes. Robert.

[Megahurts]

Hmmm,

must have forgotten about this one?