Please support Makefile/CMakefile/Meson/<pick something> command line build system

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
andrewl
Offline
Last seen: 1 year 7 months ago
Joined: 2020-11-05 02:45
Please support Makefile/CMakefile/Meson/<pick something> command line build system

Hi, folks,

 

Can we *PLEASE* get a standard build system to compile this stuff?  It's silly to need to run full IDEs just to compile something that is running the gcc arm tools underneath anyway.

 

I don't really care *which* build system you pick.  I would prefer Meson as you have explicit cross files and Visual Studio Code can pick up the paths directly from the Meson configuration files.  *HOWEVER*, I don't really care all that much--as long as the example has the dependency paths in plain text form, most people can convert to <their favorite build system> and <their preferred IDE>.

 

In addition, it's even hurting Dialog itself.  There are a couple of path issues and some missing files in SDK6.0.14 that would have been caught if you had some continuous integration running from the command line.

 

Thanks.

Device: 
PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi andrewl,

Hi andrewl,

Thanks for your question on our public BLE forum and thanks also for you interest in our BLE solutions.

Could you please indicate the Dialog BLE Device that you are using?

Is it a DA14581 ( as tagged in the initial post), or a DA14531?

Thanks, PM_Dialog

andrewl
Offline
Last seen: 1 year 7 months ago
Joined: 2020-11-05 02:45
Sorry, don't know how I

Sorry, don't know how I missed that tag.  I'm actually using the DA14531.

 

I had to back up to SDK6.0.12 to pick up some of the missing files.

 

Thanks.

PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi andrewl,

Hi andrewl,

Thanks for modifying the initial post.

The pxp_reporter example of the SDK6.0.14. expect from the Keil includes both IAR and Eclipse projects.  

>>>There are a couple of path issues and some missing files in SDK6.0.14 that would have been caught if you had some continuous integration running from the command line.

Can you please indicate the path issues and what files are missing that was included in SDK6.0.12?

Thanks, PM_Dialog

maximilian
Offline
Last seen: 9 months 3 weeks ago
Joined: 2019-02-26 22:01
Thank God. I thought I was

Thank God. I thought I was the only one. Why chip manufacturers always choose to "make life easy" with fancy IDEs but always manage to achieve the oposite is beyond me.

I am struggling to compile the example projects with make/gcc. For my application this is a requirement. It determines weather Dialog is a viable option as a development platform for us. There are a few reasons for this. Continuous integreation as mentioned by Andrew. The ability to script build pipelines with tools that run from the command line. Availability of the build tools (gcc and make can be installed on any respectable system). Reducing the number of dependancies not of the project code, but of the build system itself.

So far I have been able to compile the mass storage device example and the baremetal blinky example.

Doing this was fairly straight forward just a bit of work. I can't tell you if the produced binaries work as I am waiting for the devkit.

Notes:

Device DA1469x

The file bsp_memory_layout.h is included in the project specific custom_config_qspi.h but is not provided in the sdk or example code. I have removed the #include and it seems it's not required anyway.

You must use the -include or -imacros gcc flag to force include custom_config_qspi.h. This is ugly (my personal opinion) because this dependancie is not reflected well in the code. better would be to use a compiler flag to choose between qspi and ram. You can use #error to give some output when the flag is not defined, and the developer can read the code and be made aware of the possible options.

The msc example requires that you modify the sdk files (as indicated by the documentation)... This is also not so nice, since it means neither the sdk nor the example will compile out of the box. A huge turn off. There is nothing worse than examples that don't compile... except maybe examples that rely on precompiled closed source binaries ;).

Speaking of which, libble_stack_da1469x.a has an undefined symbol for crypto_init. However I cannot find any code that defines it. Where is it defined? This seems to be the last missing piece to get the ble examples to link/compile. Please let me know what additional information I can provide.

andrewl
Offline
Last seen: 1 year 7 months ago
Joined: 2020-11-05 02:45
You're not alone.  The C guys

You're not alone.  The C guys like us trying to use our standard "Entrprise/Desktop" (read: *PROFESSIONAL*) development tools just aren't very well organized so it feels like there's nobody out there.

 

If I'm being a touch uncharitable, the Dialog tools are sufficiently painful that it scares people off.  We won't develop anything first on Dialog--we will only port something that has already been debugged on a much more friendly BLE system.

 

However, go check out the Rust Embedded guys.  They've been laying down a *LOT* of groundwork to try to use Rust on embedded, and that includes a lot of groundwork that makes running basic C much better for both Cortex-M as well as RISC-V.  I've made a lot of use of their stuff when coupling to Visual Studio Code. 

https://github.com/rust-embedded

Chat system: https://app.element.io/#/room/#rust-embedded:matrix.org

 

Dialog is particularly painful for me to convert to command line as chips like the DA14531 call into ROM for its BLE stack.  That's not a typical thing to do, so standard Cortex-M command line tools, debuggers, and examples really aren't set up for that.  That also causes fairly weird organization of code as everything *must* be callback-based.  I still don't have things distilled to command line (read: Meson/Ninja) yet.

 

The whole IDE thing is particularly annoying to me as practically the only reason I use something like Keil or Eclipse is to run the debugger.  As code editors/navigators, they're *terrible* environments.

 

If you get the command line working, Maximilian, do us all a favor and upload it to something like Github, if you can so we can all beat on it.  That would be much appreciated.

 

Thanks.