Go Down

Topic: BBB is now "Diecimilia ready" (Read 2385 times) previous topic - next topic

ladyada

#15
Sep 10, 2007, 12:49 am Last Edit: Sep 10, 2007, 12:51 am by ladyada Reason: 1
Quote
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

Quote

Patches welcome.  :)


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

ladyada

Quote
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! :)

Oliver Keller

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

Oli

ladyada

Quote
Quote
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! :)


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?

mellis

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.  

ladyada

Quote

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

Quote
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?

mellis

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.

ladyada

Quote
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!

mellis

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: http://svn.berlios.de/wsvn/arduino/avrdude-5.4-arduino/?rev=0&sc=0, so you might want to use that as the starting point for any avrdude hacking.

Oliver Keller

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

ladyada

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

Go Up