lwip

    0熱度

    1回答

    我得到了將庫lwIP重寫爲OOP風格的任務,我開始理解,要將其作爲對象流,以便爬入此庫,但問題在於: src \ include \ lwip \ arch.h包含文件cc.h(第43行),它既不能找到也不能找到編譯器

    4熱度

    1回答

    的原始TCP API時的性能問題我使用lwIP向我的系統添加網絡功能。在我的平臺上,我構建了一個緩衝區,每次發送完時都要發送它。這可能會很快發生。系統直接連接到專用局域網中的交換機。最初發送數據的時間差在2秒之間。此外,如果我的內存正確地爲我提供服務,數據包的大小爲720字節。目前使用的緩衝區容量大約爲20000字節,我可能會決定在未來增加這個容量。網絡有100兆比特速度,我想在我的平臺上接近這些

    5熱度

    1回答

    我在嵌入式設備上使用lwIP,我覺得我可能會遇到一些與內存不足相關的錯誤。我知道,mem_malloc函數本身將在內存分配失敗時返回null,但是有什麼方法可以在任意時間點對可用內存進行粗略評估嗎?能夠直接監視它,確定哪些使用模式正在泄漏內存將是一件好事。 謝謝。

    2熱度

    1回答

    我寫使用LwIP的一個Ç程序與FreeRTOS的用於嵌入式設備,該微控制器是Atmel AVR32。 在LwIP的,建立UDP後通過udp_recv()收到回調函數,我知道,回調函數將被調用一次接收到UDP數據報。然後,我可以在回調函數中執行類似process_udp_packet()的操作。但是,如果在回調函數完成之前接收到另一個UDP數據包,這個第二個數據包是否會在緩衝區中排隊?或者立即再次調

    4熱度

    4回答

    當LwIP的netconn_accept()或netconn_recv()函數被調用,如果我們使用的是RTOS,它會阻塞線程和等待,直到超時連接或永遠取決於LWIP_SO_RCVTIME0設置。超時時間等於SYS_ARCH_TIMEOUT。 SYS_ARCH_TIMEOUT被定義爲0xffffffff在覈心包含LwIP堆棧的一部分,所以我認爲它不會被改變。 實際上,我希望它檢查是否有連接,如果不是

    1熱度

    3回答

    我在具有相同IP地址但具有不同端口的客戶端和服務器的同一臺計算機上以C語言實現多線程客戶端 - 服務器套接字編程。我已經在C環境中使用pthread概念實現了它。但是我可以看到只有我的客戶端線程正在運行,而我的服務器線程一旦到達'accept()'例程就停止了。 我想知道可能是什麼問題。如果有任何人能找出我犯了一個錯誤那麼這將是非常有益的 我的客戶端代碼如下所示: void *client_con

    8熱度

    4回答

    我正在使用名爲lwip的TCP/IP堆棧。我已經在下面實現了一個函數來發送數據包,這得益於類似的接收數據包的回調函數。 每次收到數據包時,我都會使用pbuf_alloc函數創建一個緩衝區。然後,我使用udp_sendto發送數據包。最後,我使用pbuf_free釋放緩衝區。 (請參閱下面的代碼。) 由於某些原因,pbuf_free未釋放緩衝區。 (我拿到後n個包,其中n是池大小緩衝區溢出。)The

    7熱度

    2回答

    我正在開發一個嵌入式網絡服務器的控制設備。網絡服務器提供一個控制界面給任何請求它的網絡瀏覽器(從Windows瀏覽器,Mac瀏覽器,iPhone機器人等)。 我遇到的問題是通用方法,一般知道如何訪問設備。即在Web瀏覽器中輸入什麼地址。 固定IP對於我的用戶來說太專業了,可能會出錯,因爲我的設備可能會插入許多不同的本地網絡。使用uPnp服務發現需要軟件在某些平臺的客戶端上運行,並不像輸入網址那麼自

    0熱度

    1回答

    我目前正在使用Atmel AT91SAM9260評估板(帶有多個外設的基於ARM的微控制器)實現一個簡單的tcp/ip服務器。 Atmel提供的一些示例包括基於uIP的Web服務器,但uIP無法處理所需的吞吐量。 我發現基於版本1.1.1(或略高於)的同樣的例子,剛剛服務我。 最近我開始有堆棧問題,我無法找到一個端口到AT91SAM9260與新版本的lwIP。爲了構建這個項目,我使用Eclipse

    0熱度

    1回答

    我開發了一個微控制器上的lwip客戶端,確實似乎在上電時成功獲取IP地址。此外,設備正在成功響應基於網絡的查詢(例如基於套接字的命令,網頁「GET」)。 我遇到的問題是當我看着路由器的「Active IP Table」設備不存在時,我開始懷疑我是否在lwip啓動過程中做了錯誤的事情。 有誰知道我應該開始排除故障嗎? UPDATE(10/20/2011): 我越來越確信,該設備的MAC地址是至少在某