1 起源 - 关于Halim的设想

       Halim原意为硬件抽象层交互模型（Hardware Abstraction  Layer Interaction Model）的英文缩写。硬件抽象层交互模型本身也不是哪里标准的词汇，之所以堆砌这个词源于思考产品气体闭环控制器的新框架之初，期望能够做到从硬件层就进行抽象，让交互建立在统一的平台之上，从而可以摆脱产品在变更和升级过程中牵一发动全身的弊端。气体闭环控制器从2012年末到2015年初，经历了多个版本的迭代，但由于可靠性和功能上不完全满足市场需求等原因，到最后仍然未能够顺利推向市场。闭环控制器产品的研发过程，让我从电路硬件设计细节，到软件框架，乃至产品架构上思考甚多。闭环控制器多次迭代之后，最后发现其最致命的问题来自于最初的定义，越是往后走，问题越是不可收拾。尝试寻求新的解决办法，决定重新设计产品框架，将硬件抽象出来，把功能在其抽象后的标准上进行定义。可是，除了现代的通用计算机框架，如我们所熟悉的，PC、嵌入式ARM、WinCE、Linux、Arduno或者树莓派等等之外，似乎找不到其他更好的参考。直觉上，我不接受这个通用的框架，当然，如果你问我到底想要什么样的一个东西，那时估计我也说不清。因此，Halim被创造出来，寓意这是一个和上面所述不一样的抽象模型，于是，后面一切的设想就被纳入Halim的范畴。Halim的设想诞生之初，离现实其实很遥远，离落实到具体的产品更是奢望。所以，有大约半年的时间，Halim并没有什么进展。

       关于Halim设计的第一次尝试是在2015年7、8月份。将硬件从功能定义上抽象出来，按照已有的思路就是将先建立一个电路硬件无差别的统一框架，这个框架表现为硬件电路板是在规定功能之后才被创立，然后无缝接入已有的系统中。整个系统从硬件上看，是一个分布式的形态。产品总的功能被打散为各个局部的功能模块，每个子功能模块一方面实现自己负责的功能，另一个方面是与其他功能模块进行交互。为了让这个板间分布式系统工作起来，第一个Halim法则（Halim法则1）被建立，描述为：当X卡向Y卡请求数据时，Y卡把自己的X数据段的数据发给X卡，X卡将收到的来自Y卡的数据存在Y数据段。这个法则期望功能卡之间的交互原则是，每个卡只负责好自己，便能在这个新世界自由畅行。

       尽管这是当时自认为最好的模式，如可能不需要第三方的仲裁机制，便可以将硬件一开始从具体功能中抽象出来，以统一的交互法则，将不同的模块接入进来，从而不断拓展。表面一看，似乎解决了核心问题。那时在激动和期待中，写了一个软件对这个法则进行模拟。但模拟中发现，不需要第三方的仲裁机制是不现实的，于是为了修补这个漏洞，添加了T表机制。T表机制的存在，导致了本来的期望几乎崩溃，原因是把本来期望的每个卡节点只负责自己，折中变成了需要添加必要的限定，添加第三方路由管理，从而导致内部产生了相对复杂的交互行为。在规定功能节点初始化的步骤中，必须小心翼翼，甚至为实现自由插入和交互，还必须要添加更多的细节限制，如自由地址分配机制等来限定异常行为。除了行为管理复杂以外，仿真还发现，法则1还导致功能定义被限制了，原因是为了实现路由，法则的本身已经将数据分区管理，并且关联T表，与内核功能绑定，导致内部太多耦合，拓展的消耗成本面临指数级增长风险。

       Halim设计的第一次尝试，虽然仿真表明基本实现了Halim的基础，内核被设计了出来，并且硬件被抽象出来，成为交互平台，不能说有错误，但是如此的堆砌，如同缺乏灵魂思想的创造，生涩、僵硬、找不到无限展开的生命力。是继续推进硬件实验，还是另觅他路，一时还有点迷茫。或许灵魂就在那里，找便是了。

(未完待续)