Microchip have dropped the ball. Is ST going to be any better? - Page 1
Forum section: electronics / general

author: Mangozac
author_rank: Frequent Contributor
timestamp: November 10, 2019, 03:59:51 am
content: Ever since Microchip started integrating the Atmel tools into MPLAB it's been bug after bug. They fix a bug and a new one gets introduced. I'm sick of wasting hours of my time not only getting to the bottom of it but then convincing the support staff that the bug exists and getting them to replicate it. Some of these bugs have been catastrophic - for example when importing hex files for a specific part the latter part of memory was offset by one byte! We've been loyal Microchip customers for many years but I feel like the next bug will be the final straw so we're looking at suitable alternatives to begin switching to for new projects.We use the full spectrum of Microchip parts, from 8 pin PIC12 right up to PIC24 and PIC32.STM8 and STM32 seem to be competitively priced and have a fairly wide range. Application support looks to be pretty rich with plenty of libraries available. There are free compilers and IDE available and programming/debugging tools are affordable.My main question is how buggy are the ST ecosystems? Is anybody experienced with using both Microchip and ST in a professional environment and can comment as to how similar or dissimilar the two brands are? Is it perhaps normal to have bugs in production programming tools from all vendors?Edit:It seems that I need to clarify that my usage of the word "tools" is primarily referring to the programming tools (MPLAB X IDE, IPE, PM3 and ICD). While compiler bugs do come up occasionally for us they have been pretty rare and usually there has been a simple workaround. On the whole I find the XC compilers pretty reliable.

author: OwO
author_rank: Super Contributor
timestamp: November 10, 2019, 04:10:43 am
content: If you think microchip tools are bad you have never tried ST. I avoid vendor tools whenever possible (FPGAs are the only exception) and always go with gcc + open source toolchains like libopencm3. Most hardware companies just CAN NOT design software competently, and just like you should never use the OS that come with a computer you shouldn't use the software that vendors supply for their microcontroller.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 04:13:54 am
content: ^ This. All vendor tools are horrible.

author: brucehoult
author_rank: Super Contributor
timestamp: November 10, 2019, 04:38:30 am
content: Quote from: ataradov on November 10, 2019, 04:13:54 amHave you left Microchip (Atmel)?

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 04:41:17 am
content: Quote from: brucehoult on November 10, 2019, 04:38:30 amNo. But I'm not a shill. I really think that those tools are horrible. My job is to help you with them, if you still chose to use them, and I will gladly do so, of course. I personally will never use them. I value my time and don't like tools that waste it.But I'm not going to tell people they are "holding it wrong".

author: Mangozac
author_rank: Frequent Contributor
timestamp: November 10, 2019, 04:47:08 am
content: Quote from: ataradov on November 10, 2019, 04:41:17 amSo what's your suggested alternative to the factory tools and PM3 programmer?

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 10, 2019, 04:48:02 am
content: Quote from: Mangozac on November 10, 2019, 03:59:51 amThat's odd. I'm not having any problem with MPLAB 8.92 or AVR Studio 4.18QuoteSo you have a lot of experience with PICs. Why throw it all away over a few bugs that you could easily avoid simply by not upgrading to the latest version of MPLAB?QuoteDon't know because I haven't upgraded in years. They used to be a bit buggy, but the main problem I had was the lack of good documentation and reliance on the HAL (hardware abstraction layer) to cover for it. Being used to interacting directly with the hardware in PICs I found this to be extremely frustrating.As for the hardware, I haven't done a survey of ST chips recently but I suspect Microchip has a broader range with wider application.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 04:50:27 am
content: Quote from: Mangozac on November 10, 2019, 04:47:08 amI don't use PICs, so I have no idea. I'm pretty well switched to ARM, for a bit part because of open ecosystem. We'll see if RISC-V ecosystem manages to beat that.I make my own tools. For programming I usehttps://github.com/ataradov/edbgwith either Atmel-ICE or any other CMSIS-DAP compliant debugger.For "IDE" - any text editor and Makefiles.

author: Mangozac
author_rank: Frequent Contributor
timestamp: November 10, 2019, 05:13:49 am
content: Quote from: Bruce Abbott on November 10, 2019, 04:48:02 amThat's really not a viable solution for a professional business. Even ignoring the fact that MPLAB8 no longer supports new parts, I could not justify the lost productivity of going back to such an ancient IDE.Quote from: Bruce Abbott on November 10, 2019, 04:48:02 amBecause if one wants support for the latest parts then there is no choice but to upgrade MPLAB. And of late it's a cyclical problem of upgrading to fix bugs that were introduced when we upgraded to fix bugs....

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 10, 2019, 05:20:15 am
content: Quote from: OwO on November 10, 2019, 04:10:43 amThat attitude is what created the current situation. Linux fanbois were pressuring Microchip into producing a version of MPLAB for their OS, and the only practical way to do that with a single codebase was to write it in Java. It's been downhill ever since...

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 10, 2019, 06:11:51 am
content: Quote from: Mangozac on November 10, 2019, 05:13:49 amDid you not see the smilee? All I am saying is it might pay to hold back a little on getting the latest parts, until the bugs (both software and hardware) are sorted out.BTW it's quite possible to use the latest compilers with these older IDEs, or even just run them from the command line (I do most of my coding in a text editor, no IDE required!).QuoteIf your IDE is increasing productivity then perhaps you should stick with it. Switching to a completely different MCU line will probably impact productivity a lot more than the problems you are having now.QuoteWhere are these bugs - in the IDE, the compiler, the device files? Microchip are constantly bringing out new parts, so it's not surprising a few might have bugs. But you don'thaveto use the latest parts.

author: techman-001
author_rank: Frequent Contributor
timestamp: November 10, 2019, 06:28:10 am
content: Quote from: Bruce Abbott on November 10, 2019, 05:20:15 amJava and Linux seems to have worked out for Google and Android ... just saying.

author: brucehoult
author_rank: Super Contributor
timestamp: November 10, 2019, 06:41:57 am
content: Quote from: ataradov on November 10, 2019, 04:41:17 amYes, fair enough.It's go to be tough on the PIC side. All hardware-oriented companies seem to have software as a 2nd class citizen with tiny teams. And no one else is going to help with PIC. AVR would be similar. And MIPS (PIC32) these days. But with the SAM stuff there are a ton of ARM licencees and users working on at least toolchain stuff. Supporting your own peripherals is a different matter, but much smaller.Since you mentioned RISC-V (in a later message) there is also the advantage of people at a lot of different companies and educational and research institutions working on things. At SiFive we have our own Eclipse-based IDE which I think is regarded as OK by people who like Eclipse -- I don't know as I'm allergic to Eclipse bloat.I think Ivan Kravets in Ukraine is doing good work with PlatformIO. I was quite impressed with it and how it makes a pretty nice lightweight IDE with VS Code when I followed along with the Western Digital CTO's videos ()When those videos were made some parts of PlatformIO cost money but SiFive and Western Digital have since sponsored Ivan so that it can be completely free for users of any CPU or board, not just RISC-V. I also saw recently Seeed Studio or maybe Sipeed have also sponsored PlatformIO.It claims to work with PIC32, AVR, and SAM, but not 8 bit PIC. Have you looked at it?

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 06:52:30 am
content: Quote from: brucehoult on November 10, 2019, 06:41:57 amNot interested. Seriously, I type faster than those atom-based things could handle. I don't understand how people can live with that much input lag.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 10, 2019, 07:18:16 am
content: Quote from: techman-001 on November 10, 2019, 06:28:10 amKotlin is now Google’s preferred language for Android app developmentQuoteIs the end of Java near?Quote

author: brucehoult
author_rank: Super Contributor
timestamp: November 10, 2019, 07:34:46 am
content: Quote from: ataradov on November 10, 2019, 06:52:30 amWeird.OK, so I can get VS Code up to about 80% CPU by holding down a key on autorepeat at 60 characters per second in the middle of a big file, or similarly holding down the up arrow or down arrow. So, sure, it's not super efficient.Emacs holding down a key on insert in the same C source file actually stabilises at over 99% CPU, and no one complains about emacs these days :-) Up or down arrow only gets it's to 7%.But anyway I don't type at 60 CPS.Just for completeness, vim gets up to 60% on the same insert chars test, running in a terminal. And gnome-terminal uses about 8% at the same time. (VS Code and emacs were running in their own GUI windows)So VS Code doesn't seem like an outlier.

author: Mangozac
author_rank: Frequent Contributor
timestamp: November 10, 2019, 08:02:04 am
content: Quote from: Bruce Abbott on November 10, 2019, 06:11:51 amI'm sorry, I took the smiley as smugness, so I apologise for being short with my response.We avoid using "bleeding edge" parts for this reason but the number of parts Microchip have on offer means that we have to keep programming tools relatively up to date. The cycle of bug fixes has gone on for so long now I wouldn't even know where to roll back to.Our issues of late aren't with the compilers but actually the programming tools and parts definitions. And I'm talking profeasional tools such as the PM3. Microchip screwing with and screwing up parts definitions for parts that are a decade old!Quote from: Bruce Abbott on November 10, 2019, 06:11:51 amThe problem occurs when it's time for debugging - I have no desire to do that without an IDE!Quote from: Bruce Abbott on November 10, 2019, 06:11:51 amSure, hence why it's a matter of weighing up whether learning a new line of parts and associated toolchain is likely to result in better productivity in the long term.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 10, 2019, 08:53:09 am
content: I worked for a large well-known chip maker, who provide compilers and debuggers for their hardware. Sad to say, the guys writing the tools didn't really know what they were doing. We were using the toolset for an internal project. The IDE was slow, buggy and used huge amounts of memory. Tbh, it was almost unusable. After several back and forth with the support team, they eventually admitted the data loss I saw with the "real time debugger" was a design flaw they couldn't fix. The project I worked on eventually was cancelled before launch.Unfortunately, bean counters like to choose devices based on unit cost, and "software" is just an NRE cost. If their vendor provides "free" software, that's a tick in the box but is a problem for Engineering dept anyway. It would be great to work for a company which picked the best software support, and then the device, but I've never worked for one that actually did that.

author: Karel
author_rank: Super Contributor
timestamp: November 10, 2019, 08:59:30 am
content: In our last project, I made the switch from PIC32 to STM32 and so far I'm happy with it andI don't want to go back to PIC32 anymore.https://www.eevblog.com/forum/microcontrollers/pic32mx-vs-stm32l4-my-first-impression/msg1717868/

author: iMo
author_rank: Super Contributor
timestamp: November 10, 2019, 09:00:53 am
content: 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..".FYI:Keil MDK pricelist:https://uk.farnell.com/arm-keil-mdk-armIAR Systems pricelist:http://www.mouser.com/catalog/catalogusd/645/2360.pdf

author: malagas_on_fire
author_rank: Frequent Contributor
timestamp: November 10, 2019, 11:27:01 am
content: Quote from: ataradov on November 10, 2019, 06:52:30 amVim and a makefile with ctags?

author: nctnico
author_rank: Super Contributor
timestamp: November 10, 2019, 12:22:20 pm
content: Quote from: ataradov on November 10, 2019, 04:13:54 amIndeed. It is not their core business and the fact Microchip has acquired the software company which made MPLAB doesn't help.However several other vendors are using Eclipse nowadays. Eclipse has been built to be a productive IDE from the ground up. For sure there is a learning curve (the way you can have multiple projects in one workspace) but every person I have introduced to Eclipse is still using it. Whether it is for C, C++, Python, PHP.

author: hans
author_rank: Super Contributor
timestamp: November 10, 2019, 12:40:04 pm
content: I used to tie together my own toolchain and use any stable GUI that can work with Makefiles and GDB. Recently I've switched to CLion, as I was already using it for my unit tests.Pros:- Stable IDE- Embedded project integration for STM32CubeMX definitions- A run/debug configuration tool that is actually usable, allowing to run multiple target definitions side-by-side- CMake/Makefiles is more powerful than the "integrated project tools" in many other IDEs- It's not tied to any chip vendor. I've been able to makePIC32 with GDB proxywork in it at some point. I think it's matter of time before RiscV is supported, or other cross-platform toolchains with GCC/GDB support is added (be it from Jetbrains or community plugins/support).Cons:- Works great with STM32, but needs a bit more work for other chip vendors.. (no project import, GDB/Openocd still supported though)- You need to write CMake files - just Makefiles is not supported- Haven't found an option to define 2 compilers within 1 CMake project - thus switching between x86/ARM toolchains & CMake projects is necessary- CLion/Jetbrains requires a powerful machine (I run a AMD R9 3900X and have got no complaints about the speed though)My firmware projects have the following folder structure:lib/ - 3rd party libraries/chip header filesopenocd/ - Openocd configurations, SVD definitions (RTL information), and some Python scripts that interface via the debug tool (pylink) for e.g. live memory monitorsprojects/ - Contains multiple c/cpp main() files where one is picked for a specific executable target, e.g. keeping testbenches for the hardware in separate filessrc/ - Files and protocol stacks for the actual projectsrc/bsp/*/boot/ - startup/linker code for a specific hardware platformtest/ - CLion x86 project for GoogleTest environment, and various utilities to run mixed-domain simulations (utilizing same codebase as found in src/)CMake-build-debug/ - contains elf/bin/hex/map/assembly listings, etc., not in version controlThis 1 tool does everything for me, from firmware debugging, unit tests up to desktop programs.CLion is free for me because of my work (academia), but I think otherwise it isn'tthatexpensive to buy for professional or personal use.

author: luiHS
author_rank: Frequent Contributor
timestamp: November 10, 2019, 12:41:15 pm
content: You can also try NXP ARM microcontrollers with their MCUXpresso development environment.I have been using the Kinetis for a while and now the RT1020, and in general they work well, and the MCUXpresso IDE has evolved very well, each time with more and better features.Sometimes I use ST STM32, but I prefer the NXP RT series and its MCUXpresso environment more and more. The NXP-based SDK system seems very successful. Something I really like about MCUXpresso is the direct import of sample sources from the SDK, that in the ST environment is more complicated, there is no option for direct access to the sample sources.Also the NXP RT microcontrollers are cheaper than the ST H7 series.As for Microchip PIC microcontrollers, I never liked them, although I used PIC32 for a long time. Its compiler is paid and very expensive, nor is it compatible with third-party microcontrollers, as is the case with ARMs between manufacturers.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 10, 2019, 01:46:20 pm
content: Quote from: nctnico on November 10, 2019, 12:22:20 pmI need a fact check on that. MPLAB was developed in house by Microchip AFAIK. MPLAB X is developed by Microchip on top of NetBeans framework, which is Apache/Oracle.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 10, 2019, 02:41:19 pm
content: Quote from: Mangozac on November 10, 2019, 03:59:51 amYes, they're the two brands I use by far the most often. The choice depends on application requirements, so I would choose Microchip if I need:- 5V power supply and/or voltage output- temperature rating >125C- quick development time for a simple application- bespoke peripherals, especially (though not exclusively) analogue componentsOn the other hand, I favour STM32 for:- any application requiring 32 bit performance- anything requiring more memory- anything requiring quick, reliable reprogramming and real-time debugging- anything that doesn't specifically require a feature that's only available in a PICI use Rowley CrossWorks for ARM development. For hobby stuff there's a non-commercial licence which is stupidly good value for what you get. The full professional licence isn't inexpensive, but I'd buy it again without a moment's hesitation. In terms of speed and reliabilty it's so far removed from MPLABX that it's hard to believe they're products of the same period in computing history.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 04:01:30 pm
content: I for one have. I used to use Microchip MCUs almost exclusively up until 3 years ago. I then switched to STM ones, mainly the L4 series which fits most of my needs.I never cared about the tools much per se, if you're talking about IDEs and such, as I don't use them. So I always used makefiles and other build tools, invoking the compilers/linkers directly in both cases. Both Microchip and STM have GCC-based compilers (at least for the 16-bitters and 32-bitters for Microchip, not sure about the 8-bitters). But in Microchip's case, the licensing is weird. The compilers are NOT free unless you use the crippled versions (without all optimizations) - not talking about using cracks of course, as it works but it's obviously illegal. The GCC back-end for PIC cores is also less robust IMO compared to ARM targets for obvious reasons (it's only used for PIC targets and only maintained by Microchip!). And you can get ahold of a GCC compiler for ARM Cortex targets anywhere, in the exact version you want. You're absolutely not stuck to anything distributed by STM. Also, you have a large choice of programming probes for STM MCUs, not so for the Microchip ones...Power draw in most cases (at least with the L4 series) is also MUCH lower than even the Microchip XLP series.The only good point still holding IMO for Microchip MCUs is the relatively better documentation, the simpler architectures (at least for the 8-bitters and 16-bitters), which can be an advantage. This in turn makes programming them 100% without any third-party (including vendor's) library possible without much difficulty, whereas it is, but it's a lot more work, for STM MCUs (and ARM-based MCUs in general).Of course there may be other criterions for your particular uses, such as regulatory ones. Do you need automotive-qualified MCUs? Are you designing medical devices? Vendors can have very different approaches for those segments.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 04:32:33 pm
content: Quote from: malagas_on_fire on November 10, 2019, 11:27:01 amOn Linux whatever the default simplest editor in the DE. At the moment it is Gedit/Pluma. On Windows the editor in FAR Manager.I would really like to find a good fast editor, but everything I find is too much, and require a lot of configuration. 4Coder is probably the closest to what I really want.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 04:34:48 pm
content: Quote from: AndyC_772 on November 10, 2019, 02:41:19 pmI second this. I for whatever reason thought they got acquired by someone.If I were forced to use an IDE, Rowley CrossWorks would be my #1 preference. It actually is fast and seemed to do the business very well when I was looking at different IDEs.

author: Karel
author_rank: Super Contributor
timestamp: November 10, 2019, 04:38:54 pm
content: Quote from: SiliconWizard on November 10, 2019, 04:01:30 pmYou are wrong. The 16-bit and 32-bit compilers are modified GCC compilers which come with a GPL licence, so it's completely legal to "crack" them.You canNOTput new strictions on GPL software that makes it less free than it was before.In fact, Microchip doesn't want you to know this but if you look carefully, you can find somewhere on their website the modified source of their16-bit and 32-bit compilers. So, legally, there's nothing that prevents you to enable the higher optimizations.This has already been discussed before in other threads.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 05:04:04 pm
content: Quote from: Karel on November 10, 2019, 04:38:54 pmYes it has been discussed, and I don't agree. (Bit tricky though I admit.) The whole discussion was interesting and I'll suggest looking at it (we're not going to go through it all again...)"Cracking" the distributed binaries from Microchip is IMO illegal, as would be cracking any other paid-for software. By cracking I mean using the official distributed binaries and modifying the binaries in any way. (AFAIR, cracking the official Microchip compilers involved 1/ writing a fake "license manager program" - very easy - and 2/ modifying some hash codes in the binaries, that may have changed...)Now whether Microchip enforcing a license with crippled, although GPL software as they do is itself legal or not, I'm not completely sure, but I'm sure their legal department has worked on that. I don't think they ever got sued for that, if you know they did, please give a link.So this is with the cracking; what you're allowed to do, though, is building the compilers yourself as they release source code, and remove/don't enable the license checking part. No problem in theory. Good luck with that though. I remember trying building their GCC versions for the 16-bitters from the source they released and never succeeded (knowing that I had built quite a few cross-gcc compilers for various targets before, so I knew what I was doing.) If you succeed building a working version from sources, don't hesitate to chime in. Now even if you succeeded, there would be always some doubts as this would be completely unsupported. But try that first and report back! (This is for the 16-bit cores, the PIC32, which are MIPS-based, can be used with a cross-GCC for MIPS, but AFAIR, Microchip included some patches specific to the PIC32 and a vanilla cross-gcc for MIPS may not work as intended for PIC32 targets, or with some bugs...)And even if you got that far, the part that would not be GPL (and thus illegal to copy as such) would be all Microchip support files (headers, libraries, startup code...) Not impossible to rewrite all those from scratch of course, but good luck with that.

author: madires
author_rank: Super Contributor
timestamp: November 10, 2019, 05:04:22 pm
content: Quote from: ataradov on November 10, 2019, 04:32:33 pmHave you tried SciTE? It's simple, yet powerful if you like.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 05:10:18 pm
content: Quote from: madires on November 10, 2019, 05:04:22 pmI tried a long time ago. It did not stick. It was not bad, but something just did not work.But I'm not really actively looking for a new editor. My situation is pretty ok as it is.The reason I like FAR Manager is that it acts as a "project navigator" itself being a file manager. But no project files of any sort are required. It is easy and elegant. 4Coder uses very similar approack, and I like it.

author: Karel
author_rank: Super Contributor
timestamp: November 10, 2019, 05:30:12 pm
content: Quote from: SiliconWizard on November 10, 2019, 05:04:04 pmYou'r wrong again. It's completely legal to crack/modify a binary/executable which has been compiled from GPL'ed software.You canNOTgrab some GPL'ed sourcecode, compile it and distribute the binary and sue somebody who dares to patch/crack/modify that binary.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 05:32:23 pm
content: SciTE is a bit too rough as an all-purpose programming text editor IMO, but hey, whatever floats your boat. If you're looking for something simlilar but a bit more polished, you can consider Geany instead, it actually uses Scintilla as well.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 05:33:07 pm
content: Or better yet, just use stock GCC or Clang and skip the whole vendor lock-in and the need for cracking, even if legal.

author: Karel
author_rank: Super Contributor
timestamp: November 10, 2019, 05:38:50 pm
content: Quote from: ataradov on November 10, 2019, 05:33:07 pmI agree. It's one of the reasons I prefer STM32 over PIC32.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 06:14:51 pm
content: Quote from: Karel on November 10, 2019, 05:30:12 pmAlthough I'm no GPL specialist, I think it's a bit more involved than this. You are indeed probably not directly infringing Microchip's license itself if you're patching the GCC binaries, as this is software under the GPL. But...- The binaries that are distributed from GPL software are supposed to be released with the corresponding source code. Microchip distributes the source code indeed, although as I said it is notoriously hard to build, but AFAIR they even release the source code for the license checking part (which is what made the cracking very easy in the first place). Which they have no choice doing as the GPL implies that any released binaries must be buildable from the accompanying source code, thus implying that there may not be any omitted part in it if I'm not mistaken...- Now if you modify the binaries (by patching them directly), I think you're somehow breaking the GPL because you're supposed to modify and release the source code in an according way so they match. This is the tricky part. Again it would probably take a specialist, but modifying GPL software involves modifying the source code. I'd think modifying binaries only with no matching source code IS breaking the GPL. Now you may think it all comes down to what you're allowed to do personally with GPL software as long as you don't redistribute it. That's where it becomes tricky (at least to me). Is it not against the spirit of the GPL to even do this?So what it may mean (surely it's not an easy matter) is that if you patch Microchip GCC binaries, you are probably OK with Microchip but you may be infringing the GPL. Not completely sure how those cases are handled, I suppose if you're not redistributing them, you're probably safe, as no one will, by definition, know. But is it not against the GPL? That I don't know for sure, I'm thinking it may be, at least in theory. And now that could mean that if it were true, you'd be 100% fine if you actually released the compiler's source code modified to remove the license checking part, and recompile it from there. You should in theory be allowed to redistribute both the source code AND the matching binaries! But I don't think I have ever seen anyone redistributing this. Maybe that's because Microchip made it so hard to build their compilers from source, which is itself not infringing on the GPL (you're supposed to distribute the source code, but not to make building it easy.)Lastly, and as I said earlier, even if the cracked binaries are perfectly legal (modulo the above), the support files are not under the GPL and AFAIK can't be used freely outside of Microchip's own license. That would include the support header files for the MCUs, the runtime components (this is how it's mentioned in Microchip's license) and the math library, which is commercial software (I'm basing this on the XC16 license). So, distributing them along a completely free and non-crippled version of GCC would be illegal. When it's for your own use only, I'm honestly not sure. The "licensee", as the license says, is granted a right to use them. Now are you considered a licensee if you are using a modified (compared to the official release and source code!) version of GCC? I don't know. Maybe. Tricky.

author: nctnico
author_rank: Super Contributor
timestamp: November 10, 2019, 06:23:36 pm
content: Quote from: SiliconWizard on November 10, 2019, 05:32:23 pmIMHO you should also look at other stuff an IDE can do. What I like about Eclipse is the ability to navigate through large projects by using searches and being able to jump to a certain point in a file, see a function when you hover over the name with the mouse or jump to it's definition or body. And then there are things like outlines which show the defines, variables and functions in a file, listing FIXMEs and TODOs, and bookmarks. Not to mention realtime syntax checking. Eclipse is just and example of an IDE which goes way beyond a good text editor and it can boost productivity a lot.

author: ataradov
author_rank: Super Contributor
timestamp: November 10, 2019, 06:30:47 pm
content: Quote from: nctnico on November 10, 2019, 06:23:36 pmIt is a matter of preference, of course. But not using an IDE with all those bells and whistles actually forces me to create a project structure I can navigate easily. More automation just encourages sloppiness.But there is no harm trying, of course. I did and I consistently revert back to a text editor.One thing that specifically bothers me about the IDEs is the need to maintain a "project". That's just one more thing to think about. The file structure on my hard drive reflects the desired project structure. All I need is a way to navigate that without creating additional entities.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 06:46:14 pm
content: Quote from: nctnico on November 10, 2019, 06:23:36 pmYou can do almost all this with editors such as Geany (which is more like a lightweight IDE, actually), except the pop-up info on hovering, which I personally don't like (but whatever floats your boat!)It has navigation (back and forth with any level), list of symbols, bookmarks, easy to use search... so yeah, we basically agree on the big picture. Just know that there are "IDEs" out there that are much more lightweight than Eclipse (that I don't like much) and are also fine. I put Geany more in the text editor category, as it would probably be considered so for many die-hard users of Eclipse or VS code.The list of symbols and search across a whole project are almost a must have to me.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: November 10, 2019, 07:44:20 pm
content: Quote from: SiliconWizard on November 10, 2019, 06:14:51 pmI'm not a copyright attorney, but I have a five-digit Slashdot userid. Sooo...QuoteThe overarching principle is, where you convey a binary to someone built from GPL source, you must also offer to them the source used to build it, and you must not interfere with the recipient's exercise of rights under the GPL to do the same. The GPL is chiefly concerned with redistribution. Usage and modification of binaries or source is freely permitted under the GPL, (maybe) revocable only if you break the license by redistributing binaries in violation. In particular, the GPL explicitly allows GPL software to be simply aggregated on a distribution medium with non-GPL software, without imposing any extra terms on the aggregate or its components. So header files, linker scripts, etc. don't have to be GPL because they're aggregated, not combined.Linkingto produce a combined work, by static or dynamic means, is where the GPL "virally" subsumes non-GPL software and sets conditions on distribution of the whole.I'd consider binary patching very much like linking, in that you're creating a combined work comprising GPL software and non-GPL software. The source release conditions apply. Which is easily satisfied by including the GPL tarball, your patch data, and the source used to build the patch (if any).But it's more practical to release the patch data alone, with the minimum of non-GPL context to validate the patch, because the onus is on the distributor of the binaries to distribute the source, and bandwidth can be expensive.QuoteIf you don't distribute, the GPL doesn't even care.QuoteThe author has complete freedom within applicable laws to dictate terms on those parts merely aggregated but not combined (linked) with GPL code. The vendor is free to require, as a condition of their license grant to you, that Thou Shalt use them only with hardware or softwareas provided byMicrochip. The GPL is silent on that. If the vendor doesn't require that, it might be fair game.

author: malagas_on_fire
author_rank: Frequent Contributor
timestamp: November 10, 2019, 07:57:30 pm
content: Quote from: ataradov on November 10, 2019, 04:32:33 pmYep the simple it gets the easier is to get into the harder stuff. use Vim / Gvim since it is the same in all OSes , works good with makefiles and ctags for code completion, not the easier one but the most general for embedded linux system development were you use a lot of vi / vim built-in busybox. Tend to stay away from IDE because it is another set of keybindings that you need to learn, adapting and time consuming. OK, Netbeans based IDE's and that's the border line in GUI as last resort aka "microXp". 2Atmealesphere" and the raw Netbeans until makefile comes into place.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 08:03:19 pm
content: Quote from: jhpadjustable on November 10, 2019, 07:44:20 pmThis is where it's not so black and white IMO. The GPL states: "This License explicitly affirms your unlimited permission to run the unmodified Program". So far so good if you're not modifying anything: you can do whatever you want. If you're modifying anything... that's just another problem.This part should probably deal with what we're talking about: "You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force."I think pached binaries would qualify as "covered work" in the strict sense.But it's not quite as clear as it may appear. Clear as mud maybe.Oh well. Anyway as I said, you can't do much with the raw compiler unless you're ready to rewrite all the support stuff from Microchip, which, AFAIK and contrary to others vendors, they are not releasing outside of the compiler distribution itself. Which makes all the licensing even more confusing.Another related point is that, AFAIK, the PIC back-end, contrary to many other targets, never made it to the official GCC source code. Is it because it's such a mess that the GCC team rejected it entirely? (Very possible!)

author: bingo600
author_rank: Super Contributor
timestamp: November 10, 2019, 08:28:52 pm
content: µChip must like this announcementhttps://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-nowWonder what happens w. avr-gcc/Bingo

author: coppice
author_rank: Super Contributor
timestamp: November 10, 2019, 08:57:40 pm
content: Quote from: bingo600 on November 10, 2019, 08:28:52 pmI think the people who did the original avr-gcc development moved on long ago. Every now and then GCC or binutils requires some significant changes in all the backends, and it seems they have reached such a position with GCC 10. If nobody is motivated to keep the back end up to date it will be kicked out at GCC 11. I was trying to get a new back end up to date for integration into the main line binutils code a few years ago, when the GDB interface to its backends was changing rapidly. It was a serious PITA, but it has to be accepted if the front ends of these tools are to improve.

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 10, 2019, 09:07:14 pm
content: The licensing issue is surprisingly clear.Distributing and modifyinggccor other software licensed under the GPL, or derived from software licensed under the GPL, is solely based on the GPL license. Microchip EULAs, contracts, etc. do not affect this, as applying any additional restrictions would make Microchip themselves to be in copyright violation.The sources for theMicrochip AVR and ARM toolchainsare listed in the product release notes (for example, sources for AVR 8-Bit Toolchain 3.6.1 arehere; possibly hosted on a potato connected to internet via Avian Carrier), and in thearchive.The toolchain is just a GPL'd part of the development environment. The rest of the development environment is licensed under different licenses. While the development environment as a whole is Microchip's product, parts of it are licensed under GPL, and then under GPL only. When Microchip refers to licensing restrictions, they are very careful to use language that refers to the entire environment, and not the toolchain specifically.Although Microchip may state thatlinker scriptsare not licensed under the GPL, they are a necessary part of the sources to build the software. In Europe, since those configuration details have nothing creative in them, and are necessary for interoperability, even if copyrightable, it is not enforceable. In real life, Microchip will not complain about distributing those linker scripts or their derivatives.To keep users paying for their crappy software, Microchip seems to rely on users either not caring, or not understanding the difference between the development environment and the toolchain.Quote from: SiliconWizard on November 10, 2019, 08:03:19 pmNo, 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.Remember, Microchip has not and can not restrict users from changing and distributing changes and modified versions of GPL-licensed software. No, their EULA/whatever license does not apply to the GPL'd parts: if they did, Microchip would violate GPL themselves.Quote from: SiliconWizard on November 10, 2019, 08:03:19 pmNot the compiler; the entire toolchain is derived from GPL'd software (GCC, binutils, libc).The interesting thing is exactly what you mean by "all the support stuff from Microchip".Essentially, the toolchain being under GPL means you can compile and build firmware for the devices. The interfaces are publicly documented in datasheets, and in general, declarative header files (i.e., definitions and interfaces, excluding implementation) are not considered copyrightable. (Oracle is fighting very hard to change that, but if they succeed,everyoneis in violation, so we can ignore that.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 10, 2019, 09:20:50 pm
content: Quote from: Nominal Animal on November 10, 2019, 09:07:14 pmRead again this GPL part to understand why I said it was not so simple: "You may make, run and propagate covered worksthat 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, because as far as I understand the GPL, all the source code distribution stuff applies to work that you "convey". Really, the GPL is not as simple as some may say IMO. It's a can of worms.Quote from: Nominal Animal on November 10, 2019, 09:07:14 pmI 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.Of course you can use the compiler without any of the above, that you can fully rewrite, but it's going to take serious work.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!

author: cv007
author_rank: Frequent Contributor
timestamp: November 10, 2019, 10:45:37 pm
content: If I want to modify the Linux kernel on my pc, whether through modifying the binary, or changing the source code and compiling, I have no obligation at all to tell anyone or start giving out my modified code. If I get to a point where I cause a transfer of the license- by distributing my modified kernel in any form, then I have transitioned from just a recipient of the licensed code to something that requires giving the next recipient the same freedoms and potential obligations I currently have.When talking about the gcc compiler or gpl code in any form, just substitute Linux kernel as the name. Mchp distributes the Linux kernel, they will allow it to run faster if you pay them $1000 (perfectly fine, but a little lame), but they also abide by the gpl and make their changes available. If you want to modify that kernel binary, why would you think in the line of license transfers that took place along the way, that the previous one happens to be special and can place additional restrictions on you? They cannot. They know it, but don't really want to put a big banner saying so right next to the $1000 price tag. They fulfill their obligations in the background, but they are fulfilled. Those who know, know. Those who don't, shell out $1000 and get chained to dongles and activation servers.By the way, adding a simple 17 byte text file to a folder removes all xc16/32 restrictions. No binary mod needed.>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!That's one reason why a binary patch would be used. They provide the source, but it cannot successfully be compiled. Since there is no restriction to modifying a gpl binary, and you have the source to find out what you want modified, just change a few bytes in the gpl binary to get what you want. If you want to distribute, just provide all the same files/source you have been provided, with the additional info to account for the patch. If you are using for your own use, and do not distribute to others, then tell no one as no one else cares.

author: techman-001
author_rank: Frequent Contributor
timestamp: November 10, 2019, 11:31:22 pm
content: Quote from: Mangozac on November 10, 2019, 03:59:51 amIf you had asked " Which MCU type has all the data I need todesign my own development system? I'd have replied "ARM" because it has CMSIS-SVD which provides all the data needed to build your own header files. There are also some very capable FLOSS tools, especially for STM32xxx.Given that the FLOSS world is jam packed with programs so good that even many commercial vendors include them in their offerings, i.e. GCC, putting together your own development environment using them is pretty easy, easier than many people probably think.For instance when someone here replies "Oh I just use VIM, GCC, Opencm3 and Makefiles", that's what they just said.They made their own development system.I also agree that the chip vendor free tools really suck. I don't know why but I suspect that because they're free, they get their clueless interns to make them. I remember downloading megabytes of free STM guff to make a 'blinky' for a new STM32F0 Discover board back in 2016 and I couldn't do it because nothing worked.Within a few hours I had arm-none-eabi, vim, opencm3 (or something like that) and a makefile all set up. The blinky was running no problem.I never bothered with the STM tools again, I just buy their chips.

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 10, 2019, 11:43:46 pm
content: Quote from: SiliconWizard on November 10, 2019, 09:20:50 pmNote 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.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.Quote from: SiliconWizard on November 10, 2019, 09:20:50 pmSupport 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.)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 toolchainsuffices, 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.Quote from: SiliconWizard on November 10, 2019, 09:20:50 pmI 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 11, 2019, 12:43:18 am
content: Quote from: Nominal Animal on November 10, 2019, 11:43:46 pmYou 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...Quote from: Nominal Animal on November 10, 2019, 09:07:14 pmI 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.Quote from: Nominal Animal on November 10, 2019, 11:43:46 pmI 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:QuoteSo 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.Quote from: Nominal Animal on November 10, 2019, 11:43:46 pmWell, 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...

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 11, 2019, 02:38:07 am
content: Quote from: SiliconWizard on November 11, 2019, 12:43:18 amIt'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.Quote from: SiliconWizard on November 11, 2019, 12:43:18 amTrue, 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".Quote from: SiliconWizard on November 11, 2019, 12:43:18 amThe license checker is part of the GPL-licensed sources for XC16: insrc/XC_GCC/gcc/gcc/config/pic30/pic30.c:get_license(), with an explicit GPL license at the beginning of the file.Replacing that function withstatic 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.Quote from: SiliconWizard on November 11, 2019, 12:43:18 amOk; 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.)Quote from: SiliconWizard on November 11, 2019, 12:43:18 amDeclarative parts -- macros and interfaces, like structure and function declarations -- cannot, because they have nooriginality: 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-headersreplacing the Windows SDK header files, for example. Even when the contents declare the same facts, it is not infringing on copyrights either way.Quote from: SiliconWizard on November 11, 2019, 12:43:18 amThings 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.Quote from: SiliconWizard on November 11, 2019, 12:43:18 amNo, 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.)Quote from: SiliconWizard on November 11, 2019, 12:43:18 amIt 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.Quote from: SiliconWizard on November 11, 2019, 12:43:18 amThe 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 11, 2019, 02:57:41 am
content: Quote from: Nominal Animal on November 11, 2019, 02:38:07 amI 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.

author: aandrew
author_rank: Frequent Contributor
timestamp: November 11, 2019, 05:42:14 pm
content: Quote from: imo on November 10, 2019, 09:00:53 amUgh, 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.

author: mikerj
author_rank: Super Contributor
timestamp: November 11, 2019, 05:51:18 pm
content: Quote from: aandrew on November 11, 2019, 05:42:14 pmNot 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.

author: ebclr
author_rank: Super Contributor
timestamp: November 11, 2019, 05:54:05 pm
content: Pics have a lot of other tolls free and paid, And some are very good, You don't need to relly on Mplab

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 11, 2019, 07:12:13 pm
content: Quote from: SiliconWizard on November 11, 2019, 02:57:41 amI probably communicate the concepts wrong; I'm much better at concrete examples than lawyer talk.Quote from: SiliconWizard on November 11, 2019, 02:57:41 amYes, 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 inabstraction-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.Quote from: SiliconWizard on November 11, 2019, 02:57:41 amNo, 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.0and// SPDX-License: BSD-3-Clause, with the license texts inLICENSE.CC0-1.0andLICENSE.BSD-3-Clausein 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.TheARM GNU Toolchain provided by Microchip(and the upstreamGNU ARM Embedded Toolchain) provides the compiler (gcc), linker and debugger (binutils-gdb), and the basic C headers and libraries (newlib), all licensed under GPL.TheAVR 8-bit Toolchainprovides 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.Quote from: SiliconWizard on November 11, 2019, 02:57:41 amMe 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 11, 2019, 07:18:34 pm
content: 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!)

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 11, 2019, 09:58:47 pm
content: Quote from: SiliconWizard on November 11, 2019, 07:18:34 pmYes, 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 howtheir similarity, even if obtained from copyright-protected sources, is not copyright infringement.If you look at e.g.avr-libc, say theavr/iom32u4.hheader file, that defines registers and pins for ATmega32u4 microcontrollers, it is clearly labeled (C) 2008 Atmel Corporation, but incorporated in a project licensed with avery 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 macronames, 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 infringementin Europe, because of the reasons I outlined in my earlier posts.Quote from: SiliconWizard on November 11, 2019, 07:18:34 pmI 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.Quote from: SiliconWizard on November 11, 2019, 07:18:34 pmAgreed (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 bysrc/XC_GCC/gcc/gcc/config/pic32/mchp.candsrc/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 generatefunctionallyequivalent 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 patchand 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.candzeha:xc16/src/src/XC_GCC/gcc/gcc/config/pic30/pic30.c, and look forget_licensefor 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.)

author: emece67
author_rank: Frequent Contributor
timestamp: November 11, 2019, 11:12:33 pm
content: .

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 11, 2019, 11:42:50 pm
content: Quote from: Nominal Animal on November 11, 2019, 09:58:47 pmFor 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 12, 2019, 12:36:04 am
content: Quote from: SiliconWizard on November 11, 2019, 11:42:50 pmTrue, 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 thereareother 16-bit targets still supported, like cr16, m32c, and msp430.Quote from: SiliconWizard on November 11, 2019, 11:42:50 pmPerhaps 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 tocr16,m32c, ormsp430. 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 forcr16,m32c, ormsp430do 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.

author: Mangozac
author_rank: Frequent Contributor
timestamp: November 13, 2019, 07:38:04 am
content: Thanks to those who provided the on-topic commentsWell 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"...

author: westfw
author_rank: Super Contributor
timestamp: November 13, 2019, 08:17:20 am
content: QuoteI'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"?

author: AndyC_772
author_rank: Super Contributor
timestamp: November 13, 2019, 08:43:31 am
content: Quote from: Mangozac on November 13, 2019, 07:38:04 amI 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 timeThe 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.

author: Karel
author_rank: Super Contributor
timestamp: November 13, 2019, 09:22:57 am
content: Quote from: AndyC_772 on November 13, 2019, 08:43:31 amThis!Quote from: AndyC_772 on November 13, 2019, 08:43:31 amI 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

author: techman-001
author_rank: Frequent Contributor
timestamp: November 13, 2019, 09:58:22 am
content: Quote from: AndyC_772 on November 13, 2019, 08:43:31 amAgreed 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.

author: Kjelt
author_rank: Super Contributor
timestamp: November 13, 2019, 12:37:15 pm
content: Quote from: brucehoult on November 10, 2019, 06:41:57 amFor 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 oreven 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 likeautocad, the students learned how to use it and will continue to use it in their daytime jobs.

author: coppice
author_rank: Super Contributor
timestamp: November 13, 2019, 12:46:48 pm
content: Quote from: brucehoult on November 10, 2019, 06:41:57 amThis 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: November 13, 2019, 12:53:04 pm
content: Quote from: coppice on November 13, 2019, 12:46:48 pmYour story sounds so disorganised and typically human it is sure to be accurate!

author: Kjelt
author_rank: Super Contributor
timestamp: November 13, 2019, 02:20:16 pm
content: 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

author: coppice
author_rank: Super Contributor
timestamp: November 13, 2019, 02:49:23 pm
content: Quote from: Kjelt on November 13, 2019, 02:20:16 pmA 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 13, 2019, 05:20:45 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 13, 2019, 05:50:18 pm
content: Quote from: NorthGuy on November 13, 2019, 05:20:45 pmQuite 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!!

author: AndyC_772
author_rank: Super Contributor
timestamp: November 13, 2019, 09:27:09 pm
content: Quote from: techman-001 on November 13, 2019, 09:58:22 amI liken the libraries to a tour guide or interpreter in a foreign country. They speak a language that's easy for you to understand, but also have the skills to communicate somewhere where you can't.What youwantis someone who can carry out simple instructions for you. Things like "buy a train ticket to <place>, returning tomorrow", or "order the chicken with spicy noodles". Ideally, you don't want to have to navigate and understand the transport network of a foreign city, or learn which characters represent recognisable food vs things you'd rather avoid.Imagine, though, the usefulness of a guide whose response was "sure, no problem, you tell me exactly which words to say, and I'll say them for you".That's about the level of the ST libraries. You need to provide the a contents of a data structure which maps very closely to the underlying register interface, and as do that, you might as well RTFM and just program the hardware yourself.The irony is, it's just not that hard. (Just don't try and learn the timers first, especially the complex ones... <shudder>)

author: NorthGuy
author_rank: Super Contributor
timestamp: November 13, 2019, 10:25:48 pm
content: Quote from: AndyC_772 on November 13, 2019, 09:27:09 pmIt's rather the opposite - they translate from well-documented language of the datasheet to undocumented language of library implementers.It's like watching an English movie which has been synchronously translated to Spanish. You can either try to make sense of foreign Spanish words, or you can try to listen through the translation to catch some English words in the background. Either way, it would be much easier to watch if the Spanish translation was simply removed.

author: techman-001
author_rank: Frequent Contributor
timestamp: November 13, 2019, 11:16:39 pm
content: Quote from: AndyC_772 on November 13, 2019, 09:27:09 pmNice analogy!I agree, it's not that hard especially as all the STM32 peripherals I've used have sensible defaults and almost run by themselves.You're right about the timers, they're quite the perfect example of endless config permutations. I made up the list below to show which ones are the more complex, with TIM 1 being the winner and TIM6 the least complex.For those not familiar with bitfields, every bitfield below represents a timer configuration choice.TIM122 registers127 bitfieldsTIM220 registers107 bitfieldsTIM320 registers107 bitfieldsTIM68 registers13 bitfieldsTIM1412 registers27 bitfieldsTIM1518 registers78 bitfieldsTIM1616 registers57 bitfieldsTIM1716 registers57 bitfields

author: Jan Audio
author_rank: Frequent Contributor
timestamp: November 14, 2019, 04:43:39 pm
content: Quote from: Mangozac on November 10, 2019, 05:13:49 amWhat do you mean, cant you install the latest compilers in old MPLAB ?I use the latest version 2, and like to buy the latest chips sooner or later.Thanks for the warning.Is there a support list per MPLAB ?I still hope you wrong on this.

author: Mangozac
author_rank: Frequent Contributor
timestamp: November 14, 2019, 10:14:31 pm
content: Quote from: Jan Audio on November 14, 2019, 04:43:39 pmMy problem isn't with compilers - we actually rarely have issues there! All of the issues of late have been with the programming tools.

author: Bassman59
author_rank: Super Contributor
timestamp: November 18, 2019, 08:58:35 pm
content: Quote from: SiliconWizard on November 13, 2019, 05:50:18 pmI think the vendors who provide software tools based on Eclipse do so because users demand multiplatform tools. gcc can be compiled for any of the three operating systems, so that's covered. Segger's J-Link works on all three OSes. And Eclipse runs equally well on Windows, macOS and Linux. Being that it's easily extended and customized makes Eclipse attractive for the silicon vendors who want to cover all of those bases.So, yeah, I seem to have a half-dozen installs of Eclipse on my workstation ...

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2019, 12:14:49 am
content: Quote from: Bassman59 on November 18, 2019, 08:58:35 pmThere certainly are a lot of customers who seem to love and demand Eclipse. I can't stand it myself. But we (SiFive) provide an Eclipse-based IDE.Before Eclipse, we supported the Arduino IDE for the HiFive1. It is also cross-platform, and is very very easy to get started with. It's hard to regard it as "professional", though.More recently, we (along with Western Digital) dropped some sponsorship money on the PlatformIO people to make their product completely free for any one to use, with any supported SoC family (currently 34, including not only multiple RISC-V but also AVR, Espressif 32 & 8266, Intel 8051, PIC32, MSP430 and of course a bunch of ARM vendors), on a wide range of IDEs/editors including Cloud9, Codeanywhere, Eclipse Che, Atom, CLion, CodeBlocks, Eclipse, Emacs, NetBeans, Qt Creator, Sublime Text, Vim, Visual Studio.We recommend using it with VS Code, but there is a wide choice.PlatformIO claim 744 different boards are supported.Sadly, traditional PIC is one of the few popular things not supported.

author: boz
author_rank: Regular Contributor
timestamp: November 21, 2019, 08:39:09 pm
content: Had to install the latest MPLABX and XC8 and XC16 on my new Windows 10 laptop to update a project to a new dsPIC chip the old MPLAB did not support. It Installed much easier than the first time I tried it about 2 years ago in fact I dont recall any issues/errors; The new pickit 4 programmer I bought to replace my ICD2 connected OK and the project upgraded compiled and programmed much the same as the old with only a slight increase of a few bytes in code and RAM.I guess the story is different people/environments/targets have different problems and I was just lucky as I dont push past programming and simple debugging. I have looked at the newer 32 bit development boards and have been tempted by the crazy specification/prices of the newer Atmel and STM devices but have yet to move beyond 8/16 bits for commercial projects as we never get close to hardware limits.I dont think I would drop a manufacturer or ecosystem just because they dropped the ball occasionally or you would always be moving and never get any shit done.

author: westfw
author_rank: Super Contributor
timestamp: November 22, 2019, 12:56:32 am
content: QuoteOh. That presumably means that most of the discussion has been pretty useless...QuoteI would expect that from a programming tool point of view, a vendor with essentially two device families and three programming protocols (JTAG, SWD, and whatever STM8 uses) would have fewer bugs than the full range of Microchip devices.Although I've noticed that while JTAG/SWD is theoretically common across lots of chip, it doesn't actually include flash programming - that's normally done either by manipulating the internal NVM controller registers/etc, or by loading actual target code into RAM and letting it run. That means that you can run into situations where YOUR particular tool/target combination doesn't actually have all the bits needed to achieve programming. Theoretically (again), you can do it yourself in some "generic" way using something like OpenOCD. But that can be a pain when you're trying to get things to work, and your IDE doesn't interface to your generic tool, and...