对软件和硬件能力的要求很平均
软件上,你会得自己处理协议、组织控制逻辑甚至加密解密等
硬件上,你们会用运放调整信号、设计合适的电源稳定的驱动电路等
在开发管理上,常见的有以下两种模式:
一:大家一起完成系统架构,然后软件硬件独立分开,在框架设计时约定接口。分别测试,最后系统联调。
二:由一高手(通常是老工程师)归纳好所有结构框架,组织下面几个单片机工程师(可能各有所长)逐步构建系统。
这两种模式各有优势和不足,你们采取的是哪种?
执行效果怎么样?说说您的感受,也为这个看似简单到不需要管理(其实更需要管理)的行业积累一点你的经验
89 个解决方案
#1
单片机就是一个人搞定,软硬通吃。不存在团队放入问题。
执行效果很好,常见于中小规模的公司。
执行效果很好,常见于中小规模的公司。
#2
项目的规模足够小的话,那当然一个人做完是最合适的
但这样也带来很多问题:
这个人的工资开多少?
技术积累怎么保障?
这个人被挖走了怎么办?技术传承如何解决?
如果将来的项目他一个人做不下来怎么办?临时招人,这个可是更郁闷的。
我相信有超级明星,但是,除非他自己开的公司、拿公司股份或者是大公司,否则这样的超级明星对中小规模的的公司来说并不能说是很好的模式
#3
技术传承是很大的问题
#4
看你管理的规模,
如果规模大,可以学习一下华为 中兴 这样的团队;
如果规模小,小公司,都是1-2个牛人工程师,1个人一个项目搞定
如果规模大,可以学习一下华为 中兴 这样的团队;
如果规模小,小公司,都是1-2个牛人工程师,1个人一个项目搞定
#5
版主今天那么有空,呵呵,自己搞个帖子。
小公司的话,很多都是自己负责项目的,特别是单片机项目,说难谈不上,大不了就说它复杂。毕竟代码量不会太多。外围的电路也不会太多,就算很多,也是模块式的,很多都已经是成熟的模块,网上电路图一大把。我公司就是小公司,所有的压力都自己扛。
不过,有点规模的公司我就不清楚了,呵呵。
假如真的要二选一的话,我选第一个。
这两种方式的区别就在系统架构上面。软硬件人员协商,考虑到的东西会比较周全吧,毕竟三个臭皮匠顶一个诸葛亮啊,前提是他们有相关的经验,呵呵!
小公司的话,很多都是自己负责项目的,特别是单片机项目,说难谈不上,大不了就说它复杂。毕竟代码量不会太多。外围的电路也不会太多,就算很多,也是模块式的,很多都已经是成熟的模块,网上电路图一大把。我公司就是小公司,所有的压力都自己扛。
不过,有点规模的公司我就不清楚了,呵呵。
假如真的要二选一的话,我选第一个。
这两种方式的区别就在系统架构上面。软硬件人员协商,考虑到的东西会比较周全吧,毕竟三个臭皮匠顶一个诸葛亮啊,前提是他们有相关的经验,呵呵!
#6
这是个纠结的问题
我还是一菜鸟·~ 先学为主
我还是一菜鸟·~ 先学为主
#7
技术的积累和传承很重要~~
#8
现在是一个人软件和硬件都做!希望使用第一种!
#9
一个团队 最好是软硬件方面人才都有吧,但是现在 现实是要一个人丛PCB 搞到 程序部分比较多
#10
"一:大家一起完成系统架构,然后软件硬件独立分开,在框架设计时约定接口。分别测试,最后系统联调。"
虽然是“一起”,但还得有主次之分。主要是指遇到分歧怎么办?必须有人能拿主意。一旦确定后坚决执行。所以,第二种比较理想。由高人总体负责结构,然后分而治之。这样一来也比较容易控制进度,毕竟高人的经验多,对开发时间的掌握比较准确。
虽然是“一起”,但还得有主次之分。主要是指遇到分歧怎么办?必须有人能拿主意。一旦确定后坚决执行。所以,第二种比较理想。由高人总体负责结构,然后分而治之。这样一来也比较容易控制进度,毕竟高人的经验多,对开发时间的掌握比较准确。
#11
纠结中..这是个很复杂的问题,自从单片机系统出来后这个问题就一直困扰着各方人士.
以上为个人瞎说!
回贴,捞分,示以存在!
以上为个人瞎说!
回贴,捞分,示以存在!
#12
很多公司都这么干的。感觉单片机系统的开发自古以来就这样
也不知道是谁给咱这行数定下了这样的规矩
是何立民哥?还是周立功哥?天知道呢
#13
这关于以下几点提出来的:
1.新人不知道学软件还是学硬件,看到坛子里不少这样的贴子
2.个人经历这两种模式,感觉也都对,也都不完整。所以列出来和大伙聊聊
#14
新人想学什么,跟着感觉走最好,看自己喜好什么,就做什么,呵呵,
世间上,没有两全其美的东西吧,呵呵,这个问题就正如用C好还是用汇编好?只有具体到什么公司,什么环境下,什么情况下,才有个取舍的定夺,呵呵,,个人愚见!
世间上,没有两全其美的东西吧,呵呵,这个问题就正如用C好还是用汇编好?只有具体到什么公司,什么环境下,什么情况下,才有个取舍的定夺,呵呵,,个人愚见!
#15
通常要面对的问题是:
这样的高人不好找,而且,咱周边的高手呢,有很多都是专家型的到管理上不一定能体现出水平
第一种:这个存在很大的问题是成员间的通信,《人月神话》里就对这个问题做出了很好的解答,但是,这样的构建成本和风险对于小公司来说相对是比较低的,它不怕人走,当然集体跳槽那没办法。能保证一定的人才积累,随着公司的成长,有可能会慢慢熬出一两个高手。这将迎来团队的春天!
其实,我个人比较认同第二种方案,也是典型的外科手术团队的形式(手术团队不需要太多的外科医生(牛人、高手),有且仅有一个就够了,然后给他配备相应的护士和麻醉师等辅助其工作,让他专心设计同时助手们也能得到提高和成长),现在大多数老板也都采用这种方案,只不过他们都习惯性的只要一个牛人,然后,把它当成一神牛,一人拉着公司项目的重车。让一牛X的医生一个人去完成一例手术!这显然比较荒唐,可是我们单片机工程师很多人每天都在做着这样的事。呵呵(所有依据来自《人月神话》)
#16
《人月神话》开始我是想提及一下的,不过感觉在单片机论坛提还是稍微有点太“虚空”,不实在。
实际项目中,根据我的经验,还是比较喜欢软硬分开,但二者都对对方的内容有相当的了解,然后由一个人主导制定总体方案,然后分头开发,最终合并调试。这样都可以发挥自己的长处,毕竟软硬都强的牛人太可遇而不可求。
#17
不知道楼主说的单片机的软都要做哪些工作? 我认为单片机的软实际上也是硬。
#18
软硬件通吃
#19
通信协议实现过没?人机接口界面实现过没?各种不同的控制逻辑实现过没?
这都是硬不起来的,嘿嘿
#20
学习了,硬件啊,一直是我的软肋……
#21
我觉得实际上并没有这么为难。
在立项的时候自然有这么一个人出来规划,要不谁是总负责的呢?
这个人软件或硬件均可,因为都是大概念得问题,不涉及到细节。譬如,需要有哪些功能,需要多大的存储,用什么样的存储,是支持彩屏还是黑白屏,要不要USB通讯等等,这是个总体上的规划,有较多经验的人就可以规划出来。
而作为硬件工程师,我的目标就是作出开发板/demo板,然后试跑demo程序(软件工程师做的)以验证基本的功能,然后就可以交给软件工程师了。
至于什么协议之类的问题,不关我硬件工程师的事,我只需要保证电路参数合格就可以。
软件工程师在实现的过程中,如果确实发现了难以解决的问题,就会和硬件工程师沟通。其实验证硬件只需基本的驱动程序就可以,所以跟软件其实也没太大关系的。
总的来说,软硬基本上是可以分开的。
在立项的时候自然有这么一个人出来规划,要不谁是总负责的呢?
这个人软件或硬件均可,因为都是大概念得问题,不涉及到细节。譬如,需要有哪些功能,需要多大的存储,用什么样的存储,是支持彩屏还是黑白屏,要不要USB通讯等等,这是个总体上的规划,有较多经验的人就可以规划出来。
而作为硬件工程师,我的目标就是作出开发板/demo板,然后试跑demo程序(软件工程师做的)以验证基本的功能,然后就可以交给软件工程师了。
至于什么协议之类的问题,不关我硬件工程师的事,我只需要保证电路参数合格就可以。
软件工程师在实现的过程中,如果确实发现了难以解决的问题,就会和硬件工程师沟通。其实验证硬件只需基本的驱动程序就可以,所以跟软件其实也没太大关系的。
总的来说,软硬基本上是可以分开的。
#22
如果是大规模应用,譬如开发游戏的、大量应用程序的,软件工程师就会分成做BSP的和做应用程序的,后者机会完全看不到硬件这一层了。
#23
如果是做小规模应用,譬如什么电子锁啊,门控的终端啊,软硬一个人也是很正常的事。
#24
什么通信协议? 难道单片机要实现类似基于TCP的复杂协议?
什么人机接口界面? 单片机能够驱动的顶多是灰度点阵液晶吧? 界面应该不会太复杂。
控制逻辑就更简单了。
起码我至今没用单片机做过多少复杂的软件,完全是很硬件相关的,几千行代码都可以由硬件工程师搞定。
#25
如果楼主用ARM-M3,7,9等,那另当别论了。
#26
软硬件通吃
#27
楼主指的通讯协议应该指的是公司内部通讯自定的数据通讯协议,可以他就是基于232、485或者USB、TCP,并不是说要自己开发一个底层的通讯协议
现在的工程师都把ARM叫单片机了,所以跑个wince、linux啥的有个人机接口界面很正常
其实现在说单片机软硬部分好多都是设计到ARM了,如果纯粹的8位单片机可能还是偏硬一点,从16位的开始就不太好说了……
#28
建议这位兄弟去看看任天堂的游戏机,索尼的游戏机,还有PDA(ARM也是单片机)
#29
一个智能前端监控设备协议,光协议就2000多行,我也郁闷,那么轻量级的东西,我要写这么多行代码
另外,用人机接口界面,比如说一个128*64点阵屏的多级菜单和按键选择功能
这很容易就能把人搞郁闷,当然,从网上直接扫代码和拿设计方案结果的不算
除了卖给学生和学校,网上直接能抄到的应该都不值啥钱了吧?
找个能写几千行代码的硬件工程不太容易哈。。。
甚至更郁闷的是,硬件工程师没有经过规范的编码训练,写出来的代码是很郁闷的,几乎没有可读性和可维护性
当然,不排除有那些软件和硬件都做得很好的,这样的人的确很少。
#30
米用过ARM,一直觉得8和16位机没学完的飘过。。。
#31
这种私活性质的一锤子买买,对于研发人员来说会是很郁闷的哈。。。
#32
关于这个问题我不想做太多评价
#33
顶起这个帖子,这确实是很多新手遇到的问题。我刚学单片机,感觉编写程序比搞外围硬件简单
#34
初学者,学习。。。。
#35
学习
有道理软硬统吃
好
有道理软硬统吃
好
#36
软硬统吃
#37
单片机关键在于外围电路,就单片机本身很简单的
#38
我感觉,单片机软件的比硬件的更加需要懂硬件.
#39
由一高手(通常是老工程师)归纳好所有结构框架,组织下面几个单片机工程师(可能各有所长)逐步构建系统。
#40
这种问题,主要看项目规模,其次是项目完成的期限。这两项就决定了需要的人员,两个及以上的人员就需要指定负责人。开发流程也是需求分析->总体设计->软硬件总体设计->软硬件详细设计->软硬件测试->联调->系统总体测试. 在这个流程中,也许可以一个人担负起各项工作.也许需要不同的人员配合. 就算一个人搞,也要有人对其进行考核,设计文档等完备了就可以积累和传承.
#41
个人认为还是得软硬件通吃的好,更有信心
#42
UPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUP
#43
个人和团队都有各自的优势
#44
硬件是基础 软硬通吃是必然的 这样才能把握总的架构
#45
UP!
#46
很早一起大家就说软硬件都懂会比较好,现在的情况是企业里边分工很细,复杂的项目不可能靠个人,得靠团队,个人认为方案一好
#47
无聊,这就好比是先有鸡还是先有蛋的问题!!!!!!!!
#48
单片机其实就是一门软硬通吃的课程嘛。。。。。。。。。。呵呵呵呵呵呵!!!!!
#49
这个问题:其实说纠结,也纠结。说不纠结,也不纠结。
纠结,是因为,你必须经过几次具体的实施才能真正的说是能把握。而且,不同的人,不同的资源组成会有不同的结果。它不完全遵从于当前的纯软件和纯硬件的设计经验,在国内也很少能看到具体总结这个结合领域的参考文献,甚至连文档规范都是千差万别的。
不纠结:是因为,你可以很简单的把它归结为两个说法:经验和具体问题具体分析。
发起这个话题,目的是为了从纠结中找到不纠结,而不是直接不纠结。
呵呵
纠结,是因为,你必须经过几次具体的实施才能真正的说是能把握。而且,不同的人,不同的资源组成会有不同的结果。它不完全遵从于当前的纯软件和纯硬件的设计经验,在国内也很少能看到具体总结这个结合领域的参考文献,甚至连文档规范都是千差万别的。
不纠结:是因为,你可以很简单的把它归结为两个说法:经验和具体问题具体分析。
发起这个话题,目的是为了从纠结中找到不纠结,而不是直接不纠结。
呵呵
#50
刚开始还是跟着感觉好,呵呵
#1
单片机就是一个人搞定,软硬通吃。不存在团队放入问题。
执行效果很好,常见于中小规模的公司。
执行效果很好,常见于中小规模的公司。
#2
项目的规模足够小的话,那当然一个人做完是最合适的
但这样也带来很多问题:
这个人的工资开多少?
技术积累怎么保障?
这个人被挖走了怎么办?技术传承如何解决?
如果将来的项目他一个人做不下来怎么办?临时招人,这个可是更郁闷的。
我相信有超级明星,但是,除非他自己开的公司、拿公司股份或者是大公司,否则这样的超级明星对中小规模的的公司来说并不能说是很好的模式
#3
技术传承是很大的问题
#4
看你管理的规模,
如果规模大,可以学习一下华为 中兴 这样的团队;
如果规模小,小公司,都是1-2个牛人工程师,1个人一个项目搞定
如果规模大,可以学习一下华为 中兴 这样的团队;
如果规模小,小公司,都是1-2个牛人工程师,1个人一个项目搞定
#5
版主今天那么有空,呵呵,自己搞个帖子。
小公司的话,很多都是自己负责项目的,特别是单片机项目,说难谈不上,大不了就说它复杂。毕竟代码量不会太多。外围的电路也不会太多,就算很多,也是模块式的,很多都已经是成熟的模块,网上电路图一大把。我公司就是小公司,所有的压力都自己扛。
不过,有点规模的公司我就不清楚了,呵呵。
假如真的要二选一的话,我选第一个。
这两种方式的区别就在系统架构上面。软硬件人员协商,考虑到的东西会比较周全吧,毕竟三个臭皮匠顶一个诸葛亮啊,前提是他们有相关的经验,呵呵!
小公司的话,很多都是自己负责项目的,特别是单片机项目,说难谈不上,大不了就说它复杂。毕竟代码量不会太多。外围的电路也不会太多,就算很多,也是模块式的,很多都已经是成熟的模块,网上电路图一大把。我公司就是小公司,所有的压力都自己扛。
不过,有点规模的公司我就不清楚了,呵呵。
假如真的要二选一的话,我选第一个。
这两种方式的区别就在系统架构上面。软硬件人员协商,考虑到的东西会比较周全吧,毕竟三个臭皮匠顶一个诸葛亮啊,前提是他们有相关的经验,呵呵!
#6
这是个纠结的问题
我还是一菜鸟·~ 先学为主
我还是一菜鸟·~ 先学为主
#7
技术的积累和传承很重要~~
#8
现在是一个人软件和硬件都做!希望使用第一种!
#9
一个团队 最好是软硬件方面人才都有吧,但是现在 现实是要一个人丛PCB 搞到 程序部分比较多
#10
"一:大家一起完成系统架构,然后软件硬件独立分开,在框架设计时约定接口。分别测试,最后系统联调。"
虽然是“一起”,但还得有主次之分。主要是指遇到分歧怎么办?必须有人能拿主意。一旦确定后坚决执行。所以,第二种比较理想。由高人总体负责结构,然后分而治之。这样一来也比较容易控制进度,毕竟高人的经验多,对开发时间的掌握比较准确。
虽然是“一起”,但还得有主次之分。主要是指遇到分歧怎么办?必须有人能拿主意。一旦确定后坚决执行。所以,第二种比较理想。由高人总体负责结构,然后分而治之。这样一来也比较容易控制进度,毕竟高人的经验多,对开发时间的掌握比较准确。
#11
纠结中..这是个很复杂的问题,自从单片机系统出来后这个问题就一直困扰着各方人士.
以上为个人瞎说!
回贴,捞分,示以存在!
以上为个人瞎说!
回贴,捞分,示以存在!
#12
很多公司都这么干的。感觉单片机系统的开发自古以来就这样
也不知道是谁给咱这行数定下了这样的规矩
是何立民哥?还是周立功哥?天知道呢
#13
这关于以下几点提出来的:
1.新人不知道学软件还是学硬件,看到坛子里不少这样的贴子
2.个人经历这两种模式,感觉也都对,也都不完整。所以列出来和大伙聊聊
#14
新人想学什么,跟着感觉走最好,看自己喜好什么,就做什么,呵呵,
世间上,没有两全其美的东西吧,呵呵,这个问题就正如用C好还是用汇编好?只有具体到什么公司,什么环境下,什么情况下,才有个取舍的定夺,呵呵,,个人愚见!
世间上,没有两全其美的东西吧,呵呵,这个问题就正如用C好还是用汇编好?只有具体到什么公司,什么环境下,什么情况下,才有个取舍的定夺,呵呵,,个人愚见!
#15
通常要面对的问题是:
这样的高人不好找,而且,咱周边的高手呢,有很多都是专家型的到管理上不一定能体现出水平
第一种:这个存在很大的问题是成员间的通信,《人月神话》里就对这个问题做出了很好的解答,但是,这样的构建成本和风险对于小公司来说相对是比较低的,它不怕人走,当然集体跳槽那没办法。能保证一定的人才积累,随着公司的成长,有可能会慢慢熬出一两个高手。这将迎来团队的春天!
其实,我个人比较认同第二种方案,也是典型的外科手术团队的形式(手术团队不需要太多的外科医生(牛人、高手),有且仅有一个就够了,然后给他配备相应的护士和麻醉师等辅助其工作,让他专心设计同时助手们也能得到提高和成长),现在大多数老板也都采用这种方案,只不过他们都习惯性的只要一个牛人,然后,把它当成一神牛,一人拉着公司项目的重车。让一牛X的医生一个人去完成一例手术!这显然比较荒唐,可是我们单片机工程师很多人每天都在做着这样的事。呵呵(所有依据来自《人月神话》)
#16
《人月神话》开始我是想提及一下的,不过感觉在单片机论坛提还是稍微有点太“虚空”,不实在。
实际项目中,根据我的经验,还是比较喜欢软硬分开,但二者都对对方的内容有相当的了解,然后由一个人主导制定总体方案,然后分头开发,最终合并调试。这样都可以发挥自己的长处,毕竟软硬都强的牛人太可遇而不可求。
#17
不知道楼主说的单片机的软都要做哪些工作? 我认为单片机的软实际上也是硬。
#18
软硬件通吃
#19
通信协议实现过没?人机接口界面实现过没?各种不同的控制逻辑实现过没?
这都是硬不起来的,嘿嘿
#20
学习了,硬件啊,一直是我的软肋……
#21
我觉得实际上并没有这么为难。
在立项的时候自然有这么一个人出来规划,要不谁是总负责的呢?
这个人软件或硬件均可,因为都是大概念得问题,不涉及到细节。譬如,需要有哪些功能,需要多大的存储,用什么样的存储,是支持彩屏还是黑白屏,要不要USB通讯等等,这是个总体上的规划,有较多经验的人就可以规划出来。
而作为硬件工程师,我的目标就是作出开发板/demo板,然后试跑demo程序(软件工程师做的)以验证基本的功能,然后就可以交给软件工程师了。
至于什么协议之类的问题,不关我硬件工程师的事,我只需要保证电路参数合格就可以。
软件工程师在实现的过程中,如果确实发现了难以解决的问题,就会和硬件工程师沟通。其实验证硬件只需基本的驱动程序就可以,所以跟软件其实也没太大关系的。
总的来说,软硬基本上是可以分开的。
在立项的时候自然有这么一个人出来规划,要不谁是总负责的呢?
这个人软件或硬件均可,因为都是大概念得问题,不涉及到细节。譬如,需要有哪些功能,需要多大的存储,用什么样的存储,是支持彩屏还是黑白屏,要不要USB通讯等等,这是个总体上的规划,有较多经验的人就可以规划出来。
而作为硬件工程师,我的目标就是作出开发板/demo板,然后试跑demo程序(软件工程师做的)以验证基本的功能,然后就可以交给软件工程师了。
至于什么协议之类的问题,不关我硬件工程师的事,我只需要保证电路参数合格就可以。
软件工程师在实现的过程中,如果确实发现了难以解决的问题,就会和硬件工程师沟通。其实验证硬件只需基本的驱动程序就可以,所以跟软件其实也没太大关系的。
总的来说,软硬基本上是可以分开的。
#22
如果是大规模应用,譬如开发游戏的、大量应用程序的,软件工程师就会分成做BSP的和做应用程序的,后者机会完全看不到硬件这一层了。
#23
如果是做小规模应用,譬如什么电子锁啊,门控的终端啊,软硬一个人也是很正常的事。
#24
什么通信协议? 难道单片机要实现类似基于TCP的复杂协议?
什么人机接口界面? 单片机能够驱动的顶多是灰度点阵液晶吧? 界面应该不会太复杂。
控制逻辑就更简单了。
起码我至今没用单片机做过多少复杂的软件,完全是很硬件相关的,几千行代码都可以由硬件工程师搞定。
#25
如果楼主用ARM-M3,7,9等,那另当别论了。
#26
软硬件通吃
#27
楼主指的通讯协议应该指的是公司内部通讯自定的数据通讯协议,可以他就是基于232、485或者USB、TCP,并不是说要自己开发一个底层的通讯协议
现在的工程师都把ARM叫单片机了,所以跑个wince、linux啥的有个人机接口界面很正常
其实现在说单片机软硬部分好多都是设计到ARM了,如果纯粹的8位单片机可能还是偏硬一点,从16位的开始就不太好说了……
#28
建议这位兄弟去看看任天堂的游戏机,索尼的游戏机,还有PDA(ARM也是单片机)
#29
一个智能前端监控设备协议,光协议就2000多行,我也郁闷,那么轻量级的东西,我要写这么多行代码
另外,用人机接口界面,比如说一个128*64点阵屏的多级菜单和按键选择功能
这很容易就能把人搞郁闷,当然,从网上直接扫代码和拿设计方案结果的不算
除了卖给学生和学校,网上直接能抄到的应该都不值啥钱了吧?
找个能写几千行代码的硬件工程不太容易哈。。。
甚至更郁闷的是,硬件工程师没有经过规范的编码训练,写出来的代码是很郁闷的,几乎没有可读性和可维护性
当然,不排除有那些软件和硬件都做得很好的,这样的人的确很少。
#30
米用过ARM,一直觉得8和16位机没学完的飘过。。。
#31
这种私活性质的一锤子买买,对于研发人员来说会是很郁闷的哈。。。
#32
关于这个问题我不想做太多评价
#33
顶起这个帖子,这确实是很多新手遇到的问题。我刚学单片机,感觉编写程序比搞外围硬件简单
#34
初学者,学习。。。。
#35
学习
有道理软硬统吃
好
有道理软硬统吃
好
#36
软硬统吃
#37
单片机关键在于外围电路,就单片机本身很简单的
#38
我感觉,单片机软件的比硬件的更加需要懂硬件.
#39
由一高手(通常是老工程师)归纳好所有结构框架,组织下面几个单片机工程师(可能各有所长)逐步构建系统。
#40
这种问题,主要看项目规模,其次是项目完成的期限。这两项就决定了需要的人员,两个及以上的人员就需要指定负责人。开发流程也是需求分析->总体设计->软硬件总体设计->软硬件详细设计->软硬件测试->联调->系统总体测试. 在这个流程中,也许可以一个人担负起各项工作.也许需要不同的人员配合. 就算一个人搞,也要有人对其进行考核,设计文档等完备了就可以积累和传承.
#41
个人认为还是得软硬件通吃的好,更有信心
#42
UPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUPUP
#43
个人和团队都有各自的优势
#44
硬件是基础 软硬通吃是必然的 这样才能把握总的架构
#45
UP!
#46
很早一起大家就说软硬件都懂会比较好,现在的情况是企业里边分工很细,复杂的项目不可能靠个人,得靠团队,个人认为方案一好
#47
无聊,这就好比是先有鸡还是先有蛋的问题!!!!!!!!
#48
单片机其实就是一门软硬通吃的课程嘛。。。。。。。。。。呵呵呵呵呵呵!!!!!
#49
这个问题:其实说纠结,也纠结。说不纠结,也不纠结。
纠结,是因为,你必须经过几次具体的实施才能真正的说是能把握。而且,不同的人,不同的资源组成会有不同的结果。它不完全遵从于当前的纯软件和纯硬件的设计经验,在国内也很少能看到具体总结这个结合领域的参考文献,甚至连文档规范都是千差万别的。
不纠结:是因为,你可以很简单的把它归结为两个说法:经验和具体问题具体分析。
发起这个话题,目的是为了从纠结中找到不纠结,而不是直接不纠结。
呵呵
纠结,是因为,你必须经过几次具体的实施才能真正的说是能把握。而且,不同的人,不同的资源组成会有不同的结果。它不完全遵从于当前的纯软件和纯硬件的设计经验,在国内也很少能看到具体总结这个结合领域的参考文献,甚至连文档规范都是千差万别的。
不纠结:是因为,你可以很简单的把它归结为两个说法:经验和具体问题具体分析。
发起这个话题,目的是为了从纠结中找到不纠结,而不是直接不纠结。
呵呵
#50
刚开始还是跟着感觉好,呵呵