回复了主题帖： 祝大家六一儿童节快乐！趁娃上幼儿园拆个玩具看看原理

一几年火了一段时间的手按式发电手电筒，我记得价格也就十块钱左右，那才是真的自发电

回复了主题帖： 浅谈加班

楼主描述的这种适合毕业生，拖家带口的，家里总有一堆事等着你

回复了主题帖： 【小熊派BearPi-HM Micro】七：试用总结

freebsder 发表于 2022-5-27 17:52 OpenHarmony是华为那个吗？

不是，只是开源的部分而已，华为的还要加上不开源的部分

回复了主题帖： 给先楫HPM6750EVKMINI画一个LCD扩展板

各种屏幕官方价格都是劝退一大波人啊

发表了主题帖： 【小熊派BearPi-HM Micro】七：试用总结

本帖最后由 数码小叶 于 2022-5-23 21:52 编辑         两个月的试用时间，可以说小熊派BearPi-HM Micro真的是一块适合来入门OpenHarmony的板卡，在这之前，完全没有接触过OpenHarmony的代码，这次通过一步步的实践，对OpenHarmony有了很多的认识和了解，不然一直觉得OpenHarmony挺神秘的。         从搭建环境到第一次成功编译源码，都是满满的成就感。虽然遇到各种问题，但是正是在解决这些问题过程当中去认识和了解OpenHarmony的方方面面。对于学习OpenHarmony，小熊派提供的资料可以帮助入门，但是想了解更多，比如为啥这么操作，中间的一些原理，小熊派提供的资料就显得有点不够的，就要推荐看官方的文档了             官方文档写的很详细，包括一些名词都有介绍，可以说小熊派的资料告诉你怎么去操作，而官方的文档，就是告诉你为什么这么操作，两者结合起来就是知其然知其所以然。官方文档是用markdown写的，所以也可以去自己编辑、备注都很方便。           小熊派BearPi-HM Micro的优点很明显，缺点也是存在的，就是资料的开放性，比如底层bootloader部分，这部分对于想更深入的了解和学习OpenHarmony在STM32的引导过程还是比较重要的，虽然说会开源，但是一直是延期。另一方面不全的就是板卡硬件驱动这块，作为驱动开发方向（小熊派分南向驱动、北向应用），板载这块应该是主要起点。可能是因为部分功能还在完善中，感觉后期可能会补上这块吧，不然少了这部分对于开发就不完整了。         最后感谢论坛组织了这次试用活动     

回复了主题帖： 先预告下：国民技术寄送的9块板卡到了，太快了，夕发朝拾

以前快递很多空运，现在很少很少见了，都是陆运，基本都要三四天以上

发表了主题帖： 【小熊派BearPi-HM Micro】六：JS应用控制LED灯

本帖最后由 数码小叶 于 2022-5-3 11:17 编辑 要实现APP控制LED灯，可以分为五个步骤进行： 1.添加控制LED灯的JS API接口； 2.编写控制LED灯c++ 业务代码； 3.配置HDF头文件路径； 4.编译、烧录； 5.安装HAP应用；   添加JS API接口，就是修改~/bearpi/project/bearpi-hm_micro_small/foundation/ace/ace_engine_lite/frameworks/src/core/modules下的app_module.h 添加两行代码 static JSIValue ToggleLed(const JSIValue thisVal, const JSIValue* args, uint8_t argsNum);   JSI::SetModuleAPI(exports, "ledcontrol", AppModule::ToggleLed);   编写控制LED灯c++ 业务代码，这个要依赖上一篇的LED灯闪烁代码中的操作函数，同样是修改 ~/bearpi/project/bearpi-hm_micro_small/foundation/ace/ace_engine_lite/frameworks/src/core/modules下的app_module.cpp       在~/bearpi/project/bearpi-hm_micro_small/foundation\ace\ace_engine_lite\ace_lite.gni文件里添加HDF头文件路径以及编译依赖项 "//drivers/framework/ability/sbuf/include", "//drivers/framework/include/core", "//drivers/framework/include/utils", "//drivers/adapter/uhdf/posix/include",     所有修改完成后，开始编译，编译无误后，烧录到BearPi-HM Micro     BearPi-HM Micro底层控制部分已经ok，还需要安装一个HAP应用，起到在屏幕端控制的功能。HAP 全称OpenHarmony Ability Package，一个HAP文件包含应用的所有内容，由代码、资源、三方库及应用配置文件组成，其文件后缀名为.hap。 所要安装的hap文件位于系统源码的~/bearpi/project/bearpi-hm_micro_small/applications/BearPi/BearPi-HM_Micro/tools/hap_tools/hap_example下的Led_1.0.0.hap。有两种方式安装，一种是内存卡、一种是直接编译进系统烧录文件，相比于编译进系统，内存卡的方式在时间和步骤上要优越很多。   复制要安装的hap文件和上层的bm文件到内存卡，bm是一个安装工具     要安装hap应用，首先要关闭OpenHarmony的签名模式，打开调试模式，这两条命令，不是每次安装都需要，开机后执行一次就行了，重启后失去作用， ./bm set -s disable ./bm set -d enable 调试模式成功打开后就可以安装应用了 ./bm install -p LED_1.0.0.hap   安装完成后，在BearPi-HM Micro的屏幕上可以看到多了一个应用图标   这一篇中间耽搁了很长时间，因为开始一直控制不了led，所以各种找原因，后来发现依赖于上一篇的led控制信号，只有led控制信号被注册了，JS应用才能发挥功能，曲折越多，学到的也越多   打开后就可以愉快的控制led了

加入了学习《发帖插入视频1》，观看 JS控制led

回复了主题帖： 免费版rt-thread的内核实在差太多。。。

额。。。没在一个线程挂起过其它线程，所以还真没考虑过这个，但是rt-thread的优先级继承提升反转肯定有啊

回复了主题帖： 结构体中 “ u8 Dat2 : 7; ”是个什么写法，这个什么意思？

主要现在的MCU的空间比较大，所以很少有这么去省的，除非大工程了

回复了主题帖： 一种历史告警功能的实现——基于拓普微Lua脚本实现

有没有一下简单的Lua脚本分享，方便初学者使用

回复了主题帖： 【小熊派BearPi-HM Micro】四：熟悉Openharmomy编译框架，串口交互输出

Jacktang 发表于 2022-4-14 07:15 确实Openharmomy编译框架和组件打交道的次数还是比较多的

感觉要熟悉的规则好多

回复了主题帖： 【小熊派BearPi-HM Micro】四：熟悉Openharmomy编译框架，串口交互输出

lugl4313820 发表于 2022-4-14 08:41 看来得认真学习一下如何编译了。看着头有点晕晕的呀！

Openharmomy这个没CMake通用

回复了主题帖： 【小熊派BearPi-HM Micro】四：熟悉Openharmomy编译框架，串口交互输出

freebsder 发表于 2022-4-19 17:42 看见这种文本的工程配置就头疼。

好处是免费，不需要IDE

发表了主题帖： 【小熊派BearPi-HM Micro】五：利用HDF驱动框架实现LED闪烁

本帖最后由 数码小叶 于 2022-4-19 08:26 编辑         HDF（Hardware Driver Foundation）驱动框架，为驱动开发者提供驱动框架能力，包括驱动加载、驱动服务管理和驱动消息机制。旨在构建统一的驱动架构平台，为驱动开发者提供更精准、更高效的开发环境，力求做到一次开发，多系统部署。        基于HDF框架进行驱动的开发主要分为两个部分，驱动实现和驱动配置，驱动实现包含驱动业务代码和驱动入口注册，这两者开发文档里都提供了模板，比如驱动业务代码，一个简单的模板如下： #include"hdf_device_desc.h"// HDF框架对驱动开放相关能力接口的头文件 #include"hdf_log.h"// HDF 框架提供的日志接口头文件 #define HDF_LOG_TAG sample_driver // 打印日志所包含的标签，如果不定义则用默认定义的HDF_TAG标签 //驱动对外提供的服务能力，将相关的服务接口绑定到HDF框架 int32_t HdfSampleDriverBind(structHdfDeviceObject*deviceObject) { HDF_LOGD("Sample driver bind success"); return0; } // 驱动自身业务初始的接口 int32_t HdfSampleDriverInit(structHdfDeviceObject*deviceObject) { HDF_LOGD("Sample driver Init success"); return0; } // 驱动资源释放的接口 void HdfSampleDriverRelease(structHdfDeviceObject*deviceObject) { HDF_LOGD("Sample driver release success"); return; }   实际编程时，就可以直接在此模板上扩展，比如BearPi-HM Micro提供的demo //驱动对外提供的服务能力，将相关的服务接口绑定到HDF框架 int32_t HdfLedDriverBind(struct HdfDeviceObject *deviceObject) { if (deviceObject == NULL) { HDF_LOGE("Led driver bind failed!"); return HDF_ERR_INVALID_OBJECT; } static struct IDeviceIoService ledDriver = { .Dispatch = LedDriverDispatch, }; deviceObject->service = (struct IDeviceIoService *)(&ledDriver); HDF_LOGD("Led driver bind success"); return HDF_SUCCESS; }                 驱动注册，就是实例化驱动入口，驱动入口必须为HdfDriverEntry（在 hdf_device_desc.h 中定义）类型的全局变量，且moduleName要和device_info.hcs中保持一致。HDF框架会将所有加载的驱动的HdfDriverEntry对象首地址汇总，形成一个类似数组的段地址空间，方便上层调用。 struct HdfDriverEntry g_ledDriverEntry = { .moduleVersion = 1, .Bind = HdfLedDriverBind, //GPIO不需要实现Bind,本例是一个空实现，厂商可根据自身需要添加相关操作 .Init = HdfLedDriverInit, //见Init参考 .Release = HdfLedDriverRelease, //见Release参考 .moduleName = "HDF_LED",,//【必要且需要与HCS文件中里面的moduleName匹配】 }; //调用HDF_INIT将驱动入口注册到HDF框架中 HDF_INIT(g_ledDriverEntry);         而对于驱动配置，HDF框架使用的是.HCS文件，.HCS文件全称是HDF Configuration Source，是HDF驱动框架的配置描述源码，内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦，便于开发者进行配置管理。HC-GEN（HDF Configuration Generator）是HCS配置转换工具，可以将HDF配置文件转换为软件可读取的文件格式：在弱性能环境中，转换为配置树源码或配置树宏定义，驱动可直接调用C代码或宏式APIs获取配置。在高性能环境中，转换为HCB（HDF Configuration Binary）二进制文件，驱动可使用HDF框架提供的配置解析接口获取配置。HCS经过HC-GEN编译生成HCB文件，HDF驱动框架中的HCS Parser模块会从HCB文件中重建配置树，HDF驱动模块使用HCS Parser提供的配置读取接口获取配置内容。                 和驱动实现一样，驱动配置同样包含两部分，HDF框架定义的驱动设备描述和驱动的私有配置信息，HDF框架定义的驱动设备描述位于：~\bearpi\project\bearpi-hm_micro_small\device\st\bearpi_hm_micro\liteos_a\hdf_config\device_info\device_info.hcs。驱动的私有配置信息，则是用户自己添加的配置信息，比如这里的~\bearpi\project\bearpi-hm_micro_small\device\st\bearpi_hm_micro\liteos_a\hdf_config\led\led_config.hcs   device_led :: device { // led设备节点 device0 :: deviceNode { // led驱动的DeviceNode节点 policy = 2; // policy字段是驱动服务发布的策略，等于0，不需要发布服务 priority = 10; // 驱动启动优先级（0-200），值越大优先级越低， preload = 1; // 驱动按需加载字段 permission = 0777; // 驱动创建设备节点权限 moduleName = "HDF_LED"; // 驱动名称，该字段的值必须和驱动入口结构的moduleName值一致 serviceName = "hdf_led"; // 驱动对外发布服务的名称，必须唯一 deviceMatchAttr = "st_stm32mp157_led"; // 驱动私有数据匹配的关键字，必须和驱动私有数据配置表中的match_attr值相等 } }   root { LedDriverConfig { led_gpio_num = 13; match_attr = "st_stm32mp157_led"; //该字段的值必须和device_info.hcs中的deviceMatchAttr值一致 } }     最后，是需要将需要将该配置文件添加到板级配置入口文件hdf.hcs device\st\bearpi_hm_micro\liteos_a\hdf_config\hdf.hcs #include "device_info/device_info.hcs" #include "led/led_config.hcs" 关于GPIO口的操作，GPIO驱动已经提供了相关的接口   然后就是led闪烁的业务代码编写了，就是驱动程序指令接受的的代码，用户态向内核态发送指令 int32_t LedDriverDispatch(struct HdfDeviceIoClient *client, int cmdCode, struct HdfSBuf *data, struct HdfSBuf *reply) { uint8_t contrl; HDF_LOGE("Led driver dispatch"); if (client == NULL || client->device == NULL) { HDF_LOGE("Led driver device is NULL"); return HDF_ERR_INVALID_OBJECT; } switch (cmdCode) { /* 接收到用户态发来的LED_WRITE_READ命令 */ case LED_WRITE_READ: /* 读取data里的数据，赋值给contrl */ HdfSbufReadUint8(data,&contrl); switch (contrl) { /* 开灯 */ case LED_ON: GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_LOW); status = 1; break; /* 关灯 */ case LED_OFF: GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_HIGH); status = 0; break; /* 状态翻转 */ case LED_TOGGLE: if(status == 0) { GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_LOW); status = 1; } else { GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_HIGH); status = 0; } break; default: break; } /* 把LED的状态值写入reply, 可被带至用户程序 */ if (!HdfSbufWriteInt32(reply, status)) { HDF_LOGE("replay is fail"); return HDF_FAILURE; } break; default: break; } return HDF_SUCCESS; }           通过代码可以感受到OpenHarmony的设备开发中的驱动调用与单片机的驱动开发不太相同，单片机的驱动调用往往是采用函数调用的方式，但是OpenHarmony没有这样的操作，驱动调用采用的是驱动程序向用户态暴露server后，程序才能通过Dispatch的方式发送指令到驱动程序，并可以将用户态的数据携带到驱动程序，也可以从驱动程序读出数据。像上面的代码就是通过Dispatch向驱动程序发送指令从而实现LED灯的亮灭，当然，内核态也可以向用户态发送数据。         和上一篇，helloword一样，还需要编译文件，对于业务代码，和上一篇一模一样的操作，配置BUILD.gn、applications.json、config.json。对于驱动文件，不但需要自己写的BUILD.gn，还需要修改~\bearpi\project\bearpi-hm_micro_small\device\st\drivers\BUILD.gn import("//drivers/adapter/khdf/liteos/hdf.gni") hdf_driver("hdf_led") { sources = [ "led.c", ] }     最后编译，烧录到板子了，和之前一样，打开串口助手 ，通过指令操作led的亮灭状态变化        

回复了主题帖： python的速度将提高2倍

win7不升上去，没机会体验了啊

回复了主题帖： F769移植CoreMark串口无输出

Somiy 发表于 2022-4-15 03:13 请问如何解决的呢  

堆栈设置不合理

发表了主题帖： 【小熊派BearPi-HM Micro】四：熟悉Openharmomy编译框架，串口交互输出

本帖最后由 数码小叶 于 2022-4-13 21:21 编辑         通过几天的实践，对于Openharmomy有了更多的了解，比如怎么把一个简单的程序编译到系统里去。         首先需要一个实现功能的源码程序，比如helloworld.c。还需要一个BUILD.gn文件。.gn文件是一种编译构建文件，类似于Cmake。相较于Cmake，当工程规模增大到难以想象的量级时，编译速度和工程模块的划分变得尤为重要，而gn便很好解决了这两个问题。Openharmomy的文档里，介绍了相关的.gn编码规范。 BUILD.gn基本结构如下 import("//build/lite/config/component/lite_component.gni") executable("生成的库名称") { output_name = "可执行文件名称" sources = [ "源文件" ] include_dirs = [] defines = [] cflags_c = [] ldflags = [] } lite_component("lite组件名") { features = [ ":库文件", ] }   导入 gni 组件，将源码编译成库文件，然后将库文件打包成 lite组件，同时，定义好了输出的可执行文件的名称。 还有和Cmake一样的地方是，这个BUILD.gn也对大小写敏感，开始就是这个弄错了，一直编译不过   接着就是配置~\bearpi\project\bearpi-hm_micro_small\build\lite\components\applications.json文件，将刚才定义的lite组件添加进去   添加后保存，再修改单板配置文件~\bearpi\project\bearpi-hm_micro_small\vendor\bearpi\bearpi_hm_micro\config.json   开箱时，看到自带的锁屏画面，其功能所定义的组件也在这里看到了，倒退回刚才的applications.json文件，也可以找到screensaver相关内容，相比简单的helloworld串口输出，锁屏依赖的组件就比较多了     同时，也可以解释，上一篇烧录完源码后，只有两个应用，在这可以看到定义 到这个目录下，找找看锁屏的原始图片春夏秋冬四季的图片   对于如何修改上面几个文件，每个文件里的参数什么意义，在Openharmomy的文档里都可以找到详细的介绍，包括内部结构说明以及配置示例    编译整个源码，和上一篇一样，将编译后的文件烧录进BearPi-HM Micro   烧录完成后，打开串口助手，通过串口助手，可以使用大部分的linux操作指令     运行我们编译的程序，查看串口输出 ./bin/helloworld 成功打印了源文件里的内容   整个过程操作下来，发现和组件打交道的次数还是比较多的，OpenHarmony整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 组件”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的组件。子系统是一个逻辑概念，它具体由对应的组件构成。   组件就是对子系统的进一步拆分，可复用的软件单元，它包含源码、配置文件、资源文件和编译脚本；能独立构建，以二进制方式集成，具备独立验证能力的二进制单元。  

回复了主题帖： 【小熊派BearPi-HM Micro】三：烧录编译的固件程序

wangerxian 发表于 2022-4-6 17:31 这个芯片是双核的，好像挺难编程的，不知道有没有相关教程。

主要是第一次接触Openharmomy，写详细点，方便自己查阅

回复了主题帖： 【小熊派BearPi-HM Micro】三：烧录编译的固件程序

wangerxian 发表于 2022-4-6 17:31 这个芯片是双核的，好像挺难编程的，不知道有没有相关教程。

好在底层已经适配好了，所以难度大大下降了。教程可以看小熊派自家的，也可以看Openharmomy的教程，Openharmomy的教程很详细