Well, the difference between input-pulled-high and output-driven-high is that you can use an external pulldown to pull the input low. Can’t do that to an output-driven-high pin without killing the micro.
Like you said, for practical purposes, without extra hardware to manage, it’s the same.
It seems to me that the “RIGHT” thing to do would be to change the firmware to do what the MCU does by default: configure all the pins to be inputs.
ST recommends specifically for the STM32 to do the following (this would apply to Cerberus):
[quote]We recommend configuring the I/Os as follows:
● At the startup of the application:
– Enable all GPIO clocks
– Configure all I/Os in analog input mode
– Disable all GPIO clocks
● In the main application:
– Enable the required GPIO clock
– Configure the required I/Os on the application
● I/O configuration trick:
– If the user application just needs the I/Os to configure it as a peripheral alternate
function in order to output or input signals (no read or write from/to GPIO
registers), we recommend disabling the associated GPIO clock of the used I/Os
after configuration. In this case I/O signals are still available and we optimize the
GPIO current consumption by disabling its clock.
● I/O toggling frequency:
– When configuring the I/O, pay specific attention to the I/O speed value configured
in OSPEEDR (2 MHz, 10 MHz, 25 MHz, 50 MHz and 100 MHz). Current
consumption is as high as the I/O toggling frequency, so, to optimize current
consumption, OSPEEDR should be configured with the lowest possible value.
[/quote]
The “At the startup of the application” items should be taken care of by the NETMF firmware.
Thanks much for this detailed dialog, godefroi and randomr. I have learned a great deal that will be useful. Right now I’m only going to be testing how to optimally handle the ADC inputs, but knowing about the larger issue of what happens to I/O pins at reset should avoid future “gotcha’s”.
Just wrapping up this thread for future reference on what was determined for interfacing to the op amp as well as handling unused ADC pins. Still undetermined is what if any error a slight over voltage on AD0.0 might cause, but that will be for a future thread if more testing shows anything useful.
As mentioned earlier I was tying unused ADC pins AD0.1 through AD0.5 to ground so as not to leave them in what I thought was a floating state. Thanks to godefroi and randomr I now understand that these pins aren’t floating and are inputs pulled high internally at reset. To see how much current was being drained by tying to ground I measured each pin to ground and got 0.065 ma - pretty small, but X 5 it’s 0.26 ma. Since in my application, unlike randomr, I can live with the pins pulled high, I am going to leave them as is and remove the ground tie. These numbers imply an internal pull r of about 51K.
As for how to connect the op amp output to the ADC I followed advice in this thread and put in a 15K/100K voltage divider for two reasons. First it puts a resistor in series between the op amp and the ADC as is recommended in the LPC 2387 manual, and secondly because it guarantees that the ADC won’t see more than 3.3 volts. It worked nicely in this case because the op amp swings from zero to Vcc - 1.0volts. Vcc is the Panda II voltage so the swing is 4.75-1.0 = 3.75 volts. reduce that by 100/115 and you get 3.26 volts max at the ADC input.
One final item that will be raised in another thread if I find how to duplicate the behavior. Twice during these tests the AD0.0 input seemed to latch up and stay at ground level preventing any signal from being digitized. I haven’t been able to make this a repeatable phenomena, but one of the times it happened, I unplugged the Panda, shorted the AD0.0 pin to ground, and then restarted to find that it was back to normal. Like I said this will be another thread if I can get it to be repeatable, but it almost sounds like a CMOS latch up. If anyone has had a similar experience let me know and we can discuss in another thread.
Thanks for the summary. I am sure this will be helpful.