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?
> 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?
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.
>> The hostmot2 pinouts are almost certainly different than the ones in the
>> other 5i20 firmwares & drivers. The pinout used is determined by the
>> firmware loaded and the configuration chosen by the user. The pinout used
>> is written to the system log when the driver is loaded.
>
> It can't be too different if it is going to work with the existing
> interface boards like the 7i33, 7i37, etc.
That's true - all the existing firmware images mate up well with the other Mesa
products.
--
Sebastian Kuzminsky
You think you can defeat me with your rebellious beard?
<http://www.youtube.com/watch?v=k_QAPjtO2cA>
-------------------------------------------------------------------------
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
