John Kasunich wrote:
> [EMAIL PROTECTED] wrote:
>> How valuable is it for hostmot2 to have stand-alone gpio access (for the PCI 
>> cards only)?  It seems like sort of a klunky interface.
>>
>> The differentiating feature of hostmot2 is the flexible firmware, which 
>> solves this problem very neatly.   So I still think the current interface is 
>> the right one, and the solution to the problem JMK described is to compile 
>> another firmware image.
> 
> There are arguments both ways.  I agree that separate GPIO is a bit
> klunky.  But on the other hand, "compile another firmware image"
> immediately takes it out of the reach of 99% of users, no matter how
> "simple" the VHDL is.  The Xilinx toolset is a gigabyte+ download, and
> is not trivial to figure out how to use it.  You might as well be
> telling them "write another driver".  In fact, they are more likely to
> have a C compiler and C programming skills than the Xilinx toolset and
> VHDL skills, and we have a makefile that handles the complexities of the
> build.

Agreed, telling a user to compile custom firmware is not reasonable. 
However, telling them to email Peter is, and that's actually already 
happened.  Peter produced a firmware with the requested number of 
stepgens, pwmgens, and encoders in basically no time, and it worked with 
no changes to the driver or anything else.

But even so: sometimes you might not be on the net, or Peter might be 
busy with something else, or it might just not be convenient for some 
other reason.  Having the existing firmware & driver be able to do 
something reasonable for you in that situation would be nice.

I could add a "threadsafe" flag to the board driver struct, which gets 
set by the board driver if the board I/O hardware is thread safe (PCI), 
and cleared if it's not (EPP).  The high-level hostmot2 driver would 
examine this and only export the "full" read()/write() functions if the 
board driver is not thread safe.  If the board driver *is* thread safe, 
the hostmot2 driver would in addition export gpio_read()/gpio_write().

The PCI drivers would work just as well as they would if hostmot2 didnt 
have to care about thread safety in the low-level drivers.

The EPP drivers would work just as poorly as they would in any case (ie, 
no quick access to gpios).  But at least they wouldnt be broken like the 
m7i43_hm2 driver is, due to my earlier misunderstanding of RTAI 
multitasking model!


-- 
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

Reply via email to