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%的可靠性范围在其目前的状态。

你认为和谐会有所不同？我在固件游戏中已经有很长一段时间了，我知道这些事情是如何发展的。当代码最初开发时，你得到了一个团队的工作。他们很有经验，想出了一个有凝聚力的设计，所有的团队成员都明白整个设计。然后，随着时间的推移，A团队转移到下一个草图设计，较新的团队成员对原始设计没有那么好的知识，并且开始做出不适合的更改。然后，你让小家伙分配bug修复并做一些次要的功能添加。他们没有经验，了解整体设计，有较差的编码技能，并作出糟糕的设计选择。我相信MLA会走这条路，随着Harmony变得更加复杂，设计也更加难以理解，我认为这个代码会走得更快。

如果您有一个基于MLA的产品代码，不要打扰它。如果您的产品发展需要集成多个栈（TCP/IP、USB、GFX）或者需要RTOS，请相信我……使用Harmony。如果你是在设计中使用Atmel部件，你必须重新编写整个MLA软件。和谐是底层的变化，和谐让你先行思考，这是我个人的观点……当然。

与和谐，它只是应该是膜层。这比那更复杂。Exspecialy从API到底层的文档记录不足，从版本到版本都发生了变化。

看起来人们并没有像使用Harmony那样使用抽象层，而是使用Harmony中包含的以太网、USB和图形模块，然后他们只需要尽可能多地引入Harmony来使这些模块工作。如果有单独的以太网、USB和图形模块，人们本身就不需要任何和谐。

一点也不奇怪。自顶向下模式下的应用程序设计需要框架、驱动程序和工具，它们可以毫无问题地工作，并且支持要解决的任务。协调引入非常不同的开发模型，它不支持现有的经验，也不支持移植现有的软件。e，使得接受缓慢。此外，在处理硬件外围接口时，由于和谐外围层中的残酷抽象，许多工作并不容易。相反，和谐引入了PIC32 MZ和MX与PIC24的区别……DSPIC…家庭，甚至在外围设备几乎相同的地方。这将是新一代的开发人员，他们不熟悉SFR编程，不能阅读和理解PIC数据表和家庭参考手册，他们更喜欢和谐而不是STSFR编程。使用符号的SFR编程由设备支持文件定义的lic常数和结构已经是硬件的抽象。实际上，设备支持文件在PIC硬件寄存器上提供了两种不同的抽象。“typedef struct”定义，支持表单的表达式：OSCCONbits.SOSCEN=1；..._MASK、..._POSITION和..._LENGTH常数，支持这种表达式：OSCCONSET=_OSCCON_SOSCEN_MASK;是同一硬件的两个不同抽象，由相同的设备支持文件支持，并且跨越整个PIC设备范围，没有模糊、没有丑陋的警告，也没有穿透关于蜂鸣已经过时。设备家族之间的符号有一些差异，主要与数据表中术语的差异有关。即使这样，设备支持文件也大多提供覆盖这些差异的别名符号。而且，许多设备支持带有mul的设备的文件。每种类型的tiple设备都提供别名符号，以便与只有一种外围设备的设备兼容。目前，我看不到使用Harmony低级抽象的明显好处。为了实现Harmony提供的抽象的可能好处，Harmony将需要为了证明它能够支持PIC24…、dsPIC器件、PIC18芯片和Atmel微控制器与兼容的应用编程接口。在微芯片内部似乎存在一些内部竞争。采用高级abst进行自上而下的和谐开发工具。虽然MCC使用更传统的PIC微控制器来处理硬件和更高的模型。目前，这两个组都有足够的工作来支持他们工作的设备家族，但是我看不出为什么和谐不能为PIC24以及d dsPIC。正如没有理由为什么MCC不能用于PIC32MX和MZ一样，可能除了人员配置和资源之外。在这个过程中，它们将导致不兼容的应用程序编程接口。例如：DRV_I2C_TransmitThenReceive(句柄、地址、*writeBuffer、writeSize、*readBuf)。fer,readSize,*Context);I2C1_MasterWriteRead(*pWriteData,WriteLength,*pReadData,ReadLength,Address,*p.);然后，Harmony函数期望地址参数为8位或11位格式，而MCC函数调用期望I2C地址为7位或10位表示。armony提供了关于地址参数需要什么格式的任何清晰文档。MCC尽管在生成的头文件中有示例代码，说明它希望Micro.24AA512 EEPROM响应地址：0x50。RESe= 0xDeto地址，否则未指定的从属。MCP7940N恰好有一个7位的I2C地址==0x6FAnyone，能够给出一个好的理由，为什么具有以下寄存器的设备需要不同的软件框架？问候，Mysil

PIC18没有所有者来处理额外的代码和谐层。我猜想很多PIC24也不能提供动力。Harmoney团队更喜欢优雅而不是裸露的金属效率。虽然我发现一些MCC代码臃肿。它至少是工作代码。两者都有一些理论，可以保护程序员不受低级代码的影响。奥尔迪诺嫉妒？但让你和Aurduino一样，在互联网上寻找潜水员。试图加快CPU，以克服效率。我也不介意，我介意微芯片认为他们现在可以停止编写示例和文档了，因为您不再需要它了。