New Multiwii Serial Protocol

LuFa · Post by **LuFa** » Fri Apr 13, 2012 7:47 am

Hi

At the moment i try to read the data from multiwii with the new Multiwii Protocoll .

But for the moment my programm doesnt work

I try it with this code :

Code: Select all

int Byte; 

void setup() {
  
  Serial.begin(115200); // Serial Monitor
  Serial1.begin(115200); // Mwii 

}

void loop() {

  /* Data request */
  Serial1.write('$');
  Serial1.write('M');
  Serial1.write('>');
  Serial1.write(102); // 9 DOF IMU Data Massage request
  
  /* Read Data from Mwii */
  while (Serial1.available() > 0) {
    
    Byte = Serial1.read();  
    Serial.println(Byte); // Print data from Multiwii
 
  }
 
}

can anyone help me ?

Thanks !

Hamburger · Post by **Hamburger** » Fri Apr 13, 2012 10:00 am

maybe your code is too fast? If the other side does not respond quickly enough, your while loop has nothing to execute. You may have to insert something like 'while (!Serial1.available() ) /*do nothing*/;'

dynai · Post by **dynai** » Fri Apr 13, 2012 2:26 pm

Hi,

would it be possible to have the communication on MEGA on Serial3 as well? or as an Option?
this would allow to permanently wire a zig-bee, bluetooth or APC 220 to that port

kind regards Christoph

JohnyGab · Post by **JohnyGab** » Fri Apr 13, 2012 5:14 pm

i'm going to try to integrate that into Rushduino OSD

Alexinparis · Post by **Alexinparis** » Sat Apr 14, 2012 12:33 pm

LuFa wrote:Hi

At the moment i try to read the data from multiwii with the new Multiwii Protocoll .

But for the moment my programm doesnt work

I try it with this code :

Code: Select all

int Byte; 

void setup() {
  
  Serial.begin(115200); // Serial Monitor
  Serial1.begin(115200); // Mwii 

}

void loop() {

  /* Data request */
  Serial1.write('$');
  Serial1.write('M');
  Serial1.write('>');
  Serial1.write(102); // 9 DOF IMU Data Massage request
  
  /* Read Data from Mwii */
  while (Serial1.available() > 0) {
    
    Byte = Serial1.read();  
    Serial.println(Byte); // Print data from Multiwii
 
  }
 
}

can anyone help me ?

Thanks !

Serial1.write('<');

Alexinparis · Post by **Alexinparis** » Sat Apr 14, 2012 12:35 pm

dynai wrote:Hi,

would it be possible to have the communication on MEGA on Serial3 as well? or as an Option?
this would allow to permanently wire a zig-bee, bluetooth or APC 220 to that port

kind regards Christoph

It would be possible, but currently the code can handle only one port via TX interrupt (needed for communication)
The mod should not be complicated

Synthex · Post by **Synthex** » Sun Apr 15, 2012 2:50 pm

Very good work Alex !!

By cons, when the link is bad, I receive incorrect values.
Do you use the checksum to validate incoming messages ?

just for information, there must be a display issue on GPS.

Alexinparis · Post by **Alexinparis** » Sun Apr 15, 2012 10:47 pm

Synthex wrote:Very good work Alex !!

By cons, when the link is bad, I receive incorrect values.
Do you use the checksum to validate incoming messages ?

just for information, there must be a display issue on GPS.

Hi,
Thank you for pointing me the GUI lat/long bug.
It was a typo in the GUI.

Every message with a data payload are checksummed, and the GUI should keep the old values until a good is received.
I don't have explanations for the moment about your "spike"

Hamburger · Post by **Hamburger** » Sun Apr 22, 2012 5:39 pm

Would that typo also explain why reset and calib.acc do not work in gui?

nhadrian · Post by **nhadrian** » Mon Apr 23, 2012 4:58 am

Hi, also there is possibly a BUG in debug values either on MW or GUI side because al the debug parameters are constantly zero and doesn't matter what I define in sketch for debug...
BR
Adrian

PatrikE · Post by **PatrikE** » Mon Apr 23, 2012 10:11 am

I dont have a baro but tested a walue on debug2 and it works

kos · Post by **kos** » Thu Apr 26, 2012 3:53 pm

i am unable to connect to mwc using the new serial protocol from MultiWii_dev_20120414.zip, witjout any modification .. i try with the gui , with the arduino ide console , with some python code , i try with 8mhz , 16mhz 328p with a usb ftdi and with a direct omap uart , i even boot in a real windows32 .. no luck .. the old serial work without a flaw , when i send back the char parsed in the code i can reach oldSerialCom, but it do not go in the header detection loop .. :'(

does anyone have the same issue ?

Bledi · Post by **Bledi** » Sun Apr 29, 2012 1:55 pm

Can you add "armed" to the datas

Alexinparis · Post by **Alexinparis** » Mon Apr 30, 2012 12:41 am

Bledi · Post by **Bledi** » Mon Apr 30, 2012 7:13 am

Thanks

I miss that

Hamburger · Post by **Hamburger** » Mon Apr 30, 2012 8:36 am

any update on the non-functioning 'Calib ACC' and 'Reset' buttons in GUI?
For whatever reason pressing any of these does not have any effect. Cannot currently test the 'Calib MAG' button. Triggering the ACC calibration via TX sticks combo still works, so that code in MWii on the arduino side is still working as expected. Just never gets triggered from GUI via Serial Protocol.

Alexinparis · Post by **Alexinparis** » Mon Apr 30, 2012 10:40 am

Everything is working fine on my side.
But I don't use extra features like telemetry, it's maybe the problem.

Tommie · Post by **Tommie** » Fri May 04, 2012 8:02 am

Any idea why the debug values are not working? I'm currently tinkering with a new I²C sonar and it'd be nice to see which values are generated by it.

kos · Post by **kos** » Mon May 07, 2012 4:01 am

when running at 8mhz the new serial protocol only seems to work at 57600bds :roll:

when running @112500 it never get after stateMSP==1 ..

Code: Select all

switch(c) {                                // header detection $MW<
          case '$':
            if (stateMSP == 0) stateMSP++; break;  // first octet ok, no need to go further
          case 'M':
            if (stateMSP == 1) stateMSP++; break;  // second octet ok, no need to go further
          case '<':
// we never get here ..
            if (stateMSP == 2) stateMSP++; break;  // third octet ok, no need to go further
        }

Hamburger · Post by **Hamburger** » Wed May 09, 2012 3:21 pm

The status display for the checkboxitems via highlighting the label to the left does not work for passThrough and Beeper. The data are not sent on the MWC side?

kos · Post by **kos** » Wed May 09, 2012 4:31 pm

kos wrote:when running at 8mhz the new serial protocol only seems to work at 57600bds

ok , this is caused by either the serial interupt library not handling long serial burst correctly or having the serialCom not fast enough .

solved by changing multiwiiconf to write char one by one

the new serial work on 328p 8Mhz 115200 with this modification

edit : not a good solution

Code: Select all

serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_IDENT);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_STATUS);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_RAW_IMU);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_SERVO);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_MOTOR);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_RC); 
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_RAW_GPS);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_COMP_GPS);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_ALTITUDE);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_BAT);
 serialize8('$');serialize8('M');serialize8('<');serialize8(MSP_DEBUG);
for(i=0;i<indTX;i++) {g_serial.write(char(outBuf_[i]));}

based on my experiment , this bug can lead to this beahaviour -> viewtopic.php?f=16&t=1666

one should monitor how many MSP_PACKET are never answerd

edit : still not happy with the way it work at 8mhz

copterrichie · Post by **copterrichie** » Fri May 11, 2012 6:49 pm

I am trying to figure out when and how this following subroutine is called and used. Any ideas? Seems to be useful but I see no evidence it is presently being used.

Thank you.

Code: Select all

void SerialWrite(uint8_t port,uint8_t c){
 switch (port) {
    case 0: serialize8(c);UartSendData(); break;                 // Serial0 TX is driven via a buffer and a background intterupt
    #if defined(MEGA) || defined(PROMICRO)
    case 1: while (!(UCSR1A & (1 << UDRE1))) ; UDR1 = c; break;  // Serial1 Serial2 and Serial3 TX are not driven via interrupts
    #endif
    #if defined(MEGA)
    case 2: while (!(UCSR2A & (1 << UDRE2))) ; UDR2 = c; break;
    case 3: while (!(UCSR3A & (1 << UDRE3))) ; UDR3 = c; break;
    #endif
  }

kos · Post by **kos** » Sat May 12, 2012 3:00 am

in LCD .. deprecated spoted

#elif defined(LCD_TEXTSTAR) || defined(LCD_VT100)
SerialWrite(0, i );

copterrichie · Post by **copterrichie** » Sat May 12, 2012 3:03 am

Thank you, I looked every where but the LCD file.

msev · Post by **msev** » Sat May 12, 2012 9:17 am

Sorry for the slight off-topic question, but on a MEGA board which has I think 3 serial ports, is it possible for using multiple at once,..

For example one for connecting an osd to the board, another for connecting and using a bluetooth board and the third for connecting the GPS for rth and position hold (gps would be shared between osd and multiwii).

Hamburger · Post by **Hamburger** » Sat May 12, 2012 10:47 am

kos wrote:in LCD .. deprecated spoted

#elif defined(LCD_TEXTSTAR) || defined(LCD_VT100)
SerialWrite(0, i );

what makes you call that deprecated? Is it not the standard way to output serial data anymore? By which strategy/implementation is it superseeded now?

copterrichie · Post by **copterrichie** » Sat May 12, 2012 10:58 am

I am looking at ways of sending the telemetry data to a different serial port on the mega

Serial0 - normal USB
Serial1 - PPM
Serial2 - GPS
Serial3 - ODS/Telemetry

Any help is greatly appreciated.

Thank you.

copterrichie · Post by **copterrichie** » Sat May 12, 2012 12:23 pm

Seems to me, I should be able to test for which port the require for data is coming from, then send the reply for that port.

Code: Select all

 while (SerialAvailable(0)) { <- Change to  (SerialAvailable(port)
    c = SerialRead(0); <- Change to SerialRead(port) 
.
.
.
tailSerialReply(); <- Change to tailSerialReply(port)
.
.
.

Correct?

copterrichie · Post by **copterrichie** » Sat May 12, 2012 3:09 pm

I made all of the required changes in the serial handler and it is working great. What I need now is a smart way to automatically switch the port number based upon which port requires servicing.

Code: Select all

void serialCom() {
  uint8_t i, c, port = 0; <- Need a smart way to change this number.
  static uint8_t offset,dataSize;
  
  while (SerialAvailable(port)) {
    c = SerialRead(port);

I need to be able to switch between port 0 and port 3, at present, I can manually change these numbers, compile and load the code.

PatrikE · Post by **PatrikE** » Sat May 12, 2012 6:19 pm

Code: Select all

if(rcData[AUX4]< 1500){port=0;}else{port=1;}

copterrichie · Post by **copterrichie** » Sat May 12, 2012 6:43 pm

Interesting, thank you.

However, I was thinking more along the likes of checking a flag or an Interrupt.

copterrichie · Post by **copterrichie** » Sun May 13, 2012 12:12 am

Question, using this example "UCSR0B |= (1<<UDRIE0);", how would I send data to Serial Port 3?

Thank you.

Edited: I got it now.

I need to add something similar to this to handle the port.

This is for Serial0, so I need to duplicate it for Serial3

Code: Select all

ISR_UART {
    if (headTX != tailTX) UDR0 = bufTX[tailTX++];  // Transmit next byte in the ring
    if (tailTX == headTX) UCSR0B &= ~(1<<UDRIE0); // Check if all data is transmitted . if yes disable transmitter UDRE interrupt
  }

Code: Select all

#if !defined(PROMICRO)
  ISR_UART {
    if (headTX != tailTX) UDR0 = bufTX[tailTX++];  // Transmit next byte in the ring
    if (tailTX == headTX) UCSR0B &= ~(1<<UDRIE0); // Check if all data is transmitted . if yes disable transmitter UDRE interrupt
  }
#if defined(MEGA)
  ISR_UART3 {
    if (headTX != tailTX) UDR3 = bufTX[tailTX++];  // Transmit next byte in the ring
    if (tailTX == headTX) UCSR3B &= ~(1<<UDRIE3); // Check if all data is transmitted . if yes disable transmitter UDRE interrupt
  }
#endif

copterrichie · Post by **copterrichie** » Sun May 13, 2012 2:34 am

Here is a copy of the draft Serial.ino, bench testing on Serial0 and Serial3. In theory, it can be configured to work on all of the four serials but there is only coded for Serial0 and Serial3.

Config.h File:

Code: Select all

// Serial Telemery Information Sent to another serial port (Mega)
#define TELEMERY_SERIAL 3
#define TELEMERY_BAUD 115200

Main File under Setup:

Code: Select all

#if defined(TELEMERY_SERIAL)
   SerialOpen(TELEMERY_SERIAL,TELEMERY_BAUD);
  #endif

And the attached Serial.ino file.

msev · Post by **msev** » Sun May 13, 2012 9:14 am

So this mod enables telemetry on serial 3 right? Are you going to send that data to yourself with bluetooth or what are you going to use it for?

copterrichie · Post by **copterrichie** » Sun May 13, 2012 3:34 pm

msev wrote:So this mod enables telemetry on serial 3 right? Are you going to send that data to yourself with bluetooth or what are you going to use it for?

No, it is going to the onboard Arduino nano for ODS and for Antenna tracking.

viewtopic.php?f=6&t=1611

Katch · Post by **Katch** » Sun May 27, 2012 5:52 pm

msev wrote:Sorry for the slight off-topic question, but on a MEGA board which has I think 3 serial ports, is it possible for using multiple at once,..

For example one for connecting an osd to the board, another for connecting and using a bluetooth board and the third for connecting the GPS for rth and position hold (gps would be shared between osd and multiwii).

This seems to have been overlooked. I'm also interested as I've started flying MEGAs and would like to make better use of its serial channels. Is this re-write going to enable xbee telemetry or at least the ability to pass serial communications off to a BT module on serial 2 or 3 (0 is standard and 1 is tied up with PPM SUM).

If this is not the intended functionality then I may start tinkering myself but I don't want to work something that is already being attended to.

With the now very functional and maturing GPS code I think telemetry is going to become more and more important as waypoint navigation becomes possible.

PS - very exciting time for MultiWii - my favourite and first choice for flying robots.

LuFa · Post by **LuFa** » Mon May 28, 2012 9:56 pm

Hi ,

i try to Controll the Mwii via the new Protocol .
i can read datas from multiwii without any proplems

but i cant send anythink to Mwii .
Can anyone tell me how i have to calculate the Checksum for send datas to Mwii ?
i use a second arduino to do this , a example code will be also very nice :mrgreen:

Thanks !

kos · Post by **kos** » Mon May 28, 2012 10:15 pm

you can grab the code from multiwii , look at serializeN() function

$M<[payloadlenght][mspId][payload][cheksum]

payloadlenght = payload / 8
cheksum = for (char c :payload){ checksum ^= int(c); }

ex : with mspId = MSP_SET_RC_TUNING the payload lenght is 7

here is java implementation that i use in myMultiWiiConf.pde, a liitle readable than the previous checksum calculation

Code: Select all

 // MSP_SET_RC_TUNING
      payload = new ArrayList<Character>();
      payload.add(char( round(confRC_RATE.value()*100)) ); 
      payload.add(char( round(confRC_EXPO.value()*100)) ); 
      payload.add(char( round(rollPitchRate.value()*100)) );
      payload.add(char( round(yawRate.value()*100)) );
      payload.add(char( round(dynamic_THR_PID.value()*100)) ); 
      payload.add(char( round(throttle_MID.value()*100)) );
      payload.add(char( round(throttle_EXPO.value()*100)) ); 
      requestMSP(MSP_SET_RC_TUNING,payload.toArray( new Character[payload.size()]) );

Code: Select all

//send with/without payload
void requestMSP(int msp, Character[] payload) {
  if(msp < 0) {
    return;
  }
  StringBuffer bf = new StringBuffer().append(MSP_HEADER);
  
  if (payload != null){
    bf.append(char(payload.length)).append(char(msp));
    byte checksum=0;
    for (char c :payload){
      bf.append(c);
      checksum ^= int(c);
    }
    bf.append(char(int(checksum)));
  }else{
    bf.append(char(msp));
  }

nicodh · Post by **nicodh** » Wed Jun 06, 2012 4:36 pm

Hello,
May I make a request for adding MSP_INFO to the protocol?

What I need, is to be able to diferentiate the type of board (8bits or 32bits) and maybe the firmware release (at least the date of compilation for example).

For example create a variable like boardtype that would be 8 or 32 depending on the type of processor.
I know that change the revision number would be a pain, so instead you could add the compilation date, which is included by the compiler at build time.

This way it would be possible to show or hide features (like the command line interpreter for 32bits version) in my android development and my all in one windows configurator.

I would really appreciate this. Thanks.

EOSBandi · Post by **EOSBandi** » Thu Jun 07, 2012 7:29 am

HI,
I commited a small change in the serial.ino, now it is able to process single commands. Perviously to finish a command processing it needed the first byte of the next command to come in.
EOSBandi

copterrichie · Post by **copterrichie** » Thu Jun 07, 2012 2:14 pm

EOSBandi wrote:HI,
I commited a small change in the serial.ino, now it is able to process single commands. Perviously to finish a command processing it needed the first byte of the next command to come in.
EOSBandi

EOSandi, AWE! This makes sense and explains allot.

Thank you.

Tommie · Post by **Tommie** » Thu Jun 07, 2012 7:13 pm

I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned :-)

Alexinparis · Post by **Alexinparis** » Thu Jun 07, 2012 7:45 pm

Tommie wrote:I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned

Hi,
Could you explain basically the mod principles ?
Have you also some idea about the way to code a non aware checkbox index gui ? (with strings inside the sketch)
I see the last changes you made, and I think we will have to think about it if the number grows too much.

EOSBandi · Post by **EOSBandi** » Thu Jun 07, 2012 8:57 pm

Alexinparis wrote:
Tommie wrote:I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned

Hi,
Could you explain basically the mod principles ?
Have you also some idea about the way to code a non aware checkbox index gui ? (with strings inside the sketch)
I see the last changes you made, and I think we will have to think about it if the number grows too much.

Hi Alex,
Even it's not addressed to me, I have some ideas about the GUI, pid's and checkboxes. What i'm currently working on is to make the gui (wingui) parameterized. I think about a def file which can be fed into the gui and which defines the PID's and the checkboxes. So if you change the code on the FC (reorder PIDs, checkboxes, add new ones), you only have to change the parameter file. Currently it's something like this :

Code: Select all

<?xml version="1.0" encoding="us-ascii"?>
<!-- This a config file for RC options for latest dev MultiWii Code-->
<CONFIG>
   <AUX_OPTION id="0"  name="LEVEL"    desc="Auto Leveling mode" />
   <AUX_OPTION id="1"  name="ALTHOLD"  desc="Altitude hold" />
   <AUX_OPTION id="2"  name="MAG"      desc="Heading hold with compass" />
   <AUX_OPTION id="3"  name="CAMSTAB"  desc="Camera Stabilisation" />
   <AUX_OPTION id="4"  name="CAMTRIG"  desc="Camera Trigger" />
   <AUX_OPTION id="5"  name="ARM"      desc="Arm motors" />
   <AUX_OPTION id="6"  name="RTH"      desc="Return to home" />
   <AUX_OPTION id="7"  name="POSHOLD"  desc="Position hold" />
   <AUX_OPTION id="8"  name="PASSTHRU" desc="Passthru for flying wings" />
   <AUX_OPTION id="9"  name="HEADFREE" desc="Head free mode" />
   <AUX_OPTION id="10" name="BEEPER"   desc="Activate beeper" />
   <AUX_OPTION id="11" name="LEDMAX"   desc="Maximum illumination" />
   <AUX_OPTION id="12" name="LANDLIGHT"   desc="Landing Lights" />
   
   <PID id="0" name="Roll" desc="Roll Rate control" />
     <P id="0" shown="true" min="0" max="20.0" prec="10" />
     <I id="0" shown="true" min="0" max="0.250" prec="1000" />
     <D id="0" shown="true" min="0" max="100" prec="1" />

    <PID id="1" name="Pitch" desc="Pitch Rate control" />
     <P id="1" shown="true" min="0" max="20.0" prec="10" />
     <I id="1" shown="true" min="0" max="0.250" prec="1000" />
     <D id="1" shown="true" min="0" max="100" prec="1" />
   
   <PID id="2" name="Yaw" desc="Yaw Rate control" />
     <P id="2" shown="true" min="0" max="20.0" prec="10" />
     <I id="2" shown="true" min="0" max="0.250" prec="1000" />
     <D id="2" shown="true" min="0" max="100" prec="1" />
   
   <PID id="3" name="Altitude" desc="Altitude hold control" />
     <P id="3" shown="true" min="0" max="20.0" prec="10" />
     <I id="3" shown="true" min="0" max="0.250" prec="1000" />
     <D id="3" shown="true" min="0" max="100" prec="1" />
     
   <PID id="4" name="PosHold" desc="Position Hold control" />
     <P id="4" shown="true" min="0" max="2.54" prec="100" />
     <I id="4" shown="true" min="0" max="2.54" prec="100" />
     <D id="4" shown="false" min="0" max="100" prec="1" />
     
   <PID id="5" name="PosHoldRate" desc="Position Hold Rate control" />
     <P id="5" shown="true" min="0" max="20.0" prec="10" />
     <I id="5" shown="true" min="0" max="2.54" prec="100" />
     <D id="5" shown="true" min="0" max="0.254" prec="1000" />
     
   <PID id="6" name="Navigation Rate" desc="Navigation Rate control" />
     <P id="6" shown="true" min="0" max="20.0" prec="10" />
     <I id="6" shown="true" min="0" max="2.54" prec="100" />
     <D id="6" shown="true" min="0" max="0.254" prec="1000" />
     
   <PID id="7" name="Level" desc="Autolevel control" />
     <P id="7" shown="true" min="0" max="20.0" prec="10" />
     <I id="7" shown="true" min="0" max="2.54" prec="100" />
     <D id="7" shown="true" min="0" max="100" prec="1" />
     
   <PID id="8" name="Mag" desc="Heading hold control" />
     <P id="8" shown="true" min="0" max="20.0" prec="10" />
     <I id="8" shown="false" min="0" max="2.54" prec="100" />
     <D id="8" shown="false" min="0" max="100" prec="1" />

    <PID id="9" name="Velocity" desc="Velocity control for Altitude hold" />
     <P id="9" shown="true" min="0" max="20.0" prec="10" />
     <I id="9" shown="true" min="0" max="2.54" prec="100" />
     <D id="9" shown="true" min="0" max="100" prec="1" />
     
</CONFIG>

Adding these definitions to the FC code and make them queryable also could work but will definitely cost a huge amount of memory (no AtMega328 any more for sure).

Pyrofer · Post by **Pyrofer** » Thu Jun 07, 2012 9:09 pm

Don't you dare leave the 328 out of this!
I will hunt you down and slap you silly if you do :p

Katch · Post by **Katch** » Thu Jun 07, 2012 9:22 pm

with Mega boards appearing out of china for $70 complete with 10 DOF it's not a bad time for people to think about upgrading.

kos · Post by **kos** » Thu Jun 07, 2012 9:39 pm

Alexinparis wrote:
Tommie wrote:I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned

Hi,
Could you explain basically the mod principles ?
Have you also some idea about the way to code a non aware checkbox index gui ? (with strings inside the sketch)
I see the last changes you made, and I think we will have to think about it if the number grows too much.

the gui can construct the gui base on what is found in the uploaded config.h
the gui can also construct all elements based on the recived msp messages

from my point of view : the difficult parts is changing how the params are stored and arranged in the eeprom and upgrading the serial code the efficient way ... the gui is the easy part

waiting for your technical design to adjust the gui

edit : we could also upload the firmware from the gui , that would ease the above technical proposal .

copterrichie · Post by **copterrichie** » Thu Jun 07, 2012 9:40 pm

With DIY, only limitation is one's imagination.

This is an ATmega1280 with a Nano on a project board to handle all of the house-keeping tasks. viewtopic.php?f=6&t=1611

Pyrofer · Post by **Pyrofer** » Thu Jun 07, 2012 9:44 pm

I bought an all in one board with a 328p on it, if we lose that I have to buy a new controller and imu, or another all in one, that's not cheap.

I imagine there are a lot of people that couldn't afford the change.

nicodh · Post by **nicodh** » Thu Jun 07, 2012 9:59 pm

Hi, well, after some mail discussion with tommie, I added the new checkboxes to my android app and at the same I manage to just show what is stored in the board. I mean, my app is basically designed for naze32 (multiwii 32bits port) so the latest tommie changes are not yet taken into account. So I decided to not show these 3 new checkboxes using the 3 byte from the serial code. It give me the number of checkbox items so I can erase the latest in case of diferent firmware.

For the upload firmware, I have a naze32 gui AIO that does exactly the same things as the android app, but for windows. It fetch the latest firmware from svn and update the board.

I can share my code of course, but it's visual basic, and it's not very clean.