今日の休日は、UIFlow でブロックプログラミング。
とにかくやってみれば、必要な知識やノウハウなんて、勝手に身に付くんじゃないの・・・？
ということで、毎度おなじみのモールスを鳴らしてみました。
今回使用した M5Stack と Hat
小さな M5StickC に SPK Hat を繋いだだけの、シンプルな構成です。
UIFlow の Blockly だけで、モールスを鳴らす
わたしのコールサイン ”JH1LHV” を３回繰り返してみました。
電源投入後、画面にコールサイン "JH1LHV” を表示する。
ボタン A を押すと、コールサインが鳴動する。
先頭に配置した変数 msg の ”JH1LHV JH1LHV JH1LHV" を一文字ずつ取り出して、その文字に対応したモールスの短点（.）と長点（-）を、関数 dot と dash で呼び出して、音（700Hz）を鳴らします。
文字とモールスの対比は、辞書型としました。
先頭に配置した変数 dot_speed は、基準になる短点の長さで、初期値は 200 と長めです。
最初、この基準となる短点の長さを 60ms にしたんですが、なんかこれでは音は鳴らなくてダメで、徐々に長さを長くして試していったところ、150ms 付近から音は出るようになったんですが、あまりいい音じゃなっかたので、いっそのこと 200ms にしてみました。
Um... これじゃ遅すぎ。
せめて 150 ms で設定できればいいんですが・・・
確か、Arduino IDE なら短点を 60 ms でちゃんと音は鳴ったと思うのですが・・・
これは、今後の課題とします。
Blockly から python に切り替えたところ。
MicroPython で直接記述すれば、こんな程度のとっても短いプログラムです。
ホンネのこと言えば、ムリにブロックプログラムする必要はないんじゃないかって。
画面 UI の設計を楽したいとか・・・
UIFlow のいいとこだけ使って、あとは MicroPython で直書きする。
多分、今のバージョンの UIFlow なら、そうした方が早くプログラムは書けるんじゃないでしょうか。
それでイチバンの問題というか、ただわたしが勘違いしてただけなのかもしれませんが、Blockly から python に切り替えた後に、python プログラムをひと文字でも弄ると、Blockly に戻ろうとすると、「今触った python プログラムは消えますよ！」って表示されて、結局、Blockly には戻れないのです。
Blockly から python に切り替えて触ったプログラムは消えてしまいます。
Blockly に戻る前に、すべての python コードをコピーしておく必要があります。
「python プログラムではこうなってるんだ」って、確認することしかできないので注意が必要です。
Blockly で細かなデータ処理をしようとすると、むしろブロックが煩雑になってわかり難くなったりするので、もしかすると python をそのまま学習するよりも難しく感じてしまうかもしれません。
UIFlow で Wi-Fi で書き込みすると、かなりの頻度で失敗する
これにも泣かされました。
M5StickC のプログラムは Wi-Fi 経由で書き込めるんですが、10回に１回くらいしか成功しなくて、Uploding のままフリーズすること頻繁で、ホントこれにはイライラで、ブロックを配置してる以上にムダに時間が掛かってしまったように思います。
で、このままじゃ UIFlow なんて使ってられないとググったところ、”UIFlow Desktop IDE deployment” という、オフライン版（com ポートで書き込める）のソフトウェアがあることがわかり、早速ダウンロードしてみました。
そしたら、これは最高に Good で。
com ポートを使ったケーブル接続での書き込みなので、まずフリーズすることはないし、Wi-Fi 書き込みに比べて、ホント快適な環境となりました。
ただし、現バージョンは V1.4.3 と、ひと世代前のバージョンなので、M5StickC の UIFlow ファームウェアのバージョンも、このソフトウェアに合わせて、M5Burner で V1.4.3 に書き直す必要があります。
ということで、今日は UIFlow で morse を鳴らしてみたんですが・・・
実用的な速さでモールスを鳴らせない、といった致命的な課題が残ってしまいました。
まぁ、なにか対策を考えてみたいと思います。
