[Feature] More precise intervals #9
Comments
|
The logTask loop also seems to poll interrupt flag with no delay whatsoever. This may hog CPU to 100% when waiting for something to happen. Optimizing logTask will give Wifi Task more CPU time to do its job! |
|
@tomek-szczesny Thank you for the feedback. First, I will check that you can set log intervals both of WiFi and Serial each of them so that we can set different intervals. |
|
Hmm, I was thinking, in addition to the above, maybe saving the logging output to some temporary memory buffer and reading the values for WiFi and serial logging output from there could decouple the tasks (and maybe run them on different cores). Then the logging would not necessarily have to wait for Serial and WiFi to finish sending, the log sending method could be turned on/off independently. That would also have it's drawbacks (like what if the sending part is too slow and the memory buffer grows too large or overflows, but that is also solvable). |
|
Breaking down processes into asynchronous producers and consumers may also help, especially if the consumer runs at the lowest priority. Good idea. Like I was saying, I think the log data may be buffered and sent less often.
Quite unlikely to happen, and the real question is what would we do if the consumer/sender part said the buffer was full.. Stop measurements? :) Might as well discard some samples that do not fit into the buffer. |
Just brainstorming:
|
|
I think you convinced me that no samples should ever be dropped - that would be a regression compared to current solution. But, digging deeper, perhaps a buffer should be a class of its own. A circular buffer with no explicit outputs. Here's how I see it: A circular buffer class, that is basically an array of bytes to be sent, and one integer variable, a "write counter". This variable will always represent an array index of the last byte written to the array. All the new data will be written after the old one, in a circular manner. The producer, writing data to a buffer, will also update the "write counter". Consumers will have read access to this buffer, more specifically the data array and write counter. Each consumer will have their own integer variable, the "read counter", that will represent the last index the consumer has read in previous iteration. If we assume that producer will never be faster than consumers, then no mutex magic is even required. I think 10kB buffer would hold up to 1s worth of data, which is definitely enough. I'm just thinking out loud, maybe not all of that makes perfect sense. I won't be able to help you implementing it, so it's up to you to select the approach you think is the best. By the way, you've done such a great job working on this firmware, thanks for that. If you were a student that could be a solid basis for a thesis, you know. :) |
|
Thank you :) I'll think about the problem. To be frank It won't be the next item I am planning to implement (have something else related to SP3 in the works and time is limited) - just wanted to get my thoughts on the matter written down here just in case somebody else decides to work on this in the meantime. |
This is my log from measurements in 10ms intervals, captured via wi-fi:
Barely any samples actually are spaced out by 10ms.
I think the Wi-Fi process is too heavy and clogs the normal operation of the device.
I think it is sensible to sacrifice Wi-Fi response time to restore equal interval operation.
What I suggest to do is either:
The text was updated successfully, but these errors were encountered: