gmane.linux.distributions.emc.devel

Re: Controlling EMC from a non-GPL application

Jon Elson — 2008-11-29T20:12:04

No, much, MUCH harder than you think. IC design software is INSANELY expensive, $250 K per seat per year in some cases. And, the educational licenses specifically state nobody can benefit from the chips made through the use of these tools. We have had a few chips made through MOSIS using Mentor and Cadence tools, and since it is all for government grant and university research, it passes muster. I even build the boards commercially after the chips are supplied from one university to another (my customer). An all-digital chip is a lot easier to simulate and be sure it will work, but the number of potential pitfalls are enormous. And, still, even making them in small quantity, the cost is quite high. We pay something like $200 PER CHIP for a fairly large, mostly analog signal processing chip. (Ummm, we are in the seventh generation of one of them, and it STILL has problems - that's my job security, taking flawed chips and coming up with the external hacks to make them work.) The guy who does the IC design had one chip that was missing one via between layers, but it was connecting the main digital clock from the lead bonding pad to the rest of the works, so the entire chip was totally DOA. Anyway, even a quite small ASIC through MOSIS will run about $10K installed in a package, for the first FORTY chips! If those work, you can then get more off the same wafer for another couple grand. MOSIS will NEVER be competitive with commercial chips unless you buy them by the thousands, and then you can just contract directly with one of the foundries. What I'd really like to see work is an RT_USB driver to the Cypress FX2LP chip and an FPGA after that. I'm still not too clear on the limitations of the USB, though, so maybe ethernet is a better choice. But, I've been fooling around (yes, that REALLY is the right term, I have NO IDEA what I'm doing yet) with the Cypress chip at work, on a control project that doesn't need real time or any great speed. But, I have a little demo on my desk that reads 39 MB/sec and writes 31 MB/sec over USB. QUITE impressive. The FX2LP chip handles the actual transfers entirely in hardware, so it is as fast as the USB high-speed can go. I don't know what the latency of sending a small request out and getting a small reply back would be, or how you might arrange to force a small packet to be sent and prevent it from buffering them up. But, it looks fairly promising. Jon ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Jeff Epler — 2008-11-29T15:00:51

There are two separate questions that seem to be asked in this thread. First, and what Paul seemed to be asking: Can someone distribute the binary firmware files such as pluto_step.rbf along with the corresponding source code and meet all the requirements of the GPL? Matt Shaver and I have gathered a lot of information to show that the consensus of the Free Software community is a clear "yes". There's a separate question that is getting mixed in, which is Would the goals of Free Software be advanced if it were possible to develop for FPGAs using only Free Software? This isn't a question of complying with the terms of the GPL. The answer is also "yes". But that doesn't mean that those who are pragmatic and write code for FPGAs today can't release their work under the GPL and let others benefit from it. The second question is a matter of Free Software advocacy, and it's off-topic for this list. Jeff ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Matt Shaver — 2008-11-29T05:29:35

I think I have found out. While reading Slashdot, one of my favorite ways to waste time, I came upon this: http://linux.slashdot.org/linux/08/11/28/2339242.shtml which points to this article, which is a good summary of the situation: http://itmanagement.earthweb.com/osrc/article.php/12068_3787736 Our situation is even one step above that described in the article because we are distributing the source and build scripts (as it is possible) for the firmware, with our only non-free dependence being the tools. I suppose we could make the firmware related files a separate package, maybe "emc2-contrib"? Past that point, we are at an impasse. Without firmware, the hardware doesn't work. As far as I know, there are no libre firmware "synthesizers" for the FPGAs the we use. Also I am unaware of any libre FPGAs There was this, but it's long dead: http://www.eetimes.com/showArticle.jhtml?articleID=161600613 There's also this: http://fpgalibre.sourceforge.net/intro_en.html but, if you scroll down to the "Synthesis" section, you'll find that they have no alternative but to use the "gratis" tools as there are no "libre" ones. I think, for now, if we want FPGAs, then we are stuck with Quartus (Altera) and WebPack (Xilinx). Personally, I've only recently warmed up* to these kinds of devices (I even looked askance at PALs and GALs when they came out for the same reasons). My reluctance to fool with them was directly a result of this non-free tools situation. However, the benefits of this, admittedly very clever, technology are so great that the "no libre tools" argument is unlikely to sway most technology consumers. If a chip maker _did_ offer libre tools, I would be their enthusiastic spokesman! It's possible that a "universal cnc peripheral chip" could be designed and made this way: http://www.mosis.com/ but I expect the cost benefit analysis would still favor FPGAs unless considerable weight were given to libre philosophical requirements. Puzzled but ever hopeful, Matt * - I actually designed some hardware that used Intel's Flex Logic, before it was sold to Altera, but another smarter guy did all the logic inside the device. ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Chris Radek — 2008-11-28T01:12:31

Sure but the thread was about the GPL, and more specifically your mistaken interpretation that led you to incorrectly assert that distributing these firmwares is not allowed under the GPL. You are not suggesting that mistakenly including a config.log in a source package (if in fact we accidentally do that) is a GPL violation are you? If you want to submit a patch that cleans up something about the packages I'd happily review it. Yes, as it says, that's exactly what causes it to be in contrib. What is your point exactly? Yes they both do a good job! What is your point exactly? Chris ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

paul_c — 2008-11-28T00:43:00

NO. It falls under the heading of what should or should not be included (or even code review). For example, why distribute pointless files such as config.log, config.status, and assorted *.pyc If you have a USRP, you probably also want to install the usrp package as suggested, which lives in contrib because the FPGA bitstrings require non-free tools to build. Peter Wallace has had the foresight to release his source under a dual GPL/BSD, and thanks to the efforts of Seb, the drivers are free of excessive bloat. ------------------------------------------------------------------------- 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=/

Re: I need an RF TRANSMITTER and RECEIVER DATALINK FOR PARALLEL PORT

Dave Caroline — 2008-11-26T21:08:10

Perhaps google for the following a bi-directional microwave link maybe a license exempt one if available this would internally have serial to parallel and parallel to serial at both ends, be aware that any loss of communication would disable feedback and endanger the machine and its operator and the work. far better to make the controller robust enough for the conditions its in. Dave Caroline ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Jeff Epler — 2008-11-26T15:34:23

Actually, Paul, the fact that Debian distributes gnuradio and its usrp component including an .rbf firmware file[1] makes it clear that Debian also interprets the GPL the same way as gnu, opencores, xilinx, mesa, Matt Shaver, Peter Wallace, and I all interpret it. If Paul's argument (that you can't build GPL software with proprietary software and distribute the result while complying with all requirements of the GPL) were true then Debian would refrain altogether from distributing the binary firmwares in the usrp-firmware package, not merely segregate it to "non-free". "non-free" doesn't mean "we unrepentantly violate licenses in this section"[2]. Red herring. Jeff [1] http://packages.debian.org/etch/gnuradio http://packages.debian.org/etch/usrp http://packages.debian.org/etch/usrp-firmware http://packages.debian.org/etch/all/usrp-firmware/filelist containing /usr/share/usrp/rev2/multi_2rxhb_2tx.rbf among other files [2] It is most likely that gnuradio is outside of main because of the requirement that packages in main must not require a package outside of main for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-main package), http://www.debian.org/doc/debian-policy/ch-archive.html#s-main not because of any GPL violation, which would obviously cause Debian to not distribute the package at all. ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

paul_c — 2008-11-26T14:47:56

GNU Radio's firmware is not "free" enough for Debian to distribute in Main.. If it is OK to distribute firmware binaries without the necessary tools to build them, it raises the question why bundle stuff like yapps as part of the emc2 tarball. ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Jeff Epler — 2008-11-25T16:37:31

Paul, You are simply wrong in your interpretation of the GPL here. The linuxcnc.org project is not alone in applying the GPL to software that runs on FPGAs and is compiled by proprietary tools. The GNU project "gnuradio" is another (and you can bet that official GNU projects have a high level of scrutiny as far as license compliance!). Their home page is: http://www.gnu.org/software/gnuradio/ they do very much the same thing I have done: provide the verilog source, the other files used by the Quartus 2 environment, and the .rbf output files. Take a look at the gr-gpio/src/fpga subdirectory of their source distribution to see for yourself. Others who believe the GPL can be applied to FPGAs are Xilinx (a major FPGA producer), which I mentioned the last time you brought up this crazy "FPGAs can't run GPL software" claim over a year ago: http://www.xilinx.com/publications/xcellonline/xcell_46/xc_pdf/xc_freesw46.pdf

Re: Controlling EMC from a non-GPL application

Matt Shaver — 2008-11-25T11:50:15

If we're in trouble, so is the GNU Radio project. As an example, if you download their latest version and look in the archive file at /gnuradio-3.1.3/usrp/fpga/megacells/ you'll find stuff that was autogenerated by Altera's tools. Also, in /gnuradio-3.1.3/usrp/fpga/rbf/ a lot of .rbf files are included in their project's distributed files, yet they don't distribute the development tools that produced them. "# Compiling the verilog (not required unless you're modifying it) If you want to build the FPGA .rbf file from source (not required; we provide pre-compiled .rbf files in usrp/fpga/rbf directory), you'll need Altera's no cost Quartus II development tools. We're currently building with Quartus II 5.1sp1 Web Edition. The project file is usrp/fpga/toplevel/usrp_std/usrp_std.qpf. The toplevel verilog file is usrp/fpga/toplevel/usrp_std/usrp_std.v. The bulk of the verilog modules are contained in usrp/fpga/sdr_lib" I have to believe that if there was a problem with distributing these files then the FSF would not have given this project their imprimatur. 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=/

Re: Controlling EMC from a non-GPL application

paul_c — 2008-11-25T08:58:09

Section 3 c) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Quartus does not qualify as a "major component", nor is it free, neither is it's output - Please read Altera's T&C. If you need clarification on what constitutes "non-free tools", I would suggest contacting the Free Software Foundation. ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Jon Elson — 2008-11-23T00:27:34

Good point! Are you volunteering to write an overview of the license environment of EMC2? In lieu of a truly comprehensive list of license status for every file, it is up to each person who has some commercial interest to understand the license environment and how it affects what he is doing. You are quite right. Bit, I think it is quite possibel to have a sophisticated software interface between licensed software and EMC2 without any entanglements, by using the right interface(s) into EMC2, at least for the kind of situation Les was interested in. Jon ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Jeff Epler — 2008-11-22T20:17:47

Paul, Thanks for giving me a chance to clarify this. The pluto_step.rbf file is built from the source files in pluto_step_firmware using the proprietary Quartus II development environment from Altera. The process of building in the Quartus GUI seems unscriptable; instead, I describe the process in prose in the manual: The src/hal/drivers/pluto_servo_firmware/ and src/hal/drivers/pluto_step_firmware/ subdirectories contain the Verilog source code plus additional files used by Quartus for the FPGA firmwares. Altera's Quartus II software is required to rebuild the FPGA firmware. To rebuild the firmware from the .hdl and other source files, open the .qpf file and press CTRL-L. Then, recompile emc2. Like the HAL hardware driver, the FPGA firmware is licensed under the terms of the GNU General Public License. The gratis version of Quartus II runs only on Microsoft Windows, although there is apparently a paid version that runs on Linux. http://linuxcnc.org/docs/html/hal_drivers.html#r1_8_7 As described in the gpl version 2 faq, the use of a proprietary toolchain is not problematic in gpl2 software: Q: Can I release a program under the GPL which I developed using non-free tools? A: Which programs you used to edit the source code, or to compile it, or study it, or record it, usually makes no difference for issues concerning the licensing of that source code. However, if you link non-free libraries with the source code, that would be an issue you need to deal with. It does not preclude releasing the source code under the GPL, but if the libraries don't fit under the “system library” exception, you should affix an explicit notice giving permission to link your program with them. The FSF can give you advice on doing this. http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#NonFreeTools (pluto_step and pluto_servo do not use any "libraries", they just use the standard facilities of the verilog language) Jeff ------------------------------------------------------------------------- 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 Emc-developers< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: Controlling EMC from a non-GPL application

paul_c — 2008-11-22T19:39:10

Most, yes. But nowhere is there a list of which licences are involved or to which binaries they apply. Not a problem for a user (generally), but if anyone is redistributing this stuff, it should be - Without knowing what licences are used, how is anyone able to meet the Terms & Conditions ?? As has already been pointed out, there is one file (as an example) claiming to be GPL2, pluto_step_rbf.h - In it's self, an autogenerated file from pluto_step.rbf - The HDL sources are labelled as "GPL ver 2 or later".. Now, if Epler can provide the tools to generate the intermediate rbf file then the GPL T&C can be satisfied. You are probably correct which is why I recommended Les does an audit of any/all sources he wishes to use and/or distribute. ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Steve Stallings — 2008-11-22T16:22:37

Mario, Not quite, the code that Artsoft benefited from came from the version of EMC before EMC2. Also the closed source nature of their software and its rapid evolution have resulted in code that is significantly different from the EMC2 of today and which struggles to cope with the inevitable bugs because only a couple of people can work on the code. Steve Stallings ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Mario — 2008-11-22T14:31:32

So, that gives us the opportunity to *BRAG* about Artsoft MACH3 *BASED* on EMC2! Why not to use it in counterstrike? On Sat, Nov 22, 2008 at 3:07 PM, Ray Henry public.gmane.org> wrote: ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Eric H. Johnson — 2008-11-22T14:22:08

Ray, Adding on, halrmt is to halcmd as emcrsh is to emcsh and is described here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Halrmt Regards, Eric Adding the use of HAL messaging is another issue that may need a bit of legal clarification. My memory is foggy these days but I think that the intent of the LGPL licensing of the source that makes up halcmd was that it should allow a proprietary system to send properly formed, plain text commands to halcmd. Most of the functionality desired for SheetCam/EMC2 would not require direct HAL connections. Again Smithy uses a connection to Halcmd for a couple of signals. ------------------------------------------------------------------------- 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=/

Re: Controlling EMC from a non-GPL application

Ray Henry — 2008-11-22T14:07:31

There seems to be a deliberate lack of clarity with this whole proprietary v gpl/lgpl stuff in this thread. It's not that the developers are incorrect but more incomplete. You should consider this post to be my opinion and a near rant and you might want to stay away. On Sat, 2008-11-22 at 05:46 +0000, Chris Morley wrote: Yes they are and they connect both through NML and halcmd, which is a bit like dialing up your friends on a conference call and talking. Most of what is happening is exactly what the use of NML (Neutral Messaging Language) does for us. It allows multiple graphical interfaces -- as long as those interfaces use NML status structure calls rather than making assumptions about the state of EMC based on something done within that GUI. (AXIS did a bit of this early on as did Mini.) NML allows proprietary systems to develop NML messages and send and receive them in a system neutral way. There are two Tcl/Tk based extensions to Tcl's wish shell that connect between a Tcl/Tk based program and the NML channels. The original, written by FredP at NIST is emcsh. It is commonly run on a single computer with the rest of EMC2. The second is the remote system emcrsh that was written by EricJ and described in his documents at http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh I use emcsh for most all of my connections to NML and don't see any significant loss of computer ability because of the extra messaging. Even at 20-50 loops a second the cost is trivial and is all on the user side of things rather than the rtai side. Now if you prefer not to use Tcl/Tk, a similar library of NML message classes could be developed for other languages. In fact, a set of Java and/or C++ NML message classes can be autogenerated using a system maintained by WillS at NIST. If you prefer writing these classes in a pristine clean room way you could study the public domain code from EMC and write the additional codes that have been added to EMC2 to provide additional functionality

Re: Controlling EMC from a non-GPL application

Chris Morley — 2008-11-22T05:46:49

------------------------------------------------------------------------- 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 Emc-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: Controlling EMC from a non-GPL application

Chris Morley — 2008-11-22T05:29:07

Re: Controlling EMC from a non-GPL application

Dave Engvall — 2008-11-22T05:03:34