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.
谢谢。
Device:
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?
谢谢，PM_DIALOG.
对不起，不知道我是怎样错过的那个标签。我实际上是使用da14531。
我不得不备份到SDK6.0.12以挑选一些丢失的文件。
谢谢。
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.
您能否注明路径问题以及缺少SDK6.0.12中包含的文件？
谢谢，PM_DIALOG.
感谢上帝。我以为我是唯一一个。为什么芯片制造商始终选择“让生活轻松”与花哨的ides，但总是设法实现过度的过度。
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.
您必须使用-include或-imacros gcc标志来强制包含custom_config_qspi.h。这是丑陋的（我的个人意见），因为这个依赖性在代码中没有很好地反映出来。更好的是使用编译器标志选择QSPI和RAM之间。您可以使用#Error在未定义标志时给出一些输出，并且开发人员可以读取代码并了解可能的选项。
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有一个未定义的crypto_init符号。但是，我找不到定义它的任何代码。它在哪里定义？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.
你不是一个人。C伙伴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.
整个IDE的东西对我来说尤其令人烦恼，就像我使用像Keil或Eclipse这样的东西的唯一原因是运行调试器。作为代码编辑/导航器，它们是*可怕的*环境。
如果你得到了命令行，Maximilian，请让我们所有人帮助，并将其上传到像Github这样的东西，如果可以，我们都可以打败它。这将非常感谢。
谢谢。