RFC: Provide preconfigured hex files for missionplanner to flash

[smurfy]

Hi,

i want to discuss the possibility / the need to create some kind of automatic build server and repository to provide the users with pre compiled hex files to flash firmware to their board.

Stuff we should discuss:

• Is there a need for this
• Is it feastable (there are a lot of different boards/rc input/frametype configurations in mpng)
• Is it possible throu the default load custom firmware method of the missionplanner
• Either its not possible via missionplanner or it is better to create a GUI tool for avrdude to flash the images. (like kkflash tool but for mpng)

[claytonc2001]

I love the idea. If there where enough people contributing different configurations in a clear and concise way it could be great. Maybe a page where you enter what hardware/software/firmware you have and it matches that to what has been contributed. I would probably be more of a consumer than a contributor (at first) but I still like the idea.

[SirAlex]

I'm already have build server. It can produce HEX files for predefined firmwares. But you cannot compile for all possible settings. There is lot of configurable parameters (~1000 variations).

I'm have idea to make user-end GUI application - Firmware flasher. User will enter all parameters (board type, frame, type, RC type....). The program will send request to build server and server will build HEX with provided settings and program will flash it to controller. So no Arduino IDE needed.

But... there is lot of work to make possible to configure all parameters in firmware with external defines (which will pass to make). Also I need to make some server side scripts which accepts user request and build HEX for it. And GUI application itself.

So if someone can help with this, it will be great.

[smurfy]

So if someone can help with this, it will be great.

I'm interested in helping out. My ideas for the Gui/Server part.

• Creating a GUI for avrdude using QT (works on all systems (windows, mac, linux)
• Two part development, first a simple repository and then switch to build's on demand
• Serverpart for repository, use a webserver with a small xml file for metadata
• Serverpart for build server i would suggest node.js, with a yet to define rest api to trigger builds/download hex

I also want my fork for arduplane in the repository and suggest add some sort of separate git repository to manage the configuration of the repository data / build server. And all contributors get commit access or use pull requests.

I would concept the simple repository version of the Gui like this.

• General configuration: RC Input method
• General configuration: Board type selection
• Main Screen: Images like in Missionplanner for the different Firmwares. (ArduPlane, ArduCopter)
• Main Screen: Dropdown after selection of Firmware or per Firmware type below the Image to select version to flash (stable, tags, master)
• Flash button triggers a popup to select the serial port of the usb device and after ok starts the flashing process via avrdude.
• Flash Status and maybe even a small connect to the board and check some stuff via mavlink commands

[smurfy]

After reading up on the topic and looking at the mission planner source i think it would be also possible to do the flashing directly, without using avrdude.

also mission planner has an autodetection of the board you are using based on the usb id. but i don't know if this works for us aswell.

[smurfy]

Also interesting to use as basis for flashing and board detection: https://github.com/diydrones/qupgrade its already QT

[SirAlex]

I'm just created new repo for FlashTool (and all server side things). https://github.com/MegaPirateNG/FlashTool So we can move to it.

Also I'm created new organization MegaPirateNG and I want to move all repos regarding MPNG to it (from my personal github). What you think? May I just move repo to new place?

[smurfy]

Also I'm created new organization MegaPirateNG and I want to move all repos regarding MPNG to it (from my personal github). What you think? May I just move repo to new place?

Yea you can move the repro via settings -> dangerzone I could move my docu repro too.

i'm not sure how we handle my arduplane branch. or any other branch in the main mpng repro i would suggest something like that:

• master <- like the current master ardupilotcode + mpng hal + platform specific changes + new mpng features
• mpng_ArduCopter-3.0.1 <- development branch for arducopter based on ardupilot's stable arducopter platform with mpng hal + patches.
• mpng_ArduPlane-2.75 <- same for arduplane

the platform specific branches normally are based on their corresponding ardupilot stable version and contain the hal patches. if possible new mpng features gets backported from master to the platform stable branch.

We tag the platform branches like mpng_Arducopter-3.0.1-rc1 ... for release and for autobuilding for the flashtool.

[SirAlex]

Yea you can move the repro via settings -> dangerzone I could move my docu repro too.

I'm just afraid all forks from my repo will lose this connection, or something will go wrong.

I think, master must contain only stable code, for example 3.0.1-R2. Because a lot of people load latest code from master and try to fly it even it alpha or beta version. So to prevent any damage, it must contain only stable code (releases). or make some changes in files to make it unflyable (not pass compilation with Error message). I'm encountered this problems with current master 3.1-rc4, users downloads it and try it.

[smurfy]

I'm encountered this problems with current master 3.1-rc4, users downloads it and try it.

i know what you mean. so scrape the master branch and create a "development" or whatever branch.

Also i think with the flashtool that problem gets mitigated because the users mostlikly only flash the stable version. I will start working on it this weekend and hopefully have a working prototype version by monday