rgh wrote:Note the driver needs to know which pins are to be used for servos, so it can program them as outputs on startup. So, if you want to use a P1-4=<width> sort of syntax "'P1-4" would only be valid if either P1-4 was one of the default pins, or if you'd specified it in a --p1-pins= parameter.
Yes. I am aware of it and it makes sense. That's why a separate device which can be read which returns list in that format (or some other mechanism we discussed here) would be useful. If you try a pin that is not configured and got error that would be completely expected.
Now, just a food for thoughts: what if you can configure it 'on the fly' adding new pins as someone tried unconfigured pin for the first time? Also, you might, then want a format of P1-4=<something special> to deconfigure pin if not in use any more.
No idea how hard would that be - but if possible would make /dev/servoblaster really easy to be used and remove some static (or semi-static) constraints. And I hope you don't mind my 'daydreaming' here!
Again - I am aware that such operation itself can be slightly costlier and could cause all other servos to 'lose' a few pulses while 're-configuration' is happening.
rgh wrote:Anyway, it'd be easy enough to support a P1-4=<width> syntax in addition to the current syntax, and I can see that might be useful, so I'll add it. Not until sometime next week though.
rgh wrote:Your other question, about opening the device file once and then writing multiple commands -- that should work ok.
Thanks again. I'll organise our code to be based on file being constantly open.
rgh wrote:You also mentioned doing updates up to 333 times a second. This driver uses a 20ms cycle time for the servo pulses, so there is really no point updating the pulse width more often than every 20ms (i.e. 50 times a second). It could be changed to use a shorter cycle time if someone needed it.
That's fine. I expected that behaviour. But if you eventually make cycle shorter (for all pins at the same time - I expect that to be cheaper - or each individual pin) it would help.
Again - this is only my thinking ahead - a day dreaming - all singing and dancing final driver would, in that case, have ability of setting each pins frequency to 50Hz, 65Hz, 120Hz, 240Hz, 333Hz (or something like that) - or even better almost free form from 0Hz to 333Hz and you would be able (with some constraints) to change resolution between 1us to 10us... (that last one is a bit stretched I know! O : ). Now I do understand that there are trade offs in such cases and that's why I didn't even begin to contemplate asking you (or looking into it myself) for such concessions.
Even with all we already have - Servo Blaster presents really cool piece of software! Thank you!