If I simly call it using "test2_id" like: mavlink_msg_param_value_pack(SYS_ID, COMP_ID, &msg, test2_id, param.value, ....
then it works ..just as expected.
but when I get the parameters from struct like:
struct stParameters param = mavParameters[i];
and call it like: mavlink_msg_param_value_pack(SYS_ID, COMP_ID, &msg, param.name, param.value, ....
then something bad happens, the packet is not ok. it is hard to tell what goes wrong. - it compiles - but does not work.
(to test - it needs to speak to ground control software and autopilot)
Please note that param.name works fine ... but not the char array,
What is it that I do goes so strangely wrong?
are you missing ending nulls?
string should be terminated, pretty sure it happens automatically with the way you declared test2_id but not in the struct, but you do got the room for 1 more char add a null /0 to TST1 and TST2.
good luck..
No the name is just an example, I can send any null-terminated text up to 16chars.
the point of using char was exactly that they are null-terminated.
It seems there is something else going wrong here..but I do not understand what .. wish I had python's type() function to dig into it..
There is no way for you to reproduce it unless you hook it up with an autopilot and ground station.
The three first lines is the transmitted MAVlink packet that uses direct variable for "SW_VER"
The last three lines is the packet for when SW_VER comes from the table. - both seem ok,and 0x0 terminated except for ..the second packet's payload fails.
I cannot expect perfectly equal packets - because the last bytes are checksum, and there is a sequence number in the beginning.
After much testing .. this is what I find ... using param.name fails. - for unknown reason.
The last line will fail compilation with: Compilation error: invalid types 'uint8_t {aka unsigned char}[int]' for array subscript
Maybe this somehow "proves" that param.value is somehow different, or contains something more than it should?
IDK. Maybe the function/library somehow gets confused by exactly that ? it is expecting char array.
That's the issue here.. I do not know exactly why this do not work. - trying to understand it .. I would expect param.value[2] to be accessible ... just like a char[2] would be ... if the stuct-way was completely transparent.
Does the compiler throw an error, or is the error at run-time?
Could the problem be that param.name is a local variable, that may be overwritten with random data before it is actually used by the library?
Yes, I am disappointed that getting param.name from a struct is disregarding const char name[5];
In fact, I find it frightful - I thought that structures were a neat way to organize things, not to mess them up.
Now that we narrowed it down, it remains to figure out a way of fixing this.