I like the ideas, keep em coming
you've got a lot more experience with this type of software than I do. I deal with low level embedded stuff for work and almost never write for an OS.
Well I learned that python has a GIL which basically means multi threading doesn't work as you'd expect because only 1 thread ever runs at a time in a python interpreter. This explains why my seperate thread to handle SPI comms at a specific interval goes to complete shit once the digital inputs get loaded up.
I realized that what slows it down is the combination of the fact anytime the digital inputs switch, a call back occurs in python, where I determine frequency of wheel input and the fact that the SPI ADC calls are all blocking and I can't kick them to a separate thread like I'd expect. When these two happen together, CPU usage hits 100% (on a core) and the script gets backed up with so many call backs that it takes a while for it to do anything
This means I have 2 options:
1) write the critical code in c like I should have done from the start.
2) have multiple python threads launched separately that somehow communicate to each other.
I know doing this via C is the correct method, just sucks I'll have to rewrite all of my code :'(
Guess I'll need to look into how timers work on this thing and if I have access to them at any low level.
I shouldn't need the CPU to run at 1.5 GHz to accomplish 100 Hz sampling.
It was so easy in python... Damn