Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.46%. Comparing base (e0beace) to head (61e694c).
⚠️ Report is 15 commits behind head on master.

@@           Coverage Diff            @@
##           master   #12331    +/-   ##
========================================
  Coverage   98.45%   98.46%            
========================================
  Files         175      176     +1     
  Lines       22646    22784   +138     
========================================
+ Hits        22297    22435   +138     
  Misses        349      349            

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

As mentioned on the linked PR, this work is much appreciated and we're keen to have esp32 CAN driver support. Implementing a common machine.CAN API will take some time, the new plan for this work is in #12337.

@IhorNehrutsa I hope you're keen to keep this PR open and it can be adapted it to the new API once that's available.

esp-idf 5.02
["esp32", "esp32", "1.22.0-preview", "v1.22.0-preview.132.g958c6d917.dirty on 2023-11-08", "with PSRAM"]
Work with some code change.

>>> dev = CAN(0, extframe=False, tx=4, rx=5, mode=CAN.NORMAL, baudrate=500000, auto_restart=False)
>>> dev.recv()
(857, False, False, b'\x00\x00\x00\x00\x03\x00\x00\x00')
>>> dev.recv()
(857, False, False, b'\x00\x00\x00\x00\x03\x00\x00\x00')
>>> dev.recv()
(853, False, False, b'_\x00d\x00')
>>> dev.recv()
(857, False, False, b'\x00\x00\x00\x00\x03\x00\x00\x00')
>>> dev.recv()
(857, False, False, b'\x00\x00\x00\x00\x03\x00\x00\x00')
>>> dev.recv()
(857, False, False, b'\x00\x00\x00\x00\x03\x00\x00\x00')
>>> dev.recv()
(862, False, False, b'hi\x89i\x00\x00  ')
>>> dev.recv()
(857, False, False, b'\x00\x00\x00\x00\x03\x00\x00\x00')

@straga Can you share your code changes? This PR may not be completed so quickly.

@winnie-xzh
I am use user_modules for CAN, draft version, but work for me. Not need more touch micropython core code.
https://github.com/straga/micropython-esp32-twai

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

Hi, I tried to compile this PR to test it, but I can't seem to enable the idf twai component. While building, I get errors indicating that it doesn't recognize the

#include "driver/twai.h"

as seen in this error:

ports/esp32/machine_can.c:82:15: error: implicit declaration of function 'TWAI_TIMING_CONFIG_25KBITS' [-Werror=implicit-function-declaration]
   82 |     .timing = TWAI_TIMING_CONFIG_25KBITS(),
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~

I've already tried to enable it via idf.py menuconfig, but couldn't find the option there.
I'm using idf version 5.2.2

Would be nice if anyone could help me.

I was able to use your branch @IhorNehrutsa , but I had to make some changes to the example code found here:
pyb.CAN or I had misc type expectation errors.

pseudo patch:

buf = bytearray(8)
-lst = [0, 0, 0, 0, memoryview(buf)]
+lst = [0, False, False, memoryview(buf)]
# No heap memory is allocated in the following call
-can.recv(0, lst)
+can.recv(lst)

I tested it today again with an ESP32S3 to get some data about latency. An incremental encoder (24p) with channel A and B is connected to 2 GPIO. I use an IRQ to watch 6 channels and if a rising or falling edge occurs, the Micropython code sends a CAN-Message (500_000 kbit/s) with 1 byte data which is the state of the GPIO.

On the receiver side is a RPi4 with a USB2CAN from inno-maker. It's directly recognized as can0. The receiver code is Python and uses the python-can module to receive the messages.

(the slowest possible combination)

I got a latency of 550 - 650 µs during rotating manually one incremental encoder.
The more data on the bus, the higher the latency is.
To test it, I applied a 2 kHz PWM (50%) signal.
Then the latency went up to 1.2 ms.
Maybe it's faster, if the esp32 supports hard interrupts for Pin.

The signals of the receiver side are inverted.

This will need to be updated to use the new extmod/common machine.CAN interface added in 0225704

Code size report:

Reference:  tools/ci.sh: Increase qemu_arm test run timeout. [5c00edc]
Comparison: port/esp32: Add CAN(TWAI) class. [merge of 61e694c]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32: +13052 +0.748% ESP32_GENERIC[incl +3208(data) +8(bss)]
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

@dpgeorge @projectgus
You may continue. Thanks.

@dpgeorge @projectgus You may continue. Thanks.

No worries, thanks for all the work you put into this.

If I understand, you're asking for someone else to pick up adding machine.CAN for esp32?

@projectgus Yes, sure