You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've modified one of the potentiometers of the direction gimbals (channel 1 or roll). I've managed to find online an almost identical copy of the originals, both are 5k precision pots and have the same measures, but the originals can vary with 60 degrees and the clone with 220 degrees. That makes a huge difference in the stick sensor scale. Is it possible to rescale the stick analog readings to adapt to the new values?
I have been messing with the C code in the last few days but couldn't find a definitive lead on how to make those changes.
I know from source/adc.c that this signal (ch1 roll sensor) is called ADC0_SE7b internally, and is assigned to PORTD6 or pin 63 of the MCU. I kind of found out on how to configure things such as reference voltage, resolution, clock sources etc; using the adc16_config_t config struct and the ADC16_Init function from drivers/fsl_adc16.c. I've also seen a bunch of commented out functions in the source, one specific that seems to tackle this issue, but for some reason it's not supported any longer is int32_t adc_get_channel_rescaled(uint8_t idx). Perhaps formatSensorValue(char* target, int sensorID, uint16_t sensorValue) from source/alt.c is doing something similar? I don't really understand the IBUS_MEAS_TYPE signals but my guess is that the telemetry data is not related with ADC calibration module, so the answer is no?
Other problem that could possibly fit in a different issue, but since this is just a question: every change I make doesn't seems to be reflected on the final build. I have just an idea on how to map the generated bytecode to memory using the linker scripts. I've modified a few variables that most certainly would have an affect on my FlySky, but it didn't change anything. I didn't add any new function nor my build causes memory overlapping issues, so in my understanding, I wouldn't have to edit the memory map, right? Does the fs-i6_updater_*.bin resulted of make all contains the original firmware binaries or do I have to manually combine it? If so, how can I do it?
For building I'm using the GNU GCC ARM Toolchain binaries found on the default RPM repositories provided by Fedora 34 5.13.12-200.fc34.x86_64.
I couldn't compile exactly 1.7.6 release source code (probably related with #121 but 863819f seems to address this issue) to compare against my modified build. So I did the following:
Downloaded the latest source code available (parent 863819f)
Compiled using make all and generated fs-i6_updater_08_29_15_37.bin & copied it to a different location
Made a few changes in the source code:
I've changed lines 68-89 of adc_init_internal(void) from source/adc.c
I've modified one of the potentiometers of the direction gimbals (channel 1 or roll). I've managed to find online an almost identical copy of the originals, both are 5k precision pots and have the same measures, but the originals can vary with 60 degrees and the clone with 220 degrees. That makes a huge difference in the stick sensor scale. Is it possible to rescale the stick analog readings to adapt to the new values?
I have been messing with the C code in the last few days but couldn't find a definitive lead on how to make those changes.
I know from
source/adc.c
that this signal (ch1 roll sensor) is calledADC0_SE7b
internally, and is assigned toPORTD6
orpin 63
of the MCU. I kind of found out on how to configure things such as reference voltage, resolution, clock sources etc; using theadc16_config_t config
struct and theADC16_Init
function fromdrivers/fsl_adc16.c
. I've also seen a bunch of commented out functions in the source, one specific that seems to tackle this issue, but for some reason it's not supported any longer isint32_t adc_get_channel_rescaled(uint8_t idx)
. PerhapsformatSensorValue(char* target, int sensorID, uint16_t sensorValue)
fromsource/alt.c
is doing something similar? I don't really understand theIBUS_MEAS_TYPE
signals but my guess is that the telemetry data is not related with ADC calibration module, so the answer is no?Other problem that could possibly fit in a different issue, but since this is just a question: every change I make doesn't seems to be reflected on the final build. I have just an idea on how to map the generated bytecode to memory using the linker scripts. I've modified a few variables that most certainly would have an affect on my FlySky, but it didn't change anything. I didn't add any new function nor my build causes memory overlapping issues, so in my understanding, I wouldn't have to edit the memory map, right? Does the
fs-i6_updater_*.bin
resulted ofmake all
contains the original firmware binaries or do I have to manually combine it? If so, how can I do it?For building I'm using the GNU GCC ARM Toolchain binaries found on the default RPM repositories provided by Fedora 34 5.13.12-200.fc34.x86_64.
make all
seems to return successfullyI couldn't compile exactly
1.7.6 release
source code (probably related with #121 but 863819f seems to address this issue) to compare against my modified build. So I did the following:make all
and generatedfs-i6_updater_08_29_15_37.bin
& copied it to a different locationI've changed lines 68-89 of
adc_init_internal(void)
fromsource/adc.c
rm -rf fs-i6_*.bin
andmake clean
make all
and copiedfs-i6_updater_08_29_15_38.bin
to a different locationfs-i6_updater_08_29_15_37.bin
andfs-i6_updater_08_29_15_38.bin
usingxxd
diff i6_updater_08_29_15_37.hex i6_updater_08_29_15_38.hex
Expected behavior:
Different bytecode of section
0x0C24
(adc_init_internal
according tobuild/fs-i6.map
) of the dumped hexObserved results:
Even though they have different checksum:
They are virtually the same binary, except for the building date and the last 2 bytes (maybe a checksum?). See from
diff
:The text was updated successfully, but these errors were encountered: