Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: pozz Newsgroups: comp.arch.embedded Subject: Re: AM623 experiences Date: Tue, 26 Nov 2024 13:10:31 +0100 Organization: A noiseless patient Spider Lines: 115 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 26 Nov 2024 13:10:32 +0100 (CET) Injection-Info: dont-email.me; posting-host="9919e7694c63f4a13d280ed0b818139a"; logging-data="3536807"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VXT04qD0sMloFfHpQGOIcP/3gw+RaOoE=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:8P2ph1SKvP5AeO1Wt3Np2bMCvcs= In-Reply-To: Content-Language: it Bytes: 7108 Il 25/11/2024 09:37, David Brown ha scritto: > On 24/11/2024 18:12, Grant Edwards wrote: >> On 2024-11-24, David Brown wrote: >> >>> Some vendor-supplied toolchains are not bad, but some are definitely >>> subpar - and often many years behind the versions you get from >>> manufacturer independent suppliers (like ARM's build of a gcc toolchain, >>> or commercial gcc toolchains).  The biggest problem with microcontroller >>> manufacturer's tools is usually the SDK's that are frequently horrible >>> in all sorts of ways. >>> >>> But I agree with your advice - where possible, use ARM's gcc toolchain >>> build for ARM development.  And make sure your project build is >>> independent of any IDE, whether it is from the vendor or independent. >>> IDE's are great for coding, and vendor-supplied IDE's can give good >>> debugging tools, but you want the project build itself to be >>> independent. >> >> What he said, defintely: Avoid vendor-specific IDEs and SDKs like the >> plague. > > I didn't /quite/ say that.  Avoid relying on them for your builds, was > what I said.  The last thing you want is your project being dependent on > whatever version of the IDE and SDK the supplier provides at a given > time.  For a serious project, you want to be able to take a new > computer, check out the old source, install the specific toolchain you > use for the project, and re-build to get exactly the same binary.  And > you want to be able to do that a decade later. > > I /do/ make use of parts of SDKs.  But I figure out what I need, and > copy the source into my project structure.  The main point is to avoid > having your project change because it is linked to some SDK stuff that > gets updated by the manufacturer's tools.  Library updates happen when > /I/ want them to happen, not on someone else's schedule. > > Often, the actual SDK stuff is very inefficient and bizarrely > structured.  But it can be convenient for things like initialisation of > complex peripherals, and that's fine - you don't (normally) need > efficiency during initialisation.  For real-time access - setting your > pwm values, using your gpio's, etc., - it is usually best to handle > things "manually". > > And of course the project build gets controlled by external tools.  I > like hand-written makefiles, but cmake or whatever suits is fine. > > Vendor-supplied tools can be very useful for debugging, however, as well > as being convenient for startup code, device initialisation, examples, > and so on.  I am not at all against using them - use every tool you can > get hold of that makes your job easier!  But don't make your actual > project binaries dependent on them. Unfortunately newer MCUs are little monster with a pletora of complex peripherals (USB, Ethernet MAC, clocks, ...), multitude of pins with several functions and so on. I think it's quite difficult to write an initialization procedure from scratch that configure correctly everything. So I use the tool that the vendor gives me. Many times it's an SDK with functions to call and, in this case, I try to configure the project to use "local copy" of the SDK (as you wrote, I copy the SDK source code in my project folder). However, newer tools often generate code at runtime, after you configure the system by using a graphical interface. In this scenario, the tool usually reads the configuration from a file and can re-generate the same source code from it. Here you /have/ a local copy of the source code generated by the tool, but what happens if you want to change something later, maybe after some years? First of all, you need to save the configuration file. Then you need the same graphical tool (same version as the original, if you want the same source code) and make all the changes you need. Maybe you want to upgrade the tool if it solved some bugs in the meantime. You can oganize your project so that you need only make, gcc and ld for the bulding process, but you can't be sure you wont' ever need to use the the vendor tools again (if you needed to use them one time, you could need them again in the future). So you are forced to add configuration files of these tools to the repository and instructions how to use these tools to obtain the same source code. Maybe you need to save the installer of these tools too. >> Demo apps and libraries from Silicon vendors are usually awful -- even >> worse than the toolchains. I'm pretty sure they're written by interns >> who think that to be "professional" it has to incorporate layers and >> layers of macros and objects and abstrcation and polymorphism and >> whatnot. >> > > Often the demos are terrible, I agree.  And they are often wildly > inconsistent.  But that doesn't mean they are completely useless - they > can be inspirational too, and can be helpful to see what you are missing > when your own code doesn't work. > >> As a result I rememeber failing to get a vendor's "hello world" demo >> to run on a Cortex-M0+ because it was too large for both the flash and >> RAM available on the lower end of the family.  And it wsan't even >> using "printf" just a "low level" serial port driver that should have >> been a few hundred bytes of code but was actually something like >> 10KB.. >> > > I think the clearest "war story" I have seen of that kind was for a tiny > 8-bit device from Freescale.  The chip had perhaps 2K of flash.  Since > this was a one-off use of the chip and I didn't want to read more > manuals than I needed to, I use the vendor IDE "wizard" to make the > initialisation code and a "driver" for the ADC.  The resulting code was > about 3.5 KB - for the 2 KB microcontroller.  So I read the manual and > found that the ADC peripheral needed one single bit set to make it run > as I needed. > >