高速TINI设计需要从较慢的非易失性闪存初始化快速RAM

来源：analog 发布时间：2023-08-28

摘要： 在DS80C400之前，受DS80C390处理器的最高速度限制，TINI 系统的最高运行频率限制为40MHz。随着DS80C400上75MHz的承诺，支持被添加到TINI固件中，以允许系统以允许的最快晶体乘子运行。然而，为了使系统经济实惠，TINI参考设计(TINIm400和TINIs400)并没有设计在这些高速下运行。许多开发人员试图在x4晶体乘法器设置下运行他们的tini，最后每个人都注意到他们的tini只是停止了。这样做的原因不是DS80C400处理器不支持这个速度，而是闪存不支持这个速度。因此，高速TINI系统需要一个带有RAM的定制板来存储和执行固件。本应用笔记将讨论初始化这样一个高速TINI系统。

Flash的局限性

闪存通常是高速TINI设计中的限制因素。最好的商业上可用的闪光灯的访问时间为55ns。下图显示了与DS80C400 CPU速度和AM29LV081闪存(1)的关系:

额定闪光速度	最大CPU速度
55 ns	40 mhz
70纳秒	33 mhz
90纳秒	27.5兆赫
120纳秒	21兆赫
150纳秒	17兆赫

这里提供的数据让开发人员有一个选择——用完闪存并限制到40MHz的执行速度，或者用完RAM并运行到75MHz。为了实现使用DS80C400和TINI OS的高速设计，必须改变正常的TINI内存映射(如TINIm400上的)。

TINI OS内存要求

要在DS80C400上运行TINI Java Runtime (TINI OS)， CE0(地址0)上必须至少有512K的RAM, CE2(地址400000h)上必须有512K的代码空间。在TINIm400上，代码空间被实现为闪存，但它也可以像RAM一样容易实现。

用于应用程序代码的RAM的问题是，它最初是空白的，如果电源被移除、电池耗尽或其他一些外部事件擦除了它的内容，它将被擦除。TINI应用程序通常用于远程监视和控制，如果设备丢失其代码，则现场更新非常不方便。解决方案是将应用程序的映像从位于普通TINI内存映射之外的闪存复制到RAM中。

备用内存映射

考虑以下高速TINI的内存映射。

图1所示高速TINI系统可能的内存映射

这个内存映射显示了TINI OS所需位置上的两个512K ram(一个在地址0，另一个在地址400000h)。它还包含一个额外的闪存地址600000h。这个flash包含一个初始化应用程序，它负责:

初始化堆
将固件和应用程序映像复制到地址400000h
将控制权移交给TINIOS

当启动DS80C400引导加载程序时，它从内存顶部开始，搜索要运行的可执行文件。当它找到一个有效的TINI应用程序签名时，它将控制权转移到该地址。我们将把启动代码放在地址6F0000h，确保它是找到的第一个应用程序代码。一个有效的TINI签名在64K内存库的地址0处由以下结构组成:

SJMP声明	字符串“TINI”	银行号码(或0)
2字节	4个字节	1个字节

有关此过程的更多信息，请参阅DS80C400数据表(2)中的“查找用户代码”部分。

使固件运行更快

现在我们已经设计了定制的TINI硬件，我们需要更改固件以更快的速度运行。

随TINI软件开发工具包一起发货的TINI固件预编程为在14MHz晶体上以2的晶体乘法器运行。高速TINI系统通常在14MHz或18MHz晶体上以2或4倍频运行。TINI固件可以改变不同的晶体速度和乘法器使用TINI fixer工具。不带参数运行此应用程序以查看命令行选项。通常，只需要更改晶体乘法器(-m选项)和晶体值(-c选项)。使用文件tini400。TINI SDK中的tbin作为此应用程序的输入文件。

启动应用程序

将固件更改为以更快的晶体乘法器运行后，我们现在可以将注意力转向将TINI系统初始化为在RAM外执行的程序。这里介绍的典型启动应用程序是用汇编编写的，并使用TINI软件开发工具包附带的免费工具(macro和a390)构建。

对于这个启动应用程序，我们选择将TINI固件和Slush应用程序作为TBIN(3)文件存储在闪存中。因此，我们的启动应用程序将需要处理TBIN文件格式的解析。这样做的好处是TBIN格式存储了其数据的所有地址信息，使启动应用程序更加通用。

文件init.a51(4)显示了一个初始化应用程序，它读取存储在闪存中的一些TBIN文件并将它们复制到RAM，然后将执行转移到RAM。代码是通用的，尽管三个位置可能需要针对不同的内存配置进行一些调整:

TBIN_GLOB_ADDRESS = 600000h
这是存储TBIN文件的地址。这里驻留的映像应该使用BuildTBIN应用程序构建(请参阅下一节)。
EXECUTE_ADDRESS = 400000h
对于TINI Java运行时，这个地址应该保持400000h(对于用C编写的应用程序，它可以改变)。初始化应用程序完成后，将执行到该位置的LJMP以转移应用程序控制。
org 6 f0000h
应用程序的org语句指定代码的位置。

使用初始化应用程序的默认配置，存储在地址600000h的TBIN文件将被复制到RAM中(在TBIN文件本身指定的地址上)。拷贝完成后，程序执行将转移到地址400000h。

开发人员应该考虑当前init代码中的几个问题:

串行调试:初始化应用程序配置定时器2来生成串行端口0的波特率。(该应用程序包含一些用于调优波特率的等式。)它输出关于复制到RAM的每个TBIN记录的信息。可以删除所有串行例程，而不会影响初始化代码的功能。
未展开的拷贝:Copy256函数包含一个部分展开的256字节拷贝(以16个单字节拷贝的16个循环展开)。这有利于提高性能，但会增加代码大小。如果代码大小比启动延迟更重要，那么这是一个好地方。
POR检查:init代码在复制TINI固件和应用程序之前不检查POR。但是，如果TINI应用程序有意重置而不循环电源，则这可能是可取的。在这种情况下，应用程序可以跳过复制并直接执行代码。注意，建议区分有意和无意的看门狗复位。一个无意的看门狗重置可能意味着一个不正确的TINI功能，在这种情况下，重新编写值得考虑的应用程序代码。
RAM Erase:启动代码还执行前64 kb RAM的擦除，以确保系统有一个干净的启动。如果CE0的RAM是电池支持的，则可以删除此操作。之所以包含此启动代码，是因为在上电时，许多TINI系统假定需要重新初始化文件系统。

使用宏(宏预处理器)和a390(汇编器)构建启动代码，使用以下命令:

宏init。a51 a390 -l -Ftbin -d -p 400 init.mpp

生成的文件称为init。应该与BuildTBIN应用程序的输出一起加载到TINI系统中，下一节将详细介绍。

buildbin应用程序

BuildTBIN应用程序是一个Java应用程序，它接受一个或多个TBIN文件，并将它们格式化为一个文件，供前一节中提供的启动应用程序使用。由于我们的高速应用程序将把Slush和TINI固件从地址600000h复制到适当的位置，BuildTBIN的命令行看起来像这样:

java BuildTBIN 600000h file_to_load。tbin slush400。tbin tini400.tbin

在本例中，文件为slush400。Tbin和tini400。它们将被组合成文件file_to_load。，目标地址为600000h。文件file_to_load。tbin应该与文件init.tbin一起加载到TINI系统中。

BuildTBIN应用程序接受输入的TBIN图像，并将其作为二进制数据处理，将其重新包装到另一个针对不同地址的TBIN文件中。这里有一个复杂的问题:启动应用程序需要知道包含多少TBIN记录。这对于诸如JavaKit和MTK之类的加载程序来说不是问题，它们查找EOF(文件结束)以确定何时没有更多的TBIN记录。为了解决这个问题，输出TBIN文件的第一个字节包含文件中TBIN记录数的计数。由于TBIN文件可以包含多个TBIN记录，因此BuildTBIN应用程序必须解析每个输入的TBIN文件，以计算它包含了多少条记录。

图2 BuildTBIN程序接受输入的TBIN文件，添加一个'count'字节，将整个文件作为二进制流处理，并输出一个新的TBIN格式文件。由于每个TBIN记录包含一些开销，请注意输出文件可能包含多达9个TBIN记录，尽管输入文件仅包含8个。