辛昕

hotsauce1861 发表于 2016-2-26 11:04
哪些可以下载源码？ 学习一下

我之前v0.1的源码 放在 oschina的 git上

我的帐号是 xinxin19871118，项目名是 FreeUI

辛昕

ljj3166 发表于 2016-2-26 13:52
nice
发布出来玩玩啊

v0.1已发布，在oschina的git上

辛昕

armink 发表于 2016-2-26 16:25
辛版，一直有在关注 FreeUI ，但遇到一些问题就没有继续下去了。我最近再重新试试，正好有个改型的产品（也 ...

话说，具体遇到啥问题？

armink

辛昕 发表于 2016-2-26 21:32
话说，具体遇到啥问题？

今晚我又重新下载源码搞了下，现在主要有下面这几个问题

1、直接打开 demo 中的工程并且编译，还是会报错，f0 的那个库路径不是每个人都有的啊。这点我还好，自己折腾下就能通过了，但是其他开发者一看到错误就害怕，更别说让他们用起来，移植到自己的平台上。

2、在遇到 f0 库的问题之后，我就没管别的，直接把 FreeUI/src 源码文件夹复制到自己的项目中。将所有 f0xx 统一更换为 f10x，这个工作量还好，但是改完之后编译包一堆函数被重复定义，仔细查找才发现，源码中有很多直接 include .c 源码文件的代码，由于源码结构不了解，图省事，我就直接删除了 include .c 的代码，替换为extern 方法的方法（这里强烈建议把共有方法提取出来，在头文件中声明，否则通用性太差了，移植成本也会增大）。

3、编译通过后，接下来就是调矩阵键盘，虽然咱们键盘都一样都是 4*4 ，但是矩阵键盘中一点注释都没有（drv 和 sam简写的意思我到最后也没搞明白），又是寄存器操作又是库函数操作，哪些需要用户改，哪些保留最好要有个说明吧。搞了半个小时，矩阵键盘也没弄好，最后我就放弃了，等改天再详细查查。

辛昕

armink 发表于 2016-2-26 22:36
今晚我又重新下载源码搞了下，现在主要有下面这几个问题

1、直接打开 demo 中的工程并且编译，还是会 ...

额，原来是这样。
话说我是不是有点烦了嘿嘿.....催的烦了

其实，drv sam是 drive 和 sample的意思，矩阵键盘，拉低拉高的线，是驱动电平的，所以我就叫做driver,简写成drv
至于sample是扫描。

这是以前写的了，一直没注释。

这个地方，之所以又是寄存器又是库，是因为ST这个库我不是太满意，有的地方实在操作太简单了，库里写的乱七八糟我也就直接摒弃，说到 这个地方，属于硬件的驱动吧，我是时间长了自己总结下来的一个套路，就是在这唯一仅有的一个驱动源文件里 直接堆代码。
换一个MCU，完全可以重新写一份这个源文件。

但我确实没想过别人可能完全不适应这种方式。
也没有注释。

至于 F0库那个东西，其实我在ReadMe中提过。
我把F0库单独作另一个项目也一并推到了osc上了。看起来，果然还是会不习惯看ReadMe的......

不过，不管怎么说，只有这样的反馈我才会知道该怎么修改......

辛昕

然后就是，话说我确实有点催烦了吧......
次次都艾特你。

辛昕

armink 发表于 2016-2-26 22:36
今晚我又重新下载源码搞了下，现在主要有下面这几个问题

1、直接打开 demo 中的工程并且编译，还是会 ...

至于公有方法这事，共有方法或者通用函数，说的都是一回事，只是提法不同。
说实在的，这个地方，不太好统一。
但结构上又希望尽可能地做在一个框子里。
这也是我现在先铺开接着做v0.2版的原因

之前v0.1在v0.95那个地方之所以迟迟没往前倒v0.1主要就是因为这里。
因为在只有一个demo的情形下，其实根本看不出来怎么抽取才有意义。
不过这个，无所谓了，先做下去才知道。

armink

辛昕 发表于 2016-2-26 22:52
额，原来是这样。
话说我是不是有点烦了嘿嘿.....催的烦了

其实，drv sam是 drive 和 sample的意思， ...

关于 Demo 项目，给我的感觉就是应该是一个像你所说的 started guide 的项目，可以让一个没有使用过 FreeUI 的用户打开工程就能很好的理解然后去使用。所以如何降低用户的操作难度，让用户下载下来什么都不用怎么修改就能用，就能编译通过等等，这些细节就显得尤为重要（这也就是我们常听到产品经理说的用户第一印象及用户体验）。

矩阵键盘我也想过换成自己项目中的源文件，但是不太熟悉你的源码结构，所以就想先看懂你的源码，再在你基础上改改再去用。虽然 ST 库是有很多地方不尽人意，但是至少他的 API 我们可以通过名称就知道它是干嘛用的，直接看寄存器还得翻手册，上手难度又增加一成。所以我觉得提高库在移植时代码的可读性，对于减低移植难度就显得尤为重要。

armink

辛昕 发表于 2016-2-26 22:52
然后就是，话说我确实有点催烦了吧......
次次都艾特你。

哈哈~这个一点都没有，反倒让我觉得你挺用心的。毕竟有哪些帖子更新了，通过 @ 方式发送消息提醒是最直接的。

armink

辛昕 发表于 2016-2-26 22:55
至于公有方法这事，共有方法或者通用函数，说的都是一回事，只是提法不同。
说实在的，这个地方，不太好 ...

我觉得这个可以参考其他开源软件结构，例如：UCOS，FreeRTOS，RT-Thread等，他们的很多抽象方法的思想和技巧是可以学习的。

辛昕

armink 发表于 2016-2-27 08:25
关于 Demo 项目，给我的感觉就是应该是一个像你所说的 started guide 的项目，可以让一个没有使用过 Free ...

我昨晚想了想，也是该增加一些注释了。
我有过一段时期，注释写的非常详细，方方面面都照顾到了，甚至到了 注释比源码 还长的地步。
很多人对此感到非常震惊，后来我就习惯性了 能不写就不写一句 的风格。
但是我完全疏忽了 我的设计和考虑 思路，别人是一点都不知道的。

辛昕

armink 发表于 2016-2-27 08:29
我觉得这个可以参考其他开源软件结构，例如：UCOS，FreeRTOS，RT-Thread等，他们的很多抽象方法的思想和 ...

其实根源还是在于第一版的时候，没有其他版本的需求驱动，所以并不确认那些值得抽象和通用。
在这个地方，我也是有过一段很弯路的时期。
所以后来，习惯了在某些场合下 堆代码。
或者是，函数只是用来分层的，而不在意通用性

辛昕

所以，我想了想，目前我的做法是:
在v0.2出雏形前，暂时不动结构和代码。
只是完善注释 和 started guide

armink

辛昕 发表于 2016-2-27 09:00
所以，我想了想，目前我的做法是:
在v0.2出雏形前，暂时不动结构和代码。
只是完善注释 和 started guide

这点我也赞同。更快的让用户入门，积累用户，才能收集到更多的用户建议。

lcn1992

刚好有F429I的板子，等你发布下来玩玩。

懒猫爱飞

果断来学习一下

辛昕

armink 发表于 2016-2-27 09:12
这点我也赞同。更快的让用户入门，积累用户，才能收集到更多的用户建议。

这也是我的思路。
在这论坛里，在各式各样的圈子里混迹了五六年之久，自己也工作了五年。
我深刻发现，对于程序员来说，真正值得用来交流的东西其实只有一个东西。

一个项目及其代码

shmily53

来看看                        

wforest68

不要总想着什麽手机，现在手机上的系统出了apple公司的IOS就是Android，IOS是很不错的，但是我绝对不喜欢Android，不喜欢的原因不外两点：1、占用资源太大；2、内存回收机制太差，造成系统稳定性降低。
虽然我不喜欢android，但是我明白若是想抢占Android短时间内是不可能的，尤其是正面抢占Android的市场，但是随着可穿戴设备的快速发展，在今后十年、二十年小型化的RTOS绝对是一个快速发展的市场，因此若想做RTOS就应该奔着这个目标走，面向这个目标做系统，除了好用的RTOS核心外（稳定性、可扩展性、可移植性），最重要的是要支持广泛的通信协议（包括网络协议）、传感器支持、友好的界面，这几方面做好了，再有一个好的商业模式是不难成功的。