Closed Copper-Bot closed 1 year ago
First, board pin definitions should not be mixed with driver pin definitions: a board may have a P1_CAN_RX
pin, but the driver should not specify a pin, only indicate what type of pin should be connected. The driver should use internally a name defined by the lib.
This driver/lib configuration should preferably be declared in the lib configuration file and set in the app configuration file.
You can see a example here: https://github.com/ARMmbed/mbed-os/blob/master/connectivity/drivers/802.15.4_RF/atmel-rf-driver/mbed_lib.json
Now, for the examples. If an example uses the P1_CAN_RX
pin, it should be fully functional on all Zest_Core boards, as long as the Zest daughter board is connected on the P1 port. If an example wants to add compatibility to all Zest_Core board formats, it should declare a pin name that should then be affected to a specific pin depending on the target, in the app configuration file.
All those mechanisms are part of Mbed OS build system configuration. What should be done, if not already, is to specify the pin naming for all ZestCore boards with the `P1` prefix as defined when the Zest_Core_STM32H753ZI board was developed.
I think the pinname is correctly defined for this target, I close this issue.
It may be incorrect on other Zest_Core targets, though.
If a user is creating a program on a full-size board, it can't run it on a half-size board, because
P1_xxx
pins do not exist.Additionally, a 6TRON driver example can't be run on a full-size board because classic 6TRON bus pin names do not exist.
Has this subject already been discussed? Because one simple solution could be to add definition of half-size pins to redirect on P1 bus.
like
CAN1_RX = P1_CAN_RX ,
inPinName.h
.This issue is linked to https://github.com/catie-aq/6tron_www/issues/31