On Sat, 2008-08-09 at 11:50 -0600, Sebastian Kuzminsky wrote: > John Kasunich wrote: > > Sebastian Kuzminsky wrote: > >> John Kasunich wrote: > >> What's a use case where it's valuable to read/write the modules separately?
If I get the drift of this conversation (and that's always questionable) I think what you are asking is: "Is there a situation where a GPIO pin needs to be read or written in the base thread, or in a faster thread than the 'modules'?" If so, I think the most stressful situation is probing - the need for a high speed input surrounded by 'modules' that only require servo thread rate servicing. 1. Since I'm planning to use the PCI bus cards, I fully support the "thread-safe flag" idea ;P. 2. Another, possibly technically superior, method is to make a "probe module" in the FPGA. This could take a snapshot of the position registers (step generators and/or encoder counters) for later retrieval by EMC. The problem with this idea is that when the probe trips, deceleration wants to start immediately. Since trip detection is delayed by less frequent readings in the slower thread, a hard collision with the probe _might_ occur. This means that (unless we could have the Mesa card send a hardware interrupt to the real time system) the probe bit needs to be read at high frequency, although a hardware triggered "position snapshot" would maximize probe data accuracy. > Heh, the way to do that with HostMot2 is to email Peter and ask for a > new firmware image with an extra stepgen and encoder. :-) > Or just change a couple of constants at the top of the VHDL and compile > it yourself (assuming you have enough gates & pins). The new VHDL > source (not in CVS yet) makes this kind of tweaking really easy. On Sat, 2008-08-09 at 16:01 -0400, John Kasunich wrote (in another message of this thread): > 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. 1. The WebPACK is now about 2-1/2GB, and concerned scientists predict it will grow until the mass of it's bits is so great that the universe implodes. 1a. I couldn't get WebPACK to run on Linux because I'm on an x86_64 machine, and it's ia32 only. There was the beginnings of 64 bit support (references to non-existent directories in the install script), but even hacking the install script didn't work. This will probably be fixed soon, but this whole package should probably be distributed by bit torrent... 1b. I can't help but think that there is (buried under the IDE) a command line VHDL>bit-image compiler. I couldn't find it, and we probably couldn't redistribute it without permission, but if there is, and we could, that would solve the first problem with making new FPGA code if incorporated into the build system. 2. I did try to do modifications to the FPGA configuration myself, and just couldn't understand what to do. In my defense, I was really tired at the time! I called Peter and he was very good about quickly making the changes I wanted! I haven't had the chance to test what he made yet (I'll get back to this sometime before September 1st), and maybe by studying the differences between what Peter made and the stock configuration files, I'll gain the understanding needed to help myself in the future. 3. Once I know enough about what to do to make new VHDL files, I can probably hack together a program that takes user input of the desired configuration and spits out the required VHDL. This would be limited to "themes and variations", not entirely new module types, but could be helpful. Thanks, Matt ------------------------------------------------------------------------- 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
