NOTICE: Trunk has been migrated to .cpp/.h files

[Sebbi]

An official issue tracker would be a nice tool to help keeping track, I agree. I don't like the one googlecode offers, but it's better than a forum for bug reports

As a follow up, I played around with the code and found that the Mega 2560 is too slow for the GUI when using an input buffer of 64 bytes length. It regularly "bites itself in the tail" in store_uart_in_buf (Serial.cpp) and misses MSP messages. I fixed it by increasing the input buffer size to 256 ...

[clough42]

That Eclipse tutorial seems to be very Windows specific.

Especially these days not everyone (esp. Developers) uses Windows. If MultiWii does not remain platform agnostic, it will shed developers like --- well --- like Windows. If it sheds developers, it's toast.

I build on Linux, and I have access to Mac's but I do not have a Windows machine.

For now, and for at least the near term future, I see that I can still use the Arduino IDE. I have also used Eclipse for other stuff (Android, Java...).

I assume I do not need a replacement for WinAVR, since Linux already has compilers/cross compilers, but I have never built for Arduino on Eclipse. I'm sure I can find that info (If/When) I need to, but I and others would appreciate it if the Wiki was kept as platform-agnostic as possible.

Thanks for the reminder. The MultiWii firmware can certainly be developed under non-Windows operating systems. For the most part, the steps in the tutorial are correct, but some of the details are windows specific. I have added some alert boxes in areas where different steps are needed under MacOS and Linux. I don't have either up and running at the moment, so I can't work out the details.

Take a look at the updated docs. If you have any specific details or links I can include, let me know, and I would be happy to add them.

[casquad]

Hello everybody,

Sorry I have been disconnected for a while. I am really glad that all the work done for the cpp migration has finally seen the light. I have received my board so now I can play with the code.

I would suggest to commit the eclipse project files into the trunk (as I did in the cpp migration branch), so we all have the same eclipse configuration. If I am not missing anything, now every developer has to checkout the sources into a clean AVR project and configure it (Include search paths, defines, compiler options, linker options, etc), and do this every time we want to ckeckout. Since all these options are common to all of us, I think it is safer to share them.

For those who loved the old Arduino style, please do not be afraid of C/C++. Apart from the fact that the language is not so hard to learn, this migration gives us a new world of possibilities, such as reorganizing the function and global variables in independent modules, and create a well-defined layered arquitecture, making the development and porting to new platforms very much easier (separating the application from the low level drivers, for example).

Thank you all for this great job!

[casquad]

Forget about my comment on the Eclipse project files. I have just realized it is already done!

[Sebbi]

About developing in Eclipse ... there are a few things I noticed and I'd like to know how you guys are handling it:
1) programming an Arduino Mega works, but only with the magic "mode COM1 dtr=on" (Windows) before each upload. Other Arduinos who use the "arduino" protocol instead of "stk500v2" work without that hack
2) while the compilation says everything is fine, when I open individual files different kind of errors show up (like GYRO_SCALE couldn't be resolved in IMU.cpp or conf.* in EEPROM.cpp, etc) ... is that normal?
3) all those static functions ... why are they static? AFAIK that confines a C-function to be only available in the file it is defined in. Declaring a function static doesn't seem to make a difference in the produced binary
4) an issue tracker would be nice ... there were some error reports here in the forums, but I guess they will be lost (buried in threads about other topics) if none of the active developers fixes them right away.

P.S.: I am currently (and slowly) rewriting some of the serial communication code ... who would one need to talk/write to to get this kind of modification looked at and eventually integrated in MultiWii? Posting patches or zip-files with the whole code in a forum doesn't feel like the most efficient way.

[itain]

3) all those static functions ... why are they static? AFAIK that confines a C-function to be only available in the file it is defined in. Declaring a function static doesn't seem to make a difference in the produced binary

There may be two reasons:
a. Optimization... Using static functions may help the compiler make better optimization. If a function is static then it is not exposed to other files. The compiler knows about all the uses of a function. Also, only a static function can be truly in-lined.
b. Encapsulation... I make a function static when this function should not be part of some API. I do not want other pieces of code to use it or to know about it.

[clough42]

3) all those static functions ... why are they static? AFAIK that confines a C-function to be only available in the file it is defined in. Declaring a function static doesn't seem to make a difference in the produced binary

There may be two reasons:
a. Optimization... Using static functions may help the compiler make better optimization. If a function is static then it is not exposed to other files. The compiler knows about all the uses of a function. Also, only a static function can be truly in-lined.
b. Encapsulation... I make a function static when this function should not be part of some API. I do not want other pieces of code to use it or to know about it.

The other benefit of encapsulation is avoiding accidental conflicts.

[Hamburger]

does GPS work for anyone after the migration?
I just upgraded another copter to the newer MWii and this has stopped gps from working on the mega2560. This is it:

Code: Select all

#define GPS_SERIAL 2
#define NMEA

symptoms:
a) Return to home does nothing
b) on LCD output #sats stays at zero, but status is up to OK.

[Sebbi]

GPS seems to show correct data, but I haven't tried RTH yet. Same configuration here ...

[doppler]

I have GPS working on a HK Mega with MKS GPS, MKS16 defined. RTH works, and its the first time I played with it, kinda neat.

Version is 1539.

Andrew

[Hamburger]

Thanks. That helped me track it down.
The default gps baud rate is changed From 115k to 57k.
Makes you wonder why the status did go to ok with wrong baud rate?

[doppler]

So, which is right? I saw the 57k too, left it alone but remember setting my MKS to 115, maybe binary mode switches rates anyway....

[Hamburger]

my gps came configured to 115k, older MWii code had same 115k for gps speed; now MWii has changed default to 57k.
If it does not work, either reconfigure gps to 57k or change MWii gps port speed back to 115k. Ignore the status OK for diagnosis, use #sats instead.

[timecop]

57k is more than enough for 10Hz GPS.
there's no reason to do 115k.

[doppler]

Thank you both Hamburger and timecop.