Date
1 - 5 of 5
Best pinmux approach for Atmel sam soc (sam4s & same70)
|
Vincent - VLoTech
Hi all,
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. Kind regards, Vincent van der Locht |
|
|
|
Kumar Gala
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. 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. - k |
|
|
|
Jiří Kubias <jiri.kubias@...>
Hi, 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. Best regards, Jiri st 3. 10. 2018 v 17:14 odesílatel Kumar Gala <kumar.gala@...> napsal:
--
=================================================== Ing. Jiri Kubias e-mail: jiri.kubias@... mobile: 775 593 956 =================================================== |
|
|
|
Kumar Gala
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 message
Show 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. - k On Oct 3, 2018, at 10:31 AM, Jiří Kubias <jiri.kubias@...> wrote: |
|
|
|
Vincent - VLoTech
Hi,
toggle quoted message
Show 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 I2C drivers. 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 pinmux driver. 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. Kind regards, Vincent 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. |
|
|