I have been working with PaulB on things Arduino with his Bare Bones Board. Paul was initially dismayed because the FTDI TTL-232 cable he uses only supports RTS/CTS, no DTR, and felt that 'autoreset' was out without a redesign or a hack on the IDE. I harbored a suspicion that we might be OK after all, that there might be a simple fix.
So few devices implement a complete set of signals that many drivers have RTS and DTR chained together, either hard coded or someting user configurable. I suspected that the FTDI cable and its driver having only RTS/CTS just might be that way and that it would respond by flagging RTS when commanded to flag DTR. So having nothing to loose but a $0.05 cap and a minute with the soldering iron, I took a 0.1 uF cap with long leads and ran it from pin 6, farthest right from the reset switch (the green wire on the FTDI cable) over to the reset switch and tack soldered it to the side.
I fired up Arduno-0009 and sure enough, I got a reset and a program load, but with the usual interminable wait for the timeout.
I took out my avrisp mkii and my burning jig and burnt a Diecimilia Bootloader and 'voila' I had a Bare Bones Board with autoreset and instant start. This simple modification will work for Rev B and Rev C Bare Bones Boards.
Its a real clean hack and doesn't look bad either. I will take pictures tomorrow.
I have developed an inexpensive (kit is $4, 3/$10) serial adapter called the P3 that can be used to program the BBB as well as me a 232/TTL interface that Paul and I will begin marketing next week, my goal tomorrow (oooops, later today) is to adapt that for auto-reset ...
So few devices implement a complete set of signals that I suspected that the FTDI cable and its driver having only RTS/CTS just might respond by flagging RTS when commanded to flag DTR. So I took a 0.1 uF cap with long leads and ran it from pin 6, farthest right from the reset switch (the green wire on the cable) over to the reset switch and tack soldered it to the side.
I fired up Arduno-0009 and sure enough, I got a reset and a program load, but with the usual interminable wait for the timeout.
cool! i added this to my clone before i sent it out for prototype manufacture, on the same suspicion but havent had time to check it out. i will try it out myself, too.
I have developed an inexpensive (kit is $4, 3/$10) serial adapter called the P3 that can be used to program the BBB as well as me a 232/TTL interface that Paul and I will begin marketing next week, my goal tomorrow (oooops, later today) is to adapt that for auto-reset ...
whats the TTL interface, is it a MAX232 based thing or a FTDI based thing?
So few devices implement a complete set of signals that I suspected that the FTDI cable and its driver having only RTS/CTS just might respond by flagging RTS when commanded to flag DTR. So I took a 0.1 uF cap with long leads and ran it from pin 6, farthest right from the reset switch (the green wire on the cable) over to the reset switch and tack soldered it to the side.
I fired up Arduno-0009 and sure enough, I got a reset and a program load, but with the usual interminable wait for the timeout.
cool! i added this to my clone before i sent it out for prototype manufacture, on the same suspicion but havent had time to check it out. i will try it out myself, too.
hmm was not successful in the attempt. which driver are you using? im using the 'FTDI VCP" standard and it doesnt twiddle RTS, checked with my scope. doenst do the right thing with Arduino 009 Alpha either. it would be trivial to make the Arduino software twiddle RTS as well as (or instead of) DTR
maybe it could be a preference in the next version?
I have developed an inexpensive (kit is $4, 3/$10) serial adapter called the P3 that can be used to program the BBB as well as me a 232/TTL interface that Paul and I will begin marketing next week, my goal tomorrow (oooops, later today) is to adapt that for auto-reset ...
whats the TTL interface, is it a MAX232 based thing or a FTDI based thing?
limor
No its some resistors and a diode feeding a two gates of a hex inverter, which is why an hour ago I made it work with auto reset with just the addition of 2 10k resistors and a cap and one of the heretofore unused gates on the 74HC04.
Max23x is an 'expensive' proposition, if you use the 232 you are paying in real estate with 5 electrolyics, if you use the 233, you paying in cash with an expensive chip. I took the front end used by the PICAXE to protect the TTL (3 resistors and a diode) and the inversion of the 7404 family. For autoreset, I added 2 resistors to protect the TTL front and the cap for the flagging and used another gate to invert and I have a solid reliable 3 and 5 volt interface that I can sell in kit form with a PCB for $4-5 each and still make a reasonable profit to pay for more R&D for even more toys ...
I have developed an inexpensive (kit is $4, 3/$10) serial adapter called the P3 that can be used to program the BBB as well as me a 232/TTL interface that Paul and I will begin marketing next week, my goal tomorrow (oooops, later today) is to adapt that for auto-reset ...
whats the TTL interface, is it a MAX232 based thing or a FTDI based thing?
limor
No its some resistors and a diode feeding a two gates of a hex inverter, which is why an hour ago I made it work with auto reset with just the addition of 2 10k resistors and a cap and one of the heretofore unused gates on the 74HC04.
Max23x is an 'expensive' proposition, if you use the 232 you are paying in real estate with 5 electrolyics, if you use the 233, you paying in cash with an expensive chip. I took the front end used by the PICAXE to protect the TTL (3 resistors and a diode) and the inversion of the 7404 family. For autoreset, I added 2 resistors to protect the TTL front and the cap for the flagging and used another gate to invert and I have a solid reliable 3 and 5 volt interface that I can sell in kit form with a PCB for $4-5 each and still make a reasonable profit to pay for more R&D for even more toys ...
cheers ... BBR
huh, i remember some kids doing stuff like that when i was in school, just using zeners, but never did it myself. from what i recall it did work fine for short cable distances.
you dont actually need 1uf electrolytics for the max232, you can just use 0.1uF ceramics which are 5cents each but they're still bulky, its true.
hi i understand what you did, what im trying to say is that my cable (TTL-232R-5) that i bought from mouser doesn't do what your does. it may be a version thing, it may be a marginal thing. all im saying is that if it doesnt work for me, theres a chance it doesnt work for a bunch of cables and that can make for frustrated customers.
you may want to verify it with a couple different cables to make sure!
hi i understand what you did, what im trying to say is that my cable (TTL-232R-5) that i bought from mouser doesn't do what your does. it may be a version thing, it may be a marginal thing. all im saying is that if it doesnt work for me, theres a chance it doesnt work for a bunch of cables and that can make for frustrated customers.
you may want to verify it with a couple different cables to make sure!
That is the cable I am running, but I run on a MacBookPro under OSX 10.4.10 ... I have a java problem with Arduino 0009 on my Windows partition I recently thoughtlessly let that upgarde to Java 1.6 . I have to take it over to my actaul Windows box whihc still has Java 5 (I hope) and see if I can get it to run there .... I will bet that is what it is! Redmond cannot do anything right especially Java!
hi i understand what you did, what im trying to say is that my cable (TTL-232R-5) that i bought from mouser doesn't do what your does. it may be a version thing, it may be a marginal thing. all im saying is that if it doesnt work for me, theres a chance it doesnt work for a bunch of cables and that can make for frustrated customers.
you may want to verify it with a couple different cables to make sure!
That is the cable I am running, but I run on a MacBookPro under OSX 10.4.10 ... I have a java problem with Arduino 0009 on my Windows partition I recently thoughtlessly let that upgarde to Java 1.6 . I have to take it over to my actaul Windows box whihc still has Java 5 (I hope) and see if I can get it to run there .... I will bet that is what it is! Redmond cannot do anything right especially Java!
cheers ... BBR
yup. its probably a driver thing or a java rxtx thing. good luck!
Hmm, on the Mac, the FTDI drivers may assert (lower) both RTS and DTR when you open the serial port. On Windows, I modified avrdude to explicitly twiddle DTR, but RTS is probably never touched. In retrospect, I'm not sure that I actually need to touch DTR in the Arduino code itself, even though I do (in flushSerialBuffer() in Uploader.java).
Hmm, on the Mac, the FTDI drivers may assert (lower) both RTS and DTR when you open the serial port. On Windows, I modified avrdude to explicitly twiddle DTR, but RTS is probably never touched. In retrospect, I'm not sure that I actually need to touch DTR in the Arduino code itself, even though I do (in flushSerialBuffer() in Uploader.java).
david, do you think it would be possible to make it an option in preferences.txt whether to twiddle RTS or DTR? by default it would be DTR but for us freaks, we could change it to RTS
It should be possible, though it might be a pain. I'm not sure if RXTX has methods for setting RTS (that may have been why we went with DTR instead, I don't remember). Otherwise, we can probably just build it into avrdude on Windows. Again, on Mac and Linux, you might not need to do anything, as some of the lines get set when the port is opened. Mostly, it just requires lots of testing, which I don't really have any hardware for.
you simply add a section like this to $ARUINO_DIR/tools/avr/etc/avrdude.conf:
programmer
id = "arduino";
desc = "Arduino Serial Bootloader";
type = stk500;
reset = 7;
;
In the avrdude.conf is a SUB-D RS-232 connector pin mapping which shows RTS is pin 7 (hence reset = 7).
Well, after seeing this again, I may have done something wrong, as I initially wanted to toogle DTR (which is pin 4!) but it worked with the setting above!
I've to look at the board again - I probably soldered the wire to one FTDI pin aside or something ...
But it should work in general, as it toggles a reset on my trusty Arduino Extreme/USB boards.
Or maybe the reset does come allways from the general serial port opening? I'm too lazy now to pull my scope from the shelf...
Mellis, what did you find out with avrdude and reset?
p.s. to use this new avrdude option, preferences.txt (or the makefile must read upload.programmer=arduino of course
It should be possible, though it might be a pain. I'm not sure if RXTX has methods for setting RTS (that may have been why we went with DTR instead, I don't remember). Otherwise, we can probably just build it into avrdude on Windows. Again, on Mac and Linux, you might not need to do anything, as some of the lines get set when the port is opened. Mostly, it just requires lots of testing, which I don't really have any hardware for.
I dont quite understand the preferences stuff in Java as changing the preferences.txt file doesnt seem to do the right thing. probably im not doing something earlier or parsing it wrong.
but other than that this works. its a bit cleaner than messing with the driver and if you're not using an FTDI chip, etc. etc. This way you can also 'turn off' the DTR auto-reset thing by editing the preference.
Hopefully this will make it into the next version...
in Uploader.java
protected void flushSerialBuffer() {
// Cleanup the serial buffer
Serial serialPort = new Serial();
byte[] readBuffer;
while(serialPort.available() > 0) {
readBuffer = serialPort.readBytes();
try {
Thread.sleep(100);
} catch (InterruptedException e) {}
}
System.out.println("test DTR/RTS");
if (Preferences.getBoolean("upload.useDTR")) {
serialPort.setDTR(false);
System.out.println("Release DTR");
}
if (Preferences.getBoolean("upload.useRTS")) {
serialPort.setRTS(false);
System.out.println("Release RTS");
}
try {
Thread.sleep(100);
} catch (InterruptedException e) {}
if (Preferences.getBoolean("upload.useDTR")) {
serialPort.setDTR(true);
System.out.println("Set DTR");
}
if (Preferences.getBoolean("upload.useRTS")) {
serialPort.setRTS(true);
System.out.println("Set RTS");
}
serialPort.dispose();
}
and in Serial.java
public void setRTS(boolean state) {
port.setRTS(state);
}
awesome! i will try this out. i also just quickly wrote up a 'patch' for Arduino (software) but this will do in case it doesnt end up in the official distro.
thanks, this is great team-work!
Nice!
But I would prefer keeping the reset functionality out of java and the IDE if possible.
If avrdude is capable of doing it, let it toggle the reset, as it's actually a part of the uploading process. And it's much more flexible regarding user changes.
I've the same feeling here as with using makefiles in the background...
I'm a sucker for modularity. Long live UNIX style: small tools, one for each domain, entity or problem
awesome! i will try this out. i also just quickly wrote up a 'patch' for Arduino (software) but this will do in case it doesnt end up in the official distro.
thanks, this is great team-work!
i tried this hack with no success...it still tweaks DTR but not RTS...i have to go to a party but can someone else verify that this works?
On my Mac, I can upload sketches to my Diecimila without pressing the reset button or doing any explicit twiddling of the DTR line. I'm pretty sure that the FTDI drivers automatically assert the line whenever you open the port. Does anyone know if it does the same to the RTS line? I think the behavior should be the same on Linux too, though we should test that as well.
On Windows, we might just want to explicitly set the RTS line in addition to the DTR line, unless anyone has any good reasons not to. I'd rather not start adding command line arguments to avrdude. Alternatively, we could twiddle the appropriate line from the Arduino software before calling avrdude, but there are a couple of disadvantages. One is that it doesn't work for people who aren't using the Arduino environment. The other is that if launching the external avrdude process takes too long, the bootloader will time out before the upload happens. I'm not sure I trust Java and Windows enough to be confident that this will always be fast enough.
