【摘要】介绍单片机系统仿真工具PROTEus VsM及其在单片机系统仿真中的应用，并详细阐述采用PR0TEUs vsM建立单片机虚拟实验实的方法。【关键词】PROTEUS VSM；软件；单片机；仿真；虚拟实验牢：
上传时间： 2013-11-20
上传用户：努力努力再努力
linux 中断和设备驱动 本章介绍L i n u x内核是如何维护它支持的文件系统中的文件的，我们先介绍 V F S ( Vi r t u a lFile System，虚拟文件系统)，再解释一下L i n u x内核的真实文件系统是如何得到支持的。L i n u x的一个最重要特点就是它支持许多不同的文件系统。这使 L i n u x非常灵活，能够与许多其他的操作系统共存。在写这本书的时候， L i n u x共支持1 5种文件系统： e x t、 e x t 2、x i a、 m i n i x、 u m s d o s、 msdos 、v f a t、 p r o c、 s m b、 n c p、 i s o 9 6 6 0、 s y s v、 h p f s、 a ffs 和u f s。无疑随着时间的推移，L i n u x支持的文件系统数还会增加。
上传时间： 2013-11-13
上传用户：zxh122
标号： ＦＴＯＤ 功能：格式化浮点数转换成双字节定点数入口条件：格式化浮点操作数在[R0]中。出口信息：OV=1时溢出，OV=0时转换成功：定点数的绝对值在[R0]中（双字节），数符在位1FH中，F0=1 时为整数，CY=1时为一字节整数一字节小数，否则为纯小数。影响资源：PSW、A、B、R2、R3、R4、位1FH 堆栈需求： ６字节FTOD: LCALL MVR0 ；将[R0]传送到第一工作区MOV A,R2JZ FTD4 ；阶码为零，纯小数JB ACC.7,FTD4；阶码为负，纯小数
上传时间： 2013-10-15
上传用户：洛木卓
标号： ＦＳＱＲ 功能：浮点数开平方（快速逼近算法）入口条件：操作数在[R0]中。出口信息：OV=0时，平方根仍在[R0]中，OV=1时，负数开平方出错。影响资源：PSW、A、B、R2～R7 堆栈需求： ２字节FSQR: MOV A,@R0JNB ACC.7,SQRSETB OV ；负数开平方，出错
上传时间： 2013-11-17
上传用户：止絮那夏
标号： ＦＤＩＶ 功能：浮点数除法 入口条件：被除数在[R0]中，除数在[R1]中。出口信息：OV=0时，商仍在[R0]中，OV=1时，溢出。影响资源：PSW、A、B、R2～R7、位1EH、1FH 堆栈需求： ５字节
上传时间： 2014-12-28
上传用户：wfl_yy
入口条件：被除数在R2、R3、R4、R5中，除数在R6、R7中。出口信息：OV=0时商在R2、R3中，OV=1时溢出。影响资源：PSW、A、B、R1～R7 堆栈需求： ５字节DIVS: LCALL MDS ；计算结果的符号和两个操作数的绝对值PUSH PSW ；保存结果的符号LCALL DIVD ；计算两个绝对值的商JNB OV,DVS1 ；溢出否？POP ACC ；溢出，放去结果的符号，保留溢出标志
上传时间： 2013-11-09
上传用户：lht618
一、实验目的１．掌握定时/计数器、输入/输出接口电路设计方法。 ２．掌握中断控制编程技术的方法和应用。３．掌握8086汇编语言程序设计方法。 二、实验内容与要求 微机灯光控制系统主要用于娱乐场所的彩灯控制。系统的彩灯共有12组，在实验时用12个发光二极管模拟。1. 基本要求：灯光控制共有8种模式，如12个灯依次点亮；12个灯同时闪烁等八种。系统可以通过键盘和显示屏的人机对话，将8种模式进行任意个数、任意次序的连接组合。系统不断重复执行输入的模式组合，直至键盘有任意一个键按下，退出灯光控制系统，返回DOS系统。2. 提高要求：音乐彩灯控制系统，根据音乐的变化控制彩灯的变化，主要有以下几种：第一种为音乐节奏控制彩灯，按音乐的节拍变换彩灯花样。第二种音律的强弱（信号幅度大小）控制彩灯。强音时，灯的亮度加大，且被点亮的数目增多。第三种按音调高低（信号频率高低）控制彩灯。低音时，某一部分灯点亮；高音时，另一部分点亮。 三、实验报告要求 １．设计目的和内容 ２．总体设计 ３．硬件设计：原理图（接线图）及简要说明 ４．软件设计框图及程序清单５．设计结果和体会（包括遇到的问题及解决的方法） 四、设计原理我们以背景霓虹灯的一种显示效果为例，介绍控制霓虹灯显示的基本原理。设有一排 n 段水平排列的霓虹灯，某种显示方式为从左到右每0.2 秒逐个点亮。其控制过程如下： 若以“ 1 ”代表霓虹灯点亮，以“ 0 ”代表霓虹灯熄灭，则开始时刻， n 段霓虹灯的控制信号均为“ 0 ”，随后，控制器将一帧 n 个数据送至 n 段霓虹灯的控制端，其中，最左边的一段霓虹灯对应的控制数据为“ 1 ”，其余的数据均为零，即 1000 … 000 。当 n 个数据送完以后，控制器停止送数，保留这种状态（定时） 0.2 秒，此时，第 1 段霓虹灯被点亮，其余霓虹灯熄灭。随后，控制器又在极短的时间内将数据 1100 … 000 送至霓虹灯的控制端，并定时 0.2 秒，这段时间，前两段霓虹灯被点亮。由于送数据的过程很快，我们观测到的效果是第一段霓虹灯被点亮 0.2 秒后，第 2 段霓虹灯接着被点亮，即每隔 0.2 秒显示一帧图样。如此下去，最后控制器将数据 1111 … 111 送至 n 段霓虹灯的控制端，则 n 段霓虹灯被全部点亮。 只要改变送至每段霓虹灯的数据，即可改变霓虹灯的显示方式，显然，我们可以通过合理地组合数据（编程）来得到霓虹灯的不同显示方式。 五、总体方案论证分析系统设计思路如下：1) 采集8位开关输入信号，若输入数据为0时，将其修改为1。确定输入的硬件接口电路。采样输入开关量，并存入NUM的软件程序段。2) 以12个灯依次点亮为例(即灯光控制模式M1)，考虑与其相应的灯光显示代码数据。确定显示代码数据输出的接口电路。输出一个同期显示代码的软件程序段（暂不考虑时隙的延时要求）。3) 应用定时中断服务和NUM数据，实现t＝N×50ms的方法。4) 实现某一种模式灯光显示控制中12个时隙一个周期，共重复四次的控制方法。要求在初始化时采样开关输入数据NUM，并以此控制每一时隙的延时时间；在每一时隙结束时，检查有无键按下，若是退出键按下，则结束灯光控制，返回DOS系统，若是其他键就返回主菜单，重新输入控制模式数据。5) 通过人机对话，输入8种灯光显示控制模式的任意个数、任意次序连接组合的控制模式数据串（以ENTER键结尾）。对输入的数据进行检查，若数据都在1 - 8之间，则存入INBUF；若有错误，则通过屏幕显示输入错误，准备重新输入灯光显示控制模式数据。6) 依次读取INBUF中的控制模式数据进行不同模式的灯光显示控制，在没有任意键按下的情况下，系统从第一个控制模式数据开始，顺序工作到最后一个控制模式数据后，又返回到第一个控制模式数据，不断重复循环进行灯光显示控制。7) 本系统的软件在总体上有两部份，即主程序（MAIN）和实时中断服务程序（INTT）。讨论以功能明确、相互界面分割清晰的软件程序模块化设计方法。即确定有关功能模块，并画出以功能模块表示的主程序（MAIN）流程框图和定时中断服务程序的流程框图。 六、硬件电路设计 以微机实验平台和PC机资源为硬件设计的基础,不需要外加电路。主要利用了以下的资源：1．8255并行口电路8255并行口电路主要负责数据的输入与输出，可以输出数据控制发光二极管的亮灭和读取乒乓开关的数据。实验时可以将8255的A口、B口和一组发光二极管相连，C口和乒乓开关相连。2．8253定时/计数器8253定时/计数器和8259中断控制器一起实现时隙定时。本设计的定时就是采用的t＝N×50ms的方法，50ms由8253定时/计数器的计数器0控制定时，N是在中断服务程序中软件计时。8253的OUT0接到IRQ2，产生中断请求信号。8253定时/计数器定时结束会发出中断信号，进入中断服务程序。3．PC机资源本设计除了利用PC机作为控制器之外，还利用了PC机的键盘和显示器。键盘主要是输入控制模式数据，显示器就是显示提示信息。 七、软件设计 软件主要分为主程序（MAIN）和中断服务程序（INTT），主程序包含系统初始化、读取乒乓开关、读取控制模式数据以及按键处理等模块。中断服务程序主要是定时时间到后根据控制模式数据点亮相应的发光二极管。1．主程序主程序的程序流程图如图1所示。
上传时间： 2014-04-05
上传用户：q986086481
有两种方式可以让设备和应用程序之间联系：1. 通过为设备创建的一个符号链；2. 通过输出到一个接口WDM驱动程序建议使用输出到一个接口而不推荐使用创建符号链的方法。这个接口保证PDO的安全，也保证安全地创建一个惟一的、独立于语言的访问设备的方法。一个应用程序使用Win32APIs来调用设备。在某个Win32 APIs和设备对象的分发函数之间存在一个映射关系。获得对设备对象访问的第一步就是打开一个设备对象的句柄。 用符号链打开一个设备的句柄为了打开一个设备，应用程序需要使用CreateFile。如果该设备有一个符号链出口，应用程序可以用下面这个例子的形式打开句柄：hDevice = CreateFile("\\\\.\\OMNIPORT3", GENERIC_READ | GENERIC_WRITE,FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL ,NULL);文件路径名的前缀“\\.\”告诉系统本调用希望打开一个设备。这个设备必须有一个符号链，以便应用程序能够打开它。有关细节查看有关Kdevice和CreateLink的内容。在上述调用中第一个参数中前缀后的部分就是这个符号链的名字。注意：CreatFile中的第一个参数不是Windows 98/2000中驱动程序(.sys文件)的路径。是到设备对象的符号链。如果使用DriverWizard产生驱动程序，它通常使用类KunitizedName来构成设备的符号链。这意味着符号链名有一个附加的数字，通常是0。例如：如果链接名称的主干是L“TestDevice”那么在CreateFile中的串就该是“\\\\.\\TestDevice0”。如果应用程序需要被覆盖的I/O，第六个参数(Flags)必须或上FILE_FLAG_OVERLAPPED。 使用一个输出接口打开句柄用这种方式打开一个句柄会稍微麻烦一些。DriverWorks库提供两个助手类来使获得对该接口的访问容易一些，这两个类是CDeviceInterface, 和 CdeviceInterfaceClass。CdeviceInterfaceClass类封装了一个设备信息集，该信息集包含了特殊类中的所有设备接口信息。应用程序能有用CdeviceInterfaceClass类的一个实例来获得一个或更多的CdeviceInterface类的实例。CdeviceInterface类是一个单一设备接口的抽象。它的成员函数DevicePath()返回一个路径名的指针，该指针可以在CreateFile中使用来打开设备。下面用一个小例子来显示这些类最基本的使用方法：extern GUID TestGuid;HANDLE OpenByInterface( GUID* pClassGuid, DWORD instance, PDWORD pError){ CDeviceInterfaceClass DevClass(pClassGuid, pError); if (*pError != ERROR_SUCCESS) return INVALID_HANDLE_VALUE; CDeviceInterface DevInterface(&DevClass, instance, pError); if (*pError != ERROR_SUCCESS) return INVALID_HANDLE_VALUE; cout << "The device path is " << DevInterface.DevicePath() << endl; HANDLE hDev; hDev = CreateFile( DevInterface.DevicePath(), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); if (hDev == INVALID_HANDLE_VALUE) *pError = GetLastError(); return hDev;} 在设备中执行I/O操作一旦应用程序获得一个有效的设备句柄，它就能使用Win32 APIs来产生到设备对象的IRPs。下面的表显示了这种对应关系。Win32 API DRIVER_FUNCTION_xxxIRP_MJ_xxx KDevice subclass member function CreateFile CREATE Create ReadFile READ Read WriteFile WRITE Write DeviceIoControl DEVICE_CONTROL DeviceControl CloseHandle CLOSECLEANUP CloseCleanUp 需要解释一下设备类成员的Close和CleanUp：CreateFile使内核为设备创建一个新的文件对象。这使得多个句柄可以映射同一个文件对象。当这个文件对象的最后一个用户级句柄被撤销后，I/O管理器调用CleanUp。当没有任何用户级和核心级的对文件对象的访问的时候，I/O管理器调用Close。如果被打开的设备不支持指定的功能，则调用相应的Win32将引起错误（无效功能）。以前为Windows95编写的VxD的应用程序代码中可能会在打开设备的时候使用FILE_FLAG_DELETE_ON_CLOSE属性。在Windows NT/2000中，建议不要使用这个属性，因为它将导致没有特权的用户企图打开这个设备，这是不可能成功的。I/O管理器将ReadFile和WriteFile的buff参数转换成IRP域的方法依赖于设备对象的属性。当设备设置DO_DIRECT_IO标志，I/O管理器将buff锁住在存储器中，并且创建了一个存储在IRP中的MDL域。一个设备可以通过调用Kirp::Mdl来存取MDL。当设备设置DO_BUFFERED_IO标志，设备对象分别通过KIrp::BufferedReadDest或 KIrp::BufferedWriteSource为读或写操作获得buff地址。当设备不设置DO_BUFFERED_IO标志也不设置DO_DIRECT_IO，内核设置IRP 的UserBuffer域来对应ReadFile或WriteFile中的buff参数。然而，存储区并没有被锁住而且地址只对调用进程有效。驱动程序可以使用KIrp::UserBuffer来存取IRP域。对于DeviceIoControl调用，buffer参数的转换依赖于特殊的I/O控制代码，它不在设备对象的特性中。宏CTL_CODE（在winioctl.h中定义）用来构造控制代码。这个宏的其中一个参数指明缓冲方法是METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, 或METHOD_NEITHER。下面的表显示了这些方法和与之对应的能获得输入缓冲与输出缓冲的KIrp中的成员函数：Method Input Buffer Parameter Output Buffer Parameter METHOD_BUFFERED KIrp::IoctlBuffer KIrp::IoctlBuffer METHOD_IN_DIRECT KIrp::IoctlBuffer KIrp::Mdl METHOD_OUT_DIRECT KIrp::IoctlBuffer KIrp::Mdl METHOD_NEITHER KIrp::IoctlType3InputBuffer KIrp::UserBuffer 如果控制代码指明METHOD_BUFFERED，系统分配一个单一的缓冲来作为输入与输出。驱动程序必须在向输出缓冲放数据之前拷贝输入数据。驱动程序通过调用KIrp::IoctlBuffer获得缓冲地址。在完成时，I/O管理器从系统缓冲拷贝数据到提供给Ring 3级调用者使用的缓冲中。驱动程序必须在结束前存储拷贝到IRP的Information成员中的数据个数。如果控制代码不指明METHOD_IN_DIRECT或METHOD_OUT_DIRECT，则DeviceIoControl的参数呈现不同的含义。参数InputBuffer被拷贝到一个系统缓冲，这个缓冲驱动程序可以通过调用KIrp::IoctlBuffer。参数OutputBuffer被映射到KMemory对象，驱动程序对这个对象的访问通过调用KIrp::Mdl来实现。对于METHOD_OUT_DIRECT，调用者必须有对缓冲的写访问权限。注意，对METHOD_NEITHER，内核只提供虚拟地址；它不会做映射来配置缓冲。虚拟地址只对调用进程有效。这里是一个用METHOD_BUFFERED的例子：首先，使用宏CTL_CODE来定义一个IOCTL代码：#define IOCTL_MYDEV_GET_FIRMWARE_REV \CTL_CODE (FILE_DEVICE_UNKNOWN,0,METHOD_BUFFERED,FILE_ANY_ACCESS)现在使用一个DeviceIoControl调用：BOOLEAN b;CHAR FirmwareRev[60];ULONG FirmwareRevSize;b = DeviceIoControl(hDevice, IOCTL_MYDEV_GET_VERSION_STRING, NULL, // no input 注意，这里放的是包含有执行操作命令的字符串指针 0, FirmwareRev, //这里是output串指针，存放从驱动程序中返回的字符串。sizeof(FirmwareRev),& FirmwareRevSize, NULL // not overlapped I/O );如果输出缓冲足够大，设备拷贝串到里面并将拷贝的资结束设置到FirmwareRevSize中。在驱动程序中，代码看起来如下所示：const char* FIRMWARE_REV = "FW 16.33 v5";NTSTATUS MyDevice::DeviceControl( KIrp I ){ ULONG fwLength=0; switch ( I.IoctlCode() ) { case IOCTL_MYDEV_GET_FIRMWARE_REV: fwLength = strlen(FIRMWARE_REV)+1; if (I.IoctlOutputBufferSize() >= fwLength) { strcpy((PCHAR)I.IoctlBuffer(),FIRMWARE_REV); I.Information() = fwLength; return I.Complete(STATUS_SUCCESS); } else { } case . . . } }
上传时间： 2013-10-17
上传用户：gai928943
(11)实验十一：MMU 在理论上概括或解释MMU，这不是我能胜任的。我仅基于为了理解本实验中操作MMU的代码而对MMU做些说明，现在先简单地描述虚拟地址(VA)、变换后的虚拟地址(MVA)、物理地址(PA) 之间的关系： 启动MMU后，S3C2410的CPU核看到的、用到的只是虚拟地址VA，至于VA如何最终落实到物理地址PA上，CPU是不理会的。而caches和MMU也是看不见VA的，它们利用VA变换得来的MVA 去进行后续操作——转换成PA去读/写实际内存芯片，
上传时间： 2013-10-18
上传用户：jhs541019
为了满足超声波探伤检测的实时性需求，通过研究超声波探伤的工作原理，提出了基于FPGA芯片的实时信号处理系统实现方案及硬件结构设计，并根据FPGA逻辑结构模型实现了软件系统的模块化设计。根据实验测试及统计数据得出，基于FPGA芯片的信号处理系统提高了探伤检测的准确性与稳定性，满足了探伤过程中B超显示的实时性要求。
上传时间： 2013-10-11
上传用户：909000580
