I am pretty sure I found a bug in the Diecimila. Basically, I hooked up the basic motor control using a TIP120 transistor and a pot. I followed this lab:
When I turn the pot above about 1/3, then the Diecimila starts reseting a lot, sometime so much it doesn't come back until I turn it down again. I tried this with USB power and a wall wort. When I ran the Diecimila off of USB power, then ran the transistor of a totally separate power supply with its ground wire connected to the Arduino ground, it then worked fine.
When I ran the exact same circuit and code using an Arduino #1296, it worked fine, with both the exact USB port or the exact same wall wort or the external power supply.
The key part here is that the same exact setup worked fine with an Arduino #1296. This happened to me on the Diecimila even when using an external power supply.
Try addition 4700uF /16V. capacitor on +12 supply to reduce back EMF load effect and add more diode to prevent reverse voltage back to TIP120 and may effect I/O pin
I know the power supply circuit changed somewhat between the older Arduino boards and the Diecimila. In particular, the FTDI chip is now powered whether you're using USB or external power (to suppress extraneous serial data), meaning that the total load on the power supply is larger with the Diecimila than the older board.
As others have said, I don't think it's a bug in the Diecimila so much as a different handling of a slightly sketchy circuit. Just because something used to work doesn't mean it's the right way to do it.
I am not trying to say that this circuit is a good one to use, but it is definitely a good one to learn from because it's so simple. But the real key is that this circuit works totally fine on the Arduino and Arduino NG, but causes repeated resets on the Diecimila. I made a video to illustrate it:
It seems to me that it's related to the frequency of the motor, rather than the current. I'll try adding a filter cap to isolate it. But since Arduino is a learning platform, I think that the Diecimila should be as robust as the previous generations.
As do I. This change was to make the Diecimila more robust in other ways than the previous boards. Unfortunately, one of the challenges of making a flexible board that's simply enough to use as a teach platform is balancing all the different requirements. In this case, we traded off a bit of capacity to ensure sketch startup when powering with an external supply.
Sorry, I started the meta-conversation a bit prematurely... back to the details of what's happening. Tom and I just spent some quality time debugging this with his boards. It seems that there is at least one red herring in this. Since it works fine when the motor power supply is totally separate, we are changing that tutorial on Tom's site to reflect that.
I measured the current from the motor, it uses 130mA at full speed. So I don't think that current is an issue here, just to put that to rest. I am using a 400mA supply, Tom was using a 1000mA supply. Plus I am using Vin to power the motor, which if I understand correctly, is just a pass thru from the external power supply.
So my Arduino NG also resets in this circuit. But for some reason, my Diecimila sets the PWM pin to 0 when it restarts, while my Arduino and Arduino NG leaves it at the same level. Tom's Diecimila left it at the same level too. With the arduinos that don't turn off the PWM, you don't really notice the reset in this circuit since it just means that you can't change the speed of the motor for a couple of seconds. The thing that leaves me wondering is, does the PWM keep running even when the chip is resetting? How come my Diecimila does reset the PWM?
So far, the status is that the Diecimila seems more sensitive to the motor noise, i.e. it resets more easily. But the Arduino NG resets too. None of them reset when the motor power goes straight to the breadboard. Would there be any downside to adding something to make it more resilient to noise? I don't mean it to make bad circuit designs work, but more in general, to make the Arduino more stable.
Also, I am curious what the mechanism is that is causing the reset...
For one, you should check motor current at full stop torque (that is, stop the shaft while running it full power) that's your max possible current. Torque is what uses current, not speed. As for the PWM. I've noticed this behaviour on my NG, but I have the Diecimila bootloader. But as far as I can see in the Makefile, both use the same fuse (David maybe you can correct me here). So I'm really not sure where the issue is here.
It might be the brownout fuse. The chip might act differently if a reset is caused by the detection of a brownout than if brown-out detection is disabled and the chip resets because it loses power completely. While the fuses burned with the current burn bootloader menu items are the same for the NG and Diecimila, we shipped the NG's without brown out detection enabled (if I remember right). You might try reburning the bootloaders on your board and seeing if that changes its behavior.
It would be interesting to know the reason for the reset. The AVR stores bits in a register that distinguish between power-on reset, brown-out reset, watchdog reset, and reset input reset; I don't THINK that the bootloader clears those bits, so your sketch could examine them and show which had occurred somehow...
I am pretty sure the current is not the issue, since things worked fine when I connected the power supply directly to the motor. But to make sure, I did some measurements. Previously, I measured the current while the motor was in this circuit illustrated in the video.
This time I am testing with a 12V, 1000mA supply.
open supply voltage: 13.5V
voltage with motor on full stop: 8.8V
full speed, no load current: 0.08A
full stop current: 1.2A
It seems very unlikely to me that the ATMEGA168 would brown out if there was 8.8V on the regulator. Also, if I hook up the Arduino to USB power and the motor to the external power it still happens. Also, the reset doesn't happen when the motor is starting, but rather after it's running for a bit. From what I understand, there should be a current spike when the motor starts.
Also, from what I understand, the reset state is written to the EEPROM. I set the whole EEPROM to 0, then the reset motor control sketch again. All of the EEPROM bytes were still 0.
I would not spend too much time speculating about the fact that it resets on one Arduino and not on the other. That's because neither were really designed for noisy power supply environments. The Diecimila in particular has about 35 cents worth of power supply filtering, with a whopping capacitance of... 100uF. Whew, I'm drowning in electrolyte here!
As a result of the lean power supply filtering, and if you want predictability, it is wise to keep noisy things like motors, solenoids and other inductive loads as far away as possible from the Arduino's +5 logic supply .
I will bet you a bag of grommets that adding 220Uf to the +5 supply causes your Diecimila reset problem to go away immediately. Solder it right on top of the Atmega and give it a try. And if that does not work, put a .1 across the Atmega +5/GND pins.
You guys must have a scope there, so what does the reset line look like? Put the +5 power supply on channel A and the reset line on channel B, set it AC coupling on both channels, with really fast trigger and capture if available... all will become evident.
FWIW, in the past I've had to add one or more of the following to get prevent interaction between the logic and motor supply:
.1 caps on supplies near motor V+, to quench high-frequency noise caused by pwm switching
220Uf to 1000Uf caps on either or both logic and motor supplies
.01 on the motor itself to quench high frequency noise that is emitted electromagnetically ( i.e. radio noise)
schottky 'freewheeling' diodes on the motor to clamp inductive spikes
diodes or low value (.1R) resistors inline with the motor power supply, to encourage the noise to stay in the motor supply
in extreme cases an opto-isolator between the uProcessor and the motor driver silicon.
In general I just put a whole truckload of 100Uf and .1Uf capacitors on the logic supply, and keep the supplies as separate as possible, and as a result I pretty much never have to deal with what you're describing.
One of the main reasons I am going into detail on this is to write a tutorial about it. But also in the process, it seems that the Diecimila (mine at least) is more sensitive to noise than the previous versions. It would be quite helpful to figure out how to improve that situation.
Do you have any diagrams for what you describe that I could use in a tutorial?
sure i could dig up some diagrams, but each solution is symptom-driven, so it is best to find out why the reset is happening and then apply the simplest solution. Did you try the extra filter caps on the Diecimila? If that works, tutorial-wise it would be just a matter of saying add 220Uf or something to the +5/GND pins. I am almost certain that that is why it is happening, and I still have that bag of grommets.
If you really want to get to the bottom of things to discover why your Diecimila is more sensitive to noise than earlier versions, then the scope is the ticket. I can only think of three ways that the reset could be happening: via the reset line, a brownout on the power supply line, or within the code somewhere. The scope will tell you if it's one of the first two. From that you can suggest a tutorial workaround.
I just looked at your video, which I hadn't looked at previously.
You have no additional filtering.. that is almost certainly the problem. Motors make noise, and you need to add filtering to ensure the logic supply stays clean. The "Diecimila difference" is not really a bug but is more likely caused by the fact that the FTDI is always powered in the Dieci, and might be interacting with the new reset mechanism when it gets a little blast of the noisy DC you're injecting into the power supply with that motor.
In any case it is really obvious that you need filter caps! Add some and it will be fine. I up my bet to a a truckload- no, make that an ocean liner- of grommets, especially because it is frequency related, and capacitors (i.e. the onboard Dieci filter caps) have different filtering abilities at different frequencies.
You can't add noisy motors like that without additional filtering- there is only 47Uf before the regulator and 47uF after, which is woefully inadequate.
I tested eighthave's motor circuit with a Freeduino, which is a Diecimila compatible board, and it doesn't reset. Freeduino has the same FT232RL powered all time, like the Diecimila. So maybe you have a faulty Diecimila??
I tested eighthave's motor circuit with a Freeduino, which is a Diecimila compatible board, and it doesn't reset. Freeduino has the same FT232RL powered all time, like the Diecimila. So maybe you have a faulty Diecimila??
Are you sure it doesn't reset at all? What I've found in further testing is that they all reset with this circuit (it has no noise reduction whatsoever). My particular Diecimila seems to reset noticeably easier than my Arduino and my NG, but all of them reset. It's not so noticeable on most boards, because the PWM keeps running. Set up a test LED to watch for resets, and watch it carefully.
Are you sure it can be called a reset? When Arduino resets, PWM stops for 1 sec (diecimila) or 3 sec (NG). Sure the power lines and any output suffers some fluctuation, but I don't think it is a reset unless the Arduino bootloader gets invoked again.
I am testing using a Freeduino, better Arduino than Arduino
Set up a test LED to watch for resets, and watch it carefully.
Hmmm, it may be you are blinking your eyes...
Seriously, I tested with a scope. As I said before, there is some fluctuation that causes some LEDs to dim, but it is within a tolerable range and the atmega168 doesn't reset.
back to the details of what's happening. Tom and I just spent some quality time debugging this with his boards. It seems that there is at least one red herring in this. Since it works fine when the motor power supply is totally separate, we are changing that tutorial on Tom's site to reflect that.