嵌入式系統(tǒng)需要通過標(biāo)準(zhǔn)網(wǎng)絡(luò)接口與外界進(jìn)行通訊,常規(guī)網(wǎng)絡(luò)包括以太網(wǎng)、TCP/IP和套接API琐侣。人們通常認(rèn)為以太網(wǎng)具有非確定性,但是,本文通過測(cè)試和研究表明,當(dāng)集成了100Mb(或1Gb)以太網(wǎng)端口的小型CPU成本經(jīng)濟(jì)辑剿、性能可行時(shí),將有機(jī)會(huì)在分布式I/O中采用TCP/IP協(xié)議。

我以前所做的幾個(gè)嵌入式設(shè)計(jì)項(xiàng)目都需要這樣或那樣的網(wǎng)絡(luò)連接,這些項(xiàng)目不斷重復(fù)著同一主題,即嵌入式系統(tǒng)需要通過標(biāo)準(zhǔn)網(wǎng)絡(luò)接口與外界進(jìn)行通訊拢胆。這些項(xiàng)目通常包括實(shí)時(shí)操作系統(tǒng)(RTOS)和常規(guī)網(wǎng)絡(luò)模式:以太網(wǎng)婆沟、TCP/IP和套接API。通常,這些系統(tǒng)中的以太網(wǎng)數(shù)據(jù)處理要么以非實(shí)時(shí)數(shù)據(jù)的形式轉(zhuǎn)交給后臺(tái)處理,要么數(shù)據(jù)本質(zhì)上是可循環(huán)的,只要數(shù)據(jù)在一段時(shí)間內(nèi)進(jìn)行刷新(約15至30毫秒),一切都可正常工作猛计。換言之,我們并不奢望小于幾個(gè)毫秒的精度唠摹。

然而,我最近承擔(dān)了一項(xiàng)特殊的系統(tǒng)設(shè)計(jì)項(xiàng)目,該系統(tǒng)需要一個(gè)極低延遲時(shí)間的確定性網(wǎng)絡(luò)作為這一項(xiàng)目的核心。這促使我研究確定一般的網(wǎng)絡(luò)工具是否適合該任務(wù)奉瘤。盡管研究期間可以參閱許多優(yōu)秀的網(wǎng)絡(luò)理論跃闹、標(biāo)準(zhǔn)化協(xié)議和結(jié)構(gòu)性原理,但性能規(guī)范始終難以捉摸,因?yàn)榫W(wǎng)絡(luò)系統(tǒng)存在許多不可預(yù)知的因素,如網(wǎng)絡(luò)硬件、網(wǎng)絡(luò)軟件毛好、計(jì)算機(jī)硬件及操作系統(tǒng)等望艺。通過這項(xiàng)研究,我加深了對(duì)TCP/IP和以太網(wǎng)性能特征的實(shí)際了解,而這些細(xì)節(jié)只能通過給定網(wǎng)絡(luò)的實(shí)際運(yùn)用在實(shí)踐中獲得。

該項(xiàng)目的目標(biāo)是通過嵌入式I/O處理器網(wǎng)絡(luò)來替代飛行模擬器中包含1,000多個(gè)I/O的高度集中式I/O系統(tǒng),從而降低生產(chǎn)和設(shè)計(jì)成本肌访。另外,由于降低了配線復(fù)雜性,生產(chǎn)效率預(yù)計(jì)也有所提高找默。新的分布式I/O系統(tǒng)包含許多遠(yuǎn)程節(jié)點(diǎn)(位于其所服務(wù)的面板和儀器附近),這些遠(yuǎn)程節(jié)點(diǎn)相互連接,可在仿真處理器和各種飛行器及模擬器設(shè)備之間傳送數(shù)據(jù)。

最初,以太網(wǎng)被認(rèn)為是最佳的網(wǎng)絡(luò)媒介選擇,它的確能夠滿足低廉硬件吼驶、低生產(chǎn)成本以及每個(gè)模擬器包含50至70個(gè) I/O節(jié)點(diǎn)的要求惩激。畢竟,集成有以太網(wǎng)功能的CPU面板隨處都可買到,因此可大大降低成本。圖1描述了最初設(shè)想的模擬計(jì)算機(jī)系統(tǒng)布局,它在分布式I/O中利用以太網(wǎng)作為網(wǎng)絡(luò)媒介蟹演。

然而,由于以太網(wǎng)是非確定性的,因此需要評(píng)估其它媒介风钻。我們?cè)u(píng)估了各種網(wǎng)絡(luò)總線,包括反射式存儲(chǔ)器、現(xiàn)場(chǎng)總線(通常用于工廠自動(dòng)化)酒请、RS-485等,結(jié)果表明它們都不能經(jīng)濟(jì)有效地滿足要求缎选。以太網(wǎng)看來是最合適的,唯一缺陷是非確定性數(shù)據(jù)傳輸(盡管已廣受注目)。此外,還必須研究以太網(wǎng)是否適用于要求較少延遲時(shí)間和確定性行為的系統(tǒng)陕牲。

以太網(wǎng)否胜、TCP、UDP和IP

我曾多次聽到同仁們這樣老生常談:“以太網(wǎng)是非確定性的”芒极。但是,以太網(wǎng)究竟不確定在哪兒忽愧？是因?yàn)樗皇芟拗?還是僅僅定義適用公差的問題崇已？為解決這些問題,讓我們先從以太網(wǎng)和TCP/IP的基本概念入手,做一下深入探討。

大多數(shù)應(yīng)用程序通過TCP/IP協(xié)議棧與以太網(wǎng)相聯(lián),該協(xié)議棧采用分層的方式實(shí)現(xiàn)組成TCP/IP的各種子協(xié)議脑苫。在網(wǎng)絡(luò)界,TCP/IP是一套基于因特網(wǎng)協(xié)議(IP)的協(xié)議集的統(tǒng)稱,TCP是眾多協(xié)議中的一個(gè)贱起。TCP/IP協(xié)議棧位于以太網(wǎng)驅(qū)動(dòng)器之上,并與之緊密配合。換言之,TCP/IP通過排列輸出數(shù)據(jù)舱踊、緩沖輸入數(shù)據(jù)及提供網(wǎng)間路由機(jī)制,來協(xié)調(diào)應(yīng)用軟件和網(wǎng)絡(luò)驅(qū)動(dòng)器之間的數(shù)據(jù)(信息包)流動(dòng)迫扫。簡單的說,測(cè)試應(yīng)用軟件是通過套接API來訪問TCP/IP協(xié)議棧的。

TCP/IP協(xié)議提供了兩種可選的數(shù)據(jù)傳輸協(xié)議:TCP或UDP孟景。兩者最大的差別在于TCP可提供可靠的連接,確保接收方能收到所發(fā)送的每個(gè)信息包刻渔。而UDP是一種送畢即棄的協(xié)議,如果需要接收方確認(rèn),應(yīng)用軟件本身必須提供確認(rèn)方式。人們或許傾向于更可靠的協(xié)議,但必須認(rèn)識(shí)到可靠性是要付出代價(jià)的让腹。

通過TCP協(xié)議發(fā)送的每一個(gè)信息包都要觸發(fā)接收堆棧發(fā)回一個(gè)確認(rèn)信息包远剩。對(duì)于少量數(shù)據(jù)而言,性能代價(jià)相當(dāng)不合算。例如,如果要傳輸1字節(jié)的數(shù)據(jù),須通過網(wǎng)絡(luò)傳輸一個(gè)64字節(jié)的信息包(以太網(wǎng)信息包的最小尺寸),并相應(yīng)地發(fā)回一個(gè)64字節(jié)的確認(rèn)信息包,這使得整個(gè)網(wǎng)絡(luò)的通信量增大一倍骇窍。在同樣的情況下,使用UDP協(xié)議只需發(fā)送初始信息包即可瓜晤。因此,使用TCP協(xié)議將會(huì)給網(wǎng)絡(luò)添加不必要的開銷,而網(wǎng)絡(luò)并不需要更多的可靠性。

我們利用以太網(wǎng)硬件設(shè)備,即網(wǎng)絡(luò)接口(NI),來連接網(wǎng)絡(luò)媒介腹纳。NI采用一種兩階段總線仲裁方案,即載波偵聽多路訪問與沖突檢測(cè)(CSMA/CD),因此當(dāng)設(shè)備檢測(cè)到總線未被占用時(shí),便發(fā)送數(shù)據(jù),這是總線仲裁協(xié)議的CSMA部分痢掠。該方案允許兩個(gè)或更多設(shè)備同時(shí)在總線上傳輸數(shù)據(jù),這正是CD(沖突檢測(cè))部分的由來。如果同時(shí)訪問總線的情景發(fā)生,設(shè)備便檢測(cè)到“沖突”,經(jīng)過一段隨機(jī)延遲時(shí)間,再重新向總線發(fā)送數(shù)據(jù),直到發(fā)送成功為止嘲恍。這就是以太網(wǎng)最基本的不確定性特征,然而,如果總線仲裁方案能在更高一級(jí)實(shí)現(xiàn)的話,還是有可能超越CSMA/CD方案的足画。

為克服以太網(wǎng)不可預(yù)測(cè)的仲裁方案,我們采用了一種軟件協(xié)議,規(guī)定網(wǎng)絡(luò)設(shè)備只有得到許可才能訪問總線。該協(xié)議并不限制CSMA/CD的使用,而只對(duì)控制以太網(wǎng)媒介訪問的高級(jí)(應(yīng)用)軟件起約束作用佃牛。為使該方案行之有效,必須建立以下規(guī)則:僅專有節(jié)點(diǎn)才能連接到網(wǎng)絡(luò)上淹辞；一個(gè)設(shè)備被指定為控制器,其余設(shè)備視為遠(yuǎn)程節(jié)點(diǎn)；除非控制器發(fā)出請(qǐng)求,否則遠(yuǎn)程節(jié)點(diǎn)不能訪問網(wǎng)絡(luò)總線俘侠；遠(yuǎn)程節(jié)點(diǎn)有預(yù)先設(shè)定的時(shí)間來響應(yīng)控制器請(qǐng)求象缀。

我們?yōu)榭刂破鞴?jié)點(diǎn)設(shè)計(jì)了一個(gè)測(cè)試程序,控制器節(jié)點(diǎn)中的數(shù)據(jù)通過網(wǎng)絡(luò)傳送到遠(yuǎn)程節(jié)點(diǎn)。該程序等待遠(yuǎn)程節(jié)點(diǎn)的響應(yīng)數(shù)據(jù),然后將其與原始傳送數(shù)據(jù)做比較,以檢測(cè)是否出錯(cuò)钦将。如果兩個(gè)數(shù)據(jù)不一致,或者過了預(yù)定時(shí)間遠(yuǎn)程節(jié)點(diǎn)仍未做出響應(yīng),測(cè)試程序便生成一個(gè)出錯(cuò)信息促弯。控制器軟件還可記錄信息包往返的最長阱纷、最短及平均時(shí)間诲厚。遠(yuǎn)程節(jié)點(diǎn)軟件只等待控制器發(fā)來的輸入網(wǎng)絡(luò)數(shù)據(jù),一旦收到數(shù)據(jù),將對(duì)控制器做出回應(yīng)。觀測(cè)這些協(xié)作程序產(chǎn)生的往返數(shù)據(jù)處理時(shí)間可用于評(píng)價(jià)系統(tǒng)的性能郭血。

投入測(cè)試

我們搭建的原型網(wǎng)絡(luò)由2個(gè)節(jié)點(diǎn)(控制器節(jié)點(diǎn)和遠(yuǎn)程節(jié)點(diǎn))組成,通過10BaseT以太網(wǎng)連接,以方便收集實(shí)驗(yàn)網(wǎng)絡(luò)的吞吐量和測(cè)定時(shí)間钟展。我們選用Phar Lap的TNT實(shí)時(shí)內(nèi)核作為所有節(jié)點(diǎn)的運(yùn)行環(huán)境。除該內(nèi)核外,還用到了Phar Lap以太網(wǎng)設(shè)備驅(qū)動(dòng)器和TCP/IP協(xié)議棧瓶答。我們?yōu)槊恳还?jié)點(diǎn)選用了Ampro 486級(jí)100MHz PC/104板肢钙。盡管我們的目標(biāo)是在產(chǎn)品中使用帶有集成以太網(wǎng)10BaseT端口的CPU,但目前尚不可得。因此為了進(jìn)行測(cè)試,我們使用了帶有SMC 91C94以太網(wǎng)接口芯片的Ampro PC/104網(wǎng)絡(luò)接口卡山毛。將一個(gè)示波器連接到每一節(jié)點(diǎn)的并行端口也有利于時(shí)序分析遍削；應(yīng)用軟件中某些數(shù)據(jù)位隨重要事件而設(shè)定和清除,它們被用作時(shí)序指示器。使用示波器對(duì)于該項(xiàng)目來說或許有點(diǎn)大材小用,但它提供了“清楚的校驗(yàn)”,而且看來棒極了,尤其是對(duì)廣大的軟件工程人員而言泽兼。圖2示出了這一測(cè)試系統(tǒng)子擅。

在控制器和遠(yuǎn)程節(jié)點(diǎn)程序的邏輯序列中,控制器節(jié)點(diǎn)調(diào)用速率為60Hz,而遠(yuǎn)程節(jié)點(diǎn)則不斷地循環(huán)。在控制器初始化階段,也會(huì)將信息包發(fā)往遠(yuǎn)程節(jié)點(diǎn)贝咙。這迫使ARP協(xié)議接受初始化的影響,從而不干擾我們的實(shí)時(shí)測(cè)量样悟。

對(duì)結(jié)果波形和軟件累加器的分析表明,2ms是最佳的往返時(shí)間,在此期間可向遠(yuǎn)程節(jié)點(diǎn)發(fā)送64字節(jié)的有效載荷,并保證控制器收到響應(yīng)信息包；最壞情況下的往返時(shí)間為6ms庭猩。

單個(gè)節(jié)點(diǎn)完成往返處理必需的循環(huán)時(shí)間為16.7ms (相應(yīng)的頻率為60Hz),最壞情況下的往返時(shí)間為6ms,該系統(tǒng)只能可靠地支持兩個(gè)遠(yuǎn)程節(jié)點(diǎn)窟她。顯然,該方案只能提供較小的吞吐量,對(duì)于單個(gè)飛行模擬器而言,需要25個(gè)或更多的這種獨(dú)立網(wǎng)絡(luò)。因此該系統(tǒng)需要巨大的性能突破,才能作為傳統(tǒng)堆架式I/O的一種可行替代方案蔼水。

保留TCP/IP

有兩個(gè)問題是顯而易見的震糖。首先,對(duì)于10Mbps的信號(hào)速率,即便最佳情況下的2ms仍是很長的延遲時(shí)間；其次,所產(chǎn)生的抖動(dòng)十分嚴(yán)重趴腋。我們將在稍后討論抖動(dòng)問題吊说。至于延遲時(shí)間,探討一下穿過導(dǎo)線的信息將對(duì)其時(shí)序特征的了解有所啟發(fā)。

測(cè)試中,我們向TCP/IP協(xié)議棧發(fā)送了64字節(jié)數(shù)據(jù)优炬。如圖3所示,隨著協(xié)議報(bào)頭開銷的增加,信息包到達(dá)總線時(shí),這64字節(jié)數(shù)據(jù)將變?yōu)辇嫶蟮?28字節(jié)颁井。讓我們來計(jì)算一下126字節(jié)在10Mbps以太網(wǎng)上往返一次所需的最短時(shí)間。126字節(jié)等于1,008位,乘以100ns(10MHz的倒數(shù))得到100.8μs,再乘以2(因?yàn)閿?shù)據(jù)被發(fā)送回來),最終得到的往返時(shí)間為201.6μs蠢护。我們忽略了像傳播時(shí)滯這樣的次要因素,而實(shí)際上是達(dá)不到這一理論極限值的雅宾。但通過測(cè)量可知,最好情況下的結(jié)果是該極限值的10倍」粑。可見這并不太有效!

早期帶有可變負(fù)載的內(nèi)核測(cè)試顯示,只要涉及定時(shí)和時(shí)序,內(nèi)核性能是一致不變的陶焙。因此,我們認(rèn)為延遲時(shí)間和抖動(dòng)很大程度上可能是由TCP/IP協(xié)議棧或設(shè)備驅(qū)動(dòng)器引起的鹦堕。于是,我決定重寫軟件程序,但不使用TCP/IP協(xié)議听量。由于Phar Lap網(wǎng)絡(luò)驅(qū)動(dòng)器接口表現(xiàn)良好,而且使用現(xiàn)有的驅(qū)動(dòng)器仍可保持部分硬件獨(dú)立性,因此,該計(jì)劃是要修改應(yīng)用程序代碼的網(wǎng)絡(luò)訪問模塊,以便直接與設(shè)備驅(qū)動(dòng)器連接,而非套接庫。

這項(xiàng)修改絕非無足輕重,我們必須創(chuàng)建緩沖管理和信息包結(jié)構(gòu)代碼辆雇。這些改變使得應(yīng)用程序代碼的移植性下降,因?yàn)樗兊脙H適用于某一特定的操作系統(tǒng)榕暴。然而,如果性能的提高能帶來成本效益,那么這種折衷還是值得的。

軟件修改完成后,相同的程序(見表1和表2)將再次運(yùn)行完冻。最好情況下的往返時(shí)間為0.45ms,而最壞情況下為0.6ms飘具。這一修改是分布式I/O項(xiàng)目開發(fā)中的重要步驟,它將最壞情況下的性能提高了一個(gè)數(shù)量級(jí)。性能的提高應(yīng)部分歸功于信息包開銷的降低,這固然緣于摒棄了UDP和IP報(bào)頭,但更大程度上還在于數(shù)據(jù)無需通過功能更多的協(xié)議棧。

在新的結(jié)構(gòu)中,每個(gè)網(wǎng)絡(luò)系統(tǒng)能在最高要求速率下,以最小有效載荷支持20個(gè)遠(yuǎn)程I/O節(jié)點(diǎn)载易。

圖4是從連接到原型系統(tǒng)并行端口的示波器捕獲的屏幕圖像,以下是對(duì)其跡線的描述:

1. 最高曲線:當(dāng)準(zhǔn)備好的信息包發(fā)送到設(shè)備驅(qū)動(dòng)器時(shí),第一控制器節(jié)點(diǎn)信號(hào)設(shè)定為高電平粒惜；當(dāng)控制從驅(qū)動(dòng)器返回時(shí)設(shè)定為低電平。信號(hào)的上升沿位于信息包往返定時(shí)開始之際颈墅。

2. 次高曲線:當(dāng)收到的信息包正確時(shí),第二控制器節(jié)點(diǎn)信號(hào)設(shè)定為高電平蜡镶；當(dāng)信息包收到時(shí),信號(hào)設(shè)定為低電平。信號(hào)下降沿表明信息包一次往返的結(jié)束恤筛。

3. 次低曲線:當(dāng)驅(qū)動(dòng)器通報(bào)信息包可用時(shí),第三遠(yuǎn)程節(jié)點(diǎn)信號(hào)設(shè)定為高電平官还；當(dāng)應(yīng)用程序重新收到該信息包時(shí),信號(hào)設(shè)定為低電平。

4. 最低曲線:在信息包傳輸之前,第四遠(yuǎn)程節(jié)點(diǎn)信號(hào)設(shè)定為高電平毒坛；當(dāng)控制在通知驅(qū)動(dòng)器發(fā)送信息包返回時(shí),信號(hào)設(shè)定為低電平望伦。這段時(shí)間包含從接受信息包到傳輸信息包期間復(fù)制數(shù)據(jù)的時(shí)間。

圖5在原型系統(tǒng)經(jīng)驗(yàn)值的基礎(chǔ)上,顯示了平均信息包大小對(duì)往返時(shí)間的影響煎殷。值得注意的是,由于以太網(wǎng)規(guī)定了信息包的最小長度,往返時(shí)間絕不會(huì)低于500μs屯伞。

構(gòu)建系統(tǒng)

控制器節(jié)點(diǎn)將解析配置文件,并為每一遠(yuǎn)程節(jié)點(diǎn)存儲(chǔ)配置信息。當(dāng)遠(yuǎn)程節(jié)點(diǎn)在線時(shí),這些信息可通過網(wǎng)絡(luò)動(dòng)態(tài)配置遠(yuǎn)程節(jié)點(diǎn)蝌数。為確保系統(tǒng)的確定性,網(wǎng)絡(luò)中的遠(yuǎn)程節(jié)點(diǎn)只有先收到控制器的傳輸請(qǐng)求,才能在以太網(wǎng)總線上傳輸愕掏。此時(shí)它將向控制器發(fā)送一個(gè)信息包,該信息包與來自控制器的信息包類型應(yīng)相互匹配。換言之,如果控制器發(fā)送了一個(gè)數(shù)據(jù)包,指定的遠(yuǎn)程節(jié)點(diǎn)必須發(fā)回一個(gè)數(shù)據(jù)包顶伞。同樣地,如果控制器發(fā)送了一個(gè)配置信息包,則唯一適合的響應(yīng)也是配置響應(yīng)信息包饵撑。遠(yuǎn)程節(jié)點(diǎn)必須在兩次接收控制器信息包期間完成所有的數(shù)據(jù)處理和I/O掃描。

為最大限度地利用CPU,控制器總是在等待當(dāng)前節(jié)點(diǎn)響應(yīng)數(shù)據(jù)包到達(dá)期間處理前一個(gè)節(jié)點(diǎn)收到的信息包,然后再處理下一個(gè)節(jié)點(diǎn)傳輸?shù)男畔裘病＠?如果控制器剛給遠(yuǎn)程節(jié)點(diǎn)3發(fā)送了一個(gè)信息包,控制器接著將處理先前從節(jié)點(diǎn)2接收到的數(shù)據(jù)(如果有的話)拙故；然后著手構(gòu)建發(fā)往節(jié)點(diǎn)4(或任意下一節(jié)點(diǎn))的信息包；控制器等待來自節(jié)點(diǎn)3的信息包或暫停工作吕得；隨后,再將先前構(gòu)造的信息包發(fā)送給節(jié)點(diǎn)4,接著處理來自節(jié)點(diǎn)3的數(shù)據(jù),如此不斷循環(huán)下去亮倍。

分布式I/O網(wǎng)絡(luò)中的信息包符合圖3頂部所示的以太網(wǎng)幀格式,幀類型字段用于確定發(fā)往接收節(jié)點(diǎn)的幀功能,表1列出了所用類型的描述。類型字段之后的8位字段是節(jié)點(diǎn)ID,不管信息包發(fā)往何處,它總是攜帶遠(yuǎn)程節(jié)點(diǎn)的ID浴誉。節(jié)點(diǎn)ID之后是一個(gè)8位錯(cuò)誤代碼字段,信息包的剩余部分是用戶數(shù)據(jù)纠惧。

每個(gè)節(jié)點(diǎn)在專有I/O板上都有一個(gè)8位端口,系統(tǒng)由此確認(rèn)該節(jié)點(diǎn)。對(duì)每一個(gè)登錄在配置文件中的遠(yuǎn)程節(jié)點(diǎn),控制器都會(huì)利用(自帶的)MAC地址查詢(MAQ)協(xié)議來廣播節(jié)點(diǎn)的以太網(wǎng)MAC地址請(qǐng)求孝速。在配置合適的系統(tǒng)中,只有一個(gè)遠(yuǎn)程節(jié)點(diǎn)能響應(yīng)給定的MAQ赛虽。與MAQ信息包節(jié)點(diǎn)ID匹配的遠(yuǎn)程節(jié)點(diǎn)通過發(fā)送MAQ響應(yīng)信息包對(duì)控制器做出響應(yīng)。遠(yuǎn)程節(jié)點(diǎn)還保存了MAQ信息包的源地址,該地址在隨后所有的傳輸中可用來填充目的地址字段橱殉。MAQ響應(yīng)信息包的源字段中包含了響應(yīng)節(jié)點(diǎn)的MAC地址刺泌。接著,控制器將此地址存入列表以便將來建立該響應(yīng)節(jié)點(diǎn)的索引(這很像ARP)。

確定節(jié)點(diǎn)MAC地址后就向其發(fā)送配置信息包泰啼。遠(yuǎn)程節(jié)點(diǎn)以配置響應(yīng)信息包的形式響應(yīng)每個(gè)配置信息包,以通知控制器信息包已收到男枝。遠(yuǎn)程節(jié)點(diǎn)將收到的配置信息包存儲(chǔ)起來,并用于實(shí)時(shí)數(shù)據(jù)轉(zhuǎn)換和定標(biāo)。

每個(gè)分布式I/O網(wǎng)絡(luò)的控制器都以一定的配置速率(即幀速率)進(jìn)行循環(huán)。幀速率的范圍為1Hz 到100Hz,幀速率的1/2场刑、1/4般此、1/8和1/16等次速率可按節(jié)點(diǎn)來分配。這些次速率可用于更密集的系統(tǒng)(網(wǎng)絡(luò)中有更多節(jié)點(diǎn)),而且不會(huì)與高速節(jié)點(diǎn)的定時(shí)要求發(fā)生沖突摇邦。

此外,采用網(wǎng)絡(luò)分析儀可追蹤遠(yuǎn)程MAC地址獲取恤煞、配置循環(huán)和正常數(shù)據(jù)傳輸這一系列事件的序列屎勘。但須注意,時(shí)間字段的精確度為1ms,在1ms內(nèi)可發(fā)生多次傳輸,時(shí)間字段還表明控制器的幀速率為60Hz施籍。

結(jié)論

我并非有意摒棄TCP/IP。相反,該項(xiàng)目使我對(duì)這一重要協(xié)議有了更深入的了解,希望將來有機(jī)會(huì)將這些認(rèn)識(shí)應(yīng)用于實(shí)踐概漱。我確信,當(dāng)帶有集成100Mb(或1Gb)以太網(wǎng)端口的小型CPU變得經(jīng)濟(jì)可行時(shí),我們將有機(jī)會(huì)在分布式I/O中再次采用TCP/IP協(xié)議丑慎。

作者簡介:

Joe Kerkes已在BAE系統(tǒng)公司飛行模擬和訓(xùn)練業(yè)務(wù)部從事研究達(dá)18年之久。現(xiàn)在,作為資深計(jì)算機(jī)系統(tǒng)工程師,他在最近11年中一直從事嵌入式應(yīng)用和系統(tǒng)的設(shè)計(jì)工作瓤摧。此前,他曾為自動(dòng)化測(cè)試設(shè)備設(shè)計(jì)測(cè)試程序和接口竿裂。可通過電子郵件jkerkes1@(暫不可見)與其聯(lián)系照弥。

聲明：本網(wǎng)站所收集的部分公開資料來源于互聯(lián)網(wǎng)腻异，轉(zhuǎn)載的目的在于傳遞更多信息及用于網(wǎng)絡(luò)分享，并不代表本站贊同其觀點(diǎn)和對(duì)其真實(shí)性負(fù)責(zé)壳晨，也不構(gòu)成任何其他建議铣修。本站部分作品是由網(wǎng)友自主投稿和發(fā)布、編輯整理上傳意宝，對(duì)此類作品本站僅提供交流平臺(tái)杭喊，不為其版權(quán)負(fù)責(zé)。如果您發(fā)現(xiàn)網(wǎng)站上所用視頻慎间、圖片烤恃、文字如涉及作品版權(quán)問題，請(qǐng)第一時(shí)間告知粗啼，我們將根據(jù)您提供的證明材料確認(rèn)版權(quán)并按國家標(biāo)準(zhǔn)支付稿酬或立即刪除內(nèi)容肴奠，以保證您的權(quán)益！聯(lián)系電話：010-58612588 或 Email:editor@mmsonline.com.cn蘸概。