I am having trouble addressing analog pin A5 as a digitalPin on the arduino pro mini. Using code:
void setup() {
// initialize the digital pin as an output.
pinMode(A5, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(A5, HIGH); // turn the LED on (HIGH is the voltage level)
delay(3000); // wait for a second
digitalWrite(A5, LOW); // turn the LED off by making the voltage LOW
delay(3000); // wait for a second
}
I would expect to see the voltage on PIN A5 alternate between +3.3V and GND. All I am seeing is plus 3.3V though. Am I addressing the pin incorrectly?
I've always used 14 to 19 instead of A0 to A5, makes it more clear that digital is being used.
So:
byte pin19 = 19;
void setup() {
// initialize the digital pin as an output.
pinMode(pin19, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(pin19, HIGH); // turn the LED on (HIGH is the voltage level)
delay(3000); // wait for a second
digitalWrite(pin19, LOW); // turn the LED off by making the voltage LOW
delay(3000); // wait for a second
}
CrossRoads:
I've always used 14 to 19 instead of A0 to A5, makes it more clear that digital is being used.
So:
byte pin19 = 19;
void setup() {
// initialize the digital pin as an output.
pinMode(pin19, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(pin19, HIGH); // turn the LED on (HIGH is the voltage level)
delay(3000); // wait for a second
digitalWrite(pin19, LOW); // turn the LED off by making the voltage LOW
delay(3000); // wait for a second
}
3000 = 3 seconds, not 1 second
I tried using '19' instead of 'A5' after I did my post but it still didn't work. I changed it to delay 3 seconds to give my multi meter time to stabilize. Any other ideas? Could it be something specific to the pro mini?
Well, let me tell you, I ran your code and it worked perfectly.
Mind you, I tried it on a 16 MHz Pro Mini (clone) at 5V (and used a LED with resistor as indicator, but also tried just testing with a meter). You mention 3.3V - you are not perchance attempting to run a 16MHz board at 3.3V are you?
The missing information - what else have you done successfully with this arrangement?
Well it's not an official Arduino Pro Mini. It's my own circuit that shares the same pin assignmens of the Arduino Pro Mini, runs at 3.3v and 8 mhz and has a bunch of other stuff on it. Schematic is attached at the bottom.
The eagle files and code are located here and here:
Pin A5 is connected to the P-Channel Mosfet located right around the middle of the schematic, labeled U$4 (because I was too lazy to change the Eagle assigned label). It is there to cut power to the OLED, SD card, and GPS to save on power when the micro controller is asleep. The GPS's backup is kept connected to V+ to maintain its memory. I noticed when testing it out that the display was not turning off when the micro controller would go to sleep. It would however dim slightly. That's when I started looking at the voltage at the gate of the mosfet using the blink sketch. What I saw was that the gate voltage was staying at +3.3v and not alternating between 3.3 and ground. There is continuity between the mcu pin and the gate so I assume that whatever is happening at the gate is happening at the pin as well. My voltmeter probes aren't small enough to check the actual pin voltage without bumping in to the pins next to it.
I ran it with the actual intended program for this board and the gate voltage was doing what it was supposed to do. This brings up another problem which is, why is there voltage after the P-Channel Mosfet when the gate voltage is brought high? I made a video to help explain my problem.
You might just have a bad analog pin. Note that the signal has a pull-up resistor to 3.3vdc at the mosfet, so the signal line will be a high is the pin is open circuit internally in the chip. Have you tried your 3 second test sketch on some of the other analog pins?
retrolefty:
You might just have a bad analog pin. Note that the signal has a pull-up resistor to 3.3vdc at the mosfet, so the signal line will be a high is the pin is open circuit internally in the chip. Have you tried your 3 second test sketch on some of the other analog pins?
The pin seems to be working fine on a different sketch that I wrote. My problem seems to be something else now. The video above explains the problem that I am happening. Any insight that you can offer would be great!
I can't open your flicker picture, would be better if you use Additional Options, Browse to your locally stored file, and Attach it.
You mention
why is there voltage after the P-Channel Mosfet when the gate voltage is brought high?
If the control signals to devices powered by that line are high, the voltage can leakt thru their input clamp diodes and power the device. If you plan to cut power, you should bring their IO lines first so that doesn't occur.
CrossRoads:
I can't open your flicker picture, would be better if you use Additional Options, Browse to your locally stored file, and Attach it.
I attached the file as you instructed.
You mention
why is there voltage after the P-Channel Mosfet when the gate voltage is brought high?
If the control signals to devices powered by that line are high, the voltage can leakt thru their input clamp diodes and power the device. If you plan to cut power, you should bring their IO lines first so that doesn't occur.
This is what I thought may be happening. So I should set all of the lines to input and low before turning everything off. What should the lines be set to when the device is on? This would be SPI so we have CS, MISO, MOSI, and CLK.
Bring the arduin's output lines low, then turn off power.
Maybe use SPI.end();
then digitalWrite the 4 pins low. CS for sure, the others may be already depending on what SPI mode you are using.
When powering back up, bring up power first, then SPI.begin(), and CS back high.
CrossRoads:
Bring the arduin's output lines low, then turn off power.
Maybe use SPI.end();
then digitalWrite the 4 pins low. CS for sure, the others may be already depending on what SPI mode you are using.
When powering back up, bring up power first, then SPI.begin(), and CS back high.
The u8glib library seems to have its own SPI initialization routine that I can't find in any of the .c or .h files. I'm a bit concerned about changing the data direction registers and port registers without knowing what their values are supposed to be. Given this concern, is it reasonable to do something like this:
byte ddrcValue = 0;
byte portcValue = 0;
//store current value of DDRC and PORTC
ddrcValue = DDRC;
portcValue = PORTC;
DDRC &= ~0b00011111; //clear all of the bits corresponding to SPI
PORTC &= ~0b00011111;
digitalWrite(A5, HIGH); //turns off the GPS and Display
sleep_enable();
attachInterrupt(0, button_press, LOW);
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
power_adc_disable();
Serial.println("I'm Asleep");
Serial.flush();
sleep_cpu();
//code starts back up here after wake up
Serial.println("I'm awake");
sleep_disable();
DDRC |= ddrcValue; //set DDRC and PORTC back to its pre-sleep state
PORTC |= portcValue;
digitalWrite(A5, LOW); //turns on the GPS and Display
This is fantastic! The code that I posted above seems to work. The display turns off completely now. I haven't checked the voltage to confirm that it is zero but it looks very positive that it is. Thanks everyone for all of the advice!
