Get first version out

[smurfy]

Get a first version out and working.

Focus on Windows but should work on Mac and Linux too.

First Version infos

• [x] create gui
• [x] downloading firmware infos and settings from server
• [x] download the firmwares
• [x] flashing selected firmware to controller

[SirAlex]

Great!

Could you please share sources (maybe via beta branch)? Just to review and sync our ideas how it will work :)

[smurfy]

i'm currently testing things out how to best do it vs. file size. I will push the working gui part later today

my current idea is:

• download sources
• apply .patch files for the options chosen (later mit advanced / custom options with additional patch files)
• compile the code locally (i'm currently trying to create a small toolchain to compile the source from the console)
• upload hex via avrdude

pros about the idea is:

• we don't need a build server with hundreds of .hex files
• it would be possible for the user to apply custom patches / choose much more options.

current challenges:

• getting console compile working (https://code.google.com/p/ardupilot-mega/wiki/BuildingWithMake)
• not sure how big the toolchain will be, i will only use the files required

[SirAlex]

IMHO, it's not good idea. First of all, regular user will not use custom patches. Second you will get compatibility issue to run toolchain on different platform. Third there is already Arduino IDE which doing almost same.

I'm still thinking on build-on-server-side solution. As I'm wrote early, I'm already have build server so it's not problem. Also we can save only stable versions and betas with common settings. Any other FW will be stored for some time (1 week for example) and will be deleted. At last point, any custom firmwares can be compiled via Arduino IDE.

This FlashTool intended for Newbie users and for who not familiar with compiling. It must be easy to use and lightweight :)

[smurfy]

Ok fine with me too. But i still like to ship / use avrdude to do the actual flashing for now.

list of options i prepared.

• boardtype
• rcinput type
• platform + frame-variants (copter-quad, copter-tri, plane...)
• version

so we should think about a naming schema for the hex files. i would suggest:

boardtype_rcinput_platform_version.hex

sample:

crius2_ppma8_copter-quad_3.0.1-rc3.hex

Here is the xml i'm currently using. (altered a bit for the build server) I would use the idattribute for the hex-file name.

<xml>
    <boards>
        <board name="RCTimer CRIUS V2" id="crius2"/>
        <board name="RCTimer CRIUS V1 / Hobbyking AIOP boards" id="crius1"/>
        <board name="Hobbyking Red MultiWii Pro" id="hk_red"/>
        <board name="BlackVortex" id="blackvortex"/>
    </boards>

    <rcinputs>
        <rcinput name="PPM on A8" id="ppma8"/>
        <rcinput name="PPM on PL1" id="ppmpl1"/>
        <rcinput name="Regular PWM on A8-A15" id="pwma8"/>
    </rcinputs>

    <platforms>
        <platform name="APM:Copter - Quad" version="copter" image="copter-quad.png" id="copter-quad"/>
        <platform name="APM:Copter - Tri" version="copter" image="copter-tri.png" id="copter-tri"/>
        <platform name="APM:Copter - Hexa" version="copter" image="copter-hexa.png" id="copter-hexa"/>
        <platform name="APM:Copter - Y6" version="copter" image="copter-y6.png" id="copter-y6"/>
        <platform name="APM:Copter - Octocopter" version="copter" image="copter-octox.png" id="copter-octox"/>
        <platform name="APM:Copter - X8" version="copter" image="copter-x8.png" id="copter-x8"/>
        <platform name="APM:Copter - Helicopter" version="copter" image="copter-heli.png" id="copter-heli"/>
        <platform name="APM:Plane" version="plane" image="plane.png" id="plane"/>
        <platform name="APM:Rover" version="rover" image="rover.png" id="rover"/>
    </platforms>

    <versions>
        <version platform="copter" number="3.0.1-RC3"  id="3.0.1-rc3"/>
        <version platform="plane" number="2.74b" id="2.74b"/>
        <version platform="plane" number="2.75"  id="2.75"/>
        <version platform="plane" number="2.76"  id="2.76"/>
    </versions>

</xml>

[SirAlex]

We must also add RCInput mapping, GPS Driver and GPS port speed...

[smurfy]

RCInput mapping,

not sure if we need that for the "dummy user", we have the default mapping documented so the user should use that. if he likes another one maybe he should compile it himself. or we move that to an advanced settings tab.

GPS Driver and GPS port speed...

same as above. the default is "auto" which should work fine for most users.

[SirAlex]

Yes, Advanced settings will be fine.

But RCinput usually changed by users, since same board used for Muliwii. So to not change wires, user must change mapping in code.

[smurfy]

But RCinput usually changed by users, since same board used for Muliwii. So to not change wires, user must change mapping in code.

i changed the wires the first couple of times :)

but i will add the setting as-well.

[smurfy]

Ok, i pushed my current code.

i'm now working on the actual flashing and more error handling.

[smurfy]

Ok,

so my first version is finished and ready for testing. I guess the easiest way to test it if i compile a working version, but for that i need the url to get the update.xml from.

I will create a seperate issue for the buildserver / hex / update.xml file host.