DavidBo

We have now discovered. That enabling of the I2C interface and after adding an I2C_master but without any devices will have an impact on the traffic on the spi interfaces (or the canopen manager) and here by on the traffic on the can bus as well. We thought that the OS or CODESYS behind the scene with a critical region or semaphores ensured protection of the above. Because in the above example we had an I2C_master as well as one device. Without any I2c_master it can run for days, with an I2C_master...

Raspberry Pi 2 & 4 I suppose that that the I2C_master doesn't do anything as long no device are added. But my experiments have shown tha it interferes with spi. However it requires a great deal of traffic to see it. How can I make sure that SPI and I2c are not used simultaneously?

Raspberry Pi 2 & 4 I suppose that that the I2C_master doesn't do anything as long no device are added. But my experiments have shown tha it interferes with spi. How can I make sure that SPI and I2c are not used simultaneously?

We have now discovered. That enabling of the I2C interface and after adding an I2C_master but without any devices will have an impact on the traffic on the spi interfaces and here by on the traffic on the can bus as well. We thought that the OS or CODESYS behind the scene with a critical region or semaphores ensured protection of the above. Because in the above example we had an I2C_master as well as one device. Without any I2c_master it can run for days, with an I2C_master only for <3 hours

Raspberry Pi I have in the log for the CANOpen_Manager the following message [-img src=canopen manager.jpg width=50%: missing =-] "Tx message pool is empty. Tx queue contains still messages" My problem is that the CANopen_Manager stops sending heartbeat, but can still receive.

We are talking about cyclic PDO. It means a loss of some frames (messages) is not a problem. The problem is that in the above example the transmitting of any message PDOs or heartbeat from the master simply stops and a warm reset has to be done. I don't think the load in the above example is high. However, it can be the driver (or stack) for the can bus, which cannot figure out to queue messages properbly if they come fast from the CANOpen_manager. I will later try it out with a newer version (Bullseye)...

Can anyone explain how the CANopen manager schedules the PDO for each node at every PLC cycle. What happens if the CANBus controllers buffer is full (PiCAN2 is using MCP2515)? It seems only a limited number of frames from the master can be sent from the master, one for each node of total 6. Above that after a while the transmitting from the Pi just stops. The CANOpen Manager version 3.15.17.0 does not it seems scale well.

Have you enabled SPI in Pi using raspi-config