【正文】 度明顯下降，有時還會造成短時失靈。而環(huán)境光不夠亮時，有人體存在才開燈，無人體存在不開燈。on relay 2Jnc SensOut 。 探測器的抗電磁波干擾性能符合GB10408中4. 6. 1要求，一般手機電磁干擾不會引起誤報。、家具、大型盆景或其他隔離物。人體存在傳感器對于徑向移動反應(yīng)最不敏感，而對于橫切方向(即與半徑垂直的方向)、求得最佳檢測靈敏度極為重要的一環(huán)。在數(shù)據(jù)讀/寫完后，RST端應(yīng)置成低電平，以防止外部干擾對DS1302內(nèi)部時鐘的影響。數(shù)據(jù)在SCLK的上升沿串行輸入，在開始的8個時鐘周期把命令字裝入移位寄存器之后，若跟隨的是寫命令字節(jié)，則在下8個SCLK周期的上升沿輸入數(shù)據(jù)字節(jié)，若跟隨在讀命令字節(jié)的8個SCLK周期之后，在下8個SCLK周期的下降沿輸出數(shù)據(jù)字節(jié)。當把此位置為0時，時鐘將啟動。此外，涓流充電寄存器各位的作用及工作原理等在本論文前半部分DS1302的硬件設(shè)計中己作過介紹，此處不再詳述。 a=60H to Set DS130239。s Second again ACall DSRdlByte Cjne a, DSCheckData, DSOK 。初始化DS1302的充電狀態(tài)及其初始時間的設(shè)置。本系統(tǒng)中采用共陽極的數(shù)碼管，其中采用ULN2803作為驅(qū)動數(shù)碼管的段選的芯片，采用簡單又便宜的9012三極管來驅(qū)動數(shù)碼管的位選，節(jié)約成本，程序編寫簡單。又由于ULN2803為低電平驅(qū)動，所以數(shù)據(jù)送到單片機端口之前，應(yīng)在程序中先將數(shù)據(jù)取反，然后將數(shù)據(jù)送到與ULN2803輸入端口相連接單片機的PO端口即可，簡化軟件程序。本系統(tǒng)在運行過程中需要顯示察看的數(shù)據(jù)有時鐘及遙控器鍵盤顯示數(shù)值。系統(tǒng)根據(jù)鍵采集過程中得到的鍵號，散轉(zhuǎn)到相應(yīng)的鍵處理子程序，通過鍵盤設(shè)置修改系統(tǒng)工作參數(shù)。1Ajmp Key2 。5Ajmp Key6 。95系統(tǒng)調(diào)試運行及問題分析 整個系統(tǒng)設(shè)計完成后，要進行運行調(diào)試，排除軟件和硬件的故障，同時驗證系統(tǒng)的可靠性及穩(wěn)定性，使系統(tǒng)符合設(shè)計要求。硬件和軟件分調(diào)完成之后，還要再進行軟件和硬件的聯(lián)調(diào)，在調(diào)試中找出問題，判斷故障源，修改軟硬件。同時還應(yīng)當用萬用表檢查電路，看應(yīng)當開路的地方是否開路，應(yīng)當短路的地方是否短路，電源地線連接是否可靠。:系統(tǒng)軟件程序在編制好以后，可通過匯編軟件對源程序進行匯編，變?yōu)榭蓤?zhí)行的目標代碼，在匯編過程中出現(xiàn)的錯誤，要及時糾正。整個單片機系統(tǒng)進行在線調(diào)試時，需借助仿真開發(fā)工具來對用戶軟件及硬件電路進行診斷、調(diào)試。而對于一些與硬件相關(guān)的用戶程序，如接口驅(qū)動程序等，則需要配合硬件，進行在線調(diào)試，如果有邏輯錯誤，也要及時糾正修改。在本系統(tǒng)的調(diào)試過程中遇到的主要問題及分析解決: 問題1:電源供電電路中集成穩(wěn)壓器溫度過高。問題3:有人存在的教室中，若人體超過十秒沒有活動，人體傳感器是不會有信號輸出的，那么如何判定教室此時有人的問題。 分析解決:單片機輸出控制信號，在控制繼電器時，必須加三極管來驅(qū)動，否則信號電流過小將不能使繼電器產(chǎn)生吸合動作，而且必須采用三極管的集電極端來驅(qū)動繼電器，最后再帶動負載。解決辦法:一方面是充電電池沒有充電功能。同時還加入了時間控制參數(shù)，使教室燈光的控制更加符合學(xué)校的作息時間。系統(tǒng)控制單元的硬件電路中多采用簡易芯片(ULN2803, DS1302, X5045等)，簡化了電路設(shè)計，同時節(jié)省了單片機I/0口資源，為系統(tǒng)進一步擴展留下了空間。軟件設(shè)計上采用多任務(wù)形式對信號的采集、處理，達到最終控制燈光的目的。為防止這種現(xiàn)象發(fā)生，使系統(tǒng)更加可靠，最好采用多個人體傳感器。本系統(tǒng)適用性較好，可以應(yīng)用于教室、樓道和辦公室中。還有，一直在幕后默默理解、支持和幫助我的家人和親戚朋友們。I39。SCK 串行時鐘輸入，其上升沿將數(shù)據(jù)或命令寫入，下降沿將數(shù)據(jù)輸出。 revised 27 September 2002。 Protocol1．IntroductionCommunication networks currently have a widespread use at all hierarchical levels of factory automation systems. Unfortunately, the lack of a well clear standardisation process together with the continuously changing munication requirements have led to the necessity of using an heterogeneous variety of networks and protocols. As a result, several types of networks, such as for example fieldbuses, Local Area Networks (LANs) and Wide Area Networks (WANs), are monly encountered in factory automation systems. This scenario, at the highest hierarchical levels, is rapidly converging towards a de facto standardisation, because, thanks to the impressive growth of the Internet, some very popular protocols such as for example FTP, HTTP, based on the TCP/IP suite are even more adopted also in industrial applications. These protocols are usually implemented on Ethernet networks whose physical extension is limited to that of the plant under control: the resulting networks are normally referred to as Intranets. Conversely, the situation is particularly critical at the lowest level of factory automation systems, called ‘device level’, where fieldbuses are typically used. In this area there has been a proliferation of proprietary products, which are inpatible among each other. At present, many of these products have been included in some international standards such as for example IEC 61158, EN 50170 and EN50254. However, although some considerable efforts to reach a form of harmonisation (. the NOHA ESPRIT project), they are still inpatible. An interesting tendency originated recently is represented by the possibility of using Ethernet networks also at the device level of factory automation systems. The advantages of such a solution are indubitable, among them: a very easy integration with the higher levels, the big availability of hardware ponents, the possibility of accessing the device level through the Internet/Intranet. The use of Ethernet networks at the device level requires suitable real time protocols to implement the typical functions performed at this level. Unfortunately, at present a protocol of this type worldwide recognized as ‘the standard’ is not available. Also in this case, however, some proprietary products are already on the market, and there is the concrete risk of assisting to a new ‘fieldbus war’.For this purpose it is worth mentioning that the IAONA organization encourages the growth of open networking in factory automation systems and the adoption of Ethernet at all levels. IAONA, in particular has the objective of harmonising the different protocols available for Ethernet and to prevent further paper investigates the possibility of adopting a very popular fieldbus protocol, Profibus DP, as a real time protocol for Ethernet networks employed at the device level. In practice, the paper proposes of implementing an Ethernet network with the Profibus DP protocol placed on top of its data link layer. As it will be shown, this solution, which for modity will be later on referred to as DPEthernet, may be realized in a simple way. Moreover, as in this case the interface to the user applications does not change, DPEthernet could replace Profibus DP in any already established application. In detail, the structure of the paper is the following: Section2 reports the main features of Profibus DP. Particular attention will be given to the functions available to the user applications and to their mapping onto data link layer services. Section 3 illustrates the features of Ethernet and of the Logical Link Control (LLC) protocol, which are extensively used by DPEthernet. Section 4 describes how DPEthernet may be implemented. Section 5 takes into consideration some typical configurations of DPEthernet and evaluates their performances using a suitable software simulation package.2. Profibus DPProfibus DP is a protocol designed to perform cyclic high speed data exchange between process controllers and field devices, such as sensors and actuators, in a masterslave configuration.The first version of the Profibus DP standard was issued in 1994. Subsequently it was include