Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rework CAN to use esp-idf functionality #267

Merged
merged 3 commits into from
Feb 15, 2020

Conversation

the0ne
Copy link
Collaborator

@the0ne the0ne commented Apr 10, 2019

only limited testing was posible.
please especially verify that CAN networking still works as expected!

@the0ne
Copy link
Collaborator Author

the0ne commented Jul 16, 2019

This new CAN implementation turns out to work really well.

Is there any test script for testing CAN networking? I got two ESP32-EVB devices with CAN that I could wire together. Anything I need to be aware of with regards to CAN networking?

@jolivepetrus
Copy link
Contributor

@the0ne,

I will focused again on CAN shortly.

@the0ne
Copy link
Collaborator Author

the0ne commented Jul 16, 2019

fantastic - let me know whenever I can help

added cpu.h required for CPU_FIRST_CAN and CPU_LAST_CAN
@@ -65,6 +65,7 @@
#include <sys/mutex.h>

#include <drivers/can.h>
#include <drivers/cpu.h>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now required for CPU_FIRST_CAN and CPU_LAST_CAN

make sure we won't block forever if
* the can-bus is buggy/gone
* resp. the queue is full

does properly to auto-recover once the bus is back
@the0ne
Copy link
Collaborator Author

the0ne commented Jan 3, 2020

after having done quite some testing / using the CAN-bus,
these are the improvements I have implemented.

Comment on lines 149 to 150
can_start(); //make sure can is running
can_initiate_recovery(); //make sure the bus is on
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these calls should not be performed on every send so I have moved them to the error-case only

Comment on lines 157 to 159
can_start(); //make sure can is running
can_initiate_recovery(); //make sure the bus is on

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these calls should not be performed on every send so I have moved them to the error-case only

@jolivepetrus
Copy link
Contributor

Hi Thomas,

I'm working again with CAN on ESP32. Testing this PR with my current CAN nodes HW test, based on PIC18FK MCU doesn't work as expected.

Example code:

-- Attach CAN at 500 Kbps speed
can.attach(can.CAN0, 500000)

-- Send a message
can.send(can.CAN0, 0x200, can.STD, 1, string.pack("B", 0x01))

PIC18FK MCU nodes don't respond to the sended CAN message. May be something related to 500 Kbps?

@jolivepetrus
Copy link
Contributor

Ok, I see the problem.

In current implementation:

https://github.com/whitecatboard/Lua-RTOS-ESP32/wiki/CAN-module

speed is expressed in bits/sec, but in your implementation it's expressed in Kbps.

No problem, I will change the wiki, it's more clear to express speed in Kbps.

Thanks.

@jolivepetrus jolivepetrus reopened this Feb 15, 2020
@jolivepetrus jolivepetrus merged commit 5e3fbfc into whitecatboard:master Feb 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants