koheiのおもちゃ修理記録

宇部おもちゃ病院 毎月第2土曜日 13:00~16:00
宇部新天町の西の端、市民活動センターで開院してます。

4/3 リワークステーション買ってしまいましたw

2023-04-03 | PIC・電子工作
直りそうにないNINTENDOのSWITCH Liteについて調べてたら、ハンダごてでは取り外し困難or不可能なUSB-CコネクタやQFPをヒートガンでやすやすと外して取り替える人達の動画が出てて、悩んだ末に、リワークステーションを買ってしまいましたw。

最初はヒートガンを買おうかと思ってたのですが、ネットで調べると中国製の安いリワークステションを買ってレビューを詳しく書いてくれてる人がいて、なんか良さそう。YIHUAの「959D」というリワークステーションです。
お勧めの密林で7,999円で、ちょっとした小物もセット(AMTECHのフラックスは別買い)。Aliも調べたけどドル高で安くないので、密林から買う事にした。

先週の水曜日に注文して2日後には到着。(さすがプライム砲w)
早速日曜日に使ってみました。
デジタル顕微鏡で映しながら動画も撮ろうとすると、コタツの上が一杯に…w。

動画撮らなければ、まあそこまででもないかな…。

練習で廃家電の基板から、SOT-23、SOP-8と外して、また付けて、としてみたのだけど、一番最初はいまいちうまくできなかった。デジタル顕微鏡がボロなせいか、動画もうまく撮れなんだw。
国産家電の基板は鉛フリーハンダかもしれません。温度設定を440℃まで上げて、最後にSSOPの外し・付けをやってみます。

これはもう、完全にはんだごてでは不可能ですね。拡大静止画ではこんな。

一番細いコテ先とφ0.3mmの糸ハンダと比べてみて下さい。ピッチが0.65mmなので、足の幅がほぼ糸ハンダと同じ、足と足の間もほぼ糸ハンダと同じ、といったサイズですね。デジタル顕微鏡を見ながらでも、はんだごてでリフローするのは非常に困難です。

外すのはあっという間でした。動画撮り損ねましたが「フワっ」と浮いたようになって簡単に外れました。
再取り付けは動画撮れました。「セルフアライメント※」がバッチリ撮れました。

※セルフアライメント:部品のセットが多少ズレてても、ハンダが溶融するとハンダの表面張力で引っ張られて、勝手に正しい位置に部品が動いてくれる現象w
加熱が均一じゃないせいでか、一発で定位置に来ませんでしたが、最終的には正しい位置に落ち着きました。
手ハンダではSSOPのハンダ付けは非常に困難ですが、ホットエアーで楽ちんちんですw。(足が多めの方がセルフアライメント効果が大きくてより楽になる気がするほどです。)
ボクは右利きで、右手にガン・左手にピンセットで撮ってますが、逆で慣れた方がいいだろうねぇ…。

再取り付け後の静止画:

ちょっとハンダが薄い気もしますが、元と区別がつかないレベルです。(今回は単なる練習なので、確実な導通も動作もどうでも良かったのですが、本チャンは熱かけながらちょっとプレスした方がいいかもしれませんね。)

さて、おもちゃ修理で使う機会があるでしょうか…。表面実装で放熱板付きの三端子レギュレータだと、ハンダごて2丁持ちでも外すの大変なので、これ使った方がいいかもしれませんが…
そもそも、どこを目指すのw?

おもちゃ修理に必要な技術・知識の幅、仕事の範囲は非常に広い。
他の人に説明するのに「トラブル・修理は割合的に、機械:3分の1、電気:3分の1、電子:3分の1」と説明するようにしてる。
 機械:骨折とかギアの割れとかの機械的故障
 電気:電池・電池端子・配線・スイッチ・モータ等の電気的故障
 電子:基板・電子部品や回路不良による動作不具合等の電子的故障
まあ「電気」の範囲はそんなに広くないかもしれないけど、「機械」の範囲は出来ない事や必要な道工具がまだまだある。旋盤もフライスも欲しいし、最近は3Dプリンタをおもちゃ修理に使う人も多い。やるべき事も道具もまだまだ果てしない…。
一方「電子」の範囲は、PIC換装もまだ「やった事がある」レベルで、パパっとすぐには出来ない。回路もプログラミングもまだまだ知識が足りず、勉強・習得すべき事はまだまだ果てしない…。いくら時間があっても足りないw。

メンバーの多いおもちゃ病院なら、機械の得意な人・電子の得意な人等で分業すればいいのだろうけど、ウチの現状だとそうもいかず、出来る事は全部自分で出来るように、「修理可能」の範囲を広げていかなければならない。

今回は、SWITCH Liteの修理をきっかけにリワークステーションを買ってみたけど、動画探してたら、SWITCHの40PINのQFPパッケージ電源管理IC「M92T36」、非常に故障の多いデバイスだそうだけど、「これの取替が出来るなら修理屋さんになりなさい!」との事。
見た海外動画の人達みたいに、QFPやCPUがサクサク取り替えれるような電子基板のプロになるつもりはないんだけどねぇ…。
ま、とりあえずSWITCH Lite修理にチャレンジしてみますか~w。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

11/28 ハンダ吸取器とステーション型ハンダごて買いましたw

2021-11-28 | PIC・電子工作
プリモプエルの修理で、かなり高頻度でハンダ付けしてます。これはもう、アマチュアの域を超えてるのじゃないかしら…。という事で、もうちょっと道具にお金を使ってもいいか?という事で、ポンプで吸い取る「自動ハンダ吸取器」と、ステーション型のハンダごてを買う事にしました!
という事で、到着!

HAKKOの自動ハンダ吸取器:FR-301と、ハンダごて:FX-888Dです。(右下に写ってるのは、今まで使ってたHAKKOの温調ハンダごて:FX-600です。)

温調ハンダごては、おもちゃドクター始めてしばらくして買ったのですが、非常に使いやすいです。普通のハンダごてだと、十分に温まるまで3分以上掛かりますが、温調ハンダごてはワット数が高い(FX-600は50W)し、こて先の近くまでヒーターが入ってるので、1分以内で使えるようになって非常に便利です。
こて先は「2C型(T18-C2)」を買い足してます。これは、FX-600を買った時に、(どこのショップか忘れましたが)たまたまマニアックなショップで、「絶対C型が使いやすい!」と力説するC型こて先推しで、2C型を付けて売ってたのですが、これが「当たり」です。もう普通の鉛筆型のこて先は使う気がしませんw。
1.25ピッチの狭いICの足やチップ部品の再ハンダ付けには、先端の角を使います。電池BOX端子の様に熱容量が高い箇所には、カットの「面」を使うと、高出力・高速復旧と相まって、昔使ってた30W電子工作用のハンダごてとは比べ物にならないぐらいちゃんと溶けてくれます。
HAKKOのハンダごてを使うなら、是非「2C型」をお勧めします!

さて前置きが長くなりましたが、まだ前置きw。
今まで、簡易吸取り器:通称「スッポン」を酷使してきましたが、ハンダごてと吸取器と両手を使うので、小さいスイッチ基板を逆作動ピンセットで咥えて、そのピンセットをラジペンの柄で押さえて、さらにそれに糸ハンダを重しにして、「スッポン!」と吸うのですが、

この「スッポン!」の衝撃で、基板が飛んでってしまう事が多いんです…。こてを当てながらなんとか隙間にノズルをできるだけ密着させて押し付けるので、どうしても反動が出ちゃうんですよね。

リード線ハンダ付け部のスルーホールランドの吸い取りも厳しいです。

ランドが小さいので、裏からランドに熱掛けながら、表からスッポンで吸い取りますが、裏も表も見えないのでやりにくいです。

やっと本題ですw。早速使ってみました。

説明書には「ランドではなく、リード線とはんだを加熱する様に心がけて下さい。ノズルを直接ランドに当てるとランドが剥離する恐れがあります。」と書いてあるのですが…、そんな0.1mm単位の微妙な押し付け調整は無理です…。ハンダの山にノズルを押し付けて、ハンダが解けたらノズルが下に下がる。下がったらボタンを押して吸引します。
(スイッチ取付けのスルーホールは、反対側の吸いが悪かった。裏まで溶けるまで数秒待ってから吸った方が良さそうです。)
リード線ハンダ付け部も吸い取ります。上の写真で見えてる面は、ハンダが乗ってないのでやりにくい。裏返してハンダの乗ってる方から吸えば吸い取れました。

吸い取った後はこんな感じ。

タクトスイッチの足は、広めの状態で基板穴に突っ込んであるので、外側に押し付けられたような状態になってます。その接触側でやっぱりハンダが切れてませんね。スッポンの時も同じでしたが、ここからハンダごてで足を押して、縁を切ってやる必要がありました。
まあ「吸っただけで一発で取れる!」という程ではありませんでしたが、少なくとも「しょっちゅう基盤が飛んでく」は解消されますw。

ちょっと難易度の高い物も吸ってみました。

スルーホールで付けられた電化製品のピンヘッダとコネクタを吸ってみます。

う~ん、いまいちです。無鉛ハンダで融点が高い心配があったので、温度設定上げて吸ってみました。途中で吸いが悪くなったのでノズルを掃除してみたりしましたが、ピンヘッダの方、コネれば取れるほどには吸い取れませんでした。コネクタの方は取付足のピンがノズル穴径より太いのもあって、ちゃんと吸えず。信号ピンの足もやっぱりいまいちですね…。
ノズル・フィルタの掃除をどのぐらいの頻度でしないといけないか、フィルタのモチはどうか等、もう少し様子見ですね。

そうそう、ステーション型ハンダごてのレビューを忘れてました。
元々の温調ハンダごて:FX-600が十分使いやすいのであまり期待してなかったのですが、まあまあ使いやすいです。70Wのおかげか、立ち上がりはFX-600より早い気がします。ステーションに温度が出るので、見てればいつ使い始められるか一目瞭然です。重量が軽いしコードもしなやかなので、手元が軽いです。
今回「コテ台」も期待してました。ずっとスポンジ式のクリーナを使い続けてますが、「ワイヤー式のクリーナってどうなんだろう?」と思ってました。

温調の無いハンダごてでは、ほっとくとコテ先が400℃以上とかに過熱してしまうので、水で濡らしたスポンジで「ジュッ」と温度を下げながらハンダ付けする必要があります。(有鉛ハンダのハンダ付けは340~350℃ぐらいでよく、それ以上上げるとヤニが飛ぶのが早くなって付きが悪くなるし、ハンダの酸化も進みます。)
温調ハンダごてだと「ジュッ」と温度を下げる必要はないので、ワイヤー式のクリーナでいい。また、コテ先に急激な温度低下を与えないし、蒸気によるコテ先悪化も無いので、温調ハンダごての場合はワイヤー式の方がいいらし、という情報があったので、気になってました。
で、ワイヤー式のクリーナを使ってみたのですが…、今のところスポンジの方がいいなぁ…w。コテ先があまりキレイにならない。また、今回のコテ台に付いてるヤツは底が浅いので、あまり強く突っ込むとコテ先が底に当たってしまう。まあ、これももう少し慣れるまで使ってみるかなぁ…。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

2/11 フリスクケース電子工作~第1弾:RFチェッカー

2021-02-14 | PIC・電子工作
さて、プリモちゃんと格闘する前、「フリスクケース電子工作」で格闘してましたw。

世の中に「フリスクケース電子工作」という分野があります。(←あるのかw?)
電子工作愛好家は、100均とかでちょっとした文房具(クリップとか)の入れ物みたいなケースを見ると「何を入れよう…」とワクワクします。(←みんなするかなw?)
そんな中でも、「この小さなフリスクのケースに何を詰め込もうか…」という電子工作ですね。

今回初チャレンジは、以前にちょっと大きめのお菓子ケースに入れて作ったRF&赤外線信号チェッカーを、フリスクケースで作り直します。

左が以前に作ったもの。スライドSWで切り替えて、RFと赤外線とを切り替えれます。
これを、右のフリスクケース版に作り直します。

元の中身はこんな感じでした。

アンプは使った事のあるLM386でした。だいぶ前に作ったので、空中配線が多くて見苦しいです…。今ならもう少しきれいに作れるかも。
先輩おもちゃドクターから頂いたRFユニットは3V指定だったのですが、LM386が4V以上必要だったので、5VのACアダプターを繋いで使う仕様になってます。

それをこの度、電池式にしようかと思ったのですが、最終的に結局ACアダプター式になりました…。
最初電池式で行こうと思ったので、秋月で50円程度でなるべく低電圧で動くアンプを探して、NJM2113Mというアンプを買ってみたのですが、これが…どうだったでしょう…。
小さく作ろうとSOPタイプを買ったのですが、標準回路でちょっと分からない所があってブレッドボードで確認したので、結局SOP→DIP変換基板を使ってしまいました。
ブレッドボードで確認したところ、あまり大きな音が出なかったので、結局電源電圧アップの為にACアダプターにしてしまいました。

標準回路はこうなってます。(転載禁止かな??)

「C1が十分大きい時はC2は不要」とありますが、「十分大きいってどんくらいなん?」「不要ならどう繋ぐ?」と疑問がいろいろ…。(どうもこのICメーカーさんのデータシートは、今一つ不親切な気がする…)。
このC1・C2は「電源電圧変動除去率」とやらに効くらしいですが、今回の使い道からすると音質はどうでもいいw。とりあえずC1は10μFにしてC2なし。C2なしの場合は、PIN2はNCでよさそうです。
PIN1のパワーダウン入力は、プルダウンされたNPNに入力されてるとの事なので、パワーダウンを使わない場合はNCでいいと思われます。(実機工作は、GNDラインの取り回しの都合、GNDに落してます。)

これで回路を検討して、基板レイアウトを散々悩んでから、ケースの加工・ユニバーサル基板の加工をします。

配置はこんなになりました。スピーカーは薄型を使おうと思ってたのですが、同じ音源で鳴らした時に普通のヤツの方が大きな音が出る。おもちゃで一番よく使うφ29mmのヤツがキリキリ入りそうだったので、基板に穴をあけてスピーカを配置します。
ACアダプタージャックは、用済みの基板用が1個あり、寝かせばちょうどケース深さ(9mm)にぴったりだったので、基板をきっちり切ってはめ込んで固定します。

めんどうなので回路の詳細は省略w。途中改造して、最終の基板はこんなになりました。

前回作ったRFチェッカーは、空中配線が多くて見苦しかったので、今回はなるだけビニール線を使わないように工夫しました。スピーカの周りに回ってるのは、RFユニットのアンテナ線なのでしょうがないですが、それ以外は3本しかビニール線を引いてませんw。

裏はこんなです。

基板裏はぎゅうぎゅうですw。万能基板じゃなくてプリント基板を作れば、もっと美しくできるんだろうけどね~。(まあ一旦作ってから回路変更もしたから、万能基板の方がいいこともあるけどね~。)

最初に作った後、ちゃんと動きませんでした…。ボリューム上げ下げしても、音量がちゃんと操作できない。アンプICが触れないぐらい熱くなってる。これって異常発振かしら…?
ボリュームの前(RFユニットor赤外受光モジュールとボリュームの間)に入れてたカップリングコンデンサ:1μFを、ボリュームの後ろに変更。(LM386の時はそれでもちゃんと動いてたのですが…)
オシロで当たったら異常発振はしてないようでしたが、電源ラインに0.1μFのパスコン追加(「電源リップルが多いと発振しやすい」という記事があったので)と、出力に通称「Zobelフィルタ」として(0.1μF+10Ω)×2を追加して、最終となりました。
それでも結局、ICはかなり熱くなります。まあ「指で触れないぐらい」=多分80℃くらいかな…。「そういうもんだろう」と思う事にしますw。(定格上の動作温度は、Max75℃と書いてありますね…。)

ケース加工も基板切り出しもなかなか大変でした。出来上がりはこんな見た目になりました。

まあまあ格好よく出来たかな~。
(「フリスクケース電子工作」の皆さんは、ケースのラベル(シール)をそのままで加工してる人も多いようですね。ま、穴もあけるしこれでいっか~w)

そもそも電池で動かそうと選択したICだったのですが、結局ACアダプターで動かすなら、元のLM386で良かったなぁ。まあ、熱でケースが変形したりしない限り、とりあえずこれで使ってみようと思いますw。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12/6 デジタル顕微鏡 購入レビュー

2020-12-06 | PIC・電子工作
最近のおもちゃは、ほぼ「コンピュータ」な物も多いのですが、ピッチの細かいICのハンダ付けに困ってました。
以前に隣国から500円ぐらいで眼鏡タイプの拡大鏡(「5/11のつづき:DVDプレイヤー修理(断念)」で使ってるヤツ)を買ってみたのですが、焦点距離が近すぎて、ハンダ付け作業にはいまいち…。
「実体顕微鏡がいいよ」との噂だけど、まともに買うと10万円以上して手が出ない…。
拡大率としては、スマホ(ぼくのはiphoneSE)のデジタルズーム最大ぐらいの大きさでいいんだけど、適度な固定や、ハンダこてが当たって欲しくないとかで、スマホを使う訳にも…。

という事で、11/11のビッグセールで、CCDカメラにLCDが付いた「デジタル顕微鏡」を買ってみました。
レビューついでに、約1年前に修理断念したディズニートイパッドの見直しをしてみます。

商品ページは下記。

セールを狙えば7,000円ぐらいですね。ディスプレイが4.3inchのが3,000円台であったのですが、ちょっと不安で、7inchディスプレイで、ディスプレイの角度が変わる、ちょっと高いヤツにしてみました。

3週間ぐらいで届いたかな?

ついでに同じショップから小物を買いました。
左からステップドリル:143円。電子工作してケースに入れる(あまりないけどw)時、DCジャックやオーディオジャックとかボリュームとかをケースに付けるのに、8mm~11mぐらいの穴をあけたい時がある。しかし、6mmより大きいと、ドリル刃も高いしハンドドリルでは咥えられなかったりして、今までヤスリで削って広げてた。ステップドリルは、ホームセンターで買うとかなり高い。Aliで3~13mmで1mm刻みのが安く売ってたので買ってみた。まあボロでしょうけど、プラスチックの穴あけなら使えるでしょう。
2番目はドリルチャック用のボルトなんだけど、寸法考えずに買ったら失敗した…。
3番目はジャンパーピン。ちょっと5~6個欲しかったんだけど、秋月で25個100円。今回Aliで買えば100個で53円。絶対にそんなに使わないんだけど、安いのでつい100個w。
4番目は電池端子。今までaitendoの10ペアで100円の端子を使ってたのだけど、結構よく出るので、補充で買ってみた。50ペアで120円なのでお得w。サイズがはっきりしなかったけど、aitendoの単3用と単4用の中間ぐらいの大きさでした。まあ、単3の取替の時に横幅がオーバーで切って使う事が多かったので、多分ちょうどいいくらいでしょう。
11/11セールとセールクーポン使いまくって、全部で6,780円(明細見たら、クーポンで$11も安くなってたw)。セール価格でデジタル顕微鏡買ったら、後はおまけがついてきた、みたいな感じw。

さて、本題のデジタル顕微鏡です。まず開封写真。

英・中2カ国語の取説。CDついてますが、パソコン用ソフトはメーカーサイトからダウンロードできました。
左上の銀色の丸いのは、取説にも何も書いてませんでしたが、カメラの透明カバー部分を外して付け替えれます。

まったく「組み立て」と言う程の作業でもなく、組み立てて使ってみるw。
まず、ガイドのほぼ一番上の位置でピントを合わせた状態。

これで、カメラ保護カバー下端と基板との間が40mmぐらいあいていて、ハンダこてを入れるスペースは十分ありそう。

次に、保護カバー下端と基板とを25mmぐらいまで近づけた状態。

次いで、15mmぐらいまで近づけると、かなり大きく出来る。


これで、ディズニートイパッドの再ハンダ付け失敗したSSOP10のICの確認をしてみる。
USBケーブルで繋いで、パソコンで見れる(パソコンに繋いでる間は、本体の液晶に画像は出なくなる。)
パソコンの画面で見ても、表示にあまりタイムラグはない感じ。パソコン上だと2倍のデジタルズームがあるので、もしかしたら本体の液晶より使いやすいかも。
(という事は、液晶無しでカメラ&スタンドだけのタイプでも良かったのかも?)
以下の画像は、パソコンに直接落したもの。ブログ記事用の写真には便利!

しかし…、SSOP=0.65mmピッチと思ったのだけど、定規当ててみると、0.65mmよりもピッチが細かい…。

(SOPと思って)間違えて買った0.65mmピッチのICがあったので、並べて撮ってみる。

やっぱりピッチがだいぶ細かいわ~。多分0.4~0.45mmぐらいのピッチだなぁ。これは、裸眼での手はんだ付けが厳しかった訳だわ~w。

これで、このデジタル顕微鏡使ってハンダ付けのやりなおしにチャレンジしてみる。
HAKKOの多分一番細いI型こて先と0.3mmの糸ハンダで、このくらいのスケール。

非常に厳しい…w。コテ先を狙った足に当てるのはなんとかできるけど、立体感があまりないのもあって、狙った所に糸ハンダを当てるのはほぼ無理…。ハンダ補充しない単なるリフローか、事前にコテ先にちょっとハンダを乗せとけば、なんとかなるかなぁ…といった感じ。

これで、一番状態悪くしてしまったPIN10(右下)を何とかしようとした結果、

う~ん、このぐらいが限界。はしっこだから何とかなったけど、途中の足はもっと厳しいなぁ。

開封の所で書いた「銀の丸いの」は、レンズ保護の透明カバーを外して付け替えれる。透明カバーのままだと、本体のLEDの照射が強くてハンダが光って見にくくなるが、この「銀の丸いの」に付け替えると、拡散かな?色合いもいい感じになる。
こんな感じの作業になる。

まあ、SSOP=0.65mmピッチまでなら、なんとかハンダ付けできるかな。それ以上に細かいピッチの再ハンダ付けは、やっぱり「最後の手段」まで触らない方がいいなぁ。

さてこれで、TSOP10PINの足をマシにできたので、再度電池を入れてみるけど、やはりうんともすんとも言わない…。
液晶のバックライトへの電圧供給が、バックライト行きのラインが生きててLEDが付けば10V程度?ラインが切れてれば30V以上の電圧が出る、との事だが、約3.3Vの電源電圧が出てるだけ…。
近くにコイルがあるので、インダクタンスとFETでの昇圧回路で、液晶の明るさ調整もできるなら、電流監視して指示通りの電流になるようにFETのスイッチングを変えるんだと思う。
FETがスイッチング無しで切れっ放しだと電源電圧がそのまま出るので、つまり多分、メインのコンピュータが動いておらず、バックライトへの電圧供給もちゃんとできてない状態と思われる。
やっぱりダメか…。(まあ、1年前に預かって「ダメでした…」と連絡済みなんだけどね…。)

という事で、Aliで買ってみた7inchディスプレイ付きのデジタル顕微鏡、SSOP=0.65mmピッチぐらいまでなら、ハンダ付け作業に使えそう。(これはもう、拡大率の問題じゃなくて、手作業の限界w。)
QFPの足のハンダ付けの状態確認には便利そう。0.65mmピッチより細かい再ハンダ付けは、やっぱり厳しいかな、といった所でしょうか。
コメント (2)
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

11/29 8×8×8 LED Cube改造

2020-11-29 | PIC・電子工作
数年前に作った「8×8×8 LED-Cube」ですが、改善したいところ等もあったのと機能追加で、バージョンアップしましたw。
前の記事は3年前の「11/5 8×8×8 LED-Cube作りました」です。

とりあえず、見た目はこうなりました。

このLED-Cube、イベントの時のイルミネーションとして時々持って行ってたのですが、言ってみればこれは「ディスプレイ(表示機)」。せっかく苦労して作った表示機があるので、ちょっとしたゲームもできるようにしたら、もちょっと子どもたちの目を引くかな~と思って、スーファミのコントローラを繋いで操作できるようにしました。

ゲームとして、
・ランダムな位置にターゲットが出る。
・自分のドットを操作して、ターゲットに当てる。
・ターゲットに当たると、自分の長さが1ドット増えて、だんだんヘビの様に長くなっていく。
・長さが10まで行くと終了。
というゲームにしてみました。
とりあえず、「動画はこちら」から。(音も出るようにしました。ちょっと録画音量が小さいので、聞きたい人はボリューム上げて下さいw。)

ハードの前回から今回への改造点は、
①制御マイコンを、ルネサスエレクトロニクスの「GR-SAKURA」から、同じくルネサスの「RX621ボード」に変更。
②ケース変更
③基板配線整理(裏面ビニール線を全部表側に移した)
④スーファミコントローラ追加
⑤スピーカ追加(1-Trアンプ・ボリュームも追加)

それぞれ理由・背景は、
①ピンヘッダに安物ピンコードで刺してたボード→LED基板間の配線の信頼性が非常に低く、時々抜き差ししてやらないと接触不良を起こす。ハンダ付けしてしまえばいいけど、せっかくかわいいボードのSAKURAちゃんは、汎用として他の用途にも使いたい。
どのマイコンボード使おうか悩んだけど、秋月にクロックが同じ(96MHz)で同じルネサスのRX621ボードがそこそこの値段(2,700円)であったので、メーカ同じで移植もしやすいかも、と購入してみた。(このRX621ボードの詳細ついては「6/5 マイコンボードいっぱい買った②~RX621マイコンボード動作確認」を見てね。)
②ケースが微妙に小さくて、配線等に無理があった。(また、見えそで見えない微妙な半透明だったのもいまいちw。)
③底のないケースを使ってるので、裏面にビニール線で配線してると、被覆が傷んでショートの可能性があるかも。
④SWでコントローラを自作するより、市販ゲーム機のコントローラを使った方が早いかな?古いゲーム機の方が単純と思う。家にスーファミのコントローラが1個あったので、これにしてみた。
⑤ゲームなら、ちょっと音がした方が気分が出るかな?(周りの状況で必要な音量が変わるので、音量は調整できるようにした。)

さて、SAKURA→RX621への移植は、結論はあまり難しい作業ではなかったのですが、辿り着くまでかなりの時間を浪費しました。
移植前に久しぶりに動作確認すると、なんか表示がおかしい…。LEDの不良があると意図しない所が点灯してしまうので、LED不良を疑ってかなり長時間調べたけど、結局GNDラインにハンダ付け不良があって、そこそこ動くのに微妙にいまいちになってました。
それから移植後、sqrtを使ってる所の表示が変になって、いつも親切なルネサスのフォーラムに相談して皆さんにご迷惑をお掛けしましたが、randの使い方が間違ってて表示用配列の定義の範囲外に書き込みをしたせいでスタック?(sqrt計算に使うテーブルでもあるのかな?)が書き換えられて計算がおかしくなってたのでした。(これもだいぶ時間を浪費。BASICだとエラー出してくれるんだろうけどね~)
移植自体は、SAKURAがArduino準拠に対して、RX621はCで作るので、若干Arduino関数の書き換えがあったぐらいです。(degitalWrite等はほとんど使ってなかったけど、bitSetやbitReadの書き換えが必要だった。)

②の配線整理は、表はこうなりました。(1-Trアンプ部分の追加はまだの状態)

裏はこんな。

「before」は、前の2017/11/5の記事を見て下さい。
(ほぼ「初めての大きなデジタル作品」なので、汚いとかVccラインとGNDラインの引き回しが悪いとかは、目をつぶって下さいw。)
だいぶ前に作ったので、今作るなら、層選択のダーリントン接続TrはFETにしたいし、いっぱいあるLED電流制限抵抗はSMD抵抗にしてもっとコンパクトに作りたいですね…。
基板のピンヘッダからLED-Cubeを繋げるのに、8×9=72本のビニール線が繋がるので、ケーシング内は「ビニール線の塊w」みたいになってます。せっかくのスケルトンケースなのに、回路は全然見えませんw。LEDを基板に直付けすればLEDの駆動は基板上の配線だけで済むのですが、LEDと基板を別にしたので、間に配線が必要となってしまいました。
これを機に基板も作り直したい気もしますが、どうかなぁ、やるかなぁ…w。

③のケース変更は、前のSAKURAは、ボードを固定せずに外に宙ぶらりんにしてたのですが、今回はマジメに固定しました。

プログラム書き換えにDIPスイッチの変更が必要なので、ケース上面に穴をあけて、このままの状態でUSBケーブル刺して書き換えができます。

④のスーファミコントローラは、RX621への一旦の移植が終わってから、あいたSAKURAでテストしました。

コントローラのコネクタとの接続は、ジャックなんて売ってないし、ジャンクから取ったりしても金掛るので、部品のリード線の先端を折り曲げてコネクタに突っ込んでます。それを直角に曲げて、ユニバーサル基板で受けてます。

スーファミコントローラの仕様はネット上に情報多いので他の人に任せますが、不正確な情報も多いようです。
イネーブルにせずともクロックを送らずとも、最初のデータ(Bボタン)は、常にDATA端子に出てます。イネーブルにしてクロックを送ると、2個目(Yボタン)に進む、もう1個のクロックで3個目(Selectボタン)に進む…という順で進んでいきます。(ボタン操作のデータは12個までありますが、途中でイネーブルを切れば、途中までの読み込みにもできます。)
SAKURAのテストで、まあ一発ではありませんが、そこそこ簡単に操作読み込みできました。

ついでにこのSAKURAで、RXマイコンでのPWMによる音階出力までやっておきました。SAKURAのRX63N→RX621への移植は、レジスタがほぼ同じで、まあまあ簡単でした。
平日にぼちぼちプログラム考えて、この土日で本体プログラムに組み込んで動作確認。再々動作確認・デバッグしては書き込んで、なんとか今週、一応完成しました。
小学校(~中学校)の頃に、N-BASICでプログラム作った頃のことを思い出しながら作りましたw。その頃も似たような「ヘビがだんだん長くなる」プログラムを作った記憶がありますが、10ドットぐらいになると、相当遅くなってしまう。まあクロックというよりも、BASICインタプリタとCコンパイラの差でしょうね~。長くなっても目で見て実行に何の差も出ませんねw。

息子(大学1年)と奥さんにやってみてもらったところ、息子は「そこそこおもしろい」、奥さんは「操作が難しくて言う事聞かない」との感想でしたw。
キューブの表面・中をドットが動きながら、左右に曲がる・キューブの中に入っていく方向に曲がる、といった動きをどう操作・表現するか、ロジックをよ~く考えてルールを決めましたが、操作をちゃんと理屈で理解するのはけっこう大変ですw。
(ちっちゃい人がキューブ表面を歩いてる時に、足と顔がどっち向いてるか、を基準にして、左右に曲がる方向が変わるんですね。)
(まあ、よ~~~く考えたロジックなのですが、誰も参考にしないと思うので、ストレージにもプログラムは載せませんw。全体で1,100行、ゲームの部分だけでも400行ぐらいになるので、直接貼り付けはできないし。もし見たい人が居たら、個人的に連絡してね。)

という事で、冒頭の動画の様に、とりあえず出来上がりました。あと、コントローラをもう1個付けて2人対戦プレイが出来るようにして、1P/2Pの選択・どっちが勝ったのかの終了表示の追加、あたりを、気が向いたらするかもな~~w。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

10/24 Nucleoボードをちょっと触ってみる~最速でGPIOをON/OFF

2020-10-24 | PIC・電子工作
買ってしばらく放置してたNucleoのSTM32F446REボード、ちょっとやりたい事があって使ってみることにしました。

前回(5/31 マイコンボードいっぱい買った①~Nucleoボード動作確認)の時の結論では、
「とりあえずオンラインmbedの方がarduinoライクに簡単にプログラムが書けそうだけど、もっと詳細な設定をしたければ、cubeMXで設定作ってmbedに必要な部分だけコピペするか、「cubeMX+SW4STM32」で作った方がいい」
となったのですが、mbedのオンラインコンパイラーは、どうもできる事が限られてる気がする…。
アセンブルリストを確認したいのだけど、どうしても出し方が分からない…。

だいぶ探した後、「エクスポートして別のオフライン環境で開発する」という作戦があるとの事。見てみると、

e2studioがある!SW4STM32もある!
e2studioはルネサスのRX621ボードの為にインストールしてちょっと使ったので使いやすい。SW4STM32は、一応入れたけど、まだあまり使ってないw。

エクスポートして開いてみたけど、どちら(e2studio/SW4STM32)もprintfがエラーになってビルドできない。printfを全部コメントアウトしても’undefined reference to _wrap_vsnprintf’とやらのエラーが出て、どうしてもビルドできない…。
いろいろキーワードで検索してもなかなか解決せず、最終的にいつも親切なルネサスのフォーラムでヒントを見つけて、e2studioで何とかビルドできて、アセンブルリストも見れるようになりました。
(具体的には、プロジェクトのルートにあるファイル’.cproject’の中から、エラーの出る_wrap_??printfを含む行を削除していったら、ビルド通るようになりました。)
英語にはそこそこ自信があるのですが、e2studioはフル日本語で、やっぱり助かる~ww。

プログラムは前回の「クロックを設定して、クロックの各設定値をprintfで出力した後、Lチカする」というプログラムですが、「mbedで作ったプログラムはサイズがデカい!」という情報だったので、プログラムサイズ見てみます。

やはり、クロック・GPIOの設定して表示してからLチカするだけのプログラムで、42KBもありますね…。まあ、これから手書きでプログラムのライン数を増やしていっても、比例で増えてくことは無いと思いますけど。
mbed のバイナリサイズを減らす方法」という記事によると、printf不使用・実行時アサート無効にするとかなり小さくできるとの事ですが、今のところはprintfが使えた方が都合がよさそうだし、メモリには余裕があるので、とりあえずこのままとします。

このプログラムで、アセンブルリストを確認・できる範囲で解読を試みますw。
前半のHALでクロックやGPIOの設定・初期化をしてるところは省略して、Lチカのところだけ貼り付けます。(一部加工してます。)
  42 0008 4B4C     		ldr	r4, .L4
 159 00c8 254E     		ldr	r6, .L4+40

 65:../main.cpp   ****     RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
 190              		.loc 1 65 0
 191 00fc 236B     		ldr	r3, [r4, #48]
 192 00fe 43F00103 		orr	r3, r3, #1
 193 0102 2363     		str	r3, [r4, #48]
  66:../main.cpp   ****     GPIOA->MODER |= 0x5555;
 194              		.loc 1 66 0
 195 0104 3368     		ldr	r3, [r6]
 196 0106 43F4AA43 		orr	r3, r3, #21760	// 0x5500
 197 010a 43F05503 		orr	r3, r3, #85	// 0x55
 198 010e 3360 	     		str	r3, [r6]
  67:../main.cpp   ****     GPIOA->OSPEEDR |= 0xAAAA;
 199              		.loc 1 67 0
 200 0110 B368 	 		ldr	r3, [r6, #8]
 201 0112 43F42A43 		orr	r3, r3, #43520	// 0xAA00
 202 0116 43F0AA03 		orr	r3, r3, #170	// 0xAA
 203 011a B360 	 		str	r3, [r6, #8]
 204              	.L2:
  68:../main.cpp   **** 
  69:../main.cpp   ****     for(;;) {
  70:../main.cpp   ****         GPIOA->ODR = 1;
 205              		.loc 1 70 0 discriminator 1
 206 011c 104C     		ldr	r4, .L4+40
 207 011e 0123     		movs	r3, #1
 208 0120 6361     		str	r3, [r4, #20]
  71:../main.cpp   ****         wait(0.2);
 209              		.loc 1 71 0 discriminator 1
 210 0122 1048 	 		ldr	r0, .L4+44
 211 0124 FFF7FEFF 		bl	wait
 212              	.LVL15:
  72:../main.cpp   ****         GPIOA->ODR = 0;
 213              		.loc 1 72 0 discriminator 1
 214 0128 0023     		movs	r3, #0
 215 012a 6361     		str	r3, [r4, #20]
  73:../main.cpp   ****         wait(0.5);
 216              		.loc 1 73 0 discriminator 1
 217 012c 4FF07C50 		mov	r0, #1056964608
 218 0130 FFF7FEFF 		bl	wait
 219              	.LVL16:
 220 0134 F2E7     		b	.L2
 221              	.L5:
 222 0136 00BF     		.align	2
 223              	.L4:
 224 0138 00380240 		.word	1073887232	// 0x40023800
 225 013c 00000000 		.word	.LC0
 226 0140 14000000 		.word	.LC1
 227 0144 2C000000 		.word	.LC2
 228 0148 44000000 		.word	.LC3
 229 014c 5C000000 		.word	.LC4
 230 0150 74000000 		.word	.LC5
 231 0154 8C000000 		.word	.LC6
 232 0158 A4000000 		.word	.LC7
 233 015c BC000000 		.word	.LC8
 234 0160 00000240 		.word	1073872896	// 0x4002000
 235 0164 CDCC4C3E 	.word	1045220557	// 0x3E4CCCCD

一番前の2行は、前のほ~うから探して取ってきました。
HAL関数の実装やwaitは、このmain.o.lstには含まれていない様です。
RCCの設定用にr4=0x40023800、GPIOの設定用にr3=0x4002000を使っている様です。
そして、offsetを使ってstrでメモリ上に書き込んでます。
(これは、PICのバンク切り替えに似てるかもしれません。「今からGPIOAに関する操作をするよ」という事で、「メモリ・アドレスのベースとなるレジスタ」をセットしてからGPIOAを操作し始める感じです。)

まず、先頭の番地を指定します。

次に、各設定のoffsetに従って、代入します。

元のプログラムでは、例えば「GPIOA->MODER |= 0x5555;」で1行であたかも即値代入ですが、or取ってる事もあって1命令では済んでませんが…、orが2つに分かれてます…。
なんででしょう?データシートを調べます。

「フレキシブル第2オペランドについては59ページを見てね」との事w。

(日本語のデータシートがゲットできて助かった~ww)
なるほど~。定数で指定できるのは0x55等の8ビットだけだけど、シフトして0x5500なら指定できるのね。ニーモニック的には区別つかないけど、コードに変換されるときに8ビット+シフト数がコードに入れ込まれるんでしょうね。
できるなら、急ぐポート出力には、orを使わずに代入した方がいいですね。
ポートへの出力(メモリへの代入)も即値でできず、"0"と"1"をレジスタに代入してからストアしてます。それとアドレスベースの代入もループの中に入ってるので、それらをループの外に出せば、速度が上がりますね。

このアセンブラリストを手掛かりに、インラインアセンブルを使って、GPIOの最速でのON/OFFを目指してみます。
プログラムの必要部分だけ書き出すと、こうなりました。
    int high, low
    high = 1;
    low = 0;

    asm volatile (
    		"ldr r4, .List		\n\r"
    		".Label1:			\n\t"
    		"str	%[H],[r4,#20]	\n\r"
    		"str	%[L],[r4,#20]	\n\r"
    		"b .Label1			\n\r"
    		".List:			\n\r"
    		".word	0x40020000	\n\r"
    		:
    		:[H] "r" (high),
		 [L] "r" (low)
		 : "r4"
    );

high=1,low=0は、アセンブルの中のループの外にアセンブラで指定してもよかったのですが、今回は拡張インラインアセンブラで、C側から変数を渡す書式にしました。
元のCを参考にして、ラベル:.Listに書いてあるwordを参照させてr4にGPIOのアドレスを設定し、そのアドレスに値(汎用レジスタ)をストアする形になりました。
(最初、「mov r4,#0x40020000」としましたが、ダメでした。movの第2オペランドでの即値は16ビットまででした。)

アセンブル結果はこうなってます。
  71:../main.cpp   ****     high = 1;
  72:../main.cpp   ****     low = 0;
  73:../main.cpp   **** 
  74:../main.cpp   ****     asm volatile (
  75:../main.cpp   ****     		"ldr r4, .List	\n\r"
  76:../main.cpp   ****     		".Label1:	\n\t"
  77:../main.cpp   ****     		"str	%[H],[r4,#20]	\n\r"
  78:../main.cpp   ****     		"str	%[L],[r4,#20]	\n\r"
  79:../main.cpp   ****     		"b .Label1	\n\r"
  80:../main.cpp   ****     		".List:	\n\r"
  81:../main.cpp   ****     		".word	0x40020000	\n\r"
  82:../main.cpp   ****     		:
  83:../main.cpp   ****     		:[H] "r" (high),
  84:../main.cpp   **** 			 [L] "r" (low)
  85:../main.cpp   **** 			 : "r4"
  86:../main.cpp   ****     );
  52              		.loc 1 86 0
  53 0028 0020     		movs	r0, #0
  54 002a 0123     		movs	r3, #1
  55              		.syntax unified
  56              	@ 86 "../main.cpp" 1
  57 002c 014C     		ldr r4, .List	
  58              	
  59 002e 6361     	.Label1:	
  60 0030 6061     		str	r3,[r4,#20]	
  61 0032 FCE7     	
  62              	str	r0,[r4,#20]	
  63 0034 00000240 	
  64              	b .Label1	
  66              	.List:	
  67              	
  68              	.word	0x40020000	
  69 0038 5DF8044B 	

意図通りに、最速でGPIOAに1.0を書き込むプログラムになってると思います。

オシロで出力を見てみます。

早すぎるせいか、1Vぐらいしか出てませんね…。約36MHz出てます。
1ループ:180÷36=5サイクルでしょうか?strが1サイクルとすれば、ジャンプが3サイクル…?(近距離の条件なし相対ジャンプで3サイクルも食うかしら…?)

1を書くstrと0を書くstrの間にnopを3つ入れてみました。

今度は25~26MHz出てます。180÷7=25.7MHzで、7サイクルになったのかしら…?
上のnop無しの「str:1-str:1-ジャンプ:3」と計算が合いませんね…。
(cortex-M4の命令実行サイクルの一覧表を探したのですが、見つけきれませんでした…。)

ちょっとすっきりしませんが、とりあえずこの環境(e2studio=eclipse)でインラインアセンブルを使って、最速でのポートON/OFFが出来た、という事で、今回は終了としますw。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

10/17 USB-RS232変換ケーブルを使って、マイコンからのシリアル受信

2020-10-17 | PIC・電子工作
今日は電子工作のネタをw。
PICやマイコンを使った工作や修理に、いつも「つつじが丘おもちゃ病院」の大泉さんのプログラムを使わせて頂いてます。
大泉さんのプログラムには、マイコン側からシリアルでデバッグ文字列や変数を出力して、プログラムのどこを動いてるのか・変数がどんなか、を見れるような仕掛けが仕込んである(事が多い)のですが、今までパソコン側でシリアルを受信できる手段がなかったので、使ったことがありませんでした。
しかし、途中の変数の値の仮出力・確認等は、VBとか他のプログラミングのデバッグでも常套手段で、自分でPIC等の低レベルマイコンのプログラムを作るなら、必要な事でしょう。(メーカ純正の高級デバッガーは持ってないのでw。)

大泉さんが作っている16F1454を使ったUSB-シリアル変換器を作れば済むことなのですが、今手持ちの16F1454は、Attiny13高電圧プログラマーに使ってる1個だけしかない。
手持ちに、秋月のプログラマーを買ったときに一緒に買わされたUSB-RS232変換ケーブルがある。これが使えるのでは?

と、大泉さんとメールでやりとりしていたらば、「USB-RS232変換ケーブルは、中でUSB-シリアルの変換をした後、TTL-RS232へのレベル変換をしている。モールド破壊してレベル変換前のTTLレベルの信号で入出力すれば使える」という話になりました。(これは、のちほど方針変更されますがw。)

そこで、秋月のUSB-RS232ケーブルのモールド破壊して、中身を確認します。(モールド除去、大変でした…w。)
表には、Prlolific社(台湾)のPL2303TAというUSBドライバがメモリ:12C04付きで乗ってます。

裏面は、Zywyn社(米国、"サィウィン"と読むらしい)のZT213LFEAというRS232トランシーバが乗ってます。

それぞれデータシートより、接続例・ピンはこんな。

PL2303の入力は、ZT213の出力でホールドされてしまうので、ZT213を無視してPL2303に入力するには、パターンの切断が必要。どちらもSSOP28でピン間隔も基板上のパターンも極小ですが、「多分このライン」という所の貫通ビアを切断して繋ぎこみしてみたものの、うまく動かず…。
ICの下にもラインが通ってて追えないので、ZT213側から根拠もなく「R1OUT使ってるんじゃない?」とやってみたけど、そんなんじゃダメよねw。(何で入力4ch・出力5chもあるんだろうと思ったけど、TXD/RXDの信号線だけじゃなくて、DTRやRTS等のハンドシェイク線もレベル変換してるんだなw。)

そうこうしてるうちに、大泉さんとのメールで「その変換コードの先に更にRS232C-TTLの変換を付ければいい。反転なのでTr1個で作れる。(電源はRS-232の信号線から取ればいい)」という話が。
どういう事でしょう?

RS-232の電圧レベルは「±5V~±15V」と書いてあります。電圧が高いので、ノイズに強く長距離伝送できる利点がありました。(過去にはw)
ところが、ZT213のデータシートによると、

RS-232信号出力は±5V~±6Vですが、信号入力は2.4V以上でH、0.8V以下でL認識となっていて、別にマイナスまで振らなくてもLになります。
図解すると、

図中の破線の所に(データシート保証値の)スレッショルド電圧があり、それ以上/それ以下でH/Lを認識してくれます。通信の相手がRS-232という事だけが分かっててそれ以上の詳細が不明なら、規格の範囲内の±5V~±15Vで通信する必要がありますが、相手の仕様が分かってれば、相手の仕様を満足する電圧範囲で信号を送ってやればいいですよね。

送受信両方やるならロジックICのインバータ(74HC04とか)を使った方が早いかもしれませんが、今回はマイコン側からの送信だけなので、Tr1石で作ってみます。
よ~く吟味の結果、回路はこうしました。

ミソはコレクタの抵抗値。ZT213のデータシートによると、インバータの入力は5kΩでプルダウンされてるので、反転回路を付けると、コレクタ抵抗とで分圧されて、入力電圧が下がります。よって、分圧後もインバータがちゃんとHを認識できるように、コレクタ抵抗は低めにしてあります。
電源はDTR(データ端末レディ)から取りました。念のため逆流防止ダイオード付けてます。

これで、DSUBコネクタ付けて基板作成。

こんなに小さく作る必要はないのですが、たまたまこの寸法の基板切れ端があったのでw。(どうも根がケチでw。しかも、部品は全てジャンク取り外し品を使用ww)
表側はこんな。

これで、マイコン側からシリアル信号出力して、TeraTermで受け取りしてみます。

プログラムは、先日作ったAttiny13aのOSCキャリブレーションにシリアルデバッグ出力を追加して使用。(大泉さんのプログラムから張り付け足しただけですがw。)
#define F_CPU 9600000 // 9.6MHz
#define DBG_OUT 2		//デバグ情報出力ポートのビット位置

#include <avr/io.h>
#include <avr/eeprom.h>
#include <util/delay.h>

//1ビット分の時間待ち(9600bps@9.6MHz)
void dbg_wait(void)
{
	volatile unsigned char n=106;
	while(n--)  { }
}

//1文字を送信
void dbg_c(
unsigned char c)	//表示する文字データ
{
	unsigned char n;

	PORTB&=~(1<<BG_OUT);	//スタートビット
	dbg_wait();
	for(n=0;n<8;n++)	//8ビット分繰返す {
		//LSBからデータビットを送信する
		if(c&1) PORTB|=1<<DBG_OUT;
		else PORTB&=~(1<<DBG_OUT);
		dbg_wait();
		c>>=1;		//次のビットに進める
	}
	PORTB|=1<<DBG_OUT;	//ストップビット
	dbg_wait();		//2ビット分を確保する
	dbg_wait();
}

//16進文字で1バイトを送信
void dbg_b(
unsigned char b)	//表示するバイトデータ
{
	const unsigned char hex_tbl[]
	={'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};

	dbg_c(hex_tbl[b>>4]);
	dbg_c(hex_tbl[b&0x0f]);
}

int main(void)
{
    while (1) 
    {
	//ポート初期設定
		DDRB = 0x05;	//PB0,PB2を出力に
		PORTB = 0b00011110;	//PB2はH、PB1,3,4はプルアップ
		_delay_ms(500);
dbg_c(':');
dbg_b(OSCCAL);
dbg_c(' ');
	for(;;) {
	//信号出力
	      asm volatile(
			"ldi  r16, 0b00011110"    "\n\t"	// L出力用データ
			"ldi  r17, 0b00011111"    "\n\t"	// H出力用データ
			"ldi  r18, 0b00011010"    "\n\t"	// SW検出用マスク
			"LABEL1:"                 "\n\t"
			"out  0x18, r17"          "\n\t"	// H出力				CPU 1 cycle
			"in   r19,0x16"           "\n\t"	// ポート入力		CPU 1 cycle
			"com  r19"                "\n\t"	// 入力結果反転		CPU 1 cycle
			"and  r19, r18"           "\n\t"	// SWポートマスク	CPU 1 cycle
			"brne LABEL2"             "\n\t"	// 0でなければループ抜ける	CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle

			"out  0x18, r16"          "\n\t"	// L出力				CPU 1 cycle
			"in   r19,0x16"           "\n\t"	// ポート入力		CPU 1 cycle
			"com  r19"                "\n\t"	// 入力結果反転		CPU 1 cycle
			"and  r19, r18"           "\n\t"	// SWポートマスク	CPU 1 cycle
			"brne LABEL2"             "\n\t"	// 0でなければループ抜ける	CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle
			"rjmp LABEL1"             "\n\t"	// 先頭に戻る	CPU 2 cycle
			"LABEL2:"                 "\n\t"
			"nop"                     "\n\t"
	    :::"r16", "r17", "r18", "r19"
	    );

		if(!(PINB&0x08)) {		//PB3がLのときは
			OSCCAL+=1;		// 校正値をインクリメントする
			dbg_c('+');
			dbg_b(OSCCAL);
			dbg_c(' ');
			_delay_ms(500);
			while(!(PINB&0x08));	//PB3がHになるまで待つ
			_delay_ms(500);
		}
		if(!(PINB&0x10)) {		//PB4がLのときは
			OSCCAL-=1;		// 校正値をデクリメントする
			dbg_c('-');
			dbg_b(OSCCAL);
			dbg_c(' ');
			_delay_ms(500);
			while(!(PINB&0x10));	//PB4がHになるまで待つ
			_delay_ms(500);
		}
		if(!(PINB&0x02)) {		//PB1がLのときは
			eeprom_busy_wait();	// キャリブレーション値をEEPRONの0番地に書込む
			eeprom_write_byte(0x0000,OSCCAL);
			dbg_c('=');
			dbg_b(OSCCAL);
			dbg_c(' ');
			_delay_ms(500);
			while(!(PINB&0x02));	//PB1がHになるまで待つ
			_delay_ms(500);
		}
	}
   }
}

(あいかわらず<>を倍角で書き換えているので、コピペする場合はご注意願います。)

TeraTermでの受け取り結果は、こんな感じ。

(一発でうまくいった訳ではないのですがw。)
最初の起動時、":"に続いてOSCCALの初期値を出すようにしてます。それから、プラスしていくつ、マイナスしていくつ、EEPROMへの書き込みは”="でいくつ、という表示です。
OSCCAL初期値=56で、実クロック=9.296MHz。OSCCAL=5aでほぼ9.6MHzになりました。
上げ下げすると、9600bps想定のシリアル信号が正しく取れなくなります。(文字化けします。)
下は53→9.02MHz、上は10.24MHzぐらいで正しく取れなくなりました。
だいたい±6%程ズレると、正しく取れなくなりますね。

オシロで信号確認。

ch1(黄)がPB2の出力信号、ch2(水色)が反転信号。反転信号のHレベルは4.35Vでした。クロックを9.6MHzに合わせた状態で、最初のスタートビットの幅が約104μsで、1÷9.6MHz=104μsにぴったりです。

測定作業中の状況。

いろいろ繋ぐものが多くて、結構めんどうですw。

これで、今後プログラムを自作してうまく動かない時の解明がはかどるに違いありませんw。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

9/22 Attiny13aの内蔵オシレータキャリブレーション

2020-09-22 | PIC・電子工作
さてこの4連休、Attiny13aをつついて遊んでいます。
安くて便利なこのAttiny13aですが、内蔵RCオシレータの誤差が、カタログスペックで±10%となっています。
マイコンを赤外線リモコンの送信機等で使う場合、38kHzの変調波を作る必要があります。
一般的に使われてる赤外線受光素子は、外乱を受けない様に(代表的には)38kHzの信号のみを受信するように作られていますが、その周波数の必要精度はどのくらいでしょう?

データシートになかなか載ってないのですが、いつもお世話になってる大泉さんから型番(PL-IRM2121-A538)を教えて頂いて、周波数-感度のグラフをゲットしました。

これによると、38kHzから±10%外れると、感度半減です!これでは、操作可能距離に大きく影響すると思われます。
±5%ズレても70%。38kHz変調波の周波数誤差は、3%以内ぐらいに抑えたいです。
それなのに、使用するマイコンのオシレータ誤差が±10%もあったのでは話になりませんw。
(まああくまでも「保証値」なので、10%はないと思いますが。)

Attiny13aは、内蔵オシレータの精度を工場出荷時より上げたい場合には、自分で校正したOSCCALを指定してやる必要がありますが、Attiny13aにはクロック出力の機能が無いので、プログラムで何らか出力してやって、その周波数を測定する必要があります。
Attiny13aの内蔵オシレータキャリブレーションは、ネット上にいくつかありますが、参考にさせて貰いながら自分で作ってみます。

要件としては、
・インラインアセンブルできっちりサイクル数えて、ポートにパルスを出す。(結果、クロックの16分の1のパルスを出す事になった)
・PB3(PIN2)をLにするとOSCCAL値がインクリメントする。
・PB4(PIN3)をLにするとOSCCAL値がデクリメントする。
・目標の周波数になったら、PB1(PIN6)をLにするとOSCCAL値をeepromの0番地に書き込む。
とします。

プログラムはこうなりました。

/*
PB0(PIN5)に周波数カウンタ(又はオシロスコープ)を繋ぐ。
クロックの1/16がPB0出力に出力される→9.6MHzなら600kHzが目標。
PB3(PIN2)をLにするとOSCCAL値をインクリメントする。
PB4(PIN3)をLにするとOSCCAL値をデクリメントする。
目標の周波数になったら、PB1(PIN6)をLにするとOSCCAL値をeepromの0番地に書き込む。
*/ 

/*ヒューズ設定*/
// 7A FC

#define F_CPU 9600000 // 9.6MHz

#include <avr/io.h>
#include <avr/eeprom.h>
#include <util/delay.h>

int main(void)
{

    while (1) 
    {
	//ポート初期設定
		DDRB = 0x01;	//PB0を出力に
		PORTB = 0b00011110;	//PB1~4はプルアップ

	//信号出力
	      asm volatile(
			"ldi  r16, 0b00011110"    "\n\t"	// L出力用データ
			"ldi  r17, 0b00011111"    "\n\t"	// H出力用データ
			"ldi  r18, 0b00011110"    "\n\t"	// SW検出用マスク
			"LABEL1:"                 "\n\t"
			"out  0x18, r17"          "\n\t"	// H出力			CPU 1 cycle
			"in   r19,0x16"           "\n\t"	// ポート入力		CPU 1 cycle
			"com  r19"                "\n\t"	// 入力結果反転		CPU 1 cycle
			"and  r19, r18"           "\n\t"	// SWポートマスク	CPU 1 cycle
			"brne LABEL2"             "\n\t"	// 0でなければループ抜ける	CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle

			"out  0x18, r16"          "\n\t"	// L出力			CPU 1 cycle
			"in   r19,0x16"           "\n\t"	// ポート入力		CPU 1 cycle
			"com  r19"                "\n\t"	// 入力結果反転		CPU 1 cycle
			"and  r19, r18"           "\n\t"	// SWポートマスク	CPU 1 cycle
			"brne LABEL2"             "\n\t"	// 0でなければループ抜ける	CPU 1 cycle
			"nop"                     "\n\t"	//					CPU 1 cycle
			"rjmp LABEL1"             "\n\t"	// 先頭に戻る	CPU 2 cycle
			"LABEL2:"                 "\n\t"
			"nop"                     "\n\t"
	    :::"r16", "r17", "r18", "r19"
	    );

		if(!(PINB&0x08))		//PB3がLのときは
		{
			OSCCAL+=1;		// 校正値をインクリメントする
			_delay_ms(500);
			while(!(PINB&0x08));	//PB3がHになるまで待つ
			_delay_ms(500);
		}
		if(!(PINB&0x10))		//PB4がLのときは
		{
			OSCCAL-=1;		// 校正値をデクリメントする
			_delay_ms(500);
			while(!(PINB&0x10));	//PB4がHになるまで待つ
			_delay_ms(500);
		}
		if(!(PINB&0x02))		//PB1がLのときは
		{
			eeprom_busy_wait();	// キャリブレーション値をEEPRONの0番地に書込む
			eeprom_write_byte(0x0000,OSCCAL);
			_delay_ms(500);
			while(!(PINB&0x02));	//PB1がHになるまで待つ
			_delay_ms(500);
		}
		
    }
}

(あいかわらず<>を倍角で書き換えているので、コピペする場合はご注意願います。)

「メインルーチンをCで書いて、時間が重要な部分をインラインアセンブラで書く」のが普通なところ、逆にメインがアセンブラの様なプログラムになってしまいましたが、一応動きましたw。(C側の変数をインラインアセンブラ側で使う方法とか、まだまだ勉強が必要ですが、今回は「インラインアセンブラを初めて使ってみた!」という事でご勘弁をw。)

出力される周波数は、秋月のカウンターキットとオシロとで測定。(水晶発振の確認の為に買ったカウンターですが、アンプ通さないと測定できなくて、未だにちゃんと使えてない…。)

写真はほぼ600kHz(=9.6MHz)に校正後(OSCCALの1上げ下げで、5kHzぐらい変わるので、このくらいがほぼベスト)。SOP8のAttiny13aは、SOP8→DIP8の変換基板を使って作ったアダプターを使用して、ブレッドボードで仮組みです。

オシロでの測定状況。

使ったAttiny13aの「校正値バイト」は、"56 5A"でした。
それに対して、校正後のOSCCALは56→59で、校正前後で約3%の誤差でした。やはり、周囲とのやり取りで周波数やクロックが重要な場合には、校正が必要でしょう。

さて、以上は9.6MHz内蔵クロックの話ですが、4.8MHzを使う場合はどうなるのでしょう?
データシートによると、

17.3 校正バイト
Attiny13の識票エリアには、内蔵オシレータ用の2バイトの校正値が格納されている。校正データのアドレス0x00番地の上位バイトは、9.6MHz動作時のオシレータ設定に使用される。オシレータの正確な周波数を保証する為に、リセット時にこのバイトが自動的にOSCCALに書き込まれる。

4.8MHz動作時用に別個の校正バイトがあるが、そのデータは自動的には読み込まれない。ハードウェアはリセット中に、常に9.6MHz用の校正データを読み込む様になっている。4.8MHz動作時にこの別個の校正データを使うには、ファームウェアでOSCCALを更新する必要がある。4.8MHz動作時の校正データは、識票エリアのアドレス0x01番地の上位バイトに格納してある。

と書いてあるようです。
つまり、今回使用したAttiny13aの校正バイトは"56 5A"で、"56"の方が9.6MHz用の工場校正値で、これが自動的に読み込まれてOSCCALのデフォルトになる。"5A"の方は4.8MHz用の校正値だが、これは、せっかくあるのに使われない!
という事になりますね…。(なんでせっかく設定してるのに使わないんだ??)

先ほどの校正用プログラムを4.8MHzで動かしたときの状況です。

目標:300kHzに比べて、随分低くなってます。そりゃそうだよね、工場校正で「5Aがいいですよ」っていうのに、OSCCALは"56"になってるのですから。(実際、eepromに書き込んで確認しました。)
これを300kHzにするのに、OSCCALプラス8が必要でした。9.6MHz→4.8MHzで工場校正値の差が+4、9.6MHzの時の校正値が工場校正値より+3だったので、ちょうどそんなところでしょう。

つまり、Attiny13aを4.8MHzで使う際は、やっぱり校正した方がいいけど、せめて校正値バイトを読んでその2バイト目に書いてある数字でOSCCALを更新するべき!
という結論になりましたw。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

9/21 LEDのI-V特性などなどの続き~Attiny13aでのQステア送信機検討

2020-09-21 | PIC・電子工作
昨日アップした記事ですが、検討した回路に不具合(?不都合)がありました…。

大泉さんより、
「PB5(RESET)は駆動能力が低い。PB0とPB1が強力だが、ADC入力できない。PB2、3、4を使った方が良い。(ADCの分解能に十分余裕があるので、分圧抵抗値は今より下げる)」
という助言を貰いました。

「そんなポートの出力に差があるなんて、データシート(日本語版)の18.1絶対定格にも18.2DC特性にも書いてない…」と思ったのですが、
・19.8出力駆動部能力(低能力ピン):PB4,3,2
・19.9出力駆動部能力(通常ピン):PB1,0
・図19-40I/OとしてのRESETピン出力電圧 対 ソース電流(Vcc=3V)
にこっそり書いてありました…。不親切だなぁ…。I/Oの所とかに一覧表にして書いてくれればいいのに…。(ここのグラフ以外に「低能力ピン/通常ピン」なんて表現はどこにもない?!)

よって、「プルアップ抵抗が高めのPB5を使おう!」と思ってましたが、LEDの直接駆動には向かない(というか、ほぼ無理w)。操作可能距離に響くので、LEDには15mAぐらいは流したい。PB2,3,4なら15mAぐらいまでは流せそうだけど、分圧抵抗をいまより下げると、そちらに流れる電流が増えて、ポートがますます厳しくなる…
といった事で、いろいろと制約が増えてきました…。
こうなると、素直に14PINの16F1503で作るか、8PINにするなら12F1501なりを使う方がいい気がしてくる…。

しかし、次善の策として「ターボSWとチャンネルセレクトを兼ねる」という作戦も考えてた事を思い出しました。回路にするとこんな感じです。

機能・プログラムとしては、
・ターボSWだけは正論理にして、ピン変化割り込みから外す(ターボSW単独押しではWake-upしない)
・Wake-upしたら、プルアップONしてADCを読んで、チャンネルを設定する。
・万が一Wake-up時にADC読み込み結果=ほぼVccだったら、ターボSWが押されていると判断して、sleep前のチャンネル設定を踏襲する。

ちなみにこれで、プルダウン変化時の電圧はこうなります。

昨日の記事の回路より、こっちの方が断然簡単な気がしてきましたww。

操作上の不都合としては、「電源入れて最初(orチャンネルセレクトSWを変更して最初)に、先にターボを押しながら前進を押す様な操作をすると、チャンネル設定がちゃんとできない」だけかと思いますが、「あれ?操作できない」となっても、多分次に何か操作してみたら動いた、ぐらいの事で済みそうに思われます。
さてこれで、Attiny13aで実際に作ってみるかみないかは…私次第ですw。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

9/20 LEDのI-V特性などなど

2020-09-20 | PIC・電子工作
さて、楽しい4連休。ですが、おもちゃの入院品も無い。その他やりたい事を消化して、有意義に過ごそう~!
(注:ピンポイントでマニアック過ぎる記事なので、関心のない方は読み飛ばして下さいw。)

ちょっと前に「Qステアのクローン送信機」を作ってみましたが、元プログラム設計者の大泉さんとのメールのやりとりの中で、「LED出力端子に抵抗分圧でチャンネルセレクトさせて、8PINのAttiny13aで作るのがいい!」という提案がありました。
(チャンネル設定読み込み時だけ内部プルアップを掛けて、ADCで電圧を読む。それ以外の時は、内部プルアップを切ってデジタル出力にしてLED点灯に使う。)
スペースも厳しいので、8PINで済むならそれに越したことはない、検討してみました。

実機のSW構造を考慮して、大泉さんとのやりとりの結果、回路はこんな感じを考えました。

実機の回路は、ch-A選択時は、多分接点がどこにも繋がってないと思われます。そこに接点を追加するのはちょっと面倒なので、ch-A選択時にどこにも繋がらずに段階的プルダウンを実現するために、こんな並列抵抗の回路となりました。

まずLT-SPICEで検証してみました。
回路図には繋がってない抵抗が書いてありますが、ベースとなるR5の抵抗値をステップ応答で変化させて、電圧・電流を計算させます。

これによると、LED端の順方向電圧が0.5VぐらいまではLED側にほとんど電流が流れず、電圧はプルダウン側が支配的で、プルアップ抵抗との分圧で直線的に電圧が上がっていく。
0.5Vを超えて0.56Vぐらいになると、今度はLED側が支配的になって、LEDの(低電流時の)順方向電圧でほぼ一定になって、プルダウン抵抗をそれ以上上げても電圧が変わらなくなる。
という計算結果となりました。

電圧の低い所を拡大するとこんな感じ。

黄色の線ぐらいの感じで電圧を設定すれば、チャンネル4つを識別できそうです。

しかし、LT-SPICEがLEDの低電流時のI-V特性を正確に模擬しているかどうか怪しいので(型番も指定してないしw)、次は、実物のLEDのI-V特性を測定してみます。
LEDは「電流の大小によらず、順方向電圧がほぼ一定」という説明が多いですが、それはあくまでもLEDが点灯するような2~40mAぐらいの電流範囲の事であって、それより低い電流域ではそうでもないよなぁ…、と思ってたので、この際で確認します。

普通にLEDに入れる電流制限抵抗をどんどん上げていって、低電流時のLED順方向電圧を測定しました。参考までに手持ちの赤外線、赤色、青色のLEDで測定。

横軸:電流を対数目盛にして、電流を流して発生する順方向電圧は、電流の対数にほぼ比例、という結果でした。ウチで測れる極小まで電流下げても、かなりの順方向電圧が残りますね。
LEDのカタログ上の公称スペック(一部は、袋に書いてあるスペック)は、
①赤外LED:aitendoのYSL-R531FR1C-F1、Vf=1.4~1.6V、If=50mA(Max)
②赤色LED:秋月のLTL2U7SEK-002A、Vf=2.25V、If=20mA
③青色LED:aitendoの5408BC-5MM-BLUE、Vf=3.0~3.4V
です。スペックと比べると、公称のVfより0.4Vほど下げておけば、LED側の影響を無視できそうです。

さらに、手持ちの中で、赤外LEDのVfの個体差も見てみましたが、結論は、同じ型番(の、多分同じロット)だと、個体差はほとんどない。型番の違うLEDだと多少差があるかな、といった感じ。
上述のaitendoの5mm赤外LEDは、手持ちが7個ありましたが、電流制限抵抗を50KΩ入れた状態で、どれも0.933Vでほぼプラマイなし。
もう1種類、秋月の3mm赤外、OSI5FU3A11C、Vf=1.35~1.6V:10個を測ってみたところ、どれも0.910Vでほぼプライマイなし。

最後に、LEDも付けた模擬回路で、マイコン想定側のプルアップ抵抗を30k、51k、81kに変えて、プルダウン側を変えたときの電圧を測定。

マイコンのプルアップ抵抗は、きっちり固定じゃなくて幅があります。Attiny13aのデータシートによると、

となっています。
プルダウン側の抵抗が小さくなると、LEDを点灯させたときにプルダウン側にも流れてロスになる電流が増えるのでおもしろくないので、プルアップ側の抵抗が大きい方が有利です。
Attiny13aの場合、RESETピンだけプルアップ抵抗が高い(より「弱い」プルアップ)ので、このピンを使った方がよさそう。公称で30k~80kΩという事になります。

上の表は、実測結果と、LED側を無視して単純な抵抗分圧で計算した「電圧理論値」を記載していますが、実測と計算値ほぼぴったり。0.7V以下程度であれば、LED側を無視して計算してよいという事になります。
(手持ちのリード型抵抗が1、2、5.1の刻みしかなかったので5.1k、10k、20kを使っていますが、実機組むときはもちょっと細かく刻んだSMD抵抗を使うので、もうちょっと間隔を均一化できると思います。)
Attiny13aのADC分解能は、10bitフルに使えば1024→Vcc3Vなら0.003Vなので、十分電圧差を検出できるでしょう。

これで、一番上の回路図でLED点灯とADCを兼用させたチャンネルセレクトができそうです。
問題は、Attinyの内部プルアップの個体差で判定電圧が変わる点ですが、次のような方法を考えました。
・回路を組んで一番最初に電源を入れる時に、必ずchA選択にしておいて、その時のADC測定電圧をリファレンス電圧としてeepromの#00,#01に書き込む。(電源入れたときにeepromの#00,#01を読み込んで、"FF"なら「リファレンス電圧未設定」と判断して、リファレンス電圧の測定・書込を行う。)
・以降は、そのリファレンス電圧に対する比で、チャンネルを判定する。
これなら、組む前に都度Attinyのプルアップ抵抗の実測をせずに済みます。

という事で、事前準備は完了。あとは実際にプログラムを作ってみるかみないかは…私次第ですw。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする