×
Welcome to the Kunena forum!
Tell us and our members who you are, what you like and why you became a member of this site.
We welcome all new members and hope to see you around a lot!
Tell us and our members who you are, what you like and why you became a member of this site.
We welcome all new members and hope to see you around a lot!
can_due vs esp32_can when sending?
- lordryck
-
Topic Author
- Offline
- New Member
-
Less
More
- Posts: 2
- Thank you received: 0
4 years 3 months ago #303
by lordryck
can_due vs esp32_can when sending? was created by lordryck
This is my first time here so I'll put it in the Welcome Mat category. My name is Rick and I have an electric Ford Ranger. I'm working on improving my instrumentation so I bought an ISAScale CAN bus shunt from EVTV. I've been using the CANDue for a while but for this project I picked up a couple of the ESP32 CANdue boards. I've been adapting Jack's ISP library to work with the ESP32 and I've run into a bizarre problem.
The base issue is that commands I send to the ISAScale are being ignored. I set up the ISAScale, one ESP32 as my controller and a second running GEVRET. Two computers--one running SavvyCAN and the second monitoring my controller. The data from the ISA is being read by my controller and the values seem to be accurate. That data is also seen in SavvyCAN. When I send a packet, however, the data portion is getting garbled. The ID comes out right but where I sent 43 01 00 00 00 00 00 00 I might get something like FF 02 DD DD 00 00 20 00. I don't think it's the wiring because a packet sent from SavvyCAN goes and the ISA responds properly.
I thought maybe I had a bad port but I tried both of them with the same result.
So I just swapped in a CANDue board and it works fine. That leads me to wonder if there's some fundamental different between can_due and esp32_can that I don't know about. I'm sending the packet with this:
outframe.id = 0x411; // Set our transmission address ID
outframe.length = 8; // Data payload 8 bytes
outframe.extended = 0; // Extended addresses 0=11-bit1=29bit
outframe.rtr=1; //No request
outframe.data.uint8[0]=0x43;
outframe.data.uint8[1]=0x01;
outframe.data.uint8[2]=0x00;
outframe.data.uint8[3]=0x00;
outframe.data.uint8[4]=0x00;
outframe.data.uint8[5]=0x00;
outframe.data.uint8[6]=0x00;
outframe.data.uint8[7]=0x00;
canPort->sendFrame(outframe);
One tweak I had to make in Jack's module: He declared "CANRaw * canPort" but CANRaw doesn't exist in esp32_due so I switched it to "CAN_COMMON* canPort". I'm not sure it's related but just thought I'd point it out.
Any thoughts? Thanks.
--Rick
The base issue is that commands I send to the ISAScale are being ignored. I set up the ISAScale, one ESP32 as my controller and a second running GEVRET. Two computers--one running SavvyCAN and the second monitoring my controller. The data from the ISA is being read by my controller and the values seem to be accurate. That data is also seen in SavvyCAN. When I send a packet, however, the data portion is getting garbled. The ID comes out right but where I sent 43 01 00 00 00 00 00 00 I might get something like FF 02 DD DD 00 00 20 00. I don't think it's the wiring because a packet sent from SavvyCAN goes and the ISA responds properly.
I thought maybe I had a bad port but I tried both of them with the same result.
So I just swapped in a CANDue board and it works fine. That leads me to wonder if there's some fundamental different between can_due and esp32_can that I don't know about. I'm sending the packet with this:
outframe.id = 0x411; // Set our transmission address ID
outframe.length = 8; // Data payload 8 bytes
outframe.extended = 0; // Extended addresses 0=11-bit1=29bit
outframe.rtr=1; //No request
outframe.data.uint8[0]=0x43;
outframe.data.uint8[1]=0x01;
outframe.data.uint8[2]=0x00;
outframe.data.uint8[3]=0x00;
outframe.data.uint8[4]=0x00;
outframe.data.uint8[5]=0x00;
outframe.data.uint8[6]=0x00;
outframe.data.uint8[7]=0x00;
canPort->sendFrame(outframe);
One tweak I had to make in Jack's module: He declared "CANRaw * canPort" but CANRaw doesn't exist in esp32_due so I switched it to "CAN_COMMON* canPort". I'm not sure it's related but just thought I'd point it out.
Any thoughts? Thanks.
--Rick
Please Log in or Create an account to join the conversation.
- collink
-
- Offline
- Administrator
-
Less
More
- Posts: 60
- Thank you received: 12
4 years 3 months ago #304
by collink
Replied by collink on topic can_due vs esp32_can when sending?
Welcome!
You're not crazy.
First of all, you're right, on esp32_can you should use CAN_COMMON instead of CANRaw in order to generically support different CAN ports. In fact, with up to date due_can you can use this same techique - CAN_COMMON exists in due_can now too. So, that's the most platform agnostic and generic way to go about it. Jack's code is just older than when that change happened so it still retains use of CANRaw. Don't use CANRaw anymore.
Now, the other problem is easy to explain too. outframe.rtr=1 is WRONG. Jack was confused about that one for a while too. Setting RTR to 1 means to send a remote request frame. These have no data payload themselves and actually request that the other side send a frame with the given length back to the originating node. You want rtr=0. Now, why does this work on due_can? Because I hate RTR frames and on due_can I just plain ignore the rtr field. Apparently esp32_can actually pays attention to it and thus you are likely getting an RTR frame. This seems to suggest that SavvyCAN doesn't support RTR frames either and it is also misinterpreting the frame. Really, I don't like RTR frames at all. They've been deprecated for a while now and very few things use RTR. Anyway, to cut this long story off, just set outframe.rtr=0; and things will probably be better.
You're not crazy.
First of all, you're right, on esp32_can you should use CAN_COMMON instead of CANRaw in order to generically support different CAN ports. In fact, with up to date due_can you can use this same techique - CAN_COMMON exists in due_can now too. So, that's the most platform agnostic and generic way to go about it. Jack's code is just older than when that change happened so it still retains use of CANRaw. Don't use CANRaw anymore.
Now, the other problem is easy to explain too. outframe.rtr=1 is WRONG. Jack was confused about that one for a while too. Setting RTR to 1 means to send a remote request frame. These have no data payload themselves and actually request that the other side send a frame with the given length back to the originating node. You want rtr=0. Now, why does this work on due_can? Because I hate RTR frames and on due_can I just plain ignore the rtr field. Apparently esp32_can actually pays attention to it and thus you are likely getting an RTR frame. This seems to suggest that SavvyCAN doesn't support RTR frames either and it is also misinterpreting the frame. Really, I don't like RTR frames at all. They've been deprecated for a while now and very few things use RTR. Anyway, to cut this long story off, just set outframe.rtr=0; and things will probably be better.
The following user(s) said Thank You: lordryck
Please Log in or Create an account to join the conversation.
- lordryck
-
- Offline
- New Member
-
Less
More
- Posts: 2
- Thank you received: 0
4 years 3 months ago #305
by lordryck
Replied by lordryck on topic can_due vs esp32_can when sending?
Bingo! Thanks so much.
BTW, the ESP32 CANDue doesn't seem to have reverse polarity protection on the power inputs. Stupid me found out the hard way. It still works via USB power so that one will stay on my test bench.
BTW, the ESP32 CANDue doesn't seem to have reverse polarity protection on the power inputs. Stupid me found out the hard way. It still works via USB power so that one will stay on my test bench.
Please Log in or Create an account to join the conversation.
Time to create page: 0.054 seconds
- You are here:
-
Home
-
Forum
-
Main Forum
-
Welcome Mat
- can_due vs esp32_can when sending?