ARMmbed
Support GCC
It would be nice if you didn't have to spend thousands on a Keil license to compile this!
Before GCC support can be added RTX needs to be updated. The version of RTX used by DAPLink doesn't have support for GCC, but newer versions do.
I don't think the USB stack has strong ties to any toolchain, so it should be fairly straight forward to update to use GCC.
Can we track who has the knowledge and who has the time to obtain a basic "this is as far as I/we got" to facilitate PR's for doc and possible forks to show their results be they ever so humble with possible PR's to code with possible problems not solved at the moment.
@c1728p9 named RTX. This is probably http://www2.keil.com/mdk5/cmsis/rtx/
Royalty-Free - No on-going costs. There are no run-time royalty payments or other hidden charges. Ship your RTX based products without further fees or recurring costs
Given no cost, and if the RTX refered to is the one I found, the github seems to be a start for compiling? https://github.com/ARM-software/CMSIS_5
Additional links found http://www.keil.com/pack/doc/CMSIS/RTOS/html/index.html
Hi @OwenBrotherwood, yep that is the right RTX. Since it's open source anyone who is interested could start the porting process.
In order to create a form for "if someone suddenly does not have the time", the problem needs to be broken up into blocks that are describable as start/finish such that one can build up to the final result Anyone have a breakdown on the blocks required?
It would seem that the correct branch is this for micro:bit https://github.com/mbedmicro/DAPLink/tree/freescale
Actually @OwenBrotherwood this is the right place for micro:bit https://github.com/mbedmicro/DAPLink/tree/microbit-0234 (that's the schools drop) and https://github.com/mbedmicro/DAPLink/tree/v0241 (the base that Farnell used for the newer firmware)
So many micro:bits out there and so many people wanting to do cool things with them. We need open-source compilation.
Dunno if this merge of code gives anyone any ideas. https://github.com/OwenBrotherwood/DAPLink/tree/freescale-i-sys
I haven't gone thru the code to see if it needs Kiel
Note: Purely a mechanical operation of google after how to merge one repro onto a branch of another with only one hairy moment https://github.com/OwenBrotherwood/DAPLink/tree/freescale https://github.com/OwenBrotherwood/DAPLink/tree/CMSIS-DAP_IDAP-Link
C:\source\repos\github\OwenBrotherwood\DAPLink>git merge CMSIS-DAP_IDAP-Link
Auto-merging source/common/hal/nxp/lpc11u35/DAP_config.h
CONFLICT (modify/delete): interface/mdk/lpc11u35/lpc11u35_interface.uvproj deleted in HEAD and
modified in CMSIS-DAP_IDAP-Link. Version CMSIS-DAP_IDAP-Link of interface/mdk/lpc11u35/lpc11u35
_interface.uvproj left in tree.
Automatic merge failed; fix conflicts and then commit the result.
error: addinfo_cache failed for path 'source/common/hal/nxp/lpc11u35/DAP_config.h'
C:\source\repos\github\OwenBrotherwood\DAPLink>git mergetool
This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
tortoisemerge emerge vimdiff
Merging:
interface/mdk/lpc11u35/lpc11u35_interface.uvproj
Deleted merge conflict for 'interface/mdk/lpc11u35/lpc11u35_interface.uvproj':
{local}: deleted
{remote}: modified file
Use (m)odified or (d)eleted file, or (a)bort? m
@OwenBrotherwood I'm afraid that branch is so far out of date that it's not much help.
https://github.com/OwenBrotherwood/DAPLink/tree/freescale is a very old DAPLink version, right after the folder structure started being reorganized. https://github.com/OwenBrotherwood/DAPLink/tree/CMSIS-DAP_IDAP-Link is the pre-DAPLink "mbed CMSIS-DAP" project that uses an entirely different folder layout and doesn't use progen.
Neither source branch supported gcc. (Unless I missed something.)
yep: afraid it was so. I just merged in hope and not so much in outright conviction that it would give anything.
At least I learned some more git techniques: I am not a programmer in my day time job (and sometimes it shows :) )
And of course, it doesn't do too much harm to give the issue a bump every now and then.
"Everybody is talking about apathy, but nobody is doing anything about it" :)
Hey, I created eclipse_gcc_arm project and got following error:
11:12:37 **** Incremental Build of configuration Default for project stm32f103xb_nucleo_f103rb_if **** make all mkdir build mkdir: cannot create directory `build': File exists Makefile:135: recipe for target 'create_outputdir' failed make: [create_outputdir] Error 1 (ignored) make: *** No rule to make target '[]', needed by 'build/stm32f103xb_nucleo_f103rb_if.elf'. Stop.
Is it because the generated makefile does not reference to LD script?
I am trying to understand how much work is needed to enable GCC ARM build; I will be grateful for the feedback.
Just like everyone else, I wish to compile a DAPlink with gcc (open software disciple) I've done a search for a gcc ported RTX and have found nothing. I've done a search for port of DAPlink to CMSIS-rtos. Nothing. I suspect folks are frustrated by the amount of work to do the conversion (armcc to gcc), comply with progen (multiple development environments) and unit testing (multiple MPUs). Individual initiatives are not being incorporated back into the master github. The work becomes dated and is divergent. The result is the adoption of DAPLink is being blunted.
To me, to fix this situation, some of the necessary (not sufficient) conditions are:
- to make the code base independent of MDK ARMCC dependencies (support at least gcc, and perhaps clang ).
- to modify the code to support the CMSIS-rtos interface and free the design from just one rtos. ( allow RTX, freertos, others).
- expand github to capture individual contributions and distribute testing to those who have different development and MPU environments. This means project management at some level (time and $).
comments?
DAPLink is created, developed and maintained by ARM MBED Team. They control management, architecture, internals, design and documentation. There are some good news you may want to read at https://github.com/ARMmbed/DAPLink/issues/482 :-)
As stated by @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.
Thank you for the response. Good news. ...and I'm not completely crazy, I'll just use stlink and j-link for now.
But DAPLink works fine already on a wide range of boards, targets and interfaces.. I use it everyday with no problem.. its far more effective than old tools that I have used or even created myself years ago..
What keeps you away from current DAPLink and what would GCC really solve for you @vaughanatworld ?
@cederom For me this question is really easy to answer: The available to build it myself and contribute and thus integrate one in my own circuits. At the moment it's more of a use it on the micro:bit and get a "FRDM board just to drive foreign MCUs" kind of affair...
Sure thing! Looks like it should be here quite soon.. I am waiting for that too :-)
I see that this issue is still in backlog and we are well into Q1 2019 :) Is there any plan/roadmap for this issue? I would like to run DAPLink on not supported yet platform but Keil requirement is showstopper for me.
We are actually making progress towards this goal. The first step was to move to mbed-cli for building DAPLink. This has been accomplished. Right now we're actively working on switching the RTOS, but are having size problems with RTX5 and the bootloader. I'll work on creating some issues and linking them to this one so that the progress is more clear.
Everything was going well until I hit the compile button on Keil and got the "linker" size limit error lol. I have tried the mBed CLI but I keep getting errors about missing json files. I might give it a shot again. Since Since Keil basically belongs to ARM cant they just do like a conditional license where you can just remove the restrictions of the free version to compile DapLink... Isnt Keil professional free to use for Stm32G0/L0/F0 cant Dap run on those? and thus Keil allow us to compile it?
Any news regarding this topic? I would be very interested in porting DapLink to some microcontroller boards which not yet support DapLink. And I definitely need GCC for that ...
Any news regarding this topic? I would be very interested in porting DapLink to some microcontroller boards which not yet support DapLink. And I definitely need GCC for that ...
Not to mention the impossibility to build it on Linux without proprietary tools , because it requires either Keil or ARM Compiler (which is provided free by Mbed Studio, which is not available on Linux...). Supporting GCC will just solve this issue
There is currently no immediate plan to complete the referenced tasks above (RTX5, USB stack - main dependencies on ARMC5).
Switching to RTX5 should not be difficult with the latest changes - my assumption, will need to study further the latest code base here (appreciate any help here, PR welcome). USB stack on the other hand might be more difficult.
