arm与flash连接错位的原因 (2009-09-08 01:33:26)

本文详细解释了在不同外设位宽(8、16、32位)下,CPU与外设之间地址线的连接方法。以16位NORFLASH为例,阐述了中间层MemoryController如何根据外设位宽进行数据处理,确保软件能够正确读取所需数据大小。通过实例演示了如何实现不同位宽数据的读取,强调了MemoryController在数据选择和合并过程中的作用。
标签: 

杂谈

分类: arm2440

转自http://www.100ask.net/showtopic-308.aspx

 

外设位宽为8、16、32时,CPU与外设之间地址线的连接方法

有不少人问到:
flash连接CPU时,根据不同的数据宽度,比如16位的NOR FLASH (A0-A19),处理器的地址线要(A1-A20)左移偏1位。为什么要偏1位?

从软件和CPU的角度而言,一个地址对应一个字节,就是8位数据。这是肯定的,不要怀疑这点。

对于具体器件而言,它的位宽是一定的,所谓位宽,指的是“读/写操作时,最小的数据单元”──别说最小单元是“位”,一般设备上没有单独的“位操作”,修改位时通过把整个字节、字或双字读出来、修改,再回写。

CPU的地址线(A0-A20)对应的最小数据单元是字节,即8位;
而位宽为16的NOR FLASH的地址线(A0-A19)对应的最小数据单元是16位。
这两个怎么对应起来?

如果说外设的位宽是16,难道我们写程序时会“特意”以16位进行操作吗?不用的,我们写程序时根本不用管外设位宽是8、16还是32。

仔细想想,其实是可以想通的:既然CPU、外设NOR FLASH的最小读/写单元已经固定,那么肯定就是CPU与NOR FLASH之间有个中间层,它来做处理:
这个中间层被称为“Memory Controller”,CPU要进行读写操作时,“Memory Controller”根据NOR FLASH的位宽,每次总是读/写16位数据。
以读操作为例:
CPU想进行8位操作时,它选择其中的8位返回给CPU;
CPU想进行16位操作时,它直接把这16位数据返回给CPU;
CPU想进行32位操作时,它发起2次读/写,把结果组合成32位返回给CPU。

现在的连线是:CPU的(A1-A20)接到 16位的NOR FLASH (A0-A19),即CPU的A0不接──这说明:不管A0是0还是1,NOR FLASH接收到的地址是一样的。
CPU发出地址0bxxxxxxxxx0、0bxxxxxxxxx1时,NOR FLASH看到的都是0bxxxxxxxxx,返回给“Memory Controller”的都是同一个16位数据。
再由“Memory Controller”选择其中的低8位或高8位给CPU。

“Memory Controller”会帮助我们做这些事情,举例为证:
1. 软件要读取地址0上的8位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000000的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000000
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第1个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
   ④ “Memory Controller”把这个16位数据的低8位返回给CPU,这就是一个8位数据。

2. 软件要读取地址1上的8位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000001的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000000
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第1个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
   ④ “Memory Controller”把这个16位数据的高8位(注意,前面的低8位)返回给CPU,这就是一个8位数据。

3. 软件要读取地址2上的8位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000010的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000001
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第2个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
   ④ “Memory Controller”把这个16位数据的低8位返回给CPU,这就是一个8位数据。

4. 软件要读取地址3上的8位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000011的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000001
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第2个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
   ④ “Memory Controller”把这个16位数据的高8位(注意,第3点是低8位)返回给CPU,这就是一个8位数据。

5. 软件要读取地址0和1上的16位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000000的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000000
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第1个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
   ④ “Memory Controller”把这个16位数据返回给CPU

6. 软件要读取地址2和3上的16位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000010的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000001
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第2个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
   ④ “Memory Controller”把这个16位数据返回给CPU

7. 软件要读取地址0、1、2、3上的32位数据时,硬件是这样进行的:
   ① “Memory Controller”发出0b000000000000000000000的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000000
   ② NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第1个“最小数据单元”
   ③ “Memory Controller”读入这个16位数据
 
   ④ “Memory Controller”发出0b000000000000000000010的地址信号,NOR FLASH的A0-A19线上的信号是:0b00000000000000000001
   ⑤ NOR FLASH在数据总线D0~D15上提供一个16位的数据,这是NOR FLASH中的第2个“最小数据单元”
   ⑥ “Memory Controller”读入这个16位数据
   ⑦ “Memory Controller”把两个16位的数据组合成一个32位的数据,返回给CPU。
 
   从1~7可知:
   ① 对于软件而言,它不知道底下发生了什么事,它只管结果:
         读取地址0的8位数据,就得到了一个8位数据;读取地址1的8位数据,就得到另一个紧挨着的8位数据
         读取地址0开始的16位数据,就得到了一个16位数据;读取地址2开始的16位数据,就得到另一个紧挨着的16位数据
         读取地址0开始的32位数据,就得到了一个32位数据;读取地址4开始的32位数据,就得到另一个紧挨着的32位数据
   ② 对于NOR FLASH,它只按照A0-A19地址线,提供16位数据,才不管软件要的是8位、16位,还是32位呢。
   ③ “Memory Controller”完成了这些位宽之间的数据选择、合并。


所以:
外设位宽是8时,CPU的A0~AXX与外设的A0~AXX直接相连
外设位宽是16时,CPU的A1~AXX与外设的A0~AYY直接相连,表示不管CPU的A0是0还是1,外设看到的都是同一个地址,对应16位的数据,“Memory Controller”对数据进行选择或组合,再提供给CPU。
外设位宽是32时,CPU的A2~AXX与外设的A0~AZZ直接相连,表示不管CPU的A0A1是00,01,10还是11,外设看到的都是同一个地址,对应32位的数据,“Memory Controller”对数据进行选择或组合,再提供给CPU。
现在我的程序如果只烧进片内的flash Load "E:\\FZ\\stm32Project\\smartwatchY\\FS-STM32U575-WATCH(Release)\\FS-STM32U575-WATCH(Release)\\MDK-ARM\\FS-STM32U575-Total\\FS-STM32U575-Total.axf" No Algorithm found for: 90000000H - 9000FFFFH No Algorithm found for: 90010000H - 9001FFFFH No Algorithm found for: 90020000H - 9002FFFFH No Algorithm found for: 90030000H - 9003FFFFH No Algorithm found for: 90040000H - 9004FFFFH No Algorithm found for: 90050000H - 9005FFFFH No Algorithm found for: 90060000H - 9006FFFFH No Algorithm found for: 90070000H - 9007FFFFH No Algorithm found for: 90080000H - 9008FFFFH No Algorithm found for: 90090000H - 9009FFFFH No Algorithm found for: 900A0000H - 900AFFFFH No Algorithm found for: 900B0000H - 900BFFFFH No Algorithm found for: 900C0000H - 900CFFFFH No Algorithm found for: 900D0000H - 900DFFFFH No Algorithm found for: 900E0000H - 900EFFFFH No Algorithm found for: 900F0000H - 900FFFFFH No Algorithm found for: 90100000H - 9010FFFFH No Algorithm found for: 90110000H - 9011FFFFH No Algorithm found for: 90120000H - 9012FFFFH No Algorithm found for: 90130000H - 9013FFFFH No Algorithm found for: 90140000H - 9014FFFFH No Algorithm found for: 90150000H - 9015FFFFH No Algorithm found for: 90160000H - 9016FFFFH No Algorithm found for: 90170000H - 9017FFFFH No Algorithm found for: 90180000H - 9018FFFFH No Algorithm found for: 90190000H - 9019FFFFH No Algorithm found for: 901A0000H - 901AFFFFH No Algorithm found for: 901B0000H - 901BFFFFH No Algorithm found for: 901C0000H - 901CFFFFH No Algorithm found for: 901D0000H - 901DFFFFH No Algorithm found for: 901E0000H - 901EFFFFH No Algorithm found for: 901F0000H - 901FFFFFH No Algorithm found for: 90200000H - 9020FFFFH No Algorithm found for: 90210000H - 9021FFFFH No Algorithm found for: 90220000H - 9022FFFFH No Algorithm found for: 90230000H - 9023FFFFH No Algorithm found for: 90240000H - 902408A7H Partial Erase Done (areas with no algorithms skipped!) No Algorithm found for: 90000000H - 9000FFFFH No Algorithm found for: 90010000H - 9001FFFFH No Algorithm found for: 90020000H - 9002FFFFH No Algorithm found for: 90030000H - 9003FFFFH No Algorithm found for: 90040000H - 9004FFFFH No Algorithm found for: 90050000H - 9005FFFFH No Algorithm found for: 90060000H - 9006FFFFH No Algorithm found for: 90070000H - 9007FFFFH No Algorithm found for: 90080000H - 9008FFFFH No Algorithm found for: 90090000H - 9009FFFFH No Algorithm found for: 900A0000H - 900AFFFFH No Algorithm found for: 900B0000H - 900BFFFFH No Algorithm found for: 900C0000H - 900CFFFFH No Algorithm found for: 900D0000H - 900DFFFFH No Algorithm found for: 900E0000H - 900EFFFFH No Algorithm found for: 900F0000H - 900FFFFFH No Algorithm found for: 90100000H - 9010FFFFH No Algorithm found for: 90110000H - 9011FFFFH No Algorithm found for: 90120000H - 9012FFFFH No Algorithm found for: 90130000H - 9013FFFFH No Algorithm found for: 90140000H - 9014FFFFH No Algorithm found for: 90150000H - 9015FFFFH No Algorithm found for: 90160000H - 9016FFFFH No Algorithm found for: 90170000H - 9017FFFFH No Algorithm found for: 90180000H - 9018FFFFH No Algorithm found for: 90190000H - 9019FFFFH No Algorithm found for: 901A0000H - 901AFFFFH No Algorithm found for: 901B0000H - 901BFFFFH No Algorithm found for: 901C0000H - 901CFFFFH No Algorithm found for: 901D0000H - 901DFFFFH No Algorithm found for: 901E0000H - 901EFFFFH No Algorithm found for: 901F0000H - 901FFFFFH No Algorithm found for: 90200000H - 9020FFFFH No Algorithm found for: 90210000H - 9021FFFFH No Algorithm found for: 90220000H - 9022FFFFH No Algorithm found for: 90230000H - 9023FFFFH No Algorithm found for: 90240000H - 902408A7H Partial Programming Done (areas with no algorithms skipped!) Partial Verify OK (areas with no algorithms skipped!) 它会提示这个 但是烧录成功 但是程序的现象不正常 在显示屏中是花屏 我如果选择片外的flash 就会提示oad "E:\\FZ\\stm32Project\\smartwatchY\\FS-STM32U575-WATCH(Release)\\FS-STM32U575-WATCH(Release)\\MDK-ARM\\FS-STM32U575-Total\\FS-STM32U575-Total.axf" Erase Failed! Error: Flash Download failed - "Cortex-M33" Flash Load finished at 19:58:47 出现这个问题 这是什么原因呢?是片外的flash有写保护不让烧写吗?
06-28
内容概要:本文围绕EKF SLAM(扩展卡尔曼滤波同步定位地图构建)的性能展开多项对比实验研究,重点分析在稀疏稠密landmark环境下、预测更新步骤同时进行非同时进行的情况下的系统性能差异,并进一步探讨EKF SLAM在有色噪声干扰下的鲁棒性表现。实验考虑了不确定性因素的影响,旨在评估不同条件下算法的定位精度地图构建质量,为实际应用中EKF SLAM的优化提供依据。文档还提及多智能体系统在遭受DoS攻击下的弹性控制研究,但核心内容聚焦于SLAM算法的性能测试分析。; 适合人群:具备一定机器人学、状态估计或自动驾驶基础知识的科研人员及工程技术人员,尤其是从事SLAM算法研究或应用开发的硕士、博士研究生和相关领域研发人员。; 使用场景及目标:①用于比较EKF SLAM在不同landmark密度下的性能表现;②分析预测更新机制同步否对滤波器稳定性精度的影响;③评估系统在有色噪声等非理想观测条件下的适应能力,提升实际部署中的可靠性。; 阅读建议:建议结合MATLAB仿真代码进行实验复现,重点关注状态协方差传播、观测更新频率噪声模型设置等关键环节,深入理解EKF SLAM在复杂环境下的行为特性。稀疏 landmark 稠密 landmark 下 EKF SLAM 性能对比实验,预测更新同时进行非同时进行对比 EKF SLAM 性能对比实验,EKF SLAM 在有色噪声下性能实验
内容概要:本文围绕“基于主从博弈的售电商多元零售套餐设计多级市场购电策略”展开,结合Matlab代码实现,提出了一种适用于电力市场化环境下的售电商优化决策模型。该模型采用主从博弈(Stackelberg Game)理论构建售电商用户之间的互动关系,售电商作为领导者制定电价套餐策略,用户作为跟随者响应电价并调整用电行为。同时,模型综合考虑售电商在多级电力市场(如日前市场、实时市场)中的【顶级EI复现】基于主从博弈的售电商多元零售套餐设计多级市场购电策略(Matlab代码实现)购电组合优化,兼顾成本最小化收益最大化,并引入不确定性因素(如负荷波动、可再生能源出力变化)进行鲁棒或随机优化处理。文中提供了完整的Matlab仿真代码,涵盖博弈建模、优化求解(可能结合YALMIP+CPLEX/Gurobi等工具)、结果可视化等环节,具有较强的可复现性和工程应用价值。; 适合人群:具备一定电力系统基础知识、博弈论初步认知和Matlab编程能力的研究生、科研人员及电力市场从业人员,尤其适合从事电力市场运营、需求响应、售电策略研究的相关人员。; 使用场景及目标:① 掌握主从博弈在电力市场中的建模方法;② 学习售电商如何设计差异化零售套餐以引导用户用电行为;③ 实现多级市场购电成本风险的协同优化;④ 借助Matlab代码快速复现顶级EI期刊论文成果,支撑科研项目或实际系统开发。; 阅读建议:建议读者结合提供的网盘资源下载完整代码案例数据,按照文档目录顺序逐步学习,重点关注博弈模型的数学表达Matlab实现逻辑,同时尝试对目标函数或约束条件进行扩展改进,以深化理解并提升科研创新能力。
内容概要:本文介绍了基于粒子群优化算法(PSO)的p-Hub选址优化问基于粒子群优化算法的p-Hub选址优化(Matlab代码实现)题的Matlab代码实现,旨在解决物流交通网络中枢纽节点的最优选址问题。通过构建数学模型,结合粒子群算法的全局寻优能力,优化枢纽位置及分配策略,提升网络传输效率并降低运营成本。文中详细阐述了算法的设计思路、实现步骤以及关键参数设置,并提供了完整的Matlab仿真代码,便于读者复现和进一步改进。该方法适用于复杂的组合优化问题,尤其在大规模网络选址中展现出良好的收敛性和实用性。; 适合人群:具备一定Matlab编程基础,从事物流优化、智能算法研究或交通运输系统设计的研究生、科研人员及工程技术人员;熟悉优化算法基本原理并对实际应用场景感兴趣的从业者。; 使用场景及目标:①应用于物流中心、航空枢纽、快递分拣中心等p-Hub选址问题;②帮助理解粒子群算法在离散优化问题中的编码迭代机制;③为复杂网络优化提供可扩展的算法框架,支持进一步融合约束条件或改进算法性能。; 阅读建议:建议读者结合文中提供的Matlab代码逐段调试运行,理解算法流程模型构建逻辑,重点关注粒子编码方式、适应度函数设计及约束处理策略。可尝试替换数据集或引入其他智能算法进行对比实验,以深化对优化效果和算法差异的理解。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值