Gina,
Itās not, although is probably is. I did a bit of research on how the BCM2837 does USB. I couldnāt find the actual hardware manual (I put a request into Broadcom, but have not heard back), but I found the hardware peripheral info on the BCM2835 (used in the PI2), so it is probably similar to the one used in the PI3B. The operation of the serial ports (including the USB is similar to the 16550 UART without the DMA.
Anyway, without going into a lot of hardware talk, my suspicions seem to be correct, although I have no idea how Raspbian does itās I/O. What happens is the serial data is assembled and written into a register. The processor has a limited amount of time to extract that data before the next byte is written into the register. There is a limited time after the serial interrupt when the data has to be retrieved from the UART before new data is written into the register. Timeouts and serial exception mean that when the interrupt occurs, data is not timely read from the register, and so the processor canāt get any the serial data. One can calculate this time, but obviously, Raspbian is not getting the data fast enough before the next byte of data comes in.
The problem mainly occurs when the serial handler is poorly written, and priority is not given to the serial interrupt. Remember, I have no idea how Raspbian does their serial I/O (USB), nor how it is programmed, so I canāt pinpoint where the problem lies. Unfortunately, Gina, I donāt think you can do anything about it, except find a real-time linux that will run on the PI.
What makes the Pi different? On big computers, USB is typically handled by DMA (direct memory access), where the data from the UART is written directly into a memory buffer, and therefore, timing is only critical to keep the buffers switched so the data keeps flowing. X86 architecture is like this, and the 16550 UART works like this. The little machines (like the PI or the Arduino) donāt have enough real estate on board to implement this, and so you have timing issues on high data throughput.
My suspicion on Raspbian is that they ported Debian without rewriting (or minimally rewriting) the I/O handling. These tiny chips require a total rewrite of the I/O handlers when used in a high-throughput or real time capacity. A real-time OS (or a real-time Linux) should have done this already.
When it comes to the snake (Python), how the implementation of the language interpreter and garbage collector interface with Linux may be part of the problem. If they are part of a Linux thread spawn (at the OS level), then all that software can affect the I/O timing because of the software load. You might not even know this from CPU utilization because CPU utilization might not even be calculating this. I typically go by CPU temperature to determine the load on the CPU, not the utilization number. On my PI 2B+, based on the temperature, the CPU utilization Is fairly high because I can see throttling taking place, and the 3D prints show it.
My only comment is to try to explain what is going on, not specifically how to fix it. The real fix is not to use Raspbian as a real-time OS, and to code certain portions of Octopi in C or C++, but I understand this probably isnāt practical.
Take a look at the source code of Marlin, and you will get a fair idea of writing embedded code. The PI is great for some things, but not great for others. Octoprint might have been better on an Arduino, not a PI. The Arduino is a simpler architecture and is easier to code without an OS.
The PI isnāt a big general purpose computer that does multiple things. Itās a tiny machine, that probably does one or two small things well. I had a similar argument in another part of this forum where I was asking questions about shutting off the main power supply of the printer, which also powers Octoprint. I got arguments as to why the PI should be left on all the time because it can do other things. I countered this argument, but I couldnāt convince some folks. Anyway, I figured out how to do what I wanted to do on my own, and now Octoprint nicely shuts down the printer power supply when it shuts down.
Steve
