2020年9月22日火曜日

7セグLEDを並べてみた

 最近マイコンの小ネタは別のところに書いてるのでこのブログでは久しぶり? そっちの方も思い出したようにたまに書くだけだけど。



 4桁の7セグLEDを4個並べて8桁x2行の表示。組文字?にも対応しているので多少の表現度もある。写真だと写ってないけど、16進の表示にも対応。

 7セグの下はスカスカ、STBee Miniの下にはトランジスタアレイが入ってる。LEDの制限抵抗は1.2k。もう少し低くても問題なさそう。1mA弱しか流れてないのでドライブ能力的にももう少し余裕はある。LED自体はパルスなら100mAまで流せる。今の100倍の輝度まで行けるわけか。マイコンがドライブできないし、Vf上がるとVdd超えるけど。

 写真だと見づらいけど肉眼だとある程度きれいに見える。明るいと見づらいけど。スモークのアクリルとか重ねればいいんだろうけど、加工を外注するとそこそこの値段になるんだよなぁ。この大きさで2000円くらい? 角Rとか穴とか追加すると500円とかの単位で上がっていく。レーザーなら加工の手間自体はないだろうし、データ作る手間なんだろうけど、物が小さいとデータ作成費みたいな細々したものの割合が大きいので割高感。はぁ、Haas Desktop Millがあればこれくらいのモノは好きに作れるのに…… どー考えても外注したほうが安いっすね。。。


 7セグの表示はタイマ1本とDMA3本で転送しているので、CPUからは触らずに表示できる。CPUをWFIでスリープに入れても問題なく動く。もっとも、LEDの消費電力が大きいのでマイコンの消費電力ケチったところで…という感じではあるんだけど。RTOSの1kHzティックもあるから完全にCPUが休めるわけでもないし。

 DMAで処理しているので、リフレッシュレートはかなり高く設定できる。今のところは1kHzで回してる。つまり1桁を60usecくらい点灯させて、次の文字を60usecくらい点灯させて、で、16桁で1msecで1巡して、そのまま次の表示を始める。リフレッシュレートが高いので動画でのスローモードで撮って見てもフリッカーは出ない。

 LED制御のタイミングの生成はタイマでやっているので、デューティー比もハードウェアで作れる。今の所ほぼリニアに10段階で輝度を設定できるが、最小輝度だと屋内でもほとんど見えない(真っ暗じゃないと見えない)程度に暗くできる。



 裏面はこんな感じ。セグメントは同じパターンで複数が並んでいるのでおおよそ水平垂直に配線できる。桁毎のコモンは1対1でトランジスタアレイに通す必要があるので妥協して斜めに通している。垂直水平はSeg、斜めはDig、というふうにすれば見分けやすい、みたいな言い訳。

 Segは規則的に並んでいるとはいえ、右側と左側を同じように並べると配線が面倒になる。デコードをソフトウェア実装する利点として、このあたりの自由度が高いことが挙げられる。ということで、配線しやすいように配線して、グチャグチャになったピンアサインはソフトウェアで吸収する、という方針。Digも通しやすいように通してるだけなので、マイコンのポート位置と表示桁は無関係。

 セグメントのデコードでLUTを3段くらい使っている。セグメントのLUTが右グループと左グループの2ページ、1文字ごと。xy座標からグループを求めるLUTに、ASCII文字コードからセグメントLUTのインデックスを求めるLUT。LUT3段でASCII文字からセグメントのON/OFFデータが得られるので、それをDMA用のバッファに書き込んでおく。あとはDMAが勝手に転送してくれる。LUTは文字書き込み時にしか参照しない。



 ピンアサインはほとんど使い切ってる。今のところはUSARTでコマンド叩いているけど、CANを予約してある。LSEも予約済み。残りはGPIO1本しかない。GPSのPPSの受信とかに使えば高精度なデジタルクロックも作れる。リフレッシュレートが高いから最小桁10ミリ秒もキッチリ表示できるし、フリッカーも少ないから高FPSの動画のタイミングソースにも使えそう。一昔前のカチンコみたいな。16桁あるので4桁の西暦から0.01秒の単位までフルに表示できる。肉眼で見るなら、0.1秒の桁は見えるけど、0.01秒の桁はチカチカしてるだけで何が表示されてるのか見えない。

 USARTのコネクタが4ピンなので、PPS受けるなら交換しなきゃいけない。ミスった。。。

 STM32F103のRTCは32bitカウンタが入っているだけなので、デジタルクロックとか作ろうと思うと日時の変換は自前でやる必要がある。まぁ、さほど大変な処理ではない。

 STM32F4のRTCとかでも、外部の50Hzとか60Hzを基準にLSEを校正できるんだけど、残念ながら1Hzでは校正できない。たぶん最低40Hz弱が必要。1Hzに同期できればGPSの1PPSを使えるんだけど。

 高精度なタイミング(数百usオーダー)を作ろうとすると、自前でゴリゴリする必要がありそう。どんな感じで処理するのがいいのかなぁ。HSEでタイマ回して1Hz作りつつ1PPSとの位相差を測って補正しつつ、みたいな感じか。ソフトウェアでPLL作る感じ? VCOでなく固定周波数を可変分周するだけだけど。

 STM32のDMAってGPIOをトリガにする機能ってあったっけ? ざっと見た感じそういう機能はなさそうな気がする。STM32F4のRTCだと外部パルスのエッジでレジスタコピーする機能があるけど、F1には無い。どっちにしろRTC使う旨味は無いのでTIMで組むことになるんだろうけど、FreeRTOSにSysTick、HALにTIM1本、LEDにTIM1本使ってるので、タイミングを作れる機能はあと2本しかない。あんまり贅沢な使い方はできない。どうしたものか。

 5msecくらいの精度でいいなら、1PPSをEXTIで受け取って、システムティックとのオフセットを計算しておくだけで良さそう。


 GPIOはADCにも使えるので、外部にアナログ出力の照度センサとかつけておけば、自動で明るさを調整したりできる。あるいは1wireドライバを作って、4箇所の温度を表示したり、センサ1個の現在地と最大値・最大値を表示する、みたいな使い方もできる。


 最近はUSB DFUは使わずにNucleo-64から割ったST-Linkを使ってSWDで書いてる。システムブートローダだとかなりの数のピンがプルアップ/プルダウンされたり、外からパルス入ったら正しく動作しなかったりするけど、SWDならそういう心配が少ない。単純にライタとして使っているだけで、デバッガとしては使っていない。デバッガでトレースしないとデバッグできないような高度なコードは書いてないし。システムブートローダだとリセットスイッチとBOOT0の操作が必要だけど、SWDなら書き込みプログラム読むだけでリセットかけて実行までやってくれるのでスイッチが届きづらいような配置でも気軽に書き込める。最初に本格的に使ったARMボードがSTBeeだったのでライタ不要のUSB DFUに慣れてたけど、ST-Linkも便利。

0 件のコメント:

コメントを投稿