Custom board PIO - philosophy

[TimH <Ti...@JTi.uk.com.INVALID>]

Hi all,

My custom board has a number of GPIOs that are related to more generic 
drivers. For example, the CAN implementation uses an arch. CAN driver 
appropriate for the processor, but has custom GPOs associated to 
enable/disable the CAN transceivers, and to enable/disable termination 
resistors.

Is the right/best method to extend the CAN driver with these - but 
perhaps #ifdef them so they only relate to this board (which may end up 
being submitted to the repositiry - haven't decided yet!) - or handle 
them in some other way?

I hope those with lots of experience of Nuttx can offer an opinion?

Thanks,

Tim.

Re: Custom board PIO - philosophy

[TimH <Ti...@JTi.uk.com.INVALID>]

Thanks Alan,

I'd forgotten that there's a board-specific sam_mcan.c file (I'm so 
bogged down creating the correct arch. mcan driver for this processor; 
based on the one for the samv7)!

I will put my custom stuff in there. Obvious now you made me think about 
it :)

On 30/05/2021 11:42, Alan Carvalho de Assis wrote:
> Hi Tim,
>
> Normally an arch CAN driver doesn't have this enable pin or other similar
> GPIO.
>
> But if you plan to do it for your custom driver, it is better to use a
> generic solution, like the CAN TX/RX pins do. Also UART, SPI and I2C uses
> this solution.
>
> Creating an #ifdef for each board inside your driver is not a good/right
> solution.
>
> You can use some GPIO_CANXYZ_EN_PIN in your driver and inside your board
> you #define GPIO_CANXYZ_EN_PIN GPIO_PIN_Px
>
> BR,
>
> Alan
>
> On Sunday, May 30, 2021, TimH <Ti...@jti.uk.com.invalid> wrote:
>
>> Hi all,
>>
>> My custom board has a number of GPIOs that are related to more generic
>> drivers. For example, the CAN implementation uses an arch. CAN driver
>> appropriate for the processor, but has custom GPOs associated to
>> enable/disable the CAN transceivers, and to enable/disable termination
>> resistors.
>>
>> Is the right/best method to extend the CAN driver with these - but perhaps
>> #ifdef them so they only relate to this board (which may end up being
>> submitted to the repositiry - haven't decided yet!) - or handle them in
>> some other way?
>>
>> I hope those with lots of experience of Nuttx can offer an opinion?
>>
>> Thanks,
>>
>> Tim.
>>
>>

-- 
JT Innovations Ltd., Unit 23 Tradecroft Industrial Estate, Wide Street, 
Portland, Dorset, DT5 2LN, UK Company number 7619086 VAT Registration GB 
111 7906 35

Re: Custom board PIO - philosophy

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Tim,

Normally an arch CAN driver doesn't have this enable pin or other similar
GPIO.

But if you plan to do it for your custom driver, it is better to use a
generic solution, like the CAN TX/RX pins do. Also UART, SPI and I2C uses
this solution.

Creating an #ifdef for each board inside your driver is not a good/right
solution.

You can use some GPIO_CANXYZ_EN_PIN in your driver and inside your board
you #define GPIO_CANXYZ_EN_PIN GPIO_PIN_Px

BR,

Alan

On Sunday, May 30, 2021, TimH <Ti...@jti.uk.com.invalid> wrote:

> Hi all,
>
> My custom board has a number of GPIOs that are related to more generic
> drivers. For example, the CAN implementation uses an arch. CAN driver
> appropriate for the processor, but has custom GPOs associated to
> enable/disable the CAN transceivers, and to enable/disable termination
> resistors.
>
> Is the right/best method to extend the CAN driver with these - but perhaps
> #ifdef them so they only relate to this board (which may end up being
> submitted to the repositiry - haven't decided yet!) - or handle them in
> some other way?
>
> I hope those with lots of experience of Nuttx can offer an opinion?
>
> Thanks,
>
> Tim.
>
>