在Linux上构建示例

4个职位/0个新职位
最后一篇文章
拉特斯普特
离线
最后一次见到:5年8个月前
已加入:2015-04-13 10:43
在Linux上构建示例

你好,

我刚开始在DA14580上做实验,好像到处碰壁。我遵循AN-B-024的指令,花了一整天的时间研究奇怪的问题,试图在Ubuntu上用GCC构建和示例,但仍然没有成功。我似乎已经到了这样一个地步:代码编译到了链接阶段,而ROM链接仍然失败。

我从DA14580\u 581\u SDK\u 3.0.8.0/dk\u apps/keil\u projects/appricity/prox\u reporter示例开始,并使用转换器脚本生成Makefile。我删除了怪异的树优化标志,并修复了程序集文件扩展名大小写(*.s和*.s)的问题。还有一些Keil特有的编译器魔力(内联与静态内联…),但现在我完全被卡住了。这个例子似乎引用了ROM中的代码,不管出于什么原因,这些代码在SDK附带的symbols表中被注释了。

这是make。。。
>>>
链接输出/完整emb_系统内存.axf
../../../../../src/plf/refip/src/arch/main/ble/jump\u table.o:(jump\u table\u mem\u area+0xb0):未定义对“ke\u task\u init\u func”的引用
../../../../../src/plf/refip/src/arch/main/ble/arch\u main.o:在函数“main\u func”中:
主拱门c:(。text.main函数+0x88):未定义对“patch\u llc\u task”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0x4):未定义对“l2cc\u pdu\u recv\u ind\u handler”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0x8):未定义对“smpc\u send\u pairing\u req\u ind”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0xc):未定义对“smpc\u check\u pairing\u feat”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0x10):未定义对“smpc\u pairing\u cfm\u handler”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0x14):未定义对“my\u llc\u con\u update\u req\u ind”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0x18):未定义对“my\u llc\u ch\u map\u req\u ind”的引用
../../../src/plf/refip/src/arch/main/ble/arch\u patch.o:(。rodata.patch\表+0x1c):未定义对“patched\u gapm\u adv\u op\u sanity”的引用
/usr/bin/../lib/gcc/arm none eabi/4.9.3/../../../../arm none eabi/bin/ld:out/full\u emb_系统内存.axf:未定义隐藏符号“smpc\u pairing\u cfm\u handler”
/usr/bin/../lib/gcc/arm none eabi/4.9.3/../../../../arm none eabi/bin/ld:最终链接失败:错误值
collect2:错误:ld返回1退出状态
品牌:***[外/满_系统内存.axf]错误1
<<<

keu task\u init\u func似乎在符号文件中,但有注释。
补丁llc\u任务存在于SDK的一个对象文件中,但是链接与一些代码重叠,所以我不确定那里发生了什么。。。

你能给我指出正确的方向吗,或者至少给我一个线索,哪一个例子最适合测试我的系统。据我所知,人们对GCC和你的芯片没有太多的运气,但由于我们与一系列不同的BLE-soc进行了合作,大多数情况下在经历了一些痛苦之后,我们已经能够让他们工作了,我现在还不想放弃。既然你有appnote,而且似乎已经在支持GCC上付出了至少一些努力,也许还有希望。我很乐意当我们有了工作的时候,把我们的努力开源。

关键词:
JE\U对话框
离线
最后一次见到:3天12小时前
工作人员
已加入:2013-12-05 14:02
你好,我很诚实

您好,我将诚实地指出,现在,我们不能提供广泛的支持海湾合作委员会对580。我们刚刚宣布的下一个平台(680)将有所不同,但除了我们在GCC上支持一对一的少数客户之外,我们现在不能以一对多的格式提供它的支持。。抱歉,如果这不是你想听到的,但我宁愿诚实,而不是设置不切实际的期望。BR JE\u对话框

JE\U对话框
离线
最后一次见到:3天12小时前
工作人员
已加入:2013-12-05 14:02
你好,我很诚实

您好,我将诚实地指出,现在,我们不能提供广泛的支持海湾合作委员会对580。我们刚刚宣布的下一个平台(680)将有所不同,但除了我们在GCC上支持一对一的少数客户之外,我们现在不能以一对多的格式提供它的支持。。抱歉,如果这不是你想听到的,但我宁愿诚实,而不是设置不切实际的期望。BR JE\u对话框

拉特斯普特
离线
最后一次见到:5年8个月前
已加入:2015-04-13 10:43
这真是个不幸的消息。我

这真是个不幸的消息。我真的觉得我很快就可以构建这个示例了(尽管我不知道它是否可以在任何硬件上运行)。我也不反对一对一的帮助,如果你能做到的话。我要怎么做才能得到这种帮助?我确实有项目即将进入批量生产,如果这是你所追求的,但现在我们正在做我们的大部分工作与北欧SOC(价格和功耗是我们试图优化你的硬件)。

我应该在什么时候看到680系列的示例和开发工具?我真的很有兴趣尝试尽可能多的不同的解决方案,因为我们做了很多可扩展的原型,需要尽可能多的事情。