The utility was written in Visual C#. I hope somebody familiar with C# is able to test the code in his failing setup and figure out the problem, nothing else, please don't ask me about of how integrate this code to another project because certainly I'm not an expert in C#. This code is intended for dudes that really have a basic knowledge in programming and believe can help. Just remember this code works perfectly in my PC, running Vista and using the Official FTDI cable.ArdupilotConfigTool.zip
Jordi - not a problem, glad to help. I'm still confused about one thing - what pin does the official DIY drones cable bring out, DTR or RTS? From the schematic on FTDI's site, I thought that it was RTS, in which case the Sparkfun board should work, and the official cable should not.
Either way, I'm hoping that pulling both low and adding the delay should solve everyone's problems.
I should explain a bit about what I've done here. I determined that my problems with uploading were due to the cable not resetting the ArduPilot. You should note that not all problems with uploading are due to this - as Chris mentioned above, you must also be sure that you have good electrical connections and the FTDI drivers are up to date.
I have two FTDI cables, the 5V breakout from Sparkfun and a TTL-232R-3V3. I think the latter came directly from FTDI, but I'm not positive. It has the same part number as the one from Adafruit and DIY Drones, but I am not certain it has the same functionality.
Anyways, the ArduPilot is designed to reset when pin 6 of the FTDI connector is driven low by the FTDI interface. On my sparkfun cable, pin 6 is wired to DTR on the FTDI chip, but on the other cable it is wired to RTS. The original config tool code enabled DTR to reset the AP, but did not do the same for RTS, so only the Sparkfun cable worked for me.
are what pull the DTR and RTS pins low (they are active low).
Furthermore, I was getting some errors when I uploaded to the AP with the shield connected. I have very limited test equipment available (a multimeter!), but I guessed that possibly the reset was not being pulled low enough for a long enough time to actually reset the board. So, I added in a delay with Thread.Sleep. As I noted before, this delay could probably be shorter, but I don't think it really hurts to be a bit extra long.
The lines:
serialPort1.DtrEnable = false;
serialPort1.RtsEnable = false;
return the reset pin to the hi state, so that the CPU can run and the upload can commence. I'm not certain these are needed, I'm still thinking about this...
Jordi,
Thanks for posting the source. I changed the function restart_Ardupilot in form.cs to the following, and now both of my FTDI cables work properly - I have a 5V sparkfun cable and a the TTL-232R-3V3 cable. I didn't mess around with different delays too much. I imagine the delay could be shorter and would still work.
I've attached an executable with this fix in it. If you are having problems uploading, please test and report back.
Just a note from following the discussion in other threads: if you're having trouble with your setup, check the following:
--Double-check your solder joints with a continuity checker, especially if you're using round pin connectors
--Make sure you're using the latest FTDI drivers
--Try it without the GPS connected.
Comments
Either way, I'm hoping that pulling both low and adding the delay should solve everyone's problems.
I have two FTDI cables, the 5V breakout from Sparkfun and a TTL-232R-3V3. I think the latter came directly from FTDI, but I'm not positive. It has the same part number as the one from Adafruit and DIY Drones, but I am not certain it has the same functionality.
Anyways, the ArduPilot is designed to reset when pin 6 of the FTDI connector is driven low by the FTDI interface. On my sparkfun cable, pin 6 is wired to DTR on the FTDI chip, but on the other cable it is wired to RTS. The original config tool code enabled DTR to reset the AP, but did not do the same for RTS, so only the Sparkfun cable worked for me.
The lines:
serialPort1.DtrEnable = true; //Restarts ardupilot
serialPort1.RtsEnable = true;
are what pull the DTR and RTS pins low (they are active low).
Furthermore, I was getting some errors when I uploaded to the AP with the shield connected. I have very limited test equipment available (a multimeter!), but I guessed that possibly the reset was not being pulled low enough for a long enough time to actually reset the board. So, I added in a delay with Thread.Sleep. As I noted before, this delay could probably be shorter, but I don't think it really hurts to be a bit extra long.
The lines:
serialPort1.DtrEnable = false;
serialPort1.RtsEnable = false;
return the reset pin to the hi state, so that the CPU can run and the upload can commence. I'm not certain these are needed, I'm still thinking about this...
Thank you very much!. =)
Thanks for posting the source. I changed the function restart_Ardupilot in form.cs to the following, and now both of my FTDI cables work properly - I have a 5V sparkfun cable and a the TTL-232R-3V3 cable. I didn't mess around with different delays too much. I imagine the delay could be shorter and would still work.
I've attached an executable with this fix in it. If you are having problems uploading, please test and report back.
private void restart_Ardupilot()
{
serialPort1.Open();
serialPort1.DtrEnable = true; //Restarts ardupilot
serialPort1.RtsEnable = true;
Thread.Sleep(1000);
serialPort1.DtrEnable = false;
serialPort1.RtsEnable = false;
serialPort1.Close();
}
ArduPilotConfigTool_Fix1.zip
--Double-check your solder joints with a continuity checker, especially if you're using round pin connectors
--Make sure you're using the latest FTDI drivers
--Try it without the GPS connected.
-
1
-
2
-
3
of 3 Next