[参考译文] TM4C1294KCPDT：从另一个应用调用一个应用中存在的函数

Naman、

我假设该函数将驻留在引导加载程序部分、对吧？ 否则、引导加载程序将依赖于"main"应用程序、这会很奇怪。

有趣的问题、答案是肯定的。 但是、我只能考虑有关如何实现该目标的理论步骤：

-您需要确切地知道函数的驻留位置。 当然、可以使用某种链接器指令来实现这一目的。

-在不包含函数的应用程序上，您需要一个 extern 声明来组织参数和返回类型，可能需要一个宏来将调用定向到该固定地址。

虽然没有人提供更直接的答复，但有两项建议需要进一步考虑：

- Tivaware 函数包含 ROM_CALLS、这基本上是相同的情况：在本例中、运行位于"其他地方"的代码、在 ROM 中、而不是不同的闪存地址。 尝试查看 ROM_CALLS 在 Tivaware 中的工作原理、部分目标将得到解答。

- CC2650 Launchpad (具有蓝牙/无线电和专用 ARM MCU 的芯片)的示例在同一 MCU 中使用两个单独的项目进行编译：一个用于蓝牙堆栈、另一个用于应用本身。 他们使用这种交叉调用概念。

期待您在此处进一步了解您的发展！

此致

布鲁诺

(有时)"想法简单"证明"简单"是"最好的"是不是可能的？

根据这些(可能)"共享"函数的大小和数量、将此类函数与"两种"应用程序一起放置的速度更快、更简单、更好"、这是不是吗？  (这样就消除了您注意到的所有复杂性-以及(仍然是正确的)问题。)

当您报告说、"成功实施"是否在所有潜在的运行条件下(真正、正确)测试/验证了"成功"？    (甚至那些被认为是"罕见/不可能"的人？  (直至出现)

您以"代码大小缩减"换取了"响应缓慢"和"增加了复杂性"、所述的实施在"特定"运行条件下可能"易受影响"。  (假设多个中断从(每个)分离的函数到达(实时)。)

请注意、即使供应商(看起来)使用了这样的(共享函数、代码设备)、我们也不知道他们的动机和限制、也不知道(实际上)他们有多全面(测试/验证)！    错误报告、勘误表、甚至 API"修复"-所有这些都表明(甚至)供应商可能"偶然"。

"风险奖励"必须在此处扮演(部分)角色-"奖励"似乎(不)过于引人注目-并且风险(超出已确定的风险)可能等待发现...

你(们)好。

请注意"第2至最后"一段 我刚刚编辑/添加了。

了解"如何"增加复杂性-同时"邀请"风险-可能会非常伤害您！   (VCS 特别努力搜索-识别-然后"输出"大多数此类实施！)

我建议、这份深思熟虑且有才华的海报可以通过向他的计划/项目添加真正的功能来获得更好的效果-而不是通过(尝试)"节省"几 KB！

您好(熟练)供应商朋友 Charles、

谢谢-非常感谢！   (我最好的猫王——除了我的意思。)

我观察到、"并非总是"做海报问题/问题、引导他们(高效或安全地)进入"承诺的土地"。   作为一个具有(或许)比大多数技术 Biz 经验/成功更多的人-我尝试建议"替代方法/方法"-我知道这是"成功的"。    (当我感觉到海报"接近"高悬崖时出现)

我最常"证明/支持"这些建议-以便逻辑(希望)发挥作用-提高海报的信心和接受程度。    (此类方法有助于公司赢得销售和增长...)

我可以用这一时间感谢您和 Bob (每天)为您提供的巨大努力和帮助吗？    你们两个人非常感谢   再次感谢！

我的朋友-我已经尽可能地进行指导和报告-您提出的方法不是我可以支持或推荐的方法。

特别注意的是、"这是一项要求！"    为什么是这样？    谁设定："这种要求？"    而且-他/她/团队是否充分意识到、熟练并"投资于"这种额外复杂性的后果？

请注意、我已经传达了(高度)熟练的指导/建议、即(非常)有能力、意识、实现(其他)-他们"不怕投资大笔资金"-但(仅限于)风险-奖励方程 在很大程度上倾向于"奖励"。    您的-不幸的是-没有！  

的确，查尔斯，正如我所指出的那样，"太频繁"海报问题/问题是"接受和采取行动"的，没有先问"海报(选择/倡导)的道路是否有意义？"

海报"在这里迎风"、因为(最常见的)他们"不知道！"    然而，他们的"建议或期望的"攻击方法"往往是(赦免)，"不被批判地接受--并采取行动"。

公司/我致力于防止这种情况发生、因此这就像是"在一个桶中拍摄鱼"。 (鱼很大-桶很小- CB1很难错过！)

[报价用户="Naman Kumar"]您是否会参与风险[/报价]

非常简单：风险是、这种想法根本不起作用、或者需要大量时间来实施、或者它会引入在开发过程中可能未发现的未知错误、 只有在极少数因素组合出现且产品已上市时、才会出现这种情况。

这个想法的专业人士：
-这将节省一些闪存存储器(但实际上，这些函数需要多少闪存？ 这种节省是否会对 TM4C129x 产生影响？？？？)

Con：
——无论实施情况如何，它都会减慢执行速度
——事情会令人困惑
——调试起来会非常困难

您的"所有者"是否需要更多参数？ 您使用了"要求"一词、这种说法经常会混淆... 要求是市场上功能可靠的产品。 发展过程中的许多其他选择都与如何实现这一目标有关，而且往往不是必须采取的路线才能实现命运。

您好、Naman、

我要考虑的另一个问题是：我假设您知道您的功能可以在一个位置"创建和维护"、对吧？ 最好将所有受信任/经验证的函数收集到一个静态库中、并在具有适当#include 的各种应用程序中使用它们。

当然、您的两个项目都在闪存中有自己的汇编代码-但至少您使用的是"相同的经实践检验的函数"。 当源文件是常见的代码段时、我尽量避免将它们实际复制到我的项目中-这与使用 Tivaware 库的概念几乎相同。

布鲁诺

您好、Bruno、

你是对的。 但我在阅读你的答覆后，还有另一个问题。

我们使用 ROM_FlashEras()等类型的库，这样我们的应用程序就可以使用 ROM 中已经存在的库，这样 ROM 中的这些已验证函数就不会与应用程序一起编译。 这当然是为了保存闪存。 这是如何工作的？ 就像我没有使用我的代码编译 ROM 库一样、但它仍然可以使用 ROM 库。

我尝试执行相同类型的操作。 使用其他位置的函数、这些函数不是使用我的应用程序编译的。 请解释一下。

或者、ROM 库可能具有特殊状态、可从任何位置使用。 但我们无法在闪存中执行相同的操作。

此致、

那曼

[n`t user="Naman Kumar">您需要非常小心、并确保主程序不会遇到它所知的任何问题。 [/报价]

相信这些"两个注意事项"是最明智的。

到目前为止、"如此有限"的测试/验证是否能够执行(结果是"它正常工作！") 完全/正确接受/计数？    特别是考虑到第2项限制(上文)和其他多项限制----尚未抵达/注意到。

仍然保持沉默-这种需要(任何)是正当的！   已引入风险要素-计划开发(已经)缓慢-这是(肯定)推动投资者/利益因素、"Krzy！"

这些"兴趣点"是不受限制的、即如何及何时允许此类"改道"、以及如何进行调查/采取行动、因为它们 (必然)会将时间/精力从"中心任务"转移过来。   (此类(可能)是此处的"真正主旨"、但对于"风险回报"分析(之前建议)、仍然是掩码！)

[引述用户="Bruno Saraiva"]事实真相是，我更喜欢既不在我的时钟上也不在我的资金上发生这种情况！[/引述]

您的"偏好"-如 Bruno 所述-非常适合您担任技术经理和/或技术投资者！   

假设"这里的大部分"(可能)是："人员不足、资金不足、项目需求估计不足"不是、"关注项目的本质"假设"最优先？"

我们是否应该注意到过去的"要求"最可能来自(过于)好奇的海报-而不是来自某些"虚拟"老板/投资者？   (部分)需要遵守纪律。   (很无聊...)

说 Robert -我听到的是"正确的"-您正在向前10位"保持半日间"的人提供"免费"(但稍微有点被压根/用过)的 Launchpad (当然是由该山的跌落引起的)-以及(永远)"治愈"这样的"渴望攀登"？   

[引用 user="Naman Kumar">您是否会因为实施而面临风险、以便我可以与我的小组讨论相同的问题？ [/报价]

让我们看看(非详尽)

• 可能丢失编译时间检查(取决于您使用的方法)
• 如果再次在紧密环路中使用、可能会损失速度、具体取决于所使用的方法
• 过时版本
  • 调用方可能需要被调用版本不支持的功能(请注意、这也可以反向工作)
  • 被称为应用程序的应用程序也可能有错误
    • 您必须强制对被调用的版本或进行更新
    • 呼叫者必须包含较早版本的修补程序，而被呼叫者必须为较旧的呼叫者提供允许
  • 这意味着在这两种情况下都必须有某种机制来确定被调用应用程序的版本和功能
• 应用程序之间的环境不匹配

我可以考虑 四种支持这种手动中断、函数表、不完整的链接和解释器的方法。 过去、嵌入式编译器直接支持不完整的链接方法的情况并不少见。 考虑到我目前为止没有找到需要调用 ROM 函数的可用内存量(以及不调用的原因)。 这样做有正当的理由、但除非这是一次教育活动、否则您可能不想一时兴起解决这个问题。

Robert

[引用用户="Robert Adsett"]......移动的山区设法避开了登山者、但她被切断了、不得不等待天气才能救援。   抱歉、没有 Launchpad。[/quot]

拯救那些(类似地)"被切断"或其他"被炸/被弄糊涂"的人很好地描述了我的"工作人员招聘 M.O."  (尽管联合搜寻"永远不会被发现"(丢失)的小狗-土地接近第二个...)

很遗憾看到您拒绝了"dinged" Launchpad。   工作人员/我(特别是)愿意接受那些"受石头袭击"的单位，这些单位感激和 (自发)弹出了他们的"魔鬼" 0Ω(9、10里拉"瘟疫")！  

(如果没有错的话-朋友/海报/登山者 Bruno 是"现场"-并且看到了-要求一个"米！" (笑声) 来计算"下降"岩石的 dV/dt。)

M.O.  作案手法  (犯罪意图者(通常)使用的(可识别的)正常技术/方法-尽管不限于(该)努力领域...)