Maybe we need three parts: 1. At the lowest level, we send pulses to the servo. servo_set() (now called servo_move ;) could be the major API. This is close to servo_rc_master (but I don't understand what 'master' means in this name). servo_rc would be a good name and we could create other ones with similar interfaces for other servo's. This libraries should provide the most basic features to control the servo and be efficient.
2. On top of this some advanced features like ranges per servo, call with percent in stead of byte value. Maybe even 'reverse' should be in here and not the (1). 3. above this what you call REPL and where servo_rc_master_dedicated is an example of (and unlike the name suggests, it is an i2c slave library). IMO this should not be a library but a project or sample. Just the i2c interface as a library has no value as far as I can see - you either use it as is (and then it's a project/sample), or need to adapt it if you require other features too (and it is a bad habit to put application-specific stuff in libraries). As I said: the basic servo lib looks good. It can be better organised though. Joep 2010/10/15 Sebastien Lelong <[email protected]>: > OK, sure. What I mean is a servo controller library can have two parts: > - one part is responsible for sending and maintaining PWM signals > - another part is responsible for providing an interface (serial, > i2c,...). > The last part implements a REPL and interacts with the first part (it calls > procedures). The second part is what I call the firmware, and > storing/restoring servo position, defining max/min values for each servo, or > for all, can (should ?) be done at this level. > If user doesn't need any repl or firmware features, he can just use the > first part. We can also provide more than one firmware, particularly when > dealing with "servo dialect" eval (SSC32, MIC800, Pololu, ...). > > Cheers, > Seb > A user may not need the second part or could just implement his own. > > 2010/10/15 Joep Suijs <[email protected]> >> >> Hi Seb, >> >> > This is mostly related to some firmware implementation, not the library >> > itself, isn't it ? >> Not sure what you mean... >> What I mean is: give the user the option to leave enable/disable the >> option at compile time so they don't fill up their flash with >> functions they don't need. This way they have space for the stuff they >> do need. >> >> Joep >> >> -- >> You received this message because you are subscribed to the Google Groups >> "jallib" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/jallib?hl=en. >> > > > > -- > Sébastien Lelong > http://www.sirloon.net > http://sirbot.org > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
