如下仅为我的观点,欢迎讨论面试
做为一个程序猿,怎么能不会写代码呢。彻底掌握一门语言是关键。
并且不只要会写,还要写得好,好比代码规范,debug。算法
现在的技术一天一个样,若是没有必定的学习能力,很快就会被时代所淘汰。
只有活到老,学到老才能跟上时代的步伐。编程
不要遇到问题就处处问人,不如先问问神奇海螺百度。百度不知道,再问问google。
另外,一些官方的文档,源码也是寻找答案的好地方。ubuntu
团队协做总要与人沟通,遇到真的解决不了的问题也要与人沟通。说话方式我就不说了,我也不是很懂。
有一点很关键:
必定不要在聊天时直接粘贴代码。
必定不要在聊天时直接粘贴代码。
必定不要在聊天时直接粘贴代码。
这样真的很影响阅读!(通常状况下公司代码是不容许外传的)
若是须要传递代码,要么截图,要么上传到Ubuntu Paste
(我就知道这个,其余能够贴代码的网站还有不少)数组
主流的MCU,如ARM,AVR,MSP(我就知道这么几个,欢迎打脸)多少要了解。
虽然如今ARM框架盛行,尤为是STM32系列。感受到了M4以上,基本都知足要求。
是否是我见识太浅了。数据结构
写硬件必需要与周围电路和经常使用芯片打交道,能看懂是第一阶段。
若是能照搬着用是第二阶段,若是能自主设计或者改良就是第三阶段了。框架
因为任务愈来愈复杂,各个任务之间数据同步,愈来愈复杂,MCU的结构也愈来愈复杂。
就须要RTOS来帮忙进行任务调度,不管是轻量级的FreeRTOS等等,重量级的实时Linux。都是不错的选择。编程语言
因为任务愈来愈复杂,单单用数组,指针已经不能知足咱们的要求,须要一些数据结构来支撑整个任务。
若是会用一些经常使用的数据结构,好比栈,队列,哈希表等等。会大大缩短任务的执行时间(下降时间复杂度)。
并且,也能对RTOS内部的一些实现有更深入的理解。ide
算法经常和数据结构放在一块儿谈论,可是在这里,更多的是一些控制算法,如PID,模糊控制。学习
这些就不只仅只是设计周围电路或者经常使用芯片,而是设计一些更加复杂由多个芯片组成的模块。
做为硬件设计的最终手段(额,,我我的是这么认为的),FPGA能够完成许多MCU没法完成的任务。
每每FPGA是和MCU协同工做的。
必要能力中,除了编程能力之外,另外三个,说是能力,不如说是一种习惯。
这种习惯须要培养,前期可能比较不习惯,可是滚起雪球来就很明显了。
编程能力也是的,当你学会一种编程语言以后,再学其余的就没那么难了,由于他们的格式,语法都差很少。
你也没见过哪一个高级语言里,if-else结构中,条件不成立的在条件成立的部分以前。(汇编语言里为了优化,彷佛有这样的操做)
可选能力的话就须要根据要去的公司和项目来决定,固然提早会一些也是不错的。
至于加分能力,顾名思义就是加分嘛。若是不会这些,应该不会影响平常的工做。可是了解一些的话,对平常的工做会有很大的帮助。
如何提高可选能力和加分能力,天然是在项目中学习,在实战中学习。有了上面的必要能力,学起来不是问题。
固然可选能力也能够经过阅读文档来学习,(我我的不提倡)虽然较慢,效率不高。但对于现阶段无法完成项目,或者急于面试的同窗们还是一种方法。
我我的以为,基于模型的设计流程不该该和其余传统的设计流程相比较。
在Managing Model-Based Design中,Chapter 4,小标题使用的都是Model-Based Design Within xxxx。
而且摘录到如下内容:
This chapter provides an overview of common development methodologies and
explains how Model-Based Design core concepts support these methodologies.
It then explains how Model-Based Design can help you adapt any methodology
to the needs of your project.
综上基于模型的设计流程更多的应该是和传统的设计流程相结合在一块儿,做为辅助。
我我的还有一点小观点,传统的设计流程,无非是把各个流程拆分,组合,顺序调转,以达到更好的效果。
可是万变不离其宗,因此如下的分析就以最经典的瀑布模型为例:
基于模型的设计能够很快的把总体效果呈现出来,给客户或者团队成员展现。
这样相对文字和图片的描述更加直观,每一个人也能够单独查看本身感兴趣的部分。
在设计时,基于模型的设计能够很快的切换另外一个设计并进行仿真,查看是否知足要求。
一个好的组件库甚至不须要作一些接口转换就能够完成。
目前一些支持基于模型的设计的软件,如Matlab,均可以自动生成代码。
再加上一些BSP的库,就像在面包板上接线同样,接口对应就行。
将同一组数据同时交给程序和模型,而后将程序所得结果和模型所得结果进行比较,可知其正确性。
还有用模型模拟被控制对象,并接入程序,模拟真实运行环境,甚至极限环境。可知其鲁棒性。
维护的一大关键是查错,若是能够获得出错时的数据,将数据导入模型就能够模拟出当时的环境,
以便找到解决办法。
模型库对于任何一家公司都是须要很大的成本,不管是金钱上的成本仍是开发上的成本。
除了成本以外,驱动模型库须要大量的数据,数据的收集也是一大问题。
另外,若是不是对各个方面的知识都有所了解的话,用起来就会有点无从下手。因此不建议纯新手使用。
以前有作过一个两轮小车,其中涉及电机控制,PID闭环,惯性导航。
当时只是有尝试过仿真电机,可是由于电机参数都不知道,因此以失败了结。
另外,在学习惯性导航的时候,也用到了建模和仿真,有很明显的效果。
最后的感觉就是,本身用起来很麻烦,若是有现成的就很好用。
其缘由,大概仍是本身学识浅薄吧。
若是完整的使用基于模型的开发流程的话,总体的设计会很是快,毕竟模型就是拖动几个控件。
可行性的验证也会很是准确,不至于几个月都没办法肯定惯性导航的可行性。
因为编码较为简单,加上初学STM32,因此更可能是强调本身学习,不能依赖自动编程。
以后的验证和维护可能比较麻烦,由于是咱们本身设计的小车,可能没有足够的传感器来获取想要的数据。
也就是说,没有办法拿到数据和模型中的数据相对比。
综上,基于模型的开发流程仍是减小了工做量,大大的推动了项目进展。利大于弊。