记录一次国产数据库FlashDB在国产MCU GD32F103上的移植和测试过程

先说结论：国产MCU+国产嵌入式数据库，YYDS。

第一次接触嵌入式数据库FlashDB，比较好奇它的性能如何，比如支不支持掉电保存和擦写平衡。见官方的性能测试，插入13421条日志型数据，平均0.37ms，查询0,12ms，下面是官方网站摘取的详细数据库特性：

• 资源占用极低，内存占用几乎为 0 ;
• 支持 多分区，多实例 。数据量大时，可细化分区，降低检索时间；
• 支持 磨损平衡 ，延长 Flash 寿命；
• 支持 掉电保护 功能，可靠性高；
• 支持 字符串及 blob 两种 KV 类型，方便用户操作；
• 支持 KV 增量升级 ，产品固件升级后， KVDB 内容也支持自动升级；
• 支持 修改每条 TSDB 记录的状态，方便用户进行管理；

个人感觉最大的特性是掉电保护、磨损平衡、blob类型的支持，日志数据库也是一大特色。掉电保护、磨损平衡比较容易理解，其中blob类型是数据库的一种二进制数据库，除了string类型外，能存储int、struct、json等多种复杂数据类型。笔者成功将FlashDB移植到了GD32F103RC上，做了一下几个键值型数据库KVDB的测试。

一、移植过程

（1）将FAL(Flash Abstraction Layer，Flash抽象层)库移植到工程中，主要有fal.c、fal_flash.c、fal_partition.c几个文件，需要笔者新建fal_flash_gd32f1_port.c文件，实现init、read、write、erase几个函数在GD32F103上的实现，并定义flash设备

const struct fal_flash_dev stm32_onchip_flash =

{

.name = \"stm32_onchip\",

.addr = 0x08000000,

.len = 256*1024,

.blk_size = 2*1024,

.ops = {init, read, write, erase},

.write_gran = 32

};

（2）定义设备表和设备分区表

在fal_cfg.h文件中定义设备表和设备分区表

/* flash device table */

#define FAL_FLASH_DEV_TABLE

{

&gd32_onchip_flash,

}

/* ====================== Partition Configuration ========================== */

#ifdef FAL_PART_HAS_TABLE_CFG

/* partition table */

#define FAL_PART_TABLE

{

{FAL_PART_MAGIC_WORD, \"fdb_tsdb1\", \"gd32_onchip\", 104*1024, 8*1024, 0},

{FAL_PART_MAGIC_WORD, \"fdb_kvdb1\", \"gd32_onchip\", 112*1024, 16*1024, 0},

}

#endif /* FAL_PART_HAS_TABLE_CFG */

总得来说，移植过程可细分为三个步骤即定义设备、定义设备表、定义分区表，定义设备在

fal_flash_gd32f1_port.c中完成，设备表和分区表定义在fal_cfg.h中完成。

二、测试过程

利用官方自带的demo例程，在void kvdb_type_blob_sample(fdb_kvdb_t kvdb)函数中，循环100次读写\"temp\"的值，第一上电后，串口调试助手能够正常输出读写“temp”的数值，笔者并用读写工具成功读写了开始地址为0x801C000(偏移位置为112*1024)处的二进制代码，如下图所示

从flash的占用情况来看，写入100个blob型的数据，差不多占用了从0x1C000到0x1D800总共0x1800个字节，0x1800/0x800=3个扇区（页大小为2KB，0x800）。因为\"fdb_kvdb1\"的大小只有16*1024=8*2048字节=8个扇区，大概第三次上电时可能出现写满触发垃圾回收机制，从实现结果来看，也验证了这一点