Arduino MEGA2560: Where is the "more" defined?

Hi,

This may be a totally dumb question based on the very very low level of coffein in my head this evening and therefore not being able to recognize the (may be) obvious ... nonetheless: Here comes the question:

With ATMega328-based boards there are quite a few GPIO-pins with some alternate functions like one UART, one SPI etc...most sketches out there are based on this design.

For my Nixie clock I need a lot more GPIOS (I dont want to multiplex the tubes, because this does radically shorten their lifetime (or gives you very dim glow)) so I bought a board based on the ATmega2560 (no USB though).

How are the pins named? Where can I find for example the file with the definition/configuration for a ATmega2560 based board which -- for example -- explain the compiler, that there is no GPIO D911? What configuration prohibits to read data from UART#7?

Is there any documentation, which explains, what is available (and name it syntactically correct)?

I mean...beside the 600++ pages of the ATmega2560 datasheet, which is not THAT Arduino compatible?

Thanks a lot for any help in advance ! Cheers mcc

mcc01: How are the pins named? Where can I find for example the file with the definition/configuration for a ATmega2560 based board

Here it is: https://github.com/arduino/Arduino/blob/1.8.3/hardware/arduino/avr/variants/mega/pins_arduino.h

mcc01: for example -- explain the compiler, that there is no GPIO D911? What configuration prohibits to read data from UART#7?

For the most part the code just assumes that the user is going to pass a valid pin number. Otherwise you will get undefined behavior. Any checks for pin number validity are going to add overhead to functions that are already way to slow.

mcc01: Is there any documentation, which explains, what is available (and name it syntactically correct)?

It's not clear what you mean by that.

mcc01: explain the compiler, that there is no GPIO D911? What configuration prohibits to read data from UART#7?

If you look at the source code for the pin manipulation functions, you'll find that they just pass it to pgm_read_byte() to read from an array, without bounds checking. It is the responsibility of the author of the sketch to ensure that they pass valid pin numbers. If you try to use a constant like D100, that would error on compile, since the pins_arduino.h for that variant only defines constants of the form D# for pins that exist, but if you passed the number 100, for example, that would make it until it read way off the end of the arrays in progmem and got back nonsensical results and tried to use them.

UART7 would fail at compile time, since there wouldn't exist a Serial7 - the core only supports up to 4 UARTs, and the code corresponding to each one checks whether the relevant registers exist (the register names come through the compiler-supplied io.h, which in turn includes a file specific to the processor (supplied by Atmel) that #defines all the registers and bits within the registers), and the Serial object is only provided if the corresponding registers are there.

Hi,

thanks a lot for the help! :) Very useful! :)

The check, whether D911 is a valid one could be done by a preprocessor. That would take off the burden from the CPU and flag an error even before compilation has started. This preprocessor would need kinda setup file...which I tried to find. But there is not a preprocessor of this kind.

By the way...slow functions...: Is there any other framework available (beside the official ATMEL/Microchip stuff) which eases the handling of ATmegas/ATtinys (PIN handling and such) but leave more to program for the user which on the other hand put not THAT much "default software" being compiled and flashed onto the chip and gives the whole thing more e=m*c^2 ? ;) (I have no problem using vi and makefiles and the bare gcc...But I hate to read 600++ pages datasheet before the first LED gets lit...)

Cheers mcc

mcc01: The check, whether D911 is a valid one could be done by a preprocessor. That would take off the burden from the CPU and flag an error even before compilation has started. This preprocessor would need kinda setup file...which I tried to find. But there is not a preprocessor of this kind.

As DrAzzy said, all you need to do is define Dn for all the valid pins, then if you attempt to use a pin name that was not defined compilation will fail with a "'D911' was not declared in this scope" error. I just don't think it's a very common issue that people are using pins that don't exist, I mean you're going to know which pin you plugged the LED into. The only time I could see this possibly happening is if the pin number was determined programmatically and there is a bug in the code but neither the preprocessor nor the compiler is going to be able to help you there.