test message
Locked
12
12
|
> Why do people use silicon from such a sleazy company then? It seems that
> Microchip is willfully violating the GPL if they have somehow time limited > the optimization in GCC... There are much more 'GPL friendly' cores in > existence such as the Cortex-M3 from ARM that can be sourced from just > about > anywhere and have no such limitations in the compilers. As I mentioned before, I started the project wanting to use an Atmel AT91SAM7XC chip. No stock. Then I looked at a Luminary Cortex-M3 chip. I checked availability, also no stock. 26 week lead time. Then I looked at PIC32, and they were in stock. We have a winner! It's that simple. That was about 2 years ago. Things have improved since then, but I was forced down the PIC32 path, so I'm in it to win it. > I would personally be hesitant to work with a company that so flagrantly > violates the GPL... I doubt Microchip violates the GPL, they can afford legions of lawyers to tell them where the loopholes are. I think one reason Microchip makes you pay for their optimizer is if you don't, then you may have to buy a chip with larger memory. So, pay for the optimizer, or (maybe) pay more for the chip with larger memory. I'm not here to defend Microchip though. I've mentioned to their FAE's that they really need to stop charging for the tools. I've beaten them up about it on more than one occasion at their developer's seminars. If efforts of folks on this list lead to a FOSS tool set for the PIC32, that would be awesome. -- Best regards, Ivan Baggett _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Mike Panetta
Hey Mike! Nice to have you back around here :)
On Thu, Feb 24, 2011 at 1:18 AM, Mike Panetta <[hidden email]> wrote: > Why do people use silicon from such a sleazy company then? It seems that > Microchip is willfully violating the GPL if they have somehow time limited > the optimization in GCC... There are much more 'GPL friendly' cores in > existence such as the Cortex-M3 from ARM that can be sourced from just about > anywhere and have no such limitations in the compilers. I doubt it actually violates GPL. I won't pretend for a second that I understand the full implications of GPL but I believe Microchip has a strong legal department :) There are a few good reasons people use Microchip silicon, mostly the outstanding chip support package they have. You can find there full features libraries for networking (Eth+WiFi+CryptoSockets), touch sensors, radio transceivers protocols, file systems, USB devices (and ocasionally drivers) ... All free as long as you use them with Microchip products. Real life projects are generally drived by needs, not open source philosophy :) That said, in the particular case of PIC32 their attitude is indeed very peculiar. ARM is kicking major ass in the 32-bit MCU market. Obviously full toolchains are available for free. Virtually all companies that sell ARM based 32-bit MCUs offer chip support libraries with very "light" licensing policies. And yet ... http://www.appliancemagazine.com/news.php?article=1462614&zone=0&first=1 We're obviously missing something here. Probably the market aspect. Microchip has a very long (and good) history in the MCU market, ARM does not (yet). I am sure this will change, but it will take some more time. Until they do change I don't expect any change of policy on Microchip's side. > Also, even though you can 'externalize' the libs from microchip, would not > the mixed licenses of the compiled code be in violation somewhere? I am not > sure what licenses the eLua code is under at the moment (I think at one > point it was GPL/LGPL, is it now BSD?) MIT with some BSD from external libraries that we're using (most notably uIP). > but some of these licenses control > how the binaries can be distributed in addition to the source. Just linking > the proprietary Microchip code with eLua could violate a license and make > the binary itself undistributable... I'm not sure if this is the case; if it is though, no problem, we simply will not distribute the binaries. Best, Bogdan > > Mike > > On Wed, Feb 23, 2011 at 11:54 AM, Tim michals <[hidden email]> wrote: >> >> This is the route I went down and here is what I found: >> >> 1. The include files for the processor, i.e. the register mapping. >> According to the license agreement no files can be copied or modified. >> - Created a new register mapping include files using a simple address >> approach instead using linker adjust locations. One Include file has defines >> for each PIC32. Used the data sheets etc. to get mappings and addresses. >> - Since the Include file is changed, all peripheral library cannot be >> used. >> - Also, Microchips GCC has special commands built in for Fuse Bits, how >> interrupts are mapped. The standard GCC doe support ISR mapping, but it is a >> little different. So, worked on a simple ASM vector map file to help linker >> with the table. >> >> 2. Library startup, i.e. mapping flash speeds etc. >> >> 3. Flag bits in flash for setting up speed >> >> 4. New boot loader >> - There is a large chunk of flash space taken to support there jtag >> tools, since I'm not using these tools, no need to have support. What I'm >> talking about is MIPS code to support a JTAG debugger. There is code to >> help get registers etc. This for Microchip is in Flash. >> - The boot loader would only be in the first 12K. Then the 512K is up to >> the app.. >> >> Basically any code for USB, configuration of peripherals, is all new. >> >> ________________________________ >> From: "King, Mike" <[hidden email]> >> To: eLua Users and Development List (www.eluaproject.net) >> Sent: Wed, February 23, 2011 10:14:23 AM >> Subject: Re: [eLua-dev] PIC32 port status? >> >> I realize I'm joining this conversation late but has anyone looked into >> using CodeSourcery's Sourcery G++ Lite Edition toolchain for the MIPS >> architecture? Could this be a solution to the Microchip PIC32 licensing >> problem? >> >> http://www.codesourcery.com/sgpp/lite/mips >> >> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is >> for the sole use of the intended recipient(s) and may contain information >> that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized >> review, use, disclosure or distribution is prohibited. >> If this communication has been transmitted from a U.S. location it may >> also contain data subject to the International Traffic in Arms Regulations >> or U.S. Export Administration Regulations and, if so, cannot be >> disseminated, distributed or copied to foreign nationals, residing in the >> U.S. or abroad, without the prior approval of the U.S. Department of State >> or appropriate export licensing authority. If you have received this >> communication in error, please notify the sender by reply e-mail and delete >> or destroy all copies of this e-mail message and/or any file attachment(s). >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Ivan Baggett
> I think one reason Microchip makes you pay for their optimizer is if you
> don't, then you may have to buy a chip with larger memory. So, pay for > the optimizer, or (maybe) pay more for the chip with larger memory. > I'm not here to defend Microchip though. I've mentioned to their FAE's > that they really need to stop charging for the tools. I've beaten them up > about it on more than one occasion at their developer's seminars. According to Dave Jones on The Amp Hour podcast, Dave has spoken with the CEO of Microchip and he said that there's internal forces within the company to have the tools division always make a profit. Also, if it didn't show a profit then it may get cut. To me, this seems shortsighted. > If efforts of folks on this list lead to a FOSS tool set for the PIC32, > that would be awesome. That would be nice but unlikely. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s). _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |