A good part of this week has been devoted towards researching additional info on various things which have been worked into other blog entries. So most of this week's documentation has been distributed amongst the other posts.
One notable thing I've been throwing around is the possibility of RobotC multithreading. This could possibly reduce the latency of a sensor access from the NXT user program's perspective. By spinning up a background thread whose job is to continuously poll attached sensors, the data will be more or less constantly updated and available during the main execution loop. This is slightly more efficient than my current method of only polling the sensors at the start of each execution loop iteration. And it would also be good to understand how to multithread on RobotC anyways.
After looking into it (15-20 minute jam session), RobotC has a relatively simple multithreading implementation. It's referred to in RobotC as "multitasking", and it involves creating separate "Task" routines and then kicking them off with StartTask().
task main()
{
StartTask(Task1);
StartTask(Task2);
}
task Task1()
{
//Things
while() ;
}
task Task2()
{
//More Things
while() ;
}
Code 1. That's literally all you need to do to create a separate thread.
As can be seen, it's a relatively painless affair. However I do urge caution, in ANY user program ANYWHERE too much multithreading can be dangerous and resource intensive. Without proper understanding of how to multithread correctly, it may just be simpler to keep things iterative. I'm fairly sure RobotC doesn't implement any "high-level" control of multithreaded constructs (Mutexes/Semaphores), so keeping critical sections safe lies entirely on the programmer.
I may pursue this further to implement background sensor polling.
