canhardware: remove ambiguous 2-arg Send overload (lets callers drop uint8_t casts)

[wjcloudy]

Problem

The forceExt-defaulted 2-arg convenience overload

void Send(uint32_t canId, uint32_t data[2], bool forceExt = false);

makes a 3-arg call Send(id, uint32_t* data, intLen) ambiguous — the int length matches both this overload (int→bool) and the length overload (int→uint8_t). Downstream projects then have to cast every length to uint8_t:

can->Send(0x411, (uint32_t*)bytes, (uint8_t)8);  // otherwise: ambiguous overload

This came up in damienmaguire/Stm32-vcu#239 when bumping Stm32-vcu to current libopeninv (~76 call sites needed casts).

Fix

Drop the bool forceExt from the 2-arg uint32_t convenience. Nothing actually passes forceExt through this form — inside libopeninv it's carried via the canId CAN_FORCE_EXTENDED bit, and all internal Send calls use the 2-arg or uint8_t-length forms.

• Send(id, data) still sends 8 bytes (unchanged).
• forceExt remains available via the 4-arg Send(id, data, len, true).
• Send(id, u32buf, len) now resolves unambiguously to the length overload — no cast needed.

Verified — no consumer uses the dropped form

• libopeninv internals: forceExt is carried via the canId CAN_FORCE_EXTENDED bit; all internal Send calls use the 2-arg or uint8_t-length forms.
• stm32-sine: makes no direct Send() calls at all (CAN output goes through CanMap/CanSdo), so it's unaffected.
• Stm32-vcu: confirmed the (uint8_t) casts can be removed and Send(id, u32buf, 8) compiles cleanly.

Draft — happy to adjust if you'd prefer a different approach (e.g. widening the len type instead of dropping the overload).

[jsphuebner]

Thanks!