New Multiwii Serial Protocol

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

Re: New Multiwii Serial Protocol

Postby 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
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby 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. :D

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
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby 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.
Attachments
MegaSerial.zip
Telemetry on Serial3
(4.69 KiB) Downloaded 319 times
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby 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?
msev
 
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: New Multiwii Serial Protocol

Postby 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
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby 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.
Katch
 
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: New Multiwii Serial Protocol

Postby 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 !
LuFa
 
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: New Multiwii Serial Protocol

Postby 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));
  }
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby 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.
nicodh
 
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Postby 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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby 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.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby 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 :-)
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby 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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby 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).
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby 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
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby 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.
Katch
 
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: New Multiwii Serial Protocol

Postby 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 .
Last edited by kos on Thu Jun 07, 2012 9:41 pm, edited 2 times in total.
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby 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
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby 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.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby 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.
nicodh
 
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Postby kos » Thu Jun 07, 2012 10:15 pm

visual basic is not cross platform
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby nicodh » Thu Jun 07, 2012 10:19 pm

Yes I know, but I couldn't code in anything else, sorry. I would love to do it in something more platform friendly but I know how to code in vb, so I code in vb.

If i was intelligent I would code it python or java, but I'm not. That's life.
nicodh
 
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Thu Jun 07, 2012 10:44 pm

The idea is to decouple firmware changes from GUI changes. If new items are added, every GUI has to be adapted; this is clearly unacceptable. The copter should be able to tell how many switchable functions are available and what their names are;This is what I am working on, and during this process, I am straightening out and cleaning the state machine handling the serial communication. The number of switch items is (sadly) limited, and therefore it should be _easy_ to remove unneeded functions from ones firmware without breaking every GUI on the planet. I do not need PASSTHRU, other people do not own GPS devices, but perhaps want additional servos etc. This can only be achieved by making GUI and firmware independent from each other.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby copterrichie » Thu Jun 07, 2012 11:09 pm

I always thought it was possible to have the serial structure as an .ini or something similar and the GUI could read this file for the format of of the serial stream. Thereby not requiring a GUI update for each new Firmware release. Also this .ini file could be used by any third party creating OSD and other useful tools.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby EOSBandi » Thu Jun 07, 2012 11:45 pm

Tommie wrote:The idea is to decouple firmware changes from GUI changes. If new items are added, every GUI has to be adapted; this is clearly unacceptable. The copter should be able to tell how many switchable functions are available and what their names are;This is what I am working on, and during this process, I am straightening out and cleaning the state machine handling the serial communication. The number of switch items is (sadly) limited, and therefore it should be _easy_ to remove unneeded functions from ones firmware without breaking every GUI on the planet. I do not need PASSTHRU, other people do not own GPS devices, but perhaps want additional servos etc. This can only be achieved by making GUI and firmware independent from each other.


Ok, there are two use cases :
First:
User sets in config which function is needed and which one is not, then not only the unneccessary code segments are removed but the checkboxes from the GUI also. From my point of view it's only a convinience function. Which helps declutter the GUI.

Second:
During development, spare the time and work spent for updating the GUI each time when a new checkitem or pid or other parameter is added.

We can add such functionality into the FC code itself, but if we consider all parameters (checkItems, Pid's, other params) there will be definitely a memory issue. So I still recommend to use an external ini file which can be parsed by the GUI.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby copterrichie » Fri Jun 08, 2012 12:04 am

Depending upon the available free memory in EEPROM, the Serial Stream data(Class) structure could be stored there and send to the GUI or other application upon boot up or request. The only problem I foresee is, it would be a two step flash process.

1. flash erase the EEPROM and write data structure.
2. Flash new firmware.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 1:56 am

EOSBandi wrote: During development, spare the time and work spent for updating the GUI each time when a new checkitem or pid or other parameter is added.

You are referring to GUI as if there were only a single one available; adding a new function to the copter firmware requires *all* GUIs to be updated, processing, android, swing etc.
Custom additions are made very difficult by this circumstance.
We can add such functionality into the FC code itself, but if we consider all parameters (checkItems, Pid's, other params) there will be definitely a memory issue. So I still recommend to use an external ini file which can be parsed by the GUI.

Some GUIs will be able to parse INI files, others won't. People having several copters probably do not want to juggle with multiple config files.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 1:58 am

I rewrote the state machine and generalized the protocol; I also added the names of the switchables to the copter firmware for testing purposes; here are my changes:
Firmware:
https://github.com/wertarbyte/multiwii- ... al_rewrite
GUI:
https://github.com/wertarbyte/multiwii- ... al_rewrite

Now every request has the following format:

$M<xyP*c

x: payload size
y: command type
P*: x bytes of arbitrary payload data
c: XOR checksum of {x,y,P*}

I abandoned requests without payload length specification to simplify the parser; it also allows the transfer of up to 255 bytes of data. I also included command type and payload size into the checksum to ensure a safer transmission.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 8:11 am

about decoupling GUI and firmware

I do understand the motives; dealing with a multilanguage (>=2) environment most often implies duplicate data, logic and other implementation details. It is error prone and feels 'unwanted'; the urge to avoid it almost always arises.
From past experience whichever way one decides on is a tradeoff between
- resource limitations ( strong influence for MWii)
- choice of environment, where the (single) master implementation goes into
- stretchability of the build environment (could do lots of code creation during the build )

Btw. it is/was good GUI practice to only grey out unused GUI items, _not_ hide them - look at the drop down menus of any serious program. It is about orientation. Think of people with more than one copter with different sensors & features.

Currently the discussion seems limited to the checkboxitems. I think if we strive for a real good solution, it should not stop here but include all GUI items (like various PIDs). At least all data that get stored in eeprom are likely candidates. Besides, for all of these the describing strings are present in the LCD code already.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 9:13 am

OK, I just finished the dynamic generation of the switch table in the GUI. Please check the links again I posted above and please test the code; it is working great on my copter, but I'd like a confirmation of that :-)
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 10:33 am

let me ask again:
what do you think does make the checkboxitems special in that exactly those get special treatment? See my post above.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 10:46 am

The checkbox stuff is the thing that I needed; feel free to add code for the other items as well.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 10:52 am

I checked compiled file sizes, due to the new serial code the resulting firmware is actually smaller than before, even when including the strings for aux labels.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 11:01 am

Tommie wrote:The checkbox stuff is the thing that I needed; feel free to add code for the other items as well.

sure, I've been following the later development. No need to tell me I can add code.

Question is: is this current approach suitable to be applied to _all_ parameters stored in eeprom or is it an isolated partial solution to an imminent problem you (like others before you) stumbled upon during a specific feature implementation.
I would much rather see the former, but I am not sure if resources are sufficient.

minor side effect
With your code, we now have about the same strings twice in the code, once for serial, once for lcd. not good. I guess that needs fixing before code goes productive.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 11:09 am

Tommie wrote:I checked compiled file sizes, due to the new serial code the resulting firmware is actually smaller than before, even when including the strings for aux labels.

:) good sales strategy; mixing two independent modifications' effects.
Care to guess how this will evolve when the strings-to-mwii-approach gets applied to all tunable parameters, that is everything stored in eeprom? To make it clear - I would like to see that, but I am not sure the resources are sufficient. That approach is pushing the memory burden to the weakest component - the tiny limited mcu.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 11:24 am

The question is: How many people will add new tunable parameters to the multiwii codebase? And how many will connect additional devices (camera, flashlight, rocket launcher) to their copter and want to control these additions via their TXs? I think it's far more desirable to add new component to the I²C bus, apply a patch to the firmware to access the new device and have new option appear magically in _every_ GUI, be it processing, android or whatever. It's not perfect solution, because ressources are limited, but it's whatn known in OSS circles as "scratching an itch".

The two modifications aren't completely independent as well; I did not want to rewrite the serial parser and protocol at first, but due to its completely pointless limitations (payload must be <100 Byte? Why?) and caveats (4th byte might be command type _or_ payload size? commnd not included in checksum? WTF?), I had to to facilitate my primary goal of adding the switch names.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 2:41 pm

Tommie wrote:The question is: How many people will add new tunable parameters to the multiwii codebase? And how many will connect additional devices (camera, flashlight, rocket launcher) to their copter and want to control these additions via their TXs? I think it's far more desirable to add new component to the I²C bus, apply a patch to the firmware to access the new device and have new option appear magically in _every_ GUI, be it processing, android or whatever. It's not perfect solution, because ressources are limited, but it's whatn known in OSS circles as "scratching an itch".

neither you nor I know where the load of future additions will occcur. My guess would be tunable parameters for whatever comes. It will not be limited to additional checkboxitems.
I think we should strive for a solution that fits general purpose, that is solve the dilemma of tunable parameters for unknown GUIs. You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.
The two modifications aren't completely independent as well; I did not want to rewrite the serial parser and protocol at first, but due to its completely pointless limitations (payload must be <100 Byte? Why?) and caveats (4th byte might be command type _or_ payload size? commnd not included in checksum? WTF?), I had to to facilitate my primary goal of adding the switch names.

I cannot comment on either of the implementations, not my beef.

The latest r864 gives me a GUI without the copter graphics, sensor values get hardly updated if at all.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 2:46 pm

You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.

So instead of taking a first step in the right direction, you are preferring to stand still and wait for the ATMega328p to magically grow an additional flash memory circuit?

Regarding the latest SVN release, did you update your GUI as well?
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 3:04 pm

Tommie wrote:
You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.

So instead of taking a first step in the right direction, you are preferring to stand still?

to answer in that tone of yours when you want to go to the moon climbing on a tree is your first step and your last
Did you update your GUI as well?

Yes, I can see the checkboxlabels.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Pyrofer » Fri Jun 08, 2012 3:18 pm

I had much fun climbing trees in my younger years, and yes it DID get me closer to the moon.
Every path does not need to be the final one. Otherwise I will just lay down in my coffin now and cut out all that wasted time in between.

It's dev, for trying things. If it doesn't work it will get replaced or fixed when it comes to it, just like the serial code did.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 3:23 pm

Hamburger wrote:
Tommie wrote:
You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.

So instead of taking a first step in the right direction, you are preferring to stand still?

to answer in that tone of yours when you want to go to the moon climbing on a tree is your first step and your last

But sitting in the tree (which is pretty fun, with or without gear, you should try it) I am nearer to the moon than someone standing on the ground, am I not? Both in terms of altitude and adventuresness.
Did you update your GUI as well?

Yes, I can see the checkboxlabels.

And since you cannot see the other stuff, you are probably not uing the latest version (which would be r865).
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 3:27 pm

I had much fun climbing trees in my younger years, and yes it DID get me closer to the moon.

the proverb is about going TO the moon, not getting CLOSER.
Every path does not need to be the final one

to that I agree.

For the time being I will stay away from current revisions and revert that copter back to an older version.

Cheers.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 3:31 pm

Tommie wrote:And since you cannot see the other stuff, you are probably not uing the latest version (which would be r865).

my updating the tree produced r864, it is only two hours later you submitted r865 'fix checksum calculation'. I can see now you bumped revs up to 868.

Have fun
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 3:35 pm

Hamburger wrote:
I had much fun climbing trees in my younger years, and yes it DID get me closer to the moon.

the proverb is about going TO the moon, not getting CLOSER.

Right. That's why Apollo 1 went straight for the moon. Boy, I remember Virgil Grissom being the first man on Earths natural satellite back in 1967; truly a day to remember.
For the time being I will stay away from current revisions and revert that copter back to an older version.

Because getting a matching pair of firmware and GUI is totally impossible? You are whining about size issues, the new code is actually smaller than the old one. If you have eny technical reasons for staying with the old version, feel free to discuss. You might not like the new functionality, but in how far does it impact your use?
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 4:26 pm

Tommie wrote:Because getting a matching pair of firmware and GUI is totally impossible? You are whining about size issues, the new code is actually smaller than the old one. If you have eny technical reasons for staying with the old version, feel free to discuss. You might not like the new functionality, but in how far does it impact your use?


I do not always like spending time fiddling with non-working revisions. The fix you eventually provided came after I had already struggled with the code. Seems code is currently undergoing major conversion,so I am just staying away this time and leave all the fun to you.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Pyrofer » Fri Jun 08, 2012 5:45 pm

If you want a stable code release, and to not have to fiddle, staying with the stable release and not using 'dev' is probably a good idea.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 08, 2012 5:58 pm

Tommie wrote:Because getting a matching pair of firmware and GUI is totally impossible? You are whining about size issues, the new code is actually smaller than the old one. If you have eny technical reasons for staying with the old version, feel free to discuss. You might not like the new functionality, but in how far does it impact your use?

So long as you keep submitting non working sets of code I will stay away from the trunk, yes.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 6:09 pm

It was a working set of code. The missing items in the GUI resulted from an issue regarding checksum calculation that only affected specific messages, not the core functionality - and only because someone thought re-introducing Strings into the serial communication of the Processing GUI (I removed them and explained in details why they were bad) was a good idea. Therefore, Java did calculate faulty checksums. It was a bug, something that happens during development.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 08, 2012 6:46 pm

To get back to the technical issues at hand, I just shrunk the serial transmit and receive buffers; it's probably not a good idea to waste 256+256+128 Byte just for serial communication if your controller only offers 2kB; I encountered a few memory overflows today that did not only make the memory overflow, but the copter fly away as well since the entire TX/RX routines were nuked; I had to throw myself into its path before it had a chance to shred any furniture. I reduced the buffer sizes for everyone not using a serial GPS; I do not have one, so I cannot test it, but the GUI communication works flawlessly with rather small buffers:

https://github.com/wertarbyte/multiwii- ... e826452872
Last edited by Tommie on Fri Jun 08, 2012 8:32 pm, edited 1 time in total.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby kos » Fri Jun 08, 2012 7:08 pm

Tommie wrote: someone thought re-introducing Strings into the serial communication of the Processing GUI

i think this is me .. ?

i do not beleive the issue is in the String, ... it is working with String in the two latest dev release ;)

http://code.google.com/p/multiwii/sourc ... iiConf.pde

this is what help , i use something equal ..

Code: Select all
    synchronized public static void decode(final byte input) {
        char c = (char) input;
                    checksum ^= c;
                inBuf[offset++] = (byte) (c);



edit : using String the way it was proposed is ok , the way you dot it now i ok .. the only point is not calling serial.write() for individual char in a for .. it will slow the gui too much
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 1 guest

cron