How to build with make and GCC?

[martijnsanderse]

I'm able to create projectFiles for various tools, such as make_gcc_arm, sublime. But whenever I run make, I get a "make: *** No rule to make target `[]', needed by ... '. Stop."

I would like to build a firmware for the lpc11u35 i.c.w. a nrf52 first, but I don't understand how to get started with the progren tool.

Could someone give me a clue? Thanks!

[cederom]

Hello @martijnsanderse, unfortunately at this point only Keil uVision is used for DAPLink builds..

[martijnsanderse]

Thanks @cederom.

Is the plan to support gcc builds at some point?
What is the reason gcc builds are not possible?

With some better insight perhaps I'm able to contribute.

Thanks,
Martijn

[cederom]

I guess Keil uVision seems to produce higher quality binaries (smaller, less bugs, etc) and has really really well integrated debugging that is easy to use (even with DAPLink itself!). That made initial development of DAPLink some years ago quicker and more predictable on vast amount of different target HIC microcontrollers. Developers could focus on code and functions rather than build environment (and its bugs).

Since the reference design is ready it should be possible to add support for GCC build environment. You will always have a working example to compare against in case of troubles.

You are more than welcome to contribute that non trivial feature! Lots of people would be glad to have it working (including me) :-)

[therealprof]

Keil uVision seems to produce higher quality binaries (smaller, less bugs, etc)

That sounds rather bogus...

[Awais174]

I am willing to contribute too.

Martijn, there is a free version of RTX/middleware which can be used with gcc.

That’s the first step to start breaking down items to support Daplink with make/gcc.

[Awais174]

I was once able to trim down Daplink to a level where free version of Kiel could be used to build binary.

Replace HID and MSC related code with stubs, and keep only CDC ACM - USB descriptors - related code and you should be able to see your device showing up.

Debug code a little from there and then porting work to support gcc can begin.

[cederom]

Keil uVision seems to produce higher quality binaries (smaller, less bugs, etc)

That sounds rather bogus...

@therealprof this is not my decission so I am not the person to discuss with, I was DAPLink developer only for a short while recently, while decission was made years ago and I can confirm builds using with different versions of GCC that also had its own issues in fact did introduce additional burden of work and problems..

I can understand this business decision and approach focused on quick and working results. We can now use Open-Source community to create Open-Source build configuration and environment for DAPLink :-) I am willing to help, my platforms are FreeBSD and macOS Unix :-)

[therealprof]

@cederom

this is not my decission so I am not the person to discuss with

I understand but the argument about the "higher quality binaries" is still bogus. If that was the case then the code should be considered broken, not the compiler(*).

I can understand this business decision and approach focused on quick and working results.

Oh, I fully agree that Keil uVision brings nice things to the table which a naked gcc can not provide...

(*) Not to say that compilers are completely bug free, but e.g. gcc is used way more than Keil and thus under a lot more public scrutiny to generate correct and efficient code.

[cederom]

What is your point of this discussion @therealprof? You want to have GCC build make it happen, this project is Open-Source! :-)

GCC 7 works really nice for firmware build (I use it with ARM mbedOS). I guess you did not have contact with GCC 3 or 4 and pre-CMSIS era utilities? You have now working examples to compare against so you can experiment with GCC. Have fun! :-)

[flit]

This is the official story: The limitation of currently requiring Keil MDK to build DAPLink has nothing to do with tool quality. It is simply due to the fact that some of the libraries that are used in DAPLink (USB, RTX RTOS) come from Keil middleware and are written in so that they only build with armcc v5. Porting these libraries to other compilers (we need to support all of armcc v5, armcc v6, gcc, and IAR) is infeasible.

However, we recognise that this limitation is a serious issue affecting the usability of DAPLink by the community. And, we are actively working on a solution. Because of the above mentioned problem, the solution will require switching to new a USB library, and moving to RTX5 (CMSIS-RTOS2) that already supports all 4 toolchains. The goal is to have the new solution in place by early Q1 2019, or earlier if possible.

[cederom]

Thank you @flit for the insight and the official story, you saved me again! :-) :-)

I did not know the answer and had nothing to do with the decision sorry @therealprof.. I was not the person to talk that story and I did not want it to go a bad direction.. personally I don't even use Windoze.. my heart belongs to Unix (FreeBSD + macOS BSD).. peace! :-)

Sounds like RTX5/CMSIS-RTOS2 will bring exactly what we need for Open-Source build toolchain for DAPLink, so there is no point in porting current source tree, correct? We are eager to test whenever it comes out! :-)

[martijnsanderse]

Thanks everybody, my question is answered.