Atollic Truestudio Crack
Recently I started a repository that houses with a GCC toolchain. There are two code packages from STM that I used when putting this together, the firmware for the Discovery board itself, and the Standard Peripheral Library for the chip family.
Atollic Truestudio Pro Crack
I read the license agreements in the root of both packages and I think they’re quite fair. Basically the agreement is you can use them for any purposes as long as the code is only being used on STM hardware. You can image I was quite upset so see stating that I have a copyright violation with one of the files in the repo. It seems the linker script that is given as an example for Atollic’s TrueSTUDIO has it’s own extremely strict copyright:. (c)Copyright Atollic AB.
You may use this file as-is or modify it according to the needs of your. project. Distribution of this file (unmodified or modified) is not.
permitted. Atollic AB permit registered Atollic TrueSTUDIO(R) users the. rights to distribute the assembled, compiled & linked contents of this. file as part of an application binary file, provided that it is built. using the Atollic TrueSTUDIO(R) toolchain.
First off, I’m in violation just for posting the file in a repository. But read a bit deeper.
Any code that is compiled with this using a GCC toolchain also breaks the copyright unless it’s Atollic’s toolchain. My beef here is that STM is distributing this. Why put something so restrictive into a software library with such an otherwise reasonable license? Surely there are many engineers at STM capable of writing a linker script that they could release under their own license which would work with TrueSTUDIO. And, it would have the added benefit of allowing other GCC-based toolchains a convenient (and legal) method of linking code. So I’ve completely removed the file from the repository.
If you were one of the ten people watching it on github, this had the unintended consequence of dumping your watch request. In the mean time I’m trying to learn how to write my own linker. Has been a great help. If you have the skills to contribute a working linker script, please issue a pull request or raise an issue. Posted in Tagged, Post navigation.
ST probably provides linker files for each of their parts. If I were you I would look around wherever you found the peripheral driver library. Also look at any examples that came with the driver libraryeach of them will have a linker command file. FYI Linker files are pretty standard, so the ST ones should work with pretty much any linker (although it might need some tweaking). Linker command files are somewhat daunting to those who have never messed with them, but they are even easier to tweak than code once you understand how they work. I maintain some similar “skeleton” projects for microcontrollers.
To be honest there aren’t too many ways to write a linker script for a micro. It’s not like the memory map moves around. I really doubt the license in that file could be enforced. I would do the following if you’re really worried about: — Study the bad license linker file and write down the memory sections etc you need. These are public knowledge and should be in the datasheets anyhow so it’s not “stealing”.
— Using the ld manual and the tricks cribbed from the existing linker script write your own. Or just do like everyone else does (including demo board vendors!) and just remove the license notice, clean up the formatting, remove any unneeded junk, and rewrite the comments. Also you really don’t want to write your own linker. That’s a lot harder than a linker script.:p. Luckily there’s a loophole: The code as-is is copyrighted, but the methods used can only be patented. Replace all the variables, then change the order, maybe throw in some obfuscation for good measure. The result is identical function, but no violations of copyright.
It is entirely unethical to some, but so is releasing that bogus code in the first place. This is a method that skirts between the lines of copyright and patents, and the fact that code can fall in the cracks.
I cannot claim the full legal validity of the method though, so I would consult with counsel before trying. Not that code, all code has the same issue.
You can copyright non-functional features (design, actual words, etc) or patent functional ones (algorithms, etc), but most software is never patented. That license oddly leaves out a lot of needed restrictions, and therefore is only enforceable as a copyright violation (not breach of contract). If they ever did try to sue, their lawyer would talk them out of it, the judge would talk them out of it, and eventually, the case would be thrown out on the grounds that it’s an equivalently functioning work, not a copy. ChibiOS is an excellent GPL-licensed RTOS for the STM32 that includes from-scratch startup code and linker scripts for several compilers, including GCC.
Its development is heavily targeted towards STM32, and so it has terrific peripheral drivers integrated into the OS (synchronous threaded UART I/O, for example) and it’s very performant on all the STM32 families. Yet, it’s well abstracted from the architectures it runs on, so you run into relatively few arcane embedded issues. I’ve been using and contributing to the OS for my own projects, and ChibiOS + STM32F2/F4 is now definitely my go-to µC solution these days. The only thing relevant in those linker scripts is the memory map, it is not copyrighted. There are many dummy scripts in gcc’s directory ( using the ‘.x’ extension ) just browse it’s alongside with crt’s objects. Basicaly a LD linker script is no challenge for a developper, but you have to read LD’s info page first ( on linux ). Furthemore those provided by Attolic are just bullshit!
They lack many sections filled by the compiler( ex: ‘sdata’ section ). LD is part of the Tool Chain, as GCC do, so one have to learn how to use it too. ST guys are lamers!!
Also, if it’s not a good idea to rewrite a linker, an elf loader would be great, but It may use a lot of RAM. If you are using C, you’ll have to add ‘.ctors’, ‘.dtors’ as well as ‘.gccexcepttable’ sections.
“Basically the agreement is you can use them for any purposes as long as the code is only being used on STM hardware. Fair enough.” That isn’t fair enough in my opinion. You can’t build open source software (as defined by OSI) out of code with that restriction.
CMSIS and all other significant sample code I’ve seen from every ARM vendor has similar or worse restrictions. If you want to make open source hardware or software, you must look elsewhere or start from scratch.
Lately I’ve been working on adding LPC43xx support to libopencm3. It’s a lot of work, but hopefully it will enable plenty of future open source projects.