Change setting of RTC to use ticks. #159
Conversation
| I don't upgrade my smaller quads too often (because they're working great and are tuned). So, I prefer to have a working lua script with all version of betaflight. I'm not aware of the complexity to have backward compatibility code. I assume that we have the API version, so what's the problem ? Memory or something else ? :) |
| @SRWieZ: Good point. We don't per se have the API version, we have to send an MSP command to the flight controller to get it to return it. This adds more complexity to the lua scripts, and will push us closer to running out of RAM on the TX again, so it's not something that should be done lightly. |
| I see. We don't have enough RAM but we have plenty of storage, right ? Can we add different bf.lua with version number like bf33.lua bf35.lua bf40.lua ? So we could assign bf33 on older quad telemetry screen and bf40 for our beta testing quad. Should be easy to maintain, or I am missing something ? |
| My first thought was to use different branches for different versions on github like vendor libraries I'm working with. I don't know what's the best solution. :) |
| @SRWieZ: Yes, using different names for scripts used for different versions is one thing that crossed my mind - I assume that when switching from one model to another on your TX the 'telemetry' script stopped and the memory freed. |
| values[6] = now.min | ||
| values[7] = now.sec | ||
| if API_VERSION < 1.041 then | ||
| local now = getDateTime() |
There was a problem hiding this comment.
The only thing that comes to mind is instead of having the two branches in the if/else expr, we do something like
assert(loadScript(SCRIPT_HOME.."/rtc_"..API_VERSION..".lua"))()` which contains the api-version specific section.
There was a problem hiding this comment.
I am a bit divided on that. Until now the approach is for the lua scripts to only support the latest released version of the firmware, and I am not sure that going down the rabbit hole of introducing backwards compatibility is something we want to do, not least because we are already constrained by the available RAM as it is.
src/SCRIPTS/BF/background.lua Outdated
| local now = getRtcTime() | ||
| | ||
| values = {} | ||
| values[1] = bit32.band(now, 0xFF) |
There was a problem hiding this comment.
perhaps a loop 1..4?
local now = getRtcTime() values = {} for i = 1,2,3,4 do values[i] = bit32.band(now, 0xFF) now = bit32.rshift(now, 8) end values[5] = 0 values[6] = 0| values[3] = bit32.band(now, 0xFF) | ||
| now = bit32.rshift(now, 8) | ||
| values[4] = bit32.band(now, 0xFF) | ||
| values[5] = 0 -- we don't have milliseconds |
There was a problem hiding this comment.
Is it worth documenting in here the expected payload, or is it documented on the FW side re: MSP_SET_RTC?
4 participants
To go with betaflight/betaflight#4682. Due to the dependency on this it will only work with firmware 4.0 and up, unfortunately. I do not know how to best deal with this, except allowing the user to change it by un-/commenting the relevant sections of code - supporting multiple API versions like it is done in configurator seems to be overly complex for the lua scripts.
Fixes betaflight/betaflight#6504.