Work in progress, semi daily blog, will post something more detailed later.
Using the CANReceiver sketch that comes with the CAN library.
Started off with the CAN shield fitted, power from USB, no other CAN devices fitted.
As it is, appears to be no signs on life in my serial terminal program, I'm using HandiTerm.
Modified the example CANReceiver sketch to do figure out what was going on.
Started by adding a touch of blink LED code to loop()
This proved the code is running, it's just the serial port messages at start up don't appear.
The missing messages are sent in the time when Windows is setting up the USB link.
Should have tried adding a delay loop to see if that helped.
So after further messing around I made is so the initial status messages were shifted to loop.
CAN.begin only fails if you don't have the CANshield connected at all, the actual link doesn't get tested in this example.
The code will wait a thousand years for a message to come from another CAN device.
Found a few traps where the code will stop, both of which make debugging annoying.
1. while (!Serial); Yeah, some of us would like to test it off battery power only.
2. while (1); in the CAN.begin code Only annoying due to initial serial messages being lost.
That second one is there for a reason though, you get a lot of phantom data without it.
Oh and I did find a cable with the correct connector for the LiPo battery terminal.
It's now got a single 18650 battery and colour coded connector via my sharpie collection.
Further experimenting, gotten the MKR to send and receive CAN traffic, I think.
Strongly suspect the other device with CANbus I'm using has configuration problems.
Going to try using the MKR to transmit, and the other micro to receive.
Tried to get my 16x1 LCD working, as it's got to be easier than the issues I'm having with CAN.
Nope, it won't cooperate either, was about to give up when I noticed some of the Pins I was using are also Interupt inputs, low and behold the CAN shield uses GPIO7 as INT, and I'd forgotten to write that down.
Long story short, GPIO assignments for the LCD are:
GPIO0 D4 (LCD)
GPIO1 D5 (LCD)
GPIO2 D6 (LCD)
GPIO5 D7 (LCD)
GPIO13 EN (LCD)
GPIO14 RS (LCD)
Everything else is either taken by the CAN shield, the onboard LED, or something I'd like to leave free.
Every single generic GPIO port is now used, leaving the I2C bus and all 6 ADC capable inputs free for other projects.
A few issues remain with this display, it's actually 16x1 but behaves as 8x2.
Was no way to tell this until I powered it up, I've got other displays but this is the only backlit one.
Also not figured out the correct offset for text to appear in the last 8 characters.
More to come.