旧世代と同等に実装できるドライバの調査¶

この文書は実装前の調査記録です。調査後、CANはClassic・電源のみ互換、デバッグはUART4、ブザーは正確なHz指定、ADCユーザーSWは旧HWと同じと確定しました。現在の実装状況は基礎ドライバを参照してください。以下の「現行」「未実装」「未確定」は調査時点を示します。

以下の旧パケット表・モード・通信断条件は日付付きの調査根拠として保持します。現在の機器間契約の定義にはspecsを参照し、この履歴を正本として新仕様を追加・変更しません。

対象と判定基準¶

2026-09-13の要求に従い、CAN、デバッグUART、ブザーPWM、ユーザーSWなど、旧世代と同等にできる部分は同等仕様を採用する方針とする。この文書は実装前の調査であり、設定変更・ドライバ実装・実機検証の完了を示すものではない。

参照元はC:\Users\hiroyuki\STM32CubeIDE\workspace_1.17.0\G474_Orion_main。確認時のHEADはd050c6a616055e7936b1f78d9d56d0dc2bc17795で、未コミット差分は.settings/language.settings.xmlのみ。以下の旧世代パスはこのディレクトリを基準とする。READMEや旧文書と異なる場合は現行ソースを根拠にした。

「実装可能」は、旧世代のソースと本プロジェクトの現行設定からソフトウェアを作成できるという意味。新基板での通信成立、音、押下方向、アクチュエーター動作の確認とは区別する。

判定一覧¶

CAN¶

根拠: 旧Core/Src/fdcan.c:42、:81、Core/Src/can_ibis.c:32、:85、:153、:233、Core/Src/main.c:1077。

同等仕様として実装できる転送仕様は次のとおり。

• FDCAN½ともNormal、Classic CAN、自動再送有効、BRSなし。
• クロック170 MHz、分周1、nominal prescaler 10、SJW 1、TSEG1 14、TSEG2 2。計算上1 Mbit/s、サンプル点は約88.2%。
• 標準IDマスクフィルターを1個、ID=0・mask=0でRX FIFO0へ全標準IDを受け入れる。送信は標準IDのデータフレーム、DLC=8。
• RX通知時にFIFO0のメッセージを読み出し、バス・ID・データを上位へ渡す。
• バスごとに20フレームまでソフトウェアFIFOへ退避する。実配列は空／満杯区別用を含む21要素。待ちフレームがあれば新規フレームも後ろへ並べ、追い越させない。
• TX FIFO empty通知で空きがある間転送する。ソフトウェアFIFO満杯時は新規フレームを破棄し、バス別の破棄数を記録する。HAL登録成功・失敗・退避数も記録する。

現行Core/Src/fdcan.cはFD+BRS／FD without BRS、標準フィルター0、IRQ未設定。同じ1 Mbit/sでもprescaler 17・TSEG1 4・TSEG2 5でサンプル点50%のため、同等化する際はbitrateだけでなくタイミング値を変更する。FDCAN2 TXは旧PB13から現行PB6へ移っているため、ピンは現行の生成定義を使う。旧世代はHSE起点、現行はHSI起点のPLLであり、通信精度は新基板で確認する。

旧コードには通常受信時のID種別・DLCの確認、明示的なglobal filter設定、bus-off復帰処理が見当たらない。標準IDの受入れ仕様は再現できるが、「拡張IDやremote frameを確実に拒否する仕様」や「自動bus-off復旧がある」とは扱わない。新実装では受信形式・長さの検証、送信の失敗通知、IRQとの排他を定義する。復旧方針は別途決定する。

Board/board_canは転送・キュー・エラーを担当し、パケット解析から機体状態やモードを変更しない。旧main.cはIRQ内で機器パケット解析まで行うが、新実装では前文書の依存方向に従って受信の引渡しを分離する。

既存機器のパケット¶

根拠: 旧Core/Src/actuator.c、Core/Src/can_ibis.c:262、Core/Src/util.c:146。

floatは旧STM32のメモリー表現を4 byte順にコピーしており、同MCU上の既存形式に合わせて変換処理を実装できる。ただし、4WSの操舵指令・角度原点・回転方向・接続台数はこの表からは確定しない。byte2=200の意味も送信側コードだけでは確定しない。

CAN受信タイムアウトは旧コードで100周期を「超えた」場合に検出する。MAIN_LOOP_CYCLE=500の約200 msという設計意図は読み取れるが、対象ノード一覧と新制御周期が未確定なので、現時点のBoard仕様には含めない。機器別の受信時刻は記録し、異常判定は上位へ置く。

デバッグUART¶

根拠: 旧Core/Src/usart.c:45、:183、Core/Src/main.c:120、:311、:360、:1002、:1347。

• LPUART1、2,000,000 baud、8 bit、parityなし、stop 1、flow controlなし、FIFO無効。
• TXはDMA normal、byte単位、memory increment有効。旧DMA1_Channel7に割当。
• RXはHAL_UART_Receive_IT(..., 1)を完了ごとに再設定。RX用DMAの生成設定も存在するが、実際の通常デバッグ受信はDMA開始ではなく1 byte割り込み。
• 出力用の文字列バッファは2000 byte。通常ログはメインループで作成してDMA送信。別に1 byteをtimeout 1 msで送る__io_putchar()がある。
• RX割り込みが無効になっていれば再設定する処理がある。

現行LPUART1はPC1 TX／PC0 RX、UART4はPC10 TX／PC11 RXで、両方2 Mbps・8N1。旧世代のデバッグがLPUART1であることから、移植先の第一候補はLPUART1だが、旧世代の情報だけで新基板のデバッグコネクターとの対応は確定できない。送受信コードは実装可能で、最終のハンドル対応だけをBoardへ集約できる。

現行はDMA・UART割り込みが未設定。TX DMA、DMA IRQ、UART IRQ、HALハンドル連携を追加する。DMAチャネル番号とNVIC優先度はSPI等との資源配分で決め、旧番号を通信の互換要件にはしない。

旧p()はvsprintf()の前に現在長だけを確認しており、1回の大きな追加を制限できない。また、DMA送信中の同一バッファ書換えを明示的に防ぐ処理がない。同等化の対象は文字列の送受信機能とし、容量制限付き整形、送信完了までのバッファ保持、busy／overflow／UART errorの扱いを新実装で整える。

受信文字の意味付けはApp。ソース上はq/aがkp変更、w/sがkd変更、gが走行ログ、数字がページ指定、0x7Fが先頭ページ、CR/LFが次ページ、それ以外が前ページ。旧READMEの説明とは異なる。ゲインの対象や表示項目は新制御の定義後に割り当てるため、ドライバの完成条件はバイト列送信と受信文字の引渡しまでとする。

ブザーPWM¶

根拠: 旧Core/Src/tim.c:49、Core/Src/actuator.c:148、Core/Src/main.c:442、Core/Src/buzzer_control.c:57。

旧世代はTIM5 CH2・PC12、PWM1・active-high、PSC=170、ARR=500、初期CCR=0。鳴動時CCR=250、停止時CCR=0。周波数指定ではPSCへ170 * 2000 / frqを整数化して書き込む。現行はTIM1 CH1・PA8のBUZZERで、PWM1・active-highだがPSC=16、ARR=65535。タイマーとチャネルを差し替えるだけでは同等の波形にならない。

旧レジスター値での定常波形は再現可能。170 MHzなら、基本音は170000000 / ((170 + 1) * (500 + 1))で約1984.34 Hz、dutyは250 / 501で約49.9%。旧関数に2000 Hzを指定しても厳密な2000 Hzではない。

同等化で実装できる範囲は、鳴動／停止、周波数指定、時間指定、音列の再生。基本波形の互換を厳密に求めるなら旧PSC計算・ARR・CCRを再現できる。Hz指定を正確にする場合はPSC+1・ARR+1を考慮して再計算するため、旧波形に対する意図的な変更として扱う。どちらを採用するかは実装仕様を決める際の残項目。

旧起動音は1046、1174、1318、1396 Hz指定を各50 ms。モールス短音40 ms、長音120 ms、音後の間隔20 msも再現できる。旧コードの時間指定はHAL_Delay()で待つが、新階層では周期処理を止めない音列状態機械へ置き換えられる。

エラー、低電圧、CAN切断、vision喪失による鳴動の選択はApp。旧通知は制御ループ回数で時間を数えるため、そのカウンターをそのまま別周期へ移すと時間が変わる。例えば>20なら21回で反転する。参考として旧TIM7のPSC=170、ARR=2000は170 MHzで約496.83 Hzであり、ソフト定数の500 Hzとは少し異なる。鳴動時間と高速制御周期は別々に定義する。

ユーザーSWとLED¶

アナログ5方向SW¶

根拠: 旧Core/Src/adc.c:186、Core/Src/main.c:462、Core/Src/util.c:244。

旧入力はADC5 IN2・PA9、12 bit、PCLK/4、連続変換、640.5 cycles、4倍oversampling・2 bit右シフト、1サンプルの循環DMA。実行時に開始しているADC DMAはこのSW入力で、ADC1/ADC3の電圧・電流取得は開始していない。

この境界値で判定する関数は旧ソースだけで実装できる。ヒステリシスやデバウンスは旧判定関数にない。現行のU_BTNはADC1 IN3・PA2で、regular変換に未登録。ADC1を他のPHOTO/BATT入力と共用するため、スキャン＋DMAまたはチャネル切替の設計が必要。

旧抵抗値・新抵抗値が同じと確認できるまでは、上表を「旧世代互換の判定設定」とし、新基板の押下方向を保証しない。未取得の値を0で表すと中央押下と誤認するので、取得済み・有効性を値とは別に持たせる。長押し、モード選択、アクチュエーター出力値はAppで扱う。旧校正では左右共通カウンターが1000を超えると繰り返し送信する実装で、汎用の1回限り長押しイベントではない。

DIPとデジタルSW¶

根拠: 旧Core/Src/main.c:1258、旧・現行Core/Inc/main.hとCore/Src/gpio.c。

旧モード値は15 - (DIP_0 + 2*DIP_1 + 8*DIP_2 + 4*DIP_3)。各項はHigh=1、Low=0。DIP_2とDIP_3の重みが名前順とは逆。旧のピン配置PB5/PB6/PA10/PD2は現行PB0/PB1/PB2/PB10と異なる。

この変換式は実装可能だが、新スイッチの目盛と一致するかは配線確認が必要。生レベル取得は既存board_gpio、反転・並べ替えはDevice/user_input、値からモードへの対応はAppに置く。SW_90、SW_2の操作仕様は旧ソースでは定義できない。

LED¶

旧Core/Src/gpio.cのUSER CODEには、青=周期表示、赤=イベント、緑=UART受信表示のHigh/Low操作がある。同じ役割の表示処理は実装可能。現行のRGBとLED_0～3については点灯極性・用途対応を別途定義する。現状の生レベルAPIから旧基板のHigh=点灯を推測して固定しない。

旧世代だけでは完成仕様にならないもの¶

• IMU: 旧ICM20602の通信はSPI1 Mode 0、約5.3125 Mbit/s、CS Low選択。現行SPI1は約10.625 Mbit/sで、旧FSYNC出力に対して現行は入力、旧IMU_INTのPC4は現行で無名の出力。型番と配線を確認するまで旧初期化を呼ばない。旧ソースにはWHO_AM_I期待値のコメントと他機種由来と思われる記述が混在するため、型番確定後に機器仕様と照合する。
• BATT_V: 旧通常処理はCANから電圧を受け取る。新ADC端子の分圧比・換算式・しきい値は決まらない。
• PHOTO_0/1とINTERRUPTER_OUT: 旧ボール検出はCAN 0x240。新しい直接接続の受光・発光回路、変調周波数、検出しきい値は決まらない。
• ESC_PWM: 旧ドリブラーはCAN 0x104の指令。PWM周期・パルス幅・arming手順は旧実装から得られない。
• I2C1、UART4の用途、無名GPIO: 対応機器の仕様が必要。
• CM4 SPI、4WS操舵制御、ブートローダー: 旧世代の通信や配置をそのまま適用できず、今回の基礎ドライバ互換調査とは別に仕様を決める。

実装着手範囲と残項目¶

追加HW資料を待たずに着手できるのは、CAN転送と既存パケットの変換、デバッグUART送受信の共通処理、ブザーPWMと音列処理、SWのADC取得基盤と旧判定ロジック、DIP変換ロジック。パケット変換やSW判定は実機へ接続せずに検証できる。

新基板への最終対応付けで必要な情報は、デバッグUARTの端子、U_BTN抵抗回路と方向、DIPビット順と極性、接続CAN機器とバス・ID、LED点灯極性。ブザーは旧波形の再現と正確なHz指定のどちらを互換仕様とするかを決める。これらは同等化可能なコードの作成自体を止める条件ではない。

実装時には、CANのモード・bit timing・filter・NVIC、UARTのDMA・NVIC、ADC取得チャネル・DMA、ブザーTIM1の設定について.iocと生成コードを同時に整合させる。変更後は対象ビルド、CANキューの満杯・順序・受信長検証、UARTバッファ寿命・容量超過、SW境界値を確認し、実端子での通信・波形・押下確認は別の検証記録に残す。

今回の作業はソース照合と文書化のみ。旧・現行双方のソース、生成設定、ビルド設定は変更せず、ビルド・書き込み・実機試験は行っていない。