void sendSettings() {
uint16_t data[] = {setpointVariable, targetGroundSpeed};
uint8_t* payload = (uint8_t *)data;
webSocket.broadcastBIN(payload, sizeof(payload));
}
there are other ways of doing what I think you want, which is essentially to serialize two values
if you're sure that your values will always fit in a uint16_t, then your original approach is not too bad. You probably want something like this:
void sendSettings() {
uint16_t data[] = {setpointVariable, targetGroundSpeed};
webSocket.broadcastBIN((uint8_t *)(&data[0]), sizeof(data));
}
agnostic to datatypes that is
none of these uC have hw floats. All floats are software, which means that float-based calculation is rather expensive. That said, the AVR is pretty weak compared to the ESP, which is most likely why you got jumped. Doing floats on the ESP is still expensive computationally, and there is a lot of code that is linked in for the float stuff, but it shouldn't have trouble calculating a simple PID
@ashthespy So I just avoid floats untill human interface time.
about work, that reminds me that I'm done with it, and I gotta head home :p later all!
@devyte ..perhaps you could help with a few simple questions that are driving me loco
@devyte they aren't code but are design related
@devyte Thanks for your help earlier today. I tried your first suggestion for the payload array casting and it works great. I was hoping you could tell me why console is now reporting to be 3 or 4 arrays being sent over websockets.
ArrayBuffer(4) {}
[[Int8Array]]
:
Int8Array(4) [42, 0, 53, 0]
[[Int16Array]]
:
Int16Array(2) [42, 53]
[[Int32Array]]
:
Int32Array [3473450]
[[Uint8Array]]
:
Uint8Array(4) [42, 0, 53, 0]
byteLength
:
(...)
@devyte or is it the same array being read 4 different ways?
@moose4621 @devyte @ashthespy Hello there
Hello all actually :-)
anyone around ?
@moose4621 I think I found part of what I was looking for .. Its a very basic example but shows how to get the variables across