Comments (10)
After reviewing the standard I understand there is 2 scenarios of padding:
- When TX_DL = 8, all frames should be padded up to 8 bytes. Seems to be inheritance from before CAN FD support
- When TX_DL > 8, therefore CAN FD frames, unused bytes shall be padded.
I agree that the current behaviour of the Python module is not adequate. I think the addition of a tx_min_data_length
parameter is relevant. I will proceed with the implementation shortly
from python-can-isotp.
@pylessard: sorry for the delay. I just checked the implementation and it works as specified and expected. Good work. The issue can be closed now.
from python-can-isotp.
The kernel implementation supports TX_PADDING and also is able to check the received PDUs if they were padded correctly. Do you refer to this functionality?
from python-can-isotp.
Thank you for the fast response. In the Kernel it is used as I was describing it. If I´m using -L option and set the padding to 64 , the CANFD-Frame will always be of a length of 8 byte if the data is < 2 byte.
using this command with tx_dl 64
echo 3e 00 | isotpsend -s 0b1 -d 0b0 vcan0 -L 72:64:0 -p 0x00
the kernel generates this output:
vcan0 0B1 [08] 02 3E 00 00 00 00 00 00
using the same command while sending data >8 byte
echo 3e 00 aa aa aa aa aa aa | isotpsend -s 0b1 -d 0b0 vcan0 -L 72:64:0 -p 0x00
this is the output:
vcan0 0B1 [12] 00 08 3E 00 AA AA AA AA AA AA 00 00
In comparison to the python-can-isotp package:
I´ve used this params:
can_fd: True
tx_padding: 0x00
tx_data_length: 64
and the output is always padded up to 64 byte.
vcan0 0B0 [64] 02 3E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....
The Problem with this setting is that the ECUs will drop this messages if the iso-tp data is only 2 bytes while the can-fd frame is 64.
I´m not sure where this behaviour is specified. Maybe in the specification of ISO-TP for CAN-FD?
from python-can-isotp.
Hi sorry for the late answer,
I can look into fixing this soon. Do you have any reference in the standard that describe this behaviour?
If we don't, I'll make sure to add options supporting every cases.
Thank you
from python-can-isotp.
I just had a look into the specification. It´s not 100% clear but I think padding a CAN-FD frame up to 64 byte if the data is < 48 - PCI bytes is not allowed. Instead it should always just use the appropriate CAN-FD frame length
From the Spec ISO 15765-2 Third Edition 2016-04-01:
10.4.2.3 Mandatory padding of CAN FD frames (TX_DL > 8)
... For DLC values from 9 to 15, only the mandatory padding shall be
used. ...
from python-can-isotp.
This would mean even if you have a padding of 64 byte, the iso-tp layer should decide on which can dlc to use. But a minimum of 8 byte. Do you have access to that specification ?
from python-can-isotp.
AFAIK the padding is used to fill up the "uninitialized" / "unneeded" bytes that are generated by the non-linear length steps introduced by the DLCs in the CAN FD case.
E.g. when you have 26 bytes to be transferred the DLC 0xd is needed which has space for 32 bytes - where the last 6 bytes are to be padded.
And for padding the minimum frame length is at least 8 bytes.
from python-can-isotp.
@CanCanRep : I pushed a fix. The stack now support a new parameter tx_data_min_length
.
Can you validate that the behaviour seems correct to you?
Thanks
from python-can-isotp.
Fixed in v1.6
Thanks
from python-can-isotp.
Related Issues (20)
- How to set stmin when use transfer_data() HOT 7
- TypeError: dataclass() got an unexpected keyword argument 'slots' HOT 5
- Performance on Windows HOT 7
- timed out isotp_socket.recv() HOT 7
- CanStack automatically stopped and program crashed HOT 2
- Able to RX/TX ISO-TP frames using Linux can-utils package but not via Python HOT 3
- AttributeError: 'CanMessage' object has no attribute 'channel' HOT 2
- The Listener can not log can message correctly HOT 3
- Preformance issue of func "specific_wait_frame" HOT 8
- UDS request with BRS enabled and ESI Disables is not working through CanStack request HOT 4
- After receivie NRC0x78, isotp cannot receive the follow-up messages. HOT 12
- still absent support of CAN bus timeouts HOT 2
- Rate limiter still works strange HOT 11
- Custom counter for consecutive frame HOT 6
- Replacing the bytearray data handling with Generator HOT 10
- fails on _socket.send(*args, **kwargs) HOT 14
- No connection via virtual environement HOT 20
- ..
- Comma is missing in IsoTp sockets example HOT 2
- How do I fill in padding byte in Flow Control messages? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-can-isotp.