I'm improving my automatic chicken coop door closer . I built the first version with some discrete components and an LDR, but after a year or so of issues with the failing LDR's and lack of functionality. I decided to replace the circuit by a new one driven by an arduino. So I breadboarded the new circuit and used a Arduino UNO to build and develop the sketch. After some days of development I was happy with the sketch and started designing a proper PCB board that I could insulate from moisture and other external elements. Since a Arduino UNO was too bulky to put on the PCB, I decided to buy a pro mini, put some rounded headers on it so I could simply stick it on a IC socket on my PCB board. So everything was working as expected until I decided to close the PCB enclosure and I removed my serial to USB cable, leaving the headers RxD/TxD/RST open.
For some strange reason, the analogread on A0 which is reading the value of a phototransistor is acting strange. Most of the time I think it's reading the correct value, but at regular intervals it reads a higher value, resetting a counter I have in my sketch
Of course every time I would stick the cable back to debug the damn thing it would work !!! At some point I thought I just needed to put some delays into the loop to simulate the serial.println but to no avail, until I figured that just having the USB to serial cable connected fixed the problem.
I tried to set pin 0 and 1 to input, output, HIGH, LOW but to no avail, the problem persists. The next thing I'm going to do is take a multimeter and measure the voltage on the serial connector and fabricate a dummy header which simulates the same behaviour as the cable, but I would like to understand the root cause of the issue.
I use an external power supply to power the PCB, there's an LM317 to regulate the power and get the correct 5V voltage. The pro mini has an onboard resistor and reset push button in place, there's no need to connect a pull-up resistor
And yes, I use a goto in my if statements to break out of the loop, two interrupt handlers to handle the buttons. In this case the goto saves me a lot of other if/and elses and I think is appropriate in my design.
Without the serial cable in place all the other logic is working, button presses, controlled opening/closing of the door with retries,...
I rechecked my circuitry in order to be absolutely sure about the power supply configuration. It's a Deek Robot Arduino Pro Mini. My regulated power is connected to the VCC pin on the board, there's no VIN on these type of boards, just VCC and RAW (this is when you want to use the onboard voltage regulator) When I measure the voltage between GND/VCC I get 5.1V, which is pretty close to 5 V and within spec.
I'm under the impression that with RxD, TxD and DTR pins open it picks up some interference which affects the ADC. I'll try to get a scope and measure the waveform on pin A0
// the follow variables is a long because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long BlinkTime = 500; // interval at which to blink (milliseconds)
millis uses unsigned long, all time related variables should be unsigned long
const int button1 = 2; // button_force
const int button2 = 3; // button_press
const int ledRed = 4; // the number of the LED pin
int ledStateRed = LOW; // ledState used to set the LED
unsigned long ledTimeRed = 0; // will store last time LED was updated
const int ledGrn = 5; // the number of the LED pin
int ledStateGrn = LOW; // ledState used to set the LED
unsigned long ledTimeGrn = 0; // will store last time LED was updated
const int enable = 16; // enable pin on H-bridge
const int pin1a = 15; // 1A pin on H-bridge
const int pin2a = 11; // 2A pin on H-bridge
const int pinCDclsd = 13; // end switch CD tray closed
const int pinCDopen = 12; // end switch CD tray open
Declare the rest of your IO pins - any of 0-19 that are not listed here already
and add pinMode (pinX, INPUT_PULLUP) in setup for them
make these INPUT_PULLUP also
/*pinMode(0,OUTPUT); // Fix issue with open pins on serial port
pinMode(1,OUTPUT); // Fix issue with open pins on serial port
and have this after those, so that when uncommented the Serial library can re-purpose them as needed:
// initialize serial communication at 9600 bits per second:
// Serial.begin(9600);
// Serial.println("Setup");
Do the 4 input pins have pullups or pulldowns on them so they are not floating when their button/switch/whatever is not pressed?
Promini regulator is only good for 150mA. I've always bypassed it and used external regulator, and then the Promini was just a small part of the overall 5V load.
Why do you need the lm317 when you have a RAW input on the Pro-Mini ?
Promini regulator is only good for 150mA. I've always bypassed it and used external regulator, and then the Promini was just a small part of the overall 5V load.
Indeed I use an LM317 because I need more amps than the poor regulator on the promini board can handle. I'm driving a small motor and in the future also some relays
Do the 4 input pins have pullups or pulldowns on them so they are not floating when their button/switch/whatever is not pressed?
I did not connect any pull-up resistor to the 4 pins (RxD/TxD/DTR/USB-VCC), because I need them to function when I connect my FTDI to USB cable in order to program it, so yes they're floating. I'm thinking about fabricating a dummy header I can put in place when I don't have the cable connected.
I'll also declare all pins and set the unused ones to INPUT_PULLUP
You can do as I mentioned for Rx/Tx, the internal pullup is only activated when the sketch runs - when the bootloader is installing code, the pullup is not turned on.
DTR does not need a pullup; it is one side of a 0.1uF cap, the other side is the Reset pin which has a pullup already.
USB-Vcc is the power pin, you would not put a pullup on that, it is externally driven already by the power source. You can add a 10uF and a 0.1uF cap on VCC if you think the external supply needs some smoothing.
I applied all the suggested changes to no avail. I can't make head or tails of this. I'm starting to suspect it's a grounding problem, when I connect the serial cable, the PCB is connected to the ground of my PC.
