RFC: Separation of MCU and board identities in FPC

[ccrause]

FPC currently supports using board aliases which then loads the underlying controller unit automatically (see e.g. ARDUINO_DUE and ARDIUNO_LEONARDO}.  Unfortunately (in my opinion) the board alias is currently treated as another separate controller type (see ct_arduinoleonardo vs ct_atmega32u4).

This leads to redundant checks, for example the usb.pas unit written for the atmega32u4 (MCU on the Arduino Leonardo and Pro Micro boards) contain checks for FPC_MCU_ARDUINOLEONARDO.  This unit does not compile correctly if the user specifies that the atmega32u4 controller is used, even though it should.  The workaround is to include all possible board aliases and the MCU in the conditional check, which is redundant since the board definition implicitly encapsulates the controller type.

My proposal is to remove board aliases from the list of controller types, moving board aliases to a separate list that contains a reference to the underlying controller.  When a user then specifies a board alias, the compiler should then generate the controller define (e.g. FPC_MCU_ATMEGA32U4) when the board alias is specified, and the board alias should then be defined as a separate value (e.g. FPC_BOARD_LEONARDO).

To not add yet another command line option, I also propose to re-use the -Wp command line option to specify either the board alias or the controller name.

Any comments on this suggestion?

[ackarwow]

@ccrause,

Sorry for commenting so late - I just found this thread.
Regarding usp.pas, I can (and I think I should) use a different conditional compilation adding FPC_MCU_ATMEGA32U4 to conditionals:

Code: Pascal  [Select][+][-]

1. {$if defined(FPC_MCU_ARDUINOLEONARDO) or defined(FPC_MCU_ATMEGA32U4)}
2. EPDIR = 0;
3. EPTYPE0 = 6;
4. EPTYPE1 = 7;
5.  
6. USB_ENDPOINTS = 7; // AtMegaxxU4
7. {$endif}
8.  

I have corrected this in the UnoLib sources.

In my opinion, the current FPC architecture is sufficient. From my perspective - developing the AVRPascal IDE, an ARDUINOLEONARDO is one thing, and an ATMEGA32U4 is another, so repeating the definitions is convenient for me. In my IDE, the Leonardo and ATMega32u4 appear as separate devices in the list of available devices, and I can easily map the selected device to a compiler calling parameter. So, from my perspective, the current situation is good and convenient, and nothing needs to be changed.

But your suggestion of adding the FPC_BOARD_LEONARDO alias is logical. What would my conditional code for the Leonardo/ATmega32U4 look like in that case?

[ccrause]

In my opinion, the current FPC architecture is sufficient. From my perspective - developing the AVRPascal IDE, an ARDUINOLEONARDO is one thing, and an ATMEGA32U4 is another, so repeating the definitions is convenient for me. In my IDE, the Leonardo and ATMega32u4 appear as separate devices in the list of available devices, and I can easily map the selected device to a compiler calling parameter. So, from my perspective, the current situation is good and convenient, and nothing needs to be changed.

But your suggestion of adding the FPC_BOARD_LEONARDO alias is logical. What would my conditional code for the Leonardo/ATmega32U4 look like in that case?

The idea is that a board alias must describe additional information that cannot be deduced from the mcu itself.  For example when specifying FPC_MCU_ATMEGA32U4 one knows that the controller have:
- a USB peripheral
- I2C, SPI and USART peripherals
- 1x 8bit timer/counter and 2x 16 bit timer/counter peripherals

When specifying a board such as Leonardo it is known that mcu=atmega32u4, additionally:
- clock runs at 16 MHz
- a user LED is connected to PC7
- controller runs at 5V

With this distinction you could specify -Wpleonardo and simplify the USB configuration code as follows:

Code: Pascal  [Select][+][-]

1. {$if defined(FPC_MCU_ATMEGA32U4)}
2. EPDIR = 0;
3. EPTYPE0 = 6;
4. EPTYPE1 = 7;
5.  
6. USB_ENDPOINTS = 7; // AtMegaxxU4
7. {$endif}