Sebastian Kuzminsky wrote: > [snip] > >I totally agree it's far from ideal, but it's the least worst thing I >could think of at the time. > >The fundamental problem is the low-level board drivers need to support >multiple boards, and each board has multiple pwmgen and stepgen >instances etc, each of which will need its own configuration information >eventually. So really what's needed is an array of board-config >structures. Lacking that, a two-dimensional array for pwmgen configs, >another one for stepgens, etc, would work. But modparams dont support >either of those data structures. > >I could hack up something like this: > >"loadrt hm2_5i20 firmware0=hm2/5i20/SVST12.BIT >firmware1=hm2/5i20/SVST8_4.BIT encoder_enable0=1,1 >encoder_enable0=0,0,0,0,0,0,0,0 encoder_index0=1,0 >stepgen_enable1=1,1,0,0 stepgen_width1=2,2" > > How about something like this: 1) the user loads hostmot2 just like now 2) for each type of board, the user specifies parameters for that board set, in a linear array. The board driver can put things where they need to be in the hostmot2_t structure. Example: 2 boards, 2 stepgens used on the first and 1 on the second board. The driver must have an RTAPI_MP_ARRAY var that's big enough to hold settings for the maximum total number of stepgens (or anything else) that it supports, so 4 stepgens * 4 boards = a 16 element mp_array. The stepgen related parameters would be as follows: loadrt hm2_5i20 num_stepgens=2,1 step_types=1,2,2 step_widths=2,2,5 You only specify the types and widths (assuming they're independent, which they probably don't need to be) for the stepgens you have turned on. In this case, board 1 will have 2 stepgens, type 1 width 2 and type 2 width 2. Board 2 will have one stepgen, type 2 width 5. The board driver has to move the parameter values around so that the third stepgen info is in a second hostmot2_t structure.
The other possibility is to use a single array with all the positional data concatenated for all boards. Assuming there are 4 stepgens per board, my previous example would be: loadrt hm2_5i20 stepgen_enable=1,1,0,0,1 step_types=1,2,0,0,2 step_widths=2,2,0,0,5 (Actually, I like the idea of having any enables positional - that way you don't have to use the first N "things", you are specifying a map). Actually, using positional enables with shorthand options seems the best route to me. It's pretty easy to have a descriptor for each board that tells the number of possible "things" for that board. There can be a function in hostmot2.c that takes pointers to the parameter arrays, the hostmot2_t structs, and the "board type descriptor" struct, which can move the numbers around as needed. (ie, take the third set of stepgen info in my first example and move the type 2 and width 5 into the second hostmot2_t struct) >That's not exactly pretty either, but maybe it's better than the >alternatives. > > I don't know :) >You (JMK & SWP) solved this configuration problem by (iirc) adding an >"r" chunk to the bit files, but I dont like that, I think the config >should be separate from the FPGA firmware. > > It's debatable. There are merits to having a file that always defines the same functionality. As long as it's not too hard to create and move configurations, I think it's a good system. >I considered putting the config info in a separate file and let the user >supply the filename as a modparam, the driver would request_firmware() >to pull it in and parse it in kernel space. That's pretty gross though, >the user would have to put the file in /lib/firmware, and writing a >config-file parser in kernel space will not make me any friends. :-/ > > Well, it's not a great idea. It's reinventing a big wheel, for no practical gain. What's the real difference between the two modes? It's that the data for a single stepgen (or whatever) will be in one place (with some extra words in between). You still need to provide all the data on the command line, there's no way around that. >What's there now is essentially that, except the file contents are >passed in in the "config" modparam, and the kernel driver parses *that*. > > Well, you could use this instead: halcmd loadrt config="$(cat myfile)" or similar. No, I don't recommend it. ;) I'm leaving tomorrow mid-day (eastern time), but I'll have a few hours in an airport and another few in an airplane that I can work on this. Let's try to get a "best mix" preliminary design done before then, and I'll work on it on the trip. - Steve ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
