Reorganising source *.c code with *.h headers; Eclipse IDE

Hamburger · Post by **Hamburger** » Sun Jun 16, 2013 5:30 pm

Please verify output code sizes are same as within arduino ide or smaller.

alll · Post by **alll** » Sun Jun 16, 2013 8:00 pm

Hamburger wrote:Please verify output code sizes are same as within arduino ide or smaller.

The same

ECLIPSE:

Code: Select all

20:55:01 **** Incremental Build of configuration Release for project MultiWii ****
make all 
Invoking: Print Size
avr-size --format=avr --mcu=atmega328p MultiWii.elf
AVR Memory Usage
----------------
Device: atmega328p
Program:   15438 bytes (47.1% Full)
(.text + .data + .bootloader)
Data:        987 bytes (48.2% Full)
(.data + .bss + .noinit)
Finished building: sizedummy
20:55:01 Build Finished (took 134ms)

ARDUINO

Code: Select all

d:\Temp\AppData\build7539297584309471069.tmp\MultiWii.cpp.hex 
Binary sketch size: 15,438 bytes (of a 32,256 byte maximum)

casquad · Post by **casquad** » Sun Jun 16, 2013 8:55 pm

As soon as I have permissions in the svn, I will create a branch for cpp/h development and commit my first version. This cpp code will be the start point for the migration so everybody can add their contributions to this new branch.

I will let you know when this is done.

timecop · Post by **timecop** » Mon Jun 17, 2013 12:28 am

Try using a newer avr-gcc than whats included with tarduino IDE - previous attempts at C-ifying the code have consistently produced smaller binaries. Also might want to try doing -Os or -O3 or similar for optimization options.

alll · Post by **alll** » Mon Jun 17, 2013 6:15 am

Yes, all avr compiler + avrdude are included in the Arduino IDE.
All that is needed (follow install instructions i mentioned abobe) :
*Install Java JRE,
*Install latests version of Arduino,
*Install Eclipse C+C++,
*Install Arduino Plugin,
And you should have your toolchain working.
I am happy this is finally on the road, no way back!
manu
PS: could a similar setup (using Eclipse) be made/explained for a STM or other mcu toolchains?

EOSBandi · Post by **EOSBandi** » Mon Jun 17, 2013 8:56 am

alll wrote:Yes, all avr compiler + avrdude are included in the Arduino IDE.
All that is needed (follow install instructions i mentioned abobe) :
*Install Java JRE,
*Install latests version of Arduino,
*Install Eclipse C+C++,
*Install Arduino Plugin,
And you should have your toolchain working.
I am happy this is finally on the road, no way back!
manu
PS: could a similar setup (using Eclipse) be made/explained for a STM or other mcu toolchains?

For STM I recommend CooCox ide + GCC-arm, simple and self contained.....plus you can get a Coos for rtos.

Hamburger · Post by **Hamburger** » Mon Jun 17, 2013 11:20 am

timecop wrote:Try using a newer avr-gcc than whats included with tarduino IDE - previous attempts at C-ifying the code have consistently produced smaller binaries. Also might want to try doing -Os or -O3 or similar for optimization options.

you are free to try that and whatever else you consider interesting.
But for the time being you must _not_ break compilation with arduino IDE.

alll · Post by **alll** » Mon Jun 17, 2013 12:08 pm

Hi,

Just to keep the same AVR-Arduino Eclipse-tool-chain initial approach and reuse big parts of the multiwii code, but now target a much more powerful 32-bit ARM Cortex-M3 microprocessor, could we not use these “Arduino-like” boards (The Maple Mini) and use external sensors for example?
http://leaflabs.com/

manu

timecop · Post by **timecop** » Mon Jun 17, 2013 12:30 pm

alll wrote:Hi,

Just to keep the same AVR-Arduino Eclipse-tool-chain initial approach and reuse big parts of the multiwii code, but now target a much more powerful 32-bit ARM Cortex-M3 microprocessor, could we not use these “Arduino-like” boards (The Maple Mini) and use external sensors for example?
http://leaflabs.com/

manu

Hello and welcome to 2 years ago.
Unfortunately, attempting to do development for a proper processor in a limited piece of shit that is tarduino IDE just doesn't work. so you either get with the program and use a proper toolchain/ide or stick with tarduino, which is what this thread is about.

Sebbi · Post by **Sebbi** » Mon Jun 17, 2013 1:48 pm

alll wrote:Hi,

Just to keep the same AVR-Arduino Eclipse-tool-chain initial approach and reuse big parts of the multiwii code, but now target a much more powerful 32-bit ARM Cortex-M3 microprocessor, could we not use these “Arduino-like” boards (The Maple Mini) and use external sensors for example?
http://leaflabs.com/

manu

That would be possible if MultiWii was actually using Arduino code. In reality MultiWii is heavily optimised code for some microcontrollers that happen to be used for Arduinos, too. If there were some kind of abstraction layer (tried some concepts here a few months back: https://github.com/sebastianherp/multiw ... experiment) it would be easier to port the code to different plattforms, I agree ;-)

clough42 · Post by **clough42** » Mon Jun 17, 2013 5:32 pm

casquad wrote:I have attached the MW project separated into cpp and h files.

This is exactly what I had imagined. Well done. I'm looking forward to having this as a branch in the repo.

casquad wrote:Btw, I have checked the svn and branches are not real branches, but direct commits into the "branches" folder

Branches are just as real in SVN as they are in any other SCM. SVN uses a unified version implementation where branches, tags and folders are all really the same thing internally. This leaves lots of flexibility for different branching and merging strategies, which is both a blessing and a curse. You have to pick a strategy for your project and operate it consistently, or you can make a pretty big mess pretty quickly--especially on a large project with tens of thousands of files and millions of lines of code.

In this case, though, a merge isn't really going to buy much, since almost all of the filenames have changed. When this goes into the _shared directory, SVN isn't going to be able to track changes across the boundary. With the exception of a couple of the .h files it'll just look like the .ino files were deleted and a bunch of new files were added.

casquad · Post by **casquad** » Mon Jun 17, 2013 8:55 pm

I agree that svn provides a great flexibility for code management. Nevertheless, there are great differences between real branching and commiting files to branches folder. First, when you commit new files, they are just that, new files. So if your trunk has a size of 1 MB, you checkout, modify and commit to some other branch, the size of the svn server is increased to 2 MB, while creating a new real branch does not increase the server load, because it is just a soft link. Only incremental changes are stored.

Second, the file changelog is lost, because files are commited as new files. With real branching you keep the complete log since each file was created. This is really usefull when you want to check what changes were introduced in that file before branching.

I work as a professional programmer for a multinational company. We are more than 200 developers in three countries and our last project has more than seven hundred thousand code lines. The branch-merge strategy is crucial for the success of the project, so it is the possibility of tracking the changes of a file, no matter in which branch that file is located (mainly to blame the programmer that introduced a bug) :-)

So even if svn has this great flexibility, I would suggest to follow some good practices in the use of the svn (for the good of the project).

I have some authentication problems in the svn to create the new branch, but as soon as it is solved, I will let you now so we can start working.

clough42 · Post by **clough42** » Mon Jun 17, 2013 9:27 pm

casquad wrote:So if your trunk has a size of 1 MB, you checkout, modify and commit to some other branch, the size of the svn server is increased to 2 MB, while creating a new real branch does not increase the server load, because it is just a soft link. Only incremental changes are stored.

Ahh...I think I see the confusion. Yes. If you check out, modify and then commit that copy into another path in the repository, it will indeed make a disconnected copy. This isn't usually how it's done, though. Usually, you would use the "svn copy" command to make a branch in the repository, which is just a new revision that links to the content and history of the original location. You would then check out (or switch to) the new branch and make incremental changes from there.

Unfortunately, SVN's use of the "svn copy" command for making a branch has created a lot of confusion.

And again, in this case, since the file set is changing, SVN won't be able to track the changes. Other, more sophisticated SCMs may handle this situation better, if they're aware of the file rename operations.

For those interested in learning more about SVN, the behavior is described pretty well here: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html

A quick excerpt from the above link:

Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects..

alll · Post by **alll** » Mon Jun 17, 2013 9:52 pm

So, when will the ino files be abandoned?
I suppose you will "freeze" the current ino-development, "copy" the branch, reorganize to .h and .cpp, test all possible coptertest (1..5), if they pass, we continue with the new file structure. Am i right?
manu

casquad · Post by **casquad** » Mon Jun 17, 2013 10:02 pm

Yes, that is. I could not have explained it better :-)

The idea is create linked copies in the svn server side (what I called "real branches"), so we can easily track the changes and merge them. This also makes bug tracking really easy and also identifying which branches are affected.

I do not think we need to change the file set. I have never tried this, but after branching I think we could use the svn command "move" to rename the files while preserving the connection to the old ones and so the changelog. Could anybody confirm this?

Just a small comentary about this: what it is called here MultiWii and MultiWii_shared (both under trunk), from my point of view they are clearly two different branches, where MultiWii_shared could be the trunk and MultiWii could be the "stable" branch where we could easily merge from time to time the latest features implemented and already tested in the trunk.

And please do not missunderstand me. I do not want to despise the excelent work that is being done in this project. I just want to share my experience so we can keep improving and learning. I really think the project has a great potential :-)

clough42 · Post by **clough42** » Mon Jun 17, 2013 10:43 pm

casquad wrote:I do not think we need to change the file set. I have never tried this, but after branching I think we could use the svn command "move" to rename the files while preserving the connection to the old ones and so the changelog. Could anybody confirm this?

Yes. I can confirm that SVN will track history across file renames. I created a new file, made a change and committed, then renamed (with TortoiseSVN right-click Rename), committed and then committed another change under the new name. Here's the history that SVN is showing for the file:

It shows as a file delete and a file add, but it's tracking the changes across the revision. A file compare between r57898 and r57900 shows the textual changes correctly.

This is SVN 1.7. I don't have commit rights to test in the MultiWii repo.

Sebbi · Post by **Sebbi** » Tue Jun 18, 2013 10:58 am

Is there a timeframe for this project? I'd very much like to persue my quest to have some form of abstraction layer in between, so the MultiWii code can run on different hardware (like some ARM boards which a both cheaper and faster than plain old Arduinos) ;-)

casquad · Post by **casquad** » Tue Jun 18, 2013 11:57 am

Could anoyone help me to create a new branch in the svn? I have been trying hundred times and I am giving up. I tried Tortoise gui and command line, both failed. This is what I do:

svn copy https://multiwii.googlecode.com/svn/trunk https://multiwii.googlecode.com/svn/bra ... pMigration -m "New branch for cpp/h migration" --username codetweaker83@gmail.com

This command has always worked for me in other projects. After pressing enter, it asks for password (I use the one generated from GoogleCode, not my account password), but it fails with no error, just promp for another username and password again and again. I think I have permission to create branches, but I am starting to doub it. I have check the repo history and there is one real branch "DaedalusFC", but I do now know how it was created...

clough42 · Post by **clough42** » Tue Jun 18, 2013 5:22 pm

casquad wrote:Could anoyone help me to create a new branch in the svn? I have been trying hundred times and I am giving up. I tried Tortoise gui and command line, both failed. This is what I do:

svn copy https://multiwii.googlecode.com/svn/trunk https://multiwii.googlecode.com/svn/bra ... pMigration -m "New branch for cpp/h migration" --username codetweaker83@gmail.com

This command has always worked for me in other projects. After pressing enter, it asks for password (I use the one generated from GoogleCode, not my account password), but it fails with no error, just promp for another username and password again and again. I think I have permission to create branches, but I am starting to doub it. I have check the repo history and there is one real branch "DaedalusFC", but I do now know how it was created...

Your command line looks right to me. I just tested on my own googlecode project, and was able to create a branch with:

svn copy https://boisefirstmediasuite.googlecode.com/svn/trunk https://boisefirstmediasuite.googlecode ... pMigration -m "New branch for cpp/h migration" --username clough42@gmail.com

You appear to have the same permissions in the MultiWii project as Guillaume, who created the DaedalusFC branch.

casquad · Post by **casquad** » Tue Jun 18, 2013 9:08 pm

Ok, I finally managed to create the branch. You can find it under:

https://multiwii.googlecode.com/svn/bra ... Migration/

The MultiWii_shared project has already been ported to cpp/h files. It is compiling in Arduino IDE and you can also create a project in Eclipse to compile it. I have only checked compilation with QUADX and MultiWiiMega board. Code size is a bit larger because some inline optimizations cannot be applied when compiling separately. Please feel free to checkout, test it and add your contributions. As you can see, the svn history of each file is preserved event though some of them have been renamed.

As first work to do, I would say testing the compilation with all board configurations and check the GPS and LCD files.

Hamburger · Post by **Hamburger** » Tue Jun 18, 2013 9:34 pm

casquad wrote:Code size is a bit larger because some inline optimizations cannot be applied when compiling separately.

Ah, 32u4 and 328p users as first casualties. Someone keen to see the migration happen did confirm about equal code size just on the pre-previous page in this thread when I had asked for that.

As first work to do, I would say testing the compilation with all board configurations and check the GPS and LCD files.

You can do the first step easily, does it compile the coptertest cases?

casquad · Post by **casquad** » Tue Jun 18, 2013 10:20 pm

In my case, original ino files resulted in 21712 bytes, while compiling cpp files size increased to 21856 bytes. I do not know if this 144 bytes are a big trouble for those who work on platforms with very limited resources. If so, they can use the trunk with the traditional ino files.

I am compiling coptertest cases. At this moment I have commited fixes for tests 1, 2 and 3. Tomorrow more...

clough42 · Post by **clough42** » Tue Jun 18, 2013 10:48 pm

Hamburger wrote:Someone keen to see the migration happen did confirm about equal code size just on the pre-previous page in this thread when I had asked for that.

I believe that was a comparison between Eclipse and the Arduino IDE. I don't think that was a comparison between the .ino files and .cpp files.

Hamburger · Post by **Hamburger** » Tue Jun 18, 2013 10:54 pm

very good progress.
Maybe you need function prototypes like these

Code: Select all

#line 1 "autogenerated"
#include "Arduino.h"
  void annexCode() ;
  void setup() ;
  void go_arm() ;
 void go_disarm() ;
 void loop () ;
   uint8_t isBuzzerON() ;
   uint8_t isBuzzerON() ;
 void alarmHandler();
  void alarmPatternComposer();
  void patternDecode(uint8_t resource,uint16_t first,uint16_t second,uint16_t third,uint16_t cyclepause, uint16_t endpause);
  void turnOff(uint8_t resource);
   void PilotLampSequence(uint16_t speed, uint16_t pattern, uint8_t num_patterns);
    void PilotLamp(uint8_t count);
  void blinkLED(uint8_t num, uint8_t ontime,uint8_t repeat) ;
    void setTiming(uint8_t resource, uint16_t pulse, uint16_t pause);
     void toggleResource(uint8_t resource, uint8_t activate);
      void i2CLedRingState() ;
      void blinkLedRing() ;
      void init_led_flasher() ;
      void led_flasher_set_sequence(uint8_t s) ;
      void inline switch_led_flasher(uint8_t on) ;
      static uint8_t inline led_flasher_on() ;
      void auto_switch_led_flasher() ;
   void led_flasher_autoselect_sequence() ;
   void init_landing_lights(void) ;
      void inline switch_landing_lights(uint8_t on) ;
      void auto_switch_landing_lights(void) ;
 void vario_signaling() ;
  void vario_output(uint16_t d, uint8_t up) ;
   uint8_t calculate_sum(uint8_t *cb , uint8_t siz) ;
  void readGlobalSet() ;
   bool readEEPROM() ;
  void writeGlobalSet(uint8_t b) ;
   void writeParams(uint8_t b) ;
  void update_constants() ;
  void LoadDefaults() ;
 void readPLog() ;
 void writePLog() ;
 void storeWP() ;
 bool recallWP(uint8_t wp_number) ;
 uint8_t getMaxWPNumber() ;
     void            clear() ;
    int32_t get_P(int32_t error, struct PID_PARAM_* pid) ;
    int32_t get_I(int32_t error, float* dt, struct PID_* pid, struct PID_PARAM_* pid_param) ;
        int32_t get_D(int32_t input, float* dt, struct PID_* pid, struct PID_PARAM_* pid_param) ;
    void reset_PID(struct PID_* pid) ;
   void GPS_I2C_command(uint8_t command, uint8_t wp) ;
   void SerialGpsPrint(prog_char* str) ;
    void GPS_SerialInit() ;
  void GPS_NewData() ;
  void GPS_reset_home_position() ;
 void GPS_reset_nav() ;
 void GPS_set_pids() ;
   int32_t GPS_coord_to_decimal(struct coord *c) ;
 int32_t wrap_18000(int32_t ang) ;
 void GPS_calc_longitude_scaling(int32_t lat) ;
 void GPS_set_next_wp(int32_t* lat, int32_t* lon) ;
 static bool check_missed_wp() ;
 void GPS_distance_cm_bearing(int32_t* lat1, int32_t* lon1, int32_t* lat2, int32_t* lon2,uint32_t* dist, int32_t* bearing) ;
 void GPS_distance(int32_t lat1, int32_t lon1, int32_t lat2, int32_t lon2, uint16_t* dist, int16_t* bearing) ;
 static void GPS_calc_velocity();
 static void GPS_calc_location_error( int32_t* target_lat, int32_t* target_lng, int32_t* gps_lat, int32_t* gps_lng ) ;
 static void GPS_calc_poshold() ;
 static void GPS_calc_nav_rate(uint16_t max_speed) ;
 static void GPS_update_crosstrack(void) ;
 static uint16_t GPS_calc_desired_speed(uint16_t max_speed, bool _slow) ;
  int32_t wrap_36000(int32_t ang) ;
 uint32_t GPS_coord_to_degrees(char* s) ;
 uint32_t GPS_coord_to_degrees(char* s) ;
 uint16_t grab_fields(char* src, uint8_t mult) ;
  uint8_t hex_c(uint8_t n) ;
  bool GPS_newFrame(char c) ;
      bool GPS_NMEA_newFrame(char c) ;
      void _update_checksum(uint8_t *data, uint8_t len, uint8_t &ck_a, uint8_t &ck_b) ;
      bool GPS_UBLOX_newFrame(uint8_t data);
    bool UBLOX_parse_gps(void) ;
  inline long _swapl(const void *bytes) ;
  bool GPS_MTK_newFrame(uint8_t data) ;
 void computeIMU () ;
  int16_t _atan2(int32_t y, int32_t x);
  float InvSqrt (float x);
 void rotateV(struct fp_vector *v,float* delta) ;
  void getEstimatedAttitude();
 uint8_t getEstimatedAltitude();
  char digit10000(uint16_t v) ;
 char digit1000(uint16_t v) ;
 char digit100(uint16_t v) ;
 char digit10(uint16_t v) ;
 char digit1(uint16_t v) ;
   void i2c_OLED_send_cmd(uint8_t command) ;
  void i2c_OLED_send_byte(uint8_t val) ;
  void  i2c_OLED_init(void);
  void i2c_OLED_send_char(unsigned char ascii);
  void i2c_OLED_send_string(const char *string);
 void i2c_OLED_send_logo(void);
 void i2c_OLED_Put_Logo(void);
  void i2c_OLED_set_XY(byte col, byte row) ;
  void i2c_OLED_set_line(byte row) ;
  void i2c_clear_OLED(void);
 void i2c_ETPP_init () ;
 void i2c_ETPP_send_cmd (byte c) ;
 void i2c_ETPP_send_char (char c) ;
  void i2c_ETPP_set_cursor (byte addr) ;
 void i2c_ETPP_set_cursor (byte col, byte row) ;
 void i2c_ETPP_create_char (byte idx, uint8_t* array) ;
 void ETPP_barGraph(byte num, int val) ;
 void i2c_LCD03_init () ;
 void i2c_LCD03_send_cmd (byte c) ;
 void i2c_LCD03_send_char (char c) ;
 void i2c_LCD03_set_cursor (byte col, byte row) ;
 void i2c_OLED_DIGOLE_init () ;
 void i2c_OLED_DIGOLE_send_byte (byte c) ;
 void i2c_OLED_DIGOLE_send_string(const char *string);
 void i2c_OLED_DIGOLE_printString(const char *string);
 void i2c_OLED_DIGOLE_printChar(char c);
 void i2c_OLED_DIGOLE_clear(void) ;
 void LCDprint(uint8_t i) ;
  void LCDprintChar(const char *s) ;
  void LCDcrlf() ;
 void LCDclear() ;
  void LCDsetLine(byte line) ;
   void LCDattributesBold() ;
   void LCDattributesReverse() ;
   void LCDattributesOff() ;
   void LCDalarmAndReverse() ;
   void LCDattributesBold() ;
   void LCDattributesReverse() ;
   void LCDattributesOff() ;
   void LCDalarmAndReverse() ;
   void LCDattributesBold() ;
   void LCDattributesReverse() ;
   void LCDattributesOff() ;
   void LCDalarmAndReverse() ;
  void LCDprintInt16(int16_t v) ;
 void lcdprint_uint32(uint32_t v) ;
  void initLCD() ;
  void __u8Inc(void * var, int16_t inc) ;
 void __s8Inc(void * var, int16_t inc) ;
 void __u16Inc(void * var, int16_t inc) ;
 void __s16Inc(void * var, int16_t inc) ;
 void __nullInc(void * var, int16_t inc) ;
  void __u8Fmt(void * var, uint8_t mul, uint8_t dec) ;
  void __u16Fmt(void * var, uint8_t mul, uint8_t dec) ;
 void __s16Fmt(void * var, uint8_t mul, uint8_t dec) ;
 void __uAuxFmt1(void * var, uint8_t mul, uint8_t dec) ;
 void __uAuxFmt2(void * var, uint8_t mul, uint8_t dec) ;
 void __uAuxFmt3(void * var, uint8_t mul, uint8_t dec) ;
 void __uAuxFmt4(void * var, uint8_t mul, uint8_t dec) ;
   void __uAuxFmt(void * var, uint8_t mul, uint8_t dec, uint8_t aux) ;
  void __s8BitsFmt(void * var, uint8_t mul, uint8_t dec) ;
   void __upMFmt(void * var, uint8_t mul, uint8_t dec) ;
 void ConfigRefresh(uint8_t p) ;
 void ConfigRefresh(uint8_t p) ;
 void configurationLoop() ;
 void LCDbar(uint8_t n,uint8_t v) ;
  void fill_line1_deg() ;
 void fill_line2_AmaxA() ;
  void output_V() ;
  void output_Vmin() ;
 void output_mAh() ;
 void fill_line1_cycle() ;
 void fill_line2_cycleMinMax() ;
 void output_fails() ;
 void output_annex() ;
 void output_checkboxitems() ;
 void outputSensor(uint8_t num, int16_t data, int16_t limit) ;
 void print_uptime(uint16_t sec) ;
 void fill_line1_gps_lat(uint8_t sat) ;
 void fill_line2_gps_lon(uint8_t status) ;
 void lcd_telemetry() ;
 void outputMotorServo(uint8_t i, uint16_t unit) ;
  void lcd_telemetry() ;
  void toggle_telemetry(uint8_t t) ;
   void dumpPLog(uint8_t full) ;
    void LCDnextline() ;
   void serviceCheckPLog() ;
 void writeServos() ;
 void writeMotors() ;
 void writeAllMotors(int16_t mc) ;
 void initOutput() ;
 void initializeServo() ;
   void initializeSoftPWM() ;
 int16_t get_middle(uint8_t nr) ;
  void mixTable() ;
 void configureReceiver() ;
   void rxInt() ;
 void  readSBus();
 void readSpektrum() ;
   uint16_t readRawRC(uint8_t chan) ;
 void computeRC() ;
  void initOpenLRS(void) ;
  void Config_OpenLRS() ;
 void Read_OpenLRS_RC() ;
 void Write0( void ) ;
 void Write1( void ) ;
 void Write8bitcommand(uint8_t command) ;
 uint8_t _spi_read(uint8_t address) ;
 void _spi_write(uint8_t address, uint8_t data) ;
 void RF22B_init_parameter(void) ;
 void send_read_address(uint8_t i) ;
 void send_8bit_data(uint8_t i) ;
  uint8_t read_8bit_data(void) ;
 void rx_reset(void) ;
  void to_rx_mode(void) ;
 void to_ready_mode(void) ;
 void to_sleep_mode(void) ;
    void frequency_configurator(uint32_t frequency) ;
 void Hopping(void) ;
  void checkPots() ;
 void spekBind() ;
  void i2c_init(void) ;
  void i2c_rep_start(uint8_t address) ;
  void i2c_stop(void) ;
  void i2c_write(uint8_t data ) ;
  uint8_t i2c_read(uint8_t ack) ;
  uint8_t i2c_readAck() ;
  uint8_t i2c_readNak(void) ;
  void waitTransmissionI2C() ;
  size_t i2c_read_to_buf(uint8_t add, void *buf, size_t size) ;
  size_t i2c_read_reg_to_buf(uint8_t add, uint8_t reg, void *buf, size_t size) ;
 void swap_endianness(void *buf, size_t size) ;
  void i2c_getSixRawADC(uint8_t add, uint8_t reg) ;
  void i2c_writeReg(uint8_t add, uint8_t reg, uint8_t val) ;
  uint8_t i2c_readReg(uint8_t add, uint8_t reg) ;
 void GYRO_Common() ;
 void ACC_Common() ;
  void i2c_BMP085_readCalibration();
  void  Baro_init() ;
 void i2c_BMP085_UT_Start() ;
 void i2c_BMP085_UP_Start () ;
 void i2c_BMP085_UP_Read () ;
 void i2c_BMP085_UT_Read() ;
  void i2c_BMP085_Calculate() ;
 uint8_t Baro_update() ;
  void i2c_MS561101BA_reset();
  void i2c_MS561101BA_readCalibration();
  void  Baro_init() ;
 void i2c_MS561101BA_UT_Start() ;
 void i2c_MS561101BA_UP_Start () ;
 void i2c_MS561101BA_UP_Read () ;
 void i2c_MS561101BA_UT_Read() ;
  void i2c_MS561101BA_Calculate() ;
 uint8_t Baro_update() ;
   void Baro_Common() ;
 void ACC_init () ;
  void ACC_getADC () ;
  void ACC_init () ;
  void ACC_getADC () ;
 void ACC_init () ;
  void ACC_getADC () ;
 void ACC_init () ;
  void ACC_getADC () ;
 void ACC_init();
  void ACC_getADC();
  void ACC_init() ;
  void ACC_getADC() ;
  void ACC_init();
  void ACC_getADC();
 void ACC_init () ;
    void ACC_getADC () ;
 void ACC_init();
  void ACC_getADC() ;
 void Gyro_init() ;
  void Gyro_getADC () ;
 void Gyro_init() ;
  void Gyro_getADC () ;
  uint8_t Mag_getADC() ;
      void Mag_init() ;
     void Device_Mag_getADC() ;
  void Mag_init() ;
      void Mag_init() ;
 void getADC() ;
 void Device_Mag_getADC() ;
      void Mag_init() ;
    void Device_Mag_getADC() ;
  void Gyro_init() ;
  void Gyro_getADC () ;
  void ACC_init () ;
  void ACC_getADC () ;
     void Device_Mag_getADC() ;
  void Gyro_init() ;
  void Gyro_getADC () ;
  void Gyro_init() ;
  void Gyro_getADC() ;
   void ACC_init () ;
   void ACC_getADC () ;
 void tinygps_query(void) ;
 void Sonar_init() ;
 uint16_t i2c_try_readReg(uint8_t add, uint8_t reg) ;
 uint16_t i2c_readReg16(int8_t addr, int8_t reg) ;
  void i2c_srf08_change_addr(int8_t current, int8_t moveto) ;
 void i2c_srf08_discover() ;
  void Sonar_update() ;
 inline void Sonar_init() ;
 void Sonar_update() ;
 inline void Sonar_init() ;
 inline void Sonar_update() ;
    void initSensors() ;
  uint32_t read32() ;
 uint16_t read16() ;
 uint8_t read8()  ;
  void headSerialResponse(uint8_t err, uint8_t s) ;
  void headSerialReply(uint8_t s) ;
  void inline headSerialError(uint8_t s) ;
  void tailSerialReply() ;
  void serializeNames(PGM_P s) ;
  void serialCom() ;
  void  s_struct(uint8_t *cb,uint8_t siz) ;
  void s_struct_w(uint8_t *cb,uint8_t siz) ;
 void evaluateCommand() ;
 void evaluateOtherData(uint8_t sr) ;
   unsigned char T_USB_Available();
  void serialize32(uint32_t a) ;
  void serialize16(int16_t a) ;
  void serialize8(uint8_t a) ;
  void UartSendData() ;
   bool SerialTXfree(uint8_t port) ;
  static void inline SerialOpen(uint8_t port, uint32_t baud) ;
  static void inline SerialEnd(uint8_t port) ;
  static void inline store_uart_in_buf(uint8_t data, uint8_t portnum) ;
  uint8_t SerialRead(uint8_t port) ;
   uint8_t SerialPeek(uint8_t port) ;
  uint8_t SerialAvailable(uint8_t port) ;
  void SerialWrite(uint8_t port,uint8_t c);
 void debugmsg_append_str(const char *str) ;
  static uint8_t debugmsg_available() ;
  static void debugmsg_serialize(uint8_t l) ;
 void debugmsg_append_str(const char *str) ;
#line 22 "/Volumes/Vault/Users/js/Documents/RC-Heli/TriWiiCopter/my56-r1430/dev/MultiWii/MultiWii.ino"

alll · Post by **alll** » Tue Jun 18, 2013 11:12 pm

not in bulk like that! The goal was to put the exposed ones per topic in the .h files, and the forward declarations at the top of the .cpp.

@casquad
i don't see how we could contribute/help in this process to migrate all to .h and .cpp. If you think or tell me how, let me know.
Thanks man, finally it is going to happen.
manu

timecop · Post by **timecop** » Wed Jun 19, 2013 12:55 am

While you're fixing stuff, please get rid of empty function declarations,
i.e. void foo(); -> void foo(void); valid in cpp maybe, not valid in C.
also, the former case allows you to have shit like:
void foo();
and later on
void foo(int foo, int bar)
{
blah;
}
Which would obviously be bad news.
So yeah, let's get that part fixed.

Also, why are we renaming to .cpp? There's no actual C++ code.

casquad · Post by **casquad** » Wed Jun 19, 2013 7:33 am

Well, Arduino IDE melts together all .ino files in one MultiWii.cpp file located in your temporal folder and uses avr-g++ to compile it. The Arduino library is also compiled in cpp, so I choose cpp as extension and compile it with avr-g++. So though Arduino follows a classic C code structure (no classes, no namespaces, etc), the code is actually compiled as C++.

Function declarations that do not take arguments should be left empty. For example, if you want to rename a function using a #define foo(), there is a big difference when the funcion is declared void foo(void) and void foo(), because the preprocessor actually sees the "void" as a parameter (while the cpp compiler does not). I do not know if this compiler supports function overload. I guess so, since it is cpp, but I have never tried it.

@Manu, I think the hardest part of the work is done, but I would need help to compile all examples and testcases, fix those that do not compile (mainly adding missing declarations in header files or at the top of the cpp file), extract the final file size to compare, and it would be nice if someone could test the resultant code in a real device and check that there are not secondary effects in runtime due to the compilation process. My board will be delivered in two or three weeks, so it is a long waiting.

timecop · Post by **timecop** » Wed Jun 19, 2013 7:38 am

casquad wrote:Function declarations that do not take arguments should be left empty. For example, if you want to rename a function using a #define foo(), there is a big difference when the funcion is declared void foo(void) and void foo(), because the preprocessor actually sees the "void" as a parameter (while the cpp compiler does not).

Um, no.
First of all you should never "rename" functions with #defines, second no no no, if function is void, then the declaration should reflect that, void foo(void); not void foo(); Just promotes lazy coding and has potentials for fuckups later on.

casquad · Post by **casquad** » Wed Jun 19, 2013 7:49 am

Well, that is your opinion. I have seen that in many projects and it is widely use in C/C++ (event though I agree with you it makes the code a bit messy).

Ok, I see your point. Function declaration in .h must follow the same convention that cpp definition. So if the cpp has the void, the h must also have it (opposite is the same). Yes, I agree with you in this part. Please feel free to correct unmatched definition<-->declaration.

timecop · Post by **timecop** » Wed Jun 19, 2013 7:57 am

lack of void in definition is probably just due to lazy copypasting thats been plaguing this project for years.
so if function takes no params = void = then it should be declared/defined as such.

casquad · Post by **casquad** » Wed Jun 19, 2013 9:16 am

Ok, I will try to detect empty declarations and add the void parameter. I use both ways indistinctly, but I agree with you that adding the void is safer.

@All developers: please take this into account when commiting new code to this branch.

alll · Post by **alll** » Wed Jun 19, 2013 10:04 am

Hi casquad,

What is the easiest way in Eclipse to « point/link » to the svn directory and have the core Arduino available?
Basically how do you create a new project in Eclipse , add source folder + arduino core libraries. Do you use the Arduino plugin or just the avr plugin?

I would prefer to have an Eclipse project that just points to my local svn multiwii directory. I want to avoid to copy the source files.

What’s the best approach?

Thanks,
Manu

casquad · Post by **casquad** » Wed Jun 19, 2013 5:03 pm

At first I thought about commiting the .project and .cproject to the svn so we could checkout the project directly from Eclipse, but this can be dangerous since we probably work on different local paths (and these files keep track of your local paths to compile the project).

I use the AVR plugin and two Eclipse projects: one to compile the Arduino sources (taken from from Arduino IDE) as a static library, and the other to compile and link the MultiWii project.

I want to create a step-by-step tutorial about setting up a working Eclipse for MultiWii so we all work in a similar environment, but I am a bit busy at work lately, so it will have to wait at least a couple of weeks.

clough42 · Post by **clough42** » Wed Jun 19, 2013 5:18 pm

casquad wrote:At first I thought about commiting the .project and .cproject to the svn so we could checkout the project directly from Eclipse, but this can be dangerous since we probably work on different local paths (and these files keep track of your local paths to compile the project).

I use the AVR plugin and two Eclipse projects: one to compile the Arduino sources (taken from from Arduino IDE) as a static library, and the other to compile and link the MultiWii project.

I want to create a step-by-step tutorial about setting up a working Eclipse for MultiWii so we all work in a similar environment, but I am a bit busy at work lately, so it will have to wait at least a couple of weeks.

I would love to have these setup instructions, too. I've been struggling with my environment for a couple of days now without ultimate success. I've got it more or less happy, but I'm still getting some renaming/truncation errors during linking.

casquad · Post by **casquad** » Wed Jun 19, 2013 6:50 pm

Try to link using avr-gcc (Eclipse sets avr-g++ as default linker). Also do not forget to add the math library (-lm)

alll · Post by **alll** » Wed Jun 19, 2013 9:56 pm

casquad wrote:Ok, I will try to detect empty declarations and add the void parameter. I use both ways indistinctly, but I agree with you that adding the void is safer.

@All developers: please take this into account when commiting new code to this branch.

I have eclipse working, but can't help there i cant' commit

manu

casquad · Post by **casquad** » Wed Jun 19, 2013 10:05 pm

I spend two days to create the branch and I found something really weird: I could finally commit from Tortoise while having my internet browser opened with my google account logged in. I do not know if this is related, but ever since, when I want to commit something I firstly log in my account. Maybe this can help you.

alll · Post by **alll** » Wed Jun 19, 2013 10:48 pm

I can't commit because i don't have an account / permission. (I have a google account)

timecop · Post by **timecop** » Thu Jun 20, 2013 12:43 am

alll wrote:I can't commit because i don't have an account / permission. (I have a google account)

Just post patches, people can commit them. It's not hard.

alll · Post by **alll** » Thu Jun 20, 2013 8:50 am

timecop wrote:
alll wrote:I can't commit because i don't have an account / permission. (I have a google account)

Just post patches, people can commit them. It's not hard.

Mmmm, i don't want to upload modified source files without the help of SVN, or did i misunderstood the "post patches".

COPTERTEST 1 - 3 currently works,
once GPS is there, changes have to be done
I will wait until it is cleared out how "we" can work togheter (distribute the work of reorganizing)

manu

Code: Select all

COPTERTEST=1
Device: atmega328p
Program:   12016 bytes (36.7% Full)
(.text + .data + .bootloader)
Data:        855 bytes (41.7% Full)
(.data + .bss + .noinit)

COPTERTEST=2
Device: atmega328p
Program:   19114 bytes (58.3% Full)
(.text + .data + .bootloader)
Data:       1274 bytes (62.2% Full)
(.data + .bss + .noinit)

COPTERTEST=3
Device: atmega328p
Program:   31788 bytes (97.0% Full)
(.text + .data + .bootloader)
Data:       1765 bytes (86.2% Full)
(.data + .bss + .noinit)

COPTERTEST=4
COPTERTEST=5
COPTERTEST=6

timecop · Post by **timecop** » Thu Jun 20, 2013 8:56 am

use tortoisesvn to generate "patch" file of your modifications and post them here.

alll · Post by **alll** » Thu Jun 20, 2013 9:33 am

Ok i see, thanks, manu

casquad · Post by **casquad** » Thu Jun 20, 2013 9:44 am

The problem of that approach is that we will never know who introduced a bug in the code, who did what or who is the responsible of a module. We only know who commited the patch, what makes him somehow "supervisor" over other developers work. This is safer in the sense that only a few people can commit, but it is also a bottleneck because these people could be overwhelmed at some points.

Avoiding this bottleneck is one of the purposes of branch-and-merge strategy in svn. This is a experimental branch at which (almost) everybody should be able to commit their contributions, and at some point (let's say, every six months), project responsibles perform a whole code review, validate the changes and merge them into a stable branch (at which they are the only ones allowed to commit into). After merge there is always a stabilization and testing period (usually a couple of weeks) because nobody is perfect and there could be hidden bugs. After stabilization and validation, we can optionally launch an official release.

I mean, I am not discovering anything new here, this is typical software project management.

alll · Post by **alll** » Thu Jun 20, 2013 5:11 pm

So, should i continue with "COPTERTEST=4"? I don't want to put an efford (with the help of the indexer

, if it will not be used aferwards, or somebody else is doing the same.
I think it is not that much work.

Waiting for feedback and coordination.

Thanks,
manu

casquad · Post by **casquad** » Thu Jun 20, 2013 6:07 pm

Could you get access to the CppMigration branch? This would be much more easy than posting patches here...

alll · Post by **alll** » Thu Jun 20, 2013 6:30 pm

Who did you gave the access, i or you can ask him?

alll · Post by **alll** » Fri Jun 21, 2013 8:34 am

I am busy trying to compile COPTERTEST=4 and got stucked on this one, any suggestion ?:

'timer0_overflow_count' was not declared in this scope Serial.cpp /MultiWii line 827 C/C++ Problem

defined in wiring.c of the Arduino library as
volatile unsigned long timer0_overflow_count = 0;

Serial.cpp :

Code: Select all

#include "Arduino.h"
#include "config.h"
#include "def.h"
#include "types.h"
#include "EEPROM.h"
#include "LCD.h"
#include "Output.h"
#include "MultiWii.h"

...
void store_uart_in_buf(uint8_t data, uint8_t portnum) {
  #if defined(SPEKTRUM)
    if (portnum == SPEK_SERIAL_PORT) {
      if (!spekFrameFlags) { 
        sei();
       uint32_t spekTimeNow = (timer0_overflow_count << 8) * (64 / clockCyclesPerMicrosecond()); //Move timer0_overflow_count into registers so we don't touch a volatile twice        uint32_t spekInterval = spekTimeNow - spekTimeLast;                                       //timer0_overflow_count will be slightly off because of the way the Arduino core timer interrupt handler works; that is acceptable for this use. Using the core variable avoids an expensive call to millis() or micros()
        spekTimeLast = spekTimeNow;
        if (spekInterval > 5000) {  //Potential start of a Spektrum frame, they arrive every 11 or every 22 ms. Mark it, and clear the buffer. 
          serialTailRX[portnum] = 0;
          serialHeadRX[portnum] = 0;
          spekFrameFlags = 0x01;
        }
        cli();
      }
    }
  #endif

I don't know what the comment suggest "Move timer0_overflow_count into registers so we don't touch a volatile twice"

in RX.cpp the variable "volatile unsigned long timer0_overflow_count = 0;" does not give this problem?

Code: Select all

#include "Arduino.h"
#include "config.h"
#include "def.h"
#include "types.h"
#include "Serial.h"
#include "MultiWii.h"

...
#if defined(SPEKTRUM)
void readSpektrum(void) {
  if ((!f.ARMED) && 
     #if defined(FAILSAFE) || (SPEK_SERIAL_PORT != 0) 
        (failsafeCnt > 5) &&
     #endif
      ( SerialPeek(SPEK_SERIAL_PORT) == '$')) {
    while (SerialAvailable(SPEK_SERIAL_PORT)) {
      serialCom();
      delay (10);
    }
    return;
  } //End of: Is it the GUI?
  while (SerialAvailable(SPEK_SERIAL_PORT) > SPEK_FRAME_SIZE) { // More than a frame?  More bytes implies we weren't called for multiple frame times.  We do not want to process 'old' frames in the buffer.
    for (uint8_t i = 0; i < SPEK_FRAME_SIZE; i++) {SerialRead(SPEK_SERIAL_PORT);}  //Toss one full frame of bytes.
  }  
  if (spekFrameFlags == 0x01) {   //The interrupt handler saw at least one valid frame start since we were last here. 
    if (SerialAvailable(SPEK_SERIAL_PORT) == SPEK_FRAME_SIZE) {  //A complete frame? If not, we'll catch it next time we are called. 
      SerialRead(SPEK_SERIAL_PORT); SerialRead(SPEK_SERIAL_PORT);        //Eat the header bytes 
      for (uint8_t b = 2; b < SPEK_FRAME_SIZE; b += 2) {
        uint8_t bh = SerialRead(SPEK_SERIAL_PORT);
        uint8_t bl = SerialRead(SPEK_SERIAL_PORT);
        uint8_t spekChannel = 0x0F & (bh >> SPEK_CHAN_SHIFT);
        if (spekChannel < RC_CHANS) rcValue[spekChannel] = 988 + ((((uint16_t)(bh & SPEK_CHAN_MASK) << 8) + bl) SPEK_DATA_SHIFT);
      }
      spekFrameFlags = 0x00;
      #if defined(FAILSAFE)
        if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0;   // Valid frame, clear FailSafe counter
      #endif
    } else { //Start flag is on, but not enough bytes means there is an incomplete frame in buffer.  This could be OK, if we happened to be called in the middle of a frame.  Or not, if it has been a while since the start flag was set.
      uint32_t spekInterval = (timer0_overflow_count << 8) * (64 / clockCyclesPerMicrosecond()) - spekTimeLast;      if (spekInterval > 2500) {spekFrameFlags = 0;}  //If it has been a while, make the interrupt handler start over. 
    }
  }
}
#endif

timecop · Post by **timecop** » Fri Jun 21, 2013 8:53 am

I don't understand what the question is, but if you need to access it from inside RX.cpp or whatever, just add it as extern?

extern volatile unsigned long timer0_overflow_count;

alll · Post by **alll** » Fri Jun 21, 2013 9:39 am

Yes i just added

Code: Select all

extern volatile unsigned long timer0_overflow_count;

in MultiWii.h

Just finished COPTERTEST=4

But COPTERTEST=3 Arduino-1.0.2 IDE gives a warning that hex is too big, in Eclipse it tells it is 97.0% Full !

So, how do we further proceed?
manu

COPTERTEST=1
Device: atmega328p
Program: 12012 bytes (36.7% Full)
(.text + .data + .bootloader)
Data: 855 bytes (41.7% Full)
(.data + .bss + .noinit)
*Arduino-1.0.2: 12012 bytes (out of 28672 bytes)

COPTERTEST=2
Device: atmega328p
Program: 19110 bytes (58.3% Full)
(.text + .data + .bootloader)
Data: 1274 bytes (62.2% Full)
(.data + .bss + .noinit)
*Arduino-1.0.2: 19110 bytes (out of 28672 bytes)

COPTERTEST=3
Device: atmega328p
Program: 31784 bytes (97.0% Full)
(.text + .data + .bootloader)
Data: 1765 bytes (86.2% Full)
(.data + .bss + .noinit)
*!!! Arduino-1.0.2: 31784 bytes (out of 28672 bytes) !!!

COPTERTEST=4
Device: atmega328p
Program: 25780 bytes (78.7% Full)
(.text + .data + .bootloader)
Data: 1689 bytes (82.5% Full)
(.data + .bss + .noinit)
*Arduino-1.0.2: 25780 bytes (out of 28672 bytes)

felixrising · Post by **felixrising** » Fri Jun 21, 2013 9:48 am

ask sebbi real nice http://sebbi.de/multiwii/ or setup your own continuous integration build server / jenkins...