startup_stm32f10x_xx.s 启动代码文件选择
startup_stm32f10x_xx.s 启动代码文件选择
stm32 给的库文件太琐碎了，正如它的芯片型号一样繁多，例如启动文件：
网上查到的各个文件的解释是：
startup_stm32f10x_cl.s 互联型的器件，STM32F105xx，STM32F107xxstartup_stm32f10x_hd.s 大容量的STM32F101xx，STM32F102xx，STM32F103xxstartup_stm32f10x_hd_vl.s 大容量的STM32F100xxstartup_stm32f10x_ld.s 小容量的STM32F101xx，STM32F102xx，STM32F103xxstartup_stm32f10x_ld_vl.s 小容
量的STM32F100xxstartup_stm32f10x_md.s 中容量的STM32F101xx，STM32F102xx，STM32F103xxstartup_stm32f10x_md_vl.s 中容量的STM32F100xxstartup_stm32f10x_xl.s FLASH 在512K 到1024K 字节的STM32F101xx，STM32F102xx，STM32F103xx
固件库中的Release_Notes_for_STM32F10x_CMSIS.html 写到：
STM32F10x CMSIS Startup files: startup_stm32f10x_xx.s
Add new startup files for STM32 Low-density Value line devices: startup_stm32f10x_ld_vl.sAdd new startup files for STM32 Medium-density Value line devices: startup_stm32f10x_md_vl.sSystemInit() function is called from startup file (startup_stm32f10x_xx.s) before to branch to application main.To reconfigure the default setting of SystemInit() function, refer to system_stm32f10x.c fileGNU startup file for Low density devices (startup_stm32f10x_ld.s) is updated to fix compilation errors.那到底啥是大容量，小容量啊？又查user manual 才知道
也就是说，例如我用STM32F103RB，那么选启动文件为
startup_stm32f10x_md.s
课程设计报告-滑动窗口协议仿真
滁州学院 课程设计报告 课程名称：计算机网络 设计题目：滑动窗口协议仿真 系别：计算机与信息工程学院 专业：计算机科学与技术 组别：第五组 起止日期: 2011年11月24日~2011年12月7日指导教师:赵国柱 计算机与信息工程学院二○一一年制
课程设计任务书
一. 引言 二. 基本原理 2.1 窗口机制 2.2 1bit滑动窗口协议 2.3 后退N协议 2.4 选择重传协议 2.5 流量控制 三. 需求分析 3.1 课程设计题目 3.2 开发环境 3.3 运行环境 3.4 课程设计任务及要求 3.5 界面要求 3.6 网络接口要求 四. 详细设计 4.1 结构体的定义 4.2 发送方的主要函数 4.3 接受方的主要函数 五.源代码 5.1 发送方的主要代码 5.2 接收方的主要代码 六. 调试与操作说明 致谢 [参考文献] 课程设计的主要内容
1.引言 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家 不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在 数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快， 接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些 问题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认 才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ 协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一 个帧发送ack确认。同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack 对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第 3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落， 只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重 传协议。当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们， 存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。一旦收到重传来的帧后， 就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。 2.基本原理 2.1 窗口机制 滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。接受方为其窗口内的每一个序号保留了一个缓冲区。与每个缓冲区相关联的还有一位，用来指明该缓冲区是满的还是空的。 若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退N协议：发送窗口>1，接收窗口=1；选择重传协议：发送窗口>1,接收窗口>1。 2.2 1bit滑动窗口协议 当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
UBOOT命令详解
常用U-boot命令详解(z) 2010-09-30 15:05:52| 分类：学习心得体会|字号订阅 U-boot发展到现在，他的命令行模式已经非常接近Linux下的shell了，在我编译的 U-boot-2009.11中的命令行模式模式下支持“Tab”键的命令补全和命令的历史记录功能。而且如果你输入的命令的前几个字符和别的命令不重复，那么你就只需要打这几个字符即可，比如我想看这个U-boot的版本号，命令就是“ version”，但是在所有的命令中没有其他任何一个的命令是由“v”开头的，所以只需要输入“v”即可。 [u-boot@MINI2440]# version U-Boot 2009.11 ( 4月04 2010 - 12:09:25) [u-boot@MINI2440]# v U-Boot 2009.11 ( 4月04 2010 - 12:09:25) [u-boot@MINI2440]# base Base Address: 0x00000000 [u-boot@MINI2440]# ba Base Address: 0x00000000 由于U-boot支持的命令实在太多，一个一个细讲不现实，也没有必要。所以下面我挑一些烧写和引导常用命令介绍一下，其他的命令大家就举一反三，或者“help”吧！ （1）获取帮助 命令：help 或? 功能：查看当前U-boot版本中支持的所有命令。 [u-boot@MINI2440]#help ?- alias for'help' askenv - get environment variables from stdin base - print or set address offset bdinfo - print Board Info structure bmp - manipulate BMP image data boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootelf - Boot from an ELF image in memory bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol
STM32启动文件详解
STM32启动文件详解 (2012-07-28 11:22:34) 转载▼ 分类：STM32 标签： stm32 启动 在<
课程设计报告滑动窗口协议仿真
滁州学院 课程设计报告 课程名称: 计算机网络 第五组 起止日期：2011年n 月24 口~2011年12月7 n 指导教师: 设计题目: 滑动窗口协议仿贞 别: 计算机与信息工程学院 业: 计算机科学与技术 计算机与信息工程学院二O —一年制 别: 赵国柱
课程设计任务书 一.引言二-基本原理 窗口机制 Ibit滑动窗口协议后退N协议选择重传协议流量控制三.需求分析 课程设计题目开发环境
运行环境 课程设计任务及要求 界面要求 网络接口要求 0. 详细设计 结构体的定义 发送方的主要函数 接受方的主要函数 五. 源代码 发送方的主要代码 接收方的主要代码 调试与操作说明 致谢 ［参考文献］ 课程设计的主要内容 L引言 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能來不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问题。早期我们使用的是Ibit滑动窗口协议，一次只发送一个帧, 等收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送 ack确认，而是收到儿个帧后，对按序到达的最后一个帧发送ack确认。 同Ibit滑动窗口协议相比，大大减少了 ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了 5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，乂提出了
UBoot移植详解
u－boot 移植步骤详解 1 U-Boot简介 U-Boot，全称Universal Boot Loader，是遵循GPL条款的开放源码项目。从FADSROM、8xxROM、PPCBOOT逐步发展演化而来。其源码目录、编译形式与Linux内核很相似，事实上，不少U-Boot源码就是相应的Linux内核源程序的简化，尤其是一些设备的驱动程序，这从U-Boot源码的注释中能体现这一点。但是U-Boot不仅仅支持嵌入式Linux 系统的引导，当前，它还支持NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS嵌入式操作系统。其目前要支持的目标操作系统是OpenBSD, NetBSD, FreeBSD,4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, ARTOS。这是U-Boot中Universal的一层含义，另外一层含义则是U-Boot除了支持PowerPC系列的处理器外，还能支持MIPS、x86、ARM、NIOS、XScale等诸多常用系列的处理器。这两个特点正是U-Boot项目的开发目标，即支持尽可能多的嵌入式处理器和嵌入式操作系统。就目前来看，U-Boot对PowerPC系列处理器支持最为丰富，对Linux的支持最完善。其它系列的处理器和操作系统基本是在2002年11 月PPCBOOT 改名为U-Boot后逐步扩充的。从PPCBOOT向U-Boot的顺利过渡，很大程度上归功于U-Boot的维护人德国DENX软件工程中心Wolfgang Denk[以下简称W.D]本人精湛专业水平和持着不懈的努力。当前，U-Boot项目正在他的领军之下，众多有志于开放源码BOOT LOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入，以支持更多的嵌入式操作系统的装载与引导。 选择U-Boot的理由： ①开放源码； ②支持多种嵌入式操作系统内核，如Linux、NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS； ③支持多个处理器系列，如PowerPC、ARM、x86、MIPS、XScale； ④较高的可靠性和稳定性； ④较高的可靠性和稳定性； ⑤高度灵活的功能设置，适合U-Boot调试、操作系统不同引导要求、产品发布等； ⑥丰富的设备驱动源码，如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等； ⑦较为丰富的开发调试文档与强大的网络技术支持； 2 U-Boot主要目录结构 - board 目标板相关文件，主要包含SDRAM、FLASH驱动； - common 独立于处理器体系结构的通用代码，如内存大小探测与故障检测；
Keil4 建立STM32工程详解
Keil4 建立STM32工程详解 1：安装mdk412，用注册机注册，这个过程不详细叙述了。 2：在本地某个路径下建立STM32工程文件夹，命名：my_STM32，并在my_STM32下建立rvmdk文件夹，并在rvmdk文件夹内建立 obj，list两个文件夹。 3: 打开Keil4. 4: 选择Project菜单->New uVision Project...，选择.../my_STM32/rvmdk文件夹的路径，并命名工程文件：my_STM32，回车 5：选择器件名称，见图1
图1 单击OK。 6：如图2所示：选择否，不添加Startup.s，以后自己添加。 图2 7：如图3，建立几个Group：startup(即将装入启动文件等)，usr(即将装入应用程序文件)，FWlib(即将装入库文件的.c文件)，doc(即将装入说明文档)
图3 8：右键单击FWlib，Add Files to Group 'FWlib'，选择库文件的路径下的src 文件内的所有文件，并点击Add，如图4所示：
图4 9：将cortexm3_macro.s，stm32f10x_vector.s，stm32f10x_it.c， stm32f10x_it.h，stm32f10x_conf.h，main.c，readme.txt拷贝到my_STM32文件夹内。 10：右键单击usr，Add Files to Group 'usr'，选择main.c，stm32f10x_it.c，stm32f10x_it.h，stm32f10x_conf.h，并Add，如图5所示
STM32启动文件的选择及宏定义及芯片型号更改IAP总结(精)
STM32启动文件的选择及宏定义及芯片型号更改 IAP总结 startup_stm32f10x_cl.s 互联型的器件，STM32F105xx，STM32F107xx startup_stm32f10x_hd.s 大容量的STM32F101xx，STM32F102xx，STM32F103xx startup_stm32f10x_hd_vl.s 大容量的STM32F100xx startup_stm32f10x_ld.s 小容量的STM32F101xx，STM32F102xx，STM32F103xx startup_stm32f10x_ld_vl.s 小容量的STM32F100xx startup_stm32f10x_md.s 中容量的STM32F101xx，STM32F102xx，STM32F103xx startup_stm32f10x_md_vl.s 中容量的STM32F100xx startup_stm32f10x_xl.s FLASH在512K到1024K字节的STM32F101xx， STM32F102xx，STM32F103xx cl：互联型产品，stm32f105/107系列 vl：超值型产品，stm32f100系列 xl：超高密度产品，stm32f101/103系列 ld：低密度产品，FLASH小于64K md：中等密度产品，FLASH=64 or 128 hd：高密度产品，FLASH大于128 在KEIL下可以在项目的选项C/C++/PREPROMCESSOR symbols的Define栏里定义，比如STM32F10X_CL 也可以在STM32F10X.H里用宏定义 #if !defined (STM32F10X_LD && !defined (STM32F10X_LD_VL && !defined (STM32F10X_MD && !defined (STM32F10X_MD_VL && !defined (STM32F10X_HD && !defined (STM32F10X_XL && !defined (STM32F10X_CL #define STM32F10X_HD #endif
第五章数据链路控制及其协议
第五章 数据链路控制及其协议 主要内容 5.1 定义和功能 5.1.1 定义 5.1.2 为网络层提供服务 5.1.3 成帧 5.1.4 差错控制 5.1.5 流量控制 5.2 错误检测和纠正 5.2.1 纠错码 5.2.2 检错码 5.3 基本的数据链路层协议 5.3.1 无约束单工协议 5.3.2 单工停等协议 5.3.3 有噪声信道的单工协议 5.4 滑动窗口协议 5.4.1 一比特滑动窗口协议 5.4.2 退后n帧协议 5.4.3 选择重传协议 5.5 协议说明与验证 5.5.1 通信协议中的形式化描述技术 5.5.2 有限状态机模型 5.5.3 P etri网模型 5.6 常用的数据链路层协议 5.6.1 高级数据链路控制规程HDLC 5.6.2 X.25的链路层协议LAPB 5.6.3 Internet数据链路层协议 5.6.4 ATM数据链路层协议 5.1 定义和功能 5.1.1 定义 要解决的问题： 如何在有差错的线路上，进行无差错传输。 ISO关于数据链路层的定义： 数据链路层的目的是为了提供功能上和规程上的方法，以便建立、维护和
数据链路：从数据发送点到数据接收点（点到点point to point）所经过的传输途径。 虚拟数据通路，实际数据通路。 Fig. 3-1 数据链路控制规程：为使数据能迅速、正确、有效地从发送点到达接收点所采用的控制方式。 数据链路层协议应提供的最基本功能 数据在数据链路上的正常传输（建立、维护和释放） 定界与同步，也处理透明性问题 差错控制 顺序控制 流量控制 5.1.2 为网络层提供服务 为网络层提供三种合理的服务 无确认无连接服务 适用于 误码率很低的线路，错误恢复留给高层； 实时业务 大部分局域网 有确认无连接服务 适用于不可靠的信道，如无线网。
STM32固件库详解42324
STM32固件库详解 最近考试较多，教材编写暂停了一下，之前写了很多，只是每一章都感觉不是特别完整，最近把其中的部分内容贴出来一下，欢迎指正。本文内容基于我对固件库的理解，按照便于理解的顺序进行整理介绍，部分参考了固件库的说明，但是也基本上重新表述并按照我理解的顺序进行重新编写。我的目的很简单，很多人写教程只是告诉你怎么做，不会告诉你为什么这么做，我就尽量吧前因后果都说清楚，这是我的出发点，水平所限，难免有很大的局限性，具体不足欢迎指正。基于标准外设库的软件开发 STM32标准外设库概述 STM32标准外设库之前的版本也称固件函数库或简称固件库，是一个固件函数包，它由程序、数据结构和宏组成，包括了微控制器所有外设的性能特征。该函数库还包括每一个外设的驱动描述和应用实例，为开发者访问底层硬件提供了一个中间API，通过使用固件函数库，无需深入掌握底层硬件细节，开发者就可以轻松应用每一个外设。因此，使用固态函数库可以大大减少用户的程序编写时间，进而降低开发成本。每个外设驱动都由一组函数组成，这组函数覆盖了该外设所有功能。每个器件的开发都由一个通用API (application programming interface 应用编程界面)驱动，API对该驱动程序的结构，函数和参数名称都进行了标准化。
ST公司2007年10月发布了版本的固件库，MDK 之前的版本均支持该库。2008年6月发布了版的固件库，从2008年9月推出的MDK 版本至今均使用版本的固件库。以后的版本相对之前的版本改动较大，本书使用目前较新的版本。 使用标准外设库开发的优势 简单的说，使用标准外设库进行开发最大的优势就在于可以使开发者不用深入了解底层硬件细节就可以灵活规范的使用每一个外设。标准外设库覆盖了从GPIO到定时器，再到CAN、I2C、SPI、UART和ADC 等等的所有标准外设。对应的C源代码只是用了最基本的C编程的知识，所有代码经过严格测试，易于理解和使用，并且配有完整的文档，非常方便进行二次开发和应用。 STM32F10XXX标准外设库结构与文件描述 1. 标准外设库的文件结构 在上一小节中已经介绍了使用标准外设库的开发的优势，因此对标准外设库的熟悉程度直接影响到程序的编写，下面让我们来认识一下STM32F10XXX的标准外设库。STM32F10XXX的标准外设库经历众多的更新目前已经更新到最新的版本，开发环境中自带的标准外设库为版本，本书中以比较稳定而且较新的版本为基础介绍标准外设库的结构。
u-boot启动分析
背景： Board →ar7240(ap93) Cpu →mips 1、首先弄清楚什么是u-boot Uboot是德国DENX小组的开发，它用于多种嵌入式CPU的bootloader程序, uboot不仅支持嵌入式linux系统的引导，当前，它还支持其他的很多嵌入式操作系统。 除了PowerPC系列，还支持MIPS，x86，ARM，NIOS，XScale。 2、下载完uboot后解压，在根目录下，有如下重要的信息（目录或者文件）： 以下为为每个目录的说明： Board：和一些已有开发板有关的文件。每一个开发板都以一个子目录出现在当前目录中，子目录存放和开发板相关的配置文件。它的每个子文件夹里都有如下文件(以ar7240/ap93为例)： Makefile Config.mk Ap93.c 和板子相关的代码 Flash.c Flash操作代码 u-boot.lds 对应的链接文件 common：实现uboot命令行下支持的命令，每一条命令都对应一个文件。例如bootm命令对应就是cmd_bootm.c cpu：与特定CPU架构相关目录，每一款Uboot下支持的CPU在该目录下对应一个子目录，比如有子目录mips等。它的每个子文件夹里都有入下文件： Makefile Config.mk Cpu.c 和处理器相关的代码s Interrupts.c 中断处理代码 Serial.c 串口初始化代码 Start.s 全局开始启动代码 Disk：对磁盘的支持
Doc：文档目录。Uboot有非常完善的文档。 Drivers：Uboot支持的设备驱动程序都放在该目录，比如网卡，支持CFI的Flash，串口和USB等。 Fs：支持的文件系统，Uboot现在支持cramfs、fat、fdos、jffs2和registerfs。 Include：Uboot使用的头文件，还有对各种硬件平台支持的汇编文件，系统的配置文件和对文件系统支持的文件。该目下configs目录有与开发板相关的配置文件，如 ar7240_soc.h。该目录下的asm目录有与CPU体系结构相关的头文件，比如说mips 对应的有asm-mips。 Lib_xxx：与体系结构相关的库文件。如与ARM相关的库放在lib_arm中。 Net：与网络协议栈相关的代码，BOOTP协议、TFTP协议、RARP协议和NFS文件系统的实现。 Tools：生成Uboot的工具，如：mkimage等等。 3、mips架构u-boot启动流程 u-boot的启动过程大致做如下工作： 1、cpu初始化 2、时钟、串口、内存(ddr ram)初始化 3、内存划分、分配栈、数据、配置参数、以及u-boot代码在内存中的位置。 4、对u-boot代码作relocate 5、初始化malloc、flash、pci以及外设(比如，网口) 6、进入命令行或者直接启动Linux kernel 刚一开始由于参考网上代码，我一个劲的对基于smdk2410的板子，arm926ejs的cpu看了N 久，启动过程和这个大致相同。 整个启动中要涉及到四个文件： Start.S →cpu/mips/start.S Cache.S →cpu/mips/cache.S Lowlevel_init.S →board/ar7240/common/lowlevel_init.S Board.c →lib_mips/board.c 整个启动过程分为两个阶段来看： Stage1：系统上电后通过汇编执行代码 Stage2：通过一些列设置搭建了C环境，通过汇编指令跳转到C语言执行. Stage1： 程序从Start.S的_start开始执行.(至于为什么，参考u-boot.lds分析.doc) 先查看start.S文件吧!~ 从_start标记开始会看到一长串莫名奇妙的代码：
UBoot源码分析1
?UBoot源码解析（一）
主要内容 ?分析UBoot是如何引导Linux内核 ?UBoot源码的一阶段解析
BootLoader概念?Boot Loader 就是在操作系统内核运行之前运行 的一段小程序。通过这段小程序，我们可以初始 化硬件设备、建立内存空间的映射图，从而将系 统的软硬件环境带到一个合适的状态，以便为最 终调用操作系统内核准备好正确的环境 ?通常，Boot Loader 是严重地依赖于硬件而实现 的，特别是在嵌入式世界。因此，在嵌入式世界 里建立一个通用的Boot Loader 几乎是不可能的。 尽管如此，我们仍然可以对Boot Loader 归纳出 一些通用的概念来，以指导用户特定的Boot Loader 设计与实现。
UBoot来源?U-Boot 是 Das U-Boot 的简称，其含义是 Universal Boot Loader，是遵循 GPL 条款的开放源码项目。最早德国 DENX 软件工程中心的 Wolfgang Denk 基于 8xxROM 和 FADSROM 的源码创建了 PPCBoot 工程项目，此后不断 添加处理器的支持。而后，Sysgo Gmbh 把 PPCBoot 移 植到 ARM 平台上，创建了 ARMBoot 工程项目。最终， 以 PPCBoot 工程和 ARMBoot 工程为基础，创建了 U- Boot 工程。 ?而今，U-Boot 作为一个主流、通用的 BootLoader，成功地被移植到包括 PowerPC、ARM、X86 、MIPS、NIOS、XScale 等主流体系结构上的百种开发板，成为功能最多、 灵活性最强，并且开发最积极的开源 BootLoader。目前。 U-Boot 仍然由 DENX 的 Wolfgang Denk 维护
STM32F10x 启动代码文件选择
startup_stm32f10x_xx.s 启动代码文件选择startup_stm32f10x_cl.s 互联型的器件，STM32F105xx，STM32F107xx startup_stm32f10x_hd.s 大容量的STM32F101xx，STM32F102xx，STM32F103xx startup_stm32f10x_hd_vl.s 大容量的STM32F100xx startup_stm32f10x_ld.s 小容量的STM32F101xx，STM32F102xx，STM32F103xx startup_stm32f10x_ld_vl.s 小容量的STM32F100xx startup_stm32f10x_md.s 中容量的STM32F101xx，STM32F102xx，STM32F103xx startup_stm32f10x_md_vl.s 中容量的STM32F100xx startup_stm32f10x_xl.s FLASH在512K到1024K字节的STM32F101xx，STM32F102xx，STM32F103xx 固件库中的Release_Notes_for_STM32F10x_CMSIS.html写到： STM32F10x CMSIS Startup files: startup_stm32f10x_xx.s Add new startup files for STM32 Low-density Value line devices: startup_stm32f10x_ld_vl.s Add new startup files for STM32 Medium-density Value line devices: startup_stm32f10x_md_vl.s SystemInit() function is called from startup file (startup_stm32f10x_xx.s) before to branch to applic ation main. To reconfigure the default setting of SystemInit() function, refer to system_stm32f10x.c file GNU startup file for Low density devices (startup_stm32f10x_ld.s) is updated to fix compilation err ors. 例如我用STM32F103RB，那么选启动文件为startup_stm32f10x_md.s
计算机网络选择重传协议实验报告
《计算机网络》选择重传协议 实验报告
1.实验内容和实验环境描述 实验内容： 利用所学数据链路层原理，设计一个滑动窗口协议，在仿真环境下编程实现有噪音信道环境下两站点之间无差错双工通信。信道模型为8000bps 全双工卫星信道，信道传播时延270毫秒，信道误码率为10-5，信道提供字节流传输服务，网络层分组长度固定为256字节。 实验环境： Windows7—64位操作系统PC机VC 6.0 2.协议设计 数据结构： 数据帧 +=========+========+========+===============+========+ | KIND(1)| SEQ(1) | ACK(1) | DATA(240~256) | CRC(4) | +=========+========+========+===============+========+ 确认帧 +=========+========+========+ | KIND(1) | ACK(1) | CRC(4) | +=========+========+========+ 否定确认帧 +=========+========+========+ | KIND(1) | ACK(1) | CRC(4) | +=========+========+========+ KIND：表示帧的类别 ACK：ACK序列号 SEQ：帧序列号 CRC：校验和
模块结构： staticinc(Uchar* a) 作用：使一个字节在0~MAX_SEQ的范围内循环自增。 参数：a，字节类型。 static between(Uchara,Ucharb,Uchar c) 作用：判断当前帧是否落在发送/接收窗口内。 参数：a,b,c，均为字节类型，其中两个分别为窗口的上、下界，一个为帧的编号。其中，发送窗口的上界和下界分别为next_to_send和ack_expected，接收窗口的上界和下界分别为too_far和frame_expected，均定义在main函数中。 static void put_frame(unsigned char *frame, intlen) 作用：为一个帧做CRC校验，填充至帧的尾部并将其递交给网络层发送。 参数：frame，字节数组，由除padding域之外的帧内容转换而来；len，整型，为帧的当前长度。 staticsend_frame_(Ucharfk,Ucharnext_frame,Ucharframe_expected,Packetout_buf[]) 作用：构造一个帧，并将其发送。 参数：fk，字节类型，为帧的内容；next_frame，字节类型，为帧的编号；frame_expected，字节类型，为希望收到的帧的编号；out_buf，二维字节数组，为缓冲区。 int main(intargc,char *argv[]) 作用：主程式，包含选择重传协议的算法流程。 参数：argc，整型，表示命令行参数的个数；argv，二维字符数组，表示参数内容。 算法流程：
用STM32一步一步点亮led灯
STM32之一步一步点亮led (2011-05-09 19:40) 标签: stm32led v3.4MDK 4.12入门分类：stm32 入手stm32以来，一直想快速上手，所以在各大论坛闲逛，各个达人的blog 上学习，正所谓欲速则不达，心急是吃不了热豆腐的！有木有？ 最终决定使用st官网的库开发，据大侠们写道使用库可以快速上手，貌似的确如此，一个个教程写的那么好，直接拿过来用就是了。可是那么多个库，聪明的你请告诉到底选择哪一个啊？My God！实话实说，我被这些库折腾了个够！好吧，我最后还是承认最后用的是v3.4的库，是很方便！ 切入正题，点亮LED。 硬件：红牛开发板，STM32F103ZET6（144封装）. 软件：RealView MDK 4.12 stm32固件库：v3.4 附上自己整理后的库： V3.4_clean.rar 根据官网库自己整理了下，新建了工程模板如下图：（主要参考文章《在 Keil MDK+环境下使用STM32 V3.4库.pdf》）在KeilMDK+环境下使用STM32V3.4库.pdf 入图所示：新建一个目录01_ProLed,建议放在英文路径下，避免不必要的麻烦。将上面的库v3.4解压到此目录，再新建一个project目录，存放工程。 说明： CMSIS：最底层接口。StartUp：系统启动文件。StdPeriph_Lib：stm32外围设
备驱动文件。Project：工程文件。User：用户文件。新建工程步骤：此处略去300字。 简单说明： 1.core_cm3.c/core_cm3.h 该文件是内核访问层的源文件和头文件，查看其中的代码多半是使用汇编语言编写的。在线不甚了解。--摘自《在Keil MDK+环境下使用STM32 V3.4库》 2.stm32f10x.h 该文件是外设访问层的头文件，该文件是最重要的头文件之一。就像51里面的reg51.h一样。例如定义了 CPU是哪种容量的 CPU，中断向量等等。除了这些该头文件还定义了和外设寄存器相关的结构体，例如： 1.typedef struct
STM32启动概述
STM32启动代码概述 一般嵌入式开发流程就是先建立一个工程，再编写源文件，然后进行编译，把所有的*.s文件和*.c文件编译成一个*.o文件，再对目标文件进行链接和定位，编译成功后会生成一个*.hex文件和调试文件，接下来要进行调试，如果成功的话，就可以将它固化到flash里面去。 启动代码是用来初始化电路以及用来为高级语言写的软件作好运行前准备的一小段汇编语言，是任何处理器上电复位时的程序运行入口点。 比如，刚上电的过程中，PC机会对系统的一个运行频率进行锁定在一个固定的值，这个设计频率的过程就是在汇编源代码中进行的，也就是在启动代码中进行的。与此同时，设置完后，程序开始运行，注意，程序是在内存中运行的。这个时候，就需要把一些源文件从flash里面copy到内存中，又要对它们进行初始化读写，这又有频率的设置。这些都是初始化。 初始化完成后，我们又要设置一些堆栈，要跳到C语言的main函数里面运行。这就需要堆栈。对普通的ARM CPU有这样一个要求：在绝对地址为零的地方要放置一个异常向量表，但并不是所有的ARM CPU都留有这个一个空间，这就需要用到映射的功能。我们可以将其它地方的一些空间映射到绝对地址里面。当发生异常时，ARM核来读取异常中断表的时候，它会使用映射之后的那个表，这个就可以接着往下执行，否则在绝对地址零的地方找不到任何信息，程序就会死掉。这些运行的环境全部建立好后，程序就会跳转到我们的main函数里面。 总之，启动代码，就是对最小系统的初始化。包括晶振，CPU频率等。 启动代码的最小系统是：异常向量表的初始化–存储区分配–初始化堆栈–高级语言入口函数调用– main()函数。 程序的启动过程：
uboot_freescale_imx51_start.s_详解
/* * *Purpose: the document is used to learn detailed information aboutimx51 cpu start.S, *referring to some documents on websites. *file address: U-boot-2009.08/Cpu/Arm_cortexa8/start.S * * writer: xfhai 2011.7.22 * *Instruction: *1.@xxxx : indicates annotation *2./***** *** *****/ : stand for code in my files *3.instructions refers to code not included in my file * */ Section 1: uboot overview 大多数bootloader都分为stage1和stage2两部分，u-boot也不例外。依赖于CPU体系结构的代码（如设备初始化代码等）通常都放在stage1且可以用汇编语言来实现，而stage2则通常用C语言来实现，这样可以实现复杂的功能，而且有更好的可读性和移植性。 1、Stage1 start.S代码结构 u-boot的stage1代码通常放在start.S文件中，他用汇编语言写成，其主要代码部分如下：==> （1）定义入口。由于一个可执行的Image必须有一个入口点，并且只能有一个全局入口，通常这个入口放在ROM（Flash）的0x0地址，因此，必须通知编译器以使其知道这个入口，该工作可通过修改连接器脚本来完成。 ==>（2）设置异常向量（Exception Vector）。 ==>（3）设置CPU的速度、时钟频率及终端控制寄存器。 ==>（4）初始化内存控制器。 ==>（5）将ROM中的程序复制到RAM中。 ==>（6）初始化堆栈。 ==>（7）转到RAM中执行，该工作可使用指令ldr pc来完成。 2、Stage2 C语言代码部分 lib_arm/board.c中的start arm boot是C语言开始的函数也是整个启动代码中C语言的主函数，同时还是整个u-boot（armboot）的主函数，该函数只要完成如下操作： ==>（1）调用一系列的初始化函数。 ==>（2）初始化Flash设备。 ==>（3）初始化系统内存分配函数。 ==>（4）如果目标系统拥有NAND设备，则初始化NAND设备。 ==>（5）如果目标系统有显示设备，则初始化该类设备。 ==>（6）初始化相关网络设备，填写IP、MAC地址等。 ==>（7）进去命令循环（即整个boot的工作循环），接受用户从串口输入的命令，然后进行相应的工作。
STM32_V3.5的固件库工程模板
准备工作如下: 1：下载STM32_V3.5的固件库去论坛上找，很多 2：准备Keil uVision4 软件，并安装到电脑上。 3：不要带板凳了，带上你的脑袋就行，因为板凳不会思考。 开始： 1：首先解压缩下载的固件库（保留一个备份，你懂的） 里面有， _htmresc ： ST的 logo完全无用，不用理会， Libraries：比较重要的文件包含STM32的系统文件和大量头文件，也就是库文件了。 Project：包含大量外设的例程，和各个软件版本的评估版工程模板。 KEIL对应的就是 MDK-ARM 文件下的工程模板。你也可以利用这个工程模板来修改，得到你自己的工程模块，本文不用此法。 Utilities：就是评估版的相关文件：本文也不会用到，无视既可。 这四个文件，（先去掉文件的只读属性吧，相信你会的） 2：安照一般的方法，建立工程模板先建立一些文件夹，比如工程模板要建在D盘，下面的 D:\STM32\PRO1（项目名字，自己随便定）再该文件夹下面新建以下文件夹 Libraries：直接复制上述的的Libraries文件夹，把其中的CMSIS剪切出来，放到PRO1目录下，直接成为另一个文件夹。另外把STM32F10x_StdPeriph_Driver下的inc和src文件夹剪切出来，放在Libraries目录下，STM32F10x_StdPeriph_Driver文件夹就可以删除了。会发现里面就只剩下头文件了。 CMSIS：就是从上面粘贴来的。在CMSIS\CM3\DeviceSupport\ST\STM32F10x目录下直接将Sta rtu p文件剪切出来，放在Libraries目录下，其他的不需要动。里面存放的就是重要的系统文件，先不要理会是什么作用吧，慢慢就明白了。 Startup 就是从上面粘贴来的。我们要用的比如是：STM32F103VC，只要把startup\arm目录下的startup_stm32f10x_hd.s文件剪切出来，放到Startup 下面就好。Startup只要这个文件，
滑动窗口的仿真协议
计算机网络课程设计书
计算机网络课程设计说明书 （封面） 学院名称：计算机与信息工程学院 班级名称：网络工程一班 学生姓名： 学号：201321 题目：滑动窗口协议仿真 指导教师 姓名：邵雪梅 起止日期：2015.6.23－2015.6.29 第一部分：正文部分 一，选题背景
早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点 阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问 题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等 收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。 同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。 发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重传协议。当接收 方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。一旦收 到重传来的帧后，就可以将存于缓冲区中的其余帧一并按正确的顺序 递交给主机。本文主要介绍如何根据滑动窗口协议的原理，在Visual C++的平台上设计一个滑动窗口协议模拟程序，并最终使该程序得以实现。本次程序设计分两部分：第一部分是发送方，第二部分是接收方。通过发送方和接收方之间的数据帧传输模拟，学习滑动窗口协议控制流量的原理和方法，以及滑动窗口协议的工作机制。 二、设计理念 2.1滑动窗口协议工作原理