Type of index variables

[oppm]

I saw that all index variables (e.g. to access action array, nodes, etc) are of type "signed char", so are in the range 0..127. What is the reason for this limitation ? For a big procedure or state machine you would run into problems...
Also, I think it would be much better to use normal "unsigned int" for index variables as the generated code runs much faster (unless you have an 8-bit processor) and requires less code (no masking on variable access).

[pasetti]

The reason for the "signed char" choice was that, at least in some cases, I am using the value -1 to encode an invalid or not yet defined value.

I am not really worried about users wanting to define state machines with more than 127 states or procedures with more than 127 as I think that this would be very unlikely (and probably indicative of poor design choices -- one should never have such large state machines or procedures). In any cases, all types are defined through typedef and users, if they really wanted to, could extend the type of their variables.

The argument about speed and memory footprint is appreciated but I am not sure it is completely correct. I would imagine, for instance, that the state machine and procedure descriptors would become larger if we switch from "signed char" to "signed int" (I am assuming that the compiler would "pack" the data structures representing the descriptors).

One final point: when there was a trade-off between memory footprint and speed, I generally gave priority to minimizing memory footprint. The rationale for this choice is as follows. In most realistic scenarios, most of the CPU would be used by the application code which implements the actions and guards of the state machine and procedures. Hence, CPU optimization of the state machine and procedure code would only have a marginal impact on the overall CPU efficiency.

[oppm]

I agree on the memory footprint minimizing, as less code/data means much faster code because of caching.

Ok, if users are expected/allowed to update the data types, then it probably doesn't matter at all and this issue is obsolete.

Packing data does indeed save memory for the data, but not for the instructions accessing them. Say, you want to read one element in such a packed 8-bit array on a 32-bit processor. You would need, a) read the 32-bit value where the element is included, b) mask the other elements away, c) shift the value to the correct position. So, three instructions instead of only one when using 32-bit variables.
I did a small test with the Example 3 (example procedure provided in the fwprofile-editor). I compiled for sparc processor with optimization enabled (GR712RC) for signed int and signed char:
text data bss dec hex
56240 3048 2124 61412 efe4 signed char
55536 3064 2204 60804 ed84 signed int
As expected: memory usage for data goes up when using 32-bit index variables, while instructions go down.

[artbody]

Application: OLED Display , STM32L476 some switches, a rotary encoder and a big user menu with a lot of options.

I was running in the same problem
with 125 transitions it worked perfect
then i've to add a new part in the user menu
this gives 133 transitions .

/** Check that the SM is properly configured */
	if (FwSmCheckRec(smDesc) != smSuccess) {
		printf("The state machine FSMMAIN is NOT properly configured ... FAILURE\n");

in smDesc i found this error message
smUndefinedTransSrc

so i debugged this error message and came to this part
smDesc->errCode = smTooManyOutTrans;

and then i found this in FwSmConstands.h
typedef signed char FwSmCounterS1_t;

after changing it to signed int
typedef signed int FwSmCounterS1_t;
it works again - as expected perfect LOL

/** Type used for signed counters with a "short" range. */
//typedef signed char FwSmCounterS1_t;
/** If there are more then 127 transitions  uncomment */
typedef signed int FwSmCounterS1_t;

I agree with
oppm commented on 15 Nov 2016

memory usage for data goes up when using 32-bit index variables, while instructions go down.