The only problem with SPI you have to face is clocking speed and distance - if the clocking speed is too high then the data coming back from the slave might be too much misaligned to be able to adequately receive it. That's the short story.
So, if you transmit at 128 kbps then the clock is 128 kHz and one symbol of data is approximately 7.8 us. You then have to consider how long it takes for a data to fly down the cable and that is based approximately on 70% of the speed of light.
Light travels 1 metre in 3.33 ns and so 2 metres of cable takes about 10 ns to be received and, when the slave responds, it does so on clock edges that are 10 ns "late" compared to the master's perception of time so, there's another 10 ns to add on to the overal skew of data coming back to the master.
So, 20 ns of skew in a basic clock period of 7.8 us isn't really going to be a problem.
Well your main goal is to keep the MCU (generally all parts) within its operating region.
For that you have to have to guesstimate the current needed for operation, the thermal resistance (which is hard) and the ambient temperature the device will operate in.
The power dissipation figures you find in the datasheet are numbers which will prevent the junction temperature to go out of spec at the given ambient temperature.
So worst case, everything on, 3.6 V running full speed, they give 109 mA. This is 392 mW.
You are limited to 240 mA max through Vdd or Vss. 109 mA end up in the core, leaves 131 mA for the rest.
With modern LEDs I would not drive them with more than 5 mA as indicators, except they are used outside in sunlight.
Driving 10 LEDs with 5 mA and 0.4 V internal drop (table 49) adds another 20 mW to the internal dissipation.
Not sure about the other I/O ports. But lets assume a 450 mW power dissipation.
Table 98 has the thermal resistance for the packages listed. With the worst one you have 46 K/W.
With 450 mW you get a rise of 20 K of the junction temperature over the ambient (ambient of the MCU not the enclosure). That means you basically can have 85 °C inside your enclosure and the MCU would be fine. (84,3 °C to be precise)
Modeling what temperature will result in your enclosure is much harder. You need to know how the heat will transfer from the air to the enclosure and then from enclosure to ambient again - maybe your enclosure gives a number but most don't.
What I usually do is estimate the total power dissipation (add some extra), place a PCB inside the enclosure and solder a part on it which is able to handle the dissipation.
Then measure the ambient temperature, the temperature of the enclosure and the temperature inside the enclosure while powering the device. After some hours the temperatures will have stabilized and you can see what rise above ambient you get. If it's something like 40 K rise of the inside temperature, you can't use your device in temperatures above 45 °C. Because then, the ambient temperature of the MCU would be above 85 °C.
If you want to have some safeguards, you can use the internal temperature sensor of the MCU to shutdown in case of overtemperature.
There are some ICs around which will do the same and probably more accurate if you don't trust the internal sensor.
Best Answer
You should have at least two nodes and a twisted pair with 120 ohm terminations at each end. Identifiers must be unique. Read up on the various formats (11/29 bit) and CAN-FD vs. CAN. I suggest starting with 11 bits. The lower numbered identifier is the higher priority.
Typically when a microcontroller supports CAN it means that the 2nd network layer (data link) is supported by a CAN MAC. Usually you have to supply a transceiver (the physical layer). CAN has (electrically) demanding requirements for maximum voltage tolerance that would typically be incompatible with low-cost monolithic processes that support microcontroller complexity. You can also buy chips with serial interfaces that implement the MAC, which you can connect to almost any microcontroller with (eg.) SPI.
There are various high level protocols that can go above the 2 layers specified by CAN, or for a simple application you can implement your own. CAN messages are essentially broadcast and can be used or discarded by each node- like multicast or broadcast.
A CAN protocol analyzer can be helpful- you can buy them for the value of an hour or two debugging.