Implement at6561 can trx driver

[firas-hamdi]

Contribution description

Write a driver for the AT6561 CAN transceiver built on the CAN generic transceiver interface can_trx.

Testing procedure

The driver is tested with tests/sys/can_trx application. Hardware used for testing is the same54-xpro devBoard.

[kfessel]

wouldn't a generic can_8pin_transceiver driver be a better option?

I don't know why there is a tja1042-driver in the first place, But this one certainly fits the intention of the tja1042-driver author to keep every can trx driver seperate.

? @vincent-d might know ?

[kfessel]

Suggested change

	gpio_t stby_pin; /**< AT6561 standby pin */
	can_trx_t trx; /**< AT6561 interface */
	can_trx_t trx; /**< AT6561 interface */
	gpio_t stby_pin; /**< AT6561 standby pin */

please swap to keep consistent with the other cantrx_drivers

[firas-hamdi]

I have no problem with swapping them, but I don't like the usage of can_trx_t *trx = &at6561 as other drivers are used in the test app tests/sys/can_trx (I find it very error prone and it limits the freedom to define structure members)

[kfessel]

just swap -- so it won't fail if someone does it like can_trx_t *trx = &at6561 as they might if they looked at the other drivers ( make it more simmilar)

[firas-hamdi]

wouldn't a generic can_8pin_transceiver driver be a better option?

I don't know why there is a tja1042-driver in the first place, But this one certainly fits the intention of the tja1042-driver author to keep every can trx driver seperate.

? @vincent-d might know ?

I agree with that partially. We have already the can_trx as a generic transceiver driver, and we can use pseudo-modules on top of that to define different CAN transceivers.
But maybe the intention is to keep one driver for every CAN transceiver because there are two CAN transceiver drivers implemented separately

[benpicco]

You could have just used tja1042, as far as I can tell it is identical to this driver.

[firas-hamdi]

You could have just used tja1042, as far as I can tell it is identical to this driver.

I could yes, they are identical with the slight difference that at6561 does not provide the silent mode. But as I found different CAN transceiver drivers I though about adding a new one.

[benpicco]

they are identical with the slight difference that at6561 does not provide the silent mode

As far as I can tell tja1042 doesn't provide silent mode either.

[firas-hamdi]

they are identical with the slight difference that at6561 does not provide the silent mode

As far as I can tell tja1042 doesn't provide silent mode either.

You're right indeed. I just checked the driver and saw that the silent mode is same as normal mode configuration-wise.
But still the question: what if someone wants to use the AT6561 and does not catch the TJA1042? It's for this reason that I would prefer to have a driver for AT6561 (that can be extended with AT6560 features), or even better have a generic CAN transceiver with standby pin supporting both transceivers

[benpicco]

We can rename TJA1042 to something more generic.

[kfessel]

@firas-hamdi
drivers/at6561: driver for AT6561 CAN transceiver
fcb97bc
@firas-hamdi
tests/sys/can_trx: add AT6561 CAN transceiver

this is enough to convey all information ( just a tip on how to shorten commit messages) the area of work does not need to be repeated in the description

[firas-hamdi]

We can rename TJA1042 to something more generic.

Should we classify the CAN transceivers according to how many modes they provide and we generate a naming from that?

[kfessel]

We can rename TJA1042 to something more generic.

Should we classify the CAN transceivers according to how many modes they provide and we generate a naming from that?

most can-trx are 8 pin with one control pin the modes that set the pin can be put into a bitmask then set_mode function has just has to check if the bit-mask says it is has that bit set or not

[firas-hamdi]

We can rename TJA1042 to something more generic.

Should we classify the CAN transceivers according to how many modes they provide and we generate a naming from that?

most can-trx are 8 pin with one control pin the modes that set the pin can be put into a bitmask then set_mode function has just has to check if the bit-mask says it is has that bit set or not

There are some CAN transceivers providing two control pins (ncv7356), should these be included too to the generic driver?

[kfessel]

We can rename TJA1042 to something more generic.

Should we classify the CAN transceivers according to how many modes they provide and we generate a naming from that?

most can-trx are 8 pin with one control pin the modes that set the pin can be put into a bitmask then set_mode function has just has to check if the bit-mask says it is has that bit set or not

There are some CAN transceivers providing two control pins (ncv7356), should these be included too to the generic driver?

seems like a secial case (single wire can) that we better might not cover in our generic can-8pin-trx-driver