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

[ghost]

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 notifications@github.com 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.

[projectgus]

Closing as the question asked in the issue has been answered.

[timsterathome]

If it’s a J1939 based system then it’s standard CAN. I’ve never come across a CAN-FD device on any vehicle I’ve come across.

[kdschlosser]

I am not a lawyer and this is not legal advise in any way shape or form. This is for informational purposes and should be used to question the lawyers. I have not dug into the copyright or trademarks and this is what I am seeing from doing a brief look over of what is available on Bosch's website.

1: TWAI (Two Wire Automotive Interface) as a name doesn't not correctly define the physical characteristics of the type of communications network it can be attached to. GM uses a data interface called SWCAN (Single Wire Controller Area Network), this is a low speed network that utilizes the CAN 1.0 specification and Expressif's TWAI does work with it. That is a naming convention conflict.

2: Changing the name from CAN to TWAI doesn't change copyright infringement, If I copyright what an orange is and does and also the name "orange" and you decided to sell a repackaged version of it and call it an apple does that make it any less an orange? No it doesn't.

Bosh has copyrighted the protocol specification along with the name "CAN". so the end game is there is still an issue either way.

3: Now Bosch has made a blunder I will let you in on. http://www.bosch-semiconductors.com/ip-modules/can-ip-modules/can-protocol/ Look at the location as shown on the webpage where you purchase the license.

"In-vehicle communication IP".

Expressif has no knowledge of where their products are being used, could be used in-vehicle or it could be used for comtrolling someone's home automation which places it outside of a vehicle. This then puts the burden of licensing onto the user or company that is using Expressif's products depending on the intended use of it.

4: By changing the name to TWAI (Two Wire "Automotive" Interface) implies that the intended use of the interface is In-vehicle. Expressif has set themselves up as an easy target for a lawsuit by changing the name to TWAI, where as with it being named CAN it's intended use could be argued.

5: You also have this possible scenario. I do not know what the internal workings of the ESP32 are. Did Expressif reinvent the wheel and design their own interface from the ground up? Or did they buy the technology from say Microchips and build it into the ESP32. If the latter was done then they would be covered under the license (if one has been purchased) the company that built the interface should be holding. If it is a ground up build then Expressif is going to have to purchase a license unless the intended use of the interface can be argued at which time it would then be placed on the company/individual that has purchased the product depending on what the company/individual is using it for.

[negativekelvin]

@kdschlosser An original compatible implementation that is not derived from any of Bosch's copyright IP would only be covered by patents, but they have expired. The name is covered by trademark. I am not sure what kind of dystopia you are living in where you can "copyright what an orange is and does"... well I guess we were there for a while with gene patents.

[kdschlosser]

@negativekelvin

As of July 21st of 2020 CAN is no longer trademarked. https://tsdr.uspto.gov/documentviewer?caseId=sn79086293&docId=MP120210130054511#docIndex=0&page=1

It is marked as abandoned. If the patents have expired then there is no need to call the interface TWAI and it can be reverted back to CAN.

[Dazza0]

@kdschlosser Patent protects implementation of the protocol (CAN2.0) expired a while back (note FD patent is still in effect). The Trademark has recently expired but can be renewed by Bosch at their discretion (unless your suggesting the Espressif does a defensive registration the CAN trademark). Furthermore, TWAI as already be defensively registered to Espressif.

[kdschlosser]

no they cannot renew the trademark registration.

Please note that the application is NOT eligible for revival pursuant to 37 C.F.R. §2.66.

[igrr]

IIRC there was also this one, valid until 08/07/2029.

@kdschlosser I appreciate your attempts to make sense of the situation and your valuable comments. While I'm not deeply familiar with all the details of the legal issues involved, all the points you have made so far have been considered by our legal team. If you have and additional feedback for them, the best way would be to reach them directly via support@espressif.com.

[kdschlosser]

I personally do not care what it is called, it can be called "some type of communications" for all I care. I am pointing out the fact that any patents and trademarks to CAN, CAN 1.0 and CAN 2.0 have expired and there is no legal ramifications for using "CAN". That being said, the decision to change to "TWAI" probably took place before the trademark expired and I can understand why the decision was made. There is no reason to remove the use of "CAN" moving forward. I know it has been deprecated and is slated for removal at some point. From a legal standpoint it's actual removal no longer needs to be carried out. That is a decision that Expressif will make. I just wanted to pass along the information.

[tonton81]

so we should be looking for TWAI tranceivers now? :)

[gril002]

Sorry to be the bearer of bad news, but is seems the CAN trademark is not exactly expired. While the trademark seems to be no longer valid for most of the world, it seems to be still valid in Switzerland, Korea, Russia and Ukraine see: https://www3.wipo.int/madrid/monitor/en/showData.jsp?ID=ROM.1048262 . And on top of that the whole EU see: https://euipo.europa.eu/eSearch/#details/trademarks/008516817 . But I'm not a lawyer so that's at least from what I understand. And Bosch still offers to license you the trademark for a fee see: https://www.bosch-semiconductors.com/ip-modules/can-protocol-license/ - "Product benefits: The right to use the CAN trademark...". This of course still prevents anyone that wants to sell their products in those areas unable to use the CAN trademark.

[RufusVS]

When I try search for "can" I get way too many search hits that aren't relevant. I look forward to when the search term is "twai" rather than "can"!

[janpub]

Please note a difference between "trademark", "intellectual property", "patent", "trade secret" etc. Under EU laws a protocol, documentation and other similar artifacts can be protected as intellectual property (much like music or computer software), however "interfaces" are not protected - so protocol compatible original implementations should be allowed.