Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!not-for-mail From: Grant Edwards Newsgroups: comp.arch.embedded Subject: Re: Makefile or not? Date: Mon, 3 Dec 2018 23:19:28 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 56 Message-ID: References: NNTP-Posting-Host: 67-130-15-94.dia.static.qwest.net X-Trace: reader1.panix.com 1543879168 13578 67.130.15.94 (3 Dec 2018 23:19:28 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Mon, 3 Dec 2018 23:19:28 +0000 (UTC) User-Agent: slrn/1.0.3 (Linux) Xref: csiph.com comp.arch.embedded:28376 On 2018-12-03, Clifford Heath wrote: > On 4/12/18 6:36 am, Grant Edwards wrote: > >> Never, ever, use any software written or provided by the silicon >> vendor. Everytime I've failed to obey that rule, I've regretted it. > > [Difficult to apply that rule for an FPGA (except some Lattice parts).] True > Also, ARM seems to require that its licensee support CMSIS. This truly > excellent idea seems to be terribly poorly thought-out and implemented. You're putting that mildly. I recently development some firmware for an NXP KL03 (Cortex-M0) part. It's a tiny part with something like 8KB of flash and a coule hundred bytes of RAM. Of course NXP provides IDE based "sample apps" that take up a gigabyte of disk space and includes CMSIS (which itself is hundreds (if not thousands) of files which define APIs for all of the peripherals that comprise layer upon layer of macros calling macros calling functions calling functions full of other macros calling macros. Trying to build even an empty main() using the CMSIS libraries resulted in executable images several times larger than available flash. I finally gave up and tossed out everything except a couple of the lowest level include files that defined register addresses for the peripherals I cared about. Then I wrote my own functions to access peripherals and a Makefile to build the app. In the end, I cursed myself for forgetting the rule of "no silicon vendor software". It would have been faster to start with nothing and begin by typing register addresses from the user manual into a .h file. > You get header files that pollute your program namespace with > hundreds or thousands of symbols and macros with unintelligible > names, many of which are manufacturer-specific not even > CMSIS-related. Yep, CMSIS is spectacularly, mind-numingly awful. > I know there's opencm3 which seems to be better, but still... > > Standard APIs like CMSIS need *very* disciplined design and rigorous > management to minimise namespace pollution. Unfortunately we don't seem > to be there, yet, unless I've missed something major. > > How do people handle this? Lots of teeth-gritting and quiet swearing. -- Grant Edwards grant.b.edwards Yow! Mr and Mrs PED, can I at borrow 26.7% of the RAYON gmail.com TEXTILE production of the INDONESIAN archipelago?