Dashboard

Guys, looking at that list I realized that theres a lot of unneeded pointers there

I added another patch to the review:

list looks now like that:
for single instance objects:

[object header [flags, name, eventlist, id, [meta flags, meta name, meta eventlist, [metadata]], [uavobjectdata]]


and for multi instance objects:
[object header [flags, name, eventlist, id, [meta flags, meta name, meta eventlist, [metadata]], num instances, [uavobjectdata]] - - > [uavobjectdata] - - > [uavobject data] – > ...

eliminating the following information from each UAVObject instance:

• instance ID (they are sequential anyway) (2 byte)
• pointer to uavobjectdata ( 4 byte )

means for each single instance object we save around 12 byte (I think) and for multi instance objects at least 6 bytes per instance - that adds up!

total saving on coptercontrol next is 536 byte which ups the total memory saved to 1304 byte )

No, there isn't even a per instance meta anyway. There's always a single meta registered when a new object is.

Normally, the commits should be exported from a git tree using

git format patch somehash{^,}

which will export the author, commit log and the patch into a file.

You would then create a local branch:

git checkout -tb newfeaturebranch origin/next

You would then use:

git am theoriginalpatchfile.patch

to apply the saved patch file to your tree.

That would be the typical workflow for taking patches.

NOTE: Altering the commits is a bit more complicated. If this looks awkward, just don't worry about it. No big deal.

If you're going to edit the commits after the fact, you may be able to use something like:

## git am ...
## git rm the files that shouldn't have been added in your tree
git commit --ammend
## you might want to add 'Modified-by: <your@email.addr> to your new commit.

I think that will maintain attribution and commit text. If it doesn't work right, just go with your original strategy.

@berkely: The Project/Windows USB/OpenPilot-CDC.inf file included in this review is the one you need to feed to windows so that it will recognize the new VCP port. That should be enough to make the device 'ready' and give you a new COM port.

With the serial number working properly now, the board should also maintain that one new COM port no matter which USB port you plug it into.

Note that the VCP port isn't active by default so pointing your GCS at it won't do anything until you activate it in the HwSettings gadget. Default behaviour (as you've seen) is to keep using the HID device so GCS keeps working after the upgrade.

whats the best tool to fix indenting and whitespaces? this file needs an overhaul (well, most do)

Can you tell us what OS you have, and if after this you can still jump between bootloader and firmware.

I'm just testing this as a general end user where it will end up I guess.

I loaded the latest firmware on a board with the standard BL. Win7 comes up with 3 new devices, a composite, an Input device and CopterControl for what it doesn't has any drivers (and apparently searches the Windows Update site for it). Windows reports that it was unable to install drivers. So we end up with a CopterControl device which is not "ready", although the GCS can just communicate fine with it.



This is the expected behavior?

I don't see anything wrong with it, and it does appear to make it easier to change the metadata bitmask in the GCS.

Wont you love Microsoft...WTF?!?

@Oleg: could you give this one last test with the latest software on stac/pt-win-vcp-fix? If this works for you, I think we're probably ready to merge this.