[OurDev开源充电器] 第三周（2007年12月3-12月9日）进展通告
1、原理图设计lvhaian，Grant，11月28日发布原理图v0.2，基本确定buck电路部分，各部分计算继续进行。
2、PCB布板
准备开始，寻找任务核心成员ing。
3、MCU固件
Trinove，martin7wind，11月26日发布MCU固件开发手册（草稿） v0.1，讨论进行中。
4、MCU端BootLoader程序
5、上位机软件
aleyn， 版本0.1界面讨论中
6、上下位机通讯协议
aleyn，版本0.4讨论中，mljda 递交了一份协议的gcc实现代码
7、充电器功能测试
8、元器件采购和PCB样板
各核心成员有需要通告的信息请跟贴发布。 顶一下，最近太冷清了。唉 加油! 顶呀
年底了，个个都忙着找过年钱去了…… PCB布板 的任务 有人在做了吗？
刚好我们公司最近都挺闲的，当然我自己也只做过两产品的布线，PCB方面还不是高手。 楼上别客气，protel图都在，拿去布一下大家看看吧（可想而知，会遇到很多挑战的，有不少朋友会挑错，但也正是这样自己才会进步 :) ）。
今天刚装了个protel99se，准备整理bom，发现原理图还欠缺不少东西，不少封装需要完善，直接转PCB也有很多错误。有时间的朋友可以完善一下，开新贴，递交的版本号从V0.21开始吧。 具体PCB尺寸及所用到的元件封装有贴出来吗？ 具体PCB尺寸 2、PCB布板
准备开始，寻找任务核心成员ing。
对PCB布板有什么具体要求呢？是不是在任务书里啊？
成员还没有？找时间布一下看看，不要嫌我差和慢就行了……
另外元件库没有是个比较大的问题…… 进度有点慢，自我检讨中。。。
最近我的事也比较多了，公司的事有时候需要两头跑。
不过活动的任务我一定会保证完成，大不了迟点进暖窝。 原理图在这里 [任务1] 1.智能充电器原理图 V0.2 发布，格式是Protel 99SE，主要器件的封装都确定了，但还需要进一步完善。
PCB尺寸大家先自由发挥一下吧，建议不要布的太密，因为后期面临不少试验性活动，可以考虑必要位置留出示波器探针触点。
大家可以在V0.2基础上往下做，递交的文件用V0.21...这样的版本号发布，大版本号由lvhaian和Grant确认吧。
*这两周帮一个朋友防护一台服务器，我也需要自我检讨，大家加油把事情往前推吧。 最近忙着写垃圾东西去了，检讨。 首先：【10楼】 aleyn 煮茶村长【11楼】 Cocal 说检讨就严重了，两位能在百忙之中还抽出时间为大家服务，我们除了说谢谢之外，还能说什么呢！
其次：关于PCB，是否有必要讨论然后决定尺寸，双面板还是单面板（可能跟成本有关哦），板上元件封装形式（比如电阻电容用普通直插型还是表面安装型），接口插件的规格等等，这些基本的东西定了，才好画PCB吧！ 枫仔占了我十二楼的位置…… 欧耶！ 1、是啊，进度慢了，我也要检讨。为了争取元旦能搬家，最近着实事件多，一到周末到处忙着买材料，都跑晕了；
2、PCB使用2层的，器件类型，MCU使用帖装，信号相关的元件使用贴片，功率相关的使用分立，跳线和接插件使用标准的2.54间距；
3、PCB尺寸，可以自由发挥，但不要太大，尽量节省为原则；
4、由于之前有提过使用CPU Pack的方式，后与安哥谈过，认为第一版，支持Pack有多此一举的嫌疑。我想这样解决：充电器主板上也支持M32 ，同时也提供扩展，支持CPU Pack，类似现在网上买的一些开发板，具体MCU是放在Pack上还是放在充电器板上，由用户自己选择，不知这样大家认为如何？目前给出的电路图，大家看到有三份，也就是这个原因。只是这样会增加Layout的工作量。
5、安装目前已经用上的元件，给出部分元件的封装库，Protel99SE下PCB格式，使用菜单的建库就可以做成库。我在我常用的PCB库中找了一些元件，向常用的0805、AXILA0.x等就没有加入。Layout的参考一下。
PCB 封装库(文件大小:13K) 恩，GRANT 。
周末开始PCB了，如果周5前没有人报名的话，我就先揽下来吧 谢谢各位 MCU固件开发手册0.2版，发布
这次希望能够有点明确的讨论意见。
征求一下 村长、Grant、Cocal、安哥、枫仔等的意见，希望能够就通讯协议中涉及的数据操作方式进行一下选择，
选项两个：1采用地址的方式访问一张连续的数据表，通讯协议中不涉及任何参数的定义
2将参数定义融合进通讯协议，不同的通讯指令发送不同的参数。
设计的面比较广泛，希望尽快得出结论。 trinove 阿力 ：
我觉得两种都可以的。
更加倾向于第一种，使用第一种方式只是修改 RAM 定义表和程序，就算程序更新不会涉及到通信协议的变更。
不过我觉得村长作的协议非常辛苦，如果要改为第一种在村长第一版提出来更加合适，所以我觉得还是第二种来吧毕竟通讯协议是可以更新的。 不一样的啊
使用连续数据表，MCU处理起来很容易的，如果按照现在这个样子的话，MCU需要针对性的解释所有的通讯指令并指定的更新数据。
既然要做，能够预见到麻烦，就应该用更少的代价去避免，而不是等到麻烦来了，再去处理，到时候更难处理。 抱歉，这两天没有上来，昨天一不小心搞得自己发烧到医院打吊针去了，还别说，我是下午下班的时候去的，医院的输液部还挺热闹啊，差点找不到位置座啊。
就MCU的处理效率和以后的扩展而言，如果通讯是一个较复杂的协议我会选择方案一。对于充电器而言，其本事协议所能消耗的资源并不是不可预测，我反倒认为第二种方案对于目前的应用需求是比较合适的，也许第二种方法不是最好的方法，但我相信是最合用的。
当然目前具体如何实施我都是支持村长的。
trinove 阿力你认为呢？
To 【17楼】 lvhaian 安哥
PCB的事情，与你一样，如果需要协助，知会我一声就行。 顶~ 好的建议，支持开源！ 使用数据表通讯，方式比较通用，能够随时修改数据内容和定义，比较适合后期的扩展。
我现在考虑采用放开的应用模块设计，大家在符合基础及口要求的情况下，可以任意设计程序，并且可以自定义一些参数。
这种情况下，我认为数据表就能比较好的适应。
由于设计的时候考虑将绝大多数的全局变量（各个模块都受全局变量的控制）都放置在数据表中，
也就是说整机已经受到通讯的控制了，对于上位机而言，充电器是透明。
我是如此考虑的。 感觉都可以，让村长和阿力电话沟通下巴。 关心中。 不考虑协议的事情了
反正固件中使用数据表处理，至于通讯怎么选，不管了 这几天比较忙，没顾得上这里，抱歉．
协议的事情，我在另一个贴子里已经说了，是二种方法一起支持，这样的话，也为以后作出一些选择．
至於这个版本的固件要选择哪一种方法，由阿力说了算．
不过，有一点需要留意一下的就是，如果采用连续表的方法的话，上位机只有等到下位机的数据表格式基本上定下来之后，
才能动工了． 数据表的工作已经委托 枫仔 开始处理了
相信很快就能看到结果了 灌个水，顶下
页:
[1]