Apply/read profile without the need of reading MCCONF

[Peemouse]

Hi Ben,

This is less an issue than exchanging thoughts.

I'm trying to play with profiles apply/read on small MCU such as Arduino.
Those MCU are very limited in term of memory and reading the whole MCCONF is quite difficult.

However, if I want to apply or read the current profile applied, I do need some values of MCCONF packet.

• Applying a profile

COMM_SET_MCCONF_TEMP requires some values such as duty_min or max and others that can be known only if MCCONF is retrieved.

1. What about a "sanity" check that would skip those values if the deserialization of them shows 0.0 ?
   For instance :

float32 read_min_duty = buffer_get_float32_auto(data, &ind);
if (read_min_duty > 0.0) { mcconf.l_min_duty = read_min_duty }

That way I can just send a profile with the values to change and send 0.0 for those I don't want to change ?

This isn't elegant (like could be a mask) but at least it keeps backwards compatibility.

• Reading the current profile

This would require an extra command I guess for retrieving needed values.
Something like :

case COMM_GET_MCCONF_TEMP : {
  mcconf = *mc_interface_get_configuration();
  int32_t ind = 0;

  buffer_append_float32_auto(buffer, conf->l_current_max_scale, &ind);
  buffer_append_float32_auto(buffer, conf->l_current_min_scale, &ind);
  buffer_append_float32_auto(buffer, conf->l_min_erpm, &ind);
  buffer_append_float32_auto(buffer, conf->l_max_erpm, &ind);
  buffer_append_float32_auto(buffer, conf->l_min_duty, &ind);
  buffer_append_float32_auto(buffer, conf->l_max_duty, &ind);
  buffer_append_float32_auto(buffer, conf->l_watt_min, &ind);
  buffer_append_float32_auto(buffer, conf->l_watt_max, &ind);
  buffer_append_float32_auto(buffer, conf->l_in_current_min, &ind);
  buffer_append_float32_auto(buffer, conf->l_in_current_max, &ind);
  //needed for speed calculation
  buffer[ind++] = (uint8_t)conf->si_motor_poles;
  buffer_append_float32_auto(buffer, conf->si_gear_ratio, &ind);
  buffer_append_float32_auto(buffer, conf->si_wheel_diameter, &ind);

} break;

The purpose of this is to be able to change the mode on-the-fly by a very simple user interface (e.g a selector button on bike handlebar) without the need of a smartphone.

I would be grateful to know your thoughts on this.
Thanks !

[vedderb]

I think the sanity check can be dangerous, as using older firmware will be problematic with that assumption. The best way is probably to make a new command with a bitmask where the fields to be updated can be selected. Older firmwares will simply ignore that new command. Then you don't have the situation that one command is dangerous unless the firmware is recent enough.

This being said, I don't think it generally is a problem that you don't know the old values. It is more or less always safe to assume the following for values that you don't care about:

current_min_scale, current_max_scale
1.0, which is the default on all hardware

erpm_or_speed_min, erpm_or_speed_max
If the speed limit is not interesting, use COMM_SET_MCCONF_TEMP (not COMM_SET_MCCONF_TEMP_SETUP) and limit to -100k and 100k. If the hardware has further limitations, they will be overridden by this command further down

commands_apply_mcconf_hw_limits(mcconf);

duty_min, duty_max
0.005 and 0.95

same here, the hardware configuration can truncate these if it has specific restrictions.

watt_min, watt_max

Set them to some really high value that does not activate, 1.5 MW is the default on all hardwares

[Peemouse]

Thanks for your answer.

The problem is that a lot of people use hw_no_limits FW (IIRC, Flipsky sells their FSESC with this FW...).
So I'm quite afraid it will end with bad consequences...

New commands seem the way to go then. 👍
I start working on it.

[vedderb]

The way to make a new command is to merge it with the old one to avoid duplicate code, as with COMM_GET_VALUES_SELECTIVE and COMM_GET_VALUES_SETUP_SELECTIVE. However, I really don't think you have to worry about using the assumptions above. The duty cycle range is the same on all supported hardwares today, and if someone makes something special (maybe some gate drive limitations or IGBTs) they should not be running no_limits firmware. No one who makes proper hardware should do that in fact, there are better ways. Even being aware that flipsky does it wrong, the above assumptions should not make their situation worse. The intention with the COMM_SET_MCCONF_TEMP command is to be fairly safe as it, without knowing specific hardware details (which is why the current is set as a ratio), so don't worry too much about it.

[Peemouse]

Just figured out...
With a new COMM_GET_MCCONF_TEMP it's now possible to retrieve the values currently used by the VESC.
So issuing this command first let the remote device know then how to fill the COMM_SET_MCCONF_TEMP (or COMM_SET_MCCONF_TEMP_SETUP) command packet with the right values.

That leads to only one additional command instead of 3.
That keeps it simple. 👍

[Peemouse]

Hi Ben,

I'm trying to make the Arduino library work with the new command.

1. buffer_append_float32_auto and buffer_get_float32_auto are an hassle with Arduino IDE.
   I could fix buffer_get_float32_auto but not the other one yet. So it makes the Arduino sending corrupted values to the VESC.
   Still trying to tweak the function to work with Arduino IDE.

2. When sending corrupted value attached to COMM_SET_MCCONF_SETUP, it makes CRASH and reboot the VESC.
   IMO this emphasizes that a sanity check is required before applying received values to the MCCONF.

EDIT : I could find a work around for 1.