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
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.
你好,一个ndrewl,
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
对不起,我不知道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.
你好,一个ndrewl,
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
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
文件bsp_memory_layout.h包含在公关oject 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.
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.