2024/04/30(火)CH376でUSBメモリの読み書きをする。

江蘇沁恒股分有限公司 wch.cn のシリアル通信対応のUSBマスストレージ管理ICを使うためにいろいろと実験した記録。
チップ単体では秋月電子でも取り扱いがあって入手性も問題ない。
USBメモリ&SDカード ファイル管理制御IC CH376S
実験用にモジュールキットはAliexpressで入手した。

概要

  • ボーレートは9600で動かせる。9600bps, 8N1
  • SD制御を行わない場合、5V電源の5VIO単一の回路構成にできる。
  • そのためモジュールキットのLDOを除去してバイパス、V3pinはデータシート通りで10nF接続した。
  • USBシリアル側も5VIOで実験できる。秋月のType-C USBシリアルがソレ。
  • D4,5,6ピンをVccに接続することで、電源投入時に9600buadとなるはず。
CH376_TEST_pic.jpg

UART制御時の仕様

UART通信仕様として、
通信キャリブレーションとして常に先頭に 0x57, 0xAB を付加してからコマンドを送信する。
送受信の表記はすべて16進数。
例1
 送信:57 AB 06 01
 57 AB=コマンド接頭語(固定)
 06=CHECK_EXIST
 01=テストバイト引数
 受信:FE(テストバイトの反転バイト)

 送信57 AB 06 55 → 受信AA
 送信57 AB 06 AA → 受信55

例2
 送信:57 AB 01
 57 AB=コマンド接頭語(固定)
 01=GET_IC_VER
 受信=41など、バージョン番号が返る

初期化手順

  • CHECK_EXIST 06 通信確認
    • 送信 57 AB 06 55
    • 受信 AA
  • RESET_ALL 05 リセット
    • 送信 57 AB 05
    • 受信 (なし)
  • CHECK_EXIST 06 通信確認
    • 送信 57 AB 06 AA
    • 受信 55
  • GET_IC_VER 01 チップバージョン
    • 送信 57 AB 01
    • 受信 41(など)
  • SET_USB_MODE 15 USBモードを設定(USBメモリ接続の場合は06)
    • 送信 57 AB 15 06
    • 受信 51(CMD_RET_SUCCESS)
この時USBデバイスが挿さっていると追加で15(USB_INT_CONNECT)を受信
以降、現在の状態でUSBデバイスが挿されると15,抜かれると16(USB_INT_DISCONNECT)が返る
  • DISK_CONNECT 30 DISK接続
    • 送信 57 AB 30
    • 受信 14(USB_INT_SUCCESS)が返れば、ディスク接続完了。
  • DISK_MOUNT 31 DISKマウント
    • 送信 57 AB 31
    • 受信 14(USB_INT_SUCCESS)が返れば、ディスクをマウント完了。
これでディスクアクセスの準備完了

接続されたディスクの容量を確認

  • DISK_CAPACITY 3E DISK容量取得
    • 送信 57 AB 3E
    • 受信 14(USB_INT_SUCCESS)が返れば、でディスク容量を取得完了。内部バッファにデータが格納される。
  • RD_USB_DATA0 27 バッファ読み出し
    • 送信 57 AB 27
    • 受信 04 FF FF EF 00(など) バッファ内容が返る。
      • 04(バッファデータバイト長)、00EFFFFF(ディスクセクタ数)
      • →1セクタ512byte(標準)なので0x00EFFFFF * 512 = 8,053,063,168 bytesとなり8GBのUSBメモリであることがわかる。

読み込みテスト

ルートディレクトに「1234.TXT」があり、内容は「1234567890ABCDEF」であるとする。
  • SET_FILE_NAME 2F 操作ファイル名を設定
    • 送信 57 AB 2F 2F 31 32 33 34 2E 54 58 54 00
      • 2F 31 32 33 34 2E 54 58 54 00 がファイル名(ファイルパス)"/1234.TXT\0"
    • 受信 (なし)
  • FILE_OPEN 32 ファイルオープン
    • 送信 57 AB 32
    • 受信 14(USB_INT_SUCCESS)が返れば成功
  • BYTE_READ 3A ファイルから内部バッファへ読み込み
    • 送信 57 AB 3A 08 00
      • 08 00 (読み出しバイト数、0008(8byte))
    • 受信 1D(USB_INT_DISK_READ)が返れば成功
  • RD_USB_DATA0 27 バッファ内容を取得
    • 送信 57 AB 27
    • 受信 08 31 32 33 34 35 36 37 38(など)が返る。
      • 08(バッファデータ長)、31 32 33 34 35 36 37 38(バッファ内容="12345678")
BYTE_READ, RD_USB_DATA0を繰り返しファイル末端へ到達した場合
  • RD_USB_DATA0 27 バッファ内容を取得
    • 送信 57 AB 27
    • 受信 00
      • 00(バッファデータ長)が返れば、それはファイル末尾まで読み出し完了し、読み込めたバイト数が0(なし)であることを示す。
  • FILE_CLOSE 36 ファイルクローズ
    • 送信 57 AB 36 00
      • 00(ファイルサイズの自動更新をしない)
    • 受信 14(USB_INT_SUCCESS)が返れば成功

書込みテスト

  • SET_FILE_NAME 2F 操作ファイル名を設定
    • 送信 57 AB 2F 2F 57 52 49 54 45 2E 54 58 54 00
      • 2F 57 52 49 54 45 2E 54 58 54 00 がファイル名(ファイルパス)"/WRITE.TXT\0"
  • FILE_CREATE 34 ファイル作成/オープン
    • 送信 57 AB 34
    • 受信 14(USB_INT_SUCCESS)が返れば成功。
      • すでに存在するファイル名の場合、その内容は削除される
  • BYTE_WRITE 3C 書き込みバッファ領域確保
    • 送信 57 AB 3C 05 00
      • 05 00(データバイト長0005(5byte))
    • 受信 1E(USB_INT_DISK_WRITE)が返れば成功
  • WR_REQ_DATA 2D 書き込みデータ送信
    • 送信 57 AB 2D 31 32 33 34 00
      • 31 32 33 34 00 が"1234\0"
    • 受信 05(など)が返る。
      • 05(書き込みできたバイト数05(5byte))
  • BYTE_WR_GO 3D 書き込みを完了させる(?)(Flush?)
    • 送信 57 AB 3D
      • 次の書き込み要求待ちにする(?) これについては詳細不明だが、このコマンドがないと実際にデータが書き込みされない。
  • FILE_CLOSE 36 ファイルクローズ
    • 送信 57 AB 36 01
      • 01(ファイルサイズの自動更新をする)
    • 受信 14(USB_INT_SUCCESS)が返れば成功

2024/01/17(水)mpg123とmpg321@ラズパイCUI

自分は、ラズパイなどLinuxでもGUIがないとほとんど何もできない&WindowsのようにGUIできるの最高だぜな人。
しかし、最近ラズパイをCUIだけで使い始めててちょっと楽しくなってきた。
それで、ラズパイならつけっぱなしでも気楽だし部屋のBGMに垂れ流し音楽プレイヤーにもしようと思ってCUIプレイヤー探していたときに「なんやねん」って思ったのがmpg123mpg321は別のアプリってこと。いやほんとなんやねんこれ。

最初mpg321をインストールして使ってたけどなんかプチプチ途切れたような再生で音質が悪い。それから結局mplayerという別のアプリを試したらノイズが消えて解決しました。この時点でmpg123の方の存在は知らなくてノイズの原因調べてたらmpg321はmpg123の亜種みたいなソフトでノイズが乗る現象をほかの人も書いてたことを知って、何が言いたいかというと「ねんやねんそれ」っていう文句w

まとめるとLinuxのCUIで有名な(?)プレイヤーを知った3つが以下
  • mpg123
  • mpg321(mpg123の亜種)
  • mplayer(FFmpegがエンジンなのでなんでもござれプレイヤー)
いずれも、
sudo apt-get install ほげほげ
するだけの簡単インストール。

熟成された格ゲー・音ゲーみたいに、初心者に厳しいLinuxと思う…のでそれを少しでも緩和するべく記録に残すことにした。

あ、あとubuntuでuseraddadduserで挙動が違うのは許し難いぞ…。

2024/01/12(金)Arduinoボード 3品種のLDO駆動能力

よく使うArduino3品種の3.3V出力の最大消費電流が分からなかったので調べたメモ。
搭載LDOの最大電流は下記の通り、自作の回路やシールド基板では1割程度余裕を見ておいたほうが良いと思う。
ボード搭載LDO最大電流
Arduino UNO R3LP2985-33DBVR150mA
Arduino Uno R4 Minimaマイコン内蔵LDO100mA
Arduino Nano EveryAP2112K-3.3600mA
Nano Every 結構強力、W5500 Ethernetチップなんかも余裕で動きそう。
がっつり3.3Vが必要な場合はVINから自前でDCDCで作るのが順当。

2023/08/21(月)Arduino Nano Everyの挙動

自分用のメモ。
Arduino Nano Everyになってから、UNO R3と違ってタイマ/カウンタが盛りだくさんになった。
その挙動を調べていて使ってるところ使ってないところなどの確認。

とりあえず起動時のTCA0周りを一覧
TCA0.SINGLE.INTCTRL = 0b0
TCA0.SINGLE.CTRLA = 0b1011
TCA0.SINGLE.CTRLB = 0b11
TCA0.SINGLE.CTRLC = 0b0
TCA0.SINGLE.CTRLD = 0b0
TCA0.SINGLE.CTRLECLR = 0b0
TCA0.SINGLE.CTRLESET = 0b0
TCA0.SINGLE.CTRLFCLR = 0b0
TCA0.SINGLE.CTRLFSET = 0b0
TCA0.SINGLE.EVCTRL = 0b0
TCA0.SINGLE.INTCTRL = 0b0
TCA0.SINGLE.PER = 255
TCA0.SINGLE.CMP0 = 128
TCA0.SINGLE.CMP1 = 128
TCA0.SINGLE.CMP2 = 128
TCA0.SINGLE.CTRLCなのですが、起動時は0b0だがtone()実行中は0b111になっています。
比較一致(Compare) CMP2OV CMP1OV CMP0OV 出力ですね。なぜ全部?

あと、この記事がすごく役立ちました。
@CoTechWorks さん
Arduino Nano Everyのタイマー割り込み機能について

この記事を参考に進めています。

2022/08/20(土)Nordic SoftDevice S132 v17.1.0にSerializeFWでアクセス

NordicのnRF52832を積んだマイコンは各社から出てますが、大体がそのチップ自体のプログラミングをして動かしてると思う。
NordicはSerialization FWというのを提供しており、これはSoftDeviceと一緒に書き込むことでそのチップはBLEモジュールとして扱い(Connectivity Chipと言う)ホストMCU側(Application Chipと言う)からUARTを通してすべて操作できるというものです。

となると、UART通信仕様が必要になりますし通信フォーマットが知りたいのですが、なんとこの情報がまともに掲載されていません。v11.0.0のバージョンに無くはないのですが
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fble_serialization_s130_functions.ble_serialization_s130_functions
命令バイトとなるopcodeがv17系と違っていてバージョン違いで平気で仕様を変えてきます。(なんなんですかこれ…。)
調べているなかで本家のコミュニティのDevZoneに同じ悩みの人がいたのですが、誰も知らないみたいなまともな回答がなくもうなんだか…。(なんなんですかこれ…。2回目)

SDKの中を覗いてみると
nRF5_SDK_17.1.0_ddde560\components\serialization
というのがあって、どうやらMCU側はこのライブラリを使って「よろしく動かしましょう。通信プロトコルやパケットフォーマットは気にしなくてよいです。」ということが言いたそうな空気を感じました。

でも自分は、生の通信を見ながらある程度の動きを把握したいので、解析を頑張りました。
  • TX_RAW_PACKET = [TX_HEADER][TX_PAYLOAD] の構成
[TX_HEADER]は2byteで、パケットの長さを示す[0x03, 0x00]の場合 0x0003で3byte続く
[TX_PAYLOAD]の1byte目は、0x00がMCU→BLEで0x01がMCU←BLEの方向、UARTの場合TX,RXで分かれているので各デバイスからは固定で送出されますね
2byte目はcommand code(opcode)、これがバージョンによって変わる。変わるなよ。例えばv17でsd_ble_version_get = 0x65ですが、v11ではsd_ble_version_get = 0x66です。
3byte目以降はopecodeによります。
*** sd_ble_version_get
--> 03 00 00 65 00 
<-- 06 00 01 65 10 00 00 00 

上記を送るとこんな感じで帰ってきます。10 00 00 00が返信内容でBLEからは4byteが標準的に返ってきます。あとは命令によって様々。
まずは基本はこんな通信みたいです。

肝心のv17.1.0のopcodeですが
\nRF5_SDK_17.1.0_ddde560\components\serialization\common\ser_dbg_sd_str.c
の中にありました。どうやらこれが一覧っぽいです。
S132 v17.1.0

static const char * sd_functions[] = {
    /* 0x60 offset */
    "SD_BLE_ENABLE",                           /*0x60*/
    "SD_BLE_EVT_GET",                          /*0x61*/
    "SD_BLE_UUID_VS_ADD",                      /*0x62*/
    "SD_BLE_UUID_DECODE",                      /*0x63*/
    "SD_BLE_UUID_ENCODE",                      /*0x64*/
    "SD_BLE_VERSION_GET",                      /*0x65*/
    "SD_BLE_USER_MEM_REPLY",                   /*0x66*/
    "SD_BLE_OPT_SET",                          /*0x67*/
    "SD_BLE_OPT_GET",                          /*0x68*/
    "SD_BLE_CFG_SET",                          /*0x69*/
    "SD_BLE_UUID_VS_REMOVE",                   /*0x6A*/
    "SD_UNKNOWN",                              /*0x6B*/
...
抜粋。

全然まとまらない。もう自分用備忘録ということで。

あと、UARTは、速度1Mですが、みんな115200に変更して書き込んでいる模様。
それと、パリティありって、Odd/Evenどっちなのか不明確でしたが、Evenのようです。RTS/CTSも標準で必要。
Arduino風に書くならSERIAL_8E1 | SERIAL_RTSCTSです。

【訂正・追記】2022/8/21