2020年7月 5日 (日)

ハードの情報

確かにメタ化しないと説明が難しいけど
(背景とか説明し始めると、とてもじゃないけど終わらない)
さりとて、メタ化されている情報では、
ほとんど意味が分からないのも確か。


じゃあ、何なら意味があるかって所なんだけど
もう生の情報を未加工で出してもらうしかない。

と言うかそれが一番早い。


ソフトウエアだとソースコードだけど
ハードウエアでは回路図、アートワーク?
実際にはこれでは全然情報が足りない。
(足りることもある)

------

しばらく前の、ロケットの電装品とか。
写真何枚かと、簡単なキャプション。
ああいうのが(情報としては)非常に分かりやすい。


ああいうの、全体的に眺めて、
あー、こういう志向の人がやってんのね、とか
まさしくメタな情報が、非常に役に立つ。
ってことは、多分この辺見てないな、とか。

情報出してる側の意識とは
全然別レベルで情報を抽出する感じ。
情報取れるのは、こういう処だ。
往々にして出してる方は意図しない情報だったりもする


こういう面もあって、(結果的に)公開される
ハードの情報が少ない理由の一つじゃないかな、
と思っていたりする。

出したくない情報と、出したい情報。
意味を残したままでは、多分うまく切り分けられない。

| | コメント (0)

2020年6月20日 (土)

stm32のHALライブラリ

なんか荒れているようだな....

個人的に思うのは、
他のプロセッサならともかく、stm32fに限っては
使うのが良いか、メリットが無いかは
ケースバイケースのような気がする。

メリットは今更、論ずることはないけど、
デメリットがなあ。まさしくゴタゴタやってる
そこやぞ、って感じ。

完成度が低いって論点ならば、まあ待ってりゃ
何とかなるかな、とは思うけど
stm32fやgは、細かい型番違いでも、
ペリフェラルが微妙に
アップデートしていくのだ。

当然便利だよ?
でもね、これって、使う側が
熟知してないと、強烈にハマったりすると思う。

ライブラリで、中途半端に違いを
隠蔽されては、却って解決に時間かかるし。
結局、リファレンスマニュアル何度も
熟読してハードウエアの微妙な
違いを掌握しないと、理解できないこともある。

ライブラリがどうとかじゃ、
どうにもならないと思うけどなあ。


それでも、stm32使うよ。
便利だもんね。

で、ゴタゴタに付き合う気は
さらさらないので、ごりごり自分で書く。

何度も言うけど、開発の平均ペースを
上げたいわけじゃなくて、
ワーストケースを担保するのが
最優先なのでね。

もちろん、担保できるように
なったら使うと思うよ。
でもI2CのNAKごとき(定番だよ)で、
もめてるようじゃ、先は長いと思うね....

タイマ周りとかはその比じゃないでしょ。

| | コメント (0)

2020年6月14日 (日)

プログラムコード記述量

あー、確かに、将来に残る”有意の”コードなら、
いいとこ月平均数百行くらいかもね。
自分はプログラマじゃないけど、
なんとなく言わんとすることは分かるかも。

試行錯誤とか、環境構築のテストとか、
作業は膨大でも、じゃあ、最終的な成果物といえるコード量は?
と言われると、そんなもん。

あれやこれはダメだった、途中まで作ったけど
筋が悪くてこのまま進めると、将来にわたって
無駄作業を生み続ける、なんて理由で
破棄されるものが大半だ。
こういうもの、普通は成果物には入れないしね。

プログラミングは単純作業じゃないので
生産性としてはそんなもんだと思うよ。


仕事量増やしたいだけなら、効率の悪い方ばかり
選べば、いくらでも仕事増やせるけど、
仕事量の多さでは満足感を得られないんだよな。
もう、そういうことやりたいお年頃でもないし。


| | コメント (0)

2020年6月 4日 (木)

ワイヤーハーネスの防水

なんて話をする。


フィールドで使う電線、コネクタのアッセンブリ、
所謂ワイヤーハーネス。

屋外で使うので、そりゃ雨が降れば
びしょぬれになったりする。
で、事前に防水対策をするんだけど。


束になっている素線に、保護材
まいたりするんだけど、こと防水、
て言ったときは、この辺はほとんど関係ない。

電線の外装表面だったり、端子だったりが
多少濡れようが、水没しようが、まあ
適当な処置をすれば、どうということはない。

致命的なのは、実は素線の内部。
導体と絶縁体の隙間に入ってくる水がヤバイ

表面濡れるのと違って、内部浸水は
毛細管現象でどこまでも浸水していく。
上方向にも昇っていくし。
途中で防水コネクタになっていても、
コネクタは内部と外部が防水になっているだけなので、
内部に浸水した時点で、勘合部分も超えて、
勘合相手側にも浸水していく。
こうなると防水構造が逆に災いして、
入ってきた水はどうやっても抜けない。


端末処理を、かしめたりしてると
この種の浸水に完全に無防備になる。
外見まったく問題ないけど、気が付くと
かなりの量の水が電線内に侵入してたりする。

コネクタ外すと、ぽたぽた水が滴るほどだ。

こうなっちゃうと、もうどうやっても水を
排除できないので、泣く泣く交換
廃棄となってしまう。

------

ハーメチックコネクタは、この種の
防水に効果的なんだけど、
種類も限られるし、施工に制限もあるので
どこでも使う、って訳にもいかない。


こと電線の防水構造については、
知ってる人は当然知っていることなんだけど、
あまり論じているものを見たことが無い。

一般的な解説って、無いのかなあ。


| | コメント (0)

2020年5月29日 (金)

これは...

https://drive.google.com/file/d/1EbIafXL5trjtbRGqAtP1mUjRdiDeP_ir/view

ああ、これ。
やりがちなんだよなあ。

特に11ページの”相互接続ボード”はやばい。

いや、これ、一見便利っぽいんだけど。
こう作りたくなるのは良く分かるけど、
実際、難しいよ?
本当に機器チェックとかならいいけど、
本番ものでこれは....


あと、一部のパケットが通っているから、
CAN BUSは問題ないってのは、
CANあるある先入観。ヤバイ

一部のパケットだけ通らないなんて
ザラだよね。
ハード的にもロジック的にも
普通に起こるよ。

こういう、直感に反するトラブル発現が、
CANの真骨頂だね。

結果、違うところに原因を求めてしまって、
非常に遠回りする、CANトラブルの
いつものパターンぽい。

こりゃあ、苦労するだろなあ....


同じ記事で、摩擦による帯電なんてのもあって、
さらにヤバい。

なんで絶縁型CANドライバなんて
ものが存在して、もうそこらじゅうで
使われているか、という話とか....




こういう技術情報は有り難いというか。
なんとなく、何が起きてるか
分かる気がするというか。

オブザーバーみたいな人はいないんだろうか?

| | コメント (2)

2020年5月23日 (土)

socket

あー、本当に今更なんだけど、
socketって、繋がるときにしか、
相手の情報必要ないのね。
それで、こういう挙動になるのか....

文章にすると当たり前すぎるんだけど、
どうもほかのプロトコルなんかのイメージで
捉えてることが多すぎるな...

なんだかやっとルーターとかの挙動の
意味が分かった気がする。
少し。

思ったより簡単に実装できそうだ。
まあ、もともと、シンプルな
もんなんだろけどね。
ネットワークなんてね。

| | コメント (0)

2020年5月11日 (月)

バイナリファイル.....

バイナリファイルです、と言われて出てきたファイル(拡張子は*.bin)
開けてみたんだけど、なんだかへんだ??

なんだこれ、ASCII文字のテキストデータ(0~F)で
16進数がズラズラとべた書きされてるだけかよ!!怒怒
しかもちゃんとEOFが、^Zになってるじゃねーか。切

これはなあ、テキストファイルっって言うんだよ。いい加減に城


こんな珍妙なファイルをバイナリファイル、と称する
文化圏もあるのか。

無知は罪、という言葉を痛感する。


つうか、こんな中途半端なファイル、
どうやって処理すりゃいいんだ笑


こういうのやりたいんなら、
インテルHEXとか、Sレコードとか、
いくらでも有名どころがあるから、
そういうので作ってほしいなあ。

まあ、今どきHEXファイルなんて
言っても、通じないのかも
しれないなあ。

| | コメント (0)

2020年5月 9日 (土)

ヒープ領域

ああこれ、標準ライブラリ。
どうしてもヒープ領域用意しないと動かないのか...

まあ、しゃあない。
不確定要素、増やしたくはないんだけど、
領域の上限、ハードコードでも監視してりゃいいか。

これで、newlib、所望の動きをするようにはなった。...が
結構たくさん要求してくるなあ....
ちゃんと見てないと危ないレベル。

| | コメント (0)

2020年5月 7日 (木)

I2Cの怖かった話

結局迷宮入りってことで
埋められちゃったネタを一つ。

------

とあるシステムで、時々I2Cの応答が
止まっちゃう、ってことがあった。

よくあること?なんだけど...
このレベルなら回避策もあるんだけど...
そもそもなんで止まるの?って所が怖い。

------

異常動作をしていたのは、予想通り
SCLの誤認識。

SCL立ち上がりの所で、なにかのトリガで
バスストレッチの要求ありと判定するみたいで
スレーブ側で、クロックが一つ飛ばされてしまう。

で、マスタはクロック全部出してるんだけど
スレーブ側はいつまでも、最後のSCL
(よりによってACK...)を待ったまま
止まってしまう。

------

色々回路を追っていくと、問題のI2Cバス
にはかなり大きめのプルアップ抵抗
(3.3Vに対して4.7kくらい)、
はっきり大き目のダンパ抵抗(100Ωくらい)に
とどめのパスコン1nFくらい?

何だこりゃ?と思ったのだけど、どうも
一番最初は、5Vのシステムだったのが
いつの間にやら3.3Vに変更されていたようだ。
これ定数大き目?と問うと、
過去のノイズ対策ガー、とのこと。

チップ変えたら、定数は都度評価してほしいなあ...

I2Cって、レベル動作しているから、
エッジをなましても仕方ないんじゃ?
一体、何を根拠にノイズ対策なんだろう。

スペックには入っているから問題ない、
との話だったのだけど。
どうも気持ち悪い....
そもそもバスに、わざわざ負荷容量つけんなよ...

------

で、問題のタイミングは、ソフトウエア
依存性があるという。
はああ?て感じだったけど。
どこよ、と聞いてひっくり返った。

I2Cの通信のタイミングが、ADCの
起動タイミングにかぶると、
シビアなタイミングでエラーが
発生している、との観測結果があったようだ。

なんじゃそら。
I2CとADCのペリフェラルなんて、
何にも関係ないでしょ....

------

ここんところで、
マイコンチップ内部の問題って
ことで放り投げられてしまった。

回路設計の問題ではない、と。

まあ、投げ時と言えばそう(これは深入りしたくない...)
なので、致し方ないか、という感じなのだけど。

------

決着ついた後、じっと回路図見ていると、
このI2Cのピンは、ADCの入力ピンにも
設定できることに気づいた。


ああー、これ、もしかすると、あれだな。

ADCは、別の複数のピンを切り替えながら
動作してるけど、コンバーターは一つだ。
マルチプレクサが、アナログ入力ピンを
切り替えながら動作してるんだよな....

当然、I2Cのピンはアナログピンとしては
使ってないけど、内部回路的には多分繋がってる
(ハイインピは、繋がってないわけじゃない)

で、マルチプレクサの切り替えにグリッジが
発生するようなロジックがあって、
ADCのサンプルホールド回路とかに
残っている電荷が一瞬だけ、
問題のピンにチャージされるんじゃないか?
クロストークレベルで。

------

こんなもの、通常のロジック動作では
ほとんど影響しないレベルだと思うけど。

色々間の悪い状況が重なって、よりによって
I2CのSCLの立ち上がりに重畳すると
ピン電位が微妙に下がってしまって、
アウト、ってことなんじゃないだろうか。

当該のI2Cのアヤシいノイズ対策も、
外からのノイズには、機能するかも
しれないけど、内部で発生する
ノイズに対しては、無力というか
悪い方向にしか効かない気がする....

でかいCRのおかげで、危険な
電圧レベルの通過に時間が掛かって
しまっているよな。

せめてプルアップ、1.8kくらいに
してくんないかな...

あと、そこまでわかってるなら、
I2C動かすときには、
ちょっとだけADC止めりゃ
いいじゃん、と思うんだけど。

------

まあ自分からは、遠い処の話だし、
結局、話は埋められてしまったので、
如何こうできないのだけど
自分的には、腹に落ちた。

裏は取れなかったけど、
状況証拠から、ほぼこれだと思っている。

物は、割と今どきのマイコン(旧M社)なんだけど、
こういうこともあるんだなあ、と。

| | コメント (0)

2020年5月 5日 (火)

CAN徒然

CANについてつれづれと。

なんだかずっとCANには煮え湯を飲まされ続けてるんだけど、
世間ではあんまりそんな話を聞かない気がする。

まあ、こういうの、自分の能力の裏返しでもあるから
不用意な発言は恥をかくだけ、ってことになるのだけど。

まあ、実際の実装見ても、本職?の作るものは
厳重な(ここまでやるの?って)対策が施してあるので
うたい文句のようにはいかない、って
雰囲気は強く感じるのだけどね。

------

そもそも基本的にやっちゃいかんでしょ、って
実装が多すぎて、トータルシステムを運用すると
死しか見えない、ってのがひどすぎる。

CANの理想と現実、って題で、一冊くらい
同人紙くらいなら軽くかけるんじゃない?
って感じだけど、この辺、あまり光を
当てても、困っちゃう所が
多すぎになりそう。

こっちは過去のバカ話のつもりでも、
実際に直面しているところでは、
シャレにならないからなあ。

CANだって、本当はUART並みに
ボーレート誤差、許容するんだよ?
規格はまあ、あるけど、ずれてくると
自動でクロックのカウントをずらして
ちゃんと読んでくれる。
本来、1%~くらいのクロック誤差なら、
ものともしないんだけどね....

2%弱くらいの(設計)誤差で1:Nで、
普通に通信できていたんだけど、
ある日、後付け追加で来たアレがね...とか

現実はそうならないところとかに、
闇がたくさんあるわけで。

CANの規格にちゃんと書いてない
部分(結構たくさんある)とかで、
CANの動作、趣旨を理解せずに
UARTのつもりで書いちゃいました~
って所に、致命的な動作仕様が
生まれがちだ。

まあ大体、人間の問題なんだけどね。

| | コメント (0)

より以前の記事一覧