How much thread does roboRIO have?
Thanks.
Here is the:
Spec Manual https://www.ni.com/pdf/manuals/375275a.pdf
User Manual https://www.ni.com/pdf/manuals/375274a.pdf
2 Likes
I will note that the metal inserts on the MXP board attachment points are not closed bottom inserts, meaning, if you use too long of a screw there, you will punch straight through the plastic and into the mainboard of the RoboRIO. So, be very careful with those.
I’m guessing the question here is regarding the programming type of threads, not the metal ones.
The RoboRIO is a dual core system, so it’s only ever able to truly simultaneously execute two threads. That being said, thanks to the magic of modern operating systems, it can execute a pretty large number in parallel, automatically switching between them. In theory, you could start just about any number of threads you’d like. In reality, you’re always going to have a tiny bit of memory overhead when starting a new thread. It’s pretty close to zero (if not zero, can’t remember off the top of my head) with C++, but more substantial in Java. So, if you’re in C++, make sure to mark the appropriate variables volatile, make sure your functions are reentrant, and go nuts. That being said, in Java you might want to be a bit more conservative — the RIO’s pretty memory limited and I’ve OOM’d it a few times with one too many threads running. If you’re looking at doing a fan out / fan in style workload distribution, with a super high number of threads, you might want to look at lightweight coroutines, a form of virtual, or software scheduled thread with extremely low memory overhead. Kotlin’s coroutines are a pretty great implementation, and so is Parallel Universe’s Quasar library.
All that being said, it’s not actually that common teams require true multithreading in FRC code - command based code does a really good job of allowing different tasks and processes to occur in “parallel” (they’re actually managed by a scheduler, but things happen concurrently as far as the programmer’s concerned).
It might help us answer this question better if you can speak more regarding what you’d be using the additional threads for?
Just to be clear, in C++, volatile is not a threading primitive. It is generally used for things like memory mapped IO where the value at a given memory location can change outside of the normal program flow. It basically disables optimizations for that variable and requires a read-modify-write for each access. But that doesn’t help with threading synchronization issues.
For c++ thread safety, look to std::atomic or for larger structures actual locking mechanisms like std::mutex and std::lock_guard.
3 Likes
Pretty thank you.
These days I read the code from Team254, and they seem to use many thread. I couldn’t understand it very well. Just want to know whether too many thread will delay or any other question or not.
Their crashTracker looks cool!
If I can, I will add it to out program.
Thanks to your answer.
Just to be clear, in C++, volatile is not a threading primitive
Agh, knew I was missing something. Embedded development’s ruining me… 
aaah yes, it was the software kind 
!
100% recommend 254’s crash tracker, or something similar to it. Used it multiple years now, it’s caught multiple hard-to-reproduce issues.
In general, the number of threads is limited by certain details of the OS, processor/RAM/Disk hardware, the JVM. However, the bigger limit is keeping each thread’s periodic update method getting called at the desired rate. Too many threads, or threads that take too long to execute, you’ll start to have issues maintaining smooth control of the robot.
So, It’s less about total quantity of threads, and more about how long it takes each individual thread’s periodic update method to complete.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.