STM 32 F 1 F 4 USBエンジニアリング更新

現状

STM 32 C ubeMXに基づくF 103/F 40 XのUSBスタックテスト完了;

Mbed OSに基づくF 103/F 40 XのUSBスタックテスト完了;

主にUSB CDC設備をテストする.

USB ACM/CCCに基づいてnRF 24 L 01及び類似の「小無線」システム集積を実現する.

USB ACM/DCに基づくVT 100 cmdline

を開発した.

USB ACM/CCCとcmdlineに基づいてSPI NOR Flashの読み書きを実現する.

USB ACM/DCに基づいてHCIカスタムプロトコルを開発する.

Linux udevに基づくUSBデバイス挿入抜去時間の検出;

けいかく

は他のTLVタイプのバイナリプロトコルと文字列に基づくJSON RPCなどのプロトコルを開発する.

はxmodem伝送を実現する.

I 2 Cデバイスのスキャンとアクセスを実現する.

既存のLoRaPHY/Aloha/LooRaWAN USB Dongleを更新する.

はC 8 T 6/RCT 6など多くのコアボードをサポートし、より複雑なスタックに対応する.

はUSB ECMをサポートし、6 LowPANなどのユビキタスネットワーク設備を直接サポートする.

Arduino STM 32を統合したBootloaderは、ファームウェアのアップグレードを実現します.

オープンソース設計とボード製品

の大部分の設計はオープンソース設計である.

またはお客様の要求に基づいてカスタマイズして設計します.

コード設計プロセス

以下、Mbed C++およびSTM 32 F 103/F 407について
今日完成したのは主にUSBチャネル上でVT 100 cmdlineを実現し、TeraTerm端末を通じて管理設備を配置したり、専門のcmd/GUI上位機プログラムを通じて自動化配置を実現したりすることができます.最初にCとシリアルポートに基づいてMbed Serialクラスへの移植も容易である.しかし、USBチャネル上でcmdlineを実現するには時間がかかり、繰り返しがあった.主な理由は、USBオブジェクトの初期化の特殊性と、Mbed C++と標準ライブラリまたはHALライブラリに基づく元の設計との違いによるものです.
標準ライブラリまたはHALライブラリベースのテンプレートは、一般的に次のとおりです.

必要なハードウェアリソース(シリアルポート、GPIO)をmainのグローバル変数として宣言する

USBをexternグローバル変数

と宣言

は、主関数においてクロックを構成し、これらのハードウェアリソース

を初期化する.

展開応用ロジック

STM 32 CubeMXのUSBインスタンスがusb_であることが判明device.cのグローバル変数.これはGPIO/ADC/PWM/CAN/UARTのような一般的なハードウェアリソースとは異なる.

// Private in main.c
CAN_HandleTypeDef hcan;
RTC_HandleTypeDef hrtc;
UART_HandleTypeDef huart1;

int main(void){
  HAL_Init();
  SystemClock_Config();  // RCC init before any other resources
  MX_GPIO_Init();
  MX_CAN_Init();
  MX_USART1_UART_Init();
  MX_RTC_Init();
  MX_USB_DEVICE_Init();  // USB init here
  while(1){
    ...
  }
}

main.c

USBD_HandleTypeDef hUsbDeviceFS;

void MX_USB_DEVICE_Init(void)
{
  USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);
  USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC);
  USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS);
  USBD_Start(&hUsbDeviceFS);
}

usb_device.c

extern USBD_HandleTypeDef hUsbDeviceFS;

usb_device.h
Mbed C++に基づいているのは特殊です.

DigitalOut myled(DBG_LED);  // See main.h for hardware issue
cmdline cmdhandler;
// You can put USBSerial/USBTerminal here, but will not be enumerated in F103
//USBSerial usbSerial(0x1f00, 0x2012, 0x0001,  false); 
USBTerminal *term;

int main(){
  confSysClock();  // RCC init first
  Serial    uart(PA_9, PA_10, 115200);
  //USBSerial usbSerial(0x1f00, 0x2012, 0x0001,  false); 
  USBTerminal usbSerial(0x1f00, 0x2012, 0x0001,  false);
  term = &usbSerial;  
}

main.cpp
USBはクロックに非常に敏感なので、システムクロックの構成が正しい後にUSBオブジェクトを生成する必要があります.
Mbed C++ではmain関数を呼び出す前にクロック構成とオブジェクトインスタンス化を行う.RCCクロック構成はMbed Libraryに隠れており,オブジェクトがMain関数の外にある場合は公有オブジェクトとみなされ,main関数の前にもインスタンス化される.
USBオブジェクトを共有オブジェクトとすると、F 407は正常に動作し、F 103は正常に動作せず、列挙に失敗する.換言すれば、F 407コードでは、main関数の外でUSBSerial/USBTerminalを宣言し、正常に動作することができる.しかしF 103コードでは同じコードでコンパイルはパスしたが列挙に失敗した.
サードパーティの開発者はパッチを適用し、main関数にconfSysClock()を追加しました.興味があれば、RCCレジスタの数値を見ることができます.
クロックはmain関数で呼び出されるため、間接的にUSBオブジェクト(USBSerialおよびそのサブクラスUSBTerminal)はmain関数のオブジェクトであり、他のモジュールおよび関数はアクセスできません.
解決策はmainです.cppにUSBオブジェクトポインタを1つ残し、他の関数や他のモジュールがUSBオブジェクトにアクセスできるようにします.その代償として、USBオブジェクトにアクセスするには、すべての方法で"->"を使用する必要があります.これにより、SerialオブジェクトとUSBオブジェクトに基づくコードが2つ存在することになり、OOPの原則に反する.
このことから,Serialオブジェクトベース,F 103ベースのUSBSerial,F 407ベースのUSBSerialのチャネルには,意外にも2セット(正確には2.5セット)のコードが現れている.この場合、HCI/SIP/TDL/JSONなど、他のプロトコルにも影響を及ぼす可能性があります.
ARMにとって、USBはIoTの一部ではありません.彼らのIoT/Conectivityには主にCellular Modem/WiFi/BLE/LoRaWAN/BLE/TS/MQTTなどが含まれている.
コードを統合するには、開発者が自分で手を出す必要があります.ポインタタイプに統一するか、Mbedの下位層が修正されることを期待するか.しかし、これらのコードはすべてMbed 2に基づいており、Mbed 5はUSBスタックをメンテナンスしていない.開発者独自のBackportが必要です.コードここで:ARM Mbed OS STM 32 F 103のシステムクロック構成コード