Sebastian Kuzminsky wrote: > John Kasunich wrote: >> [EMAIL PROTECTED] wrote: >>> For now you have to build from source to get hostmot2. It will be in 2.2.6 >>> when it comes out, which might be as early as this weekend. >>> >>> Hostmot2 treats the board I/O pins differently than previous firmwares & >>> drivers. High-level functions like stepgen, pwmgen, & encoder by default >>> "own" all the pins, but you can (at module load time) disable the stepgens >>> etc that you don't want. The pins of the disabled module instances become >>> gpios and are exported to HAL.. >>> >>> Hostmot2 gpios are read and written along with all the other stuff >>> (stepgen, pwmgen, etc) by the per-board read and write functions. >>> >> Hmmm - that means that the general purpose I/O is limited to the speed >> at which you update everything else. Was that decision driven by some >> architectural requirement, or just convenience? How hard would it be to >> pull the GPIO update code into it's own HAL function? > > It was a (perhaps misguided) deliberate decision. The old (now deprecated) > m7i43_hm2 driver has individual read/write functions for gpio, stepgen, > pwmgen, etc, but I just didnt see the value of it. I found myself with a > single HAL thread like this: > > read_gpio() > read_stepgen() > read_encoder() > do_pid() > do_other_stuff() > write_pwmgen() > write_stepgen() > write_gpio() > > Then when I wrote the hostmot2 driver I decided to put all the reads together > in one function and all the write in another. This setup (together with the > HostMot2 firmware TranslationRAM feature) also makes DMA accelleration easier > and more effective, which is one of my long-term goals for the hostmot2 > driver. > > Other than that DMA consideration, there's no reason the hostmot2 driver > can't export different functions for different modules. > > What's a use case where it's valuable to read/write the modules separately?
Mostly something like the arrangement Kirk Wallace has - software stepping, using the GPIO for the step pulses. You might ask "why do software stepping when there is hardware stepping available?" In many cases that is a darned good question, but in Kirk's case, I don't think the existing firmwares supported hardware stepping. There is also the case where you need one more channel of stepping, or encoder counting, or whatever, and you don't necessarily need the full hardware performance. For example, the Mazak at the CNC workshop uses a 4-channel Motenc board. Three encoder channels are used for X, Y, and Z, and the fourth is used to count the spindle encoder for spindle orient and rigid tapping. We used a software encoder counter and two GPIO pins for the jogwheel, since it doesn't spin fast enough to require hardware counting. The GPIO is the _only_ portion that I think would be nice to have in a separate function, I agree completely with your logic for merging the rest. >> Oh, I be I know the issue - it's the parport (EPP) interfaced boards. >> You can't share the EPP bus between threads. That issue doesn't exist >> for the PCI boards, but the unified driver architecture is limited by >> the least capable of the interfaces. > > I believe it's fine to share the EPP bus between RTAI threads, because I > believe RTAI threads (at least as used by HAL) are not pre-emptable. Isn't > that true? Not true. Threads are interruptable, based on priority. Fast threads are higher priority than slow ones, under the assumption that the code in a 1mS thread might take 200uS to execute, and a 25uS thread might need to interrupt it and run a few uS worth of code several times. > The m7i43_hm2 driver has the I/O for the different firmware modules in > different functions, but I never tried running the functions from different > threads. > Regards, John Kasunich ------------------------------------------------------------------------- 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-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
