Analog inputs A6 and A7

It would be helpful if the statement "pinmode(A6, INPUT_PULLUP)" created an error, since there is not pullup on these pins.

Sure but that line of code isn't an error.

It would probably be more helpful if people read the basic documentation on these board before they just dive in to use them. That would make it pretty clear that A6 and A7 can't be used as digital pins. Then trying to set the pinMode like that would be a moot point.

We still end up having to explain it to them here because they won't read what's already written. We'd just be explaining why it threw this error instead of why it doesn't work. We still end up with the same questions from the same folks who refuse to read before they start working.

I appreciate your point of view, but I maintain that you are wrong. There is no pullup resistor on A6, so the code implies that it is doing something that it can't.

As for reading the documentation, I am willing bet that no one has read and understood the entire Arduino manual. It is hundreds of pages of many times indecipherable text and tables (I give you the timers as a prime example) that only a person interested in a specific function would take the time to read, much less understand.

Now, if there's a nifty 40 page text that explains everything a person would need to know, I'll be glad to read it.

In the mean time, I believe it is the responsibility of the compiler writers to assist programmers when they can. If it's more effort than it's worth, that's fine, too.

Thanks.

The compiler doesn't know anything about the chip. It just knows that you tried to write a value to a register. The compiler has no way to know that this register write does nothing useful on the chip. It only knows that a value was written to a writable register and that's legal code.

As for reading the datasheet, yes several of us have. I can at least speak for myself I've been through the whole long boom for the 328 several times. I recommend it. Will take hours or maybe even days depending on your speed but it's far from impossible.

If you go through life avoiding things like reading datasheet because it looks hard, then you spend your life learning things the hard way.

I had to laugh, because of course you are right (in a very narrow sense). Hey, I've been writing code since 1965 (yeah) and this is about my 9th language and probably 12th processor. So my hat's off to all you professionals who make this your core work.

On the other hand, I've done a couple of side things. Purple Heart, got the F-117 operational, managed the technical side of the B-2, took 2000+ engineers into secret places, wrote the proposal for the StratoLaunch aircraft. These days I love the Arduino and my 3D printers as the best tools ever. Where were they when I was 30 and erasing EPROMS with UV?

So I don't mind getting my lessons the hard way. I do try to avoid being totally stupid, but RTFM just isn't in my vocabulary.

Thanks very much for taking the time.

but RTFM just isn't in my vocabulary.

But it is absolutely stupid to do things the hard way when you have the info at your fingertips and all you have to do is accept it. Only a fool throws out the words of those who know better to fly by the seat of his pants. It works great in movies but not so much in real life.

Works good 95% of the time. The other 5% one is either angry or eaten by the enemy.

BTW, I'm beginning to think you are a Jedi or maybe just a philosopher savant? I am interested in this "info at your fingertips." I think you missed the part about the 4 hours of looking for it, even if it is sitting right on your hard drive.

Note: It took me five minutes on the forum to find the "no pullups" remark. Better than reading 200+ pages and maybe still not finding the right paragraph.

I don't know what you're arguing anymore. If you think reading documentation is dumb then that's fine. But don't get mad because someone didn't go transcribe the whole datasheet into error codes to stop you from doing stupid shit by the seat of your pants.

How exactly was that supposed to happen anyway without someone knowing what was in the datasheet?

You miss the point. I made a suggestion which I thought would be helpful. It appears that targeting this specific command for special treatment is outside the scope of what you think is appropriate. So be it.

But you also miss the point that there are some aspects of processors that are nuances that take enormous amount of time to ferret out, and that ferreting is only worth the time if the problem is (1) important and (2) not easily resolved by getting help from others.

This one was not such a minor nuance; it was easily fixed.

I do appreciate the help of experts like yourself, but I would add that you could use a bit more gain on your humor and sarcasm detectors.

  1. There's no way to check this at compile time. The arguments to pinMode() need not even be constants.
  2. There's no way to indicate errors at run-time; you can't abort the program and have the OS print an error message or do a core dump. There is no OS.
  3. That was assuming that you could DETECT the errors at run time. There's nothing on the chip that prevents you from using A6/A7 as digital IO. It just won't work. On an Uno. Hypothetically, it might work on other chips. You can drop in an ATmega328PB, and suddently A6/A7 CAN do digital IO.

I've occasionally thought that it would be nice to have some errors somehow "saved", so that they could be examined later, sort of like C's "errno." Especially for the cases where the code is already detecting an error, and just ignoring it.
Users could add a library and call a function that would print "non-existent pin referenced", "function not available on pin" or whatever...

There are some third-party additions that wrap C++ objects around pins, using templates. I think that in theory, they could detect errors like this, given restrictions (constant pin number values) not in the current code. I don't know if any of them do.

On the third hand, input pullups in general are a bit of an afterthought in the Arduino APIs. Not well handled :frowning:
DigitalWrite() for many more modern chips contains special code to duplicate the historical behavior of the AVR chips used originally ("pinMode(x, INPUT); digitalWrite(x, HIGH);" turns on pullups), and it messy and slow.

Westfw,

Love your 1-2-3 factoids. At one point I was a Forth programmer and you could do all kinds of stuff at run time. But you were always asking yourself where the heck is the stack pointer.

I don't have a problem designing pullups onto the PCB, but I really hate tacking them on as an afterthought.

Thanks.

I don't have a problem designing pullups onto the PCB, but I really hate tacking them on as an afterthought.

What good to add external pull-ups? You still can't use those pins as digital pins.

Good point. I'm not using them as digital inputs. It turns out if you want to detect changes in a high impedance circuit due to moisture, you need an excitation source. So if you tie a pullup to the pin, changes in the impedance to ground of the external circuit can be detected by a voltage change at the analog pin. You're basically making a voltage divider. This could just as well have been done digitally, but I was out of pins.

It turns out that this system "measures" water in an old RV holding tank. Slightly newer versions of the tank system had a resistor ladder that required analog reading, since the output of the ladder came to the controller on one wire. So analog inputs allows the Arduino to work with both types of tanks without modification.

Sure, I guess you can read any analog pin (at ADC speeds) and convert to digital based on whatever thresholds you want... Relying on the (inaccurate) pullup for an actual analog reading seems like a bad idea, though.

(Does input_pullup work on A0..A5? I can't tell from the datasheet...)

westfw:
(Does input_pullup work on A0..A5? I can't tell from the datasheet...)

It does. What I don't remember right off is if calling analogRead does anything to them.

(Does input_pullup work on A0..A5? I can't tell from the datasheet...)

It does. What I don't remember right off is if calling analogRead does anything to them.

I meant "when they are in analog mode." ("Obviously" they work when the pins are in digital mode.)
If you don't care much about accuracy, you could reduce component and wiring costs for analog components that were effectively current sinks...

there could be thousands checks like this one proposed.

westfw,

absolutely correct. Bad idea to use imprecise pullups to set up a real analog input. But even when I need them to be real analog for those resistor ladders, the jumps in voltage as the tank fills is on the order of 0.7 volts, so it's easy to discriminate with wide thresholds.

Package pin A0 to A5 are connected either :

  • to an I/O numerical PORT
  • to an analog mux input.

Package pin A6 and A7 are connected only to an analog mux input.

pinMode apply only to numerical I/O.
pinMode(A6, inputPullup) do nothing.

When you want to program a microcontroler you have to manage electronic and you can't avoid reads his datasheet.

Notice also that nano and mini-pro are not introduced by Arduino but by Gravitech and Sparkfun.