In principle you should be able to multiplex MCU CAN signal lines, prior to their being used to interface to a CAN physical layer transceiver, using something like a 74HC4052.
In practice, I'd suggest that it's not a very good idea to do so. The problem is that multiplexing would mean that you are guaranteed to periodically miss transmissions from each of the buses.
If you can't tolerate regularly missing traffic on either/both buses, then you'd be better off using an external CAN peripheral; an example would be the MCP25625, which has a CAN link layer and PHY and is controlled via SPI. Adding this to your existing MCU + CAN PHY would allow you to simultaneously and separately interact with both CAN buses, with little if any risk of missing any traffic on either.
First of all the basic CAN transfer mechanism is:
Any node can initiate a transfer.
If a node wants to transmit and the bus is busy it waits until the end of the current packet.
If two nodes start to transmit at the same time then the message with the lower ID will take priority, the message with the higher ID will abort, wait until the bus is idle and then try again.
Most nodes will be configured to generate an ACK pulse at the end of every valid packet they receive. This doesn't mean that they will do anything with the packet, just that they read a valid packet and checksum. Multiple nodes can all generate an ACK for the same packet without any issues (normally every device on the bus will). If the transmitter doesn't see any ACK pulse it will indicate to it's controller that there was a transmission error.
There is nothing about a CAN bus that requires the system to keep transmitting no matter what or to only transmit when requested, that is entirely up to the software controlling the messages. All the CAN bus requires are that the bus has at least two nodes, the correct bus termination, and that the nodes are configured such that at least one node acknowledge every packet.
There are other standard protocols that can be used on top of CAN (e.g. ISO 15765-2) to control message transmission in a request/reply structure but they are entirely optional. Whether it is best to just blast messages out, use a standard protocol, use your own protocol, or a mixture of the above depends entirely upon the application in question.
Best Answer
Bus load = Used capacity / Max capacity. In practice this means how much of the possible bandwidth that was used over a certain period of time.
Assuming standard identifier, a CAN frame consists of:
So the amount of bits is variable depending on how much data there is and also on how many stuffing bits you end up with. Ignoring stuffing, you have an overhead of 47 bits/frame. The maximum frame size with 8 bit data with worst-case stuffing is something like 47+64+19=130.
Lets say you use 250kbps and measure bus load over 10ms intervals. The theoretical maximum amount of bits is then 10ms / (1/250kbps) = 2500 bits. But this is of course not necessarily divisible by full CAN frames.
If you send 10 frames with 250kbps during 10ms, each frame being 11 bit identifier, no data and no stuffing, then you end up with 47*10 = 470 bits, out of the theoretical maximum 2500. 470/2500 = 18.8% bus load.
Whereas 10 of my standard id rough worst-case 130 bits/frame, would give 1300/2500 = 52% bus load.
In practice, tools that measure bus load just clock the time after the end of each intermission field, until the next dominant start bit of another frame appears, then sum all such time periods.