Esp-idf: Why rename CAN to TWAI? (IDFGH-3645)

[keelung-yang]

TWAI(Two-Wire Automotive Interface) is too generic to express CAN(Controller Area Network).
No need to rename a well known term accepted in industry.

[Dazza0]

@keelung-yang Since the S2 contains a TWAI controller, and future chips will likely contain it as well, the API was changed. However, the CAN API is currently still compatible and will not require any change in your software.

[keelung-yang]

@Dazza0 Ok then, what's the difference between TWAI contoller an CAN controller? I checked ESP32-S2 Technical Reference Manual v0.5 and found nothing.

CAN APIs are marked obsolete on latest master(main) branch now. And no mention when will be removed in latest document

[Dazza0]

@keelung-yang For pretty much all intents and purposes, the TWAI on the S2 is functionally equivalent with the CAN on the ESP32, so you the TWAI API is essentially equivalent to the CAN API. As for when the CAN API will be removed, there are no hard plans as for now, but according to the ESP-IDF versioning scheme, breaking changes are only allowed on major releases. Thus the earliest possible release where the CAN API will be removed will be v5.0

[keelung-yang]

@Dazza0 There still no reason mentioned.
People will confused for reinventing CAN, but no any inventing actually.
Renaming is not reinventing.
CAN should be repected.

[negativekelvin]

The reason is lawyers and intellectual property, do you want to pay more to call it CAN? I don't

[RamPrasanth01]

TWAI(Two-Wire Automotive Interface) is too generic to express CAN(Controller Area Network).
No need to rename a well known term accepted in industry.

Yes. I was confused when I looked at TWAI. I need to implement CAN and I found TWAI. After reading your message, my assumption (that they are trying to generalize) is true.

But I would be really grateful if someone experienced using CAN in ESP32 suggest me a good API. I am using ESP32-EVB-EA. Please find the link of the board below.
https://www.olimex.com/Products/IoT/ESP32/ESP32-EVB/open-source-hardware

Thank you.

[collin80]

Citation needed. I've never seen anyone claim you can't call CAN CAN. The
original ESP32 calls it CAN. It's CAN. There doesn't seem to be any reason
not to call it CAN. In fact, NOBODY ELSE seems to have ever renamed CAN.
Why has Espressif done this? I agree with Keelung that this will do nothing
but confuse absolutely everyone. What a horrible decision!

On Wed, Jul 15, 2020 at 5:23 PM negativekelvin [e-mail]
wrote:

The reason is lawyers and intellectual property, do you want to pay more
to call it CAN? I don't

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/5580#issuecomment-659019686,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQLWZO72PE3R5TMB6FLDF3R3YM5VANCNFSM4OYIEYQA
.

[negativekelvin]

https://en.m.wikipedia.org/wiki/CAN_bus#Licensing

[elasticdotventures]

Additional note - The TWAI controller is not compatible with ISO11898-1 FD Format frames, and will interpret such frames as errors. TWAI is effectively "CAN Classic" not CAN-FD which is what automotive industry & promoters such as STMicroelectronics, Infineon, NXP, Texas Instruments, Kvaser, Bosch, Daimler and GM wouldn't appreciate Espressif referring to their transceiver as "CAN" causing confusion.

Most 'modern' vehicles produced in 2019/2020 will implement the CAN-FD specification.
I just watched the defcon 2020 tesla hacking session and it seems the communication between gas pedal, brakes, and door locks were 100% can-bus controlled! However an ESP32 with TWAI transceiver won't plug into that! (** .. without an SPI or I2C CAN-FD 2.0 transceiver!) ... because "Classic CAN can't" lol.

According to Wikipedia:
CAN FD (Controller Area Network Flexible Data-Rate) is an extension to the original CAN bus protocol that was specified in ISO 11898-1. Developed in 2011 and released in 2012 by Bosch, CAN FD was developed to meet the need to increase the data transfer rate up to 5 times faster and with larger frame /message sizes for use in modern automotive Electronic Control Units (ECU)s. As in the classic CAN, CAN FD protocol is designed to reliably transmit and receive sensor data, control commands and to detect data errors between electronic sensor devices, controllers and microcontrollers.

ISO11898-1 CAN FD shares the physical layer, with the CAN protocol as defined in the BOSCH CAN Specification 2.0 can dynamically switch to different data-rate and with larger or smaller message sizes.

Enhanced features in CAN FD includes the capability to dynamically select and switch to faster or slower data rate, as and when required, and to pack more data within the same CAN frame / message and transport it over the CAN BUS / network in less time. Faster data speed and more data capacity enhancements results in several system operational advantages compared to the classic CAN. Using CAN FD, sensor and control data can be sent and received by the ECU (Electronic Control Unit) software much quicker. Commands issued by the executing ECU software reaches the output controller much faster. CAN FD is typically used in high performance ECUs of modern vehicles. A modern vehicle can have more than 70 ECUs that use CAN FD to exchange information over the CAN Bus when the engine is running or when the vehicle is moving.

[ppisa]

By the way, we can offer open-source, open-hardware CAN FD controller to Espressif http://canbus.pages.fel.cvut.cz/ . It is quite well tested, but it would require significant investment into certification and final round testing before integration. This implementation does not overcome problems of paying fees for these CAN FD patents which has not expired yet. The way to classic TWAI (CAN) is open now, when patents has expired. Problem is that single CAN only controller disrupts all CAN FD communication on the bus. We have modified SJA1000 OpenCores design which is able to detect CAN FD frames and at least ignore them (not cause their breaking). It would worth to extend Espressif TWAI controller to allow enable this feature. We have implemented it ourselves without any prior art consultations during 2017 but it is possible that somebody patented solution which covers used technique. If such claim does not exists or we can prove rearons to invalidate it then even this small enhancement would be really significant step forward for TWAI because it could coexist with CAN FD communication of other devices on the bus and stay in area not covered by BOSCH license.

By the way, we can offer our older CANopen open-source framework project which could be ported and extended for Espressif environment. I would like to test ESP32-C3 due to its RISC-V base. I have knowledge and trust for RTEMS BSP implementation and I would like to use NuttX on the platform. I have worked on GNU/Linux CAN support before SocketCAN and some SocketCAN algorithms and drivers are reuse and attribute our preceeding LinCAN project. I CAN provide knowledge and coordination for QEMU CAN support which I have introduced with my university and GSoC students.

[phkahler]

Just because CAN-FD is on a vehicles does not mean every CAN bus is FD. There are multiple busses on a vehicle. Your OBD-II diagnostic port is probably still regular CAN.