-
Note that 'propagate' and 'convey' are GPL lawyerisms with specific meanings defined in section 0 of the license. Essentially, that statement means that if you do not enable others to make or receive copies of that software licensed under the GPL, and you abide by the other parts of the license, you can do anything you want to the covered works.No, it is surprisingly simple: you need to provide the sources for that modification. For a binary patch, the patch itself does not suffice, but a disassembly of the affected code, explaining why and how the patch works, is probably sufficient.
Read again this GPL part to understand why I said it was not so simple: "You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force." Clear as mud, but the "do not convey" matters here.
It is the first one in the set of basic rights the GPL grants. Let's expand that paragraph (second paragraph in 2. Basic Permissions in GPL v3):- You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.
If you do not enable others to make or receive copies, and you otherwise abide by this license, you can do anything to the licensed work. - You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright.
You are not distributing modified works if you use it in your organization internally, or run the modified work on someone elses hardware/infrastructure, but other than not distributing the modified work and keeping it private for your use only, you cannot place additional restrictions on the GPL-covered parts. - Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
Those in your organization working with the modified works, or providing you the services to use the modified work, must agree that the work is your private copy, and cannot make copies of the work or your copyrighted material, other than for you.
Support header files (declarative headers) are traditionally considered not copyrightable, and in any case, the information is already published in the datasheets, so it is difficult to see how distributing the original or modified header files could be an enforceable copyright violation in Europe. (In USA, Oracle is trying to upset that, but if they succeed, the entire industry is in violation.)The interesting thing is exactly what you mean by "all the support stuff from Microchip".
I listed that: support header files for the MCUs, support and runtime libraries, and incidentally, the math library, at least for XC16. Logically, anything that Microchip did not have to release as GPL.
Support and runtime libraries: Not avr-libc and other libc-derivatives, as those are GPL.
Microchips hardware abstraction layer is theirs only, not covered by GPL, but I've never used that (and I have several Atmel AVR microcontrollers). I don't know the XC16 math library, but I don't see it as part of the GPL source dumps, so I assume it is Microchip proprietary.
So, in my opinion, the GPL'd toolchain suffices, especially for AVRs and ARMs and hobbyists, but you need to pay Microchip to use their hardware abstraction layer and XC16 math library, and other non-GPL-licensed stuff.Oh, and again, if anyone manages to build XC16 from source successfully and get a fully working compiler, please chime in. I'll be interested!
I don't have any PIC microcontrollers, so I have no need for it, but I pulled the XC16 v1.41 sources, and took a gander. It isn't nearly as bad as some router firmware trees I've seen.
It is an interestingly deceptive tree, though. src/acme/ tree is used for binutils (ar, strip, bin2hex, objdump, ld, and as), and contains really odd stuff, like an old gnu toolset for 68k-based Macs. src/XC_GCC/ is used for gcc (gcc, cc1, and cpp), but for some reason, src/XC_GCC/ contains lots of other stuff, like binutils and Parma Polyhedra Library, and gmp, zlib, libelf, expat, cloog are built by default! The binutils version used is particularly ancient, whereas the one in src/XC_GCC/binutils is almost a decade younger. Both binutils are extensively modified. I wonder what the hell it needs the Parma Polyhedra Library 0.10.2 and The Chunky Loop Generator for?
I could find the proper source trees, isolate the patches applied, and write a short README on how to rebuild the ar, strip, bin2hex, objdump, ld, as, gcc, cc1, and cpp binaries for cross-compiling to the arches XC16 supports, which should produce the same binaries as the official XC16-v1.41; but I would have no way of testing or comparing actual binaries generated to the official XC16-v1.41.
Interested? - You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.
-
Note that 'propagate' and 'convey' are GPL lawyerisms with specific meanings defined in section 0 of the license. Essentially, that statement means that if you do not enable others to make or receive copies of that software licensed under the GPL, and you abide by the other parts of the license, you can do anything you want to the covered works.
You may be more familiar with all the quirks with GPL than I am. The first part ("You may make, run and propagate covered works that you do not convey") seems to be simple enough and would mean that you can modify whatever you want of the software as long as you don't convey it modified. So, that would include patching binaries or anything else, as long as, for instance, you keep it to yourself (such as would be the case if you patch binaries and don't share the result). But the second part, "without conditions so long as your license otherwise remains in force" makes it all clear as mud. What does it mean to otherwise remain in force, as long as you don't "convey" the modified software, as pretty much all the rest of the license applies to conveyed work as far as I've gotten it? Argh.
Anyway... it's probably all clear.
What I was saying earlier though, is that if, OTOH, you patch the binaries (which is considered a modification, or covered work), share them (or just share the patch or method for patching) without sharing matching source code (which you could not, as patched binaries can't possibly be the result of a build from source code, but that's probably an interesting borderline case), then you'd be violating not Microchip's license, but the GPL!
In fact, the reasoning, contrary to what some may think, is that the XC16 software (probably applies to XC32 as well) is under the GPL, as is, containing the license checker (whereas I think some would think that the added license checker is a violation of the GPL, which could be a tricky question to handle). So removing the license checker in any way constitutes a covered work! (But if it's a conditional compilation as I seem to remember, then it could be argued that it's just a variant of the build, and building this variant IS NOT covered work. Interesting thought...
Support and runtime libraries: Not avr-libc and other libc-derivatives, as those are GPL.
I was talking explicitely about non-GPL Microchip stuff, using the PIC16/XC16 compiler as an example. Read the license agreement for XC16 to see what it says.So, in my opinion, the GPL'd toolchain suffices, especially for AVRs and ARMs and hobbyists, but you need to pay Microchip to use their hardware abstraction layer and XC16 math library, and other non-GPL-licensed stuff.
I don't know much about AVR. I was really explicitely talking about the PIC16 and PIC32 lines and the corresponding compilers. Try using them without anything from Microchip. They explicitely cover the "run-time components", that's not just additional "peripheral libraries" or the like. Even the start-up code is likely included. Good luck writing your own. As to the header files, I'm really surprised that couldn't be copyrighted. Weird. All I know for sure is that for years (and even now?), the mingw stuff for Windows was certainly NOT authorized to distribute Windows' SDK headers, which would fall into a similar category? (Oh you're probably going to explain how that subtly is completely different. Dunno.) Even if all the info is in datasheets, I have a hard time understanding how source code deriving from them could not be copyrighted? (That doesn't make much sense to me.) After all, you could derive almost any source code from datasheets and reference manuals.
Reading the XC16 license more closely, it seems that the "run-time components" they cover is only related to the math lib actually: "“Run-Time Components” means components of the libm Math Library,", so I guess in effect you could use everything else.
I opened a random header file for some PIC MCU. There is a clear Copyright mention in it. There is also a mention dealing with redistributing:Quote* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
* 3. Microchip's name may not be used to endorse or promote products
* derived from this software without specific prior written
* permission.
So as long as you keep the copyright notice in the files (which you may think can't apply, but I'm still not sure about that, and frankly that would be completely unfair to remove the mentions anyway), you should indeed be able to redistribute them freely...
Edit: Point 3. is to be considered closely though. If you ever distribute your own compiler for Microchip MCUs, you can't use Microchip name if I understand correctly, without their prior consent, which they would never give you. So you better find a creative way of naming your compiler without mentioning Microchip.
I could find the proper source trees, isolate the patches applied, and write a short README on how to rebuild the ar, strip, bin2hex, objdump, ld, as, gcc, cc1, and cpp binaries for cross-compiling to the arches XC16 supports, which should produce the same binaries as the official XC16-v1.41; but I would have no way of testing or comparing actual binaries generated to the official XC16-v1.41.
Interested?
Well, do not waste too much time on this... but if you have some to spare, why not. If you succeed without pulling your hair out and in a reasonable time frame, sure, have at it! 'AFAIR, I think I managed to eventually build XC16 (an earlier version), spending a sizeable amount of time, but then the resulting compiler was failing to produce working object files, and I didn't feel like investigating that much further...)
And since we are dissecting Microchip's licenses, and apparently it should even be possible to distribute our own binaries, along with all Microchip support files (as long as you keep the copyright notices, as said above, I would not risk removing them and wouldn't see the point), except libm (which should not be too hard to replace), it'd be interesting to package the whole thing and distribute it (along, of course, with the source code, possibly modified to remove the license checker, although it may just be a matter of a conditional compilation!). And then see how Microchip reacts...
Edit: as added above, consider point 3. of the above. If you ever use the Microchip name in anything related to the compiler you built, they may sue you. If you use the "PIC" name, maybe also, as it's probably a trademark? Probably true for "XC16" as well? So good luck finding a creative name and description for all that...
-
What does it mean to otherwise remain in force, as long as you don't "convey" the modified software, as pretty much all the rest of the license applies to conveyed work as far as I've gotten it? Argh.
It's the other way around: if you do not 'convey', you can do anything that copyright law would otherwise prohibit, unless you have broken the license terms.if you patch the binaries without sharing matching source code then you'd be violating not Microchip's license, but the GPL!
True, but GPL says that the source code for a work means the preferred form of the work for making modifications to it. Not all modifications are possible at the source level, due to compiler or linker limitations. In this case, recompiling the work is obviously unfeasible, so a binary modification (again, explaining what and why is being modified, say describing how the modification works at the disassembly level), is adequate for "preferred form".In fact, the reasoning, contrary to what some may think, is that the XC16 software (probably applies to XC32 as well) is under the GPL, as is, containing the license checker (whereas I think some would think that the added license checker is a violation of the GPL, which could be a tricky question to handle). So removing the license checker in any way constitutes a covered work! (But if it's a conditional compilation as I seem to remember, then it could be argued that it's just a variant of the build, and building this variant IS NOT covered work.
The license checker is part of the GPL-licensed sources for XC16: in src/XC_GCC/gcc/gcc/config/pic30/pic30.c:get_license(), with an explicit GPL license at the beginning of the file.
Replacing that function with static int get_license(void) { return 6; } is completely allowed by the GPL. For the equivalent binary patch, disassembly of the affected ELF object, and showing that the binary patch indeed does that, would be sufficient to fulfill the GPL "source" requirement I believe, given that the original sources are publicly available.I was talking explicitely about non-GPL Microchip stuff, using the PIC16/XC16 compiler as an example.
Ok; I missed that. Note that I haven't used XC16, so I do not know what comes with it. I've used gcc-avr for AVRs (ATmega32u4, ATtiny85, AT90USB1286), and for those, GPL'd stuff and datasheet suffices. (And GCC for various flavours of ARM also, but again with FOSS libraries and toolchains only.)As to the header files, I'm really surprised that couldn't be copyrighted.
Declarative parts -- macros and interfaces, like structure and function declarations -- cannot, because they have no originality: there is only one way to define them (and work as expected).
Put more clearly, the files themselves are indeed copyrighted, but you can take the declarative parts, and provide the same interface declarations in your own header files, and not infringe. Say, mingw-w64-headers replacing the Windows SDK header files, for example. Even when the contents declare the same facts, it is not infringing on copyrights either way.I have a hard time understanding how source code deriving from datasheets could not be copyrighted?
Things like definitions on how hardware is accessed, for example how to set a GPIO pin as input, enable pullups, or set a specific SPI clock rate, are non-original, as there is usually only one way to do it (and work as expected), and that way is obvious to a skilled programmer.
As an example, the two typical ways of swapping two values (the temporary variable method, and the XOR method interpreting the data as unsigned integers), are not copyrightable, because they are too obvious. There is nothing protectable in these two methods.
Proper microcontroller bootup sequence may or may not be copyrightable, depending on whether it can be done in multiple ways. If the public datasheets describe a specific procedure, changing variable names in a straightforward state machine implementing that procedure may be enough to avoid being considered infringing.After all, you could derive almost any source code from datasheets and reference manuals.
No, because there are multiple ways to implement non-obvious, creative tasks.
Remember, copyright does not protect everything; only creative content. (Databases and such have a slightly different set of rules; there the aggregate tends to be copyrightable if it has taken effort to collate the data, but individual facts can be copied without violating the database copyright.)AFAIR, I think I managed to eventually build XC16 (an earlier version), spending a sizeable amount of time, but then the resulting compiler was failing to produce working object files, and I didn't feel like investigating that much further...)
It is obvious that to build the toolchain, one needs to define certain macros (related to licenses and such) at compile time to make it build. The values of those can be obtained by examining the (GPL-licensed) binaries, and doing that (no matter what "magic" meaning they might have to Microchip) is not a license violation. Even the "source tree" is a complete mess, and contains tons of stuff not actually needed for the toolchain.
It would not be complicated, just take some time and care, to sort out the source trees. But, to be honest, I think someone with more experience porting GCC to new architectures, could probably port XC16 to a newer GCC version with a similar amount of effort, since XC16 really only adds one new machine description, pic30. Some of the binutil changes look odd/unnecessary, so it might make sense to drop XC16 object file compatibility, to keep the changes to a simple, sane set.And then see how Microchip reacts...
The sad fact is, if someone with deep pockets gets annoyed at you, they can do a lot of damage even if they are wrong and you right.
If someone ported the PIC/XC support to upstream GCC properly, I think only the software licensing department at Microchip would be annoyed, and the rest of the company (including higher ups) quite happy. They are having big issues porting their modified gcc-derivatives to 64-bit architectures, for example; getting that for free would save a lot of money. All they really had to do at that point would be to adopt the upstream toolchain as-is, and continue with their current licensing scheme. -
As to the header files, I'm really surprised that couldn't be copyrighted.
Declarative parts -- macros and interfaces, like structure and function declarations -- cannot, because they have no originality: there is only one way to define them (and work as expected).
I don't quite agree with that, but I see the point.
There are actually several ways of writing support headers, not just one. For instance, you may declare all your registers as bit fields, or as bit masks only. You may also add additional utility macros.
You may add more structure to your definitions, or use a very "flat" way of defining things. There are definitely many ways of writing them. Give a datasheet to any developer without prior work with the MCU and without any specific coding rules, and you'll get very different results! You may still consider that the differences would be "uninteresting" enough not to qualify for original work, but it's very subjective IMO.
So I don't agree that it's not original work (especially if you're the first author of a given support header), obviously a mere copy of an existing one with just minor changes could not be copyrighted! But hey, you did a good job at defending that.
You also said that people can put copyright mentions on those, but that those mentions basically mean squat. I likewise don't agree. You said the files are copyrighted but not their content, basically? Which would mean what? That the only copyrighted part is actually the copyright mention?
Anyway, I disagree with this, and if it has been already decided legally, well, too bad for me, I still disagree.
-
Well, when the chip makers start to charge $5k per license the quality of their IDEs would certainly be better. There are IDEs which work that way - Keil, IAR, etc. But the people always complain "they make $$ with silicon, why to pay them for IDEs.."[/url]
Ugh, You couldn't pay me to use Keil or IAR. Give me a good text editor (vim or Sublime Text or even VS Code), a Makefile and some way to debug it. That could be gdb or even Segger's Ozone. Trying to roll everything into one "try to be smart", autocompleting nightmare always ends in failure.
Keil doesn't get customers because they're particularly good; they get money because they've convinced lots of chip vendors to give them a soapbox to advertise, and purchase decisions for toolsets at big companies often comes from people who never have to use them. The FAE often just needs to shmooze the manager and push the tool. -
Well, when the chip makers start to charge $5k per license the quality of their IDEs would certainly be better. There are IDEs which work that way - Keil, IAR, etc. But the people always complain "they make $$ with silicon, why to pay them for IDEs.."[/url]
Ugh, You couldn't pay me to use Keil or IAR. Give me a good text editor (vim or Sublime Text or even VS Code), a Makefile and some way to debug it. That could be gdb or even Segger's Ozone. Trying to roll everything into one "try to be smart", autocompleting nightmare always ends in failure.
Keil doesn't get customers because they're particularly good; they get money because they've convinced lots of chip vendors to give them a soapbox to advertise, and purchase decisions for toolsets at big companies often comes from people who never have to use them. The FAE often just needs to shmooze the manager and push the tool.
Not had any major snags with Keil in the 7-8 years I've been using it. The editor is perfectly useable (though not the best), the build manager is comprehensive enough for most projects and it just works. -
Pics have a lot of other tolls free and paid, And some are very good, You don't need to relly on Mplab
-
I don't quite agree with that, but I see the point.
I probably communicate the concepts wrong; I'm much better at concrete examples than lawyer talk.There are actually several ways of writing support headers, not just one. For instance, you may declare all your registers as bit fields, or as bit masks only.
Yes, and while the whole header file is protected by copyright (you cannot redistribute it unless you have a license), you can copy the facts it declares, and not infringe, because those facts are typically not "protectable elements".
I am trying to describe the filtration step in abstraction-filtration-comparison test, essentially. While the entire test is not endorsed by all courts in Europe, the filtration part basically is. In particular, quoting from the Wikipedia page, the concept of "hardware specifications, interoperability and compatibility requirements, design standards, demands of the market being served, and standard programming techniques" in software being typically not protectable by copyright.
The fair use doctrine in the USA differs a lot from the exceptions to copyrights in Europe, and I'm not familiar with those.So I don't agree that it's not original work (especially if you're the first author of a given support header), obviously a mere copy of an existing one with just minor changes could not be copyrighted!
No, I wasn't trying to claim that. Me fail English, I believe.
I meant that the declarative facts (macro values, structures, function and variable declarations) are not protected, and that copying/transcribing them into another header file is not copyright infringement, due to the reasons I listed.
Just copying the set of header files as-is is copyright infringement (because you infringe the copyright of the collection); copying a single file depends on why it was copied (if necessary for interoperability with something, it would not be infringing in Europe); and copying the declarative facts to your own header files is not infringing.
I guess the tricky bit is to understand how copyrights apply to works, like nested sets of boxes. Each box as-is is protected by a specific license, but the licenses of its contents can differ; and some contents may not be protectable by copyright at all, if they are obvious/non-creative/etc. enough. Each box needs a sticker describing its license if not compatible with the one it is in (and the outer box license must allow that), and the outermost one needs to list only the minimal set of compatible licenses.
For example, in a simple software project licensed under GPL-3.0, you might have individual files licensed under say CC-0 and modified/three-clause BSD license. These might have a license declaration at the beginning of the file, say // SPDX-License: CC0-1.0 and // SPDX-License: BSD-3-Clause, with the license texts in LICENSE.CC0-1.0 and LICENSE.BSD-3-Clause in the root directory; or they might not. Because the license compatibility, only the GPL is needed to allow distribution of that project. This is particularly important with multiple-licensed code: those extra licenses do not need to be mentioned, as they are not needed for this project; but it does not invalidate those other licenses. You can pick out a box, and if you find it has or should have a different license sticker on it, you can reuse that particular box with that different license, even if you picked it out of a box that had a different license sticker on it.
If the arrangement of the contents of a box is "original" (in the copyright law sense), then that arrangement is protected by the license chosen by the copyright holder of that arrangement. The definition of "original" is lawyer-speak, and varies a bit in different copyright jurisdictions and copyright domains.
It is important to realize that copyleft licenses, like the GPL, contain language that allows labeling a box with a GPL license only if all the contents are GPL-licensed, or licensed under a compatible license. You cannot stick a box with a proprietary license inside a GPL box; it is not allowed by the license. You also cannot add any kind of limitations or requirements on top of the GPL.
GPL does allow you to include such GPL'd boxes in "compilation" boxes or sets, with other boxes licensed under different licenses, if the boxes are "not linked" together. If you slap a license on such a compilation box, the license only applies to that arrangement, and not to the contained boxes. For example, if you create a DVD with those software packages in it, your copyright extends only to that exact arrangement (plus whatever your own boxes, like artwork you add on top, you might add). If someone takes your DVD, removes your own boxes or changes the arrangement, and distributes the derivative, they are not infringing on your copyrights on the compilation, because they created a new one.
(At this point, however, it is important to note that database stuff has other provisions. If the collection can be/is treated as a database, then different rules apply.)
In the XC16 case, the outermost box is the MPLAB XC16 Compiler. I'm not exactly sure which license it is distributed under, as I haven't run the installer, and cannot see the license described in the release notes. It contains both proprietary and GPL-licensed parts. The license check is not proprietary, it is GPL'd, because it is provided by Microchip in a file that declares itself to be GPL-licensed in a project that declares itself to be GPL-licensed. To see if the user has a license, the code uses a command-line interface, executing a binary at a specific location, whose return value declares the user reference; this is an "interface", and traditionally breaks "derivativeness". That external binary is not GPL'd, but replacing it with another binary that returns a fixed value, or modifying the compiler (under GPL) to never execute any external license checkers, is not prohibited by the GPL license, and does not violate the copyrights related to that external binary.
The ARM GNU Toolchain provided by Microchip (and the upstream GNU ARM Embedded Toolchain) provides the compiler (gcc), linker and debugger (binutils-gdb), and the basic C headers and libraries (newlib), all licensed under GPL.
The AVR 8-bit Toolchain provides the compiler (gcc), linker and debugger (binutils-gdb), and the basic C headers and libraries (avr-libc), all licensed under the GPL.
The XC16 sources provide only the toolchain binaries (all licensed under the GPL), and none of the headers and libraries. I was rather surprised by this, as I haven't used PICs or the XC compilers at all, and expected them to be more in line with the ARM and AVR toolchains I'm more familiar with. As I haven't installed the XC16, I do not know what headers and libraries it provides; I only know what the sources provide.You also said [...]
Me fail English, if you got that impression.
Perhaps the above analogue of wrapping boxes with license paper, and putting and arranging them inside each other, makes more sense? -
Alright, I get it better. Just a note then: copying support "header files" verbatim is probably infringing on copyright. Now writing similar files with a similar content is OK (and that part I can only fully be content with). The key here is that of course, it's much easier and tempting to just copy them verbatim... People are lazy beasts.
Anyway, the interesting fact we saw with Microchip is that they explicitely authorize the copy and redistribution (as long as you keep the copyright notices), so this is pretty liberal I think.
And then, as far as distributing a complete compiler for Microchip MCUs, it seems Microchip could not do much of anything because they actually allow what's needed for that, either because they allow redistributing their own files (except for libm for XC16), or because the rest is GPL. So I don't think they could sue you if you did that. (As long again as you are careful not to infringe on any trademark!)
-
Just a note then: copying support "header files" verbatim is probably infringing on copyright. Now writing similar files with a similar content is OK (and that part I can only fully be content with).
Yes, exactly. It really didn't even occur to me at first to think about verbatim copying. I was thinking about the actual situation, when one has to provide the facts like register addresses, bit labels and masks, and so on; and how their similarity, even if obtained from copyright-protected sources, is not copyright infringement.
If you look at e.g. avr-libc, say the avr/iom32u4.h header file, that defines registers and pins for ATmega32u4 microcontrollers, it is clearly labeled (C) 2008 Atmel Corporation, but incorporated in a project licensed with a very permissive license (not GPL as I thought, but a permissive GPL-compatible BSD license) maintained by non-Atmel/Microchip folks.
The contents of that file is pretty much what I mean by "declarative", too.
That avr/iom32u4.h file is definitely copyrighted by Atmel, but none of the individual facts in there are protectable. So, if you use the information in that file, and create a file that ends up defining the same macros (we could argue about macro names, although my point would be they match the public documentation elsewhere and are therefore obvious/non-creative/non-protectable), the similarity and even proven derivation between the two would not constitute a copyright infringement in Europe, because of the reasons I outlined in my earlier posts.Anyway, the interesting fact we saw with Microchip is that they explicitely authorize the copy and redistribution (as long as you keep the copyright notices), so this is pretty liberal I think.
I find this typical and expected. I mean, even if a library or component is proprietary and licensed under a very strict license, its interface (declarative headers) are usually very permissive, for practical reasons. The most important one is that compiling source that uses those headers creates a "combined work". Unless you have a permissive license to use the headers in your own binaries, you do not actually hold the sole copyrights to the ensuing binaries. So, if one is careful, one will not use libraries with headers without permissive licensing.
Redistribution of the headers is often allowed in source form, even when the licensing of the associated libraries etc. is strict, because there is nothing really valuable in the headers, and it makes users' life much easier (consider backups, long-term maintenance of the code base, and so on).
Much of the software copyright exceptions in Europe, and a lot of the filtration part in the abstraction-filtration-comparison test (as used in the USA in particular), arise from the fact that it would be counterproductive to everyone to allow such declarative parts without any creative effort to become essentially stealth copyright violation mines.as far as distributing a complete compiler for Microchip MCUs, it seems Microchip could not do much of anything because they actually allow what's needed for that, either because they allow redistributing their own files (except for libm for XC16), or because the rest is GPL. So I don't think they could sue you if you did that. (As long again as you are careful not to infringe on any trademark!)
Agreed (except that they can sue for anything; they would just be very unlikely to succeed).
The reason why I responded to you initially was to "prove" the following; which I believed you disagreed with:
You can modify the XC16 compiler to ignore the license checks, as long as you comply with the GPL.
Now, because the GPL only requires one to provide the sources to those you provide the binaries to (as one option), providing a binary patch to a GPL'd binary becomes a violation only when you refuse to disclose the source to someone who got the binary patch from you. (Such a patch would modify the binary code generated by src/XC_GCC/gcc/gcc/config/pic32/mchp.c and src/XC_GCC/gcc/gcc/config/pic30/pic30.c , stubbing out certain function calls entirely with them just returning fixed values, so it would be simple to provide the functional source changes (that would generate functionally equivalent binaries when compiled) and the effective changes the binary modifications do, in a manner that definitely fulfills GPL.)
So, even in the extremely unlikely case that Microchip would accuse someone for GPL violation due to binary-patching the compiler to avoid license checks (and that is the only violation they could accuse anyone, since the license check code in gcc/cc1 is GPL'd), they could only sue those that provided Microchip with the binary patch and refused to provide the sources for it.
No reason for anyone to refuse, though. Just take a loot at Github for the two relevant files (XC 1.23), zeha:xc16/src/src/XC_GCC/gcc/gcc/config/pic32/mchp.c and zeha:xc16/src/src/XC_GCC/gcc/gcc/config/pic30/pic30.c, and look for get_license for starters, and you'll see how simple the affected code is.
(You'll also see that most of the code there involves the license checks, and if one were to rip all that crap out, it would be quite simple. Which is why I said that anyone experienced in porting gcc to new architectures would probably port pic30 support from XC16 to current gcc without much more effort.) -
.
-
Which is why I said that anyone experienced in porting gcc to new architectures would probably port pic30 support from XC16 to current gcc without much more effort.)
For that I think you're dreaming a bit. From what I've gathered, their PIC back-end is a mess. Keep in mind it's 16-bit, which has also become harder to target with recent versions of GCC anyway. Without much effort is a wild dream, that's almost a guarantee. Microchip themselves have a hard time enough adapting it to more recent versions of GCC (they still use a pretty old one). Again there's also a reason why the PIC back-end never got integrated to the official GCC source code. I haven't discussed that with any GCC maintainer, but I'm almost certain it looks like a dead cause.
Since you seem more optimistic, don't hesitate to have at it.
-
From what I've gathered, their PIC back-end is a mess. Keep in mind it's 16-bit, which has also become harder to target with recent versions of GCC anyway.
True, but I believe the biggest problem is retaining object file compatibility with older tools. I'm talking about a from-scratch re-port.
Granted, I know very little about PICs, and nearly nothing about PIC30/dsPIC (XC16 targets), but there are other 16-bit targets still supported, like cr16, m32c, and msp430.Since you seem more optimistic, don't hesitate to have at it.
Perhaps I'm overly optimistic, but in my experience, rewriting a solution avoiding the known issues is often orders of magnitude easier than just fixing and plating over the problems in existing low-quality code. The XC16 sources are crap -- not the worst stuff I've seen peddled as an SDK, but nothing I would agree to maintain --, simply a dump of stuff that pukes out a couple of binaries, if you're lucky and tickle it just right.
Compare to cr16, m32c, or msp430. The support is relatively clean; certainly something you can work with. I don't know how difficult it would be to port the assembler to current binutils' gas, but support for cr16, m32c, or msp430 do also seem pretty clean.
My intuition says the problems Microchip is having, is due to trying to build on top of old crap and requiring continuous backwards compatibility, instead of admitting their old toolchain is crap, and rewriting it. -
Thanks to those who provided the on-topic comments
Well MLPAB Xv5.30 is out now and although Microchip support say it should have fixed my last bug, as is always the case there seems to be a new bug and IPE will no longer talk to my PM3 programmer!
Still, in light of the comments here I'm not convinced that changing to a different brand of processors will be worth the effort: not only would we need to learn a new IDE/toolchain but also change our production programming equipment and the production programming procedures used at our client's facility. Ultimately I feel like this is a case of "the devil you know"... -
Quote
All vendor tools are horrible.
I'm inclined to agree. Worse, they're all DIFFERENT from each other. When I have something serious to do, it's back to EMACS and CLI tools...
I've recently been using MPLABX for AVR development, where at least the presence of bugs is somewhat understandable. (Although "that new feature we claimed is working in 5.30 doesn't actually work because we forgot to package up the device programmer firmware too" is pretty weak.) I always assumed that the actual PIC support was much better, and I'm sad to hear that perhaps it's not. :-(
So... Are the various IDEs (Eclipse, CodeBlocks, NetBeans, etc) all actually horrible, or do the vendors MAKE them horrible with their "customizations"?
-
I'm not convinced that changing to a different brand of processors will be worth the effort
I think you might well find that it is worth your time. The official PIC tool chain has had poor speed and reliability for about as long as I can remember now, and it's not even as though there are clear and obvious signs it's improving.
Whenever I work on an STM32 project (using CrossWorks), there are some clear highlights that make my day a whole lot more enjoyable and productive...
- downloading new code via an ST-Link V2 cable takes a fraction of the time
- if it doesn't work - which is rare - unplugging and reinserting the USB cable gets it working 99% of the time, and takes seconds to do
- I can single step through code in the debugger as fast as I can press F10
- I can set breakpoints while the code is running, and they take effect immediately
- Watched variables are updated continuously in real time
The downside is that ST seem to be trying to go out of their way to make essential header files more and more difficult to find - but it's worth persevering. You need to generate a dummy project targeting your chosen CPU family using STM32 Cube (or whatever it's called this week), then search inside the project folder for the relevant .h files to put into your own project. It's a PITA the first time, but thereafter, not an issue.
Personally I don't use any of the ST peripheral libraries. I don't feel like they add any useful abstraction or portability, nor do they allow me to use peripherals without having already read and understood their register interfaces in detail.
For these reasons it does take longer to get a new STM32 project up and running - but once that's done, actually developing 'blinky' into a useful product is SO much quicker and easier I need a very good reason to use a PIC in the first place. -
I'm not convinced that changing to a different brand of processors will be worth the effort
I think you might well find that it is worth your time. The official PIC tool chain has had poor speed and reliability for about as long as I can remember now, and it's not even as though there are clear and obvious signs it's improving.
Whenever I work on an STM32 project (using CrossWorks), there are some clear highlights that make my day a whole lot more enjoyable and productive...
- downloading new code via an ST-Link V2 cable takes a fraction of the time
- if it doesn't work - which is rare - unplugging and reinserting the USB cable gets it working 99% of the time, and takes seconds to do
- I can single step through code in the debugger as fast as I can press F10
- I can set breakpoints while the code is running, and they take effect immediately
- Watched variables are updated continuously in real time
This!The downside is that ST seem to be trying to go out of their way to make essential header files more and more difficult to find - but it's worth persevering. You need to generate a dummy project targeting your chosen CPU family using STM32 Cube (or whatever it's called this week), then search inside the project folder for the relevant .h files to put into your own project. It's a PITA the first time, but thereafter, not an issue.
I was thinking the same but recently I discovered that STM keeps & maintains the header files (CMSIS) on github:
Now, when I start a new project, I use Git to (partly) pull the CMSIS header files.
https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Drivers/CMSIS
-
Personally I don't use any of the ST peripheral libraries. I don't feel like they add any useful abstraction or portability, nor do they allow me to use peripherals without having already read and understood their register interfaces in detail.
For these reasons it does take longer to get a new STM32 project up and running - but once that's done, actually developing 'blinky' into a useful product is SO much quicker and easier I need a very good reason to use a PIC in the first place.
Agreed 100%.
I just don't get this manufacturer or user group library fantasy held by so many here.
Many STM32 peripherals are so packed with features in silicon that the sheer number of config permutations means that a library to do every task would be massive, buggy and most options would never be used.
Sure it's going to take a designer *years* to master all the peripherals in a STM32, but that's what makes him/her valuable in the same way it made someone intimately familiar with the 6800 in the early 70's just as valuable.
In any event, the STM32F103 micro was announced in 2004, so no one has any excuse not to be intimately familiar with them.
... unless they spent that time using PICs or AVRs blissfuly ignorant that those devices were obsolete for new designs.
-
All hardware-oriented companies seem to have software as a 2nd class citizen with tiny teams.
For CPU companies it is perhaps not their primary goal since there are many IDE vendors out there,
that for businesses are preferable even at $3k a yr license costs as long as they got 24/7 support service.
But if you look at FPGA companies like Xylinx and Altera they sell their software for high prices and it is part of the business.
Then you have some CPU companies that do a hardwarelocked buy-in of one of the main IDE software tool vendors.
ST did this with Keil for their STM32F0 series and recently even bought a IDE software house to integrate in their products.
NXP had also some Xpresso buy in, but didn't follow that so do not know the current status.
So the main question is actually why the main IDE vendors do not sell their products for non profit hobbieists and students for a decent price or
even free. Like Autocad is doing with their Fusion360 product, it is free for students/hobbieists.
Firms like Keil and Iar should take an example and offer a <$75 a year or a one time <$250 fee for that target audience and their benefit is just like
autocad, the students learned how to use it and will continue to use it in their daytime jobs.
-
All hardware-oriented companies seem to have software as a 2nd class citizen with tiny teams.
This is not really true. Most hardware companies employ a lot of people to develop the software to support their devices, either directly, or through contracts to third parties. The real problems come from endless internal conflicts. A lot of silicon developers are really arrogant idiots who think nothing but silicon matters. Others think if they are making something it should be making them a profit. Others think that software is an essential loss leader to be able to sell their silicon, and need to be free. Others agree with the last group, but think that means its a waste of time putting more than minimal effort into it. This is why you see such inconsistent behaviour from hardware companies over time. It depends on the mindset of this week's person in the key decision making role. -
All hardware-oriented companies seem to have software as a 2nd class citizen with tiny teams.
This is not really true. Most hardware companies employ a lot of people to develop the software to support their devices, either directly, or through contracts to third parties. The real problems come from endless internal conflicts. A lot of silicon developers are really arrogant idiots who think nothing but silicon matters. Others think if they are making something it should be making them a profit. Others think that software is an essential loss leader to be able to sell their silicon, and need to be free. Others agree with the last group, but think that means its a waste of time putting more than minimal effort into it. This is why you see such inconsistent behaviour from hardware companies over time. It depends on the mindset of this week's person in the key decision making role.
Your story sounds so disorganised and typically human it is sure to be accurate! -
Don't forget uC manufacturers have only big businesses as target.
They think in selling millions instead of tens to small customers.
Look for instance at Renesas , they are in the top4 biggest players esp in car electronics and almost no hobbieist use them
-
Don't forget uC manufacturers have only big businesses as target.
A key thing most small scale users of MCUs fail to appreciate is that very few MCUs are designed to be general purpose. The mix of peripherals and memory each one has is tailored to the needs of a small handful of large customers, usually ones in very similar markets. All focus is on ensuring those customer's needs are adequately met. Additional sales into other applications is just a bonus.
They think in selling millions instead of tens to small customers.
Look for instance at Renesas , they are in the top4 biggest players esp in car electronics and almost no hobbieist use them -
I use text editor where I can.
I used to like IDEs, but the ones I came accross in the later years (e.g. MPLAB X, VS, Vivado, Eclipse) are overbloated, spongy, buggy and imposing. I simply cannot use them.
It's silly to blame vendors. The situation is the direct consequence of dominant programming paradigm (you know "don't reinvent the wheel" and that sort of things). Instead of working software, you just get a pile of assorted wheels which are kept together purely by magic and can come crashing on you any second. The developers hardly have any control of the creatures, so hoping that they ever be able to fix the majority of bugs is purely delusional.
-
It's silly to blame vendors. The situation is the direct consequence of dominant programming paradigm (you know "don't reinvent the wheel" and that sort of things). Instead of working software, you just get a pile of assorted wheels which are kept together purely by magic and can come crashing on you any second. The developers hardly have any control of the creatures, so hoping that they ever be able to fix the majority of bugs is purely delusional.
Quite right!
I don't completely agree with the fact the vendors are not to blame though - this still is their choice and their responsibility. But I admit it's become very hard to go against the wind when it comes to software development these days...
Like, a bunch of us may be very irritated that they almost all use Eclipse as their base IDE, but you'll also run into many users that absolutely WANT Eclipse, and since it's trendy... it's hard for a vendor to offer anything else.
So, the trend is to blame certainly, but the vendors have their part too, and lastly, the users as well!!