Harmony编写实际生产代码的问题怎么解决

当plibs中没有PIC32MZ支持时，我着手重写我所有的旧代码，以便不依赖于任何微芯片库。编译器包中应该包含的内容在Harmony中被隔离，以尝试并强制采用，比如支持MZ ASE的缓存管理或DSP库。我将我需要的片段作为独立的源文件输出。自从发布Harmony以来，我一直关注它，但是对于它的缺陷和不稳定程度没有丝毫印象，尤其是阅读关于它们如何开始做真正不可原谅的事情，比如完全误导的func。tion名称（例如，显然有一个I2C调用，该调用的名称中包含“wait”一词，该名称用于在返回之前等待事件完成，但不再这样做）。对于框架代码采用这种方法的权力来说，它被认为是可以接受的，这让我非常确信它将会有一个非常不稳定的未来。我认为，在Harmony走上可视化设备初始化器的道路之前或在它之前的plibs只是时间问题——这两个工具都非常强大。提出了采用收养和开发便携式/更容易，但这两件事最终被EOL代替。

这是一个令人印象深刻的壮举。正如你所说，MLA的图形库需要硬件专用的驱动程序，而且接口也定义得很好，这正是三年前我为LCD所做的。虽然我确实花了一些时间优化MRF WiFi-G SPI驱动程序（一倍以前的吞吐量不亚于！）这只是一个调整的练习。我害怕尝试让旧的TCP/IP栈与MZ一起工作的原因是它是不同的设备，还是以太网外围设备与MX上的那些设备一样？关于MLA的另一件事是命名空间，或者缺少它们。和声所做的一件事就是提供所有栈的整合。必须合并，比如说，在MLA上的USB和以太网栈不是一个轻而易举的工作。曾几何时，有一位微芯片公司的员工发布了一些示例代码，实现了这个功能，但是很遗憾，它似乎被撤销了，再也找不到了。你的努力。我不确定MLA在中长期内继续下去是否合适，它已经变得相当像意大利面条，没有多少共同的方向和大量的糠秕。取而代之的是，和谐，是一个象牙塔项目肥胖的爱孩子，试图成为一个杰克所有的行业，但几乎没有一个主人。我们已经过了两年半的时间，它仍然充满了bug，而让您的第一个程序工作的入门门槛远低于它的介绍，这主要归功于MHC（它也有自己的挑战！）接下来的步骤更像是进入黑暗的一步。关于收养，远非和谐鼓励收养，我绝对肯定这会让人们推迟收养。必须学习一个只适用于一个供应商设备的子集的新的复杂框架并不是一个卖点。虽然可能有一些营销输入（当然，当我读了“整体”和“更快的上市时间”&“畏缩”）时，我认为更可能是一个操作系统软件学者的结果，他们不知道烙铁的一端。

a)我尝试使用和声思想，尽可能地采用和声的方式，因为与它作斗争似乎会导致比它的价值更多的麻烦。b)我在记忆库中保存了一份“上游”和声的纯拷贝。当我从微芯片上得到一个新的“上游”版本时，我会更新它。我分叉上游版本并创建一个工作副本，在这里我根据需要进行更改，以修复一些损坏的东西，实现任何我想要的新驱动程序等。当新的上游版本出现时，您将更新并合并补丁。国王代码我保持这是在一个单独的文件夹MyApps/和谐树下。这被添加到.ggNebe中，所以Mcururi对此一无所知。我在这里进行标准的应用程序开发，并在自己的git存储库中维护每个应用程序（我混合了git和hg，因为我确实想使用git，但是它对2GB的和谐管理不是很好）。我避免这种情况的一种方法是，例如，我向图形核心forGFX_HGC_MessageCallbackUSER()和GFX_HGC_DrawCallbackUSER()添加了两个额外的回调；这些回调是在内置回调之后触发的，但是这样允许我创建一个单独的.c文件，在其中放置所有内容没有自动生成的图形特定的处理代码。因此，我从来不需要在gfx_hgc_definitions.c中到处乱窜，我只需要将所有应用程序代码添加到自己的文件中，从而可以重新生成新的屏幕或其他和谐配置器位，而不会出现任何合并问题。但它们只是存储库中的简单补丁，当新的上游出现时可以简单地对其进行更新。

我同意MLA TCP/IP库比图形库要难得多，它编写为演示代码要比使用API的真实库难得多。对于以太网，我们使用的是ENC28J60部分，它只需要一个SPI接口，所以对CPU硬件没有真正的依赖性，MZ上的SPI和MX上的SPI相同。MLA支持的ENC28J60不受Harmony支持。当我谈到MLA中的bug修复时，这主要是在TCP/IP栈中。在框外，MLA TCP/IP堆栈是可靠的99%。对于我们来说，这意味着有数十个站点没有正常工作，每个站点都有自己独特的设备和配置，以及独特的问题。每个问题站点通常涉及站点访问、一周左右的分析，以及代码更改来解决问题。总共花了大约一年的时间将可靠性提高到99.9%。从我正在阅读的和谐栈可以在99%的可靠性范围在其目前的状态。