Hi.
We are engineers who bought P2379 (AutoChauffeur) 3 months ago.
This thread deals with what we have struggled with while using P2379 in the last 3 months.
I hope that every engineer who reads this could understand our problem and please not evade the issues presented by responding with repeatingly meaningless answers.
( We really appreciate your previous answers and responses, however once we replied again, there was no continuing exchange of contact )
Our goal is defined as follows:
- Find the number of reliable CAN-buses which are accessible from native Linux application on Tegra-A.
The “reliable CAN-buses”, refers to:
- The reliable CAN-bus is one of the CAN-bus’s attached to the vehicle harness (CAN-1 ~ CAN-6)
- If we use the reliable CAN-bus within an acceptable baud rate, it must not make any observable delay.
The expression, “accessible from native Linux application on Tegra-A”, means:
- We want to receive a CAN Msg that arrived at this CAN-bus on native Linux application on Tegra-A
- We want to send a CAN Msg through this CAN-bus on the native Linux application on Tegra-A
To achieve our goal, we used DsCom following recommendation in EB-DrivePX_Software_User_Guide_DPX2_P2379 (section 5.1.4.1 pp26).
This approach can be summarized as below:
- Configure Rx CAN Msgs at EasyCanConfigFile.conf
- Execute provided binary LINUX_LXTHREADSX86_DrivePxApp.elf
- Execute our native Linux application which accesses (Rx/Tx) to each CAN-bus
By using the above approach we could receive/send CAN Msg from/to each CAN-bus.
However, below problems are observed:
- LINUX_LXTHREADSX86_DrivePxApp.elf buffers received CAN Msg and forward it to our native Linux application.
We could not find any clear buffering criteria (because source of this binary is not given).
When we received a 10msec period CAN Msg on the native Linux application, they arrived at our application in groups of five every 50msec
When we received a 25msec period CAN Msg on the native Linux application, they arrived at our application in groups of two every 50msec …
So, now we are suspecting that LINUX_LXTHREADSX86_DrivePxApp.elf buffers received the CAN Msg’s for 50msec before flushing buffer and sending message along.
- LINUX_LXTHREADSX86_DrivePxApp.elf cannot process consecutive CAN send requests.
When we sent 2 CAN Msgs on the native Linux application we could not send second CAN Msg right after sending the first CAN Msg.
At least 20msec delay between two consecutive CAN Tx is needed.
If we do not make delay between two consecutive CAN Tx, CAN Tx is unpredictably delayed or causes Msg loss.
We’ve already report the above problems to NVIDIA partner in South Korea.
However, they said we should talk with EB after forming a contract with them for their services.
Honestly, we could not understand the above policy.
When we attached 3rd party CAN device which uses SocketCAN, we can easily setup reliable CAN-buses accessible on Tegra-A.
So, I think it is very simple, basic and essential feature because we bought P2379 including vehicle harness.
Where can we get technical support about CAN ?
Thank you.