2017年6月20日火曜日

4k液晶を買った

 DELLの4k液晶を買ってみました。


 色んな所でレビューされてるので、詳細は割愛。

 とりあえず、スケーリング無しで表示すると、文字がかなり小さいです。そりゃFHD液晶の半分、あるいは4分の1ですから。
 もちろんスケーリングすれば文字は大きくなりますが、画像のスケーリングが綺麗にできないので、どっちもどっちですね。
 この液晶はピボットがついていて、縦置きにするのも比較的簡単(VESAマウント組み換えよりは)ですが、そもそもFHD液晶4枚置きと同じ空間があるので、縦置きにする必要がない感じです。画面3分の2くらいでVS Codeを表示して、2分割でソースとヘッダを表示、残りの領域にPDFを表示して1ページ丸ごと表示したり、Webブラウザでオンラインドキュメントを表示したり、といったことが無理なくできます。このような表示は、以前だとFHD画面にエディタ、サブ画面にドキュメント、と言った感じで表示していました。


 Webブラウジングも、画面半分でFHDの幅とFHDの倍の高さが有るので、1ページでかなりの情報量を表示できます。Googleの検索結果も、スクロールせずに全件を表示できます。
 だいたいのWebサイトは横幅1920pxは必要ないので、4k液晶なら3ページくらいを並べて表示することもできます。ただし、Windowsは左右2分割、上下左右4分割、くらいしかできないので、4kスケーリング無しに最適化されてるとはいえません。

 ピクセル密度は僕が持ってる初代Kindle PWと同程度です。つまり、PC上の電子書籍リーダーでも、Kindle PWと同程度の解像度で読むことができます。ノングレアということもあり、かなり紙に近い質感です。ただし、現行のKindle PCアプリでは、スケーリングすると正常に表示できない感じがします(僕が100%スケールで表示してる理由もこれが50%くらい)。追記1

 物理的な大きさは23.8インチなので、横においてある23インチFHDの液晶と、見た目は同サイズです。しかし、4kは1辺のピクセル数が倍あるので、マウス移動は違和感があります。
 マウス移動速度も、マウス移動量に対して何ピクセル動く、という速度なので、4kとFHDが同じ大きさなら、4kはFHDの半分の距離しか動きません。
 過渡期では4kとFHDが混在するので、マウス速度だったり、画面間の位置は、実空間ベースで実装して欲しいところです。とはいえ、そもそもマルチスクリーンで使う人はそんなに多くないだろうし、明らかにPPIが違う画面を併用する人はさらに少ないから、この機能は期待薄かなぁ。

 液晶自体の欠点はそんなに多くないと思いますが、ピボットで回転させるのがちょっと面倒、入力インターフェースが少なめ、HDMIが4k非対応、といったところでしょうか。


 買ってしまったので、今更使いづらいとも言えませんが、そういうのを差し引いても、便利になったと思います。
 FHD映像コンテンツを表示しても、画面の4分の3がスッカスカなのはかなり圧巻です。


*** おまけ ***

 

 分解能が高いので、Armaとかで敵を見つけやすくなるかな、と思ったけど、GTX950で4kだとポリゴン最低にしても30fpsくらいしか出ないので、全然ダメでした。どっちにしろプレイヤーキルが足りませんが。GTX1080とか欲しくなりますね。沼。


追記1:2017/06/20
 最近のアプリは起動時にスケーリングとかを読み込んで適切に表示できるようです。Kindleアプリも再起動したら綺麗に表示できました。ただスケーリングの異なる液晶間で移動移動させても、スケーリングは変化しないので、微妙なところ。
 あとスケーリングした上でフォントを小さくすると、VS Codeの表示がクッソ見づらい。スケーリングして通常フォントだと情報量は増えないし。


追記:2017-06-21

 4k縦置きにすると、だいたい270行くらい表示できる。文字サイズを小さくすれば、350行くらいは表示できる。どちらにしても文字はかなり小さいが、解像度はかなり高いので、全体をざっくりと見渡して、気になるところを注視して文字を読み取る、みたいな使い方はできる。適切にインデントされたソースコードなら、おおよその文字列の形でもブロックの大きさとかは見えるから、意外と便利。

 ただ、液晶の縦横を変えるのはOSから制御する必要があるので、ちょっと面倒。解像度を変えるとウインドウのスナップも動いてしまう。
 あとこの液晶で地味に不便なのは、PCをDisplayPortで接続し、AV機器をHDMI接続している場合に、液晶ソースをHDMIにすると、OS側で瞬断?みたいな挙動をする点。やはりこれもウインドウのスナップが外れるので、ちょっとつらい。
 amazonのレビューとか読んでると、ファームウェアアップデートとかできるみたいなので、付属CDのソフトを入れればそこら辺改善できるのかも。
 液晶の標準化が進んで、ドライバとか一切気にせずに、本当にPnPができると、付属ソフトウェアとか入れなくてもある程度は動いてしまうので、便利機能とか結構逃してそう。
 業務用とかで、縦置きなら縦置き!横置きなら横置き!で動かさないで、かつ入力ソースも動かさないみたいな使い方ならかなり便利そう。ただ24インチ縦置きだと首が痛くなるけどね。

2017年6月18日日曜日

気分転換に、


 気分転換に、STBee Miniである種のトリガモジュールを作っています。
 ほとんどのソースは以前に作ったFreeRTOSポーティング済みのStdPeriphLibなF1向けプロジェクトをコピーしているので、最低限の動作はすでに作り込んであります。それでも、タイマ回りの初期化とかかなり面倒だなぁと思ってしまいました。なんだかんだいっても、やっぱりHALは便利です。前にStdPeriphLibを使ったのって2ヶ月位前なんだけどなぁ。

 とりあえず、カメラのレリーズとして使いたいのですが、モノとしてはフォトカプラで簡単に絶縁したパルス発生器みたいな感じなので、カメラ以外にもいろいろ使えると思います。タイミングソースは12MHzの水晶、時間はタイマ2本を直列にし、最大1/72M*2^64秒(8000年)周期くらいでパルスを作れます。完全に過剰スペックですが、精度を求めると1/72M*2^32秒(59秒)しかありません。このあたりはある程度自由に設定できるので、用途に合わせて何パターンか周期を設定できるようにしようと思っています。1時間毎に1パルスとか、1日毎に1パルスとか、自由に作れます。定点観測とかにも使えますね。
 パルス数は、とりあえず最大2^16-1パルスくらいまでになると思います。例えば5秒毎にシャッターを切る場合、2^16枚だと3日以上ですから、僕の用途としては充分だと思います。2^16以上必用なら、パルス数のカウントをとめて、電源が入ってる間はずっと回してもいいですし。

 自由にプログラムを書けますし、I2CやSPIやUARTやADCといったインターフェースが有るので、プログラマブルなトリガソースとして使うこともできます。とはいえ、STBee Miniのメモリ量だと、かなりカツカツな感じです。
 本当はSTBee F4miniで作りたかったんですが、前回買った2個は届く前に使いみちが決まってしまったので、現状、自由に使えるF4miniボードがありません。F4miniだとCubeで初期化できたりとか、楽なんですけどね。近いうちにF4miniを買い足しておかねば。


 ペンタのデジイチはレリーズに2.5mmのステレオプラグを使っていますが、オーディオ用の2.5mm-3.5mmステレオ変換プラグを使えば3.5mmのステレオプラグとして使えます。3.5mmのステレオプラグなら電子工作的にも簡単に扱えますし、フォトカプラで簡単にシャッターを制御できるようになるので、いろいろと遊べそうです。
 マニュアルやらAvやらTvやらなら、てきとーにパルスを入れれば撮影できますし、バルブモードならシャッタースピードを自由に制御できます。本当はUARTやCANでISO感度・F値・シャッタースピード等を自由に制御できるカメラがあれば理想なんですけどね。PK-Tetherとかあるので、技術があればF4miniでUSB Hostを作って制御とかもできるのかもしれませんが。

2017年6月16日金曜日

小ネタ:超音波風速計向けのADC


 STM32F4を使った超音波風速計のために、矩形波出力やADCのタイミングを合せたりしていました。たぶん6ch(3軸双方向)の生データは取れるようになったはずです。相変わらず1つのチャンネルはゲインが低いですが。このまえ秋月で買い物した時に超音波TRも買っとけばよかったな。。

 上のグラフは40kHzのパルスを出した時のADC波形です。縦軸は電圧、横軸は時間(マイクロ秒)です。サンプリングレートは1.5Mspsで、2000サンプルなので1.33...msecの期間です。矩形波は時間0から20パルス出しており、0.5msecの期間です。
 おおよそ気温と風速が安定した状態で、6回ほど試してみましたが、位相はかなり一致していました。

 開始時点で1.65Vくらいで、0.2msecあたりで1.58Vあたりまで落ち込んでいるのは、分圧抵抗のインピーダンスに対して、入力インピーダンスが低いためだと思われます。分圧抵抗が47k2個なので、マイコンの吸い込みは490k(1.575V時)くらいでしょうか。

 0usecから450usecあたりまで、下側にノイズが出てます。また、500usecあたりにも上側にノイズが出てます。80kHzや40kHzなら矩形波がそのままアナログラインに入ってるとわかりますが、20kHzってどういうことでしょうか。

 ノイズはだいたい20kHzなので、AD変換のタイミングは正しそうです。しかし、超音波の波形は微妙に40kHzとずれているのが気になります。おそらくADCの変換タイミングのジッターではないと思うんですが。AC結合のキャパシタや分圧抵抗で発振回路みたいになって位相ズレが起きてるのかもしれません。だとしたらマズイ。


 AD変換は12bitですが、レジスタ的には16bitなので、2000サンプルだと4KiBになります。前回の超音波風速計はSTM32F103CBTで、RAMは20KiBしかありませんでした。一方、今回はSTM32F405RGTで、RAMは192KiBあります。ねむいさんの教えに従い、64KiBはスタックに当てていますが、それでも128KiBあります。約6倍ですね。かなり余裕あります。
 FreeRTOSのスタックってどこから取られてるのかな。ヒープ領域っぽいけど、そうすると64KiBのスタックはがら空きですね。まぁ使わないよりは多少なりとも使われてる方が無駄が少なくて良いのだろうけども。


 なんか位相ズレがヤバそうな感じがして、超音波風速計としての精度がとても怪しいところですが、どうなることやら。


 相変わらずアナログ回路は最小を目指していて、今回はマイコンボードが大きくなっていながら、ユニバーサル基板はC型で収まってます(前回はB型 / 今回は液晶とか温度センサとか載せる余裕は無いですけども)。
 送信機と受信機のAC結合に1632のチプコンが1個ずつ、受信機の電圧レベルの調整に同サイズのチップ抵抗が2個、ということで、1chあたり受動素子は1632サイズが4個、能動素子が0個、という超お手軽回路です。
 受信素子は片側をGNDに落とし、もう片側をAC結合してからマイコンに接続、マイコン側に分圧抵抗を入れてますが、片側に分圧抵抗、もう片側はマイコンに直結、という構成のほうがよかったかも。これなら受信側にCL負荷が増えることもないし。
 ということで次作る時はそういう回路にしてみようかな。今の基板を改修するのはかなり大変。でもコネクタの手持ちが少ないので、あんまり無闇矢鱈と試せないのよね。ま、モノタロウで売ってるのは確認済みなので、イザとなれば買い足せるのでマシですが。

 受動素子限定縛りはなんとかしたいなぁ。とはいえ基板を発注するようなモノでもないしなぁ。ムラタあたりの素子が入手できるようになれば、アナログ回路ちゃんと作り込んで、1素子で送受信して小型化、とかいろいろできるんだけども。

DSP_Libを使う

 Cubeでは ./Drivers/CMSIS/DSP_Lib/Source/hoge フォルダの中に各種演算命令が入っている。FIRを使いたかったので、試してみた。

 とりあえず、makefileに必用な関数のソースを追加し、arm_math.hを変更すれば使用できた。

 今回使ったのは arm_fir_f32.c にある arm_fir_f32 という単精度浮動小数点を使った有限インパルス応答のフィルタ。この arm_fir_f32.c をmakefileに追加し、処理を行いたいコードで arm_math.h をインクルードしておく。そうすれば演算関数を使うことができる。
 ただし、僕の環境ではエラーが出てコンパイルすることができなかった。必用な定義が足りないためなので、その定義が含まれているヘッダを arm_math.h に追加する必要がある。
 arm_math.h 先頭の _ARM_MATH_H 直下に、以下のインクルード文を追加した。

#ifdef STM32F405xx
#include "stm32f405xx.h"
#endif

 今回はSTM32F405RGT6で動いているので、stm32f405xx.h をインクルードしている。
 定義自体は数個なので、自分でdefineを書いても良いのだが、とりあえず今回はヘッダをインクルードした。


 FIRに擬似乱数とLPFのフィルタを与えて、結果をPC側でFFTに通すと、LPFっぽい感じになってるし、ちゃんと動いてるんじゃないかなぁ。
 タップ数31、データ数8192でだいたい9msecだった。ただしコアが120MHzで動いてるので、通常の速度なら6.5msecくらいかな?

 DPS_Libには各種の関数があるが、単精度浮動小数点・32bit固定小数点・16bit固定小数点のバリエーションが有る。32bit・15bitのfixedはそれぞれq31・q15と書いてあるので、符号1bit・整数0bit・小数31bit みたいなフォーマットなんじゃなかろうか(未確認)。

 いろいろとクセがありそうなのと、いまいち何をやってる関数なのかわかりにくいので、使うのはちょっと大変かも。とはいえ、中身はただのC言語ソースなので、ARM以外のプラットフォームでも動きそう。とりあえずPC上で動きを確認してみるのもアリかも。

2017年6月15日木曜日

CMSIS-RTOSが面倒くさい

 Cubeで出力されるFreeRTOSはCMSIS-RTOSのラッパーが含まれているし、Cubeでタスクやキューの設定をすると、CMSIS-RTOSに準拠した?コードが出力される。ということでCMSIS-RTOSってどうやって使うんぞ?とちょっとドキュメントのサンプルソースを見てみた。
 とりあえずQueueを使ってみたかった。

 Message Queue

 かなり面倒くさいようだ。
 つま先でつついた程度で泥沼っぽいぞ、という気がしてきたので、とりあえず今回は違う道を通ることにした。

***

 ざっくりと流れを予想してみると、初期化時にQueue以外に、mallocで使うスペースも準備する。
 Queueに渡す(Putする)時は、予め用意したスペースからosPoolAllocでメモリ割り当てを受ける。そのメモリに情報を入れて、osMessagePutで割り当てられたポインタをQueueに入れる。
 Queueから受け取る(Getする)時は、osMessageGetでQueueから受け取り、必要な情報を取り出す。操作が終われば、osPoolFreeでメモリ割り当てを開放する。

 Queueの準備や、メモリ割り当ての準備は、マクロでいろいろ操作する必要があるので、いちいち書くのは結構面倒。
 Cubeではメモリ割り当ての初期化を行うことができないので、CMSIS-RTOS風の書き方をするなら、自分で初期化を追加する必要がある。またメモリ割り当ては固定長だが、CubeでQueueを大きくした場合は、ソースコードのメモリ割り当て初期化も修正する必要がある。誘蛾灯の雰囲気がプンプンするゾ。

 で、どうしてこういう面倒なことになっているのか。

 FreeRTOSのQueue回りは、ポインタを受け取って、構造体分全体をQueueに割り当てられたメモリにコピーするという処理が有る。おおよそmemcpyのような処理が行われるはずだが、構造体が大きくなればmemcpyに要する時間も長くなるので、処理時間の予測ができない。一方、ポインタだけをQueueに入れる場合、せいぜい4バイトか8バイトの転送で済むので、OSでの処理時間はある程度予想ができる。
 ただし、ただmallocを使う場合は、メモリのフラグメンテーションが問題になる可能性がある。実行時間に制限の付けにくいRTOSでは、フラグメンテーションの可能性は可能な限り避けたいところ。
 ということで、osPoolが出て来る。osPoolは固定長のメモリを小数割り当てるための機能であり、フラグメンテーションは発生しない。また、割当の組み合わせ数はかなり少ないので、空きメモリの検索も高速で行われることが期待できる。


 ということで、CMSIS-RTOSは個人レベルでプログラムを書く場合はかなり面倒だが、安定性を重視して作られている感じがする。

 とはいえ、例えばUARTのような、1回の処理で1バイトしか転送されないと行った場合は、FreeRTOSのような直接転送する方が早そうな気がする。このあたりはCMSIS-RTOSでもちゃんと用意されてるんだろうけども。

 あくまで業務用でも使えるRTOSなので、自分で楽しむレベルの電子工作では過剰かな、という気がする。なので、僕はしばらくFreeRTOSらいくな使い方を続けると思う。いざCMSIS-RTOSが必要になった時に、相当苦労しそうだけど、まぁそれはその時に考えるということで。

2017年6月14日水曜日

Altis Tidesystem

 Arma3でAltis TidesystemというModを試してみた。
 Tideは潮の意味。潮位を変更するMod。

 Steam ワークショップ :: Altis Tidesystem
 





 Arma3のアルティスやストラティスでは水路侵入できるような水路がないので、Tidesysで潮位を上げると、谷間に水が入り込んできて、ボートで侵入するにはいい感じのマップになる。
 SEALsやSWCCも好きな僕としては、かなり面白いMod。
 水路侵入する際の注意点としては、木や陸地が障害物として存在するので、進行方向の水中をよく見て進む必要がある。
 また、インベントリに入れられる地図は海面上昇(or低下)前に作成された地図なので、Tidesysで潮位を動かした場合は海岸線が正しくない。ま、これはこれで気候変動後にやってきた調査隊、みたいな感じで面白いのだけど。
 島に残るゲリラの対応をしつつ、民間人を救出していく、みたいなミッションを作っても面白いかもしれない。


 Tidesysを使う際の注意点として、潮位をエディタ(orミッションファイル)で変更することができない。
 潮位はMod自体にべた書きされているので、潮位を動かしたいならModの設定を変える必要がある。
 設定ファイルは C:\Program Files (x86)\Steam\steamapps\common\Arma 3\!Workshop\@Altis Tidesystem\addons\altis_tide.pbo になるが、これはテキストファイルの前後にバイナリのヘッダ・フッタを追加した構造になっているので、テキストエディタで書き換えることができない。書き換える際はバイナリエディタを使うこと。
 それと、テキストエリアの大きさはヘッダかフッタで固定されているようなので、オリジナルの文字数と、変更後の文字数が一致するように工夫する必要があるらしい。とりあえずコメントの文字を削ったり追加したりで一致させればいい。


 みんなもAltis Tidesystemで快適な水路潜入を! いや、Apex買えっていいたいのはわかります。。。やっぱタノア買うべきだよなぁ。

2017年6月13日火曜日

STBee F4miniヤバそうなピンまとめ


PA0 PD10k USR-SW ActH
PA11 FL USB D-  
PA12 FL USB D+  
PA13 PU10k JTMS/SWDIO  
PA14 PU10k JTCK/SWCLK  
PA15 PU10k JTDI  
PB2 OD4.7k BOOT1  
PB3 PU10k JTDO  
PB4 PU10k NJTRST  
PC14   水晶32k IN ピンヘッダ無し
PC15   水晶32k OUT ピンヘッダ無し
PD2 USR-LED ActH

 やばそうな、というか、ボード上でピンアサインが固定されてるピンまとめ。だいたいSTBeeと似た感じかな(未確認)。

 とりあえず、PA0は使わない方向で、PA11-12は可能な限り避け、PA13-15もできたら避ける。PB2も可能な限り避け、PB3-4もできたら避ける。PC14-15とPD2はピンヘッダへの接続はないので、そもそも使えないという点に注意すれば問題なし、という感じか。

 PA0はアナログ入力だが、システムスリープ時にシステムを起動するための機能が接続されている。その関係でスイッチもここに接続されており、アナログ入力ピンとしては使わないほうが良い。入力インピーダンス10kΩで問題ないような使い方なら御事由にという感じだけど、スイッチを押すと地絡するので、あまり出力インピーダンスの低い回路を接続するのも問題。まぁ、使わないほうが無難。

 PA11-12はUSB回りなので、少なくともUSB DFUを使う場合は、PA11-12は使うべきではない。JTAGなり、USB以外のDFUなりで書き込む場合は自由に使ってもかまわないだろうが、USBコネクタから給電する場合は、PCを誤動作に巻き込むおそれがある。PA11-12をUSB以外の用途で使いたいなら、USBコネクタを殺す等の処理をするほうが無難。

 PA13-15とPB3-4はJTAGで使われており、10kでプルアップされている。JTAGを使わず、かつプルアップされていても問題ないなら、使ってもよろしい。

 PB2はユーザーFlashからプログラムを起動する限りでは、ピンを評価されることはないが、STBee F4miniはUSB DFU接続時にシステムFlashを起動するので、その際に外部の回路がPB2をHに引っ張ると正常に起動できない。ということで、PB2は可能な限り開放で使い、どうしても接続が必要な場合は、マイコンリセット時は確実にLに引っ張られるような使い方をする。

 PC14-15はピンヘッダへ接続されていないので、そもそも使うことができないという点に注意。あと水晶が直結されてるので、PC14をH、PC15をLみたいな、水晶に直流電圧がかかるような状態で放置するのはよくないはず。ということでPC14-15は使わないほうが無難。

 PD2はLEDが接続されているので、ちょっとした動作確認にチカチカさせたり、ROMのアクセスランプみたいに使ったり、いろいろ自由に使える。ただボード上にはパッドすらも無いので、ロジアナとかオシロでパルス幅を見るようなデバッガをするのは大変。ただ小さなビアが有るので、ジャンパワイヤを載せたりとかは比較的楽(パッドと違って滑りにくい)。