If somebody else had ideas about using old APM1's and soon to become old APM2's for some different purpose than autopiloting - probably you will want to connect some hardware, right?

I have gone through what I could find of documentation, and measured what was not documented.

Here is a brief overview of the connections on APM1 and APM2 that are available, once external servo wires and external (voltage, current, airspeed etc.) sensors are removed. Especially the APM1 "oilpan" shield has many routed but unused pin connections.

Not included are: UARTs, SPI and I2C, as they are pretty obvious.

External ports APM1:

Where nothing else is mentioned, connections are to the ATMEGA2560.

APM1 PWM inputs:

PWM inputs IN0..IN8: PD0..PD7 on the PPM encoder ATMEGA328p. They are hardly useful for general purpose IO, as there is only the single PPM wire to communicate to the ATMEGA2560 via.

PL0 (ICP4) is the ATMEGA1280/2560 PPM input pin.

APM1 PWM outputs:

PWM output OUT1: PL4 (OC5B) via 220R resistor
PWM output OUT2: PL5 (OC5C) via 220R resistor
PWM output OUT3: PB6 (OC1B) via 220R resistor
PWM output OUT4: PB7 (OC1C) via 220R resistor
PWM output OUT5: PH5 (OC4C) via 220R resistor
PWM output OUT6: PH4 (OC4B) via 220R resistor
PWM output OUT7: PE5 (OC3C) via 220R resistor
PWM output OUT8: PE4 (OC3B) via 220R resistor
Unknown pin on oilpan: PB5 (OC1A)
Unknown pin on oilpan: PE3 (OC3A)

APM1 Analog:

A0: PF0 via 10k resistor

A1: PF1 via 10k resistor
A2: PF2 via 10k resistor
A3: PF3 via 10k resistor
A4: PF4
A5: PF5
A6 ("expansion port"): PF6
A7:("expansion port"): PF7

APM1 Other:

PD0, PD1 are I2C. PD2, PD3 are UART1. PE0, PE1 are UART0.
PG0 is SW1 the unused button (AFAIK completely ignored in Ardupilot soft).
PG1 is the "slider switch" (AFAIK completely ignored in Ardupilot soft).
PORTC is routed to Oilpan (JP14). PC0, PC1, PC2 are the three LEDs.

Which port is driving / did drive the relay? It is Arduino Pin47, PL2?

PE6, PE7 and PL6, PL7 are the Oilpan DIP switches (AFAIK completely ignored in Ardupilot soft).

External ports APM2:
Where nothing else is mentioned, connections are to the ATMEGA2560.

APM2 PWM inputs:

PWM inputs IN0..IN8: PB0..PB7 on the PPM encoder ATMEGA8U2. There is a serial connection between ATMEGA8U2 and ATMEGA2560, so a custom firmware on 8U2 could forward (slow) data to/from 2560 from/to the port.

PL1 (ICP5) is the ATMEGA2560 PPM input pin.

APM2 PWM outputs:
PWM output OUT1: PB6 (OC1B) via 220R resistor
PWM output OUT2: PB5 (OC1A) via 220R resistor
PWM output OUT3: PH5 (OC4C) via 220R resistor
PWM output OUT4: PH4 (OC4B) via 220R resistor
PWM output OUT5: PH3 (OC4A) via 220R resistor
PWM output OUT6: PE5 (OC3C) via 220R resistor
PWM output OUT7: PE4 (OC3B) via 220R resistor
PWM output OUT8: PE3 (OC3A) via 220Rk resistor

PB7 = OC1C (NOTE Ch.9 out is not supported in firmware!!!)

APM2 Analog:
A0-A7: PF0..PF7 = ADC0..ADC7 (used for analog signals)
A8: PK0 = ADC8
A9: PK1 = ADC9 or PB7 (default) jumper selectable. PB7 via 1k resistor.
A10: PK2 = ADC10 or PL4 (default) jumper selectable. PL4 via 1k resistor. PL4 = OC5B
A11: PK3 = ADC11 or PL5 (default) jumper selectable. PL5 via 1k resistor. PL5 = OC5C

I wrote a feature for ArduPlane that allows the home position to be somewhere else than where the APM was started. This is useful for flight under "flying line" rules or if you want to ready your plane in one place and fly it from another.

The feature was requested and discussed in this thread and here. My modified code is here.

The original APM behavior: Home position is set to one of the first positions the GPS reports after powerup. Even if you desired another position as home. The position is written into waypoint 0 too, so you will see the home position by (re)loading the mission into MP.

Modified behavior: There is a new parameter STICKYHOME_RAD, in meters. If the GPS position is nearer than this from waypoint 0, home will be se to waypoint 0. Otherwise it will remain unchanged and the controls will wiggle 3 times. This allows one to set an alternative home position without risking a flyaway of more than STICKYHOME_RAD meters. In this version, I have removed the servo wiggling at normal startup because I find it unnecessary and it makes my planes rock'n'roll at gyro calibration. Wiggling = something was not as expected.

Waypoint 0 is only overwritten if it was previously undefined. Reading the mission, the waypoint 0 read is the one last written. Any reason to change that?

There are a few console messages too. It appears that not all get though because they come in a too rapid succession. See init_home() in commands.pde.

The home altitude may be quite inaccurate too, because GPS takes some time to get altitude right. If you fly with pure baro altimeter (ALT_MIX=1) and you use relative-altitude waypoints, you will not be affected. Funny enough, this is default. I fly in hilly terrain and need to check my missions carefully against Google Earth etc. and therefore need absolute altitude. I often get home altitudes that are 100s of feet off, potentially disastrous if not rejected.

To try solve that problem, the altitude of waypoint 0 is also used. If the horizontal distance to waypoint 0 was OK, the GPS altitude is compared to the waypoint 0 ditto. If off by less than STICKYHOME_MAD (Max Altitude Deviation), the altitude of waypoint 0 is used for home. Else, the controls will wiggle 5 times.

So all in all

No wiggles: Waypoint 0 was undefined at startup, or both position and altitude were within bounds of waypoint 0
3 wiggles: Position was not within bounds of waypoint 0. GPS position and altitude were used for home3 wiggles:
5 wiggles: Position was within bounds of waypoint 0 but not altitude. GPS altitude was used for home. Recommended action if using absolute altitude: Wait a few minutes, try reset APM.

For consideration: When reading the mission, should the EEPROM stored waypoint 0 be returned as waypoint 0, or should the actually used home position (which is the same if within bounds)?

If postion is OK but altitude is off, should the APM go into a wait loop until altitude is OK?