先随便写写一些思路, 以后再整理.

这段时间笔者做了一些硬件开发, 领悟了一些事情.

1 - 在常规创客的角度上, 硬件开发所需的知识面比较广, 非常广, 但不算太深.

2 - 发现硬件开发由于其特殊环境的原因, 开发难度很大, 难度绝大部分来源于很麻烦, 效率很低.

一般的开发者, 如果他们入门就直接学硬件, 他们是感觉不到这问题的.  没有对比就没有伤害.

但对于一个写惯C#,Java的程序员来说, 会明显感觉到写硬件的那种无力感.

由奢入俭难啊! 无论心理上作出多低的预期, 在实际编程阶段, 心理想的是

1 - 为什么这么多工具链安装都那么的麻烦? 而且还有那么多收费的.

2 - 为什么要花时间去等待编译, 烧录, 启动, 不行再重复再重复, 青春就这样浪费了.

3 - 为什么要花那么多时间去寻找指针出错原因, 为什么写一个小时代码要调试5个小时?

嗯.  这些不是别人的想法, 是我自己的想法.

于是笔者就去找各种脚本方案, JS,Lua,Python,... 但发现,

这些方案不多不少都有各种问题. 不太感到满意.

所以, 笔者当时就计划着自己去实现一个脚本语言.

这并不是随便就去重复做一个轮子, 而是一个有目标的计划:

1 - 要极简单, 简单到, 让笔者不到9岁的儿子都能轻松地学习和测试代码, 感受到代码与硬件的交互关系.

2 - 要极方便, 方便到, 任何用户不需要输入任何命令行, 就能搭配好开发测试环境

3 - 要满足Java,JavaScript,C#开发人员的需要, 垃圾回收, 强类型弱类型, 函数式编程, closure这些都要有.

4 - 要满足C/C++开发人员的需要, 可以随意地实现自己期待的高效率函数或硬件驱动.

5 - 要非常高效, 用极短的代码就能完成创客的想法, 有错误能快速定位, 重新运行代码要在3秒内完成.

所以, 要满足这种目标, 就只能是实现一个脚本解析器, 和配套的开发工具了.

其缺点也是明显的

1 - 内存占用问题,  导致这需要对单片机有一定的要求.  可用内存最少要32K或更高.

2 - 成熟度问题 , 这需要一个过程.  不过也没差, 因为硬件开发者懂的, 说起奇怪的bug各种方案都是半斤八两.

优点和缺点分析了,  针对这种情况, 决定了这种方案只适合以下情况

1 - 教育用途, 这是首要的目的.  尤其对于小学生, 他们理解力很有限, 那么就需要把硬件开发中的各种细节屏蔽掉.

2 - 非专业创客, 如果有一些人, 他们有一些好玩的想法, 那么这个工具就能节省他们非常多的时间和精力.

3 - 快速原型,  传统的用C和用C++做产品原型是相对花很多时间的.  使用此方案则原本需要5天做的原型, 现在只需要1天. (以上为是模糊的经验统计,仅作参考) 这样就可以随时改需求, 随时评估项目可行性.

4 - 小规模生产.  在快速原型的基础上, 如果没发现太大的问题, 对硬件的成本的敏感度不高的情况下, 甚至可以直接把原型当产品做小规模生产了.

不适合的情况:

1 - 对成本苛刻的中等规模或大规模生产 , 生产几千件以上, 选用廉价低内存芯片, 每一件硬件省个10块钱就能覆盖让程序员日日夜夜调试的开销的情况.

2 - 用于关键场合的硬件开发 ,  这种场合开发人员的成本已经完全不是问题了, 找一大堆人才去做C/C++开发和极限测试吧.

要支持的硬件优先级

1 - ESP32 , 特点, 成本低, 内存足够, 拿上手就直接可用.

2 - 树莓派 , 特点, 内存超大, 性能更强. 能做USB开发,

3 - STM32 , 特点, 接口超多而全面, 适合做超多部件的场合.

当前进度 , 脚本解释器已能使用, ESP32上GPIO/PWM已实现, 树莓派GPIO已实现,  正在实现TCP部分,HTTP部分