So we are trying to have the out of box config of a board to enable a default set of features for that board.
toggle quoted messageShow quoted text
I see now what was done on the other Atmel SAM platforms. So defining the pins in socmap.h makes sense and than having the driver have a pin_list and call soc_gpio_list_configure() is what we should do for now.
There’s a fair amount of inconsistency between SoC & board ports in this area. It needs cleaning up, but for now we should keep with the pattern used for other SAM devices.
On Oct 3, 2018, at 10:31 AM, Jiří Kubias <jiri.kubias@...> wrote:
isn't better to put the pin config into the arch/.../soc_pinmap.h and then the user app is responsible for proper pin setup. As the same board can be used in various way (typically dev boards) and some MCU can map peripheral pin function to varios pins so the soc_pinmap.h should contain all configuration variables and user have to select the correct one for his board.
st 3. 10. 2018 v 17:14 odesílatel Kumar Gala <kumar.gala@...> napsal:
On Oct 3, 2018, at 6:15 AM, Vincent - VLoTech <vincent@...> wrote:I’d avoid device tree for right now, it is were we want to be, but requires a bunch of other work we are making progress on.
I'm currently extending the support for the sam4s and same70, by adding the SPI driver for it.
To create / extend a board which actually uses the SPI bus, I noticed there several different approaches to handle the pinmux.
1) device tree spec at board level assigning peripheral pins.
2) pinmux.c file using pinmux interface
3) pinmux.c file useing pinmux device interface
What is the preferred way, or better said, what is the design pattern to apply for now and in the near future.
Looking forward to your insights.
Vincent van der Locht
So we should have a pinmux driver that sets pins, and than we have board level pin settings. You can look at boards/arm/frdm_k64f/pinmux.c and drivers/pinmux/pinmux_mcux.c for an example/pattern to use.
Ing. Jiri Kubias
mobile: 775 593 956