Re: [Flightgear-devel] Bug with Protocol handling String fields?
Is it FlightGear not parsing correctly the string input? Maybe attaching to it any \n it receives as a part of the string? Yes. That code could use some cleanup. First, it calls the simgear io channel function readline() which simply uses \n as delimiter, not knowing about the line separator specified in the protocol file. Then, the \n is left in the buffer and thus processed with the last chunk. Just committed a quick fix which: 1) warns if given line separator doesn't end with a newline, and adds it 2) warns if any input data doesn't end with the expected line separator 3) strips the line separator from the input Ideally, we'd have to pass down the line separator to simgear, but that's for another time. Report if I have broken something. Thank you Csaba, I don't think I will report anything untill I can run a precompiled binary, I really never compiled FGFS and I don't think I will this time either (compiling this stuff is really far from my experience). Just tell me please if, when and where I can find a precompiled binary. Anyway, I appreciate the news, at least I know what's going on and can write my code acordingly. Now in order to avoid this bug I will use a workaround. I will comment extensively my code where this workaround has been used, so that in the future, when the bug will be wiped out off any FGFS binary, everyone (not just me) can erase it quickly and painlessly. Btw, it's the first time I ever programmed something that use a serial connection, I was wondering, who can I ask for suggestions. I just started reading stuff about it, and since I'm not using a physical serial connection (the Arduino board is connected to the PC with a usb cable, and the driver makes it appear to the system as a /dev/ttyACM0, it's a virtual serial port) much of the physical related aspects are non working. I'm reading about buffers, hardware control flow, synchronous and asynchronus data flow, there's a lot there and sometimes I can't discern what's related to my scenario and what's not. I have quite a few perplexity about all this stuff, and everything doc I find generally deals with physical serials. I could really use some help or at least some guide in order to avoid misunderstandings on my side. E.g. there's something not working quite right at this time regarding my serial data flow synchronization. I managed setting fgfs's serial input and Arduino's output at 30hz, that works relatively nice, but things get weird when FGFS expects data at 30Hz and Arduino sends it at different frequencies (variable in time, not fixed), it looks like FGFS sometimes reads it all with huge delay, some other freezes. I'd like to know more in order to get things done in a more elegant way. It's just a detail but I'm trying to figure out the whole panorama before committing to more complex interactions. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug with Protocol handling String fields?
I don't know if it's a bug or it's me (I think it's a bug), so I ask you for comments about that. I'm fooling around with an Arduino board that sends data to FGFS with a serial protocol: fgfs --generic=serial,in,30,/dev/ttyACM1,9600,arduino_serial_basic_input The protocol input sections is this: input line_separatornewline/line_separator var_separatortab/var_separator chunk nametemp_int/name typeinteger/type node/sim/arduino_integer/node /chunk chunk nametemp_string/name typestring/type node/sim/arduino_string/node /chunk /input Arduino sends data this way command: Serial.print(1\ta\n); Well, when I look in FGFS Property browser I see this: /sim/arduino_integer = '1' (int) /sim/arduino_string = 'a\n' (string) That's obviously wrong, there should be no \n after the a string! -- Strangely enough that does work right if I switch the integer and the string input chunks, so that the string field is received first. In fact, if I use this protocol: input line_separatornewline/line_separator var_separatortab/var_separator chunk nametemp_string/name typestring/type node/sim/arduino_string/node /chunk chunk nametemp_int/name typeinteger/type node/sim/arduino_integer/node /chunk /input And this Arduino output: Serial.print(a\t1\n); I get a correct property assignment, without any \n. /sim/arduino_integer = '1' (int) /sim/arduino_string = 'a' (string) - What am I missing (if that's the case)? Is it FlightGear not parsing correctly the string input? Maybe attaching to it any \n it receives as a part of the string? Or is it me still not understanding how Arduino sends those strings out on the serial line? - n.b. if I don't add a \n in Serial.print() fgfs gets confused because Arduino's Serial.print() doesn't add any \n by default. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug with Protocol handling String fields?
On Sat, Mar 5, 2011 at 6:09 PM, Roberto Inzerillo rob...@gmx.net wrote: Is it FlightGear not parsing correctly the string input? Maybe attaching to it any \n it receives as a part of the string? Yes. That code could use some cleanup. First, it calls the simgear io channel function readline() which simply uses \n as delimiter, not knowing about the line separator specified in the protocol file. Then, the \n is left in the buffer and thus processed with the last chunk. -- Csaba/Jester -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug with Protocol handling String fields?
On Sun, Mar 6, 2011 at 1:23 AM, Csaba Halász csaba.hal...@gmail.com wrote: On Sat, Mar 5, 2011 at 6:09 PM, Roberto Inzerillo rob...@gmx.net wrote: Is it FlightGear not parsing correctly the string input? Maybe attaching to it any \n it receives as a part of the string? Yes. That code could use some cleanup. First, it calls the simgear io channel function readline() which simply uses \n as delimiter, not knowing about the line separator specified in the protocol file. Then, the \n is left in the buffer and thus processed with the last chunk. Just committed a quick fix which: 1) warns if given line separator doesn't end with a newline, and adds it 2) warns if any input data doesn't end with the expected line separator 3) strips the line separator from the input Ideally, we'd have to pass down the line separator to simgear, but that's for another time. Report if I have broken something. -- Csaba/Jester -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
