Actions
Forum Thread Details
  • Replies 19 replies
  • Subscribers 388 subscribers
  • Views 4144 views
  • Users 0 members are here
Related

Best practices for Arduino I/O selection

colporteur

I'm currently working on a project using an Arduino knock-off Mega board. I discovered during prototype board development and testing an issue using I/O' 0 and 1. I found I could not control the output within my script. From online research, I discovered if I was using serial communication then I should avoid using those two I/O's. I wonder what other gotcha's don't know about?

I confess I am way down the scale of Arduinos knowledge. I label myself more of a resurrectionist rather than a programmer. I adapt code and solutions I find to solve my problems. Rarely if ever, have I built from scratch. This leads me to the title line "Best Practices for Arduino I/O selection". Are there any resources that provide this type of guidance? Are there I/O's to avoid and others that are better for a specific function?

I realize some I/O's are for specific purposes. I'm just thinking are there best practices using I/O's. I read the review posted on the site of this new book and thought maybe that has some suggestions. I'm looking for member experience.

Parents

  • Hi Sean,

    The usual board pinout diagrams often indicate all functions available per pin, so they can be used for guidance, but the ultimate authority is the chip datasheet.

    Example snippet (found via google images):

    image


    From my perspective (others may do it differently), the way I go about it is, to decide which connections in my circuit are the simplest (e.g. basic outputs like binary status LEDs) and assign them to the least flexible GPIO pins on the chip (using the usual board pinout diagrams, or the datasheet). Then, I'll look at the board-level serial interfaces (e.g. SPI, I2C) and choose pins that support those functions, but again the least flexible ones from all other perspectives, e.g. if one set of I2C pins also supports UART, then I will likely not select those I2C pins. For buttons I'll likely try to select pins that can work as interrupt inputs, if I just have a couple of buttons or so. For encoders, again interrupt-supporting pins are important/highly useful.


    And so on, working my way through all the pins, and hopefully as a result, ending up with spare pins which have a lot of functions still available. They can go to a future expansion connector if desired. Sometimes a slight second iteration is needed when laying out the board, to simplify some track paths.


    This strategy game of selecting pins is becoming less important with some recent processors, they are more orthogonal in that selecting one pin won't shut off the option of using integrated peripherals on another pin, it's a lot more configurable basically. The Pi Pico is an example kind-of approaching that (not entirely), where there is a fair amount of flexibility, one main exception is that analog inputs are still dedicated to particular pins. 

  • in reply to shabaz

    I use the same principles but the other way round. I first do the inflexible ones, like UART, i2c/SPI, pwm/timer , interrupt and analogue. Then sprinkle the easy ones across what's left over.

Reply Children
No Data