Closed AndyLindsay closed 5 years ago
I meant to say, "...11/1 firmware and libraries..."
Whoa, that's a huge change in speed. I hope it can be fixed.
Try now with the reset checking offloaded to its own cog. Should now go back to its pervious speed.
With regards to potential slowdowns, the code that reads and clears args can take much less C overhead time by taking advantage of the fact that the args are defined contiguously and calling a single memcpy and memset. This is probably not the big slowdown we see, but there is a fair amount of extra overhead there.
so this...
int arg1, arg2, arg3, arg4, arg5;
int retVal = 0;
memcpy(&arg1, ®[ARG1], 4); memcpy(®[ARG1], &retVal, 4);
memcpy(&arg2, ®[ARG2], 4); memcpy(®[ARG2], &retVal, 4);
memcpy(&arg3, ®[ARG3], 4); memcpy(®[ARG3], &retVal, 4);
memcpy(&arg4, ®[ARG4], 4); memcpy(®[ARG4], &retVal, 4);
memcpy(&arg5, ®[ARG5], 4); memcpy(®[ARG5], &retVal, 4);
can be changed to this...
int arg1, arg2, arg3, arg4, arg5;
int retVal = 0;
memcpy(&arg1, ®[ARG1], 20);
memset(®[ARG1], 0, 20);
@MatzElectronics @PropGit 30 ms delays between bot(pin).digital_write(state) are still there. The I2C bus rests for 25 ms between 5 ms communication packets.
Verified, fixed in 11/8/18 6:27 PM commit. digital_write(0/1) cycles at about 3.8 ms per command.
The code below tested on the 10/25 firmware and libraries repeated every 9.25 ms. With the 11/1 firmware, it takes 60 to 62 ms.