An Open-Source platform to create digital devices and interactive objects that sense and control physical devices.
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.
Did a lot more testing to figure out why I can't receive CAN traffic on the MKR hardware.
Did loopback testing on both CAN devices, where the CAN controller talks to itself, both the MKR and my other dev board passed that.
For the MKR this involved using the ACAN2515 library, I was hoping that would fix the issues.
I also added error reporting code to everything I'm using to figure out what is happening, also reduced the CAN speed to 125kHz.
Despite the MKR board running a modified the ACAN2515 example, which sends the string "ABCDEFGH" with a random ID, the microcontroller on the other end gets a 0 byte length message with the random ID.
In the other direction the MKR never receives messages.
Tests with the multimeter show 0V between CAN_H and CAN_L when both boards are either off, or in reset mode, but between 1V and 2V when transmitting.
Yes despite the claims you cannot measure CAN activity without a scope, you actually can to a very limited extent.
Went looking for examples using ACAN2515 as the examples are very limited and only show certain features.
It was then I found the problem.
NO ONE USES ACAN2515 in their projects, zero search results from google that aren't the github examples.
Same for the CAN library also in the Arduino software environment.
What everyone is using is the library MCP_CAN by SeeedStudio
A improved/fixed version of which can be found here https://github.com/coryjfowler/MCP2515_lib
It's at this point I leave this mess to someone else, spent way too much time on this already.
Someone else can try out MCP215 lib to see if it works with the MCP hardware.
Oh and I cannot use a lithium cell to power the LCD, as it needs 5V and that isn't available when using the battery only.
However a 3.3V LCD isn't a solution as the CAN shield also needs 5V.
The software (and firmware) for the MKR Wifi 1010 and MKR CAN shield needs a lot more polishing and testing.
Several times the process of programming the device resulted in it vanishing or malfunctioning as a USB device.
Thus requiring unplugging the USB cable and sometimes the CAN shield to get it into a state which it would boot enough to be reprogrammed correctly.
The CAN libraries come with pitiful examples, which aren't complete enough to use in practical projects where errors and the process of getting data in and out of packets matter.
PCB on the MKR CAN shield needs some minor revision.
The top writing to label the CAN/power connections on the PCB is too small, and partially covered by the terminal block.
On the board I have, its clearly an earlier version where the text is even less clear, and also contradicts if you compare top and bottom.