On Thu, 2011-01-27 at 10:26 +0000, andy pugh wrote: > On 27 January 2011 02:25, Kirk Wallace <kwall...@wallacecompany.com> wrote: > > > I haven't seen any documentation on modparam. Does anyone have a link to > > more information? > > I don't think there is any documentation on "modparam" as part of a > comp module. > This is possibly because it doesn't work particularly well. > > You can add a line: > modparam int mp-name "documentation goes here" > to the ,comp file headers, and then > loadrt my_comp mp-name=22 > would allow you to access the value 22 in the function code as the > variable variable-name. (rather like a pin) > However, I have not managed to make it pass a value to more than one > instance of the component (loadrt my_comp count=3 mp-name=21,22,23 > appears not to work, but I didn't look too hard) > > you can use: > modparam dummy "This is the documentation" > to create documentation-only for a modparam in the man pages. > > What I have been using instead is the macros here > http://linuxcnc.org/docs/html/man/man3/RTAPI_MP_INT.3rtapi.html > > These let you read parameters into an array at load time, in the case > of the gearchange comp we have (from memory) > > ;; > int num_gears[8] > RTAPI_MP_ARRRAY_INT(num_gears, 8, "Comment here, not sure if it shows > up anywhere")
I used the RTAPI_MP_INT for my EPP interface comp, but this was just blind luck on my part. I studied most of the EPP based drivers, but they do many of the same things differently. Your (Andy's) description of RTAPI_MP's explains some of why I was confused, Some of the features were used (it seems) to get the parameters into the driver, then used again to do the documentation. Just to be clear, I am _totally_ grateful for all of the software available in EMC2, but if anyone is curious, I think it would be better if the code was clear and concise enough that a person semi-skilled in C could, with effort, figure out the code from the source. I think the automatic documentation is nice, but _not_ if it makes the source harder to understand. It may seem that much of the documentation would not get done if it were only up to the original coder, but having clear, concise code, documented by one or more other people might be good way to peer review the code. Back in the dark ages, when I was a drafter, that was how my employer's documentation got done. I would work with the engineer to understand the parts he designed, then I would make the drawings. After I was done, the drawings would then be reviewed and hopefully signed off by the engineer, another drafter and my boss. Although, none of these people thought they were my peer :(. Again, I don't want to sound like I am complaining, but it seems that there are a fair number of auto generated documents that don't really help. If it can make the source code leaner, let's just not do the documentation. Doing the documentation later could be a way for us with different skills to contribute to the cause, but this can't be done if the code isn't clear. On the other hand, I don't want the above to dissuade anyone form contributing. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
