2017年6月4日日曜日

ESP8266マイコンを安定させる方法

ESPマイコンって不安定?

ESP8266が出た当時Wifi搭載マイコンで爆発的に有名になったマイコンを購入してそのままにしてたのですが、Bluetooth搭載になったESP32マイコンが最初から技適対応して秋月で入手可能という事でぼちぼち遊び初めてみたのですが、意外にマイコンが安定してないのなんの。。
ファーム書込み後mシリアルコンソールから出てきたものはException(0)を繰り返していたり、全く微動だにしなかったりパターンは様々ありました。

これ使い物になるのか?って思いつつ試行錯誤して出た結果があるので、メモを残しておきます。


ESP8266マイコンについて

まず不具合でたマイコン使い物ならないって高飛車にならず、まずは扱い方を知るべきでしょう。
新参者なのでたまたま仕様書と実装が一致していない、一般的な使い方ではないなど色々あると思います。
製品として出荷され数も出て次のバージョンも出たりしてるところを見るとちゃんと動かせる方法があるんだという視点で正解を探していくのがこのマイコンを使うためのデバッグ手法だと思っています。

ということでインターネットで同じ不具合に悩まされた言葉を見てみたところ、

・仕様書に書かれている回路になっていない。
・Wifiモジュール起動時の突入電流が1Aくらい出る。

この2点に尽きるようです。

Note: If the power management IC is connected with the power-on enable pin CHIP_EN,
it can control the power on-and-off of ESP8266EX by output high and low voltage through its GPIOs.
However, pulsed current might be produced at the same time.
In order to delay the transmission of pulsed signal and avoid unstable current of CHIP_EN,
a RC time-delay circuit (R=1kΩ, C=100nF) is needed.
There is an internal pull-up in the CHIP_EN pin, so no external pull-up is needed.



CHIP_ENにプルアップ抵抗1kΩと0.1uFのコンデンサ入れとけよって内容ですが、実際プルアップはされてるようなのでコンデンサを追加するくらいで良いようです。

でもこの記事ってESP8266EXなんですよね。。

1つ前のESP8266はどうしたらいいんだって思ったのですが、根本的な理由は2つ目のWifiモジュールが起動したときの突入電流が原因で、CHIP_ENで起動を遅らせようって趣旨のようです。
つまり突入電流を抑えられればいいわけで、、
USBポートは5V0.5A(2.5W)出力なので3.3Vに落としても1A出ないという事から
Exceptionエラーが出るのを繰り返す理由は突入電流分パワーが出せないので
電圧降下してリセットしてしまっているようです。

では対策をどうしようかと思えば、一番簡単な方法で瞬間的な電圧降下さえ防げればいいので、3.3V-GND間にコンデンサを突っ込んでおけば回避できるのではないかっていう事です。

っていうことで家にあったタンタルコンデンサ0.1uFを早速入れてみたところ、見事解決しました。

電気屋さんにきけばもっといい解決策はあると思うのですが、小手先のテクニックで解決するには電源を安定化させるのに尽きそうです。

結論

電源を安定化させろ

でした。

ではでは


2017年5月27日土曜日

ブラシレスモータのコギングやトルクリプル抑制について考察(3)

はじめに

(1)がとても人気だったので(2)を書いたのですが、どうも一時的な人気だったようで需要がないと判断して今回が最後の回となります。
(1)と(2)を書いた後に実はハマっていたハンチング問題を解決することができたというのもあって
そのあたりについても少し触れていきたいと思います。

前回のまとめ

位置情報を微分すると速度になり、速度を微分すると加速度になり、加速度を微分すると加加速度になる。
加加速度を積分すると加速度になり、加速度を積分すると速度になり、速度を積分すると位置情報になる。
まず、この仕組みのどこを制御すればよいのかを考えます。
制御対象について
位置制御の場合、当然「位置」ですが、
位置を制御するには速度が必要で、
速度を制御するには加速度が必要で、
加速度を制御するには加加速度が必要、、、

上記の事を考えずにモータに電圧を流せば回るのですが、
一体何を制御しているのでしょうか。
最初に答えを書いてしまうと、
 最終的には加加速度を制御している
という事です。

まずブラシレスモータをコントロールするのにPID制御を使います。
このPID制御は、指示量Pは速度を指していて、Iは加速度の積分なので速度になるので
速度制御だという事が分かります。

では位置制御を行う場合、速度制御なPID制御で行えるかというとうまくいきません。
なぜかというと位置と速度は位相が90度ずれているからです。
PIDのゲインを最適値にすることである程度狙って位置で止まれるようになりますが、
外乱の影響などで条件が変わると最適な結果が得られません。
ではどうするかというと、速度制御の先の加速度を注目します。

加速度はΔt時間に進んだ時間であり、位置と180度位相がずれているパラメータです。
速度とは90度位相がずれています。
速度制御で位置をもとめようとどうしても止めたい位置で止められないというのは
位置と速度は90度位相がずれているからなので、
位置制御は加速度制御を行って速度を求めればよいわけです。

ハンチングを抑制するには

この問題は上の例と同じやり方で考えれます。
ハンチングは目標位置で止めようと頑張った証であり、
目標位置を何度も往復してしまっている状態です。
速度を落とせば収まると思っても加速度があって滑ってしまい
結果ハンチングとなってしまっているとも言えます。
ではどうやって収束させるのかを考えます。

・速度=0、加速度=0になれば完全停止になる。
・目標位置で止めるには速度が必要になる。

つまり、加速度=0な速度を作れれば良い事が見えてきます。
では加速度=0にする方法はどうすればいいんでしょうか。。
もう上の内容をおさらいすると答えが出てきます。
上の方式以外でFFTを用いたりZ変換したりいろんな研究は手法があるので
色々とやってみるといいと思います。


2017年5月24日水曜日

[UWP]VS2017でAdControlを用いて広告を挿入するには

はじめに

SDKをインストールするやり方がありましたが、VisualStudio2015までのやり方で
VisualStudio2017ではインストーラでインストールすることができません。
新しいやり方はNugetからインストールになります。




手順


Step1.Nugetから必要なライブラリをインストール

Nugetを開いたら
「Microsoft.Services.Store.SDK」
を検索して追加する。

Step2.参照の追加

参照マネージャーを開き、「Universal Windows」→「拡張」を開き
「Microsoft.Advertising.SDK fot XAML」にチェックを入れてOKボタンを押します。

これで設定完了です。
後は今まで通りに
XAMLを開き、
最初のPageタグの属性に
xmlns:UI="using:Microsoft.Advertising.WinRT.UI"
を追加する。
広告挿入は、

        

のようにする。

もし「クラスが登録されていません」というエラーが出た場合は
ビルドターゲットを[x86]や[x64]など切り替えると解消されるようです。

思った事

ここまで書いて1つ気づいたのが、ようやくAdControl挿入で広告が表示されるようになった事。
今までエラーしか返ってこなかったのでCreators Update以降になって1つ前進した感じがします。
あとは額面でAdmobよりレートの良いものとなってほしいです。
感覚的には今はAdmobの10分の1くらいなんじゃないだろうかってくらいしょぼいです(´・ω・`)


参考URL

https://docs.microsoft.com/ja-jp/windows/uwp/monetize/microsoft-store-services-sdk#a-nameinstall-the-sdkasdk-のインストール



2017年5月22日月曜日

アニサキスには正露丸が効く(動きを止める)

アニサキスとは、サバなど解鮮魚の中にいる寄生虫である。
普段は胃に入っているが捕まえて魚が死んだとき、胃壁を突き破って身の中に入ってくる事が原因のようだ。
知らずに鮮魚を食べてしまうと人間の胃の中に入ってしまい、胃の中に入ったアニサキスは胃壁を突っついてしまう。
胃には神経がないので痛くないのだが、アレルギー反応を引き起こすことで胃に激痛が走るようだ。
 

この対処方法の1つとして、、
2017年5月22日の羽鳥慎一のモーニングトークショーの特集でやっていたのですが、

正露丸が効果あるようです。



番組の紹介によると、

正露丸の特許を取る時に科学的実証実験を行った効果、
アニサキスの動きを抑制する効果がある

しかし薬事法の関係で明記することはできないようなので、こういった番組で紹介してくれるととても有益な情報だし、いざ自分がなった時にセルフケアができるのはいいですね。




2017年5月20日土曜日

人感センサーHC-SR501を使ってみる



Aliexpressで送料無料で1$切ってる人感センサーHC-SR501を購入してみた。

製品仕様



  • 電源電圧:DC5-20V
  • 待機時消費電流:65μA以下
  • 出力電圧:3.3V
  • 動作モード:L=リピートOFF、HはリピートON(デフォルト)
  • 遅延時間範囲:0.3秒から18秒
  • 待機時間:0.2秒
  • 基板サイズ:32mm*24mm
  • 検知角度:120度
  • 最大検知距離:7m(気温等の環境条件により変化あり)
  • 操作温度:-15~+70℃
  • ネジ穴:2mm、28mm間隔
  • レンズ:直径23mmドーム型

  • 回路図やピンアサインの情報は上記Amazonで並行輸入販売してる人や使い方Q&Aも載っていてぜひ覗いてみてください。

    データシートやサンプルプログラムなどはココにありました。
    上記製品仕様も引用させていただいております。

    簡単な使い方

    この人感センサーはシンプルで入力は5V300mA程度の電源に3.3V出力のピンの3つだけです。感度調整やON維持時間はトリマーで直接調整します。

    これを使って部屋の照明に人感センサーを取り付けてON/OFFさせたり、玄関で人が来た時に照明をつけたり、RaspberryPiを使えばIoTと称して人感センサーの反応をWEB上に通知したりカメラも取り付けて監視カメラにしたりできる事が増えて夢が広がりますね。

    もちろんArduinoでも使えます。
    使う場合は5VとGNDと入力ポート1つ使う程度のものなので、通信処理も書かずに簡単にできます。Lチカの入力ポート版と同じレベルですので是非実験に使ってみてはいかがでしょうか。

    参考サイト

    http://henrysbench.capnfatz.com/henrys-bench/arduino-sensors-and-input/arduino-hc-sr501-motion-sensor-tutorial/



    2017年5月15日月曜日

    ブラシレスモータのコギングやトルクリプル抑制について考察(2)


     意外とブラシレスモータの話にアクセスが多かったので前回の続きをもう少し掘り下げて書きたいと思います。


    まず、ブラシレスモータを3相UVWで回せるようになって位置制御や速度制御をしようとしたとき、ハンチングや速度のムラが生じてきます。


    制御の難しさ



     論理的にはあっているはずなのに、、

    と思っても

     CPUからの回転指令は電圧
     モータの実動作は電流
     ブラシレスモータはコイルで磁界を作る
     コイル特性
     磁界ムラ
     回路誤差
     外乱の影響
     ギアボックス特性
     、、、

    考え出すとものすごくたくさんの要因があって、それをPID制御で動かそうとなると
    Pはすぐ解決するけど、I=全外乱の影響の累積値となり、D=側近の反発力
    それが回転するたびに波打つように値が変化していて
    フィードバック制御で行っているのでどうしても制御遅延が生じてしまう。

    これが意外と致命的な結果となり、ハンチングや速度のムラとなります。

    じゃあフィードフォア―ド制御で解決すればいいじゃん!ってことで
    世の中には色んな論文が出ています。
    主な例としては、過去のデータをフーリエ変換(FFT)して周波数特性でピークとなっている周波数成分を足すことで解決するという技があります。
    実際、電流のムラが2倍近く改善しているので有効手段です。
    が、しかし低スペックマイコンで制御するには若干パワー不足な面もあります。
    そこでより原始的な方法で解決する手段を書いていきたいと思います。

    SIN・COSの性質


     意外とこれが簡単で一番難しい部分です。
    ちなみにSINやCOSを微分するとどうなるでしょうか。
    高校生の数学で習うようですが完全に忘れてました。

     積分すると位相が90度遅れる。
     微分すると位相が90度進む。

    らしいです。

     電気回路では
     90度遅れる=コイル
     90度進む =コンデンサ

    です。

    ここで電気回路と数式が一致しました。
    ここからが本題です。

    ①モータ部

    ブラシレスモータはコイルでできているので、
    CPUからの指示に対して90度遅れる。

    ②制御部

     位置(0度)を微分すると、速度(+90度)になる。
     速度(+90度)を微分すると、加速度(+180度)になる。
     加速度(+180度)を微分すると、加加速度(+270度)になる。

     速度(+90度)を微分すると、位置(0度)になる。
     加速度(+180度)を積分すると、速度(+90度)になる。
     加加速度(+270度)を積分すると、加速度(+180度)になる。


    微分と積分

    基本は速度制御で速度指令を行うと、結果が90度遅れの位置となる。
    この性質を利用することで位置制御が行える。

    ③CPU部

    ・位置制御  ・・・ 位置を基準に速度を調節する。
     ・速度制御  ・・・ 速度を基準に加速度を調節する。
     ・加速度制御 ・・・ 加速度を基準に加加速度を調節する。


    実際は加速度制御まではやらなくて良いので、今回は位置制御と速度制御に焦点をあてていきます。

    モータはコイルなので必ず指令に対して90度ずれます。

    例えば

    速度制御の場合、
    速度指令にCos波を入力します。
    すると加速度は90度遅れるのでSin波となって出力します。

    実動作を見るとどうなっているでしょうか。
    進んだり、戻ったりを繰り返すと思います。

    位置制御の場合、
    指定位置を気にしなければ速度制御と同じになります。

    指定位置を気にすると若干ややこしくなります。
    どういうことかというと速度制御でも示したように
    加速度は90度遅れているのです。


    という事は
    速度指令に0を入力しても、加速度≠0ならば急には止まれず
    必ず90度位相分遅れて止まります。

    位置制御の難しさはここにあります。


    具体的な解決方法としては、この90度位相遅れを加味したSin波を入力してあげればよいのです。(言うのは簡単)

    どういうことかというと、
    ベースのSin波に狙った位置で止まるSin波を合成させてやります。
    するとベースのSin波を0にしたとき、90度遅れで止まるのは変わりないのですが、狙った位置で止まるようになります。

    位置制御はこうやって行います。
    もう少しヒントを書くと速度制御+加速度制御が位置制御になるような感じです。


    今日はここまで。




























    2017年5月10日水曜日

    ブラシレスモータのコギングやトルクリプル抑制について考察

    しばらく悩んだ内容をメモします。

    続編書きました。

    ブラシレスモータのコギングやトルクリプル抑制について考察(2)



    コギングとは

    低速回転でベクトル制御(D=1、Q=0)で回転させたときに発生する回転のひずみ。


    トルクリプルとは

    ベクトル制御(D=0、Q=1)で回転させたときに発生する回転速度のムラ。
     応答遅れなどによる時定数があるので、即応性が得られず遅延を考慮する必要がある。


    コギングの問題

    ・静止時の位置決めの精度に影響を及ぼす。
    ・回転時のトルクリプルに影響を及ぼす。


    コギングの補正案

    ゴール:ベクトル制御(D=1、Q=0)できれいな円を描けるようにする。

    成功案

    ・UVW出力波形に第3高調波成分を付加することで回転の動きが変わる。

    失敗案

    ・ベクトル制御(D=1)は固定してQ成分を付加するとモータが音鳴りする。
    ・ベクトル制御(Q=0)は固定してD成分を変動させても効果がない。


    トルクリプル補正案

    ゴール:ベクトル制御(D=0、Q=1)で速度を一定にする。

    成功案

    ・速度制御、加速度制御の2ブロックで制御する。

    未検証案

    ・フーリエ変換を用いてUVW波形を生成する。




    加減速について

    制御の視点をどこに置くかで変わるし、外乱の影響や遅延時間がとても影響していて何とも言えない部分。


    加速側

    ・タイムチャートの時系列を基準に制御した時、外乱の影響や遅延時間を考慮しなければならないので現実的ではない。
    ・現在速度を基準に制御した時、タイムチャート通りの変化は得られないが外乱の影響や遅延時間を考慮しなくてよくなる。

    減速側

    ・タイムチャートの時系列を基準に制御した時、減速中にもかかわらず加速したり減速したりして波打つ。
    ・現在速度を基準に制御した時、最初の遅延時間が影響して遅れて減速が始まる。
    ・停止位置を考慮する場合も遅延時間が影響して最適な速度が得られない。


    まとめ

    以上の問題1つ1つが悩ましい問題で、モータ固有の特性も考慮しなくてはならないし、すべてが明確な解決方法というのが存在しない。
    こういう自分は画像処理のフィルタ処理を思い浮かべて考えている。
    画像処理にはノイズだらけの画像をきれいに見せるのにメディアンフィルタやソベル、ラプラシアン、ガウシアン、NL-Meanなどいろんなフィルタがあり、これらフィルタリング技術はそのままブラシレスモータにも転用できるからである。
    ブラシレスモータの場合、フィードバック制御内で計算するので、計算処理自体軽くする必要があるので、軽くて一番効果が期待できるメディアンフィルタが一番最有力。本来はガウシアンフィルタにしたいけど、計算量が増えるのでまだ導入はしていない。
    あとオーディオ関係のノイズフィルタでKL法というのがあり、これも試してみたところではある。


    最後に色ぶつかって通ってきた道のりを書いておきます。

    レベル1.モータを動かすまで
     ブラシレスモータを扱うにはまずUVW3波出力する所から始まります。
    その次にFETのターンオン・ターンオフ時間、デッドタイム補間を行わないといけないのが分かってきます。
    それらを攻略してオシロでUVW波形を見てみるといびつな波形をしてて訛っています。
    これが先ほどのデッドタイムの影響+回路上の誤差。
    これが個体ごとに異なっているのです。
    単純にUVW波形を出力するのからPWMのスイッチング周期時間とUVW波形のセクタを考慮してタイミングの調整が始まります。
    調整が終わるとモータの出力トルクの改善が実感できます。

    レベル2 回転を制御する。
     ここでベクトル制御の実装が始まります。
    ベクトル制御はD,Qの値で回転指令するものなので、そんな難しく考える必要はないです。
    まずは現在の電気角、これをDベクトル、電気角を基準に進角方向をQベクトルとします。
    これをDQ変換とか、AB変換など単語が出てきますがレベル1で作ったUVWテーブルがあれば、角度とDQ値さえ分かればなんとかなります。

    レベル3 速度制御する。
     ベクトル制御ができるようになったので、D=0、Q=1指令すると回転します。
    もちろんQの値を弱めれば遅い回転になっていると思います。
    しかしよく見ると回転ムラがあることに気が付きます。
    ようこそ、ここが樹海の入り口です。
    そのムラはトルクリプルといいます。詳細は上へ。。


    レベル3 位置制御する。
     モーターを回すだけじゃもの足りなくて、電気角で現在角度が分かるならモータで位置制御ができるだろうという考えで進みます。
    位置制御というのは、目的地点まで移動させ停止させるものですが、これが意外と厄介。モータの遅延時間というのが存在するという事に気が付く。
    目的地でD=1、Q=0にすればすぐ解決するのだが、モーターが発熱するのでD=0、Q=1で目的地で静止させたい。そんな欲望丸出しで突き進むと回転させるベクトルを停止させるにはモータの遅延時間を予測して外乱とモータ出力を均一化する作業となる。
    さらに低出力で低回転させてると途中で止まってしまう問題と出くわすと思います。
    ようこそ、ここが樹海の入り口パート2です。
    その止まってしまうのはコギングといいます。詳細は上へ。。

    レベル4 高効率化へ
     レベル2とレベル3が割とヘビーな問題でレベル1が全部ひっくり返すくらいのインパクトを持つ問題点なので、どの程度までチューニングするかは人によると思います。
    大型モータを扱わなければ特に気にしなくてもいいのですが、世の中にはVVVF制御というものがあります。最近の鉄道関係はこのVVVF制御で音階ドレミを鳴らしたりMIDIを再生したりモータを楽器にして動画にしてる人がいてびっくりします。
    このVVVF制御というのはPWM周期をいじって低回転の時は大電流を流して、高回転の時は小電流にしようという技です。
    具体的には電圧÷周波数を一定になるように変化させていきます。電圧を強くすれば音が強くなるので遊びながらいじってみると楽しいですよ。


    続編書きました。

    ブラシレスモータのコギングやトルクリプル抑制について考察(2)


    2017年4月17日月曜日

    [UWP]RaspberryPi3にインストールしたWin10IoT Coreのスタートアップを変える

    RaspberryPi に Windows10 IoT Core を入れてみた。


    Windows10 IoT Coreのインストールまで


     前回は、OSのインストールからUWPアプリの開発Helloworldまで行いました。

      [UWP]RaspberryPi3にWindows10IoTをインストールする 

    今回はその続き、作ったアプリのスタートアップさせるにはをやっていきたいと思います。
    スタートアップするにはPCからWin10IoTCoreへリモートログインする必要があります。
    まずはリモートログインの仕方から進めたいと思います。


    リモートログインの仕方


     Win+Xキーを押して、Powershell(管理者)を起動します。

    Win10IoTをインストールした時のPC名をminwinpc として話を進めていきます。

    Pingチェック

    まずは、Pingをやってみて返事が返ってくるかチェックします。

    ping minwinpc

    返事あれば次へ進みます。
    返事がない時はネットワークの設定をチェックしてみてください。


    信頼するPCに登録

    これは一回やれば問題ないです。しなかった場合、接続拒否になります。

    net start winrm
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value minwinpc


    リモート接続開始


    Enter-PSSession -ComputerName minwinpc -Credential minwinpc\Administrator

    上記コマンドを入力してパスワード入力画面が出てきます。
    ログイン成功すると、

    [minwinpc]: PS C:\Data\Users\administrator\Documents>


    コンソール画面に上記メッセージが表示します。

    スタートアップの登録と戻し方
     試しに最初から入っているHelloworldをスタートアップに登録してみます。

      iotstartup add headed Hello

     最初に表示してたダッシュボードに戻す場合は、

      iotstartup add headed IoTCoreDefaultApp

     このコマンドで元に戻せます。


    これでもうWindows10 IoT Coreの開発~専用端末化までできるようになりました。


    最後にリモートログインした時に使うコマンド一覧を載せておきます。

    コマンド一覧


    デバイス名変更 setcomputername 新しい名前

    アプリ一覧表示 iotstartup list

    スタートアップアプリの登録 iotstartup add headed Hello

    スタートアップアプリを戻す

     iotstartup add headed IoTCoreDefaultApp

    再起動 shutdown /r /t 0

    参照URL






    2017年4月15日土曜日

    FreeRTOS入門(1)

    FreeRTOS入門(1)

    RTOSって何?

    身近なOSであるWindowsやMACのデスクトップを見てください。CPUは1つなのに複数のアプリが同時に動いていますよね。
    これがOSの役割でマルチタスクという機能です。

     昔のWindowsなら何か1つ固まると全体がフリーズして何も操作できなくなる事態がありましたが、RTOSだとフリーズしません。
    こんな事を書くと
    今あるすべてのOSはRTOSであるべき

    と思ってしまいますが、そうでもないんです。
    そのあたりの詳しい話は後の方で説明します。

     この記事を見る方はマイコンで利用を想定していると思いますので、RTOSの定義について少し触れたいと思います。
    そもそもマイコンOSとWindowsOSを比較してもマイコンにはUIが無いし、スケール感が異なるのでイメージが結びつきません。

    そこで、
    • デスクトップ=マイコンボード
    • アプリ=マイコン
    • 機能=タスク
    というように言葉を定義すると、

    マイコンボード上に様々なICやCPUが乗っていて、それらはいろんな機能が入っている。

    こう考えれば、マイコンOSの実態が見えてきてイメージしやすくなります。

    マルチタスクの種類について

    最初の方でもう少し掘り下げて説明しときます。
    マルチタスクには
    • プリエンティブ
    • ノンプリエンティブ
    という2つの種類があります。

    プリエンティブとは、ハードウェアタイマーを使ってマルチタスクを行う方法で、
    ノンプリエンティブとは、タスク内部で明示的にタスク切り替えタイミングを指示してマルチタスクを行う方式です。

    両方ともメリットデメリットがあります。
    プリエンティブだとタイマー周期に依存して処理を切り替える

     メリット

    • 確実に同じ周期で処理が開始される

     デメリット

    • 本気でリアルタイム処理したいものが処理できない
    • タスク別にPC・レジスタ退避など行うので処理コストがかかる。

    ノンプリエンティブだとタスク切り替えはタスク依存なので

     デメリット

    • タスク毎に均等な処理時間が回せない
    • 本気でリアルタイム処理したいものに処理時間が渡せる

     メリット

    •  スケジューラは非常にシンプル

    相反する関係になっています。
    もちろんRTOSでどちらを使うか選べるので、システムに合わせて選びましょう。

    タスクの定義

    RTOSでタスクを作るといってもどの程度の粒度が最適なのか人それぞれ見方が変わってきます。何かルールがあればそれに沿って従うまでなんですが、何もない時は単機能だけに絞っておくとよいです。
    単機能の例
    •  タスク1=500ms周期でLチカさせる
    •  タスク2=シリアル通信する
    •  タスク3=LCD制御する
       ・・・
    このように粒度が単機能に絞ってあると、他のプロジェクトで似たような処理があったらコピペできるので生産性はUPします。

    もちろんOS無しの場合も移植できますが、タスクの粒度のように均一でないケースがほとんどです。

    コピペしようにも他のいらない処理が入っていたり、、
    1処理で完結しないで他の処理に依存していて芋づる式になっていたり、、

    素直にコピペで動くようなものが少ないと思えます。

    タスクの書き方

    ここではOS無しとRTOSを使った場合を比較しつつ実装例を書きます。

    タスクの粒度は両社どちらも同じものだとします。

    OS無しの場合

    タスクの中をswitch-case文で軽い処理単位に分割(いわゆるシーケンス処理)
     それをメインループでタスクを順番に処理する。
     これがノンプリエンティブ型です。
     プログラム内部で1処理行ったら抜けて次の処理へと渡していきます。
     処理コストは関数コールとSwitch~Case部分になります。

    コード例:
    void main() {
        init();
    
        for( ; ; ) {
            task1();
            task2();
            task3();
        }
    }
    

    RTOSを使う場合

    タスク単位に何も気にせずそのままコードを書ける。
     これがプリエンティブ型です。
     タスクの切り替えはハードウェアタイマーの割込み処理で行います。
     もちろん切り替える際は、タスク毎にレジスタ、プログラムカウンタなど回避するのでその分コストはかかっています。

    コード例:

    void main() {
        xTaskCreate(task1, "task1", 128, NULL, 1, NULL);
        xTaskCreate(task2, "task2", 128, NULL, 1, NULL);
        xTaskCreate(task3, "task3", 128, NULL, 1, NULL);
    
        vTaskStartScheduler();
        for( ; ; ) ;
    

    見慣れないものはFreeRTOSのAPIです。
    タスクを作る。スケジューラを動かすの2つをやっています。


    ちなみに国産OSのTRONと呼ばれるものも基本同じ作りです。ほかに独自の機能が備わってたりして便利だったり複雑だったり好みが出てくる部分ですね。

    TronOSはがんばってほしいけど、1000円くらいのボードで気軽に試せる環境がないのでホビーユーザ数が増える事はないですね。。せめてArduinoスケッチでライブラリも実行できるところまで来たら触れるのにもったいないです。

    2017年4月14日金曜日

    [UWP]RaspberryPi3にWindows10IoTをインストールする


    RaspberryPi3上で動いてるWindows10IoTの起動画面

    Windows10IoTのメリットは?


     Win10IoTが出た当初はWindowsサービスをいじったり手間のかかるもので、

    環境構築でこんな手間必要?

    って思うくらい最初のビルドを行うだけで数十分かかるものでした。

    そういったこともあってすべての機能が解放されてるRaspbianを使う方が一般的でした。
    2017年Creators UpdateでWindows10IOTもバージョンアップされたようです。
    音声認識のCortanaに対応したようなので、「Ok Google」や「Amazon Echo」のような事が自分で作れるようになるみたいで、

    これだけでご飯3杯いけるくらい期待値大です。

    使うメリットが出てきました。(音声認識を使うにはオンライン環境が必須)


    環境構築


    Step1.Windows10IOTイメージをSDカードに入れる



    にアクセスします。

    Windows10IOTダッシュボードをダウンロードして実行します。
    どのSDカードにインストールにしますかと聞かれるのでインストールするドライブを選択してボタンを押すと、イメージのダウンロードからインストールまで自動でやってくれます。

    今回使うテスト環境は、
    RaspberryPi3とラズパイ専用7インチパネルを使いました。
    キーボードは静音のものを使っています。
    時々家で飼ってる猫が膝で寝てくるのですが、タイプ音がうるさいらしくフニャーって怒られるので、マウスも静音を使ってます。







    Step2.最初のセットアップを行う

     出来上がったSDカードをRaspberryPi3に入れて実行します。

     Windows10をインストールした時のように、最初にネットワークの設定やMSアカウントの入力などが求められます。
    無線LANの設定もできるので、USBキーボードを繋げて設定します。

    まだまだ開発途上のようで

    日本語と英語が混ざっていたり、
    時計が日本時間(GMT+9)に設定できなかったり、
    キーボード配列がUSだったりしますが

    気にせず進めてください。
    日本語・英語表記は治るまで待ちます。
    唯一キーボードの設定は後で変更できます。

    時計設定は、コマンドラインを開いて
    ・タイムゾーンの確認
     tzutil /g

    ・タイムゾーンを日本時間にする
     tzutil /s "Tokyo Standard Time"

    ・タイムゾーン一覧表示
     tzutil /l

    で行います。


    過去にこういう不具合を報告した事があるんですが、個人の意見なんてミジンコ以下で全く取り合ってくれなかったです。
    なので、
    治るまで待つより使い物になるまで無視

    できないものはできないんだって気持ちが大切です。


    Step3. HelloWorld

     チュートリアルにボタンを押すだけで遊べるアプリがいくつかあるので、それでテストできます。

    Step4.VisualStudioで新規プロジェクトを作って実行する

     UWPなら何でも良いみたいなので、今回は

      クロスプラットフォームアプリ(Xamarin.Formsまたはネイティブ)

    を選びました。
    新規作成するとUWP、Android、iOSのサブプロジェクトが次々と作ってくれます。
    UWPに関しては恒例のライブラリエラーが出るので、
    プロジェクトが開いたらまずは

    ファイル→すべて保存

    その次に

    Nugetのパッケージ管理→すべて更新

    新規プロジェクトした後に必ず行うおまじないです。

    更新が終わったらいよいよ実行します。

    ビルド設定で
     AnyCPU→ARMに変更
     Device→リモートコンピュータを選択して接続するデバイスを設定

    を行い、
    リモートコンピュータボタンを押すとRaspberryPi3環境にイメージが転送されます。

    UWPで毎回思うんですが、
    最小サイズが20MBあるんです。

    デバッグ開始まで
     無線LANの場合は約30秒
     優先LANの場合は約20秒

    くらいかかりますが、
    しばらくするとXamarinアイコンのスプレッド画面が表示された後にアプリが起動します。



    まとめ

     UWPアプリなら何でも動くようです。
    Xamarinが動くんだからAndroidの組込みにも対応できそう。
    デバッグはPCで行って、実機は簡単な動作確認で済むようなテスト計画はあらかじめに決定しとくと楽かも。
    今回のCreators updateで使える所まで来てるが、時計設定はどうにかならないかな。。
    あと再起動ボタンは地雷ボタンです。



    参考URL



    続き


     [UWP]RaspberryPi3にインストールしたWin10IoT Coreのスタートアップを変える 




    2017年4月11日火曜日

    [STM32]STM32マイコンの選び方

    マイコンの型番一覧


    STM32マイコンって安くて高性能

    Arduinoを使っている人はそのままアップグレード版として使ってもいいんじゃないかってくらい高機能マイコンです。
    FreeRTOSを使えばすべての機能をフル活用できるのでポテンシャルはかなり高い。

    そんな中、マイコンボードを買うにあたってまずは値段、次はピン数やROM容量が気になりはじめ48pinじゃ足りないって自体に陥ってしまったので一通り見てすぐわかる一覧表をまとめました。


    型番早見表

    103T* 36pin
     103C* 48pin
     103R* 64pin
     103V* 100pin
     144Z* 144pin


    *の部分はROM容量
     4=16kB
     6=32kB
     8=64kB
     B=128kB
     C=256kB
     D=384kB
     E=512kB
     F=768kB
     G=1MB

    ざっくり見るなら、
     安いマイコン:STM32F103C8T6(F103Cシリーズ)
     ピン数多め:STM32F103R8T6(F103Rシリーズ)

    容量不足に思ったら、「*」印の8がBになる。


    マイコン仕様はドキュメントは参考リンクを見てください。

    参考リンク

    http://www.st.com/en/microcontrollers/stm32f103.html?querycriteria=productId=LN1565

    [Win]開発環境周りの整理と最善の選択肢とは



    現在のプラットフォームはまさに戦乱時代!

    昔は開発環境自由で悪い事もかなり沢山あるけど選択肢が少なくて良かった。。
    今は、
    ワンソース・ワンバイナリでできるよ!この言語ならね。俺んとこ来いよ!

    という思想の下でプラットフォームの囲い込み合戦が開始されている。

    今まではデスクトップ最強主義でパソコン=デスクトップという概念から、
    技術の進化で小型化が進んでスマホ・タブレットという分野が新しく開拓された。
    この先陣を切ったのがapple。
    WindowはフォントボロボロだけどAppleはしっかり美しさを全面に押し出し高級感とともにイメージ戦略に成功した感がする。

    一方Androidは2判煎じだが、開発者向けの費用は安く参入できるようコミュニティの活性からスタートして、未完成ながらもバージョンアップを繰り返し、速度で押し切りシェアを獲得したが、やや端末の屍はやや多い感がする。

    この分野で最高の地位を確保していたMicrosoftだが、大企業病が発症したのかすべてにおいて出遅れてしまい、ハンズオン分野のシェアがほぼ埋まってしまって割って入る隙間が無くなってしまった。
    未開拓領域でいえば新興国向け市場だが、ここに割り込んでも多勢に無勢。
    何か挽回の策を講じる必要がありそうだ。

    最後にLinux。
    Ubuntuが作ったGnome3はコミュニティで賛同が得られず、今年で幕閉めとなってしまった。
    悲しい結末だけど、ようはエコシステムなんだよね。

    人は儲かるか儲からないかで動く人は少なからずいる。
    そのプラットフォームで活動することで何らかの対価が得られなければ開発者たちは新たな新天地を求め去って行ってしまうんだろう。

    という事で、今回のテーマはプラットフォーム。

    UWPについて

    WindowがinRT系列でUWPを作って、WinストアでWindows製品の様々な機器で使えるよというエコシステムを作った。
    このUWPが若干曲者で、過去の資産をバッサリ切ってリファクタリングと称して現代にあったスタイルに開発環境を再構築しているようだ。
    昔からの開発者にとって迷惑だが、時代の流れなんだろう。
    というか、レガシー世代からすると新しい世代が開発すれば気にならないので若い人たちは技術の習得にいそしんでほしいといったところか。


    プラットフォーム選びについて

    色々あって迷う。
    そんな迷う時間がもったいないので、各OSやターゲット別の一覧表を作ってみた。



    Windows開発環境から見た開発環境の図

    これからアプリを作りたいなって思った時、どこをターゲットにするかを考える必要がある。そこでいろんなケースを書いてみる。

    VisualStudio環境で
    • ゲームを作りたい。→Xamarin
    • いろんなWindows製品で動かしたい。→UWP
    • Win7とかでも動くWindowsデスクトップアプリが作りたい。→WinForm
    • モバイル開発がしたい→Xamarin
    • OS問わずデスクトップで動くアプリを作りたい。→Electron
    もちろんCordovaやASPや.Net coreなど他のケースも色々あるが、個人的にいろんな開発環境を触ってみて安定していて比較的迷わず素直に作れるものだけを選別してます。


    いろんなケースを書いてみてもまだ見づらいですね。。
    さらにおおざっぱにまとめると、
    • デスクトップ=Winform、UWP、Electron
    • モバイル=Xamarin、Android、Swift
    • IOT=なんでもよし
    こんな具合です。
    参考になっていれば嬉しいです。

    2017年4月9日日曜日

    Dockerの使い方

    今回はコマンド編



    Dockerって本当に便利?

    前回はインストールを行い、軽くコマンド操作してDockerの使ってみてどういうものが分かってきた。
    でも分かってくると、

     これってDockerじゃなくてもVMWareやVirtualBoxのようなVMでいいじゃん

    って思うようになった。
    この疑念は次の文章で解消される。

    VMを使うときってイメージのバックアップや起動・停止もランチャー操作で簡単にできるし不便な事は何もない。
    DockerのGUIは使った事ないけど、ネットワークの設定はHyper-VだしVMとやってる事はほぼ同じ。なのになぜ騒がれているんだろう。
    この疑問はDockerって新しい技術は使われていないという部分を意味している。

    他、様々な情報をまとめていったら見えてきた答えが1つある。
    VMとDockerの決定的な違いは

    DockerはGitHub技術がベースになっている事

    これに尽きる。

    VMの場合はOSイメージをダウンロードしてから仮想環境のイメージを作ってパッケージインストールする一連の手間と時間がかかる。
    一方、Dockerの場合は、

    Dockerイメージを取ってくるだけ。

    いいものができたらGitHubにアップロードして貢献することもできる。
    Dockerコミュニティーは楽させようと献身的な人たちやドヤ顔( ・´ー・`)が大勢いるので、Gitな我々(Hub)はその恩恵にあずかれる分けである。


    Dockerの概要

    今日インストールばかりだけど、Dockerを色々触って感じたまま図にしました。
    間違ってる箇所もあるかもしれませんが、大体こんな感じ。

    Dockerの全体図

    Step1.GithubからDockerイメージをPullする。
     Step2.DockerイメージをRunする。(コンテナ生成)
     Step3.コンテナをいじくる。(1サービス1コンテナ単位)
     Step4.いじくったコンテナをイメージ化する。(Step2へ)

    今までならホストOSの中にパッケージを詰め込んで環境構築して、
    その中に複数サービスを入れてバージョン管理を気にしなければならなかった。
    Dockerの場合はコンテナにパッケージを詰め込むので、

     1コンテナ=1サービス

    という考えになってくる。
    つまり、Dockerのマスコットキャラであるクジラの絵のようにホストOSにコンテナを積むという感覚になり、パッケージ依存もコンテナ内で完結しているから他サービスに影響しない。
    つまり便利である

    覚えておいた方がいいコマンドについて

    ざっと下にコマンドを並べてみました。
    上の図をみて分かる通り、

    GitHub ⇔ ローカルPC(Dockerイメージ ⇔ Dockerコンテナ)

    というように3つのブロックに分かれている。

    Dockerコマンド体系はごった煮状態で区別つかないので分割してコマンド一覧を書きました。

    Dockerイメージ系コマンド一覧

    dockerイメージ検索

     docker search [検索ワード] 

    dockerイメージ取得

     docker pull [dockerイメージ名]

    取得したdockerイメージ一覧

     docker images

    取得したdockerイメージの削除

     docker rmi [dockerイメージ名]

    ---------------------------------

    コンテナ系コマンド一覧

     

    コンテナ作成&アタッチ

     docker run --name コンテナ名 -it [dockerイメージ名]

    コンテナ一覧

     docker ps -a

    コンテナ削除

     docker rm [コンテナ名]

    コンテナにアタッチ(exitすると停止)

     docker attach [コンテナ名]

    コンテナにアタッチ(exitしても起動状態)

     docker exec [コンテナ名]

    コンテナ起動

     docker start [コンテナ名]

    コンテナ起動&アタッチ

     docker start -a [コンテナ名]

    コンテナ停止

     docker stop [コンテナ名]

    コンテナ即時停止

     docker kill [コンテナ名]

    ----------------------

    コンテナ→イメージ化


    コンテナ変更内容

     docker diff [コンテナ名]

    コンテナのコミット(イメージ化)

     docker commit [コンテナ名] [作成するイメージ名]

    変更履歴

     docker history [コンテナ名/イメージ名]

    ----------------------

    Dockerイメージをアップロード


    githubにログイン

     docker login

    githubにプッシュ

     docker push [イメージ名]



    コマンド一覧を書いて思ったこと


     Dockerイメージとコンテナの仕組みさえ分かってしまえば、
    • パッケージ管理(apt-get, yum, npmなど)
    • GitHub
    • Linuxコマンド
    を使ったことがあれば感覚で使えるようになっていた。
    あとはオプションコマンド。
    コマンド毎に色々あるし、ここはやはり人海戦術的に

      使って覚えるしかないね。


    参考URL







    Androider