Path: csiph.com!weretis.net!feeder6.news.weretis.net!panix!.POSTED.::1!not-for-mail From: Grant Edwards Newsgroups: comp.arch.embedded Subject: Re: Makefile or IDE? Date: Thu, 2 Dec 2021 15:22:36 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: References: Injection-Date: Thu, 2 Dec 2021 15:22:36 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="::1"; logging-data="23939"; mail-complaints-to="abuse@panix.com" User-Agent: slrn/1.0.3 (Linux) Xref: csiph.com comp.arch.embedded:30923 On 2021-12-02, pozz wrote: > Ok, it's a good thing to start with a minimal effort and make some tests > on EVB and new chips. However I'm wondering if a good quality > commercial/industrial grade software is maintained under the IDE of the > silicon vendor or it is maintained with a Makefile (or similar). We always use makefiles. Some people do their editing and "make"ing in an IDE like eclipse. Others use emacs or whatever other environment they like. In my experience, software provided by silicon vendors has always, been utter crap. That's been true for IDEs, libraries, header files, debuggers -- _everything_. And it's been true for 40 years. Recently I tried to use the Silicon vendor's IDE and demo project/libraries to build the simple app that prints "hello world" on a serial port. This is an application, IDE, and libraries the silicon vendor provided _with_the_evaluation_board_. Following the instructions, step-by-step, did allow me to build an executable. It was far too large for the MCU's flash. I threw out the silicon vendor's "drivers" (which were absurdly bloated) and C library (also huge). I wrote my own bare-metal drivers and substituted the printf() implementation I had been using for years. The exectuable size was reduced by over 75%. We've also tried to use non-silicon-vendor IDEs (eclipse), and using the IDE's concept of "projects" is always a complete mess. The "project" always ends up with lot's of hard-coded paths and host-specific junk in it. This means you can't check the project into git/subversion, check it out on another machine, and build it without days of "fixing" the project to work on the new host. -- Grant