GeezerVison is showing github.com — Why rename CAN to TWAI? (IDFGH-3645) · Issue #5580 · espressif/esp-idf
Why rename CAN to TWAI? (IDFGH-3645) #5580DescriptionTWAI(Two-Wire Automotive Interface) is too generic to express CAN(Controller Area Network).
No need to rename a well known term accepted in industry. Reacted by Collin Kidder, Fabian Peddinghaus, Alan C. Assis, Elliot Woods, Yvon DUTAPIS, Ben V. Brown, Fahad, David Robertson, Christoph Rackwitz, Tomas Mudrunka and 19 more Reacted by Brian Horakh and ramiws Activitychanged the title [-]Why rename CAN to TWAI?[/-] [+]Why rename CAN to TWAI? (IDFGH-3645)[/+] on Jul 13, 2020Dazza0 commented on Jul 14, 2020 @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. Reacted by Gordon, Juan Boirazian and ViennaTom keelung-yang commented on Jul 14, 2020 Dazza0 commented on Jul 14, 2020 @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 Reacted by Gordon and Joël Schulz-Andres keelung-yang commented on Jul 15, 2020 @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. Reacted by nathanRamaNoodles, Fabian Peddinghaus, Elliot Woods, Christoph Rackwitz, Chris Ivarsson, rustyx, moritz bust, Gordon, Zach Zodkoy, Alaining and 12 more negativekelvin commented on Jul 15, 2020 The reason is lawyers and intellectual property, do you want to pay more to call it CAN? I don't Reacted by chegewara, nathanRamaNoodles, Yvon DUTAPIS, Brian, Jamie, diverger, glococo, Matthew Kennedy, leeebo, moritz bust and 27 more collin80 commented on Jul 30, 2020 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!
…Reacted by Ignacio Piera, András Szabó, Gordon, EmbeddedDevver, Joël Schulz-Andres, Robert Saramet, Paulo de Almeida, Dansenmansenhansen, Zachtos, zygimantasmik and 2 more negativekelvin commented on Jul 31, 2020 Reacted by Krzysztof, Brian Horakh, Fernando Carneiro, Paul Kahler, Brian, Michael, Christoph Rackwitz, Dan Mezhiborsky, diverger, Bktero and 20 more Reacted by Brian Horakh, Christoph Rackwitz, Dan Mezhiborsky, diverger, pavellzubkov, Alec Thilenius, markko67, Dinacel, Noak Palander and Nikolai Reacted by rustyx and ngzhiyang Reacted by Sukesh Ashok Kumar elasticdotventures commented on Aug 14, 2020 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. Reacted by dennis-soong, Germán Martín, Rajesh Kumbhakar, Anton Engman, rustyx, András Szabó, existedinnettw, EmbeddedDevver, Philipp Huth, Enrico Lumetti and 15 more Reacted by Raphael Pfaller and ViennaTom Reacted by Christoph Rackwitz Reacted by Waheed Barghouthi, Roman Valls Guimera and Germán Martín ppisa commented on Nov 30, 2020 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. Reacted by Dr. Mickey Lauer, Hays Chan, Wei and Sebastian Andersson Reacted by Paul Kahler, Brian, berlin4apk, Zachary J. Fields, leeebo, Sukesh Ashok Kumar, pavellzubkov, Paulo de Almeida, melonedo and Yu Yuan Reacted by Hamza Sengul phkahler commented on Jan 11, 2021 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 commented on Feb 2, 2021 Closing as the question asked in the issue has been answered. timsterathome commented on Mar 24, 2021 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 commented on Oct 3, 2021 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. Reacted by Robert Saramet, MaksM, Paulo de Almeida, melonedo, alex-toybox, Marcin Anforowicz and eccentricOrange negativekelvin commented on Oct 4, 2021 @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 commented on Oct 4, 2021 Reacted by Roman Valls Guimera, Gordon, Dansenmansenhansen, salman farooqui, melonedo, CraigT, alex-toybox and Marcin Anforowicz Reacted by Roman Valls Guimera and Rogério Cassares Dazza0 commented on Oct 11, 2021 @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 commented on Oct 11, 2021 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 commented on Oct 11, 2021 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 [email protected]. kdschlosser commented on Oct 11, 2021 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. Reacted by Sukesh Ashok Kumar, Gordon, Lubos Horacek, Rob, CraigT and trbt tonton81 commented on Feb 13, 2022 so we should be looking for TWAI tranceivers now? :) Reacted by Paulo de Almeida, Rob and alex-toybox gril002 commented on Aug 1, 2022 RufusVS commented on Jan 17, 2023 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"! Reacted by ramiws, Juraj Michálek, Olivier 'reivilibre', Dansenmansenhansen, Michael Taggatz, Dinacel, Colin Catlin, ishyesh, Hays Chan, melonedo and 1 more Reacted by Wei janpub commented on Feb 2, 2024 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.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|