toggle quoted messageShow quoted text
I'm afraid I have to respectfully disagree with you.
Many of the peripherals on the SAM family can be assigned to several
pins. Which pins used are a choice on board level, so technically this
socmap.h approach could actually not work for the SPI, UART, USART and
As this pin assignment is controlled by a specific separate peripheral,
like most MCU have except the nordic ones, I would propose to add the
The sam3x actually already has this, and can easily be made compatible
for the rest of the family of atmel sam.
I do agree that have the different possible options for each peripheral
can be published from the soc layer. In the sam series this is already
done through the ASF includes.
I don't mind putting in the effort to make these changes. Especially if
this creates a better consensus between the different soc types.
On 10/03/2018 06:30 PM, Kumar Gala wrote:
So we are trying to have the out of box config of a board to enable a default set of features for that board.
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