Open GoogleCodeExporter opened 8 years ago
I'M not an original APM1 owner to confirm, but it seems likely that the APM1
used Serial2 tied to a pinout labeled UART3. It seems that also that the
general documentation and practice was just adopted into the APM2 wiki.
I did more testing on APM2 Serial2 using the UserCode space in arducopter 2.5.5
and its 100%a clear that Serial2 is tied to UART2 pins on the APM2 board. Where
the connection (if available) for Seria3/UART3 is located on the board I'm
still not sure.
As a major component both hardware and software side, can we get this issue
prioritized?
I would be more than happy to participate however needed to
test/confirm/resolve the issue.
As a temporary work-around I wonder if its possible to simply re-route serial3
data to serial2?
Original comment by TuxI...@gmail.com
on 14 Jun 2012 at 11:22
Has any attempt been made to resolve this issue? In the Arduplane code it seems
Serial3=Serial2, somehow, somewhere. If I replace Serial3 with Serial2 in the
main ArduPlane.pde serial port configuration section, compile time errors occur:
////////////////////////////////////////////////////////////////////////////////
// Serial ports
////////////////////////////////////////////////////////////////////////////////
//
// Note that FastSerial port buffers are allocated at ::begin time,
// so there is not much of a penalty to defining ports that we don't
// use.
//
FastSerialPort0(Serial); // FTDI/console
FastSerialPort1(Serial1); // GPS port
#if TELEMETRY_UART2 == ENABLED
// solder bridge set to enable UART2 instead of USB MUX
FastSerialPort2(Serial3);
#else
FastSerialPort3(Serial3); // Telemetry port for APM1
#endif
In ArduPlane code, it is not well documented that the config.h file must be
changed to set TELEMETRY_UART2 to "ENABLED" instead of "DISABLED" and add the
following code to the serial port speeds section to get telemetry functional on
UART2 after performing the solder bridge modification:
//Start CTSi code
#ifndef SERIAL2_BAUD
# define SERIAL2_BAUD 57600
#endif
//End CTSi code
Hopefully this issue can be solved properly (replace serial3 with serial2)
and/or better documentation added to the wiki.
Original comment by samc9...@gmail.com
on 2 Aug 2012 at 3:52
Sam, I have tried my best as I am not much of an arduino programmer. I tried
hours of compiling changes to the code which compiled ok just no data from
serial2. I tried to redirect in userspace also which failed as I have no
complete understanding of the fastserial library. I called several times to
speak with 3dr and all I could get was an agreement that it is firmware related.
Original comment by TuxI...@gmail.com
on 3 Aug 2012 at 2:54
I also have just stumbled upon this issue. After hours of thinking I had my
XTEND set up incorrectly, I decided to modify the MultiSerialMega sketch to
send data out on all serial ports, and that helped me figure out that it was
the APM code itself that was not correct.
I will look through the code and see if I can fix this.
Original comment by mswil...@mtu.edu
on 8 Sep 2012 at 12:24
After going over the schematic for APM2.5.1 I can confirm that Serial3 connects
to dataflash. Made changes to the code so far to test things, but having
compilation problems -_-;
Original comment by mswil...@mtu.edu
on 8 Sep 2012 at 2:59
S0=USB
S1=GPS
S2=optical flow? I recall seeing this in various web sources. Unconfirmed.
S3=data flash confirmed by last member.
If the above is complete and true then there simply isn't a dedicated telemetry
port.
Perhaps they simply incorporated apm1 wiki documentation and firmare code into
apm2 documentation. I find it rather convient that the 3dr radio setup piggy
backs USB serial0. This also seemes to be the community workaround for xbee or
other hardware. This also leaves us with near zero user configurability. This
is much less less we might have been mislead by the documentation. :(
Original comment by TuxI...@gmail.com
on 8 Sep 2012 at 3:42
S2=Radio
Optical flow sensor is on the SPI bus I do believe (the 2x3 pin header next to
the USB port on APM2.5.1)
Original comment by mswil...@mtu.edu
on 10 Sep 2012 at 4:48
Original issue reported on code.google.com by
TuxI...@gmail.com
on 13 Jun 2012 at 12:59