collin80/esp32_can

Why does CAN0 have to be declared in the global namespace?

j4m3s opened this issue · 2 comments

j4m3s commented

With the last couple of PRs it's become possible to use your excellent library without needing to fork it to edit esp32_can.h and esp32_can.cpp. Instead, you can now:

#include "esp32_can_builtin.h"
#include "mcp2515.h"  // (or mcp2517fd.h)

as-is, and then instantiate the objects you need ESP32CAN CAN0(rx_pin, tx_pin); and MCP2515 CAN1(cs_pin, int_pin) and configure them with the BAUD rate etc. All good.

...Except, for some reason you MUST declare CAN0 globally, as CAN0. If you don't, it just doesn't work. You can call the external CAN whatever you like and it works fine - but not CAN0. And I just can't figure out why!

I'll happily submit a PR updating the examples if I can just figure out how to fix it so that CAN0 is tidy :) Any ideas what''s going on? A grep of the whole library doesn't show-up CAN0 anywhere, so I'm wondering if it's somewhere deep in the guts of the ESP32 arduino libraries maybe?

j4m3s commented

Actually, the other thing in esp32_can.h is:

extern volatile uint32_t biIntsCounter;
extern volatile uint32_t biReadFrames;

I'm not sure if they're actually required here? I'm not #includeing that file any longer and the internal CAN controller seems to be happily chugging away - possibly because they're also declared in esp32_can_builtin_lowlevel.cpp?

j4m3s commented

Closing this issue. Having rewritten my code I'm not seeing the problem I previously had with CAN0 needing to be declared globally.

For those who arrive later, I'm also not including esp32_can.h, just:

#include <esp32_can_builtin.h>
#include <mcp2517fd.h>
#include <mcp2517fd_regs.h>