2020年4月19日日曜日

小ネタ:1wireとか

 SDS1202X-E、Printしてハングアップする確率高すぎる件。運がいいと電源ボタン長押しでシャットダウンできるけど、最近はそれも反応せず、電源プラグ抜かないとシャットダウンできない。精神的に非常によろしくない。メーカーも「電源入れるときは突入電流で寿命削るから頻繁な電源のON/OFFは避けてね」とか書いてるし、数分に1回の頻度で電源プラグ抜くのはまじでヤバそう。
 一度メーカーサポートに連絡しておいたほうがいいかもなぁ。ADWINに聞いてみるか。ぐぐってもハングアップしたって話は出てこないし、症状としては稀な現象なのかも。不良個体にあたったかな? とはいえ、ウチの個体の症状だとUSBメモリにPrintするときにフリーズするが、そもそもUSBメモリにスクショ保存してる人自体が少ないから表面化してないだけ、という可能性もある。

 試しにUSBメモリをフォーマット(クイック無し)したらハングアップしなくなったので、中に入ってるデータとかの関係もあるかも。メーカーどころの1GBくらいの買って、こまめにイレースフォーマットしながら使う、あたりが良いかも。
 BUFFALOのUSBメモリ使ってるけど、Siglentは中国のメーカーだし、中国メーカーのUSBメモリのほうが相性問題は起きづらいかも。最近のUSBメモリってデザインが個性的だからなぁ。日本メーカーのは保守的というか、いかにも「USBメモリ」みたいな形で好き。

***

 ふと思い立ってSTM32F4用のI2Cのドライバを書いて、それに飽きたので1wireのドライバを書いてる。1wireは極めてアナログなバスなのでオシロで見てて面白い。
 I2Cは2chオシロでもプロトコル解析できるけど、さすがに1wireはマイナーすぎるのか対応してない。Tekの100万円クラスのオシロでもさすがに1wireは非対応なようだ。

 STM32のI2C、かなり使いづらいイメージが有ったけど、真面目にドライバを書いてみると結構使いやすい。とはいえエラーハンドリングとかは未実装なので、そのあたりもしっかり作ろうとすると大変だろうけども。。。

***

 とりあえず、1Wireはストロングプルアップを使える程度までは実装した。

 DS18B20を9bitで変換。

 全景


 コンフィグと変換開始コマンド


 変換開始部分の拡大


 データ読み出し部分の拡大


 変換開始部分を更に拡大。


 3.3kでプルアップ、プルアップからマイコン側に100Ω、プルアップ部分を47kでプルダウン。プルアップ付近でプロービング。
 0V付近まで下がっているときはデバイスが駆動。0.1V付近までしか下がっていないときはマイコンが駆動。3.3V付近はストロングプルアップが有効で消費電力が微弱。3.25V付近はストロングプルアップが有効である程度の消費電力(e.g. AD変換時)。3.12V付近はストロングプルアップが無効で消費電力が微弱。

 すべてSkip Romでデバイスを選択。
 最初に0x4Eでコンフィグの書き込み。0x1Fで9bitモード。変換時間は公称で93.75ms。
 続けて0x44で変換開始。最終ビットRisでストロングプルアップを有効化。
 ストロングプルアップを有効にしてから17マイクロ秒後付近で急激に消費電力が増えるタイミングがあり、以降ある程度の消費電力で推移する。ここでAD変換が開始したと推定。
 消費電力の増大からおよそ74ミリ秒後に消費電力が減少する。ここでAD変換が終了したと推定。
 ADCで負荷を監視すればAD変換が終わったタイミングを判定できそう。とはいえ、そこまで変換時間を切り詰めるならそもそもパラサイトパワーとか使うな、という話だよな。

 パラサイトパワーなしのDS18B20、FT232にダイオード1本と抵抗1本で直結して適当なコード書けば温度変換できるので、PC内部の温度監視とかにおすすめ。
 もう一個FT232用意してInvにしてやればWS2812とかで24bitフルカラーの表現ができるから、暖かくなってきたら黄色で表示するとか、熱くなりすぎたら赤で表示するとか、WS28内蔵の7セグLEDで情報を表示するとか、工夫次第で色々できそう。

***

 メモリ長いオシロだと1回のトリガで変換開始と読み出しの両方見れて便利。ハングアップで再起動して5回位キャプチャしたけど……
 しかし2chだと足りないシチュエーションがちらほら。4chモデルほしい。いや、くれるって言うならTekのMSO46あたりほしいけど。このあたりになると1553やSpaceWireもデコードできるらしいので、数トンクラスの人工衛星を作ろうとすると最低でもこれくらいのオシロが必要になるんだろうな。SpaceWireだと平衡接続2本でデータ送ってそれ2組で全二重やるから8本のアナログ系を見なきゃいけないはず。となると4chのMSO44や6chのMSO46では全二重はデコードできないはず。プロトコル解析はデジタルでやって、アナログで信号の品質を確認する、みたいな使い方だろうか。

 そういえば、ZEROPLUS LAPシリーズってなぜかMIL-STD-1553に対応してるんだよな。さすがにSpaceWireは非対応のようだけど。
 台湾空軍、F-16も使ってるし、自国企業が安くて使いやすい解析ツール作ってくれるのは良さそう。ミリタリーユースでこのガワはちょっと怖いけど、まぁ手荒に扱う代物じゃないので…… というか現場なら現場用の機材使うだろうし。
 ちなみに、戦闘機のデータバスは、F-15で使われたのがH009、F-16からMIL-STD-1553、F-22あたりからFireWireベース、という感じ。民間の航空機だと独自なやつとか、Ethernetベースで末端付近はCANバス、とか。軍用機でもCOTS重視ならEthernetベースを使ったりというウワサも。
 009は保守的な空軍(しかもミサイル万能論でボロ負け中に超保守的なコンセプトで計画したF-15)で使われた極初期のデータバス。もっとも、F-15にしか使われてないあたり察しろという感じだが。
 1553は衛星でもよく使われてるけど、ISSはどうなんだろう? 新しい補給機が続々と開発されてるけど、そいつらも1553なんだろうか。確かHTV-XがSpaceWriteと1553の両方を使うはずなので、少なくとも1553が必要な部分がまだ有る、ということなんだろう。とすると、やはりISSへの互換性で要求されてるんだろうな。SpaceWireに1553のパケット通して結合部周りで物理的な1553に取り出す、みたいなことをやってもいいはずなんだけど、わざわざ結合部開発する予算が出ねーってことなんだろうか。あるいはHTV-Xが古いバス機器流用してるせいで1553が必要で、実はISSはとっくにSpWに対応済み、という可能性も……


 ZEROPLUS、製品リンクからソフトウェアのリンク開くと2016年くらいで更新止まってるけど、トップページからダウンロードページに飛んで製品選ぶと2020年の更新も表示される。19年は2回更新、18年以前は結構頻繁に、という感じ。さすがにLAP-Cはだいぶ古い製品だろうし、たまにバグフィックスやる程度か。

 LAP-C Proが現行かな? 一番スペックの低いモデルで16ch、64M/ch、いくつかのバスでハードウェアプロトコルトリガ対応、という感じ。ウチのLAP-Cに比べてメモリで3桁違う。ほしい!!売ってない!!!ストリナや秋月でも扱ってない。。。
 ユーロ圏のショップだと扱ってるみたい。SiglentのロジアナオプションとかもADWINで扱ってる以外だとほとんどユーロ圏のショップだし、計器は向こうのほうが売れてるのかも。まぁ日本の電子工作erはArduinoのコピペばっかりだしロジアナとか使わないよね!!!(ひどい偏見だ

 曰く、9.6万円-37万円とのこと。たけぇ…… とはいえ、LAP-Cでも上位モデルは10万円ほどだし、それより数倍性能がいいやつが同じ価格帯と考えればさほど割高感はないんだが。
 しかしまぁ、電子工作始めて、センサとかもっとガッツリ使いたい!となったときにいきなり「10万の計器買ってね」とか言われると、そりゃ拒絶反応出るよなぁ。だからといってリマーク品ルーレットやってる奴らは気がしれねーが!! あのひとたちほんとふしぎ。プログラミングできないことを誇って海外通販でリマーク品買って安さ自慢してトラブったら他人に丸投げして。何が楽しいのやら。。。

0 件のコメント:

コメントを投稿