IP協(xié)議和MAC幀我的個人理解

ID:82781 · 發(fā)表于 2015-6-13 17:06

前幾天的試驗中我通過以太網(wǎng)向PC發(fā)送過MAC最小幀，但是一直沒有搭載IP協(xié)議部首和數(shù)據(jù)，其實我是這樣想的，既然網(wǎng)絡的最底層是物理層和數(shù)據(jù)鏈路層，那么不管什么協(xié)議都要被搭載到MAC幀域上，所以只要對MAC幀中加入相應的數(shù)據(jù)就可以了，那么主控制器首先呢寫入MAC目標物理地址和源物理地址，這是為了在實際通信中使用的唯一是真實的地址碼，而IP是邏輯上的，也就是程序中可以改變的，MAC地址則不行，他是全球唯一的，然后后面緊跟IP部首字段，IP部首后邊跟著UDP或者TCP部首，再向后就是數(shù)據(jù)了，端口號都在TCP和UDP這一層，也就是TCP提供了端口號與進程通信，而這個TCP正在學習中。。。，那就是我在主控怎么吧這個TCP實現(xiàn)，還有就是FTP一類的應用層的編程，我想他一定可以用API驚醒操作。但是WIN編程這個還真不懂，所以現(xiàn)在的驗證有如下幾個，1：通過MAC幀發(fā)送IP和UDP協(xié)議的數(shù)據(jù)到PC端看看PC端是否收到數(shù)據(jù)包，2通過ARP寫入MAC幀看看能否解析出PC的物理地址，如果沒問題，那么就可以繼續(xù)學習應用層，因為協(xié)議是分層的，所以我也要一層一層的搞，現(xiàn)在可以確定的是MAC和IP已經(jīng)搞定，就是這個TCP&UDP協(xié)議的搭載了，TCP昨天看了下，比較2，所以我打算使用UDP協(xié)議，最后在物理層的數(shù)據(jù)流就是MAC部首+IP部首+UDP部首+數(shù)據(jù)+FSC,這樣的一個流傳到計算機的網(wǎng)卡，解析出MAC地址，解析出IP地址，解析出UDP端口，他就認為是接受了一個包，初步是這樣想的，有待程序驗證，看看到底能不能受到數(shù)據(jù)包才是王道，要不然就是空想，。。。。。由于IP協(xié)議的部首在我的主控端很容以實現(xiàn)，他的核心就是一個校驗和，所以我在算法上還是難不倒的，但是高層的糾錯啥的我估計就夠嗆了，走一步看一步，反正最中目標是：通過ARM和PC進行通信，當然他不是RS232而是用的以太網(wǎng)和互聯(lián)網(wǎng)協(xié)議，這不是一天兩天能搞明白的，不放棄，一口氣就要玩自己喜歡玩的�。�！

ID:82781 · 發(fā)表于 2015-6-13 17:06

自從前天的通信失利以來，我沒有在把所有的精力都放到上面，我選擇了玩，昨天到今天上午一直在玩DOTA，知道下午感覺該看下了，就打開了編譯器，開始寫程序，把以前的位操作換了種方式，并且在程序內(nèi)部自開閉片選現(xiàn)。結果我要的結果是我成功了，反復試了幾次，后哈哈困擾多天的問題解決了，我對他的內(nèi)部經(jīng)行寫數(shù)據(jù)，然后有毒出來，結果一至，喜出望外，想想也是，勞逸結合還是有理的，這下好了，還是傳說的“分治”法厲害，一個大問題分解成很多小問題，每天高一點，搞不出來也沒關系，重要的是不放棄，知識是積累的，堅定不移的玩下去吧，下午還對內(nèi)部的寄存器進行了定義，現(xiàn)在可以方便的使用他的名字了，直觀許多，接下來的工作就是初始化和發(fā)送接收數(shù)據(jù)啦，手冊手冊，應用層的編程毫無頭緒，TCP/IP也還是不懂，一步一步來吧！即使一小步也有新高度。加油�。�！

ID:82781 · 發(fā)表于 2015-6-13 17:07

昨天開始看以太心片手冊,昨天大體上流覽了一編,今天上午開始細嚼慢咽,看了他的內(nèi)部框架,存儲結構和部分控制寄存器,一個芯片的操作方法已經(jīng)顯基本現(xiàn)出來,單是對IP協(xié)議和MACMII我都沒有認知,下一步要繼續(xù)研究寄存器和協(xié)議.上位機,掙取早日通信上位方面還是有難度,畢竟windows下編程我不太懂,API也不懂,還要用C++也不懂,還有很長的路要走,初步故記得到明年的五月份能通信就謝天謝地了,路隨遠行則將至,加油吧.

帳號		自動登錄	找回密碼
密碼			立即注冊

IP協(xié)議和MAC幀我的個人理解

瀏覽過的版塊