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

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

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

Postby alll » Sat Jan 12, 2013 9:32 pm

Hi,
I successfully (quick and dirty) managed to reorganized the sources *.c by using their *.h header files. Using the Arduino Eclipse plugin, i managed to compile it! The same code / headers do still compile in the Arduino IDE!

Using Eclipse CDT really helps understand and ease navigation, really!
CDT provides powerful features that make C/C++ development much easier such as search, code navigation and content assist. What makes these features work is CDT’s ability to analyze the user’s code, and the first step in analyzing code is to parse it.
http://wiki.eclipse.org/CDT/designs/Overview_of_Parsing


So my question : is there any demand for this? If yes, i will be pleased to share what i already did.

Some pictures of the result:

manu
Attachments
mwii_arduino_eclipse.png
CallHierarchy_loop.png
CallHierarchy_setup.png
Mwii-Eclipse-Arduino.png
Mwii-Eclipse.jpg
Last edited by alll on Mon Jan 14, 2013 11:13 pm, edited 1 time in total.
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Hamburger » Mon Jan 14, 2013 9:33 am

sure, go ahead and publish a complete set and include a description of your eclipse setup.
Should get us one step closer to portability of code.
Alex will not like the increased number of files/tabs in Arduino IDE?
User avatar
Hamburger
 
Posts: 2551
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby timecop » Mon Jan 14, 2013 9:41 am

If you're going to spend time doing that (and nothing is wrong with it, btw), go one step further and fully dump .ino stuff permanently.

I.e. rewrite everything as .c and .h files, then have ONE single multiwii.ino that does something like
#if arducrap
#include "blah.c"
#include "output.c"
etc
#endif

to ensure it builds in tarduino IDE.

I wish tarducopter guys would do this already, instead of writing retarded hacks to 'build' arduino stuff on command line.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Mon Jan 14, 2013 3:27 pm

Hamburger wrote:sure, go ahead and publish a complete set and include a description of your eclipse setup.
Should get us one step closer to portability of code.
Alex will not like the increased number of files/tabs in Arduino IDE?


+1 Agreed and Kudos to you Alll
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Tue Jan 15, 2013 11:46 pm

Hi,

Here the sources and headers (version21). I use the Eclipse Arduino plugin.
I managed to compile for #define COPTERTEST 1,2 and 3. For #define COPTERTEST 4 (GPS) i didn't (a big beast)!
I really think it is time to reorganize the mwii code and make more independent modules / functions. While doing this exercise, you see that references goes into all directions of the modules. Also the extensive usage of #defines / sub defines, to try to stay generic, doesn't ease the maintenance and readability.
There are too many dependencies imho. Sorry to be so negative, but i am still amazed how well mwii flies! A good reason to continue adding / improving the functionalities.

It would be nice to have this sort of structure:

Input data:
Reading/sampling raw rx,sensor,GPS,... data
Normalizing the input data: zero, scaling, ...
Transforming : mixing, PID, ...

Output data;
PWM, serial, ...

manu
Attachments
mwii_21 (2).zip
(130.34 KiB) Downloaded 122 times
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Hamburger » Fri Jan 18, 2013 11:37 am

The makefile mechanism adapted from the ardupilot project gives this list of autogenerated prototypes.
Maybe that is of some help to you.
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() ;
   void readEEPROM() ;
  void writeGlobalSet(uint8_t b) ;
   void writeParams(uint8_t b) ;
  void LoadDefaults() ;
 void readPLog() ;
 void writePLog() ;
     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(float y, float x);
  float InvSqrt (float x);
  int32_t isq(int32_t 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 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 lcdprint_int16(int16_t v) ;
  void initLCD() ;
  void __u8Inc(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 __upMFmt(void * var, uint8_t mul, uint8_t dec) ;
  void __upSFmt(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 writeServos() ;
 void writeMotors() ;
 void writeAllMotors(int16_t mc) ;
 void initOutput() ;
 void initializeServo() ;
   void initializeSoftPWM() ;
 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 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 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) ;


I did not check whether it works in Arduino IDE, but I would prefer to see one single .ino file and have the rest of code reside in *.[ch] world.
User avatar
Hamburger
 
Posts: 2551
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Fri Jan 18, 2013 5:13 pm

Question please: What would be the simplest way to incorporate Diffs or updates from the normal WMC code release?

Thank you.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby timecop » Sat Jan 19, 2013 3:45 pm

The idea is that if this method is accepted, it becomes the "normal code release", though I'm sure you knew that already.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sat Jan 19, 2013 4:21 pm

timecop wrote:The idea is that if this method is accepted, it becomes the "normal code release", though I'm sure you knew that already.


Yes, I don't believe it will be readily accepted but I personally want to start using it. As it stands right now, the stuff in development, I am not using at present, so there is little concern for me right now but in the event, there are some major changes/advancements, I would like to be able to update the base code here.

Thanks for the input.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 10:20 am

Alll, Question please. Once I have a compiled .elf file, How would I go about flashing the file to the Arduino? Can it be done from within Eclipse or will I have to use the avrdude?

Thank you.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 10:38 am

I figured it out. Thanks.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sun Feb 03, 2013 4:00 pm

avrdude is part of the arduino plugin. an whats the result?
manu
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 4:02 pm

First, I started out with some example code to make sure I have all of the plug-ins working correctly. That went well. Now I will attempt to compile your version of the MWC.

Will Keep you updated. Thank you.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sun Feb 03, 2013 4:33 pm

I always start with a new arduino template project, and the import/copy the arduino code in the project directory.
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 5:06 pm

Eureka!

Huston, we have liftoff.

Thank you.

Code: Select all
Building target: MWC_21.elf
Invoking: AVR C++ Linker
avr-gcc -Os -Wl,--gc-sections  -L"C:\Users\rev\workspace\Arduino_Duemilanove_w__ATmega328/Release" -mmcu=atmega328p  -o"MWC_21.elf"  ./Buzzer.o ./EEPROM.o ./IMU.o ./LCD.o ./LED.o ./MWC_21.o ./Output.o ./RX.o ./Sensors.o ./Serial.o   -l"Arduino_Duemilanove_w__ATmega328" -lm
Finished building target: MWC_21.elf
 
Invoking: AVR Create Extended Listing
avr-objdump -h -S MWC_21.elf  >"MWC_21.lss"
Finished building: MWC_21.lss
 
Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex MWC_21.elf  "MWC_21.hex"
Finished building: MWC_21.hex
 
Create eeprom image (ihex format)
avr-objcopy -j .eeprom --no-change-warnings --change-section-lma .eeprom=0 -O ihex MWC_21.elf  "MWC_21.eep"
Finished building: MWC_21.eep
 
Invoking: Print Size
avr-size --format=avr --mcu=atmega328p MWC_21.elf
AVR Memory Usage
----------------
Device: atmega328p

Program:   14966 bytes (45.7% Full)
(.text + .data + .bootloader)

Data:        811 bytes (39.6% Full)
(.data + .bss + .noinit)


Finished building: sizedummy
 

**** Build Finished ****
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 5:27 pm

Please correct me if I am wrong here, trying to learn this new method. It appears all that is required here is, to remain the .ino files to .cpp, create a project and make sure the following is included in the main file.

Code: Select all
// Do not remove the include below
#include "MWC_21.h" //name of the project
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sun Feb 03, 2013 5:46 pm

Wow, 45,7% that is a stripped version!
manu
copterrichie wrote:Eureka!

Device: atmega328p

Program: 14966 bytes (45.7% Full)
(.text + .data + .bootloader)

Data: 811 bytes (39.6% Full)
(.data + .bss + .noinit)


Finished building: sizedummy


**** Build Finished ****[/code]
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sun Feb 03, 2013 5:49 pm

google "c header file usage"
http://www.cs.cf.ac.uk/Dave/C/node35.html
http://gcc.gnu.org/onlinedocs/cpp/Header-Files.html

manu
copterrichie wrote:Please correct me if I am wrong here, trying to learn this new method. It appears all that is required here is, to remain the .ino files to .cpp, create a project and make sure the following is included in the main file.

Code: Select all
// Do not remove the include below
#include "MWC_21.h" //name of the project
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 5:49 pm

At this point, I am only loading Gyro and ACC, nothing else. :(
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 5:58 pm

Just thinking out loud here, if we were to make the various sensors, mixing and RC function modular, they could be linked by an external program and the end user would not have to use the IDE. In theory, there would be a config program and it would link the required modules files.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Hamburger » Sun Feb 03, 2013 7:52 pm

no big difference for the in-experienced in using the IDE or another program to configure required set of modules.
Obvious difference is that user friendly program does not exist yet.
User avatar
Hamburger
 
Posts: 2551
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Sun Feb 03, 2013 8:09 pm

It could also be a library. Hmmm
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Mon Feb 04, 2013 12:15 am

Don't cry victory too soon... ;)

I tried to upload the hex to the board, and it doesn't work in the gui, straight line... :( :( :( :(

Even if i compile in arduino ide, and upload, same thing :evil:

manu
PS:as said before, it was a quick and dirty try :roll:

copterrichie wrote:Eureka!

Huston, we have liftoff.

Thank you.
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Wed Feb 06, 2013 11:54 pm

EUREKA! :)

I could not compile in Eclipse the inline SerialOpen function, in Adruino IDE i got no problem. So removing the inline directive made it...??? Is there a compiler option to set?
//void inline SerialOpen(uint8_t port, uint32_t baud) {
void SerialOpen(uint8_t port, uint32_t baud) {
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Wed Feb 06, 2013 11:57 pm

:D
Attachments
ss003.png
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Wed Feb 06, 2013 11:59 pm

Congratulations! Let me see if I can repeat what you have done.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby copterrichie » Thu Feb 07, 2013 12:13 am

I am still getting nothing, will have a closer look later.
Attachments
MultiWiiConf_2_1.jpg
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Alexinparis » Thu Mar 14, 2013 3:22 pm

Hi,

As we are going on this way for the next release, I read a lot on this subject yesterday.

I think the way files are handle in your zip (alll) does not address fully the .c .h approach.
According to http://arduino.cc/en/Hacking/BuildProcess
every file with no extension (ie .ino files) are concatenated, a prototype is generated, and the big file is then compiled.

The proper way would be to use independent .c or .cpp so that they are compiled independently in .o.

So to my mind, the current file separation is good and should be adapted this way in a flat repositiory:
Alarms.ino -> replaced by Alarms.cpp + Alarms.h
EEPROM.ino -> replaced by EEPROM.cpp + EEPROM.h
GPS.ino -> replaced by GPS.cpp + GPS.h
IMU.ino -> replaced by IMU.cpp + IMU.h
LCD.ino -> replaced by LCD.cpp + LCD.h
MultiWii.ino -> we keep MultiWii.ino + MultiWii.h
Output.ino -> replaced by Output.cpp + Output.h
RX.ino -> replaced by RX.cpp + RX.h
Sensors.ino -> replaced by Sensors.cpp + Sensors.h
Serial.ino -> replaced by Serial.cpp + Serial.h
config.h -> same
def.h -> same
tinygps.h -> same


.cpp or .c : I don't know. All I know is Arduino interpret the .ino as a C++ file. The most convenient extension to avoid things like extern "C" {} seems to be .cpp

Of course adapting some c-style syntax to be friendly with other compiler/IDE is an option, but it must compiled as before with no customization in the Arduino IDE.

So, another zip would be welcomed :)


alll wrote:Hi,

Here the sources and headers (version21). I use the Eclipse Arduino plugin.
I managed to compile for #define COPTERTEST 1,2 and 3. For #define COPTERTEST 4 (GPS) i didn't (a big beast)!
I really think it is time to reorganize the mwii code and make more independent modules / functions. While doing this exercise, you see that references goes into all directions of the modules. Also the extensive usage of #defines / sub defines, to try to stay generic, doesn't ease the maintenance and readability.
There are too many dependencies imho. Sorry to be so negative, but i am still amazed how well mwii flies! A good reason to continue adding / improving the functionalities.

It would be nice to have this sort of structure:

Input data:
Reading/sampling raw rx,sensor,GPS,... data
Normalizing the input data: zero, scaling, ...
Transforming : mixing, PID, ...

Output data;
PWM, serial, ...

manu
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Tue Jun 11, 2013 6:39 pm

Hi Alex,
I am back on this topic, is it still ongoing?

I found a rather easy way to make changes to the mwii arduino ino file organisation to be able to use the code in Eclipse with the Arduino Eclipse plugin (at least the indexer is happy with it ;) :

    Install Eclipse for C/C++ developers
    1)Install the Arduino Eclipse Plugin
    2)be sure u can create "Arduino" projects from within Eclipse
    ...
    3)Create a new project and "Import" the mwii folder into a new "arduino" project

now you will see a lot of red indexer errors, to help him finding all references the basic idea is :

    1)make a "globalvar.h" header file where you copy most of the "static global" variables, enums, struct of the MultiWii.ino file
    2)in all *.ino files add on top
    Code: Select all
    #include "Arduino.h"
    #include "config.h"
    #include "def.h"
    #include "globalv.h"

    (be sure to add
    Code: Select all
    #ifndef DEF_H_
    #define DEF_H_
    ...
    #endif /*DEF_H_*/
    in all header files

thats it, only problem still have is with the serial library "HardwareSerial.cpp" with UCSR0B, ...
There is a comment in the cpp file:
Code: Select all
// this next line disables the entire HardwareSerial.cpp,
// this is so I can support Attiny series and any other chip without a uart
#if defined(UBRRH) || defined(UBRR0H) || defined(UBRR1H) || defined(UBRR2H) || defined(UBRR3H)


all after #if defined(...
is ignored?!

manu
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby clough42 » Thu Jun 13, 2013 5:21 pm

alll wrote:I am back on this topic, is it still ongoing?


I'm also interested in this effort.

I reorganized the MultiWii 2.1 code into .cpp/.h files late last year to see if it could be done. I ultimately got it working in Eclipse, but it didn't work well in the Arduino IDE, and the changes were such that it wasn't going to be possible for me to take ongoing changes from the repository or submit anything back and expect it to merge, so I abandoned it. I'm not really interested in hand-merging my own private copy of the code forever.

Alex said, "We are going this way in the next release." Is this effort in a repository somewhere? I.e. is there a branch I can check out?

I'd be happy to help if I can, but I realize I'm new here and I don't want to step on anyone's toes.
User avatar
clough42
 
Posts: 70
Joined: Sat Dec 08, 2012 6:10 pm
Location: Boise, Idaho

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Alexinparis » Thu Jun 13, 2013 10:01 pm

alll wrote:Hi Alex,
I am back on this topic, is it still ongoing?


Hi,

Yes, it's still ongoing, but in sleeping mode ;)

If it's just some file reorganization to be compliant with eclipse, I'm not interested
I'm interested in a proper way:
- c/h or C++/h so that things are compiled independently in .o
- compatible with current Arduino IDE with no mod
- compatibility with other IDE like eclipse is a bonus

So far, I didn't manage to make a draft.
I would like to see an example based on the current _shared.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby timecop » Fri Jun 14, 2013 1:16 am

To make it proper, the changes would have to be substantial. I don't think this is something one would do just to verify if concept is OK or not. Personally I'd suggest making a small test project with maybe one cleaned up driver (mpu) and no ifdefs /lcd/etc and make it work with tarduino ide requirement, then go from there.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alex.khoroshko » Fri Jun 14, 2013 3:33 pm

Hello!
I tried working in arduino IDE and it's such a pain. Eclipse idea is good, but it's still stuck with the bootloader. So I was always interested - why not just flash the good-old way, via USB ASP? Everyone can use at least AVR studio, which is way better, than arduino IDE.
As for files, it is common to divide into plenty of small files. For example, I would create separate file pid.c and pid.h. Create the data structure, used by pid (input, output, integrators, settings etc). So now, one code is being used for all pids. for example like:
Code: Select all
pAcroRoll_PID_def->input = someVar;
PID (pAcroRoll_PID_def);
anotherVar = pAcroRoll_PID_def->output;

pAcroPitch_PID_def->input = someVar2;
PID (pAcroPitch_PID_def);
anotherVar2 = pAcroPitch_PID_def->output;

Amagine, how much space that would save - one chunk of code for all the pids in the quad. This code is very easy to read (all the subcode is in pid.c, not main loop, for example), and also this implementation is very fast, because X Y Z registers are used for indirect addressing, and all data for PID is placed side-by-side in one RAM area. I have no idea, how to implemend that visually enough in current file structure.

Also, a bit offtopic - direct compile for the target hardware has plenty of options. I worked a lot with Cortex M3 and M4 processors and Eclipse IDE - direct compile / upload is awesome. For example, atmel Cortex M3 has USB driver - it can upload firmware by the software, provided by atmel (no programmer needed, just USB). Not only that, I have almost ready to use USB-ready bootloader for Atmel, Ti stellaris and STM32 cortex M4 processors. When the bootloader is there (this might be a problem for some platforms), you connect the board to PC, it detects as flash drive, copy the firmware.bin file, push the button - it is flashed (I used it for other tasks,it'll work this way as well). There should be enough RAM to accept the firmware though.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Hamburger » Fri Jun 14, 2013 4:32 pm

We can and do use eclipse already. There are several makefile environments which support arduino style compile and upload.

In your argumentation, please do not mix coding style and file layout&IDE - you can already use whatever data structure is appropriate - nothing to do with files.
User avatar
Hamburger
 
Posts: 2551
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Fri Jun 14, 2013 6:02 pm

Hi,

Here a first attempt to get multiwii (i took ver2.2) compiled from within Eclipse with the help of the Arduino Eclipse plugin.
The "MultiWii22" directory compiles still with the Arduino IDE (i tried all the 5 #define coptertests)
The Eclipse CDT indexer is happy with this structure (already a good start ;) ), however the build compiler/linker is not!
There are still "red bugs" when functions are "forward declared", i suppose this has something to do with the 1 pass indexer analyses?
If a more knowledge person can bring it one step further would be wonderful!

All i did:
    moved all global static variables of MultiWii.ino to MultiWii.h
    renamed MultiWii.ino to MultiWii22.ino from within eclipse (i used a directory named MultiWii22)
    added to all ino files :
Code: Select all
#include "Arduino.h"
#include "config.h"
#include "def.h"
#include "MultiWii.h"

    added to all xxx.h files
Code: Select all
#ifndef xxx_H_
#define xxx_H_
...
#endif // xxx_H_

Follow these instructions to get your Arduino projects done (upload via avrdude included) from within Eclipse
http://www.baeyens.it/eclipse/Install.html
in preferences asociate *.ino to cpp an c source files

In Eclipse:
    Create a new "Arduino" project in current workspace, name it "MultiWii22"
    Verify if it compile fine
    Clean project
    Rename Multiwii22.cpp to Multiwii22.ino (in preferences asociate *.ino to cpp an c source files)
    Close the Multiwii22 project
    In file explorer paste/copy all *.ino and *.h from the zip file into the working directory.
    Open project
    Refresfh folder
    Rebuild Indexes

Any suggestions are welcome.

I can say that getting the indexer parse the coditional compile directives makes the code so more readable, and i don't talk about the references search ... very helpfull.
Once i get it compile from within Eclipse, i could make eventual (modest) contributions with ideas i want to try out.

manu
PS: if a lot of people are already using Eclipse, could one share how they do it "STEP by STEP", thanks
Attachments
MultiWii22.zip
(139.02 KiB) Downloaded 56 times
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby casquad » Fri Jun 14, 2013 6:30 pm

Hello everybody,

I am new to this project and I have not found a specific forum to introduce myself to the rest of the team, so let me do it here. I have worked in embedded systems for the last five years, mainly for wireless sensor and automotive applications. I would like to build my own quadcopter in my free time and after googling some state-of-art open source flight control software, I decided to go for MultiWii. I have great experience in ARM and PPC platforms, but I have never worked with arduino-based platforms. As usual, the first thing I did was installing the tooling and downloading the source code from svn.

I must say that working with Arduino IDE is really painful (at least for a project of this size). I have always developed my code using eclipse so I installed the AVR plugin and manage to compile the MW project (not so hard once I saw what Arduino IDE was really doing in the background). During the job, I saw this thread and found it really interesting.

Keeping the source simple so it can be compiled easily in Arduino IDE is really helpful, but I agree with other developers here that given the current size of the project (and it looks it will keep growing), a new layout based on individual .c/.h files should be proposed. Is there any real planning to go into this direction? I would be glad to cooperate if necessary.

Regards
casquad
 
Posts: 29
Joined: Fri Jun 14, 2013 5:41 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby clough42 » Fri Jun 14, 2013 7:02 pm

alll wrote:The Eclipse CDT indexer is happy with this structure (already a good start ;) ), however the build compiler/linker is not!
There are still "red bugs" when functions are "forward declared", i suppose this has something to do with the 1 pass indexer analyses?
If a more knowledge person can bring it one step further would be wonderful!


I will take a crack at it tonight. I'd really like to see separate .c/.cpp and .h files for each of the existing .ino files, with proper forward declarations internal to each .c/.cpp file and only the external interfaces exposed in the .h files. I'm also imagining a separate globals.h file with extern declarations for the globals in multiwii.c/cpp.

It looks like things are fairly well organized already, so it shouldn't be too much of a slog, but it's tough to tell how much work is really involved without digging in and doing it.

The Arduino development environment makes it really easy to get something going quickly without a lot of software engineering experience. The automatic prototype generation makes it so you don't have to worry about forward declarations, but the downside is that you don't get any help keeping things encapsulated. It's really easy to cross-couple things without making an intentional decision to do so. This is probably off-topic. I'll take a look at the code tonight and report back.
User avatar
clough42
 
Posts: 70
Joined: Sat Dec 08, 2012 6:10 pm
Location: Boise, Idaho

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby casquad » Fri Jun 14, 2013 8:27 pm

I have taken a look at the code and I think we can modularize it progressively without breaking the Arduino IDE compilation. I would suggest following the next steps:

1) Extract all relevant type definitions into a common header file "types.h". There are currently variables that define the structure type in the declaration itself. This is a bad idea for modularization.
2) Create a header file for each module (eeprom.h, gps.h, imu.h, lcd.h, etc) containing variable and function declarations that are used outside the module
3) Include relevant header files in each .ino file (config.h, def.h, etc)

Of course, to avoid multiple inclusion all header files must be properly protected by "#ifndef _xxx_ #define _xxx_ ...".

But since I am new to the project, maybe I am missing something. Please let me know any comments.
casquad
 
Posts: 29
Joined: Fri Jun 14, 2013 5:41 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Fri Jun 14, 2013 8:48 pm

One of the "absolute" requirements is that all files are in a folder, you open the main ino file in the Arduino IDE, compile and upload.
And i don't know (maybe i understood it wrong) why they want to keep a absolute minimum of files...?

It is really nice to immediately see which functions/variable/structures are exposed and which are local.

Now with Eclipse like CDT code indexers, even if the code is not following the "common c way", you can still fairly well navigate and understand the logic better.

Come on, let's make it compile in both IDE's, so the moderaters will be convinced to follow. ;)

cross my fingers,
manu
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby casquad » Sat Jun 15, 2013 10:29 am

I have attached the MW project separated into cpp and h files. It is compiling both in Eclipse and Aduino IDE, so we can enjoy the wonderfull advantages of Eclipse: code navigation, sintax coloring, etc. I have only tested one configuration, but it is only a matter of resolving the dependencies between files and moving missing declarations to .h files.

Btw, I have checked the svn and branches are not real branches, but direct commits into the "branches" folder (the only real branch is DaedalusFC). This is completely against the principles of svn. How do you do the merges between branches or track the history of a file? Is there any responsible for the svn management? I have not tried to commit anything yet, do I need permissions to do it?
Attachments
MultiWii.7z
MW separated in cpp/h files
(113.15 KiB) Downloaded 62 times
casquad
 
Posts: 29
Joined: Fri Jun 14, 2013 5:41 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sat Jun 15, 2013 11:07 am

1000x thanks for this!!!!! And really happy to have a "professional" on board to guide us for the coding "best practices". Everybody, i am sure will benefit from it.

So we are a big step further ("we" : the ones that could only use the "crappy Arduino IDE"...) . I really hope the mwii "owners" take the afford now to make it true, and official asap. Most of the work is done, and proved to work.

All thanks,
manu
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sat Jun 15, 2013 12:07 pm

tested it out, its working, had to add some forward declares in sensors.
I have the whole Eclipse Arduino AVR toolchain working (upload via avrdude included!)

And it compiles still from within Arduino IDE

No exuses anymore to go further with it ;)

:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby casquad » Sat Jun 15, 2013 12:23 pm

I am glad to hear that :-)

I would like to make a step-by-step tutorial about how to integrate the MW project and arduino libraries in eclipse. It is not complex, but a bit tedious. I will upload it when I have it finished.

I am waiting for my board (I ordered it yesterday from Hobbyking), so at this moment the only test I can do is compiling. I do not know if there are side-efects on runtime, but I will be able to check it soon.

Who should take the decission of migrating the project to cpp/h files and perform the necessary testing?
casquad
 
Posts: 29
Joined: Fri Jun 14, 2013 5:41 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby timecop » Sat Jun 15, 2013 12:28 pm

casquad wrote:Btw, I have checked the svn and branches are not real branches, but direct commits into the "branches" folder (the only real branch is DaedalusFC). This is completely against the principles of svn. How do you do the merges between branches or track the history of a file? Is there any responsible for the svn management? I have not tried to commit anything yet, do I need permissions to do it?


hahaha..
lurkmoar, you'll learn that even uploading zip files into svn is ok.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sat Jun 15, 2013 1:06 pm

Try to stay positive, nobody is perfect, except ... ;)
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby casquad » Sat Jun 15, 2013 1:12 pm

Sorry, I was just trying to get familiar with the project and one of the most important aspects is the svn management. I was thinking about creating a new branch for cpp/h migration without affecting the trunk development, and merge the migration into the trunk at some point in the future. I did not mean to offend anybody.
casquad
 
Posts: 29
Joined: Fri Jun 14, 2013 5:41 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby timecop » Sat Jun 15, 2013 1:26 pm

No offense meant, sorry if it sounded that way.
But yes, SVN is not used like that here.
Basically you'd replace MultiWii_shared with C version and go from there.
But it's too major of a change, so it would need others approval.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby casquad » Sat Jun 15, 2013 1:58 pm

No problem at all :-) English is not my native language, and sometimes happens that I missunderstand some expressions. I apologize.

As I said, I would suggest creating a new branch "branches/CppMigration" from "trunk/MultiWii_shared" and use this branch for our "crazy" idea of migrating MW to cpp/h files. After our job is finished, approvals will be able to take the decission of merge this branch into the trunk or keep both development lines open so each developer may choose whatever he wants (classical Arduino IDE with ino files or Eclipse with cpp files).

If the branch is properly created, it should be easy to merge improvements and new features from trunk to branch and viceversa. We can create the branch with a simple command:

svn copy http://multiwii.googlecode.com/svn/trunk http://multiwii.googlecode.com/svn/bran ... pMigration -m "Created new branch for cpp/h migration"

I can commit my code with Alll modifications to this new branch, so other developers can contribute to develop the C code without breaking the trunk. I would be glad to cooperate if project managers like this way.
casquad
 
Posts: 29
Joined: Fri Jun 14, 2013 5:41 pm

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby alll » Sun Jun 16, 2013 6:59 am

To keep track of all these boards and features

Code: Select all
/*************************************************************************************************/
/****           config.h : CONFIG files selector                                                      ****/
/*************************************************************************************************/
#ifndef CONFIG_H_
#define CONFIG_H_

#include "CRIUS_LITE_test301205.h"
//#include "CriusSEi2cGPS_v01.h"
//#include "FREEIMUv043_v03.h"

#endif /* CONFIG_H_ */


manu
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Reorganising source *.c code with *.h headers; Eclipse I

Postby Alexinparis » Sun Jun 16, 2013 12:57 pm

Hi,

It seems you managed to do it :)
There are apparently still some tweaks to add, but the principle is exactly what I have is mind.

So to go further:

1) You can create a branch or folder (pm me with a valid email for googlecode access, because yes you need a permission for it). But the counterpart is you will have to update this branch regularly with _shared evolution until everything is fine. Once it's ok, _shared will be replaced by this branch.

2) If not too long, we can decide to freeze _shared evolution for some days until you finalize the full port work. Once done, we just have to replace the _shared folder and continue with this.

Things should at least work with all coptertest variant to think about a switch.
This page is a good indicator for configs: http://sebbi.de/multiwii/



casquad wrote:I have attached the MW project separated into cpp and h files. It is compiling both in Eclipse and Aduino IDE, so we can enjoy the wonderfull advantages of Eclipse: code navigation, sintax coloring, etc. I have only tested one configuration, but it is only a matter of resolving the dependencies between files and moving missing declarations to .h files.

Btw, I have checked the svn and branches are not real branches, but direct commits into the "branches" folder (the only real branch is DaedalusFC). This is completely against the principles of svn. How do you do the merges between branches or track the history of a file? Is there any responsible for the svn management? I have not tried to commit anything yet, do I need permissions to do it?
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Next

Return to Software development

Who is online

Users browsing this forum: Exabot [Bot], Google [Bot] and 1 guest

cron