search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.79k stars 7.31k forks source link

Incorrect TWAI macros (IDFGH-5911) #7603

Closed kdschlosser closed 3 years ago

kdschlosser commented 3 years ago

Environment

Problem Description

In the header file components\soc\include\hal\twai_types.h the following macros are defined.

#define TWAI_TIMING_CONFIG_1KBITS()     {.brp = 4000, .tseg_1 = 15, .tseg_2 = 8, .sjw = 3, .triple_sampling = false}
#define TWAI_TIMING_CONFIG_5KBITS()     {.brp = 800, .tseg_1 = 15, .tseg_2 = 8, .sjw = 3, .triple_sampling = false}
#define TWAI_TIMING_CONFIG_10KBITS()    {.brp = 400, .tseg_1 = 15, .tseg_2 = 8, .sjw = 3, .triple_sampling = false}

I believe there is an error in these macros and the tseg_2 field should be a 4 and not an 8. I wrote a script that calculates the brp, tseg1, tseg2 matches all of the rest of the macros in the header file except for these 3. The script returns a 4 for the tseg_2 field. All of the rest of the fields are correct...

If for some reason the 66.6% sample point must stay then the bitrates for TWAI_TIMING_CONFIG_5KBITS and TWAI_TIMING_CONFIG_10KBITS cannot be used as there is no match. I am gathering that an 80% sample point is fine as most other macros are set to an 80% sample point. And if that is the case then a change of the tseg_2 field for each of those would need to be a 4.

I do not have any kind of an example that shows they are incorrect other then the Python script that I wrote to calculate the needed parameters. I have attached the Python script so you can run it and also check if my calculations are correct if you like. I am pretty sure the tseg_2 is incorrect.

can_timing.py.txt

negativekelvin commented 3 years ago

https://github.com/espressif/esp-idf/commit/d604bf05affcbd80e85afde17624bfdec8f0ff9d#diff-0e889d130b589e061b63dc49b8b37ab2df59e0287b8025c1343c7be707297460

kdschlosser commented 3 years ago

Heyyyyy so I wasn't wrong. It was caught earlier so this issue can be closed.

Maybe someone might consider porting the attached script to C code and adding it to esp-idf. It has the values needed to calculate timing registers for a bunch of different interface IC's and it can be added onto really easily.

It makes it a whole lot easier to be able to plug in the bit rate you want along with a tolerance and have it give the timing registers needed to get to that bit rate. I even went to the extent of automatically calculating what the SJW/RJW should be set to using the transceiver processing delay and the bus physical length. It also takes into consideration oscillator differences and how much of a difference that would be tolerated for the provided bit rate, bus length and transceiver delay.

I also added in CIA compliant sample points for those that do not want to deal with them.

It would be a useful tool to have and maybe add it as a separate module/library called twai_tools or some such thing.

Dazza0 commented 3 years ago

@kdschlosser Auto bit timing calculation is in our future road map. So is hot-plugging bit rate detection. But it's planned for v5.0 because both features will require a change to the TWAI driver's API/programming model.

kdschlosser commented 3 years ago

OK cool. I see there is a kind of add-on repository that has been made. Is that functional? is it public, meaning can I write something and have it added to it?

Bit rate detection is also good to have but isn't it slow? I thought the only way to do it is the interface has to be set to listen only and then set the bit rate one at a time and check for errors. That is a time consuming process and you have the issue of how busy the bus is. If it's only a couple of nodes and those nodes don't broadcast then the bit rate detection would fail. If using an S2 there are 16384 prescalars and if 1/4 of those are unique bit rates you are talking 4096 different bit rates. If it was something that was built into the interface it's self that would be the better way to go about doing it.

I don't know how else an automatic bit rate feature could be done.

I am glad I was correct about those macros being wrong. It means my calculations are working correctly. Out of question what is the tolerance of the oscillator on the ESP32's? knowing this would help to select a proper sample point and SJW.

Another really nice feature would be interrupts for when a message gets received and also an interrupt if there is no traffic on the bus at all. The interface on the ESP32 seems to be directed at the automotive market and the modules in the vehicle go to sleep when there is no more data being passed on the bus and it wakes when it sees data again. I am pretty sure the wake and sleep re probably pointing to specific frame id's for this. If I put the ESP32 into deep sleep does the interface also get powered down?.. I see there is a bus-off interrupt, can this be used to put the ESP32 into deep sleep and can it be used to wake the ESP32??

I know I am straying from the issue topic figured it is easier to ask those questions here then to try and get a correct answer from the forum.

Dazza0 commented 3 years ago

@kdschlosser

Bit rate detection is also good to have but isn't it slow? I thought the only way to do it is the interface has to be set to listen only and then set the bit rate one at a time and check for errors.

Yes, it would be slow to scan every single bit rate. The more likely scenario would be to only scan the commonly used bit rates (e.g., 10K, 20K, 25K, 50K, 100K, ... up to 1M).

If it's only a couple of nodes and those nodes don't broadcast then the bit rate detection would fail. Yes that would be true. But it's not uncommon for the network layer protocol (such as CanOpen) to have a Heartbeat/keep-alive message that is transmitted periodically.

I am glad I was correct about those macros being wrong. It means my calculations are working correctly. Out of question what is the tolerance of the oscillator on the ESP32's? knowing this would help to select a proper sample point and SJW.

The peripheral is run off the APB clock which usually operates at 80MHz. I'm not sure about the exact drift tolerance (more details in this thread), but I think its drift be too small to affect the sample point selection. The propagation delay of your bus (i..e, the length) will probably have a much larger effect on sample point selection.

Another really nice feature would be interrupts for when a message gets received and also an interrupt if there is no traffic on the bus at all. The interface on the ESP32 seems to be directed at the automotive market and the modules in the vehicle go to sleep when there is no more data being passed on the bus and it wakes when it sees data again. I am pretty sure the wake and sleep re probably pointing to specific frame id's for this. If I put the ESP32 into deep sleep does the interface also get powered down?

Note that we've also had similar request regarding TWAI power saving (such as https://github.com/espressif/esp-idf/issues/5883).

kdschlosser commented 3 years ago

But if there's a significant ESP chip user base that requires TWAI power saving, we are open to adding some form of TWAI power saving feature to HW/SW.

If the ESP32 wants to really break into the automotive sector having the ability to put the MCU into a deep sleep and have the TWAI interface be in a low power mode but will have the ability to wake the MCU if it sees traffic on the bus would need to be put in place. The MCU's current draw is too high to not be considered parasitic when the vehicle has been powered off.

If you read the data sheet for the MCP25625 interface with integrated transceiver on page 7 under the section Sleep/Standby Mode It specifically states the ability to have the IC in low power mode and that the IC will come out of low power mode if it detects any traffic on the bus.

https://www.mouser.com/datasheet/2/268/MCP25625-CAN-Controller-Data-Sheet-20005282C-708896.pdf

Because of the ESP not having the transceiver built into it may not make it possible to do this. I have not come across a transceiver that will wake from a low power mode if there is bus traffic, I have not specifically looked for one either.

Here is a fantastic example of why this kind of thing is needed. If you take the door lock system in a vehicle made today it is not like the days of old where the switches were directly connected to the actuators. Now there is a single module inside a door and that module controls everything attached inside that door. The power windows, power mirror, any switches like memory seats, window switches and door lock switches. It also controls puddle lights and ambient lighting that may be in the door, it also monitors the door latch switch.

This would make it possible to only have to run 4 wires into the door of a vehicle. 12v, ground, can high and can low. The MCU inside that door must have the ability to sleep and wake based on can traffic because even an ignition/accessory wire is not going to be of help when wanting to unlock the door from the key fob.

That would be an example of an OE application. Now here is one from an aftermarket standpoint.

In order to add an alarm or a remote starter maybe even a new radio an Interface module of some kind is almost always needed. This is because of the design of the vehicles as in the OE example above. If I wanted to add an aftermarket alarm I would have to send a message on the bus to tell the door modules to lock and unlock the doors. That specific function would not need to have the bus wake the device because the pulses from the alarm to lock and unlock the doors can wake the MCU. But if someone opens the door the message that the door is opened gets sent over the bus and unless the MCU can be woken from bus traffic it's not going to know to sound the alarm.

Whats nice about the design of an automotive CAN network is the use of broad casting. If a module is outside of its normal parameters it sends message after message until it's state returns back to norm. So for something like the door being opened the door module is going to keep on sending the same frame over and over again until the door gets closed. Once it does it will send a frame stating the door has been closed and then all will become quiet again on the bus. So the need to capture the frame isn't really that important.

If an aftermarket company that manufacturers interface modules had something like the ESP32 at their disposal and the price point being as low as it is for them they would be able to trim down the cost of manufacturing, provide the ability to update the thing over WiFi (If using a firmware like MicroPython). Using retail pricing of $3.00 for an ESP32-WROVER that in and of it's self makes it a viable option if the ability to have it wake from CAN traffic is available. Now look at this, the cost of an MCP25625 which does have this ability is $2.90 and an MCU is still going to need to be purchased on top of that along with oscillator crystal filtering caps and so on and so forth.

I do not know what the delta T rise of the MCU is when the utilization is 100%. The 125C max operating temp would not be high enough if the MCU was placed inside of a plastic enclosure and the ambient temp is 60C and the MCU has a delta T rise of 40C at 100% utilization. The MCU being inside the enclosure would cause an overheat unless an aluminum enclosure or active cooling is used. A maximum of 150C would be better, I think that 175C is what is considered to be for use in an automotive application I could be wrong tho.

Those are the only 2 things I can see that would not place the ESP32 into the ideal area for automotive use. The price point is perfect to make it really attractive for use. The thing that would stop it from being used by vehicle manufacturers is the inability to write firmware using the CAN bus as the transport system. For aftermarket purposes if the temp specs are in order and the device can be woken by traffic on the bus I can see the device being used a lot. The speed is there, the flash storage is more then ample and there are several options to adjust the amount of ram that is available. There would need to be a person that is familiar with the companies that make automotive electronic accessories that would be able to market it to companies like DEI (Directed Electronics), FirstTech (CompuStar) and AAMP of America (PAC, ISimple and Connects2). Those kinds of companies would no longer need to make an assortment of different interfaces that support different vehicles. A single piece of hardware that can have it's software updated using TTL, WiFi or BlueTeeth to support whatever vehicle it is installed in I would think to be an attractive feature.

The reasoning above pretty much covers the "if there's a significant ESP chip user base that requires TWAI".. There is.. You also have to remember what TWAI means.. Two Wire Automotive Interface, which means by default it cannot have a parasitic draw and must be able to wake via CAN bus traffic.

Good way to pitch the change to the people that would make the decision. Even if it raises the retail price to 4.00 It is still cheaper then buying an MCU, separate interface w/transceiver, oscillator and all the rest of the bits and pieces that go with it.

The retail price for a large portion of the aftermarket interfaces is north of $150.00 and with a retail price that high and the manufacturer selling direct to the retail store there is no middle man making the price up. There has to be quite a bit of circuitry inside of them. being able to replace a large portion of the circuitry with a single piece and for a cheaper price I would think would be attractive.

Correct me if I am wrong here. I believe the ESP3 has enough processing ability to deal with audio, like microphones and such yes?. Does it have the ability to connect to a phone's bluetooth? sure does. Would it have the ability to send audio captured from an attached microphone to the phone? would it have the ability to receive audio from the phone and spit it out a couple of GPIO pins? If the answer is yes then these things can be used with minimal added circuitry as a bluetooth integration module for quite a lot of vehicles made. Phone book information and things of that nature are sent over a CAN bus connection to the radio, when an incoming call is to be made or answered the radio changes its input to where the GPIO pins would be connected to. The low level signal for audio is 1 - 4 volts max (typ) so a 3.3v output from the ESP is ideal. I would have to look up what the current is and the ESP might have that available for the GPIO pins.

I can think of a plethora of automotive applications and I can build working examples.

Here is a working example. ESP32 powered horizon active and curve active dual HID retrofit. This is a prototype/roof of concept and I just finished up designing the PCB.

The ESP32 is connected to a 9 axis MEMS sensorand does all of the fusion math to get the pitch and roll. It is connected to the cars CAN bus and requests the steering angle from the stability control system (EBCM) in the car. It monitors the parking, high beam, low beam and turn signal wires in the car. It is connected to 2 RGBW addressable LED strips for parking lights, turn signal and daytime running lights. It is connected to a PWM IC that sets the position of 4 different servos and those servos are attached to the projectors and bulbs.

IMG_20210514_114625

IMG_20210514_114637

kdschlosser commented 3 years ago

OK the issue you linked to has someone reply to a comment I made and that caused me to do some research. The MCP2562 has the ability to wake the MCU. YAY!!!!!

I will give more information on how to do this once I mess about with it.

Dazza0 commented 3 years ago

@kdschlosser Thank you for your suggestions. We don't get a lot of customer feedback regarding the automotive/industrial use cases of the ESP32 chips, so your feedback is quite valuable. I think the best course of action you can currently take is to submit a feature request via Espressif's official channels since this is no longer a purely SW consideration.

The more detailed your request can be, the better it will be for us to understand your requirements w.r.t to the new feature. We can't guarantee a new HW/SW feature will be added. But to maximize your chances, here are some things to consider when presenting your feature request.

You can also consider posting on the ESP32 Forum regarding Automotive/Industrial related feature requests. I would be interested to see what the rest of the ESP32 community can think of.

I'm closing this issue as we've gone quite far from the original SW issue.

kdschlosser commented 3 years ago

We have migrated off topic somewhat, the conversation was quite constructive tho. I will open up a topic in the forum to open a dialog with other people and see what they come up with for ideas.