mobiflight / mobiflight-firmwaresource Goto Github PK

The CODEOWNERS file uses a ; for the comment line instead of a # so the whole file is considered invalid and doesn't do anything.

Callback handlers used in MFButton and MFEncoder classes could be optimized in order to simplify code and gain some storage space.
(see also pending pull request) #81

The VSCode dev container is currently configured to use Debian as the base Linux image. To better match the GitHub build process this should be Ubuntu instead.

Required to fix/improve this problem MobiFlight/MobiFlight-Connector#346

Optimization of LCD Screen Library still required.

The readme now is basic and should include links to the necessary extension as well as some additional details on how to build a release version of the firmware to include in MobiFlight releases.

Firmware companion to MobiFlight/MobiFlight-Connector#579.

This will require:

• A board.h file based off the Uno board
• A new entry in platformio.ini to generate Nano builds

No change to the GitHub build process is required, it was designed from the start to expect more Arduino boards in the future.

Once the following PRs are resolved bump the version number:

#9
#10
#11
#12
#13

It's currently "promicro" and should be just "micro" for backwards compatibility with the old firmware process.

Previously, MFServo used a technique to incrementally move the internal representation of the servo position towards the desired target position over time in conjunction with a deferral for N milliseconds before adjusting the servo position.

This deferral feature was removed in MobiFlight/MobiFlight-Connector@379c5a2

The current behavior exhibits jumpy behavior, as the servo quickly reaches the target before the next configuration timer tick takes place.

Uncommenting this following line in MFServo::update() re-enables the deferral feature, resulting in a smooth servo transition:
//if ((millis()-_lastUpdate) < 5) return;

Results were tested using a SG90 servo with a timer interval at several points from 100ms to 500ms, inclusively, with satisfactory results.

• Local vs release builds
• How to override the local build number
• Add CodeTour as a recommended vscode extension

Elral moved the board-specific #define values out into separate files. Double-check they are all correct. It would be bad if my random changes for other things unrelated to this work somehow made it into this repo introduced an error in the values!

• Fork the current implementation of cmdmessenger and make the necessary tweaks to be compatible with MobiFlight

With mobiflight-admin as the owner

From @elral

Within readConfig() readBuffer[MEM_LEN_CONFIG + 1] is defined and a RAM area is reserved. Then the config (String cfg) is copied to readBuffer[].
In the nexr steps readBuffer[] is processed, all "." and ":" are exchanged to NULL (string termination) and for each device pointers are defined which are pointing to this reserved RAM area.
At the end of the function readBuffer[] this RAM area is released, but the pointer are sstill pointing to this RAM area.
In the following program it can happen, that additional RAM is required and that the remaining RAM area is not sufficient. In this case the released RAM area from readConfig[] is used and the config is mixed up.

Similar to #15 but for rotary encoders. From @elral:

Same could be applied to the encoder function, but is not part of the existing pull request. It will "only" save 12Bytes for the proMicro (4 Encoder * 4Byte(_lastmillis in MFENcoder.h) - 4Byte(mobiflight.cpp))...

Auto attach firmware to pull requests after validation completes

Allow 69 devices with 16 characters each #287

The worst case is all buttons and with 16 characters each.

This has to do with running out of memory. @elral investigated and reports this in Discord:

Stepper, Segments and LCD lib allocates there required memory on runtime. So far so good. BUT after uploading a new config the memory must be freed (delete class), and this does not really work on the Arduinos (what I have read). Most worse in this aspect is the 7Segment lib, as this one uses a bigger array in some functions (which are not used for now in the firmware).

A fix was also explored and mentioned in Discord:

I used only the required functions from the 7Segment lib and implemented them directly into the MFSegment.cpp (I guess Sebastian is not very happy with this 😉 ) so that they are used statically (for what I have understood). With these changes the promicro does not crash anymore after uploading a new config. Furthermore I could save some more RAM usage with this change and with the already prepared changes it seems that the promicro runs stable with all devices activated. The only thing I haven't tested (just defined in the config) are the shift registers.

We need to decide if this is the approach to take to resolve this issue, then implement for real.

Firmware side of MobiFlight/MobiFlight-Connector#526

The version is getting set to "BUILD_VERSION" instead of the value.

From #13 (comment).

Currently a copy of the config buffer is made because strtok_r replaces the delimiter in the original string with a null character. @elral has a proposed solution that will remove this duplicate buffer copy.

It's a TON of extra files that aren't necessary in the repo since this is the firmware source.

Either these should have non-zero numbers or support for analog inputs and shifters should be disabled for Uno.

Get rid of the promicro basic from platform.ini

From Jamie:

on the mega firmware. It was working very well, but just to test I reloaded the mfmc file for the board. The upload to the board appears to go well, but after exiting the MF Modules window, I was having problems and going back to MF Modules now showed the board is missing about half the configuration. I repeated this three times with the same result.

There should be a CHANGELOG.md file and a template for pull requests that reminds people to add it.

The #defines that determine what components are supported by each firmware are currently set in the board header files with
no way to modify them from the command line of the build. This makes it impossible to generate board variants without
modifying the header file.

Fix this by wrapping each #define with an #ifndef, so it provides the default but can be overridden at compile time.

Reported in the feedback channel of Discord, encoders that used to work with (00) now have different behaviour, confirmed by @elral in local testing.

The function that sends data out to the shift registers is off by one in the byte count.
The behavior does not cause apparent malfunctions becaus the excess byte is discarded.
Fixed by #79.

From elral:

All Buttons are read in a for loop. Every button stores it's own time when it is read the last time, but for all buttons this is the same time (for loop). To save some RAM usage (60bytes for the proMicro) the "debouncing" can be done in the central function (readButtons() ).

Companion issue to MobiFlight/MobiFlight-Connector#449.

I have this written just need to update it based on all the firmware work done recently.

Copied from MobiFlight/MobiFlight-Connector#519

Is your feature request related to a problem? Please describe.
I have encountered some electrical noise coming from 7 segment display modules, which cause jitter problems in a potentiometer. Suggestions received have reduced the problem but not eliminated it. It would be good to have a way to smoothen potentiometer readings through software.

Describe the solution you'd like
Implement a 10 reading rolling average in the arduino firmware with a soft switch in MF Connector analog input configuration, that can be used to turn this feature on and off. When on, the analog pot reading sent from the board will be the rolling average of the last 10 readings. This will effectively smoothen the readings and eliminate jitter. This technique has been successfully used to smoothen the operation of a yoke with three analog pots connected to a pro micro.

Describe alternatives you've considered
I have tried to isolate the noise problem in hardware and jitter has been successfully reduced, but not eliminated.

Additional context
Potentiometers can present jitter due to various reasons. This will provide a solution in software to alleviate this problem.
I suggest that instead of calculating a real rolling average, which can take too much computational power, adding 10 readings and dividing by 10 in each read cycle, Start with an assumed average of zero and an array of ten readings (all zero). In each cycle: increment the reading counter index (0 to 9), add the current reading divided by 10 and substract the counter indexed reading divided by 10. Finally, store the current reading in the counter indexed position (replacing the value just substracted).
Any error at start disappears within 10 cycles.

The buffer overflow with 40 chars corrupts the class storage, which leads to unpredictable behaviour.

I've rebuilt the Firmware with a new MAX_COL set to 40, uploaded to the Arduino controlling a 40 x 2 display. Works fine now.

Ideally ::attach() would return bool or byte, with an explicit error code for "too many columns". Then
the GUI can take appropriate action.

Optimization of LCD Screen Library still required.

Forgot to include this as part of the CodeTour addition. Oops.

• Update to newest servo library in platformio.ini

In the meantime the firmware was updated to version 1.11.3.
Changes according "Fixed On Press-On Release conflict for button event #504" from [(https://github.com/MobiFlight/MobiFlight-Connector/pull/504)] must be also implemented in this reposority.

• Use dev as the version number for local builds
• Use the GitHub tag version for release builds

MEMLEN_NAME is used instead of MOBIFLIGHT_NAME. This error is replicated in main.cpp as well.

Reported in the discord by user jaelee105. The attached configuration loaded without error in 9.1 but results in an upload error with the new firmware beta:

2021-11-16 오후 7:04:30(468): ExecutionManager.autoConnectTimer_Tick(): No Sim running
2021-11-16 오후 7:04:23(938): Error on Uploading.
2021-11-16 오후 7:04:21(932): Uploading config (Part): 1.53.L1:1.52.R1:1.51.L2:1.50.R2:1.49.L3:1.48.R3:1.47.L4:1.46.R4:1.45.L5:1.44.R5:1.43.L6:1.42.R6:
2021-11-16 오후 7:04:21(901): Reset config: 13

FMC1.zip

This is on a Mega ch340.

Document how to publish a new release to the readme.

Nothing special is used in this library so get rid of it and just rely on basic Arduino EEPROM functions.

https://github.dev/MobiFlight/MobiFlight-FirmwareSource/blob/19c7c64c8d7e0607db7531c119c631a1fa07793c/src/mobiflight.cpp#L14-L47

These lines are no longer needed, GitHub tracks all the changes already.

Leftover from when the code was originally in one of my older repos. Oops!

• Simplifies setting up development for new people to the project
• Enables developing in Codespaces

• Move https://github.com/elral/Arduino-CmdMessenger.git to MobiFlight github
• Update platform.ini to reference the new github location

It's not needed. Also update the pull request template to remove references to it.

The following header files are checked in but unused:

• include/MFBoardMega.h
• include/MFCore.h

These should be removed from the repo.

From Sebastian on current steps:

for mobiflight application there is the release bat
there is a little helper program that can read the version from the assembly file and uses that for creating the release package
for including the firmware into mobiflight i used to copy the hex files manually over to the firmware folder, and also add the the files manually/explicitly to the project
and then i have to update the version information in the mobifligbht module info class

There's a GitHub API for requesting info on the latest release:

https://api.github.com/repos/{{owner}}/{{repo}}/releases/latest

Or a specific tag:

https://api.github.com/repos/{{owner}}/{{repo}}/releases/tags/{{tag}}

From the MobiFlight issue elral has good changes to include:

I moved the required functions from button and rotaryencoder libs to MFEncoder.cpp. Therefore these libs are no longer required and I do not expect changes in these libs anymore (at least which would be required for MF). Interesting side effect is that this has reduced the RAM usage by ~210byte and Flash by ~2,1kB!?? If you are interested I can provide the changes and an additional test would be good if especially the FAST detection works with all encoder types.