2020年9月20日 (日)

大電流基板

多層基板(4層<)、電流容量確保の目的では
初めてトライしてみる。

ピークで25A~になる。
両面基板だと当然ダメなので、内層全部で
パワー系の配線とするんだけど、
どのくらいに見積ればいいんだろう?

導体厚から、スケア相当で計算するにしても、
あれって、放熱具合で決まるようなもんだから、
基板だと別の話になりそうだし。

通常の導体厚で1mm幅1Aってのも
良く言われるけど。

通常の35um厚だと、1mm幅で
0.035sq相当。
1sqの耐熱電線で16A相当と
言われているので、1mm幅だと0.6A
くらいが許容量になるけど、
基板パターンの放熱は、普通の電線よりも
大分有利ぽいし、耐熱性も電線に比べれば
大分高そうだ。

まあ、とりあえずやってみて、
基板の温度測ってみるのが早いかなあ。

| | コメント (0)

2020年9月15日 (火)

stm32の割り込みレイテンシ

多分、違うと思いますね。
Cortex-M3のテクニカルリファレンス
マニュアル(@ARM)に書いてありますね....

割り込み状態からの割り込み、
通常の半分ほどの時間で、
起動するみたいです。

スタック操作を端折ることで高速に
処理してる、とありますね。

| | コメント (0)

2020年9月11日 (金)

ファームウエア

まあ、なるべく移植性を上げたい、気持ちは大事。

ハードウエアそのものも、移植性?上げた方が
いいに決まってる。

------

抽象性、冗長性を持たせるには、様々な面で
余分のコストが要る。

もちろん、移植性のために支払うコストは
正当で、尊いとすら言える。

------

ただまあ....ときどき悪いw心が
ぎりっぎりの空中ブランコみたいな
ハードウエア、作りたくなったりするんだよね。

一種の病気かもね(暗黒微笑)

そういうキワモノ、うまく動くと
ある種なんだか変な物質出てきて
極まったりするのが、楽しかったり。

| | コメント (0)

2020年9月 9日 (水)

C関数の引数に

constつけるのって、そもそも標準ライブラリの関数でも、
引数const修飾だらけなんだけど....
つけちゃダメなのかなあ。
それとも、なにか違う話なのかな。

せめて参照用のポインタ変数には、
付けた方がいいと思うし。

組み込みだと、気持ちの問題ですら無くなるし。

| | コメント (2)

2020年9月 8日 (火)

組み込みプログラマ

あー、そりゃ組み込み”プログラマ” だけ
やってりゃ、そりゃキレるだろね...

自分も所謂組み込みプログラム、
仕事で書くけど、全体の作業に対する
割合は、多くて2~3割という処。


関連するハード、システムも設計、
もしくは技術介入できる
権限とセットでないと、
組み込みプログラマ専業なんて
とってもやってられないと思う。

自分だったら、絶対無理だね...
そういう環境で振り回されてる人
たくさんいるんだろね。


まあ、すべてセット(撤退する決断まで)だと
この組み込みの仕事、大変面白いんだけどね。

| | コメント (0)

2020年9月 5日 (土)

はんだごて修理

長年使っているはんだごて。
在宅作業中にヒーターが断線してしまったようだ。

そろそろ調温はんだごてに
しようか、と思いつつも。

仕事などで使ってるFX-888が
気に入っているんだけど、唯一持ち歩きに
不便なこと。

というわけで、今回も交換部品を頼んで自力修理。

おとといの夜、発注。今日の昼に届く。
助かるなあ。

2009051
ヒーター容量は18W
コテ先のサイズからすると小さい気がするが。

2009052
はんだごての修理にはんだごてが必要。

2009053
コテ先も新品に。

調温はんだごてが一般化する前の
製品だけど、コテ先の熱容量が大きいのか
小さい割に使いやすい。

| | コメント (0)

2020年9月 4日 (金)

組み込みとUSBとWindowsなど

大体、昔から便利そうなデバイスでも、
Windows絡みを想定しているような
物だと、後々厄介なことになる、って
想いが強い。

この手の物、話しが始まる前に
極力そこに行かないように誘導している。

USBなんて最たるもんだけど、
まあUSBシリアル変換チップとか、
実質内部(プロトコルとか)を触る
必要のないものは安全だ(当然例外もあり)

------

色々問題のある仕様、Windowsで使う分には
Windowsアップデートなんかで修正されたり
同じ品番でも挙動が違う物があったりしても
デバイスメーカーの供給するドライバでは
ちゃんと個体識別してて、アクセス方法を
(ユーザーには気づかせず)使い分けたりしている。

こんな対応されたんじゃ、ベアメタルで
使おうとしている立場では、まったくやっていられない。

USBデバイス、前と同じ型番の物
使ってるんだけどなあ...と言っても、
内部のチップが変更されていたりして、
結局、エンドユーザーに製造何時々々、
シリアルこれこれのデバイスを
(自力で探して)使ってください、
とか地獄のような指示をすることになる。

そういう、詰んだ組み込み製品、
ちょくちょく見るよね。


こんなの指定して探さなきゃいけないんだったら、
USBなんて使わんわ、超不便。

と、なるんだけど。

まあWindowsとかの汎用OSの
支配下以外で使おうとしている方が、
根本的な運用システム、ビジネスモデルを
理解してない、ってことだと思っている。

使いたきゃ、WindowsとかLinux乗せなよ。
メーカーの出してくるデバイスドライバ
完全に動くようにしてね...

------

コントローラーをラズパイとかにすれば、
ある種の解決はするんだろうけど、
他の問題もいろいろ出てくるので、
手放しで採用するわけにも行かず。

------

昔は組み込みのストレージに
CompactFlashドライブを使ってて、
最初は良かったんだけど。

色々な製品に使われ始めて、
出回るようになって、もう全然ダメに
なってしまい。

たまらずSDに移行してみたものの、
やっぱり同じ道をたどって、
10年は持たなかった、って印象。

結局、組み込み用のストレージは、
NAND Flashに落ち着いた。
今どきのは、十分耐久性もあるしね。



CF、SDとも標準の読み書きコマンド、
当然サポートしているんだけど、
時代が進めば進むほど、アクセス方法が
拡張されていて。

互換のあるモードでは使い物に
ならないほど、性能が落とされていたり。


例えば、初期の頃でも、
シングルセクタ読み込みが
カードの世代が進むごとに
アクセスが倍、3倍のレベルで遅くなっていく。
なんじゃこりゃ?と思うんだけど、

色々試すと、シングルセクタ読み込み
コマンドではなくて、マルチセクタ
読み込みコマンドを使って、最初のセクタを
取り込んだ後、アボートさせることで、
10倍くらい早くアクセスできることに
気づいたり。

さらに世代が進むと、マルチセクタコマンド
ではなくて、さらに別の拡張コマンドに入って...
と続いて、とても追っかけきれない。

当然ながらこういう事情、メーカーごと、
製品ごとに、それぞれ違う
アクセス方法となっていて
Windowsみたいに、すべての市販のデバイスを
網羅できるような環境(net接続含む)が
用意できないと、満足に動かせないことを
理解して終わった...

OS側は、個々のデバイス、どうやって
アクセスしてるかななんて
そもそも関わってないしね。
デバイスメーカーが、自分とこの事情で
OS外で好きなようにやってるわけだし。

組み込み、ベアメタルで使うもんじゃ無いな...


超高級グラボでも、VGA表示出力は出来るけど
其処での描画が早いわけではない、というか
メチャクチャ遅いとか、そういう構図かと。

------

USBなんて、メディアの変遷以上に
もっとヤバい動きをする
(USBの規約は問題ないけど
Windowsの挙動が読めない)ので。

動かすところまでは、そんなに時間が掛からなくとも
あとあとのサポートが泥沼化するので、
可能な限り避けている。

今の処、それで困ったことはない。

通信で使いたいなら、大概Etherで済むし、
USBしか持ってない物は、大概安いものなので、
上位機種提案すれば済むことばかりなので。



USB、規格が進んでも通信距離とかも
伸びない(おそらくあえて伸ばさない)し、
WIndows(OS)側のパワーで運用は押し切ろう、
って印象がある。

まあ、うまいこと使えたら、
ラッキーと思って。
最後のアテ、命綱には
しないってのがいいのかな、と思ったり。

| | コメント (2)

2020年8月29日 (土)

ロボット屋

やっぱり、”ロボット”をやりたくて、そこから始めた人は
なんというか、”見える部分”に偏ってる気がする。

普通の機械屋、電気屋、ソフト屋などなど、
外からは見えにくい、本質的な構造を
理解しているからこその専門だと思うけど。

”ロボット”を、やりたい人の強みでもあるけど
弱さでもあるなあ、と思う。


ちょっと言葉は悪いけど、
例えば、自動車のタイヤを見て、ゴム風船
みたいなイメージでとらえてたりとか、
そんな印象がある。
まあ、そういう風に見えるかもね....


ロボット屋さんも、ロボット以外の
専門が、もう一つくらいあると
バランス取れるのかもしれない、と思ったり。

| | コメント (0)

2020年8月28日 (金)

ACK

前のエントリの内容追加。

頭整理して考えてみると、ACK/NAKのフラグフィールドのある通信、
例えばCANとかI2C。

特定のフィールドがACKかどうかの判断が、
ノード間でずれた時に、修復不能の
ステートに入ったりするのが
致命的なんだと気づいた。

これ、同じライン、信号線を共有して動かしている以上、
原理的には、どうやっても回避できないような...

タイムアウト設定して、全部のステートマシンに
強制リセット掛けるくらいかな。


だったらいっそACK、NAKなんて使わないか、
完全に信号線分けてしまうのが、難しいステートに
入らなくていいよな。

となると、やっぱり、CANとかI2Cは
異常動作時の信頼性では失格で、
Ethernet(1xxBASE-T)、
UART、SPIなんかは合格なわけだ。

なにかすっきりした気分。


あー、CANの接続を1:1に限定するのも、
バス上でのACKの解釈を固定するのには、
かなり有効だよな...

CAN BUSの難しい挙動、ここがらみ多いし。

------

よくよく考えてみると、そもそも正常動作時?
の信頼性なんて、なんかあんまり
役に立たないような気がしてくるな?

| | コメント (1)

2020年8月27日 (木)

あー、非同期通信

まあ、見るからに115とか、300bpsあたりの速度での
通信を想定しているよね....
現代のビットレートで、ACKなんて待って
られるか、というお気持ち。

実際、マイコンで動かしても
USARTでのプロトコル処理よりも、
Ethernetパケットの処理の方が軽いというのが
もうショック。
待ち時間とか、諸々オーバーヘッド考えると
実際軽いのだ。

------

あー、考えてみりゃ、
自分基準での要注意シリアル通信、
I2CとかCANとかUSB、
どれもこれもハードウエアで、
ACK返るやつばかりだw

やっぱりそうか....


ACKがあるやつの方が、
危ないってのが皮肉なもんだけど、
まあ実際そんなもんだよね。

規約が正しくあったとしても、
ちゃんと実装されない可能性もあるしね。

| | コメント (4)

より以前の記事一覧