BBB is now "Diecimilia ready"

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!

cheers ... BBR

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 :wink:

On windows machines try this:

Device Manager - USB Serial Port - Port Settings - Advanced button - Set RTS On Close

This is research from David Fowler at uchobby.com

Paul Badger

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.

Patches welcome. :slight_smile:

On windows machines try this:

Device Manager - USB Serial Port - Port Settings - Advanced button - Set RTS On Close

This is research from David Fowler at uchobby.com

Paul Badger

aha! yes now that works fine. i was looking at the FTDI mprog thingy but it was not helpful...

limor:
you can tell avrdude directly to toogle a line before uploading. I expllained it here http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1187984620/12#12 and used it in a makfile wich is linked.

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 :wink: ...
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 :slight_smile: 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.

mmm...twiddling RTS is a pretty standard activity, being a hardware flow control
http://java.sun.com/products/javacomm/reference/api/javax/comm/SerialPort.html
should work just peachy under any OS as it is part of the core java comm API

Patches welcome. :slight_smile:

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... :slight_smile:

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);
  }

limor:
you can tell avrdude directly to toogle a line before uploading. I expllained it here http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1187984620/12#12 and used it in a makfile wich is linked.

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! :slight_smile:

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 :slight_smile:

Oli

limor:
you can tell avrdude directly to toogle a line before uploading. I expllained it here http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1187984620/12#12 and used it in a makfile wich is linked.

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! :slight_smile:

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.

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.

well, it seems to me like avrdude has already been mucked with (so that it tweaks DTR) so its not really a big deal to muck some more by putting the preference in avrdude.conf

and yes i can write the code to do this :wink:

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.

sure, that makes sense... but then why is there the setdtr() code in there now?

Yea, more hacks to avrdude are fine. If we can just include a reset parameter in a new programmer definition in the config file, that would be awesome. Otherwise, whatever you think is the best approach is probably fine.

I'm not sure why I have the explicit DTR flipping in the IDE source. It may be because there are certain situations (e.g. if you set or unset HUPCL the previous time you opened the port), in which the board won't reset just from the port being opened. Although even then, when we open the port to flush it, it should reset HUPCL, so the board should reset when avrdude opens the port. Honestly, I probably just wasn't thinking.

Yea, more hacks to avrdude are fine. If we can just include a reset parameter in a new programmer definition in the config file, that would be awesome. Otherwise, whatever you think is the best approach is probably fine.

I'm not sure why I have the explicit DTR flipping in the IDE source. It may be because there are certain situations (e.g. if you set or unset HUPCL the previous time you opened the port), in which the board won't reset just from the port being opened. Although even then, when we open the port to flush it, it should reset HUPCL, so the board should reset when avrdude opens the port. Honestly, I probably just wasn't thinking.

no problem, i dont like to do much thinking either. it hurts the brains.

here is the plan, i would to fix the two-bootloader problem because a lot of people seem to want extra chips but i dont want to have to deal with carrying two kinds of chips. thus it would be good to have one bootloader that works with both NG and diecimilas. i also want this bootloader to work w/my clones. i also want to shink the bootloader down to under 1K which is certainly possible. it would also be good if this bootloading system could cope with future chips as i i know that is already in the worx. therefore, here is my PLAN: (<= note the planningness of this plan)

  1. bootloader will be changed so it has two timeouts. one while its waiting for first serial character (3 seconds) and one after its received at least one valid bootloading directive (7-10 seconds)
  2. avrdude will be modded so that it uses either RTS or DTR (or whichever pin indictaed in the .conf)
  3. when users clicks "upload" the software uses avrdude to read the sig and fuses*. software then compiles sketch then hands off .hex to avrdude again for uploading.
  4. avrdude will also be modded so RTS and DTR are not twiddled automatically whenever the port is opened/closed, if possible. i -think- under linux/mac the ioctls are in charge of this.
  5. bootloader starts sketch immediately upon recieving "done programming" command ('Q') if and only if it has at some point also executed a flash-write command ('d')

i -believe- this will solve the problem for any OS user and any Arduino user combo. in the worst case the wait time will be 3 seconds. NG users will have to click the upload button within that same time period after pressing reset.

i can write the code and maybe some people can try it out. it certainly doesnt have to be the default diecimila bootloader that comes with the device, but may be a good intermediate bootloader.
only question im not sure of is if java can get avrdude to execute within a few seconds to do the first fuse/sigbyte read. im pretty sure it can as exec() is a pretty low level command, but it will require some testing.

let me know what you think! is this a pipe dream??

limor

  • reading the fuses before compilation is part of a grander scheme in which the software uses the fuse data to calculate the size and location of the bootloader thus the max-sketch size, and the signature to verify the chip selected is correct. it can also tell if you're using a lilypad because it would read the internal 8mhz oscillator fuse, may be very useful!

I love it.

The only problem is that I don't think it's possible to disable the twiddling of the DTR and RTS lines when opening the port (on the Mac and Linux). It's hard-coded into the driver AFAICT (on Linux, you could patch and recompile your kernel or the FTDI module, but that sucks). The only way that I know of to stop the reset from happening is by setting (or unsetting, I don't remember which) HUPCL the previous time you open the port. So if there's a three second delay in the bootloader, you'll have to wait 3 seconds every time you open the port. We could get around this with the serial monitor by hacking RXTX to set HUPCL, but it wouldn't help people using Processing or Max or PD.

Also, on some Windows machines, the reset button apparently needs to be pressed way after the upload button. This might just be because the compilation is super-slow, but it could also be slowness on the part of exec. This is also hard to test, because on all the Windows machines I've seen, the compilation is pretty zippy.

I really like the idea of running avrdude once to get information about the chip / board, then compiling, then doing the upload. We could still do that even if we had to maintain separate bootloaders and a long timeout on the NG one.

Shrinking the bootloader down to 1 KB would be cool too. It's actually a lot of fun trying to optimize it but I haven't had a chance to do it for the ATmega168 bootloader yet, so feel free to take a shot at it. The ATmega8 bootloader was at something like 1016 bytes, but I think avr-gcc has gotten better at optimizing for size since then. Still it might be challenging to fit everything in.

BTW, I ported your USBtiny avrdude changes to the avrdude 5.4 source in the Arduino svn: Arduino Starter Kit kaufen [verschiedene Ausführungen], so you might want to use that as the starting point for any avrdude hacking.

Hey limor, hi david!
I'm sorry that I caused confusion! It looks like I got fooled in thinking DTR was toggled, when it obviously was only because of the serial port opening. It just made so much sense to me, that the "reset" variable should also be parsed by avrdude when doing stk500. Bad coincidence...
But I can at least report, that auto-reset also works with a non FTDI chip, the CP2102 from silabs also does a nice DTR line toggle when the serial port gets opened - at least under Mac OS X.
I'll test both usb-serial chips with avrdude and a small serial port toggling python script under all three OSes soon.
I hope this will clarify the issues...

no prolem oliver, i dont think anybody realized that there were such driver differences. its a good thing we know now!

i will work on the Master Plan in a few days. id like to wrap up the protoshield as a lot of people seem to want it, so hopefully my beta testers will do some beta testing and get back to me soon :slight_smile: