Arduino have unstable behavior

Please, a sketch that replicates this error or is this a guessing game?

Also, describe what you mean by "unstable" behavior.

The behavior of the code you described, as a snippet, is impossible to predict without knowing what board and what the rest of the sketch does, and whether there's anything external connected to those pins.

This is why you never post snippets - always a complete sketch, and always post which board you are using, and what, if anything, is connected to it. Otherwise, all you'll get is requests for that additional information, which is necessary to answer any question you might have asked.

PA3040:
Hi all

Above code only for example and the pin 0 and 1 not for what I used but above function can be nature of unexpected behavior

Hoped will explain

Don't feed the troll.

Hi All
Sorry for delay replied

You can see the source code for the Arduino digitalRead, digitalWrite, and pinMode functions in wiring_digital.c in the official Arduino AVR core. Each of those functions contains lines like the following:

#define digitalPinToPort(P) ( pgm_read_byte( digital_pin_to_port_PGM + (P) ) )
#define digitalPinToBitMask(P) ( pgm_read_byte( digital_pin_to_bit_mask_PGM + (P) ) )
#define digitalPinToTimer(P) ( pgm_read_byte( digital_pin_to_timer_PGM + (P) ) )

The digitalPinTo* macros, which are defined in Arduino.h, use the pin number as the array index without doing any bounds checking

Please advice

If P is an enumerated value or const....

it is representing pin number

Hear i think it is acting index number of array
You can see it is defined in pins_arduino.h or the pin map for the specific board being used.
Link
[pins_arduino.h](http://is defined in pins_arduino.h or the pin map for the specific board being used.)

If the programmer passes an invalid pin number for the processor, he/she will get garbage back.

If this relates to your original question regarding the use of pins 0 and 1, it's not the cause of your problem.

Yes
But

uint8_t timer = digitalPinToTimer(pin);
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);

The digitalPinTo* macros, which are defined in Arduino.h 1, use the pin number as the array index without doing any bounds checking:

PA3040:
The digitalPinTo* macros, which are defined in Arduino.h 1, use the pin number as the array index without doing any bounds checking:

As said, garbage in is garbage out.

I did not see a reply to the question if this relates to your original question. Or I did not understand your reply.

YES It is correct
garbage in is garbage out. lovely answer and well understood

But in this case it reads unrelated flash memory space in the flash which can case operate unpredictable pins that did not specify .

If you want bounds checked then write a function that checks the bounds but with a little experience you may see code where pin numbers are held in const arrays and named in enum statements that make coding pins easier and safer. When you do that, you don't get nonexisting pin numbers being used.

Approach your code so that it stay within bounds by how it works. Filter input as necessary but make it time spent once only.

Another disadvantage i when through PWM should off every time we called digitalWrite and pinMode

Because you change the function of the pin from PWM to digital I/O it stops being PWM and that is a PROBLEM?

Perhaps you should stop feeling so sure about what doesn't meet your very poorly informed expectations.

The Foundations section on the main Arduino site has links to explain the hardware and software.

GoForSmoke:
Because you change the function of the pin from PWM to digital I/O it stops being PWM and that is a PROBLEM?

Lets suppose PWM is ruing on pin number 6 and I want to change pin mode of pin 2 using pinMode function then what happened pin number 6 also stop

if (pin < NUM_DIGITAL_PINS)

PA3040:
Lets suppose PWM is ruing on pin number 6 and I want to change pin mode of pin 2 using pinMode function then what happened pin number 6 also stop

When I have PWM running on pin 6 and I change the mode of pin 2 it does not change what pin 6 is doing.

Maybe I could wire up a circuit that would make that appear to happen, otherwise maybe the AVR has been damaged or I wrote a bug.

PA3040:

if (pin < NUM_DIGITAL_PINS)

If you have to run that every time you use a pin number then you should learn to arrange your code better.

Just because you make sure the pin number exists does not mean that the pin is used. Pin numbers defined takes care of that, it's a long-ago solved problem looking for new coders to test.

Yeah, the Arduino core an libraries are not very big on error checking. In some cases, even where there is error checking, it looks like it would be less than fully effective ("if ( g_APinDescription[ulPin].ulPinType == PIO_NOT_A_PIN )" Sigh.)

Just don't call the functions with bad arguments, and everything will be fine!

In all honesty, there are several reasons that it is unreasonable to expect more error checking:

  • Performance - adding checks takes CPU cycles and memory space that can be in short supply on arduino-class microcontrollers. People already point at digitalWrite() and laugh at how "bloated and slow" it is (compared to other code that also lacks error checking.)
  • What to do? Ok, suppose you detect an incorrect pin number used in digitalWrite() - now what? Throw an error (not supported by the AVR-C++ compiler. Wouldn't be implemented if it were (see #1.) Print an error message on the console and return the the C: prompt? Nope. Reset the chip? Could be the worst possible thing to do... etc.
  • How far do you go? You mentioned checking against num_digital_pins. Ok. How about pins that are currently in analog input mode? In PWM output mode? Have some other alternate function (uart, SPI, TWI) in use (that isn't even "known" to the core)? Pins that are on the chip, but on brought out on the specific board? AVR Arduinos have a side effect that digitalWrite(p, 1) turns on the input pullup resistor if the pin is currently in input mode, but that isn't true of most other processors. (Some other cores contain "additional bloat and slowness" just to recognize and implement this. Which sucks.)

It's complicated, and it's usually not worth it.

(Now, I happen to have a scheme that would issue much better COMPILE-TIME error messages for invalid pin numbers/etc that are constants. I'm pretty worried that it will raise expectations, though: "how come "digitalWrite(26, HIGH)" generates an error, but not "bitbang_myproto(26, data)", even though it calls digitalWrite?")

Sigh.

We're also responsible for not writing text beyond the space we allotted for it.

We can address and change memory locations without any code-nanny making sure we will win, how cry out loud is that?

If you want guide rails, C/C++ is not the language for you.