Increase recommended delay time in getting started guide #335
Conversation
There was a problem hiding this comment.
I completely understand where 2ms may seem like the incorrect value here, but it would actually be the recommended shortest delay statement. Additional clarification on why 2ms is acceptable would improve this section I think.
You're correct in that 10ms is the update rate for the majority of V5 peripherals. However, the underlying VexOS functionality that passes the updated values from peripherals to a user program operates on a 2ms cadence. Using a 10ms delay statement is fine, and you won't miss any incoming values, but you might have up to an 8ms lag between updated values being present in VexOS and your user program responding to them.
All of this to say: 10ms is a totally fine cadence for a user program loop, but 2ms can offer a slight advantage. Anything shorter than 2ms won't provide any benefit.
If you're up for re-working this change a bit to include some additional context on the reasoning behind 2ms, that would be great!
|
I think honestly we should just change the wording to "at minimum" 2 ms, but for most applications around 10-20ms of delay. |
Increase recommended delay time in the getting started guide to match the VEX OS refresh time for sensors and motors