Quote:
Originally Posted by Colby Skeggs
I only figured this out by diving into the Squawk source code that I found online - so it's possible that the cRIO uses a majorly different version of Squawk, but I sincerely doubt it, especially as it matches all my observations and it seems difficult to change the concurrency model of Squawk. Luckily, this doesn't actually matter all that much in practice. The main location where it's annoying is when you're doing vision processing, because, at least with old versions of the FRC library, our vision processing could block other threads from running for ~100ms and cause major lag. Luckily, we changed our code so that we didn't have this issue, but it still wasn't very nice.
|
I feel your pain with that one. There's definately been stuff that gets provided that just doesn't seem like it works the way it should. Like on the old PICs if you just took their standard template and inserted a single call to atan2() or cos() the robot would totally die. (The built-in math functions took longer than the watchdog's timeout, which was updated in the same loop)
Quote:
Originally Posted by Colby Skeggs
Actually, CPU usage here is completely relevant. Would you like to use a computer that's using almost all of its CPU on busywaiting? It would probably be slow, and there's certainly many better ways to do it. Busywaiting is a known antipattern. The only reason it could make sense is if you are sleeping for a very short amount of time.
I agree that this is a good solution, in some rare cases. I've even used it myself in bare-metal programming, when there's literally nothing else that the computer could possibly be spending its time. But it's not a good solution in this case. While it is a solution that "works", it is not a reasonable solution for this context. |
Why do you care about the CPU load %? If you have a latency problem then you have a latency problem regardless of CPU load. If you're not getting the throughput you want it could be because you're waiting on the internal storage. If your robot is drawing too much power, I doubt it's because of the CPU. (Does the cRIO's CPU ever go into a low power mode anyway?) And I've never heard of the cRIO having a thermal problem.
Maybe this is just the electrical engineer in me talking but when I hear about an embedded system where the CPU usage will never spike above 2% my reaction is not that the software is super-efficient but that the desginers should have put a cheaper part on their board.