-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pin management, MODULEs and BOARDs #2395
Comments
Why is it important to have an ESP_VARIANT ? |
With Arduino you just pick the development board being used and it has all the appropriate settings defined somewhere, Note that I forgot to include above the MODULE level between SOC and BOARD which also needs consideration, I agree that projects should not care about all this, and should instead specify the BOARD to be used.
I'm not going to attempt a module or board list because those would be massive. So yes, you make a good point in that the application should only be concerned with the SOC being used, |
Yes. Only chip ARCH, which is significant for the code produced by the compiler/linker. PSRAM is a peripheral and it is up to the programmer to find out what kind of peripherals the board/module supports. Boards/modules are nice to have aggregations that can tell the use which ARCH is being used and can make the framework more accessible for beginners. |
Not just beginners actually. It should help with maintainability for both the framework and user projects. At present, if I build the Another more real-world example is developing and testing an SPI Graphics library against multiple boards. There are a lot more pins to connect there. So the problem is one of documentation, and avoiding having the same information in multiple places. What I'd like is to be able to run |
General option editing now seems to be satisfied using Kconfig, but managing pin assignments needs some special consideration so I've opened a new issue to discuss.
Other than Host, Sming currently supports three different architectures with a total of five variants:
Note: To clarify,
SMING_ARCH
determines the SDK and core platform (the family) whilstESP_VARIANT
identifies which chip within the family.Additional note: Using
ESP_VARIANT
is probably going to get confusing, should change it perhaps toCHIP_VARIANT
orSOC_VARIANT
.Each pin can be configured to various functions and with various restrictions.
As an example, in the ESP32 UART driver we have this definition block at the top:
Horrible. And there is no way to communicate that information to the user other than inspecting the source code.
Duplicating the same information in a README is a maintainability nightmare.
So we need a set of core definitions which the framework code can use to ensure consistent behaviour and to assist the user in project development.
Goal 1: Device layouts
For each arch/variant, create a file mapping pin numbers with available functions.
Each pin should have a default setting which the framework will honour.
The definition can also be used to provide a definitive list of available peripherals (such as the number of UARTs or SPI controllers).
UPDATE: Goal 2a MODULE definitions
Goal 2: Board definitions
Various development boards or modules will expose pins in a different way.
A board definition should identify default pins and their function (including
NOT AVAILABLE
).Note that the board definition will contain additional information, such as the architecture and variant used.
This implies that setting the BOARD will replace use of SMING_ARCH and ESP_VARIANT.
(We may be able to import Arduino board definitions here.)
Goal 3: User definitions
A project will define the board being used (including
CUSTOM
).There should be a consistent way to label up a project to keep track of which pins are used for what purpose.
The build system can then run sanity checks against the selected board at build time.
One thing to consider here is where a pin is multiplexed for different functions at runtime,
such as GPIO connected to an FPGA. These might be marked as
CUSTOM
.IMPORTANT: This will not change peripheral defaults.
A header file can be generated from these definitions for the project to use, for example by using them
in device constructor calls.
Goal 4: Tools
Provide the user with tools to manage all this:
Implementation notes
Source data should probably be JSON as it is structured, fairly easy to edit and more flexible.
Kconfig is a good candidate for editing user configurations, but not as a source data format.
More likely then is to use some python to generate Kconfig files then we can use menuconfig for the editing.
The text was updated successfully, but these errors were encountered: