インボリュート歯車

　自作ドローソフトは、基準となる歯車からの角度を指定すれば、その場所に配置し、上位の歯車の角度に応じて回転する、という動作も組み込んだ。
　一番最初の駆動ギアの角度を秒/60で指定すれば、1分で1回転し、下位のギアは減速比に応じた角度に回転する。
　ギアの位置と角度で矢印を表示する機能を作れば、機械式時計のアニメーションを表示できる。


　と、回転させていて気がついたのだが

　ギアのかみ合わせが良くない。大きい歯数のギアが小さい方の根本に食い込んでしまっている。
　基礎円の下の処理が良くないのかと思いつつも、基礎円より先端側にも食い込んでいるような気がする。

　この画像はz8:80だが、z8:20程度(z42未満)の組み合わせでも発生する。

　そもそもギアの形が良くないようだ。
　小さい方の歯数が12以下になると良くない感じ。13以上だとあまり気にならない。


　あと、ドローソフトを10fpsくらいで書き換えるモードにすると、メモリが足りなくなって落ちるんだよなぁ。どっかでリークしてるんだが、どこでリークしてるのか見当もつかない。
　たぶん最近作った機能じゃなくて、前に作った機能のリークがここに来て表面化してきた、ということだと思うんだが。


追記
　干渉する現象は切り下げ(アンダーカット)というモノらしい。z = 2 / sin(α)^2から切り下げが発生し、α20度なら歯数17.1以下で発生するようだ。
　12と13の部分は関係なく、大きく拡大して細かく見れば16でも干渉していた。
　切り下げから逃げるにはどうすればいいんだろうか？
　圧力角を30度にすればz8でも切り下げは発生しなくなる。あんまり歯車っぽい形じゃなくなるけど。
　アンダーカットの形が計算できればいいんだが、どうやるんだろうか。

インボリュート歯車

　歯数が42以上になると基礎円が歯底園を下回り、それに対応しないと不適切な形状になる。
　インボリュート曲線のrがdfを超えるθから開始すればいい。
　前に作って結局不要で消した、途中のθから開始する処理を復活させるだけで適切に表示できるようになった。

　歯車を1個1個場所を計算したりしてスクリプトにするのはかなり面倒。
　ギアAとギアBのzやmを指定して、ギアBはギアAから90度の位置に配置して、みたいな指示をすれば位置を計算してくれるような機能があれば楽ができる。

　1秒に1回位強制的に書き換えて、その際にシステム時間を取り込んでギアの角度を指定して、それを減速比に応じて他のギアに伝えていって、みたいな機能があれば、機械式時計の表示ができるようになるな。

インボリュート歯車

　ようやくそれらしい形になってきた。
　かみ合わせも悪くなさそうだ。


　結局、インボリュート曲線は基礎円の高さから開始するという、世間一般で言われているとおりだった。

　キッチリ作ってしまうとバックラッシュがないので、そのあたりをどうにかする必要がある。軸をずらすのが楽だが、そうすると1箇所変更すると他にも影響してしまう。
　転位係数をいじれば見かけ上の大きさを変えられるから、これで変更すれば歯車の組み合わせのうち、特定の組のバックラッシュだけを調整できるはず。

　歯底はもう少し太くても良さそうだな。

　今は歯底円は単純に円を書いているが、これをしっかり分割してやれば、いよいよ歯車としての形になる。

　あとはこのクラスをLuaスクリプトから実行できるように工夫してやれば、スクリプトベースのドローソフトで歯車を書けるようになる。
　さて、もうあと数歩……　歩幅が1km位あるなら。

インボリュート歯車

　インボリュート曲線の径からθを求める方法がわかったので、基準円と歯先円を10分割してインボリュート曲線を書いてみた。いい感じ。
　ソースコードもすっげー簡単になった。数学すっげーー。


　上の図は全体像、下の図は歯の拡大で、全体像の円は、内側から歯底円、基礎円、基準円、歯先円、となる。拡大では歯底円は見えていない。

　たぶん、基準円のθがψになるはずなので、このあたりももう少しいい感じに処理できそう。
　強度が必要ないなら歯の根元はある程度自由に処理できるから、当面は基準円の内側を中心点に向ける方向で。


　そういえば、今は歯底円も歯先円も、DrawEllipseで書いてるけど、このあたりもちゃんと処理しないとなー。

　とにかく、いろいろ方向性は見えてきたので、もう少し……


「これでまた一歩、偉大なる野望に近づいた」というところか。野望、なんだろう。それも考えておかないと。
「プログラム作ってみたけど使う予定もないしこのあたりで開発一旦止めよう」で以降一切触らないは有る有るだからな。ちゃんと用途を決めておかないと。

インボリュート歯車

　前回の、かみ合わせが悪い問題の原因がわかった。
　歯厚の処理が悪かったようだ。

　歯厚はパラメータψ(psi)だが、前回参考にしたページには出ていないパラメータだった。たぶん、前回はテキトーにそれっぽい数値を入れてたんだろう。

　このページに有る。
　小原歯車工業(株)：歯車技術資料 弦歯厚法

　小原歯車には足を向けて眠れないな(?)
　ちなみに、小原はコハラと読むようだ。

　歯厚を適切に処理すると、上の画像のように、きっちりと噛み合う。バックラッシ? 何それ美味しいの?
　インボリュート歯車は多少ピッチがずれていても大丈夫なようなので、そこにバックラッシを調整する余地があるのだろう。

　それと、基礎円の内側の処理が謎い。この図を見る感じ、基礎円ではなく、基準円の内側を削っておく必要がありそうだ。
　ということは、インボリュート曲線の始点は基礎円の高さ(=インボリュート曲線のtheta=0)ではなく、基準円まで上がったところが支点になる。なかなか難しそうだ。。。


　上の図のインボリュート曲線は、適当なピッチで計算して、中心点からの距離がda/2を超えたところで計算を打ち切るようにしている。なので、よく見ると歯先円より飛び出しているのが見えるはず。
　例えば、歯先円の内側のインボリュート点をp1、外側のインボリュート点をp2として、p1とp2のそれぞれの角度を計算(atan2)し、歯先円の半径でθ1、θ2のp3、p4を計算し、線p1-p2と線p3-p4の交点を求め、その交点を最後のインボリュート点として扱う、みたいな処理をすれば、きっちり歯先円でインボリュート曲線を止めることができる。まぁ読めば分かる通り、かなり面倒な処理になるのだが。
　そして、基準円の根本を削る必要があるなら、この処理を根本にもやる必要がある。

***

　前に作った、Luaで絵を書くプログラムを、新しく作り直してる。
　そして、C#のスクリプト機能も追加し、Luaでは扱いづらい処理をC#で書くことができる。
　例えば、Luaスクリプトで位置とモジュール、歯数を指定して関数を呼べば、C#側でその形を計算して画像やPDFとして書き出すことができる。
　一つの歯車のパラメータを複数箇所で使うことができれば、歯車を切り出すPDFデータと、それを組み合わせた外観図を作ることもできる。
　と、期待しているのだが。

追記：2018/11/27
　歯厚半角の計算に出てくるxが謎で、0.3をそのまま使ってたんだが、計算が合わん。なぜだッ! (坊やだからさ) と悩んでたんだが、xは転位係数らしい。これを0にしたらいい感じになった。

　各記号は以下のページに書いてある
　小原歯車工業(株)：歯車技術資料　歯車記号と用語

　ググって出てきたページを読むだけだと、その前に重要な事が書いてあっても気が付かんからだめだなー。

　だいぶそれっぽい歯車になってきた。

ミサイルのカラーバンド

　"石川潤一の軍用機ウエポン事典"を読んでいたらカラーバンドのとかの話が書いてあった。
　昔ペーパークラフトで作ろうとして「写真によって色が違うけどどーなってんじゃ！」と書いたやつ。

　P82に記載がある。

　これによると、FS595a/bという規格らしい。
　FSはFederal Standardの略で、「連邦標準」の意味らしい。アメリカ合衆国連邦政府(Federal government of the United States)が策定した標準規格、ってことなんだろう。

　ちなみに、FS595は2017年2月に廃止されて、SEA-AMS-STD-595に移行したらしい。

　SEAは"自動車技術者協会"の意味で、"Society of Automotive Engineers"の略らしい。
　AMSは"Aerospace Material Specifications"の略とのこと。

　SEAの日本語訳は国立国会図書館のページに書いてあるが、AMSの訳は書いてなかった。直訳すると"航空宇宙材料の仕様"となる(Google翻訳)。

　自動車技術者が航空宇宙もやってるのかぁ。。

　FS595からSEA-AMS-STD-595になったのは、RS-232がEIA-232になったのと同じようなもんだろう。


　廃止になったFS595だが、ドキュメントはダウンロードできる。
　ASSIST-QuickSearch Document Details

　内容はカラーチップの大きさとか、運用の注意事項とか。
　「カラーチップは定期的に交換しろ、直接触るな、化学薬品にさらすな、紫外線を当てるな。冷暗所に保管しろ。複製はするな」みたいなことが書いてあるっぽい。
　関白宣言かよ。

　ちなみに、カラーチップは製造から3年以内に交換し、メーカーによっては2年以内の交換を求めているところもある、らしい。めっちゃ厳しい。

　カラーチップは692個の個別のチップ(3x5in(=76.2x127mm))で約900USD、単語帳みたいな形?で175USD、3x5inの単色で35USD、とのことらしい。1枚35USDが700枚で900USDは計算に合わないので、1枚じゃなくて何枚かのセットかも。あるいはまとめて買うとめっちゃ安いのか。


　で、ミサイルのカラーバンドの話に戻るわけだが、黄(弾頭)はFS33538、茶(推薬)はFS30118、青(イナート)はFS35109、とのこと。
　この型番のフォーマット見たことある！と思ったら、プラモデルの塗料だった。なるほど。プラモデルの塗料を売るときに米国の色標準の型番をそのまま商品名にしてるのか。

　Federal StandardのPDFのAppendix II/IVに各色の詳細が書いてあるが、標準光源A, C, F2, D65で書いてあって、他に60°glossとか色のグループ、色の名前、といったことも書いてある。
　60°glossというのは表面に対して垂直から60度(表面から30度起きたところ)から光を当て、反対側の60度のところで何％の光を受けれるか、という基準。前方散乱で、光沢の基準だと思う。

　色番号のうち、最初の桁は1が光沢(反射率80以上)、2が半光沢(30から45)、1が非光沢(6以下)、とのこと。
　また、2桁目は色のグループを示し、0から8まで順番に、0:茶、1:赤、2:橙、3:黄、4:緑、5:青、6:灰、7:その他(黒、白、金、銀、紫)、8:蛍光、とのこと。
　弾頭は33なので非光沢の黄、推薬は30で茶、イナートは35で青、という感じ。


　前述の通り、色は各標準光源のものが書いてある。
　標準光源Aはタングステンの白熱電灯、CはAにフィルタを通して、平均的な日光を再現、D65は昼間の日光、F系は分子のスペクトル? とのこと。
　たぶんAから順番に出てきた規格なんだろう。D65は6500Kの黒体放射に近い(近い、であって、同じ、ではない。規格が制定されたあとに物理定数の変更があって変わってしまったとのこと)。
　ちなみにAからFまでは順当に増えているが、次はLまで飛ぶ予定らしい。LED関係なんだそうだ。

File:Planckian-locus.png - Wikipedia

　図の中にA, C, E, D50, D55, D65のマーカーがあるが、これが各標準光源のホワイトポイントの位置。Aは白熱灯なので、黄色っぽいところにある。CやD65は日中の色を目安にしてるので、青白い感じ。D65って6000Kと7000Kの中間じゃないんかい!!

File:CIExy1931 AdobeRGB.png - Wikipedia

　D65色空間だけどゆるして! Cは見つからなかった。

　FS33538(弾頭のオレンジ)はX55.59%, Y50.09%, Z6.93%で、xyYに変換するとx0.49, y0.45,Y0.50あたりになる。上の図から拾うと、580nmの少し内側で、輝度が50%、となる。
　FS30118(推薬の茶)はX11.34, Y11.17, Z6.84で、x0.39, y0.38, Y0.11となり、ブラウンと言うよりは、かなり暗い黄色、という感じ。
　FS35109(イナートの青)はX9.86, Y11.38, Z21.29で、x0.23, y0.27, Y0.11となり、暗い水色、という感じ。
　もっとも、これはD65光源からのピックアップで、上記のXYZはC光源の値なので、多少の違いはあるだろうが。


　ということで、ミサイルのカラーバンドの色は「すっげーキッチリ決められてる」ということがわかった。想像以上に厳しい。
　でもこの値をRGBに変換して印刷したところで、その色が本当にFSで規定されてる色とは限らないからなぁ。完璧にその色がほしいならSAE-AMS-STD-595のカラーチップを買わなきゃいけないんだが、10万って無理ゲー。まぁ、雰囲気だけですから、大体でいいんです。。。


　このエントリに書くことを調べるだけでまた新しい知識を得られた。世の中知らないことばかりなり。ボーッと生きてるなぁ。

DTMF FFT

　ソフトDTMFデコーダを作ってる。
　時間軸と周波数軸を比較する予定。
　とりあえず時間軸では動くようになったので、周波数軸で計算してる。

　DTMFで1, 2, 3, A, 1, 7, *, 1, 5, 9, Dを送ったときのFFTの波形。
　横軸が時間(秒)、奥行き(俯瞰は縦軸)が周波数(Hz)、高さがpower。

　FFTに入れる前にオフセットしてやらないと強烈にDC成分が出る。そりゃそーだ。
　12bitADCで2048をオフセットしても若干DC成分が出てるけど、無視できるレベル。
　もっとも、DTMFのデコードではDC成分は見ないので、オフセットするだけ計算リソースの無駄な気もするが。

　8kSPS128ポイントだと微妙に分解能が悪いんだよなぁ。8kSPS256ポイントとかあればだいぶマシだけど、波形を集めるのに32msecかかるので、短いDTMF信号は取り逃すことになってしまう。

***

　メモリの使用量は、ADC周りで520バイト、時間軸で4104バイト、周波数軸で1048バイト、とのこと(それぞれのclassをsizeofして計測)。
　時間軸での計算には、FIRで強烈なBPFを作ってるので、そのバッファでメモリがガッツリ食われる。
　FFTは入力と出力にFFTポイント分の配列が必要だが、4byte*128point*2なので1024バイト+α程度で処理できる。

　感覚的には、時間軸で処理したほうが信頼性が高い気がするんだが、まだ比較してないので、なんとも言えない。

追記
　時間軸で処理した場合は3700usec、周波数軸で処理した場合は280usec、という感じ。どちらも64MHzのC-M4Fコア。
　そんなに差があるのかぁ。時間的リソースは消費電力に直結するので、低消費電力が重要な今回の用途には時間軸は無理っぽい。RAM消費リソースもすごいしね。
　もっとも、素直にFFTを使おうとするとアホのようにデカいROMテーブルを使うので、Flashが小さいチップだと厳しいけど。

　とりあえず、時間軸を使うヤツはお先真っ暗だけど、誤検出とかの比較はしておきたいな。
　無線電話に通すならホワイトノイズ耐性はほしいし。

追記2
　試しに時間軸と周波数軸の両方に入力信号を通して結果を表示してみた。
　明らかにFFT方式はホワイトノイズ耐性が低い。時間軸の方はほぼ全く誤検知しない。

　ただ、FFT方式はもう少し工夫の余地がありそうな気がする。例えばホワイトノイズなら全体的にスペクトルが出ているはずなので、全体の平均と、検出した信号のピークの比を判断に使う、といったことができるはず。ただあんまりやりすぎると弱い信号を取れなくなるんだよなー。

　それと、誤検出したとしてもランダムエラーが主で、バーストエラーはほぼ発生しない。発生したとしても同じコードではなく、いくつかのコードが出てくるはず。
　ということは、チャタリング対策みたいな感じで、例えば3回以上同じコードが出ていれば正しいDTMFコードとして扱う、みたいにすればいいはず。
　1区間は1sec/8000sps*128point = 16msecなので、3回なら48msecになる。大抵はこの期間以上は出るはず。DTMFの仕様としては最小50msec以上送信しなきゃいけないらしいので、48msecはギリギリで受けれる。タイミングによっては無理だけど、まぁ送信側で最低限100msec以上送る、みたいな運用にすれば問題ないはず。

　あと、計算時間の計測は、信頼性がちょっと怪しい。たぶん3700と280の比は問題ないはずだけど、絶対値(usec)として扱えるかは怪しいところ。
　オシロでビジーのパルス幅を見ると2.5msec/divより狭いので、3700usecはだいぶ長過ぎる。ちょうど2倍ずれてるかも。とすると1850usec対140usecか。それだと合わせて2msecくらいなので、2.5msec/divより狭い点の説明ができる。

インボリュート歯車

　インボリュート歯車を書くプログラムを作りたかったんだけど、いまいちわかりやすい説明が見当たらなかった。このあたりは基礎知識ってことなのかな。

　内側の緑が歯底円、外側の白が基礎円、次の緑が基準円、一番外の緑が歯先円。
　インボリュート曲線は基礎円の直径で計算する。基礎演から歯底円までは任意の形状でいいらしい。任意と言っても、相手の歯が入り込める形状にする必要はあるが。
　とりあえず幅を基礎円の幅で落としているが、このピニオンギヤとか見ると見るからに根本が細いので、中心点に向かったほうがいいのかもしれない。

　数値の計算は以下のページがわかりやすい
　小原歯車工業(株)：歯車技術資料　平歯車、ラックの寸法計算

　ただ、上の画像をドローソフトを使って、基準円で並べてみると、歯が噛み合わないんだよなぁ。

***

　ある人曰く、レーザーで歯車を切りたいなら、歯車屋からCADをダウンロードしてきて使えばいい、とのこと。データを自作するのにこだわりがないならそれが早そうだ。

　「歯車　製図」とかでググると、簡略化したモデルしか出てこない。確かに、機械を作るなら歯先直径と基準円直径だけあれば干渉とか位置決めはできるだろうし、いちいち全部の歯なんて書いてられないだろうし、「ここは歯数n、モジュールmのギヤを使ってね」という指示さえあれば歯の形は指定できるし。それにしてもなんだかなぁ。

　レーザーで歯車を切り出してなにか物を作るにしても、歯車をCADデータから切るなら、あとは軸受のプレートだけ自分でデータを作ればいいだけだし、そうするとそれこそ基準円と歯先円だけあれば十分だし、そっちの方で攻めるべきかなーとも思い始めてる。

　どっちが目的か、という問題。「ギヤのデータを作るのが目的で、ギヤで動くメカメカしいモノはギヤの動作確認の手段でしかない」なのか、「ギヤを使う機械を作ることが目的で、ギヤのデータを作るのは手段でしかない」なのか。
　うーん。どっちだろう。。。
　手元にレーザーカッターがあれば機械を作るのが目的足り得るけど、それができない以上、歯車のデータを作るのが目的になる。とか言い訳してみる。

STBee F4miniでPSP液晶

　気分転換に、PSP液晶で遊んでみました。

　型番はATM0430D5というモノで、HsyncやVsyncが不要なタイプです。こいつはディスコンになって現在は別のものが出てるみたいですね(未確認)。

　バックライトの点灯にはストリナのLEDドライバを使っています。5Vを突っ込めば最大38Vまで昇圧して0mAから20mAまで32段階(33段階?)で任意の電流を設定して定電流駆動できるスグレモノです。
　さすがに32ステップとかあっても人間の目には変化はわからないですし、そもそもリニアに変化させても、ということで、対数(2.2)で4段階に変化させてみました。

　いい感じに輝度変化がわかると思います。

　裏面はこんな感じです。
　ピンアサインは変換テーブルを使うので、ある程度自由に設定できます。もっとも、8bitバスをGPIOをまたいで設定すると面倒なので、RedをGPIOB[0-7]、GreenをGPIOB[8-16]、BlueをGPIOC[0-7]、というふうにしてあります。が、Red0がGPIOB0に、といった関係ではなく、配線しやすいようにバラバラになっています。

　STBee F4miniのメモリを持ってしても、480x272x3byteの保持は不可能で、8bppIndexでも不可能でした。ということで、横解像度を240pxに落としていますが、これでもかなりギリギリです。
　GPIOの変換テーブルはFlashに入れて256x3バイト、カラーパレットはRAMに入れて256x3バイト、画像データはRAMに入れて240x272バイト、他にピクセルバッファが525px x 24line x 2本 x 2バイト(16bit)あります。24ライン分を確保しているのは、可能な限り大きな範囲を一括して変換するためです。2本あるのはGPIOBとGPIOCの分です。


　ブロック図はこんな感じです。

　RAMからGPIOに対してDMAで転送する場合、DMA2を使用する必要があるので、駆動するTIMは1か8になります。今回は1を使いました。

　LEDドライバの輝度の指定にはパルス数を送りますが、タイミング要求が厳しく、遅くても100usec以内を目安にトグルを続ける必要があります。が、10パルスを送るなら2msecほどかかり、この間にDMAからの割り込みが発生するため、ソフトウェアでは転送できません。そのため、今回はパルスの生成にTIM2を使い、TIM2を特定のパルス数(&位相)で停止させるためにTIM3を使用しました。
　TIM2は0分周8400カウントで駆動し、1周期100usecのパルスを作ります。
　TIM3は2100分周0xFFFFカウントで駆動し、CH1に1を指定すればTIM2はLowを出すだけ、7を指定すれば1個目の立ち上がりエッジで確定、15を指定すれば2個目の立ち上がりエッジで確定、というふうに駆動できます。
　輝度の指定(0で消灯、1が一番暗く、32が一番明るい)から直接CH1のパルス長にすることはできないため、ここは変換テーブルを使いました。
　TIM2のスレーブモードはGatedを使用しています。
　ただ、TIM3を駆動する際にTIM2のプリスケーラやカウンタをリセットする必要があり、ここはソフトウェアで実装する必要があるので、タイミングクリティカルになります。なぜか今回は問題ありませんでしたが、TIM2に対するUpdateの生成からTIM3の開始まではクリティカルに指定したほうがいいかもしれません。

　DISPは基本的に触ることがないので、ソフトウェアで制御しています。

　DEはピクセルデータに同期する必要があるので、ピクセルデータと一緒にパラレルデータに埋め込んでいます。

　GPIOCはLSEの接続があり、STBee F4miniでは外に引き出されていません。そのため、GPIOCを16bitバスとして使うことはできません。そのため、GPIOBを16bitバスとして使用し、残りの8+1bitをGPIOCに割り当てています。

　ということで、ようやく液晶の制御と相成りました。

***

　とはいえ、今回は解像度を落とした静止画1枚を表示するのがやっとで、UARTから画像を受け取る、といった基本機能ですら動作しません。
　実用性は皆無です。

　ま、複数のGPIOで、16bitを超える幅のパラレルバスを駆動できるのがわかっただけ収穫、ということで。
　前にTIMでクロック出してGPIOからデータ出したときはうまく動かなかったんだよなー。なんで今回はうまく動いたんだろうか? クロック周波数が低かったから遅延の影響が少なかったのかな?

STM32F446RET

　買ってきた新品のNucleoを開封直後に動作確認もせずに割るやつはそうそう居ないと思いますが、とりあえずUSB DFUで動作確認できました。
　最初動かなくて焦りましたが。U5VじゃなくてE5Vに突っ込んでやらないとだめみたい。U5VはST-Link側のLDOにつながってるのかな? 確認してないですが、とりあえず動いてるので。。

　なんか変だなーと思ったら、USER SWが負論理でやんの。。。
　USER SWとBOOT0を直結しているので、単純なリセットではブートローダーが起動し、ユーザーコードを起動するにはUSER SWを押しながらリセットする必要があります。NOTインバータ挟んでもいいんだけど、それよりBOOT0用のスイッチを追加したほうが楽かなーって気がします。

　STM32F446RETは64pinLQFPなので、STBee F4miniのSTM32F405RETを引っ剥がして載せ替えたほうが楽かな、とも思います。今回はDCMIを試したくて446を買いました。
　STBee F4miniはPD2が出てないのでSDIOが使えませんが、446RETだとDCMIとSDIOが排他なので、SDIOが使えないのは関係ないですし。
　っていうかなんでカメラインターフェースとメモリーカードインターフェースが排他なんだよ。普通DCMIを使うならSDIOも使いたいだろ。と、思うわけですが。まぁSTM32F4でデジタルカメラを作ろうって人も少ないんでしょうね。それならなんでDCMIが乗ってるのか謎ですが。F4の性能だとガッツリ画像解析するには足りないだろうし、どういう用途を想定してるんだろうか。


　コードは以前書いたものと同じですし、STM32Cubeのアップデートも来ていませんが、CDCの接続に時間がかかってるような気がします。
　USBの接続がやっつけなのが原因かな? たかが12MHzでこの程度の配線延長はあんまり関係ない気もするんだけど。
　Nucleo64はHSEの水晶が実装されていないので、手持ちの16MHzと15pFをつけています。LSEは実装されてるのにHSEがないのが腑に落ちない。あとUSBコネクタくらい実装しといてくれやー！！って思います。
　mbedとして使えるならUSB deviceで遊んだりUSB hostで遊んだりいろいろできるはずなので、microUSBレセプタクルくらいあっても良さそうなのに。


　今回は妥協してNucleo F446REを使いましたが、これならSTBee F4miniのチップを載せ替えたほうが楽だと思います。
　Nucleoはピンが連番で出てないので、配線作業もかなり面倒ですし。
　この手間を考えたら、LQFP64pinを実装するほうが楽です。

***

　PICでやりたいことがとりあえず作れたので、そっちは一休みして、しばらくはSTMで遊ぶことになりそうです。
　他にもやりたいことあるんだけどなー。
　なかなか気力ゲージが回復しないので少しずつ。

追記
　Q. なんでPowerLEDが消えてるの?
　A. USBの5VをVDDに突っ込んでるからだよ!!

　まさかのやらかしです。。。

　それでちゃんとコア動いてUSBも接続できてるんだから末恐ろしい。
　あれれー？なんでLED消えてるのぉ～って調べなかったら全然気が付かなかったとおもいます。

　今日はなんかやらかしが多いです。5箇所作業したら2,3箇所はやらかしてるレベル。

　Absolute maximum rangesのVDD-VSS項はmax4.0Vが規定されています。5V突っ込んだら普通死んでますね。まぁ、AMRsは「これを超えると動作は保証しないよ」というものなので、即死ぬわけじゃないと思いますが、かといって無害なわけでもない。

　

　電源の修正のついでにリセットスイッチとユーザースイッチも追加しました。
　オンボードのスイッチはPC13(タンパ検出)ですが、白のタクトスイッチはBOOT0とPA0(Wake-up)に接続しています。リセットスイッチはどちらもリセットですね。
　このスイッチの配線だけでも相当やらかしてます。。。

　昨日やった細かい作業の疲れが残ってるのかな。。。
　年食ったなぁ。。。

PICの謎

　PIC10F222で遊んでる。
　3.3Vで動かしているのだが、気がついたらプログラムの書き込みができなくなっていた。
　5Vだと正常に書き込めるが、3.3Vではなにがしかのエラーが出る。

　最初の頃は3.3Vでも書き込めていた気がするんだが。
　ググってもそういう話は全く出てこない。
　海外フォーラムでそれらしい話し合いがあるけど、いいところで中断している。


　結局、今回はVDDをダイオード経由にして、MCLRは無接続で逃げることにした。
　こうすれば、書き込み時は外部から5Vをブチ込んで、MCLRは無接続なのでプルから外部に高電圧が抜けることもない。
　MCLR(リセットスイッチ)は使わないので、コンフィグでMCLRも無効化する。


　しかしまぁ最初の頃は書き込めていたはずで、なんとも釈然としない。
　PICのFlash? EEPROM? の書き込み耐数はかなりの回数だが、これは5Vの話で、電圧が低くなるほどシビアで、3.3Vあたりでの書き込み耐数は10回程度じゃないのか、という仮設を立ててみた。
　新品のPICでいろいろ試せばはっきりするだろうが、面倒なのでやらない。


　しかしまぁPICは手間がかかる。


　別のとこで書いているのだが、今回作っているもの、「昔のスパイ映画に出てくるようなアイテム」とでも言おうか。映画見てるときは「んなもん」と笑って流していたのだが、自分が作る番になるとそうも言ってられなくなる。
　近年の半導体製品の進化を考えると、昔のスパイ映画に出てきた電子機器はCOTSで作れそうな気配もある。