Arduino have unstable behavior

Other Hardware 3rd Party Boards
21

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.

22

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

23 
if (pin < NUM_DIGITAL_PINS)
24

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.

25

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.

26

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.

27

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.