Kick Out the World

技術的なメモとかポエムを書きます。

M5Stack×Moddable入門その1~M5stackにサンプルを焼いてみる

M5stack到着

今回買ったのは

www.switch-science.com

M5StackGray。Amazonでスイッチサイエンスから購入。

環境構築

焼きこむための環境構築を進めていく。

github.com

やったことはざっくり以下通り

  1. ドライバをインストール
  2. ツールチェイン類をインストール
  3. ESP-IDFをリポジトリからクローン
  4. M5stackをホストPCに接続
  5. Pathを通す
  6. 環境変数UPLOAD_PORTESP32_CMAKEを設定
  7. サンプルを起動
cd %MODDABLE%\examples\piu\balls
mcconfig -d -m -p esp32/m5stack

pythonのパッケージが古いとか言われて失敗したので、エラーメッセージに従い以下を実行してパッケージインストール よくよく見るとTroubleshootingにも書いてた。

python -m pip install --user -r %IDF_PATH%\requirements.txt

おまけ:manifest を追っかける

書き方自体はここ参照

github.com

Eamplesとかを見る限りは、$(MODDABLE)/examples/manifest_base.jsonとかを使いまわすのがよさそう。

M5Stack向けにビルド(-p esp32/m5stack)する構成を諸々端折って追っかけると、

$(MODDABLE)/examples/manifest_base.json
 ┗$(BUILD)/devices/esp32/manifest.json
 ┗$(BUILD)/devices/esp32/targets/m5stack/manifest.json // M5stack自体の設定
  ┗$(MODDABLE)/modules/drivers/ili9341/manifest.json // ILI9341液晶の設定

となっているので、わざわざピン番号とか機器固有の設定を調べて書く必要はなさそう。

M5Stack×Moddable入門その0~環境構築・シミュレータ起動

マイコンでの電子工作には興味があったものの、C/C++を書くことに苦手意識がありなかなか手が出せていなかったのですが、JavaScriptでも書けることが分かってきたため、この度M5Stack×ModdableでJavasSriptを使った電子工作に挑戦してみたい。

Moddable 選定について

まず今回使用するModdable以外にもobnizやJohnny-Fiveといったプラットフォームを使うことでJavaScriptによるマイコン制御ができるのですが、

obniz

obniz.io

一意のobnizライセンスが付与されたマイコンをインターネット接続することにより、クラウド上よりプログラムの実行が可能。 クラウド経由の実行となるため、環境構築の手間は最も手軽に思われる一方、実行に当たってはマイコンがインターネット接続されていることが前提となってしまうため、マイコン単体で動いてくれないことに微妙さを感じる

Johnny-Five

johnny-five.io

npmインストールするだけのため、これも環境構築の手間は手軽そうであるが、プログラム実行に当たってはホストマシンと接続しないといけないため、これもまたマイコン単体で動いてくれないことに微妙さを感じる

Modabble

www.moddable.com

これまでの2つと違ってマイコン単体でも動きそうだし、シミュレータやデバッガもありそうなので、なんとかなりそう。 日本語の情報は少なさそうだが、前述2つも少ないので、頑張って公式のドキュメントやサンプル見るか、という機運

環境構築

公式のGetting Startedを見て進める。

moddable/Moddable SDK - Getting Started.md at public · Moddable-OpenSource/moddable · GitHub

今回はWinows10 HomeをホストPCとして進めました。 やったことは大まかに以下通り。特に嵌りどころも無かった。

  1. Visual Studio 2019 (Community Editionでよし)をインストール。その時C++のよるデスクトップ開発もインストール。
  2. Moddableのリポジトリをクローン
  3. 上記クローン先にパスを通す
  4. VSのコマンドラインツールでビルドする
  5. シミュレータが動くようになるので、サンプルのhelloworldを動かす(立ち上がるがコンソールのほうにheloworldと出るだけ。。あまりに面白みがないので"examples\piu\balls"を動かした

次回はM5Stack到着後に。

(2020/06/28 23:00追記)

mcconfig

ビルドやプログラム実行時に打つmcconfigコマンドについては以下に詳細が記載されているので、軽く読んでおくと何をしようとしてるか分かるので安心。

github.com

上記にも記載されているが、$MODDABLE/buildに生成物が格納される。 XSリンカー?がmakeファイルやCファイルを吐いて、コンパイルされていそう

$ ls makefile mc.exp mc.resources.c mc.xs.c modInstrumentation.c.o modTime.c.o modTimer.c.xsi Resource.c.o screen.c.o timer.c.o mc.config.js mc.format.h mc.resources.o mc.xs.h modInstrumentation.c.xsi modTime.c.xsi modTimer.h.xsi Resource.c.xsi screen.c.xsi timer.c.xsi mc.defines.h mc.lib mc.rotation.h mc.xs.o modInstrumentation.h.xsi modTimer.c.o modules/ resources/ screen.h.xsi

USBバーコードリーダーでバーコードを文字入力として受けれた

表題の通りの結果が得られたので簡単に記録に残します、

そもそもUSBバーコードリーダーを買った動機

会社でのパソコンやモニタといった資産には、資産番号と共に資産管理用のバーコードが付与されているのですが、日常の資産棚卸の際には、目視で資産番号を確認し、管理エクセルから探すといったことをしなればならなく、とても面倒に感じていました。

その時にUSBのバーコードリーダってあるけど、それで読み取った結果をシュッと扱いことができれば非常に楽になるのでは?と思い調べ始めたところ、「USBバーコードリーダーは外部キーボード扱いとして認識され、読み取り結果がキー入力として受け取れる」ということがわかりました。 つまり、USBとして接続すれば何も特別な設定も必要もなく認識され、また、読み取った結果も専用のソフトやSDKも必要がなくキー入力として受け取れるので、非常に扱いやすいデバイスとなりそうです。

早速買ってみた

Amazonで調べた見たろころ、1次元のバーコードを読み取れるものであれば2000円台で買うことができそうであることが分かった。 実際に接続したらキーボードとして認識されるかどうかが商品情報からはよくわからなかったが、レビューの記載からそれっぽく振舞いそうという不確かな情報を基に買ったのが以下。

届いたので使ってみた

外見はかなりオモチャ感がある印象ですが、さっそく繋いで、テキストエディタを開きバーコードを読み取らせてみました。

期待通りに読み取り結果をキー入力として受け取れました。 また、読み取り後に改行が付与されるので、連続して読み取った場合にも1行ずつ入力されることとになります。 冒頭の動機として書いたエクセルのようなスプレッドシートとの相性も良さそうです。

あと、これは試していないのですが、バーコードリーダ自体の設定は、付属する冊子に設定用のバーコードがあるので、それを読み取ることで設定を変えることができます。そのため、やはり専用のソフトとかは不要になります。

読み取ったバーコードから書籍情報を取得するやつを書いた

前述までの通り、当初の目標である管理エクセルでいい感じに使用できそうなことが分かった。 ここでは、自作のプログラムから扱う方法のサンプルを書いてみた。

結果が分かりやすいく、かつ、手軽に実装できそうなものとして、Javascript(+Vue.js)を使ってみることにした。 といってもキー入力を受け取るだけなので、テキストボックスで読み取り結果を文字として受け取り、それをトリガーにするだけである。

今回は以下openBDというAPIを使って、読み取ったバーコード番号(ISBN)から書籍情報を得るというものを書いた openbd.jp

<html>
  <head>
    <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
  </head>
  <body>
    <div id="app">
      <input type="text" autofocus v-model="input" v-on:keyup.enter="onKeyupEnter">
      <div>バーコード:{{barcode}}</div>
      <hr>
      <div>タイトル:{{title}}</div>
      <hr>
      <div>著者:{{author}}</div>
      <hr>
      <img v-bind:src="cover">
    </div>

  </body>
  <script type="text/javascript">
    new Vue({
      el: "#app",
      data: {
        input: "",
        barcode: "",
        title: "",
        author: "",
        cover: "",
      },
      methods: {
        onKeyupEnter: function() {
          fetch("https://api.openbd.jp/v1/get?isbn=" + this.input)
            .then((response) => {
              return response.json();
            })
            .then((data) => {
              if( data[0] === null ) {
                this.input = "";
                this.barcode = "エラー";
                return;
              }
              this.barcode = data[0].summary.isbn;
              this.title = data[0].summary.title;
              this.author = data[0].summary.author;
              this.cover = data[0].summary.cover;

              this.input = "";
            })
        }
      }
    })
  </script>
</html>

大まかにやっていることは以下通り、 1. テキストボックスにフォーカス時に、バーコードを読み取ると結果がテキストボックスに入力される 2. 上記入力の末尾に改行を受け取るので、EnterキーイベントをトリガーにopenBDのAPIを叩く 3. 叩いた結果から得られた書籍情報を画面に表示する

実際に動かしてみるとサクッと動きました。

終わりに

今時ならライブラリ等を駆使して、カメラから画像からバーコード認識させるところでしょうが、キー入力は非常に慣れ親しんだインターフェースで、容易に扱うことができました。

また、バーコード自体を生成するライブラリも巷には存在しますが、エクセルでも生成することができます(具体的な方法は「絵エクセル バーコード生成」とかで調べてください)ので、使用できるソフトウェア・ツール類が制限されている環境でもバーコードは扱いやすい入出力インターフェースという認識ができました。

Scrum Boot Camp OSAKA in June 2018に参加しました

scrumdo-kansai.connpass.com

イベントの大まかな流れ
  1. アイスブレイク・イントロダクション
  2. スクラム概要説明
  3. スクラムイベント(スプリント、プロダクトバックログ作成・見積もり、振り返り)それぞれを体験するワークショップ
  4. QAタイム・クロージング
  5. ビアバッシュ

という流れで朝9:30-夜20:00ぐらいまでの長丁場でした。 本記事では、後述しますが、体験および気づきが重要だと感じたので、個々のワークショップ詳細については、本記事では触れません。

良かったこと
  • 講師陣が実際に現場でスクラムを実践している方々というのもあって、説明の仕方やワークショップのファシリテートも上手いなと感じた
  • ランチやビアバッシュ代込みとは言え、コミュニティイベントとしては少々高額な参加費であったが、参加者も本当にスクラムを学びに来ている人が多く、熱量も大きかった
  • ワークショップを通じて、実際にスクラムイベントを体験できたことが一番大きかった。座学や自分の少ない経験から理解しているつもりではあったが、実際に人を集めチームを組んでやってみると、思いの外上手くいかないこともあり、気付きや学びが多かった。
  • カンバン形式のQAタイムがあり、ビアバッシュまでに全部のQAを解決させる取り組みは良かった。中々聞きたい人が捕まらなかったり、人は酒を飲むとテキトーなことを言いがちなので。
請負とスクラム

QAタイムを通じて、実際に自分がもやもやし感じていたところをぶつけさせてもらった。

明確な成果物を定義できないので、契約としてはふわふわな納品物でOKとする、というか自分の現場もそうしていた。 しかし、受託脳としては、そういった場合に顧客に提供するものとしては人月としての労働量になるのでは、という謎の力が働いていた。 結果として、稼働時間を加味したベロシティや見積もりの算出となっていき、顧客向けの数字イジりにパワーを割く羽目になったし、それなりの見通しの精度を実現できた一方で、開発現場も稼働の呪縛により疲弊もしていた。

人によっては雰囲気伝わっていたし、ピンときてない人もいるという反応であり、こんな悩みに時間を割いてスマンなという気持ちであった。

色々なアドバイスや意見を頂いた結果、POとなる顧客には、スクラムおよび現場の実情に対する理解を得てもらいつつ、現場がシンドくならないような進め方を模索しないといけないな、という納得に落ち着いた。 具体的な解決に落ちてないやん、というツッコミもあるが、現状はスクラムもしていないでの、共感を得てもらったこと、考え方を示してもらっただけでも十分かと思っています。

おわりに

自身が今後スクラム開発に関わる予定は未定だが、改めてスクラムに対する考えが整理でき、また、今の現場にも何かフィードバックができることがないか考えてみようという気持ちになれた。

参加者はソフトウェア開発関係者が多かったようですが、特に開発の知識は必要もなく、開発以外の現場にも十分に適用できることだと思うので、次回開催されていればオススメです。

ビアバッシュ後の懇親会まで楽しむことができ、充実した一日となり、スタッフの方々ありがとうございました。

今回のイベント後以降も困ったことがあれば隔週開催のスクラム道関西オープンジャムに来てくれ、だそうです。

scrumdo-kansai.connpass.com

自分とスクラム開発について

Scrum Boot Camp OSAKA in June 2018に参加しましたブログを書こうと思い、 序章として「自分とスクラム開発」についての振り返りを書こうとしたら、やたら長くなり、イベント参加ブログどこいったんや状態になりそうなので、分離しておく。


続きを読む

Buildrootのドキュメント斜め読み Chaper8

Chapter 8. Buildrootの使い方

8.1 make tips

他章のものを記載する

コマンド 内容
make help サブコマンド(target)を表示する
make V=1 makeで実行されるコマンドの表示
make list-defconfigs 各ボード用に利用可能なmenuconfigを表示する
make clean 対象アーキテクチャやツールチェイン変更時に使用する
make ckean all 再フルビルド実施
make manual docs/manualに生成されるマニュアルの生成
make manual-clean マニュアルのクリア
make distclean ターゲットのクリア
make -dirclean パッケージの削除
make source dlフォルダ配下からオフラインビルドする
make O= outputフォルダを指定する
make graph-depends 依存関係のグラフを生成する

8.2 フルビルドし直すタイミング

下記でも必ず必要ではないユーザが適宜判断し実行する * アーキテクチャが変わったとき * ツールチェイン設定変更 * 依存するライブラリ追加する * パッケージのサブオプション変更時 * RFSのスケルトン変更時

8.3 パッケージの再ビルドについて

  • パッケージの削除は再フルビルドするしかない
    • stagingとか関連する場合
    • 単体で削除可能ならoutput/buildから削除するかmake <package>-dircleanでもよい
    • output/build/<package>-<version>/配下にビルド状態を管理するスタンプファイルstamp_<step-name>を生成する

8.4. Offline builds

8.5. Building out-of-tree

(makeのサブコマンドのであるため省略)

8.6. 環境変数

(関連する項目で見るため省略)

8.7. 効果的なファイルシステムの扱い方

sparseファイルについて(よくわからん)

8.8. パッケージの依存関係をグラフ化する

*make graph-depends * output/graphs/graph-depends.pdfに生成される * Graphvizを入れる必要がある * apt install graphviz * システムがでかくなると見づらいのでmake <pkg>-graph-dependsでパッケージ単位で出力するともできる * PDF以外のフォーマットでも出力可能 * BR2_GRAPH_OUT=svg make graph-depends * BR2_GRAPH_DEPS_OPTS環境変数で制御を変更可能

ビルド時間のグラフ化

  • どのパッケージのビルドに時間がかかっているかを可視化することができる
  • make graph-build
  • python-matplotlibを入れる必要がある
  • 数種類のファイルが生成される
  • build.hist-build.pdf
    • 各パッケージごとにかかった時間がビルド実行順にヒストグラムになる
  • build.hist-duration.pdf
    • ビルド時間がかかった順のヒストグラフ
  • build.hist-name.pdf
    • ファイル名順のヒストグラフ
  • build.pie-packages.pdf
    • ビルド時間の円グラフ
  • build.pie-steps.pdf
    • ビルド行程ごとの円グラフ
  • 出力フォーマットは変えれる
    • BR2_GRAPH_OUT=png make graph-build

8.10. パッケージごとのファイルシステムサイズのグラフ化

  • 各パッケージのファイルがRFS中に占める割合をグラフ化
  • 生成されるfile-size-stats.csvを利用して、ビルドごとの比較をすることができる ** utils/size-stats-compare -h

8.11. Eclipseインテグレーション

使わないので省略

8.12. 応用

8.12.1. ツールチェインをBuildRoot外で使う

output/host/bin/をPATHに追加するなりする

8.12.2. Buildrootでgdbを使う

設定でgdbserverを有効にするなりすれば使える

8.12.3. Buildrootでccacheを使う

省略

8.12.4. ダウンロードしたパッケージの配置先

BR2_DL_DIRで指定できる

8.12.5. パッケージ単位でのmakeサブコマンド

make <package>-<target>

8.12.6. Using Buildroot during development

<pkg>_OVERRIDE_SRCDIRでパッケージに対してファイルを追加できる


調査はだいぶ前に終わってたけど、しばらく体調を崩していてかけなかった

ここまでの情報でだいたいBuildrootにおけるシステム構築方法を確認することができ、以降はBuildroot自身に変更を加えて独自パッケージ追加するといったこととなるので、ドキュメント斜め読みとしてはここまでかな。

Buildrootのドキュメント斜め読み Chaper6~7

Chapter 6. Buildroot 設定

  • 設定の詳細はmake *confing内で確認できる

6.1. クロスコンパイルツールチェイン

  • 2種類のツールチェインに分類される
  • Buildroot toolchain
    • ツールチェインからビルドする
    • pros:Buildrootとの連携が柔軟
    • cons:設定を変更するとフルビルドが必要
  • External toolchain
    • Linaroなどのベンダーのツールチェインを利用する
    • pros:有る程度信頼性があり、ビルド時間も短くなる
    • cons:不具合があるとベンダー依存になる

6.2. /dev 管理

configuration, /dev management で/devの構成を変更できる

  • 静的なDeviceTableファイル
    • 古典的な方法
    • バイスファイルを予め生成したものを/devに配置しておく
    • BR2_ROOTFS_STATIC_DEVICE_TABLEにDeviceTableファイルを指定できる
  • devtmpfs
    • Buildrootでの推奨
    • 2.6.32から導入された仮想ファイルシステム
    • /devにマウントされ、デバイス追加削除に応じて自動的にデバイスファイルを生成削除する
    • CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNTカーネルコンフィグが必要
  • devtmpfs + mdev
  • devtmpfs + eudev

    • mdevより複雑で柔軟な管理制御ができる
  • initシステムにsystemdを選択するとudevになる

6.3. init システム

System configuration, Init systemから以下3つのInitシステムを選択することができる

  • Busybox
    • Buildrootのデフォルト
    • ベーシックなinitプログラム
    • /etc/inittabを読み込む
    • フォーマットは一般的(symtemV)なものと少し異なるのため、https://git.busybox.net/busybox/tree/examples/inittab を参考にすること
    • 主に行うのは/etc/init.d/rcSgettyの起動
  • systemV
    • 多くのデスクトップLinuxで使用されてきた伝統的なinitプログラム
    • /etc/inittabを読み込む
  • systemd
    • 次世代のinitプログラム
    • より複雑な制御ができる

Chapter 7. 他コンポーネントの設定

  • busyboxやLinuxKernelなどの設定ファイルがある場合はBR2_PACKAGE_BUSYBOX_CONFIG.BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG といったパラメータに指定することができる
    • 指定しなければデフォルトの設定が適用される
    • 設定はmake busybox-menuconfigとかで変更できる

現状は軽量な組み込み最小構成のLinuxシステムを想定した起動や/dev管理となってるような雰囲気。
ぼちぼちLinuxの知識が必要だったのと次章はmakeコマンドtipsが多いのでここまで。