Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Chris Dalby
@moose4621
@devyte Hi devyte, what's happenin'?
Develo
@devyte
too much, actually :) repo issue cleanup, PR reviews, mdns rewrite, investigation into a batmanadv-like mesh implementation, migration of all .c files to .cpp files, migration to a new gcc, exceptions, stability fixes....
and too little time
oh, and also an experimental integration of w5100/w5500 ethernet shields into lwip as additional interfaces
Chris Dalby
@moose4621
@devyte Ok..... Now I feel inadequate. :-(
Develo
@devyte
:D I feel that way myself about some of what the fellow developers have done. That bearssl alternative to axtls was a huge piece of code, the migration to lwip2 was mindboggling, as is the integration into lwip of the ethernet shields, and don't get me started on the available heap improvements and stack placement voodoo
Ash
@ashthespy
@moose4621 what are you trying to typecast?
Chris Dalby
@moose4621
@ashthespy Same as before. void sendSettings() { uint16_t data[] = {setpointVariable, targetGroundSpeed}; uint8_t payload = (uint8_t *)data; webSocket.broadcastBIN(payload, sizeof(payload)); }
Two int over 8 byte array.
@ashthespy I have it working using my own bastardized method but still want/need to understand typecasting. 'int setpointVariable100 = setpointVariable / 10;
int setpointVariable10 = setpointVariable - (setpointVariable100 10);
int targetGroundSpeed100 = targetGroundSpeed / 10;
int targetGroundSpeed10 = targetGroundSpeed - (targetGroundSpeed100
10);
uint8_t payload[4] = {0, 0, 0, 0};
payload[0] = setpointVariable100;
payload[1] = setpointVariable10;
payload[2] = targetGroundSpeed100;
payload[3] = targetGroundSpeed10;
webSocket.broadcastBIN(payload, sizeof(payload));'
Develo
@devyte
uint8_t payload = (uint8_t )data; => uint8_t payload = (uint8_t *)data;
?
stupid markup
uint8_t payload = (uint8_t *)data;
=>
uint8_t *payload = (uint8_t *)data;
?
Chris Dalby
@moose4621
@devyte Thanks devyte, your answer was the ticket.
@ashthespy Thanks for your time as always. Didn't work though.
Sooo need to understand this stuff.
Ash
@ashthespy
@moose4621 Sorry stepped out -> as @devyte mentioned you need to cast to a pointer
void sendSettings() {
  uint16_t data[] = {setpointVariable, targetGroundSpeed};
  uint8_t* payload = (uint8_t *)data;
  webSocket.broadcastBIN(payload, sizeof(payload));
}
Chris Dalby
@moose4621
I need to do similar to write the same int to the Eeprom. I guess I can use the same method?
Ash
@ashthespy
Lookup unions :-)
Chris Dalby
@moose4621
OK, thanks Ash. Have to go to work now but I will tonight. Appreciate your help.
Develo
@devyte
careful, sizeof(payload) may not be what you want, as it will always return 4 (size of a pointer in 32bit arch)
there are other ways of doing what I think you want, which is essentially to serialize two values
Ash
@ashthespy
The more I look at it my code - the more I see how I just got lucky.
Chris Dalby
@moose4621
@devyte serialize?
Develo
@devyte
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));
}
Ash
@ashthespy
As makuna pointed out - this needs to be deserialized big endian though for the esp8266
Chris Dalby
@moose4621
@devyte That's great. I know my int will never exceed 300 but I need to understand this anyway.
Ash
@ashthespy
@moose4621 why aren't you using floats?
Develo
@devyte
I was just about to say that the above works only for the endienness of the ESP
Ash
@ashthespy
@devyte is there a more agnostic approach to serialisaion/deserialsation for embedded stuff?
agnostic to datatypes that is
Chris Dalby
@moose4621
@ashthespy I got scared of using floats for calculations after I tried to to some PID stuff and was getting weird returns. Posted my problem to arduino forum and was jumped on for doing float calcs.
Ash
@ashthespy
I mean, is one supposed to sprinkle >> and << each time?
Develo
@devyte
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
Chris Dalby
@moose4621
@ashthespy Quote from wiki"Floating point numbers are not exact, and may yield strange results when compared. For example 6.0 / 3.0 may not equal 2.0. You should instead check that the absolute value of the difference between the numbers is less than some small number."
@ashthespy So I just avoid floats untill human interface time.
Develo
@devyte
btw, are you doing a manual PID calc, a time-difference PID, or a Z PID? a manual PID, which is the most common, is also usually the most expensive, and it usually has control instabilities because the calcs don't take into account the time discretization
Chris Dalby
@moose4621
@devyte That project is long gone. Now using a stepper motor instead.
Ash
@ashthespy
@moose4621 there is always some numeric precision that you have to account for. -- There is no one golden rule - so you need to evaluate case by case if the penalty for floating point arithmetic is going to slow you down
Chris Dalby
@moose4621
@devyte @ashthespy As much as I really want to stay here and pick your collective brains, I am late for work. But thank you to you both. I appreciate it.
Develo
@devyte
oh ok :) just wondering. It's been a long time since I've had my hands in automatic control, I kinda miss it. I wrote a doc about PID controller theory some time ago for openservo.
about work, that reminds me that I'm done with it, and I gotta head home :p later all!
Ash
@ashthespy
it's bedtime for me -- cya!
den har
@denman0000_gitlab
Hi all ... seems I missed the party :-( lol
den har
@denman0000_gitlab
@devyte Too little time indeed .. our days of information overload .. it's no wonder TCIP/IP only surfaced when it did hey ... whoever time limits the well kept global secret perhaps have made wise decisions it seems
Develo
@devyte
I'm still around
den har
@denman0000_gitlab
@devyte coolio
@devyte ..perhaps you could help with a few simple questions that are driving me loco
@devyte they aren't code but are design related
den har
@denman0000_gitlab
@devyte hehe or not :-)