">

C言語でカリカリチューンして、どの程度までいけたでしょうか？

以前、
http://207.236.16.161/JinSato/MindStorms/HW/BBS/hw_41.html
の541番の記事でアセンブラーによるものを書いたので、
Cであれにどこまで迫れる／追い越せるか、
大変興味があります。decfszの後ろに、
goto以外の命令をおいてくれるような、
最適化ができるようなら、私もぼちぼち、
PICをC言語でプログラムして見ようかなあ。

Jinです。

急に違う方法を試したくなってコードを書き始めてみました。

基本的に、サーボの位置を保持している変数の配列をパルスの短い順番に sort として
sort された順番を元に、 Timer1で作るイントラプトのタイミングを計算 と
イントラプトがかかったときに、各サーボに接続している I/O ピンの Bit パターンも計算して
変数に入れておく

あとは、イントラプトが発生したら、既に計算されている bit パターンと次の イントラプトの
タイミングを指定する。

イントラプトのルーチンは

PORT_A = bit_a_out[0]; PORT_B = bit_b_out[0];
PORT_A = bit_a_out[1]; PORT_B = bit_b_out[1];
PORT_A = bit_a_out[2]; PORT_B = bit_b_out[2];
PORT_A = bit_a_out[3]; PORT_B = bit_b_out[3];
PORT_A = bit_a_out[4]; PORT_B = bit_b_out[4];
PORT_A = bit_a_out[5]; PORT_B = bit_b_out[5];
PORT_A = bit_a_out[6]; PORT_B = bit_b_out[6];
PORT_A = bit_a_out[7]; PORT_B = bit_b_out[7];

set_timer1( time_table[ n ] );

と OUT を並べておく方法です。
いま、Cでプログラムを書いたら、20MhzのPIC16F873で それらの計算には 2.5ms程度で可能なようです。

この方法だと、16個のサーボを同時に動かすことが出来るんじゃないかと思います。

Jinです。

コードを書いてみたのですが、変数領域が不足して、PIC16F873にはインプリメントできない感じです。
（始めに計算していないと言うのがばれてしまいますが）

ポートAとBに出力するパターンを用意しておくわけですが、イントラプトの分解能よりも細かい場合は
出力バターンを 配列に展開しておく必要があるのですが、単純に考えるとその部分のメモリーが
16bit * 16 * 8 とした場合、 256byte必要になり、その量だとPIC16F873では明らかに不足
16F876 か 16F877 ならば 368 Byteあるのでテーブルを作ることが出来るので、そのうち入手
してみたいと思ってます。

サーボの解像度を落として、イントラプトの解像度よりも細かくしなければ、メモリーに入りますが
その場合、イントラプト内の処理に8μs くらいかかるので、2ms を 8us で割ると、250程度の解像
度にしかならない様です。
あ〜、残念

">

> 16bit * 16 * 8 とした場合、 256byte必要になり、その量だと
> PIC16F873では明らかに不足

こういう事態には、このアプローチはPIC向きでないと、
あっさり頭を切り替え、
DSPの安いキットに乗り換えてしまうのはどうでしょう。
http://www.tij.co.jp/jsc/docs/dsps/dsk/c3x_info.html
http://www.tij.co.jp/jsc/docs/dsps/dsk/c5x_info.html
C言語は付いてませんが、アセンブラや、デバッガー、
ハードウエアと資料集が付いて、9,980円と言うのは驚異的価格です。
私は、しばらくこれに嵌って、エコーマシンとか、codecで遊びました。

シングルチップではありませんが、I/Oの接続は簡単です。

どうも〜、mac さん

> こういう事態には、このアプローチはPIC向きでないと、
> あっさり頭を切り替え、 DSPの安いキットに乗り換えてしまうのはどうでしょう。

ですよね。 ついつい１つ覚えると、同じ手法で何でも解決してしまおうとするのが良くないですね。

> http://www.tij.co.jp/jsc/docs/dsps/dsk/c3x_info.html
> http://www.tij.co.jp/jsc/docs/dsps/dsk/c5x_info.html
> C言語は付いてませんが、アセンブラや、デバッガー、
> ハードウエアと資料集が付いて、9,980円と言うのは驚異的価格です。

いや〜、欲しいです。 代理購入お願いできますか〜？

> 私は、しばらくこれに嵌って、エコーマシンとか、codecで遊びました。

お〜、なんだか、凄い、レベルが違いすぎますね。 でも面白そうです。

しかし、サーボモーターのコントロールからDSPに行ってしまうと
なると凄い展開になってしまいそう。 でも、勢いでやってしまうほうが後々いいかな。

アッセンブラを使うのであれば、SCENIX-SXでアッセンブラで書くというのも、50Mhz
で動けばそれもいいかな〜 なんても思います。

> シングルチップではありませんが、I/Oの接続は簡単です。

さっそく、DigiKeyで通販で購入できそうなものをみると、 TMS320F241FN あたりは
PLCC だし FLASHもあるようですね。 プログラムの書き込みもJTAGだから、以前作った CPLD用が
使えるかもしれないですね。
あと、一番の問題は、自分にスキールがあるかどうかですね。（涙）

どうも、mac さん

> C言語でカリカリチューンして、どの程度までいけたでしょうか？

Cでの書き方にもよるみたいなんですが、たとえば、
変数 nTimerCount と gServoCurPosOut[0x00] は short integer なんですが、
それを比較した、サーボが繋がっている対象の Bit を Off にするこーどで

何も考えないで書くとこんなコードが出てきます。
(なお、CCSで 16bit のIntegerは long で定義です）

0000 00849 ...............if ( nTimerCount > gServoCurPosOut[0x00] ) PORT_B.bServo00 = 0;
0186 0854 00850 MOVF 54,W
0187 023B 00851 SUBWF 3B,W
0188 1C03 00852 BTFSS 03,0
0189 2992 00853 GOTO 192

018A 0854 00854 MOVF 54,W
018B 023B 00855 SUBWF 3B,W
018C 1D03 00856 BTFSS 03,2
018D 2993 00857 GOTO 193

018E 0853 00858 MOVF 53,W
018F 023A 00859 SUBWF 3A,W
0190 1803 00860 BTFSC 03,0
0191 2993 00861 GOTO 193

0192 1006 00862 BCF 06,0

それを、short integer を、2 byte の構造体にして定義して、下記のようなコードにすると

0000 01049 ..if ( nTimerCount.TMR1H > gServoCurPosOut[0x00].TMR1H ||
0000 01050 ..nTimerCount.TMR1L > gServoCurPosOut[0x00].TMR1L ) PORT_B.bServo00 = 0;

01F6 0854 01051 MOVF 54,W
01F7 023B 01052 SUBWF 3B,W
01F8 1C03 01053 BTFSS 03,0
01F9 29FE 01054 GOTO 1FE
01FA 0853 01055 MOVF 53,W
01FB 023A 01056 SUBWF 3A,W
01FC 1803 01057 BTFSC 03,0
01FD 29FF 01058 GOTO 1FF
01FE 1006 01059 BCF 06,0

13 word かかったのが 9 word まで小さくなりました。

いま、書いているコードは、Timer1と I2Cのイントラプトなども入れているのですが、
それらを取って、ぶん回すように変えたほうがよいかと思っています。

> Cであれにどこまで迫れる／追い越せるか、
> 大変興味があります。decfszの後ろに、
> goto以外の命令をおいてくれるような、
> 最適化ができるようなら、私もぼちぼち、
> PICをC言語でプログラムして見ようかなあ。

goto 分などの、ジャンプがどちらに沢山行くかなどを予測できるのは
まだ、人間の方が上（限定した条件では）だと思いますので、人間の
ハンドオプティマイズされたコードの方がやっぱり上だと思います。

でも、Cで楽したいんですよね〜自分は (^^)

">

> 0000 01049 ..if ( nTimerCount.TMR1H > gServoCurPosOut[0x00].TMR1H ||
> 0000 01050 ..nTimerCount.TMR1L > gServoCurPosOut[0x00].TMR1L ) PORT_B.bServo00 = 0;
>
> 01F6 0854 01051 MOVF 54,W
> 01F7 023B 01052 SUBWF 3B,W
> 01F8 1C03 01053 BTFSS 03,0
> 01F9 29FE 01054 GOTO 1FE
> 01FA 0853 01055 MOVF 53,W
> 01FB 023A 01056 SUBWF 3A,W
> 01FC 1803 01057 BTFSC 03,0
> 01FD 29FF 01058 GOTO 1FF
> 01FE 1006 01059 BCF 06,0
>
> 13 word かかったのが 9 word まで小さくなりました。

でもやっぱり無駄なgotoがでますよね。

MOVF 54,W
SUBWF 3B,W
BTFSC 03,0
BCF 06,0
MOVF 53,W
SUBWF 3A,W
BTFSS 03,0
BCF 06,0

にしてくれると、条件によって、実行時間が変わらず、
しかも1 step小さくなりますね。
まあC言語の仕様で、if (A || B)の場合、Aが真だと、
Bは実行しない規約を守らないので、いんちきなんですが、
この場合同じ動作になりますね。

if 分を使うと GOTOがどうしても出てきてしまうのが CCSのようです。 今回は条件が成立したときに
実行される分は １WORDで書けるものなので、 mac さんの ハンドオプティマイズされたコードの用に
はならないですね〜。

たとえば、IF分を使わないで
PORT_B.bServo00 = (nTimerCount > gServoCurPosOut[0x00]);
見たいなコードも考えられるんですが、Cの中で IF 分は有りませんが実際のコードをみると

0275 0854 01194 MOVF 54,W
0276 023B 01195 SUBWF 3B,W
0277 1C03 01196 BTFSS 03,0
0278 2A83 01197 GOTO 283
0279 0854 01198 MOVF 54,W
027A 023B 01199 SUBWF 3B,W
027B 1D03 01200 BTFSS 03,2
027C 2A81 01201 GOTO 281
027D 0853 01202 MOVF 53,W
027E 023A 01203 SUBWF 3A,W
027F 1C03 01204 BTFSS 03,0
0280 2A83 01205 GOTO 283
0281 1006 01206 BCF 06,0
0282 2A84 01207 GOTO 284
0283 1406 01208 BSF 06,0

となりますからあんまり意味ないし。

>まあC言語の仕様で、if (A || B)の場合、Aが真だと、
> Bは実行しない規約を守らないので、いんちきなんですが、

もともとの、コードは その規約を考えて、変数をわざと構造体として定義して、 byte 単位で
比較するようにしたのですが、 true と false の時の実行時間の差と言うのがやはり大きな問題
になるんですよね〜。
その意味でも、mac さんのハンドオプティマイズされたコードで、 true と false の時の実行スピード
が変わらないのは素晴らしいですね。

今までパソコンでマルチスレッドで動くソフトなんかを作りなれている自分だったので
こういったマイコンでのプログラムをしていると、考え方を変えて、１つの大きなループの
中で、タイミングを見ながら、それぞれの操作をしていくようなプログラムの書き方の方が
限られたリソースの中で有効なコードになるんだな〜と感じますね〜。

ソースが長くってスミマセン。 場所ふさぎでしたら削ってください > Jinさん。 分解能を稼ぐために、こんなことをやってみました。

macチューンの Spine 2の PWM出力部を 分解能 6ビットから 9.5ビットに
拡張、全部で16軸までコントロール出来るようになりました。 Spine 3 は
及第点がもらえますか？ ＞ macさん （過去ログが懐かしくて ^^)

下のリンクと一緒に見てもらえると何とか解ってもらえると思いますが、
分解能を稼ぐためにカスケード様のループをさせています。

http://www.geocities.co.jp/Technopolis/5834/p64.htm




MOVLW 0x00 ; PORTB = ALL LOW
MOVWF PORTB ;

CLRF pwmloop
DECF pwmloop,F

loop0 BTFSC pwmout0h,1
BSF PORTB,0
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
DECFSZ pwmloop,F
GOTO loop0

DECF pwmloop,F

loop1 BTFSC pwmout1h,1
BSF PORTB,1
BTFSC pwmout0h,0
BSF PORTB,0
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
DECFSZ pwmloop,F
GOTO loop1

DECF pwmloop,F
BSF PORTB,0

loop2 BTFSC pwmout2h,1
BSF PORTB,2
BTFSC pwmout1h,0
BSF PORTB,1
NOP
NOP
NOP
NOP
NOP
COMF pwmout0l,W
SUBWF pwmloop,W
SKPNZ
BCF PORTB,0
DECFSZ pwmloop,F
GOTO loop2

DECF pwmloop,F
BSF PORTB,1

loop3 BCF PORTB,0
BTFSC pwmout3h,1
BSF PORTB,3
BTFSC pwmout2h,0
BSF PORTB,2
NOP
NOP
NOP
NOP
COMF pwmout1l,W
SUBWF pwmloop,W
SKPNZ
BCF PORTB,1
DECFSZ pwmloop,F
GOTO loop3

DECF pwmloop,F
BSF PORTB,2

loop4 BCF PORTB,1
BTFSC pwmout4h,1
BSF PORTB,4
BTFSC pwmout3h,0
BSF PORTB,3
NOP
NOP
NOP
NOP
COMF pwmout2l,W
SUBWF pwmloop,W
SKPNZ
BCF PORTB,2
DECFSZ pwmloop,F
GOTO loop4

DECF pwmloop,F
BSF PORTB,3

loop5 BCF PORTB,2
BTFSC pwmout5h,1
BSF PORTB,5
BTFSC pwmout4h,0
BSF PORTB,4
NOP
NOP
NOP
NOP
COMF pwmout3l,W
SUBWF pwmloop,W
SKPNZ
BCF PORTB,3
DECFSZ pwmloop,F
GOTO loop5

DECF pwmloop,F
BSF PORTB,4

これを １バイト分繰り返して完了です。 同じ作業を２回行って
合計１６ビット制御出来ます。

どうも、Hirotaさん

いや〜、やっぱりアッセンブラにはかなわないですね〜。
CでTimer1とフリーランのループとの組み合わせで書いても、Hirotaさんほどの解像度がでないです。

I2CのスレーブモードをHardwareでサポートしてCで書けて、解像度が10Bitくらいで、１つのデバイスで
12チャンネル程度書ける、デバイスが欲しい今日この頃です。
CPLDを使えばかけると思うけど、マクロセルの数は相当必要そうですよね。 あ〜悲しい

どうも、Hirotaさん

Hirota さんのサーボモーターの分解能を７６７と同等のものを CCS で書こうと思い、いろいろ
挑戦したのですが、やはり、難しいですね.。 今のところ、330くらいの分解能まできていますが、
それ以上は C言語（だけ）では難しそうです。 インラインにするとまた、別ですが。
測定すると、5μS 弱の解像度ですね。

自宅にあるサーボを測定すると、1.5ms でニュートラルにきますが、最小と最大を測定すると
サーボにもよりますが、最小は 0.96ms 、最大が 2.5ms くらいまで振り切れないで行くようです。
それらの値を指定すると、大体180度くらい動かせますよね〜。
それで、1.64ms 程度 を 330の解像度にすると、大体 5μS 弱となります。

Hirotaさんのコードの解像度は 2ms を 767の解像度で動かしているんですよね、やっぱり
凄いオプティマイズですね。

どうも、Hirotaさん

やっと、C言語だけでも、 分解能が７６７くらいのものが出来ました。
まだ、I2C関連の受信がおかしくなることもある（電気的な問題かソフトの問題かは分からない）のですが
ニュートラルが、0x200くらいで、最大が0x400くらいで、動いてます。

ただ、連続して I2C のコマンドを発したときに、イントラプトの関連でどの程度 パルスが
乱れるか分かりませんが、
http://www.mi-ra-i.com/JinSato/MindStorms/Tawagoto/Images/ss-01.gif
に載せたイメージのソフトと連動させてみたいと思います。

結局、サーボの位置を示す変数は２Byteの大きさがあるんですが、
上位の８bit のループと、 下位の8Bit のループを分けることで１Byteの変数の比較で済むように
しました。 あとは、Timer1で 500μｓ単位にイントラプトをかけてタイミングを合わせるように
してみました。

しかし、時々I2Cが正しくコマンドを受けないのか謎です。 （涙） ココが確実じゃないと、ロボット
こけちゃいますからね。

> やっと、C言語だけでも、 分解能が７６７くらいのものが出来ました。
ひやー それは強烈です 0_0 最初っからコンパイラは考えてなかったし
アセンブラでも目一杯だと思ってたんですが。。

それにしても２０ＭｈｚのＰＩＣは強力ですね、F87だと考えもしなかった
使い方が出来そうですね。 シリアル通信がハードで出来たり A/Dがついて
いたりで。 イナストマーも ポートＡでそのまま読めそうですしね。
ちなみに注文したのは $6.00US / １個です。

">

> >  やっと、C言語だけでも、 分解能が７６７くらいのものが出来ました。
 
なんか凄いことになってきましたね。
8bitを超えるカウントでも、基本は、
decfszを使って、
L1
   decfsz cntL
   goto L1
   decfsz cntH
   goto L1
の形に持ち込み、cntH/Lにセットする数値を、
あらかじめ、うまく計算しておくのが、
ASMでは、最短になるんでしょうね。

while(n--);
の形だとnの修正がASMを見てからでないと、
できないと言う問題がありますが...

どうも、mac さん

> なんか凄いことになってきましたね。
もう、執念でこだわって見ました。

> 8bitを超えるカウントでも、基本は、
> decfszを使って、
> L1
> decfsz cntL
> goto L1
> decfsz cntH
> goto L1
> の形に持ち込み、cntH/Lにセットする数値を、
> あらかじめ、うまく計算しておくのが、
> ASMでは、最短になるんでしょうね。

ですよね。

以前のループは、ループの中でIF分があるのが良くないので、IF文は外に出して、前もって
ループする数を計算してみました。

> while(n--);
> の形だとnの修正がASMを見てからでないと、
> できないと言う問題がありますが...

Cではこんな風になってます。
0000 01142 .................... i = gServoCurPosOut[2]._byte.lb;
0269 083F 01143 MOVF 3F,W
026A 00D4 01144 MOVWF 54
0000 01145 .................... while ( i-- );
026B 0854 01146 MOVF 54,W
026C 03D4 01147 DECF 54,F
026D 3800 01148 IORLW 00
026E 1D03 01149 BTFSS 03,2
026F 2A6B 01150 GOTO 26B

まだ、ちょっと無駄も有るんですが、0x000〜0x400 位での位置指定はできるようなので、満足してます。
アッセンブラで書くと、0x000〜0x480くらいまではいけるんじゃないかと思います。

ただ、この方法は、途中でタイマーのイントラプトが入ったり、I2Cのイントラプトが入ると、パルスの波形が
乱れる可能性が高いのが問題で、I2Cのコマンドを連続的に出す別のPIC16F873を付けて実験して
見たいところです。

ども。 macさんが見てると思うとちょっときんちょーします ^^;

20Mhz動作の 15インストラクションでループさせていますから 3μsecの
分解能になってますね。 （組んだ後で nopで幅を合わせたのをさっき
数えました ^^;)

と書いて Jinさんのクロックは？ と、 ひょっとして分解能が良いのは
クロックが速いからだったりして。。

> でも、このあたりの勝負になると、SCENIX-SXに乗り換え、
> 50MHzに上げると、速度は一気に１０倍になり、
これ良いですね。 USERTが入ってるのがあると夢の 10ビット分解
能に手が届きますね。

ところでっ。 Jinさんも ”歩こう”としてますよね −
こんなの興味ありませんか？ -> http://www.inaba-rubber.co.jp/katarogu/inast/inast.html

アメリカの販社に今日発注しました。 サンプルもおねだりしたので
rtl9に持っていきます。

どうも〜、Hirotaさん

> 20Mhz動作の 15インストラクションでループさせていますから 3μsecの
> 分解能になってますね。 （組んだ後で nopで幅を合わせたのをさっき
> 数えました ^^;)

やっぱ、Hirotaさんのは無駄がないから早いですよね。

> と書いて Jinさんのクロックは？ と、 ひょっとして分解能が良いのは
> クロックが速いからだったりして。。

自分は20MHzの16F873です〜

> > でも、このあたりの勝負になると、SCENIX-SXに乗り換え、
> > 50MHzに上げると、速度は一気に１０倍になり、
> これ良いですね。 USERTが入ってるのがあると夢の 10ビット分解
> 能に手が届きますね。

そうなんですよね。 USERTだったら、9600くらいだったら、自前のルーチンでも余裕でOKだと
思います。

> ところでっ。 Jinさんも ”歩こう”としてますよね −
> こんなの興味ありませんか？ -> http://www.inaba-rubber.co.jp/katarogu/inast/inast.html

あります、あります。 よく見つけられましたね〜。
ゴム材成形カバードーム型タイプ とか 樹脂モールド成形カバー なんかいいですね

> アメリカの販社に今日発注しました。 サンプルもおねだりしたので
> rtl9に持っていきます。

お〜凄い。 ところでアメリカの販売会社ですか〜良かったらお教えいただけると嬉しいな〜。（＾＾）

> お〜凄い。 ところでアメリカの販売会社ですか〜良かったらお教えいただけると嬉しいな〜。（＾＾）

ここです -> http://www.cuistack.com/

日本だとツクモロボコンマガジン館にあるみたいですね。

http://www.rakuten.co.jp/tsukumo/435950/450853/

Hirota さんへ
どうもです。 早速 自分も Quoteのリクエストを送ってみました。
１つ、数ドルだったらいいな〜。 個人的には IESP12 の方が配線が楽かな〜なんて
思いました。

">

> 測定すると、5μS 弱の解像度ですね。

私が、
http://207.236.16.161/JinSato/MindStorms/HW/BBS/hw_41.html
の541番の記事で書いたものは、8ch同時に4MHz 16F84で22μs、
20MHzに上げれば、4.4μsになりますね。

でも、このあたりの勝負になると、SCENIX-SXに乗り換え、
50MHzに上げると、速度は一気に１０倍になり、
0.44μsの分解能になります。
http://www.akizuki.ne.jp/ashop/scenix.htm

PICとは、asmレベルでは互換性があるので、
PIC用のC言語でもasm出力をちょっとしたフィルターにかければ、
動かせるとか...

高級言語には、高速CPUが良く似合うような気がしますね。

どうも、mac さん。

お付き合いありがとうございます。

> > 測定すると、5μS 弱の解像度ですね。
>
> 私が、
> http://207.236.16.161/JinSato/MindStorms/HW/BBS/hw_41.html
> の541番の記事で書いたものは、8ch同時に4MHz 16F84で22μs、
> 20MHzに上げれば、4.4μsになりますね。

ですね〜。 正確に測定したわけじゃないですが、自分のCのコードでも、１２ｃｈで 4.7μs くらいまで
行くんですが、それ以上を狙うと辛いですね。

> でも、このあたりの勝負になると、SCENIX-SXに乗り換え、
> 50MHzに上げると、速度は一気に１０倍になり、
> 0.44μsの分解能になります。
> http://www.akizuki.ne.jp/ashop/scenix.htm

いや〜、10倍なんて魅力だな〜。 これで、I2Cのスレーブのハードウエアが オンチップであったら
引越ししちゃいそうです。 AVR や他のマイコンも見たんですが、 I2Cのスレーブモードになれるのは
それほど多くないですね。 H８ Tiny なんかも有るみたいですが、16Mhzだしな〜。 .... （辛）

今のところ、分解能は低いんですが、I2Cバスに7個くらい付けられるので、７ｘ１２で 最高84個のサーボ
をコントロールできるのが美味しいところなんですが。 （＾＾）

ところで、今のコードは基本的に下記の様になってます。

pos がサーボの位置

bit on;
count = 0;
while ( count < max_count ) {
if ( count > pos ) bit off;
count ++;
}

見たいな書き方な訳ですが、C言語的には無駄もあまり無いのですが、もう少しぎりぎりまで
性能を狙うと
bit on;
count = 0;

while ( pos - count >= 10 ){
count += 10;
wait( x );
}
count -= pos;
switch( count ) {
case 9: nop;
case 8: nop;
case 7: nop;
case 6: nop;
case 5: nop;
case 4: nop;
case 3: nop;
case 2: nop;
case 1: nop;
case 0: bit off;
}

こんな書き方も有るかなと思ってます。 まだ、実際に書いて比較はしていないんですが。
（switch で break 文を入れないで、だらだら流す方法です、コンパイラによってはまともなコードを
ださないかもしれませんが）
もっとも、引き算とか、比較とかの部分のオーバーヘッドが増えるような気もするけど。

> 高級言語には、高速CPUが良く似合うような気がしますね。
まったく。 PICも40MHzくらいで動いてくれると嬉しいな。

CPLD で作ってもいいかな〜とも思うんですが、12チャンネルのサーボで、分解能を1024に
持ってこようと思うと マクロセルが随分ないと作れないと思うと、手持ちの部品ではだめそうなん
で諦めてます。 （涙）