STM32F4上のEthernet over USB

最近、MK STM32F4に基づいたボードをネットワーク上で動作させるというアイデアが生まれました。 イーサネットPHYコントローラーがボード上になかったため、唯一のオプションは、USB FullSpeedインターフェイスを使用してイーサネットデバイスをエミュレートすることでした。 この機能を実装する一般的なUSBクラス標準は、RNDISと呼ばれます。
残念ながら、STM32のRNDISドライバーの検索は失敗しました。 ただし、これは驚くことではありませんでした。 オープンSTM32 USBポートの例は、製造元から提供されたもののみに制限されています。
この不正を修正したかった。 そして、同時に必要なソースを性交することで、将来的には有益になります。
ライブラリのデモバージョンの準備ができたので、MITライセンスとしてライトに投稿します。 したがって、ライブラリに興味があるすべての人-「on health」を使用してください。 ライブラリはLRNDISと呼ばれ、最初の文字は組み込みシステム「LwIP」用のネットワークスタックの使用を意味します。
ライブラリの機能を示すために、stm32f4discoveryボードでサンプルが作成されました。 彼の仕事は、基本サービス（DHCPおよびDNSサーバー）をサポートし、要求されたWEBページをusbホストに転送することです。 したがって、私たちの発見は、USBポートで実行されるほぼ完全なWEBサーバーに変わりました！
これが適用される場所についてのいくつかの言葉。
日常生活では、RNDISデバイスは通常、インターネットにアクセスするためのUSBモデムです。 開発者がPCと無線周波数（またはその他の）トランシーバーとの間の接続チェーンとしてSTM32を選択した場合、おそらくこのようなアプリケーションは実際に有用であることがわかります。 それとも、自分のネットワークをイーサネットセグメントに拡張したいのでしょうか？
私にとって主な利点があると思う別のアプリケーションは、複雑なデバイスを管理するためのインターフェースです。 この分野の典型的なソリューションは、ターミナルソフトウェアの作成です。 同時に、デバイスのサポートとともにそのサポートに対処する必要があり、これは不便です。 実際、Webインターフェースを管理するためにこのようなスキームを拒否することは、ライブラリを使用する可能性の意味です。 ルーターを構成するためのWebベースのインターフェイスを覚えておいてください。 便利に。 いいね 不要なソフトウェアなし。

それで、もし興味があるなら、読んでください...

1. RNDISドライバー

執筆段階では、デバイスに署名し、RNDIS標準をサポートするという2つのタスクが解決されました。
デバイスの署名は、有効なUSB記述子をコンパイルすることになります。 VID値は0x0483（STMicroelectronics）、PID値は0x0123（任意）です。 もちろん、これは商用アプリケーションでは行わないでください。

標準のサポートは、 ドキュメントに従って実行されます 。

また、ネットワーク上には、他のプラットフォーム用の多くのRNDISドライバー（ 1、2、3 ）があり、開発が大幅に簡素化されています。
交換に関しては、送信されたパケットがオーバーヘッド情報でラップされることを除いて、ドライバーはCDCクラスの特性を繰り返します。 デバイスを構成したり、ステータスを取得したりするために、USBホストからリクエストを送信するための特別なインターフェイスもあります。 ドライバーコードは、usbd_rndis_core.cモジュールで詳細に調べることができます。
埋め込みのための最小ドライバー設定は、usbd_rndis_core.hファイルの定義を変更することです。
-デバイスのMACアドレス（PERMANENT_HWADDR、STATION_HWADDR）
-メーカーID（RNDIS_VENDOR）
-MTU値（ETH_MTU）：

#define ETH_MTU 1500 // MTU value #define ETH_LINK_SPEED 250000 // bits per sec #define RNDIS_VENDOR "fetisov" // NIC vendor name #define STATION_HWADDR 0x20,0x89,0x84,0x6A,0x96,0xAA // station MAC #define PERMANENT_HWADDR 0x20,0x89,0x84,0x6A,0x96,0xAA // permanent MAC 

また、usbd_desc.hファイルで、製品の名前（USBD_PRODUCT_STRING）と製造元（USBD_MANUFACTURER_STRING）を変更する必要があります。

Windowsにドライバーをインストールするプロセス：



1.メニュー項目「ドライバーの更新」;
2.ドライバー検索を実行します。
3.リストからドライバーを選択します。
4.デバイスクラスのリストで、[ネットワークアダプタ]を選択します。
5.メーカーのリストで「Microsoft Corporation」を選択します。
6.製品「リモートNDISベースのインターネット共有デバイス」。

ここでは、標準のRNDISデバイスのインストールプロセスについて詳しく説明します 。

2. LwIPを固定します

RNDISドライバーは、802.3（イーサネット）フレームのトランスポート機能のみを提供します。 明らかに、あらゆる種類のパッケージと標準のサポートをネットワークスタック上に置く必要があります。 彼の役割では、最新の（現在の）バージョン1.4.1の組み込みlwipシステムに人気のあるスタックを使用することが決定されました 。 スタックの作成者に敬意を表さなければなりません。統合が非常に簡単であることがわかりました。 そのすべてのために、スタックコードには便利なコメントと指示が豊富にあります。

lwIPは、当初Adam Dunkelsによって開発されたTCP / IPプロトコルスイートの小さな独立した実装であり、現在はここで継続されています。
lwIP TCP / IP実装の焦点は、フルスケールTCPを維持しながらリソース使用量を削減することです。 これにより、lwIPは、数十キロバイトの空きRAMと約40キロバイトのコードROMの空きがある組み込みシステムでの使用に適しています。
主な機能は次のとおりです。
-プロトコル：IP、ICMP、UDP、TCP、IGMP、ARP、PPPoS、PPPoE
-DHCPクライアント、DNSクライアント、AutoIP / APIPA（Zeroconf）、SNMPエージェント（プライベートMIBサポート）
-API：パフォーマンスを向上させるための専用API、オプションのバークレー類似ソケットAPI
-拡張機能：複数のネットワークインターフェイスを介したIP転送、TCP輻輳制御、RTT推定および高速回復/高速再送信
-アドオンアプリケーション：HTTPサーバー、SNTPクライアント、SMTPクライアント、ping、NetBIOSネームサーバー

stm32でのスタックの実行は、ビルドプロセスに特定のソースファイルセットを含めることと、lwipopts.hファイルに定義を入力することに制限されていました。

 #define NO_SYS 1 #define LWIP_RAW 1 #define LWIP_NETCONN 0 #define LWIP_SOCKET 0 #define LWIP_DHCP 0 #define LWIP_ICMP 1 #define LWIP_UDP 1 #define LWIP_TCP 1 #define ETH_PAD_SIZE 0 #define LWIP_IP_ACCEPT_UDP_PORT(p) ((p) == PP_NTOHS(67)) #define MEM_SIZE 10000 #define TCP_MSS (1500 /*mtu*/ - 14 /*ethhdr*/ - 20 /*iphdr*/ - 20 /*tcphhr*/) #define ETHARP_SUPPORT_STATIC_ENTRIES 1 

スタックをSTM32F4に移植する作業は、 以前にSTMicroelectronics（アプリケーションSTSW-STM32070）によって実行されていたことに注意してください。

DHCPサーバーを起動します

ライブラリへのDHCPサーバーの追加は、ホスト側でネットワークインターフェイスを初期化する必要性と関連しています。 デフォルトでは、デバイスの接続時に作成されるインターフェイスは、IPアドレスを自動的に取得するように構成されます。 ライブラリは静的アドレス指定でも正常に機能しますが、これは完全に便利というわけではありません。

残念ながら、lwipが提供するツールの中にはDHCPサーバーがありません。

ただし、これは重大な問題ではありません。 最小限の実装では、DHCPサーバーは非常に最小限です。

ネットワークには、おそらく、lwipスタックで動作する DHCPサーバーの唯一の例が含まれています。 このソースは研究に非常に有用であることが判明しましたが、socket-apiを設定および使用する機能がないため、「現状のまま」の原則に従って埋め込むには適していません。

したがって、DHCPサーバーを作成することが決定されました。

そしてここに彼の控えめな可能性があります
-任意の時間にアドレスを発行する
-MACアドレスによるアドレスの予約
-DNSサーバーの構成

テストプロジェクトでサーバーを接続する：

 #define NUM_DHCP_ENTRY 3 static dhcp_entry_t entries[NUM_DHCP_ENTRY] = { // mac ip address subnet mask lease time { {0}, {192, 168, 7, 2}, {255, 255, 255, 0}, 24 * 60 * 60 }, { {0}, {192, 168, 7, 3}, {255, 255, 255, 0}, 24 * 60 * 60 }, { {0}, {192, 168, 7, 4}, {255, 255, 255, 0}, 24 * 60 * 60 } }; static dhcp_config_t dhcp_config = { {192, 168, 7, 1}, 67, // server address, port {192, 168, 7, 1}, // dns server "stm", // dns suffix NUM_DHCP_ENTRY, // num entry entries // entries }; int main(void) { ... while (dhserv_init(&dhcp_config) != ERR_OK) ; ... } 

DNSサーバーを起動します

私たちの仕事の望ましい結果は、ブラウザに特定のリソース名を入力したときのWebページの表示です。 ただし、これは、ホストを「認識」するDNSサーバーでのみ可能です。 もちろん、アドレスバーにIPアドレス192.168.7.1を直接入力すると、この結果が得られます。 このアドレスにはデフォルトでデバイスがあります。 ただし、より熟練し、DNSサーバーを実行します。

DHCPとは異なり、現在のDNSサーバーの実装はさらに薄くなっています。 現時点では、レコードごとに標準のDNSクエリのみを処理できます。

プロジェクトでサーバーを起動します。

 bool dns_query_proc(const char *name, ip_addr_t *addr) { if (strcmp(name, "run.stm") == 0 || strcmp(name, "www.run.stm") == 0) { addr->addr = *(uint32_t *)ipaddr; return true; } return false; } int main(void) { ... while (dnserv_init(PADDR(ipaddr), 53, dns_query_proc) != ERR_OK) ; ... } 

HTTPサーバーを起動します

長い間、無駄でしたが、lwipパッケージ「contrib-1.4.1」からの有名なサーバーの立ち上げに苦労しなければなりませんでした。 今まで、一見平らな地面に現れる神秘的なHardFaultは、私には謎のままです。 すべての設定がチェックされ、アドレスの読み取りと書き込みが行われ、スタックの深さが...残念ながら。

その後、作業用のhttpサーバーの作成を開始し、mem_mallocによって割り当てられたメモリ領域にアクセスするとHardFaultが繰り返されました。 同時に、アドレスは有効であり、内部RAMに関連していました。 一般的に、彼は喜んでダイナミックアロケーションに別れを告げ、サーバーでスタティックを使用し始めました。 ただし、HardFaultの理由に関する質問は未解決のままであるため、現在のバージョンのライブラリでlwip mem_ *関数を使用するのは安全ではないことに留意する必要があります。

だから、結果はまだ得られた。

HTTPサーバー有効化コード：

 static const my_page_t my_pages[] = { { "/", 200, MIME_TEXT_HTML, page1_html, page1_html_size }, { "/page2.htm", 200, MIME_TEXT_HTML, page2_html, page2_html_size }, { "/page3.htm", 200, MIME_TEXT_HTML, page3_html, page3_html_size }, { "/check.gif", 200, MIME_IMAGE_GIF, check_png, check_png_size }, { NULL, 404, MIME_TEXT_HTML, page_not_found, page_not_found_size } }; bool on_http_req(const http_req_t *req, http_resp_t *resp, void **arg) { const my_page_t *page; for (page = my_pages; page->uri != NULL; page++) if (strcmp(page->uri, req->uri) == 0) break; resp->code = page->code; resp->cont_len = page->size; resp->mime = page->mime; resp->conn_type = CT_CLOSE; *arg = (void *)page; return true; } void http_write_data() { for (int i = 0; i < HTTP_SERVER_MAX_CON; i++) { int n; const htcon_t *con; my_page_t *page; con = htcon(i); if (con == NULL) continue; page = (my_page_t *)con->arg; if (con->state == CON_CLOSED) { htcon_free(i); continue; } if (con->state != CON_ACTIVE) continue; n = page->size - con->writed; htcon_write(i, (char *)page->data + con->writed, n); } } int main(void) { ... htserv_on_req = on_http_req; while (htserv_init(80) != ERR_OK) ; while (1) { stmr(); // call software timers usb_polling(); // usb device polling http_write_data(); // writes http response } } 

未解決の問題

1.他のソフトウェアに含めるための独自の条件があるかもしれないlwipスタックの再ライセンスのニュアンス。
2. Linuxでの作業に関する問題。
3. POST要求処理を追加します。
4.「マルチクエリ」パケットを処理するためのDNSサーバーの最終化。
5. mem_mallocの問題。