tag 标签: ucontroller

相关博文
  • 热度 38
    2014-7-14 16:48
    3171 次阅读|
    9 个评论
    观察 uController 的视角   我们几乎无法回到 ARMv4 之前的年代,  因为 Architecture Reference Manaul 已经不建议我们这样做. 这种回溯可能毫无意义. 因为今天我们探讨 26-bit 的 instruction 显然是过时的(尽管 ARM 声称这种奇怪长度的 instruction 编码仍然被"保留"给将来的拓展).   当我们注意观察 ARMv4 ~ v6 时, 我们检查一颗 uController 的视角是被我们熟知的, 看啦, 首先是指令集, 甚至某种角度上说, 任何 mcu 的设计初衷, 都是围绕指令集完成的. 它必须致力于设计好的运算与控制器, 在读取了助记符和操作码后, 一丝不苟在指定 cycles 中完成 instruction 的定义.   好的, 除了 instruction set, 我们当然要晓得 exception, 甚至连 reset 都是 exception 中的一种, 从 uController 启动之初, 就应当得到我们的关注. exception 细节有很多, 一般包括优先级, 抢占, chains of exception, tail chain, 出于了解 uController 的视角所在,  从 uController 主动执行 sequence entry 到 return, 从它 push 必要的 context, 到 return 时的 pop, 我们从必要文档比如架构参考手册中, 可以了解得通通透透. 另外要提及的必须是 register. 无论是参与 instruction 执行的 core register(它们是 RISC, 也几乎可以说是 load/store 结构的必然), 因为我们总是无法在 memory 中直接执行指令. 另外的 status register (有时也包括 control register 与其他) 也是需要学习的必然. (这里我们举例说明的都是 RICS 的 uController 比如说是 ARM). 其他要提到的 register 是 system register, 有趣的是, 与 core register/status register 不同的是, 他们都可以被 memory mapped 的, 它们具有 memory address. 比方说要控制上一个段落中提到的 exception 中的一种 interrupt 的控制器 (NVIC). 此外比方说 memory register 与 其他在 SCS 中存在的 debuger register 之类(比如说的 cortex -M0). 这里的 memory register 相关的可能包括 VMSA(based on MMU), 或者是 PMSA. 当然的, 建立一个合适的 memory architecture 也是如此的重要. 首先我们需要知道比如 code, sram, device 在整个 memory mapped 中所占的空间(对于 32-bit mcu, 这"整个"往往指 4G byte size). 其次, 我们需要知道 memory 属性. 值得大书特书的就是, ARMv6 开始, memory 属性, 由偏于物理physics 的概念(比方说 bufferable 与 cachable), 走向了偏于理论总结的概念, 比方说 normal, device, strongly-order momeory 的引入. 当我们讨论无论属于哪种 mcu architecture 的 instruction set 的时候, 我们都不可避免要引入对 (basic) data type 的定义, 当然她们是 byte halfword word, 比方说在 ARM 定义中.   让我们一起回顾刚刚说的一切. 啊, 木有错的, 在我们的学习手册中, 上述内容都有着一个专业的名称叫作"编程模型(programer's model)". 作为 embedded enigneer, 我们研究的对象, 不是 implement 与 integrate, 而是着重对于上述内容, 即所谓 program model 进行学习与 review. 最终的目的是在, assember 的帮助下, 学习 instruction set, 并转换成合适的二进制码, program 到 uController 中运行. 当然是在合理的 register 配置下, 以及 exception 的掌握下. 同时, 我们也暂时没有提到更高级的语言要使用的 compiler tool. 以及在调试过程中的 debuger tool.   好, 这就是观察(学习) uController 的视角(对于我们研习 embedded system 的工作者而言), 有什么问题吗?   -- 是的, 存在需要进一步讨论的议题. , 因为: 以上只是 ARMv4 ~ v6 的视角.     大约在 2000年前后, v5 得到了定义(v4得到更早定义), 我们回忆, 大致在 2000年代初, 由于海量 mobiles 在全球范围的发布, 给予 ARM 成长的勃勃生机(基于 v4, v5 的 device 甚至可能高达数十亿部). 大约在 2004年, v6 定义发布. 这是的 VMSA(基于 MMU), 以及 cache 的广泛使用, 以及 coprocessor 的定义使用得到了推广, 这意味除了 ARM7 之外, 我们可以利用上 ARM9, ARM11 等, 在 embedded system 中跑所谓通用的 operate system, 无论是当年的 winCE 或者 Linux 或其他. 可以当作 v6 是对 memory architecture 的重大总结(normal, device, strongly-order momery 概念的提出). 也可以假设 v6 是"传统" ARM 架构的最后一个版本.   新的 ARMv7 版本, 比方说 ARMv7-M 在2006年最初诞生时(ARMv7-M 的成熟版本一直改到 2000年), 我们有了一个观察 uController 的新视角: 这就是所谓: Application level architecture 与 System level architecture.   Application level architecture 毫无疑问的, instruction set 被放置到了 "应用级架构" 进行说明.(题外话, instruction set 往往是占据架构手册的最大章节). instrcution set 往往具有不同 variants 的稳定性的特点, 也就是 instruction 往往不会变化太多, 而向下兼容, 它是汇编器, 编译器, 连接器, 反汇编器设计的基础(不包括调试器). 围绕着 instruction, exception 被简单的提及与说明. 并包括有一个 application 级别的 momery model. 尽管没有明确说明, 我们几乎可以假设为, application level architecture 已经有助于我们在 embedded system 中设计出诸如前后台系统的简单架构.  或者说, 为后面的 system level architecture 提供了基础的应用代码基础.   System level architecture 值得特别提及的, exception 被详细阐述. 毫无疑问的, system register 被逐条说明(意义, 以及read/write 的细节). 这甚至引入了新的概念, 一般指 memory architecture 的引入, 是虚拟空间体系架构(VMSA) -- 这往往引入了 cache 与 MMU. 还是仅仅只是保护空间体系架构(PMSA)呢? 这个疑问来得刚刚好, 因为以上区分(VSMA与PSMA), 几乎可以认为是 ARMv7-A 与 ARMv7-R 的最重要的区分点之一. 无论在系统级架构上, 要讨论的 MSA, 可能是 VMSA或者是 PMSA.还是说, 在 memory mapped 的 system register 将引入的 PENDSV 与 SYSTIMER, 都向我们解释了这样一个事实: 今天的 uController 的设计, 以及需要我们 embedded enigneer 观察的视角, 都必须上升到 sytem level. 哪怕甚至是对于预备与 8bit mcu 进行市场竞争的 ARMv7-M 与 v6-M. 它们在设计时, 已经注意了 memory architecture 与 priveleged 的拓展. 并通过 SVCall 与 PendSV 随时准备进入 system 调用(至少以 priveleged mode 访问 SCS与PPB). 并且通过 system timer (systick) interrput 的设计, 为任何一个 realtime operate system 作好准备.   更远意义上的, 我们观察 uController 的视角, 从过去单纯的统一的 programmer model. 到应用级架构与系统级架构的分离, 暗示我们, 随着 uController 工艺的发展, 资源的丰富, 在一个极低成本上的 uController 上, 过去往往仅限于 8bit mcu 世界的应用中, 将愈来愈多引入 realtime operate system, 并提供着比以往更丰富的互联互通 interface.   从观察 uController 的新视角出发, 我们得出了这样的结论, 我们怀疑可见的未来, uController 的愈小size, 愈大资源, realtime operate, 以及俞广泛的高速互连 interface, 将把我们未来世界带到一个更加互联(或者说更靠近"物联网"概念)的新世界.   从青年学生的学习角度推广一下: 80年代初第一台通用 computer 距离我们很遥远, 因为社会封闭的历史缘故, 导致了 uController 领域的专业人才涌现土壤的缺失. 而 ARM 在 2000年后, 从 v4 架构到今天的 v7, v8 架构, 从资源缺失的狭隘 microController 领域到MMU管理的多核 processors 应用下的高端服务器市场的冲击, 这个电子产业的进步, 发生正在进行时. 多份文档都暗示我们, 它们的编写历史甚至就在眼前, 举例基于 ARMv6-M 的 cortex m0+ 的初始 trm 文档甚至产生于 2012 年. 这意味着, 今天中国大陆的初中生, 高中生, 甚至大学在校生, 与 ARM 的历史大跃进发展没有任何时间滞后. 不存在当初"通用"CPU 发展的时代落后. 我觉得中国大陆的青年同学们, 比我们有更优越的时代基础, 更可能应抓住这一难得的历史机遇. 在与外界同步的工程土壤中, 未来或可诞生本土的 uController 设计, 应用, 创造的行业顶尖人才吧!   Allen Zhan 作于 EETC 2014.7.13  
  • 热度 39
    2014-5-17 21:16
    3443 次阅读|
    20 个评论
    单片机意指何物?   因为实际进入 embedded world 还是大致在 2004年左右的事儿, 所以我可能对 computer system 与 controller system 的名称演化历史缺乏了解. 者带来的最大困惑, 莫过于所谓"单片机"称谓了. 因为我们学习的惯例一般是阅读母语的基础教材与基本案例开始, 研习某个开发板, 点亮并闪烁第一个 LED... 啊, 这个过程充满着神奇与喜悦... 因为我们知道, 从点亮并任意模式闪烁LED开始, 我们就进入了当今信息化革命新浪潮的殿堂, 从手机到引擎, 从医疗手术到弹道制导, 从所谓通用compter 到我们设计的各款 uController... 我们从此进入了一个崭新的世界.   问题很快接踵而至, 今天的 uController 技术, 具体而言似乎都是在所谓"通用" computer 上的 embedded 的演化. 历史的观点来看, 它都起源于50年前的第一颗 Royce 发明的集成电路(我希望没记错), 并具体来自80年代初的第一台个人 computer (我记不住是 8080还是后续系列...毕竟我们那个时候还刚刚结束人斗人与白卷英雄时代), 这份震撼并最终改写人类历史的发明没有落在大陆...这注定我们对电子科技史的疏远, 而不像类似毕升发明这种亲切而又耳熟人详的回忆...   因为, 先进的 computer/processor/controller 的技术起源西方, 对基础概念的学习中, 我们很快不得不面临大量阅读 E 文资料的过程. 很快问题就来了, 您是否与我一样, 读过各种资料或者 datasheet 超过至少几十份了吧? 您见过单片机的E文对应词汇没?   人家问我干嘛的, 多年前我一般开口回答, 我是研习开发"单片机"的, 人家"喔喔....." 现在, 我从来不这么作答, 因为我没有见过任何与我们的学习或者实践开发, 有关联的任何"单片机"词汇. 为此, 我特别百度了一下"单片机", 似乎一个词组是 single chip computer... 这是个什么东东, 是挑战我们的技术新知吗?   我们生活的电子世界中, 似乎存在着 通用/common computer 与 embedded/ uController 两大类别. 发展到今天, 我们观察到 ARM 正在向我们展示, 其实或许不该存在这种区分, 所谓通用的桌上电脑, 也应该术语 uP 或者 uC 大类中的一份子.  将 uProcessor(微处理器) 与 main memory(内存) 的分开, 似乎并不是永远不变的布局, 也不能说明这就是高性能/高主频的必然代表.   这可能说明, 从 computer 发展的历史来看, 为了追求摩尔定律, 为了实现处理能力的急剧升级. 将 uProcessor 独立为一颗单芯片似乎是唯一的选择, main memory(一般是 DRAM)或者 IO controller 与之分离的布局, 就是我们所谓的 common computer.   ARM 向我们展示了这一点, 因为 ARM 运行模式的缘故, 我们大众工程师(我指应用级别)似乎第一次, 大量接收到原本应该在 uProcess/uController 设计中, 被类似 Intel/Microchip 标注为 confident 的资料. 阅读 ARM 的各种文档, 我们首次知道了 ARM 将主要围绕指令集实现的 IP, 也就是提供给各个厂家(无论是nxp, freescale, ti 还是华为), 称为 uProcessor. 更进步的, uProcessor(微处理器)被简称为 Processor(处理器). 单独的 Processor 似乎意指由 ALU, logic controller, instruction encode/execute 与其他 controller(我不理解是什么), 包括为数不多的 core register, 构成的一个 microcell. 现在的事情, 就开始拟合与我们的计算机系统的基础理念, 不错, 由 uProcessor(微处理器), 或者说 processor(处理器), 或者说由 arm 授权的这颗 microcell, 加上 memory, 以及各种 pripherals, 就构成完备的 comptering system. 当然的, 我们所谓的这样的 comptering system 似乎拟合了 computer 概念. 这就潜意识提醒我们: 所谓通用计算机, 是 uprocessor core 与 memory/外围 分离模式的构成, 我猜测这可能源于制造与技术能力在过去年代的限制. 在追求卓越表现时受限工艺, 而分离 main memory 与 cache. 无论从成本还是体积方面的考虑, 这种通用计算机(这个概念在过去, 又往往等同桌面, 服务器, 以及 comptering/计算), 无法用于工业控制或者说消费品应用(我指侧重于便携应用). 解决的方式很简单, 就是构建尽可能小而高效的 core, 也就是在 ARM 文档中说的 uP, processor, 或者 uCell, 将其与 memory 和外围在 bus 的作用下, 构建在一起. 我这里所谓的构建, 就是 on-chip, 似乎中文世界一般说成"片内". 也同样就是 embedded. 这个我非常熟悉, 有专业词汇对应为"嵌入式".   之所以我们作这样的等同, 也因为受到 ARM 资料的启发. ARM 资料, 在开篇讲述如何实现架构(v4T啦, v6M 啦, v7A啦, R啦)的 uCell 的移植或者实现时, 非常喜欢自我标榜说, 某类某类 uCell(uProcessor) 非常适用于 deeply embedded application. 什么叫作"深深的嵌入"? 我们作为嵌入式工程师, 难道工作的对象还有"浅浅的嵌入"芯片? 或许真的有, 如果从 uProcessor, 与 memory/pripherals 的分离与整合的程度上来看, 我个人感觉, 在E文的 embedded 的词汇含义下, 它揭示了一颗 on-chip 上整合 component 的多寡与最终IC 实现(RTL)/整合后的形态. 这或者是说, 我们今天的工作对象, 无论是 nxp, ti, microchip, freescale 提供的 mcu(也就是 uController, 微控制器, 其实又和所谓微计算器的区别仅仅是使用范围略有不同?), 所有这些 mcu/uController 都算是 deeply embedded 的. 因为, 它们往往封装好了 uCell 与 main memory(可地址访问的 flash/ram), 以及各种 io, timer, uart, usb 的外围.   当 arm 在 on-chip 上继续提供着深深的嵌入时, 我们似乎感觉到, 原来的 common computer 的概念正在淡化中, 一条由 on-chip 的 cache/main memory 的"深深的"嵌入的鸿沟变得没有那么的清晰.   今天朋友们问我"干嘛的"? 我一般回答"嵌入式". "不是说单片机吗"?   "不, 我主要工作在嵌入式 embedded 系统上. 它主要由片内也就 on-chip 的微处理器(一般由arm提供), 以及memory 构成(一般由可寻址的flash与sram提供). 除此之外还有构建在 bus 上的外围. 比方说 io 与 uart 控制器之类, 其实memory 也算外围中的一种, 但是引起特殊性...它特别重要并带有 cache/buffer 的属性而被单独称谓. 不像 intel 的 cisc(主要是所谓 common processor)那样, 这种bus 是公开的, 比方说 axi 与 ahb 协议必须遵守... 当然有的外围太慢, 可以用 arm 提供的 apb bus 协议, apb 就只能通过 bridge 的方式挂在 ahb 和 axi 上. 它们同属于 amba bus 协议. 不过你知道, uController 必须具有可以 debug 的特性, ... 你知道什么是 debug 吧. 所以往往 uCell 中包含有可选的 debug 逻辑电路, ARM  文档说, 它们既在 core 中, 又分布在 NVIC 中, 什么意思具体你问我我也不知道, 因为中国大陆的IC制造与设计行业似乎还不发达, 类似的技术属于与 arm 合作的大公司的研发才知道, 而且说不定他们还各种授权协议. 所以, uController, 也就是 mcu, 或者说嵌入式, 也可以称微控制器, 将 uProcessor 作为 uCell 而视为一个 component, 配合其他的 component(它们往往是可选的), 比如 wic, 或者atb bus 上的 coresight(用于 debug) 的其他 component, 构成了提供(出)的整体. 因为向外曝露了 axi bus, 或者 ahb bus, 往往也有 single-cycle io bus, 可以挂上各种外围, io啦, uart啦, usb啦... 唔,,, 你看这颗黑黑的微控制器, 或者说 uController, 或者说 embedded ic, 或者说 mcu, 我刚才讲的种种都在里面啦! 不过说来说去, 我们做 mcu 应用工作的, 其实也可以不管这么多,,, 因为我们只要拿到这颗 uController, 按推荐电路, 唔, 一般是所谓开发板, layout 好就可以了. 通过debugger与programmer, 我们在 ide 中用代码生成的 firmware debug 完成后 program 进去就好了..." "......" "你明白吗?" "手机就是这样做的吗?" "唔...这么说呢,,,也没错..."    "......" "......" "你不是做单片机的吗?"   "......我k...... !#!$!#%$#%^%"       Allen 作于 2014.5.17 周六傍晚 发表于 EETC