在Linux上构建例子

4个帖子/ 0新
最后一篇
ratsept
离线
最后一次露面:6年2个月前
加入:2015年4月13日10:43
在Linux上构建例子

你好,

我刚开始尝试在DA14580,我似乎处处击中墙壁。我跟着AN-B-024的指令,花了一整天追着试图在Ubuntu上建立和例如用GCC和仍然没有运气怪异的问题。我似乎已经得到了一个地步,代码编译,并得到什么好像只是ROM连接仍然失败链接阶段。

我从DA14580_581_SDK_3.0.8.0/dk_apps/keil_projects/proximity/prox_reporter示例开始,并使用转换器脚本生成一个Makefile。我删除了奇怪的树优化标志,并修复了程序集文件扩展名的问题(*。年代和* s)。还有一些Keil特定的编译器魔法(__INLINE vs static inline…),但现在我很好,真的卡住了。这个例子似乎是在引用ROM中的代码,无论出于什么原因,这些代码都被注释在SDK附带的符号表中。

这是化妆的部分输出链接...
>>>
LINK输出/ full_emb_sysram.axf
./../../../src/plf/refip/src/arch/main/ble/jump_table.o:(jump_table_mem_area+0xb0):未定义参考`ke_task_init_func”
./../../../src/plf/refip/src/arch/main/ble/arch_main.o:在功能`main_func“:
arch_main.c :( text.main_func +均为0x88):未定义参考`patch_llc_task”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x4):未定义参考`l2cc_pdu_recv_ind_handler”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x8):未定义参考`smpc_send_pairing_req_ind”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0xc):未定义参考`smpc_check_pairing_feat”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x10):未定义参考`smpc_pairing_cfm_handler”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x14):未定义参考`my_llc_con_update_req_ind”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x18):未定义参考`my_llc_ch_map_req_ind”
../../../src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x1c):未定义参考`patched_gapm_adv_op_sanity”
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld:出/ full_emb_sysram.axf:隐藏符号`smpc_pairing_cfm_handler”没有被定义
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld:最后一个环节失败:错误值
collect2:错误:LD返回1个退出状态
使:*** [出/ full_emb_sysram.axf]错误1
<<<

ke_task_init_func似乎是在符号文件,但被注释掉。
patch_llc_task是存在于SDK一个目标文件,但该链接,所以我不知道发生了什么有重叠的一些代码...

你能指出我朝着正确的方向,或者至少给我一个线索,其中的例子是最好测试一下我的系统。从我读过什么人都没有多少运气与GCC和你的筹码,但既然我们已经有很多不同BLE SOC的工作,大多是经过一番痛苦,我们已经能够让他们的工作,我不希望放弃自己的妹妹。当你有一个应用笔记,似乎至少有一些努力投入到支持GCC也许还有希望。我会很高兴的开源我们的努力,当我们得到的东西的工作。

关键词:
je_dialog.
离线
最后一次露面:3个月4天前
职员
加入:2013-12-05 14:02
您好,我会诚实

您好,我会诚实地表明,现在,我们不是在一个位置,提供580我们的下一个平台(680)上的广泛支持GCC,我们刚刚宣布会有所不同,但除了几个客户我们正在支持一对一的GCC,其不支持,我们可以在一个一对多的形式,现在报价..道歉,如果这不是你想什么,听到的,但我更喜欢说实话,不设置不切实际的期望。BR JE_DIALOG.

je_dialog.
离线
最后一次露面:3个月4天前
职员
加入:2013-12-05 14:02
您好,我会诚实

您好,我会诚实地表明,现在,我们不是在一个位置,提供580我们的下一个平台(680)上的广泛支持GCC,我们刚刚宣布会有所不同,但除了几个客户我们正在支持一对一的GCC,其不支持,我们可以在一个一对多的形式,现在报价..道歉,如果这不是你想什么,听到的,但我更喜欢说实话,不设置不切实际的期望。BR JE_DIALOG.

ratsept
离线
最后一次露面:6年2个月前
加入:2015年4月13日10:43
这是很可悲的消息。一世

这是很可悲的消息。我真的觉得我很接近得到这个例子来构建(虽然我不知道,如果它实际上在任何硬件上运行)。我对一个没事就一个帮助,可如果这是你可以做的。我会怎么做才能得到这样的帮助呢?我有项目来了,可以进入批量制造,如果这是你所追求的,但现在我们正在做我们的大部分与北欧的SOC工作(价格和功耗是我们正在设法优化与硬件)。

我何时会看到680系列的样品和开发工具?我在尝试了许多不同的解决方案,尽可能我们做了很多BLE原型和需要的是对事物的顶部,尽可能真正感兴趣。