How to apply v1.16.patch ? about canhack

[kentindell]

I've brought everything up to date to 1.18 now, and will be pushing it soon (tomorrow if I get the time). It's now been simplified enough to not need a patch: there's a folder of new stuff, and folder of stuff to copy over the top of 1.18 ports/rp2 and then it's good to make.

[kentindell]

I've updated everything to v1.18 of MicroPython and changed the way it's patched: no more patch files. It's staged on another branch:

micropython_v1_18

@Miki-AG - can you try it out against a clean MicroPython upstream and check that everything builds and that I haven't left any files out? If you give the OK I'll merge this into the master branch.

[Miki-AG]

@kentindell Yes, the new version builds just fine:

git clone -b master https://github.com/micropython/micropython.git
cd micropython
git checkout v1.18
git submodule update --init -- lib/pico-sdk lib/tinyusb lib/axtls
cp -a ../canis-patches/v1.18/canis/ ./ports/rp2/
cp -a ../canis-patches/v1.18/overwrite/ ./ports/rp2/
make -C mpy-cross
cd ports/rp2
make submodules
make

Just one thing I did differently, I only initialized the 3 submodules I need, pico-sdk, tinyusb, axtls, does your patch require any other module than the pico-sdk?

Building all of them is rather time consuming, so you prob can get away with a lighter build.

Best

[kentindell]

Good point: that's probably sufficient. I'll make a note in the README.

[Miki-AG]

Awesome work BTW. Have you considered publishing a driver under micropython/drivers?

[kentindell]

I would like to get some stuff into the upstream MicroPython build: MIN and indeed the CAN driver.

The MIN should be fairly straightforward. There's an issue with the second USB serial port that's a future TODO for MicroPython (I'll dump mine as soon as they sort it). The problem for the upstream is that the serial ports share a ring buffer with REPL and it's a mess (they get each others data). That's not a problem for MIN because it's driven from the REPL command line (from main.py, typically). I have no doubt they will sort the second USB port issue because it's a hugely useful thing to do.

The CAN driver is an issue too: the upstream CAN support is a bit weak (they've only just changed it from having "Extended" a property of the controller to having it a property of the frame). And the driver here embodies a certain approach to CAN, which doesn't fit with the upstream CAN view. The CANPico view of CAN is the bottom layer of CAN concepts that are common in industry (e.g. J1939, OBD-II). To move it upstream would require an overhaul of the whole CAN approach, which I don't think anyone is ready for yet, not least because it would require getting all the other drivers into the same framework. This is quite a lot of work, since the drivers must be free of priority inversion but it's something commonly messed up with CAN. The Zephyr project re-wrote all their CAN drivers after I reported the priority inversion problem to them but it was quite a few and took quite some effort.

[Miki-AG]

Understood, thanks.

[Miki-AG]

I made a mistake this morning while copying some files and the build was actually being completed without applying part of the patch. Seems that the build misses common.h, which is not included in the patch.

[kentindell]

Fixed. 12dc3c9