Maintenance notice: These forum archives are read-only, and will be removed shortly. Please visit our forums at their new location,

Programming a diavolino.

edited July 2012 in Microcontrollers
So, I want to program my diavolino, but my ttl serial adapter is taking ages to come in.  It occurred to me today that I also have a freetronics leostick, and that the leostick has a second uart; the first is a virtual one run by the atmega.  So, I thought I might use a simple sketch to get some data onto the diavolino.  I wired pins 0 and 1 to their opposite pins in the ftdi connector, hooked the leostick's power to vin on the diavolino, wired the grounds together, and picked another random pin to hook into reset on the diavolino.  At that point, I wrote a simple sketch that opens both serial ports at a fixed rate, checks to see if this is the first data it's seen from the host side, and if so, pulls reset down briefly.  Afterward it will read available data from one serial device and write to the other, and continue to do so until it's reset again.

Anyway, I wrote this to the leostick, switched board types in the arduino environment, but kept the port set properly.  Of course it won't upload anything to the diavolino that way.  It does reset when it begins to see data, but then the blink sketch just picks right back up and eventually the arduino software complains about being out of sync.  So, it occurs to me that I know absolutely nothing about this process.  How is it supposed to work?  You reset the unit, send it some data really fast (how fast, by the way?  There's no perceptible delay between the time you release reset and the time the led begins to blink...). The auto reset is usually handled by a flow control signal?  You -- what? -- raise rts or something to reset the board?  Any idea what I'm missing that explains why this doesn't work?



  • You might want to consider loading the ArduinoISP sketch onto that leostick (if possible) and try to do this the "recommended" way. ;)

    Auto reset is not absolutely necessary. You can often program the device if you press the reset button at just the right moment-- you should have a two second window for it to find it while trying to program.
  • Does the loader flash the pin 13 led, then?  It begins to flash as soon as it gets power and doesn't stop unless you pull reset low.

  • The LED on pin 13 is not really related to the bootloader-- it just indicates that the Diavolino is "awake" and past the bootloader stage.  There should be a delay between when you reset it and the first blink.
  • What might it mean if the delay isn't noticeable?  As I was saying, it seems to start right away and just keep going.  I hadn't been too worried about it, given that I have not been able to try programming it correctly yet, but could this be an indication of some sort of problem?

  • Also, good news.  It looks like I just got my TTL stuff today.  I should be able to do a proper test shortly.  Still, I wonder what I might have been doing wrong here.  Anyway, we'll see how it goes.

  • Well, I'm beginning to wonder whether this thing has a bootloader on it.  Just tried it with an FTDI board, and depending on which way I arrange the RX/TX pins, I get either a complete hang and a data light that's perpetually on, or an error stk500_recv(); programmer is not responding.  Reset never seems to trip, or rather, it probably does, but the LED flashing just starts right back up afterward with no delay.

    So, I thought I'd try the ArduinoISP stuff and see if I could get a loader on there.  Unfortunately, the Leonardo platform seems to have some problems with it.  MISO, MOSI, and SCK have been moved off of the usual pins and isolated in the ISP header.  This isn't a deal breaker, since I can run them out from there.  I've redefined reset in the sketch to use pin 10 instead of pin SS.  This all should work in theory, but there appears to still be some problem with the process, since avrdude keeps seeing different device signatures on the chip.  (Further, trying this with a separate, fresh ATMega on a breadboard achieves the same result, so I'm assuming that this is a problem with my ISP programming and not with the chip or the board.)

    At home I have a FutureTech TTL adapter, which maybe I could use to bit-bang the loader in through the ISP connection, so Google tells me.  Haven't tried actually using it yet, though, and who knows?  I'm not having the best of luck with this so far.  Any other ideas?

  • The "blink" sketch is loaded in a single step *on top* of the Arduino bootloader, so (if you haven't reprogrammed it) there shouldn't be any way for it to blink unless the bootloader is indeed active.

    You might also check to be sure that the 10 k resistor and 0.1 uF cap are installed correctly and in good shape, as those are also necessary for correct function.  

    If all else fails, contact our shop for a return-- we can check for correct function and reflash it if indeed necessary.
  • I'll check those perhaps later tonight, then.  The 10k resistor is a pull-up for the reset line, right?  So should I be able to tell for sure that it's working by actually testing the current through the reset pin?  Obviously I can check the solder joints manually and make sure it has 10k of resistance between poles, but I'm wondering whether there's something more useful.

    As for the capacitor, that handles the auto-reset function, doesn't it?  So what's the best way to test that this is correctly installed?  Is there a way that I can check the function of the auto-reset reliably?  Also, (hopefully) this thing is non-polar, right? :)  I don't remember from when I was assembling it.

  • >So should I be able to tell for sure that it's working by actually testing the current through the reset pin? 

    Maybe.  Easier to just check for continuity and that pin 1 is either high or low, respectively, when an external signal is disconnected or asserted low.

    >As for the capacitor, that handles the auto-reset function, doesn't it?  

    It's the combination of the R and C that makes it work. :)  

    >Is there a way that I can check the function of the auto-reset reliably? 

    The circuit should reset when you try to program it.
  • Yes, I suppose it should.  Well, it turns out that things aren't quite as bad as I thought they may be. No electrical problems with the board at all.  The reason that it wouldn't program is that the TTL serial adapter I was trying to use (which is a cp210x) doesn't seem to like programming arduinos at all.  What's more, the reason I thought the blink sketch was starting immediately after a reset was that I couldn't easily tell the difference between the LED strobe from the power being applied to the board and the blink from the sketch. :) 

    If I use the FutureTech board, (even without trying to wire it into the ISP header) it does work exactly as it should.  Let me change my question again.  Do you think the other FTDI board is hopeless?  I'd kind of like to get it working, but I'm not sure where to start.  It does apply power just fine.  Doesn't seem to reset the boards -- hopefully I can say that with some certainty now since I've replaced blink with my own soft PWM fade sketch, so the difference between the twitch from the power-on and the running sketch is obvious.  I also haven't been able to get it to program properly even resetting it manually, nor does swapping rx/tx seem to help.  I thought it might have them backwards, but perhaps not.


  • Likely not hopeless; the FTDI chips are pretty well supported, and generally can be made to work one way or another. (I do not have the same level of confidence with respect to the leostick.)

    See if you can map your adapter onto the "standard" FTDI cable pinout, to make sure of which pin is supposed to go where, and make sure that your environment is set up correctly: right port and board type and all that. 

  • The leostick does appear to have some fundamental problems with the way the arduino-as-isp stuff is handled, and I think this shouldn't be a huge problem for me now that I can get code onto the Diavolino, which ought to be much more usual in that regard.

    As for the other TTL adapter, so far I know that a loopback does work as expected.  There's actually a pin on this adapter labeled "reset," which makes it pretty obvious where it's supposed to go, and as I said, the power is at least working sufficiently well to drive the board.  I do wonder what (if anything) it's doing with that reset pin, and perhaps I should tack a multimeter onto the end of it and see.

    Luckily, I also have a pro-mini clone -- the intent here is to use the Diavolino in development of a project to be built with the pro-mini -- so I can verify that the Diavolino isn't the only thing which will program with one TTL board and not the other.

Sign In or Register to comment.