When I send new code to and restart my Duemilanove.
The pins that I'm using go high.
i.e. pin 12.
It only happens for a breif bit of time, but it's not good. As I'm powering a solenoid with a mosfet off that pin. So it clicks open for a split second.
I tried to write the pin low during the setup portion, but that didn't seem to matter.
Should I had some command to keep this from happening?
When a AVR chip goes through reset, like just before a new sketch is being uploaded to it, the first thing that happens is that all I/O pin are set as input pins, so anything you have wired to them will see a 'floating' voltage. The easiest solution would be to wire a external pull down resistor, say 5k or so, between the pin and ground and that should keep the node as a logic zero even during the reset phase.
As stated above. Most MCU pins are tri-state meaning they can be configured as either a input or output. The MCU will be a floating input so putting a 4k7 ohm resistor from the pin to ground should ensure the voltage at that pin is held to ground so yes, put it in parallel with your mosfet gate to ground.
A resistor from the pin to ground should work. Could you post a drawing of your wiring from the Arduino to the MOSFET/controlled device? Are you using a external voltage for the Mosfet controlled device? If so is the ground from the power supply wired to the ground pin of the Arduino. Again a drawing is the best method to communicate what you have and might be corrected if required?
I'll have to work up a drawing, if you really need it.
GND is connected to protoboard ground line that runs along the length.
5V is connected to protoboard power line that runs along the length.
I have the mosfet plugged into the top of 3 protoboard lines. Each in it's own lane.
I have pin13 (LED) pin connected to the lane with mosfet pin1.
I have resistor connected from the lane with the mosfet1, pin13 to ground.
On Pin2 of the mostfet I have jumped to another lane that has a led with resistor and the ground of the solenoid.
On Pin3 of the mosfet. I have it connected via jump wire to ground.
Finally the other leg of the LED and the solenoid are connected to the power.
So at this point, I have common power/ground for everything. Although, I am curious how I would use the mosfet to drive something that has a completely different power/ground. I'd guess some type of optocoupler? But I get ahead of myself.
Everything works, but during boot.. the little LED mocks me and flickers on. Triggering the onboard led, the mosfet, which triggers the protoboard led and solenoid.
I've tried on pin12, it does the same. So I don't think it has to do with me using the onboard led pin.
Would have thought 4k7 would have worked. If it didn't then the pull down is not overcoming the initial float input voltage of the pin. At 4k7 the current source is about 1mA. I would have to check the MCU data sheet for the current parameters.
You could try a 2k2, Red Red Red which at 5V would require a source current of 5V / 2200 = 2.2mA
A LED requires about 20mA and you can drive it directly from the pin. I prefer to use a limiting resistor where you need to subtract the LED voltage from your calcs about 2V.
If this doesn't work, then you need to check the data sheet for IO pins. The IO pins should be tri state on reset, but having a quick read, there is also a PUD register which enables or disables a active pull resistor for the port pin. Didn't know this myself until I read it. Read about it in section 11 of the data sheets for the ATMEGA 328.
The sheet says they should be tri state mode on reset and if the pin is set to a output, then the PUD is activated. Writing a 0 to the port if configured as a output will set the pin low. See table 11-1
The onboard LED is on pin 13 connected via a 1K resistor to the LED to ground. This is pin PB5 on the MCU which is also the SCK line. It shouldn't make any difference but as long as you have it working off pin 12, go for it.
Is pin 13 flashed high by the bootloader code?
defined in the Makefile as NUM_LED_FLASHES
Just thinking for future reference, it may be useful to be able to remove it.
Yes, he didn't mention using pin 13 in his first post on the discription of the problem. The bootloader will flash pin 13 as part of the waiting to see if there is a new sketch waiting to be uploaded or not.
So yes, there is something weird about pin 13, but it's not hardware, it's the Arduino software bootloader.
There are a few pins that should be avoided if possible, unless a careful review is done to see if there will be either hardware or software interactions. Pin 13 (used by the bootloader) and pins 0 & 1 (wired to the on board FTDI USB serial converter chip).