Bug in FastSerial Library?
Hi guys,
I think I may have found a bug in the FastSerial Library...
In trying to get the CLI test to perform a XBee test, I found that no data was being written to the telemetry port, after checking my APM_Config.h settings, my XBee setup and hooking up my osciloscope up to the telemetry transmit pin, I turned to the code to start debugging...
I found that in the XBee test routine the line that should transmit the data read
Serial3.printf_P(PSTR("0123456789:;<=>?@ABCDEFGHIJKLMNO\n"));
and although this line was clearly directing output to serial port 3, the data was in fact coming back on serial port 1, I also found that using Serial3.printf instead worked fine.
I therefore looked in the FastSerial Library source, where these two functions are declared on the base class and found that in the printf_P function, the code was passing stdout instead of a pointer the local _fd member variable to the stdio vfprintf_P function (while in the printf routine this code was correct)
So, in the prinf_P routine, I replaced the line
i = vfprintf_P(stdout, fmt, ap);
with
i = vfprintf_P(&_fd, fmt, ap);
and this seemed to solve all my problems.
Since stdout seems to default to serial port 1, this would not have caused a problem when using Serial.printf_P and therefore would also only have affected the APM with it's multiple ports.
Any thoughts or collaborations on my findings, my c++ is a bit rusty so wanna be sure I am on the right track.
Thanks
Chris
London
Replies to This Discussion
-
AdminPermalink Reply by Thomas J Coyle III on -
Chris,
Nice work! Maybe you should file a bug report on the APM official repository: http://code.google.com/p/ardupilot-mega/issues/list
Regards,
TCIII
-
Permalink Reply by Chris Mulder on -
Thanks TC,
I will do ASAP (now that I know it's there, I'm a bit of a newb to APM)
Cheers
Chris
-
Permalink Reply by Chris Mulder on
-
Oh - also just found another fix/tip....
In the XBee test code (the test_xbee function in test.pde)....
Removing the \n from the string being transmitted will make the data match up perfectly with the data packets sent from the X-CTU software... the new line of code will look like:
Serial3.printf_P(PSTR("0123456789:;<=>?@ABCDEFGHIJKLMNO"));
Therefore the X-CTU range test results will now show 100% results and not average around 50%
Hope this helps....
Chris
London
-
DeveloperPermalink Reply by Randy on -
I'm pretty sure that DrZiplock fixed this bug a day or two ago.
https://code.google.com/p/arducopter/source/detail?r=685
Hopefully you'll see that if you download the latest version of the code from SVN.
-
Permalink Reply by Chris Mulder on
-
Thanks Randy,
Will install SVN and get latest ver. do fixes normally propagate between the aurducopter and standard fixed-wing source also?
Chris
-
DeveloperPermalink Reply by Randy on -
I didn't realise until you asked but the answer is YES!
apparently we use "externals" to link the arduCopter libraries to the arduPilotMega svn repository:
http://code.google.com/p/ardupilot-mega/source/browse/Sketchbook/tr...
-
3D RoboticsPermalink Reply by Chris Anderson on -
All these projects share the same libraries, so once they're fixed, they're fixed for everyone.
-
Permalink Reply by Chris Mulder on
-
Thank for all the help guys... much appreciated.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Andropilot Users Group
203 members
-
Melbourne
54 members
-
Spanish arducopter Users
88 members
-
Moderators
24 members
-
ArduPlane User Group
720 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
