简介如果您没有跟上我的帖子，我会移植一些vscp 固件到K64F。 当我说到移植时，我真的仅意味着为Kinetis MCU编写vscp与平台相关的功能，因为采用单字节EEPROM访问可以为8位PIC提供vscp示例。
请注意，我目前正移植到裸机KSDK项目，以使事情变得简单，但随后将移植到MQX。 事后看来，MQX实际上更容易入手，因为您可以连接FLASH与POSIX fopen、ioctl、读取、写入等，而不是处理您将看到的所有细节。 然而，采用KSDK的事情仍然是相当清晰的。
vscp固件文件说明如何操作的第一批事情中，其中一件事就是调用vscp函数：
查看现有网络中是否已经初始化了vscp模块，以及是否为此模块分配了‘昵称’ID，此ID源自全局唯一ID（GUID）。 vscp_check_storage所称的上述所有功能都有报头，以描述它们应当实施的功能，然而，c代码显然对设备是特定的。 例如：
因此我的目标将是以相同方式创建一个类似的称为“readEEPROM”界面。
关于闪存
所有闪存都是EEPROM，但并不非所有EEPROM 都是闪存。 在K64F上，闪存必须擦除，并且一次设置为4KB，它与32位PIC的扇区大小相同。
另一件需要注意的是，FRDM-K64F所用的 MK64FN1M0VLL12处理器上的1MB闪存可分为两个512KB模块。如果告知CPU编程闪存的代码位于同一“模块”，且正在被擦除/编程，您会得到同时读写（RWW）错误。 您可以合理地认为，大部分程序将落入第一个512KB模块，并且只使用第二个模块作为持久性数据空间，但更好的做法将是复制代码，在执行它前将闪存编程到SRAM。 值得幸庆的是，这样的例子只存在KSDK中。
这样可防止RWW错误，但如何确保我们不会覆盖代码呢？
闪存演示的代码达到闪存结束，然后抵消了6个扇区深度。 我们可以确信此处不会有代码，但在技术上是正确的，我们应当让GNU链接器了解我们自定义的持久性数据区域。 通过这种方式，而不是遇到了奇怪的运行时错误，如果您写入一个笨重的应用程序，可以使KDS弹出错误，看它是否在空间之外运行。GNU链接器链接器的默认内存部分看起来是这样的：
在代码空间开始处放置称为‘m_vscp_data’的4KB特殊区域，m_text通常从此处开始，您可以这样做：
然而，如果我们想在闪存结束时定义24KB区域，就如同在演示中，我们可以这样做：
我喜欢这种方式，因为我想在我的区域启动KB边界，虽然只要您愿意，肯定会在0x410时进行闪存写入。 这样，我们就可以使用0xfa000作为VSCP_FLASH_BASE，并保证不会碰到奇怪的运行时错误。
本帖有点长，所以我会撰写第二部分，实际上着眼于闪存抽象层（flash_al.c）。我已经设计好了，因此VSCP平台的具体功能可以实现“readFLASH或writeFLASH”之类的事情。
| 
/3 
发表于 2015-10-23 11:10:30
沉默卡
照妖镜
