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?
谢谢，下午好
对不起，我不知道我怎么漏掉了那个标签。实际上我用的是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中包含的路径问题以及缺少哪些文件？
谢谢，下午好
感谢上帝。我以为只有我一个人。为什么芯片制造商总是选择用别致的ide“让生活变得简单”，却总是设法实现这一目标，这让我无法理解。
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标志来强制include custom\u config\u 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,lible\u stack\u da1469x.a有一个未定义的crypto\u 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之类的东西上，如果可以的话，这样我们就都可以打败它了。我将不胜感激。
谢谢。