【摘要】 本文作者在空想未来。。
写这么庞大的主题绝非笔者的本意,笔者也无力驾驭这种题目,不过,既然在 《20年华为扫地僧,揭开亿万级路灯互联的智能奥秘,参与社区互动赢好礼!》(链接:https://bbs.huaweicloud.com/forum/forum/thread-63672-6-1.html ),笔者一不小心得了一个茶杯,所以发个博文,根据大家的想法讨论下可能的路径,还是可以的。(然而只是标题党,因为题目错进来的朋友们可以小白退散了)
让我们从一则真实的小故事说起吧,一位也很想得到这个茶杯的朋友(简称L),希望LiteOS能够增加图形化编程功能,以及多跟AI结合,提供相关的平台服务(参见29楼和52楼,当然后者已经被作者删除了。。)其实他的文字还是非常不错的,有图有文,有理论有实例,还有三名辅助提供了资料。眼看着茶杯即将到手,然而一位眼熟的M同学,接着L的话题又谈了多个场景。而我又看到这个讨论很有意思,通过一个回帖加入他们的讨论,我的原文是这样的:
哈哈哈,为了茶杯真是拼了吗?那我也接着52楼和54楼的同学的建议来说一下:
1。LiteOS图形化编程
作者的意思是将LiteOS端的代码写成像Scatch风格的图形化吗?我个人认为,如果像打解包工具这种,倒是可以考虑由现有的IoTDA的云端的物模型中,倒过来生成一份LiteOS设备端的解析代码。这样确实可以减少设备端的开发量,而且正好可以完全匹配云端的解析,相当于,一套配置,设备和云端同时生成不同的代码。这样可能会更有意义点。
但是,现在LiteOS本身就是用C语言做编译比较合适。而且做了这个,也同时可以做起其他ARM芯片的物联网设备的编程,换成图形化界面之后,是否合适,还有待商榷,个人认为,可能不是很恰当。当然可以考虑推出一些积木式的开发工具,但是也要考虑跟现有LiteOS的任务、终端、信号量、内存、互斥锁,这些基本功能的融合。与其这样做,不如做出一些C语言的模板出来,供物联网开发者参考。
况且,从LiteOS轻量化的要求来看,图形化可能带来的是代码的冗余和略重。可能回导致都烧录不到小熊派等设备中去。我有次就遇到一个问题——烧个Logo都不能用WiFi而必须用NBIoT,就是因为包太大了。我当时就提出“WiFi应该是允许更多信息传输才对,怎么反而信息少了”这种质