STM32C0を使ってみる2 - OpenOCD正式対応記念 -

20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:


気づいたら私ってば今月3件も記事更新してますね…北陸侵攻は資金がすぐ
尽きるので気軽に山行けないのとGWの過密期間ずらしの相乗効果でひまが
出来てしまっておかげでしょうか…？それはさておき

さて、去る5月も末になりついにOpenOCDがSTM32C0のフラッシュ書き込みに
正式に対応と相成りました！
ねむいさんもgerritでアシストした甲斐があったものです。

おきぱにあるOpenOCDバイナリは既に対応済みで、もちろんSTM32C0用の
書き込みスクリプトの公開をしております☆

そんでもってSTM32C031-NUCLEO向けの基本プロジェクトも機能を大拡張
して公開しておりますので今のところ誰もC0使ってないようですが、
これからどんどん使ってほしいとおもいます…！


もはや実家のような景色のOpenOCDで書き込んでいるところです。
まぁ10数年やってる同じことだからもう慣れたもんですね〜
…ぇ？お前Codelite使ったデバッグ手順の公開はいつだって！？
すみませんそれだけはもうちょっとだけ待ってください・・・・！






その代わりといってはナニですが私のプロジェクトの詳細をちょっと
解説しておきましょう。色んなセンサに対応するために#defineの嵐に
なっておりますがその分細かく各機能の確認が可能です。


私の公開しているSTM32のNUCLEOボード系プロジェクトは簡単質素を
掲げており、他の方が再現しやすいようにペリフェラルも下記機能に
限定して使っております(144Pin系のNUCLEO除く)。

・汎用タイマ(を使ったuSecウエイト)
・UART(割り込み・リングバッファつき)
・I2C(センサ・表示デバイスのドライバ付き)
・1-Wire(GPIO制御による)



まずはI2Cデバイスが何もなくてもLEDとUARTが確認できるものです。
STM32C0-NUCLEO基板を買ってきてすぐに試すことができます。

UARTはSTLinkがVCPの役割もしているので別途USBシリアル変換を
用意する必要もありません☆


お次はI2Cの機能ですが、前回も言いましたがI2Cデバイス用の+3.3V
電源はAVCCからとっているため、SB25ジャンパは必ずしておいて
ください！！！買ったときはジャンパされておらずAVCCがつながって
おりません！STM32C0-NUCLEOの罠です！


NUCLEO系の基板はこんな感じに都合よくI2Cの機能を試すのに丁度よい
ピン配置で線が出ているのでやっけつハーネスを使って外部のI2C
テスト基板に接続しています。


さらにそこからSTN-LCD/OLED用の線をこんな感じで引き出します。
私はブレッドボードは意地でも使わないウーマンなのでこういった
変換基板や、ハーネス製作で汎用性を持たせプロトタイピング性を
高めております。
ちなみにI2Cのバスライン全体のプルアップ抵抗値についてですが
"つぶし"が効くように2.7~4.7kohmを保つように気を付けております。

さらにSCLのクロックはむやみやたらに上げず100kHzをベースとして動作
挿せております。最適化はまず確実に動かしてからするものです。


あとオシロスコープの波形確認用にこのようなブリッジ接続用治具を
作っておくと波形解析に極めて便利です。


秋月さんで売っているこちらのリードアダプタと組み合わせると
安定確実に波形測定が可能となります！

それとI2C程度の速度の波形確認なら今では格安で10万円以下で
USBの2chオシロが手に入るので必ず持っておきましょう。
安物でもあるのとないのとでは開発のスピードが全く違います。
遊びでも投資はケチらずしっかりと行いましょう！



話を戻して5月の更新からデフォルトのドットマトリクス表示デバイスを
I2C-STNから秋月さんで購入可能な入手しやすいI2C-OLEDに替えております。
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:
STNの方はねむいさんのお気に入りで今みたいにOLEDが自由に使える環境は
まだなかったので時代を感じますね…この辺長くなるのでまた次回にでも。
でもねむいさんこの2.5元I2C-STN液晶いまだ大好きなんですけどね…(一番手前の)


センサは秋月さんで購入できるAosoungのAHT21Bを使用することにします。
実際はAHT2x系ならAHT25やDHT22、AHT20も後述の設定で動作可能です。


main.cのdefineの定義はこのようにしておいてください。
ドットマトリクス表示デバイスはSSD1309を、defineはAHT2X系のテスト
ルーチンとします。


makefileの定義はSSD1309ですがスクロールなどの特殊コマンドは
使用しておらず、基本コマンドだけで動かしているのでSSD1306でも
SH1107でも問題なく動作すると思います(動作は遅いですが)。
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:


それとソース読んでて気づいているかと思いますがI2Cの各センサ
モジュールとI2CのOLED/STNでSTM32の同じI2Cポートを二重に初期化
しております。

これはドットマトリクス表示ライブラリ(xMSTN)の開発はSPI接続の
ものから行っていた経緯がありI2Cインターフェースのものは後から
追加されたことに由来しております。

はたから見れば二重に初期化してて未意味な無駄コード構成になって
いるように見えますがオシロで波形を確認し、実害はないことを確認
しているので将来の拡張を考えあえてこのようにしております。
決して手抜きではない！




AHT21BをOLEDを変えつつ動かしているところです。
湿度がだいぶ高くなってますがこの記事を書いてる時点で京都も
梅雨入りしたそうです。
以前は対応しておりませんでしたがCRCチェックに対応済みです。
こちらも次回の"いろいろ試す"時に詳細をお伝えします。



DS18B20やAM230x系の1-wire系デバイスももちろん動作します。
プルアップ抵抗は4.7kohmにしておいてください。


BME280をお持ちの方はこちらもしっかり動作します。実はBME280も
シリアルナンバを取得できるのですがこれも次回に詳細をお伝え
しましょう…



そんなわけでまだユーザーがほとんどいないSTM32C0ですが、秋月さんが
STM32G0の後釜でNUCLEOや単体SO8パッケのチップとか販売してくれたら
爆発的に広まると思います！
だから秋月さん頼みますよぅ〜！

20240223追:
秋月にSTM32C0参上！！

いろいろ試す57

GWは北陸出張と雨でどこにも行けなかった…！！！
気力があるうちに貯めたネタを吐いていきます…！

●OpenOCDにちょっと困った変更
ねむいさんのOpenOCDを使った書き込み手順では従来elfファイルを
指定して書き込み/ベリファイを行っておりました。しかし…
一部の方は気づいたかと思いますがOpenOCDでこのアップデート
がマージされて以来一部のelfファイルの書き込みができなくなって
しまいました…

具体的に言うとSTM32H7の作例のようなRAMの割り振りをしていて
BSS領域とデータ領域が別々に存在したり起動後にITCMにコードを
置くような使い方のプログラムが全滅です。


具体的にはこうなります…余計なことしやがって…F〇CK!!!
しかもフリーズ…


対策ですがelfの代わりにhexファイルやアドレスを指定して
binファイルを書き込んでやればいつも通りに書き込みとベリ
ファイが可能です。もちろん書き込み後は普通に動作します。


デバッグに関しては普通にelfファイルを指定しこちらは問題
なくデバッグが可能です。


私のARM開発環境まねされてる方は上記対応をお願いいたします。
ちなみにこのコミット、やっぱり方々から不評が出ているようで
差戻しの提案が出ております･･･早く元に戻して…!

20230514追:
差し戻しパッチ適用しました！！
普通にelfファイルでフラッシュ書き込みできます！！！




●ARM-GCCアップデート
ARM-GCCも2023年版にアップデートしております。
メジャーバージョン12->13を意識したものになっています。

arm-none-eabi-gcc (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205

↓
arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214


アップデート内容はCortex-M85とCortex-M PACBTI extensionやらの
サポートだそうですが私が気付いた最大の違いはC++の例外処理に
関するコードが挿入されていることです。


具体的にはeh_frame,ARM.exidxに相当するコードが挿入され、若干バイナリ
サイズが増加しております。ARM.exidxとか10年以上昔からありますが
コードが追加されています…ていうかこちらが本来の姿だったのでは…

仕事ではmbedOSでC++バリバリ使っているのでないがしろにできないので
注視していこうと思います。


また、おきぱのFatFs移植例でLTDCを使っているSTM32F7,STM32H7について
従来最適化レベルを"-Ofast"で行っておりましたが無駄にサイズが大きく
なり過ぎているのとlibpngデコード時に画面が激しく乱れる副作用が
GCC12に上がったころから出てきてしまいましたのでSTM32F4の作例も含め
スタンダードな"-O2"にして提供することにしました。


●おきぱのプログラム大更新
STM32系のメンテを続けているSTM32系のFatFs移植例の大更新を
行いました。メインは以下の箇所です。
1. C++で禁止されている"__(ﾀﾞﾌﾞﾙｱﾝﾀﾞｰｽｺｱ)"で始まるマクロや定義
　およびコーディング規約に反する一部の変数名の修正
　->このポカミス思いっきり全弾ヒットしていましたorz

　↑こういうやつ
　　 STM32Primer2の件でちょこっと触れたやつですね。
　　特にインクルードガードに関してはほぼ全部ダブルアンダー
　　スコアやらかしていましたので全部修正してやりました…はぁはぁ。

　　識別子についてはこちらの方の解説もわかりやすいです。

ChaN'師のFatFsは数年前すでに対応済みでしたね…ｻｽｶﾞﾀﾞｧ…

2. タッチパネル入力で押しっぱなしで連打機能
　->タッチパネルで該当するキーを押して一定時間後連打するやつです。
　　この機能はもともとはタッチパネルに一回ちょっと触れただけで
　　複数回押されてしまうことになっていたバグの修正からで、ついで
　　だから入れようということで追加しました。


　　ただし↑と↓だけ機能します。それだけでもすごい楽ですね。
　　該当コードは¥lib¥display¥abstract¥src¥touch_if.cの230行目
　　以降を参考にしてください。

　　これも"ねむいさんのプログラムってタッチパネル入力だけ雑"
　　って10年間くらい言われ続けていましたがやっと重い腰が上がり
　　ました。そして安心して座れる…。


また、下記のi2cデバイスの動作を絡めたexampleも超大改版を行い
ましたが、これに関しては内容が多すぎるので次回に委ねます。
先に公表しておきますが改変したプログラムは下記になります。
・STM32F03x
・STM32G03xxx
・STM32C03xxx
・STM32F401,F411



●STM32向I2Cタイミングレジスタの値計算機作った
STM32F0以降のI2Cはレジスタの構造が一新されてしまいクロック生成に
超めんどくさい計算式が必要でそれをタイミングレジスタに入れる
ようになってしまいました。一応計算用のエクセルファイルが配布
されていますがF3までしかサポートしてなくて使いづらいので…
自分で作製しました。

・使い方

まずexeを立ち上げます。デフォルトでI2Cカーネルクロック48MHz,I2C
のクロック周波数は100(KHz)が設定されております。
I2Cのカーネルクロックは上限400MHzまで設定可能、I2Cクロックは100kHz,
400kHz,1000kHzの3種類だけです。それ以外を設定すると計算結果が0に
なるステキ仕様となっております。

ひとまずKeisanボタンを押すとタイミングレジスタに入れる値がポンと
出てきます。


これを自分のプロジェクトのI2Cの設定時にコピーペーストしましょう。

・精度は?

(※STM32C0-NUCLEOの作例です)
ぁららー(脂汗)
う〜んまぁいいんじゃないでしょうか…
すみません適当のやっけつ仕事で…

ちなみにSTMicroが提供しているi2c_timing_utility.cの計算時の定数値
のtriseの値が変な値になっていて実際に波形もへんてこりんなものに
なっていましたのでエクセルファイルの値準拠に変えて計算しています。

STM32F0,STM32F3,STM32G0,STM32C0で確認しましたのでたぶん大丈夫だと
おもいます…


●PicoScopeのソフトが大変更！メジャーバージョンが7に！
読んで字のごとくです…長らくbetaバージョンだったのがついに
メジャーリリースとなったのでねむいさんも乗り換えたのですが…


あのさぁ…特殊なトリガかけようとしたら何度やってもすぐプログラム
落ちるんですけぉ！１１１１！！１１！！１！
今まで6を使ってそれのUIに慣れてしまったのですっっっっっっっごい
使いづらいうえにbuggyとかやめてください…

で、やっぱり苦情が多かったのか前バージョンの6のソフトもダウン
ロードできるようになっております…もっと7が安定化するまで当分6
で運用ですね…。

いろいろ試す56

ぁーGWですね〜…
出張疲れでなんもやることないので今まで貯めてきたUSBシリアル
変換で嵌ったチョイネタを公開します。


●USB-シリアル変換のRTSとかの制御タイミングは結構適当？
　いいえ、ねむいさんの脳みそが適当(仕様)
ねむいさん副業(本業は二次裏メイド)でHalf-DuplexなRS485の
ちょっとした基板を製作しておりました。

MAX485データシートから抜粋と追加。
_REとDEを一つにまとめ、HIで送信、LOで受信に切り替えます。
そのような仕組みなので何らかの方法で入力と出力を切り換えないと
いけないのでRS232-Cの規格に存在するRTS信号出力を手動で切り
変えて送受信を制御してやろうと思ったのですが…

…うまく動かない…
なんか送信がぶつかってるような…
最初FTDIのやつ使ってたのですが通信できたりできなかったり
そんでProlificのやつ使ったら全く通信できにゃい！！！
ぬがああああああ！１１１！！！１！！

というところでようやくオシロスコープを引っ張り出して波形を
確認することにしました。ねむいさんいつも他人にはオシロで
ちゃんと波形確認しろと言っておきながら自分もめんどくさくて
やってない。

まぁそれは置いといて実際測定してみるとなんでか分かった。
まず検証に使ったソースコードですがVC++で適当にプロジェクト
作ってCreatefileでCOMポート開いてその際にDCB構造体のfRtsControl
に"RTS_CONTROL_TOGGLE"を設定しておきます。
これでWrite関数を実行、具体的には送信したい文字列を…
今回はDAAAAAAAAA¥r¥nというゼEROみたいな文字列を1秒ごとに
吐き続けるやつで検証してみました。




イケてるとき。
信号レベルはTTLレベルなので反転前なので注意してください。
ここで見るべきは文字列送信終了後にRTSが変化していることです。
でも1.5mSecもかかって信号レベルが遷移している・・？


イケてないとき。
なんと試行して数回目で発生した！！
送信し終わってないのにRTSが戻ってる！！！！
こりゃだめだ…。

RTSの信号をEscapeCommFunction関数で手動で変えてみたりしましたが
文字列送信中にRTSが受信方向に変化しやがったり逆に何mSecも戻
らなかったりもうぜんっぜんだめ…

もう疲れたのでFTDIの奴は置いといて今度はProlificのチップ
使ったUGREEN製のUSBシリアル変換ケーブルで試してみました。

注:信号レベルはRS232なので注意。それと時間レンジに注目！
おいいいいいいいいいいいいいいいいい！！１！！１！！！！
Open関数を実行したとたんRTSが立ちっぱなしになってもとに
戻らなくなってしまいました(COMポート閉じるまでこのまま)
お前なんなんだYO!

これはいけない。

ということでネットの海にダイブしていろいろ調査していると
ねむいさんと全く同じ状況に陥っている方がいました。
西村備山様の"滴了庵日録"の下記ブログ記事にはねむいさんと同じように
文字列を送り終わる前にRTSが変化しているのがわかります。
・FTDIのUSBシリアルの不具合？

また、さらに調査されていてHalf-DuplexでRS485をやりたい人は
TXDEN信号を使えばいいとのことです。
・PCのCOMポートをRS485に接続する

なぜRTSが適切なタイミングで変化してくれないのか、USBの規格や
仕様を考えたらすぐ分かる話なのですが物理COMポートはuSec単位で
反応できる一方、USBでは最速でも1mSec(USBフルスピードで)の
"フレーム単位"ごとにしか状態を変えられないことにあります。

20240829追:
HuMANDATA様がFTDIのRTSの制御線の遅延を検証されております！
必見です！！！！
20240829追:


また、西村様の上記記事の最後にFTDIのドライバでRTSがうまく
変化してくれないと言及されておりますが我らがProlificに
至ってはおそらくOpenFile(COMポート開いた)のタイミングで
RTSがいきなりビンッビンにおっ立ってしまい、もう治まり
そうにありません！！1！！もう許ちて！！！！


…すみません下ネタに近いこと言ってしまいましたが西村様のブログ記事に
倣い、FTDI系では方向制御にTXDENを使用することにしました。

うーむ完璧！USBシリアル変換でRS485でHalf-Duplexな通信
したい人はFTDIならTXDENを使えば良いですね。なんだかんだ
言ってFTDIが一番安定して使いやすいですし。


ちなみに秋月で販売しているCH340Eシリアル変換もTXDENに相当する
制御用ポートがあります。

秋月電子のデータシートより抜粋。
CH340EにはTNOWという端子がありこれがTXDENに相当します。
こいつを引っ張り出してあげましょう。モジュール上にはちょうどR4が
TNOWに付いてて半田もしやすいですね。


うーむこれも完璧☆

今を時めくUSBType-Cコネクタで何より安いのでこれは使い勝手良いかも！？


え、肝心のProlificはどこ行ったって？
ありゃだめですよぅ…(もはや測定する気力がない)。

20231103追：
HumanData様のサイトにRTCをトグルした際の遅延を測定した
データがあります。非常に参考になりました。
やはり2~3mSecの遅延があるようですね…
https://www.hdl.co.jp/USB/jkn016/
https://www.hdl.co.jp/USB-001/usb001-t4.html



●CP2102のぱちもん
前々回DS18B20のぱちもんを紹介しましたが中華製ぱちもん半導体の
勢いはとどまることを知らない。過去にFTDIの偽物が出回ってそれ
つぶすドライバが配布されて大混乱になりましたが、駆け込み寺で
使用されたSiliconLabs製のCP2102にもぱちもんが蔓延していた
ようです。

2017年にアメリカのMAKER系イベントで配布された名札代わりの
ボードの中に使用されていたUSBシリアル変換IC(CP2102)に偽物が
混ざっており動作せず人海戦術で対応に当たったという事象が
ありました。

なおこのぱちもんCP2102はUSB-TTL(3.3V出力付き)Breakoutボード
としてAmazonやebay,Aliexpressでも蔓延しており、見分け方が
提示されておりました。

さらに調べるとロットNo.と思われる部分に"DCL00X"と刻印されてる
奴はぱちもんのようですね。
さらにその基板はReset端子がVbus(+5V)直結になっているため、
Reset端子から電流が流れ込み+3.3Vラインが+4Vとかになってると
思われます。一応全端子5Vトレラントのようですがデータシートの
説明にはVDD(内部3.3Vレギュレータ)に4.7kohmでプルアップせよ
と明記されてますね。
抵抗じゃなくてヒューズがついてるのはOKとかそうではなくこの
パチモンCP2102使ったぱちもんモジュールを使うのを避けたほうが
いいですね…


ところで私の持ってるCP2102は大丈夫なのか！？調べてみました。

DOIT-AM製のESP32-DevKit-Cです。
DCL00Xじゃなくてとりあえず安心…

ESPRESSIF製のESP32-DevKit-C-VE
CP2102Nでした。多分大丈夫でしょう。
ESP32-DevKit-C-VE

ESP32-S3-DevkitC-1
こちらもCP2102Nでした。

今現在CP2102が実装された基板はESP32系だけでした。DOIT-AM製の
2016年末くらいの奴は怪しいかなと思ってたのですが回路図見たら
ちゃんとデータシートの言いつけを守っておりました…ｻｽｶﾞﾀﾞｧ…

因みにDOIT-AM製初期のDEVKIT-Cと秋月で購入したESP32-WROVER-E
を使用したESP32-DevKit-C-VEにはADP3338に交換済みです…！！
一方最新のESP32-S3-DevkitC-1に使用されているLDO、SGM2212は
ADP3338には及びませんがVdrop最悪値が0.6Vなのでまぁ使える
レベルにあると思います。



●UGREEN製のUSBシリアル変換を改造してみた
最初のRTSの件で使用したUGREEN製のですがRS485変換には使い物に
ならなかったのでとりあえず分解してみました


結構な化粧箱に入っておりました。921600bps対応とか抜かして
ますがもちろんそんなボーレートで通信できませんでした。


とりあえず殻むきして中身を出してみます。
よくあるDsub9Pinのコネクタを利用した基板直付けタイプですが…
なんかずれてて隣のパタンとショートしそうになってました！！


Dsub9pinコネクタを外してみました。金メッキとか抜かしてました
が外から見える部分だけ金メッキでした…びんぼっちゃまくんかな？


Prorific製ICはPL2303TAが使用されていますがこのチップ、すでに
ぱちもん対策で廃版になっておりPL2303Gが最新です。
ねむいさんPL2303Gが使用されてると抜かしてたので買ったのですが
まぁチャイナリスクってやつです(12年ぶり2回目)


信号レベル変換ICはZT213LEEAなるものが使用されています。
MAX212系のRS232Cレベル信号変換のICの中華版でしょうか。


データシートを見るとMAX250kbps...
ねむいさん921600bps対応って抜かしてたので買っ(ry


とりあえず先ずは使い勝手を良くしちゃいましょう。
これからシリアル番号をつけて同じPCのどこのUSBポートに
挿してもCOMポートが固定されるように改造します。


PL2303TAのデータシートは外付けEEPROMは24C02を要求してますので
これをつけてやります。


ついでに空いていたD1に青色LEDつけちゃいます。


さらにどっかから拾ってきたEEPROMWriterでシリアル番号の書き換えに
成功です！やったぜ。


基板を覆っていたモールドは取り出し時に破壊しちゃいましたので
コネクタを追加して元のケーブルも活用することにしました。
ていうかケーブルだけは作りが無駄にしっかりしてますね…


まぁ仕事で使うのって9600bpsが関の山だから921600bps出なくても
良いっていえば良いんですけどね…ぶつぶつぶつ・・・・



そんなわけでUSBシリアル変換のことばかりだらだら紹介してしまい
ましたがUSBシリアルについてはこれだけは言わせてもらいたいです！

１．FTDI製はやっぱり鉄板
　　->何だかんだで一番安定してます。
　　　迷ったら真っ先にこれを使いましょう!もちろん本物をですよ！
　　
２．中華製ぱちもんには気をつけろ！
　　->AmazonやAliexpress,ebayでは偽物に気を付けてください。
　　　安物買いの銭失いとならないようにしましょう。

３．あえて中華製使いたいのならお覚悟を
　　->Prolificとかはぱちもん対策でばんばんモデルチェンジ
　　　してますが正規品でもちょっと道から外れた使い方したら
　　　思ったように動かないとかざらだったりCH340系もかなり
　　　癖があるので心してかかるように、また他の方の使用記を
　　　しっかり読み込んだ上で挑みましょう！

Go to top of page