New Multiwii Serial Protocol
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
Interesting, thank you.
However, I was thinking more along the likes of checking a flag or an Interrupt.
However, I was thinking more along the likes of checking a flag or an Interrupt.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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
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
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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:
Main File under Setup:
And the attached Serial.ino file.
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 589 times
Re: New Multiwii Serial Protocol
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?
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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
Thanks !
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
Thanks !
Re: New Multiwii Serial Protocol
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
$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));
}
Re: New Multiwii Serial Protocol
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.
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.
Re: New Multiwii Serial Protocol
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
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
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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).
Re: New Multiwii Serial Protocol
Don't you dare leave the 328 out of this!
I will hunt you down and slap you silly if you do :p
I will hunt you down and slap you silly if you do :p
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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
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
Re: New Multiwii Serial Protocol
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.
I imagine there are a lot of people that couldn't afford the change.
Re: New Multiwii Serial Protocol
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.
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.
Re: New Multiwii Serial Protocol
visual basic is not cross platform
Re: New Multiwii Serial Protocol
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.
If i was intelligent I would code it python or java, but I'm not. That's life.
Re: New Multiwii Serial Protocol
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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: New Multiwii Serial Protocol
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.
1. flash erase the EEPROM and write data structure.
2. Flash new firmware.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
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.
Re: New Multiwii Serial Protocol
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.
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.
Re: New Multiwii Serial Protocol
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
Re: New Multiwii Serial Protocol
let me ask again:
what do you think does make the checkboxitems special in that exactly those get special treatment? See my post above.
what do you think does make the checkboxitems special in that exactly those get special treatment? See my post above.
Re: New Multiwii Serial Protocol
The checkbox stuff is the thing that I needed; feel free to add code for the other items as well.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
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.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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?
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
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.
Re: New Multiwii Serial Protocol
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).
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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
Re: New Multiwii Serial Protocol
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?
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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.
Re: New Multiwii Serial Protocol
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
https://github.com/wertarbyte/multiwii- ... e826452872
Last edited by Tommie on Fri Jun 08, 2012 8:32 pm, edited 1 time in total.
Re: New Multiwii Serial Protocol
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