Arduino.cc Zero

Development Tools IDE 1.x
1

Been a while since I played w/ a micro-controller and it was an early PIC coded in assembly.

Thought I understood these things .. then I bought a Zero ... :wink:

Question ..

On the Zero's Schematic the I/O pins are labeled TCC0 W0, W1 etc.

Is the how the device is configured by default, I'm assuming by the bootloader?

Cause it seems that most any I/O type can be multiplexed to any I/O pin.

Also .. is anyone aware of a utility to output a list of pins already configured ?

Being a total novice w/ C++ and relying on others example code I'm concerned I might reconfigure an essential I/O and waste years trying to debug a stupid mistake ..

THANKS !!

2

On the Zero's Schematic the I/O pins are labeled TCC0 W0, W1 etc.

Yep, that's what Atmel calls them.

Is the how the device is configured by default, I'm assuming by the bootloader?

Not by the bootloader, but by initialization code called before setup() in the user sketch. The arduino implements a very simplified abstraction of the chip. You have your "digital" pins suitable for pinMode() and digitalWrite() that are configured as GPIO input pins by default, and your "analog" pins that are configured as analog inputs. Some of the timers are configured as well, in order to provide the millis() clock tick, and the possibility of doing PWM output on some of the digital pins as well, but the timers aren't actually connected to the pins until you use an analogWrite() function.
There should be a picture somewhere with the board-level pinout described, but I can't seem to find one at the moment.

Cause it seems that most any I/O type can be multiplexed to any I/O pin.

Not really. The SAMDs are a lot less flexibility than you might think.

Being a total novice w/ C++ and relying on others example code I'm concerned I might reconfigure an essential I/O and waste years trying to debug a stupid mistake ..

If you stick to the arduino functions, it's not a problem you should run into. Not much, anyway. (0 and 1 are used for Serial, usually.) If you add additional libraries (for SPI or I2C) it's usually pretty well documented whether you're restricted to specific pins or not. If you go beyond that, you'll have to dig into the Atmel datasheets (and probably ask a lot of questions.)

3

westfw .. THANK YOU for going the distance and providing a very though response.

"by initialization code called before setup()" .. so the coder needs to provide linkage to this or it's automatic and "hidden"? I've not noted anything but directives and definitions before setup() in the sketches I reviewed.

Where can I find documentation on this and the Arduino functions you mentioned, I've yet to stumble upon them (I'll be looking while awaiting your response).

As to questions .. I'm sure as I ramp up .. I'll have plenty. Seems my desired goal due timing constraints is going to require me delving into assembly to achieve it .. if even possible .. things are looking pretty tight.

I'm a HW guy .. though I code in numerous high level languages, OOP included, I've avoided C/C++ as the ability to learn from reading code requires a universal translator ... :wink: but i can see a end goal in sight with perseverance and assistance from those such as yourself.

THANKS once again

4

Found it .. Arduino - Home

5

Reading the Arduino function documentation exactly illustrates my fears.

  1. There is no ref to included libraries so I'm left to assume they are ref by default via the Adruino IDE. What if I'm using another development environment aka Atmel Studio .. it was necessary as I needed to debug another's code/library that has issues with implementation on the Zero. Now there .. I prefer it. Are these libraries installed if the target is an Arduino project ? Rhetorical ..

  2. Reading up on AnalogWrite() .. it's frequency is limited and low as the HW seems to be shared with other functions .. not sure I understand why as there seems to be more than enough timers in the Cortex such that this wouldn't be necessary, but this illustrates my concerns about my reconfiguring the HW .. I could incapacitate other code dependencies I'm unaware of .. I'd hate to debug that ..

  3. I'm realizing that to get to the understanding I desire is going to require boring deep into the user & core libraries to evaluate HW usage/configuration. Unfortunately the core is written assuming knowledge and is poorly commented. Not a good place for a novice C++ person to be. .. :wink: It would be so much easier if I could run a routine and get a report of what is and is not configured .. :wink:

6

"by initialization code called before setup()" .. so the coder needs to provide linkage to this or it's automatic and "hidden"?

Yes. See Redirecting

Reading the Arduino function documentation exactly illustrates my fears.

Be aware that the "reference" is for Arduinos "in general" (and was written in the AVR days) and is not specific to the Zero (and in fact may have errors when it comes to a particular "newer" arduino board.) Also, it's written for the target arduino user, who doesn't have your degree of HW knowledge.

  1. There is no ref to included libraries

Did you miss the "libraries" tab at the top? Libraries - Arduino Reference
Also sucked in will be a standard C library (avr-libc for avr, and I think "newlib nano" for the ARM chips. There may be some of Atmels libraries (ASF, etc) as well. Nth party libraries can be documented better, or worse. (Adafruit tends to have a tutorial for every library. Others: you get to read the code.)

Don't forget that this IS "Open Source Software", so reading the code is always a possibility.

What if I'm using another development environment aka Atmel Studio

Theoretically, Atmel Studio 7 includes a feature to import Arduino Sketches, and I think it's supposed to import the needed libraries as well. There have been some hints that maybe this only works right with AVR sketches, so far. There is also the "Visual Micro" plugin that provided similar capabilities for AS6.x. (These work by having you install the arduino IDE, and then copying the libraries from there. One reason they break is because the IDE has been changing its directory structure around.)

  1. Reading up on AnalogWrite() .. it's frequency is limited and low as the HW seems to be shared with other functions .. not sure I understand why as there seems to be more than enough timers in the Cortex such that this wouldn't be necessary

Backward compatibility with the AVR implementation. Cortex has SysTick for the millis() timer, and other timers that do PWM, but AVR only has a few simple timers, so they used one of them with overflow for the systick, and the compare registers (two per timer) for PWM. Also, the SAMD has several types of timers, and it's not clear that the code currently knows how to do PWM with all of them. And in my experience (on a SAMD10, not with an Arduino Zero), sometimes the same pins connect to two different kinds of timers, so you can't use them both at the same time.

I could incapacitate other code dependencies I'm unaware of .. I'd hate to debug that ..

I think you're overly concerned. The arduino core is very simple, without a lot of dependencies to mess up. The more likely scenario is whether the "tone" library will interfere with the "timer" library, and how that interacts with the "servo" library...

It would be so much easier if I could run a routine and get a report of what is and is not configured .. :wink:

I guess. I don't know of anything like that, though it would be an interesting project.
Systick, A2D, and GPIO are configured and enabled. Several other peripherals have their power and clocking configured for "possible future use." It all happens in the init() function, which is not very long.

The nature of modern microcontrollers is that they share a lot of different functions on a small number of pins. Figuring out and debugging conflicts is part of the game, whether you use Arduino, Atmel Studio, or raw assembler...

7

THANK YOU .. very much !!!

8

if I could run a routine and get a report of what is and is not configured

it would be an interesting project.

I've looked into this some more, and it does seem like it would be quite possible. The pin multiplexing on the SAMD chips is pretty simple - a pin is ether GPIO, or it is set to "PinMux function" that can have 1 of 8 different choices, arranged in neat categories. (This is much nicer than the SAM3X on Due, for example. And much different :frowning: )
This means that you could write an implementation in stages:

  • You just report the state of the GPIO/PinMux flag, and the value of the pinmux function.
  • Assign category names to the pinmux functions (EIC, ADC, TIMER, SERCOM)
  • Figure out pin-specific functions (ie which TIMER or SERCOM)
  • Dive deeper (figure out whether the SERCOM is UART, SPI, I2C, or whatever. Show GPIO direction/etc.)
    I may give this a try. It's the sort of code I like to write.
    I guess I'll need to get a SAMD21-based board first, though :slight_smile: (It figures that I've got one of almost everything else...)
9

Judging from your apparent knowledgebase .. I think you should .. just to keep you entertained ...

Something crude .. may save you some leg work ..

int32_t RegAddr[34]={0x40000000UL,0x40000400UL,0x40000800UL,0x40000C00UL,0x40001000UL,0x40001400UL,0x40001800UL,0x41000000UL,0x41002000UL,0x41004000UL,0x41004400UL,0x41004800UL,0x41005000UL,0x41006000UL,0x41007000UL,0x42000000UL,0x42000400UL,0x42000800UL,0x42000C00UL,0x42001000UL,0x42001400UL,0x42001800UL,0x42001C00UL,0x42002000UL,0x42002400UL,0x42002800UL,0x42002C00UL,0x42003000UL,0x42003400UL,0x42004000UL,0x42004400UL,0x42004800UL,0x42005000UL,0x60000000UL
};

String RegName[34]={"PAC0","PM","SYSCTRL","GCLK","WDT","RTC","EIC","PAC1","DSU","NVMCTRL","PORT","DMAC","USB","MTB","SBMATRIX","PAC2","EVSYS","SERCOM0","SERCOM1","SERCOM2","SERCOM3","SERCOM4","SERCOM5","TCC0","TCC1","TCC2","TC3","TC4","TC5","ADC","AC","DAC","I2S","PORT_IOBUS"};

void setup()
{
Serial.begin(9600);
while (!Serial) {
// wait for serial port to connect. Needed for Leonardo only
}

}

void loop()
{
for(int i=0;i<35;i++){
int32_t Pntr = (int32_t) RegAddr*;*
_ Serial.print (RegName*);_
_ Serial.print (" 0x");_
_ Serial.print (RegAddr,HEX);
 Serial.print (" 0x");
Serial.println(Pntr,HEX);
 }
}_

10

Pushed it a little further .. thinking this is a bit too deep .. seeing it's still spewing irrelevant data ..

void getRegisters () {

int32_t RegAddr[34]={0x40000000UL,0x40000400UL,0x40000800UL,0x40000C00UL,0x40001000UL,0x40001400UL,0x40001800UL,0x41000000UL,0x41002000UL,0x41004000UL,0x41004400UL,0x41004800UL,0x41005000UL,0x41006000UL,0x41007000UL,0x42000000UL,0x42000400UL,0x42000800UL,0x42000C00UL,0x42001000UL,0x42001400UL,0x42001800UL,0x42001C00UL,0x42002000UL,0x42002400UL,0x42002800UL,0x42002C00UL,0x42003000UL,0x42003400UL,0x42004000UL,0x42004400UL,0x42004800UL,0x42005000UL,0x60000000UL
};

String RegName[34]={"PAC0","PM","SYSCTRL","GCLK","WDT","RTC","EIC","PAC1","DSU","NVMCTRL","PORT","DMAC","USB","MTB","SBMATRIX","PAC2","EVSYS","SERCOM0","SERCOM1","SERCOM2","SERCOM3","SERCOM4","SERCOM5","TCC0","TCC1","TCC2","TC3","TC4","TC5","ADC","AC","DAC","I2S","PORT_IOBUS"};

for(int i=0;i<35;i++){
int32_t Pntr = (int32_t) RegAddr*;*
int32_t offAddr = RegAddr*;
_ Serial.print (RegName);
 Serial.print (" 0x");
 Serial.println (offAddr,HEX);
 Serial.println ("==============================================================");
 while(offAddr < RegAddr[i + 1]){
if(Pntr != 0) {
 Serial.print ("0x");
* Serial.print (offAddr,HEX);
 Serial.print (" 0x");
Serial.println(Pntr,HEX);
 }
* Pntr = Pntr + 4;
 offAddr = offAddr + 4;
 }
 }
}*_

11

You can give this a try. "It compiles." (I haven't received my board yet...)

/*
 * Pin multiplexer value names (PMUXn.PMUXE/O)
 */
const char *pinmux_names[8]={
  "EIC",   // "A": External Interrupts
  "ADC",   // "B": REF, ADC, AC, PTC, DAC
  "SERCOM",   /* "C": SerCom */
  "SERCOMALT",  /* "D": Alternate SERCOM */
  "TC/TCC",     /* "E": TC or TCC Timer */
  "TCC",        /* "F": TCC Timer*/
  "COM",        /* "G": Other Comm - USB, I2S */
  "AC/GCLK"     /* "H": Analog Comparator or GCLKs */
};

boolean print_pinno(int i)
{
  int pintype = g_APinDescription[i].ulPinType;
  if (pintype == PIO_NOT_A_PIN) {
    return false;
  }
  Serial.print(i);
  if (pintype == PIO_ANALOG) {  // try to detect and renumber Analog pins.
    Serial.print(" (A");
    Serial.print(i - PIN_A0);
    Serial.print(") ");
  } else {
    Serial.print("      ");
  }
}

void print_pinmux(int pmuxval)
{
  Serial.print("PMUX ");
  Serial.print(pinmux_names[pmuxval]);
  Serial.print("(");
  Serial.print(pmuxval);
  Serial.print(")");
 }

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  Serial.println("SAMD Pin State Report");
  Serial.println();

  for (int pin=0; pin < PINS_COUNT; pin++) {
    if (print_pinno(pin)) {  // Does pin exist?
      
      int bitno = g_APinDescription[pin].ulPin;
      PortGroup *port = digitalPinToPort(pin);
      int pmuxval;

      if (port->PINCFG[bitno].bit.PMUXEN) {  // Is pinmux enabled?
        // If pinmux is enabled, further report it's value
        if (bitno & 1) {
          // Odd pin numbers
          pmuxval = port->PMUX[bitno/2].bit.PMUXO;
        } else {
          pmuxval = port->PMUX[bitno/2].bit.PMUXE;
        }
	print_pinmux(pmuxval);
    } else {
        // Pinmux not enabled - port is GPIO
        Serial.print("GPIO ");  
        if (port->DIR.reg & (1<<bitno)) {  // Decode pinmode (direction.)
          Serial.print("O");
        } else {
          Serial.print("I");
        }
      } // Pinmux or GPIO
    } // Pin existance
    Serial.println();
  } // "pin" for loop
}

void loop() {
  // put your main code here, to run repeatedly:

}
12

With understanding comes such a more elegant solution than my brickwall hacking ..

... and it so limits my need to further research regs/bit states (not sure that's a good thing given my current point on the curve) .. :wink:

seems to work .. output is consistent with what I'd expect with the code snippits I've pieced together ..

THANK YOU so much for taking the time ..

13

westfw:
I've looked into this some more, and it does seem like it would be quite possible. The pin multiplexing on the SAMD chips is pretty simple - a pin is ether GPIO, or it is set to "PinMux function" that can have 1 of 8 different choices.......

Teensy has very similar pin configure mux hardware. Until about a year ago, the answer had been pretty much the same... dive deep into the chip's reference manual, matching up the Arduino compatible pin numbers to the chip's naming conventions using the schematic. Works, but not a simple and easy Arduino-style experience.

Recently I've added Serial1.setTX(pin) & Serial1.setRX(pin), Wire.setSDA(pin) & Wire.setSCL(pin), and SPI.setSCK(pin) & SPI.setMISO(pin) & SPI.setMOSI(pin). While they can accept any pin number, they only do something when giving a pin the peripheral actually supports for that signal.

Initially I designed the SPI ones, where they just set some bits used by SPI.begin(). Questions from users showed people expected these functions to be usable even after the SPI was up and running. When I later added them to Wire, Serial1, Serial2 and Serial3, I designed them to dynamically reassign the pins if the peripheral was already active, or set a variable to be used by begin() if called before the peripheral is active. That's some extra code and a couple bytes of RAM usage, but it seems to provide a much better overall user experience.

I have no idea if Arduino will ever adopt this API or something similar on Zero or any of their other boards. But long-term, these microcontrollers are becoming increasingly flexible in pin assignments and packing more peripherals into similar pin counts, so the need for easy pin config is growing. I've been trying to refine how to do this, mostly because it's needed on Teensy, but also (eg, this message) because the entire Arduino community will eventually need something like this.

14

Well, that was a little embarrassing. One should remember to have functions declared as "boolean" actually return a value. (rather easier if SOMEONE doesn't turn off all the warnings from the compiler. Grr.)

Edit: add github link: GitHub - WestfW/ArduinoZero-PMUX-report: Generate a user-readable report of the current state of the pins (what they're doing) on Arduino Zero and other SAMD21 based systems

In any case, the hardware i'd ordered has arrived, so I was able to do some actual debugging and tuning. The output now looks like this:

SAMD Pin State Report

0       PMUX(2) SERCOM
1       PMUX(2) SERCOM
2       GPIO I
3       GPIO I
4       GPIO I
5       GPIO I
6       GPIO I
7       GPIO I
8       GPIO I
9       GPIO I
10      GPIO I
11      GPIO I
12      GPIO I
13      GPIO I
14 (A0) PMUX(1) ADC
15 (A1) PMUX(1) ADC
16 (A2) PMUX(1) ADC
17 (A3) PMUX(1) ADC
18 (A4) PMUX(1) ADC
19 (A5) PMUX(1) ADC
20      GPIO I
21      GPIO I
22      GPIO I
23      GPIO I
24      GPIO I
25      GPIO I
26      GPIO I
27      GPIO I
28      PMUX(6) COM
29      PMUX(6) COM
30      PMUX(3) SERCOMALT
31      PMUX(3) SERCOMALT

(Note that the Sparkfun has some "extra" pins available, since it doesn't have the EDBG chip.)

Using this code:

#define mySerial SerialUSB

/*
   Pin multiplexer value names (PMUXn.PMUXE/O)
*/
const char *pinmux_names[8] = {
  "EIC",   // "A": External Interrupts
  "ADC",   // "B": REF, ADC, AC, PTC, DAC
  "SERCOM",   /* "C": SerCom */
  "SERCOMALT",  /* "D": Alternate SERCOM */
  "TC/TCC",     /* "E": TC or TCC Timer */
  "TCC",        /* "F": TCC Timer*/
  "COM",        /* "G": Other Comm - USB, I2S */
  "AC/GCLK"     /* "H": Analog Comparator or GCLKs */
};

boolean print_pinno(int i)
{
  int pintype = g_APinDescription[i].ulPinType;
  if (pintype == PIO_NOT_A_PIN) {
    return false;
  }
  mySerial.print(i);
  if (i < 10)
    mySerial.print(" ");
  if (pintype == PIO_ANALOG) {  // try to detect and renumber Analog pins.
    mySerial.print(" (A");
    mySerial.print(i - PIN_A0);
    mySerial.print(") ");
  } else {
    mySerial.print("      ");
  }
  return true;
}

void print_pinmux(int pmuxval)
{
  mySerial.print("PMUX");
  mySerial.print("(");
  mySerial.print(pmuxval);
  mySerial.print(") ");
  mySerial.print(pinmux_names[pmuxval]);
}

void setup() {
  mySerial.begin(9600);
  while (!mySerial)
    ;
  mySerial.println("SAMD Pin State Report");
  mySerial.println();

  // Set some pins up doing something different, so that the display will be
  //   more ... interesting.
  Serial1.begin(9600);
  Serial.begin(9600);
  for (int j = 0; j < 6; j++)
    (void) analogRead(j);  // read from analog pins
}

void loop() {
  for (int pin = 0; pin < PINS_COUNT; pin++) {
    if (print_pinno(pin)) {  // Does pin exist?

      int bitno = g_APinDescription[pin].ulPin;
      PortGroup *port = digitalPinToPort(pin);
      int pmuxval;

      if (port->PINCFG[bitno].bit.PMUXEN) {  // Is pinmux enabled?
        // If pinmux is enabled, further report it's value
        if (bitno & 1) {
          // Odd pin numbers
          pmuxval = port->PMUX[bitno / 2].bit.PMUXO;
        } else {
          pmuxval = port->PMUX[bitno / 2].bit.PMUXE;
        }
        print_pinmux(pmuxval);
      } else {
        // Pinmux not enabled - port is GPIO
        mySerial.print("GPIO ");
        if (port->DIR.reg & (1 << bitno)) { // Decode pinmode (direction.)
          mySerial.print("O");
        } else {
          mySerial.print("I");
        }
      } // Pinmux or GPIO
    } // Pin existance
    mySerial.println();
  } // "pin" for loop

  while (mySerial.read() < 0)
    ;  // wait for character to run again.
  mySerial.println("\nRunning again!\n");
}
15

I hadn't noted an issue w/ your original code .. compiled fine .. worked superbly .. got off and on to my next headache .. :slight_smile:

THANK Again !!

16

Keeping busy. Added further detail in sercom, com, and timer decodes:

SAMD Pin State Report

0       PA11  PMUX(2) SERCOM0 P3(UART)
1       PA10  PMUX(2) SERCOM0 P2(UART)
2       PA14  GPIO I
3       PA09  GPIO I
4       PA08  GPIO I
5       PA15  GPIO I
6       PA20  GPIO I
7       PA21  GPIO I
8       PA06  GPIO I
9       PA07  GPIO I
10      PA18  PMUX(4) TC3/WO0
11      PA16  GPIO I
12      PA19  PMUX(5) TCC0/WO3
13      PA17  GPIO O
14 (A0) PA02  PMUX(1) ADC
15 (A1) PB08  PMUX(1) ADC
16 (A2) PB09  PMUX(1) ADC
17 (A3) PA04  PMUX(1) ADC
18 (A4) PA05  PMUX(1) ADC
19 (A5) PB02  PMUX(1) ADC
20      PA22  PMUX(2) SERCOM3 P0(I2C Master)
21      PA23  PMUX(2) SERCOM3 P1(I2C Master)
22      PA12  PMUX(3) SERCOM4 P0(SPI Master)
23      PB10  PMUX(3) SERCOM4 P2(SPI Master)
24      PB11  PMUX(3) SERCOM4 P3(SPI Master)
25      PB03  GPIO I
26      PA27  GPIO I
27      PA28  GPIO I
28      PA24  PMUX(6) COM(USB)
29      PA25  PMUX(6) COM(USB)
30      PB22  PMUX(3) SERCOM5 P2(UART)
31      PB23  PMUX(3) SERCOM5 P3(UART)

The code is getting longer, so you'll have to retrieve it from The github page

17

There are some interesting things to point out...

SAMD Pin State Report

0       PA11  PMUX(2) SERCOM0 P3(UART)
1       PA10  PMUX(2) SERCOM0 P2(UART)
2       PA14  GPIO I
3       PA09  GPIO I
4       PA08  GPIO I
5       PA15  GPIO I
6       PA20  GPIO I
7       PA21  GPIO I
8       PA06  GPIO I
9       PA07  GPIO I
10      PA18  PMUX(4) TC3/WO0        [color=brown]Both TC and TCC counters are used to implement analogWrite[/color]
11      PA16  GPIO I
12      PA19  PMUX(5) TCC0/WO3
13      PA17  GPIO O
                                            [color=brown]All 14 "digital" pins are on PortA[/color]
14 (A0) PA02  PMUX(1) ADC
15 (A1) PB08  PMUX(1) ADC
16 (A2) PB09  PMUX(1) ADC
17 (A3) PA04  PMUX(1) ADC
18 (A4) PA05  PMUX(1) ADC
19 (A5) PB02  PMUX(1) ADC
20      PA22  PMUX(2) SERCOM3 P0(I2C Master)
21      PA23  PMUX(2) SERCOM3 P1(I2C Master)
22      PA12  PMUX(3) SERCOM4 P0(SPI Master)   [color=brown]// "p1" not used by Arduino SPI library[/color]
23      PB10  PMUX(3) SERCOM4 P2(SPI Master)
24      PB11  PMUX(3) SERCOM4 P3(SPI Master)
25      PB03  GPIO I               [color=brown]// PIN_LED_RXL[/color]
 [color=brown]                                                 PINS_COUNT is normally 26 on Arduino Zero.
                                                  other boards may break out additional pins,
                                                  especially if they don't have an EDBG chip.
                                                  Not sure if this is feature, or bug.
                                                  variant.cpp defines 44 pins, along with #define aliases[/color]
26      PA27  GPIO I               [color=brown]//PIN_LED_TXL[/color]
27      PA28  GPIO I
28      PA24  PMUX(6) COM(USB)
29      PA25  PMUX(6) COM(USB)
30      PB22  PMUX(3) SERCOM5 P2(UART)     [color=brown] // UART connected to EDBG chip,[/color]
31      PB23  PMUX(3) SERCOM5 P3(UART)      [color=brown]//  (or extra HWSerial on non-EDBG boards.)[/color]
32      [color=brown]PA22[/color]  PMUX(2) SERCOM3 P0(I2C Master)
33      [color=brown]PA23[/color]  PMUX(2) SERCOM3 P1(I2C Master)
34      PA19  PMUX(5) TCC0/WO3
35      [color=brown]PA16 [/color]  GPIO I                      [color=brown]// Some "distinct pins" refer to the same chip pins.[/color]
36      [color=brown]PA18[/color]  PMUX(4) TC3/WO0
37      [color=brown]PA17[/color]  GPIO O
38      PA13  GPIO I
18

Well there ya go .. you've gone and created a down right useful tool .. THANK YOU so much !!
Many I believe will find it quite helpful as I already have Atmel docs leave a little to be desired IMHO.

Now .. might I PM you my latest issue ?

19

might I PM you my latest issue ?

It's better to start a public forum discussion, and PM me with a pointer in case it's in a category I don't read regularly.

20

see .. Scope issue ?? - Programming Questions - Arduino Forum

Go to bottom .. I took the discussion on a tangent re. headers ..

THANKS for any assist !!