教科書に載らないソフトウェア開発入門 (インターフェースを切る事と実現可能なソフトウェア規模についての話)

どうやったらもっとまともにソフトウェアを書くことができるようになるのか？

僕も若い頃、いや、まだ若いんだけど、本当にどうやってソフトウェアを書いてゆけば良いのかわからなくて、とにかくダラダラダラダラダラダラダラダラ「きっとやらなくてはいけない処理」を羅列したものだった。それも膨大な量のコードを。

・・・と書こうと思ったのだが、実は自分自身はそうではなかった。

以前書いた「アセンブラでこんなに美しく書ける方がいるんだ！」という純粋な感動体験が完全に邪魔をして、職業でソフトウェアを書く時に美しさに何かの美学を見出していた若かりし自分は、とにかくいかに美しく問題を解決するのか？についてひたすら毎日考えていた。このおかげで、人よりも余計な苦労をしなくてはならなかったのと、まだ若かった自分には設計や実装に関する知恵も知識もなかった上に余計なことに思慮を巡らせるものだからとにかく時間がかかっていた。本当にあれは今でも周囲にとっては単なる迷惑な新人だっただろうと想像できる。

新しくソフトウェアを書こうと思う人にとっての最初の疑問は、どうやったらもっとまともにソフトウェアを書くことができるようになるのか？ということかもしれない。少なくとも自分はそうだった。

インターフェースを切れるようになること

「どうやったらもっとまともにソフトウェアを書くことができるようになるのか？」という疑問に対する答えのひとつは「インターフェースを切れるようになること」だ。

「インターフェースを切る」というのは、つまり、対象物が何であるのか、というのと、それをどうするのか、という二つの事を分析して理解した上で、使う側と使われる側の双方の立場で物事を考えなければならない。この分析を経てようやく何かのインターフェースを策定できるようになる。

この分析から理解、理解から策定に至るまでの道筋を立てられるようになると、インターフェースを切れるようになってくるのだけど、インターフェースが切れるようになってくると、大きな設計対象物でもそれらを部分に分割し、適切な階層構造を構築できるようになる。適切な階層構造を構築できるようになると、全体も部分もそれぞれの粒度で理解できるようになる。そして、階層構造で設計対象物を見れるようになることでソフトウェアの全体構造を見る視点が養われる。つまり、この時点で規模の大きなソフトウェアを実現できるようになってくるんだ！

この段階に入ってくると、設計対象物を様々な見方で分析して理解できるようになってくる。データの流れで全体構造を見たり、論理的な階層構造から全体構造を見たりすると楽しいものなんだ。そして、何よりも大切なのは、楽しいと自分がやりたくなるっていうこと。苦労だけすれば良いってものではないからね。

つまり、インターフェースを切るということは、全体を部分に分割するのに必要不可欠で、分割することで大きな規模のソフトウェアも実現できる。それだけではなく、全体を部分に分割する中で、関係のあるものと関係のないものを分離することが可能になり、よりソフトウェアが洗練される。例えば、何かのソフトウェアを書いていて「この処理は他でも使えるな」という処理があったとする。そういう処理は一度書いておけばどんどん使えるネタとして持っておくことができるようになるんだ。

インターフェースを切っていると出来る芸当もあって、インターフェースを切っていることで、何かの変更が必要になった時にコンパイラに助けてもらうこともできる。

例えば、インターフェースに新しい機能を追加したくなったとする。インターフェースの定義を変更するだけで、そのインターフェースを使っている上位層をあぶりだすことができるんだ。だって、変更して形の変わったインターフェースを使おうとしている上位のコードは、必ずコンパイルエラーになるでしょ？

こんな風に、インターフェースを切るという話を始めただけでも、色々な側面の話が出てくるってこと。頭の片隅にあっても良いかもしれない。

教科書に載らないソフトウェア開発入門 (インターフェースの定義と実装の詳細)

インターフェースの定義と実装の詳細

「教科書に載らない」と書くからには、教科書に書かれないような(でも非常に大切なこと)ことを書こうと思う。

働き始めて直ぐに横にいた先輩は、とある業務用ビデオ装置のディスク制御ファームウェアを書いていた人だった。この先輩は日本語の使い方しかり、話し方しかり、色々と事細かに注文を付けてきた。入社したての自分にとっては煩いだけの先輩だったのだけど、今思うと非常に大切なことをここで学んだように思う。

このシリーズの冒頭では、同じことを指示しているような一つの単語があったとしても、見方や認識の差から結果的に全く異なる場所に行きついてしまう点について書いた。実はこの先輩も同じような事を言いたくて若い頃の自分に事細かに指導をしてくれていたのだと思う。

ここ約20年ほど、様々なソフトウェア開発者の設計や実装を見てきて、如実に実力の差が明らかになるのは、インターフェースの定義と実装の詳細についての明確な思想が育っているか、という点だ。経験の浅いソフトウェア開発者、あるいは経験はあるはずなのに一向に技術レベルが向上しないソフトウェア開発者には共通して「インターフェースの定義と実装の詳細を明確に区別できていない」という問題があった。

おそらくこの区別を最初に身に付けておくだけでも、相当なレベルの差になりそうだから、ここで非常に重要なこととして「インターフェースの定義と実装の詳細」について述べておくことにしたい。

もしかしたら、とても重要でかつ唯一といって良いかもしれない。そしたらこのシリーズは既に今日の内容で終わってしまうことになるが、それはそれで良いだろう。

インターフェースの定義

インターフェースとは、ある面と別のまたある面の境界にある出入口のことだ。ざっくり言うとね。その出入口にはそれぞれ定められた規則があって、その規則に従う限り何かを通すことができる。”何か”っていうのがポイントだ。この通すものや規則を具体的に定めるのがインターフェースの定義。この定義に従う限り面と面を接続できる。

これはソフトウェアの言語に依らない考え方ではあるのだけど、具体的な例が欲しいのでここではC言語で書いてみようと思う。

int getc(FILE *stream);

例えば、上記の関数があったとしよう。この関数はFILEへのポインタを第一引数に取り、intを返値に持つ。この関数の実際の動作はインターフェースを定義した際に具体的な挙動が決められることになる。この関数はlibcの標準ライブラリだが、実際にこの一見簡単に見えるインターフェースでさえ、インターフェースの定義が明確になっていない限り、どのような動作になるのか見当もつかないはずだ。

例に挙げると

• streamにnullを与えるとどうなるの？
• streamに与えるFILEへのポインタとは一体なんなの？
• streamのFILEへのポインタは開かれていないFILEだったらどうなるの？
• 返値のintはどういう規則で返されるものなの？

のように細かな動作を決めるのはインターフェースの定義に含まれる。いずれにせよ重要なのは外部から見た出入口の振る舞いを決めるということだ。

このインターフェースの定義は何もソフトウェアに依らない。ハードウェアでも同じように考えることができる。このチップはI2CバスとSPIバスの橋渡しをするデバイスだ。インターフェースにI2CバスとSPIバスを取っている。

実装の詳細

実装の詳細とは、インターフェースの定義で定められた振る舞いを実現するためのものだ。とても乱暴に言うと、インターフェースの定義で定められた振る舞いさえ提供できれば、中身の実装がどんな風になっていても構わない。もちろん実装詳細の具体的な内容は時と場合によって正解もあり間違いも当然ながら存在するが。

例えば、二つの数を与えると加算して返す関数があったとする。インターフェースの裏側にある実装の詳細がコンピュータで実現されていても良いし、小人さんが10人で寄ってたかって一生懸命計算していても良いし、紙テープで何か不思議な計算処理をしていても良い。つまり、インターフェースの定義に従っていさえすれば良い、というのが実装の詳細の基本的な考えだ。

ここまでで

ここまででインターフェースの定義と実装の詳細について簡単に説明した。具体的なイメージは上記の説明だけでは不十分で、これから先のシリーズでより具体的な設計や実装のイメージをつかめるようにしていきたいと思う。

教科書に載らないソフトウェア開発入門 (今はあまり出来ないと考えている君へ)

今できることと将来の自分

「教科書に載らないソフトウェア開発入門」なのだから、当然のように最初からソフトウェア開発の何たるかについてツラツラと書き記したい気持ちがあるのだが、やっぱり先の記事と同様に少しだけ寄り道をしようと思う。

というのも、15年ほどソフトウェア開発をしてきて振り返ると、今でこそ考えた通りに動作するソフトウェアが出来るようになったものの、始めた一年目なんかは本当にひどい状況だった。書くソフトウェアの全てが100%の確率で思った通りに動かない。動かないならまだしも、そもそもコンパイルも通らないしリンクとか言われてもワケがわからない。

もう本当に詰まらないというか何をやっているのか自分でわからないような日々が続いた。そもそも自分がソフトウェア開発をやることになったのは、自分で設計した基板に載せていたマイクロコントローラのファームウェアをアセンブラでスラスラと書いているのが間違ってソフトウェア開発を統括する人の目に留まってしまったからだ。これは失敗だったと当時は何度も思った。

そんな動きもしないソフトウェアを何年も作り続ける日が続いたのを今では懐かしく思うが、当時は本当にこれは駄目だなと何度も思った。手掛かりになればと色々な書籍やウェブを読み漁ったけど、どれもこれもピンと来ない。当時はなぜなのかわからなかった。

何かのきっかけ

物事にはきっかけというものがあるみたいだけど、自分のソフトウェア開発の状況を徐々に改善するきっかけになったのは、やっぱりこれも「どうしようもなく動かないソフトウェア」を作ってしまった時だった。もう本当に納品することになっていたソフトウェアを担当していた自分は、先輩から言われた前提条件に従って限定的に動作するソフトウェアを書いていた。この前提条件に従う限り、確かにソフトウェアは動作した。まずかったのは、その前提条件があまりにも厳しく、殆どの場合で適用できなかったことだ。

そんなソフトウェアを納品に持って行った結果、御客様の落胆度合いは半端でなかった。また、不運にも、というか当然の結果として御客様の環境はその前提条件に該当しなかった。ソフトウェアについての説明を加えながら実際に動作をさせていったところ、あらゆる処理で例外が発生した。これには本当に作っていた本人が参ってしまった。当然ながら御客様はそれ以上に参ってしまった。今でも表情を思い出せるくらいの落胆さを示された御客様は、お引き取り下さいだったか何かを仰っていたように思うが、もう当時のこの瞬間を思い出すことも出来ない。記憶から消してしまったのだろう。

とにかく、この厳しい前提条件で限定的に動作するソフトウェアは、本当に世の中に何の役にも立たず、もっと言うと様々な人に害を与えるために世に生まれてきてしまったのだった。

この話を聞きつけた上司（彼がその厳しい前提条件で良いと話していた）は、顧客と同様に激しく落胆し、私を担当から外して別の人間に修理させようといった内容の話をしていたようだ。その話を聞いた自分は落胆に落胆を重ねた落胆パレードに参加しているかのような錯覚に陥った。ひどく参って次の日は一日休んで何かを考える日に使った。

心に決めたこと

休んだ一日は本当に何をやっても手に付かなかったし、自分のボロボロのソフトウェアを修正する担当を逆恨みしたりした。これはひどい。出来ない人の典型みたいだ。だから決めた。ちゃんと作ろうと。ちゃんと作るのは当時の自分からすると何をして良いのかわからなかった。唯一わかっていたのは、動かないソフトウェアは「考えられていない」ということ。

何を考えるのかも重要だったと思うけど、とにかくあちこち隅々まで考えられていない事で徹底されていた。当時はわからなかったけど、厳しい前提条件を自分の思い込みで設定してしまった上司が典型例だった。特に何も考えないで「それで良いんじゃない？」と言う。その何かにとって都合の良い思い込みで作り続けてしまう。そんな事はもうたくさんだと思った。

その日からとにかく考えて作ることにした。まず、厳しい前提条件は何故生まれてしまったのか？その前提条件を外す方法は何か？そもそも前提条件を外すのは無理なのか？なぜ人々は過ちを犯してしまうのか。（いや、それは考えすぎだった）

調べてみるとその前提条件は、当時制御対象になっていた装置の実装制約から来ているものだった。とある信号を生成するのに使っていた設定ファイルが、無数の数式から出てきた値を保存するものになっていた。その値を編集するソフトウェアだったのだが、元の式が一体どういうものだったのかわからないものもあった。

仕方がないから100個くらいあった設定値の数式をあらゆるソースコードやユーティリティから漁っていくことにした。式は軽く数十個。中にはよくわからないパラメータも無数にあった。わからなくなってくると周りの先輩に聞いて回った。中には「そんなの勝手にやれ！」とか「なんでそんなの必要なんだよ！」と怒り出す先輩もいたが気にしなかった。「自分はこれを完成させないといけないんです」と逆切れした。

兎にも角にも「前提条件を外せば今よりももっとまともに動くはず」という目論みで進めた結果、意味不明な設定値の羅列だったものが、設定ファイルから元の数式にはまるパラメータを逆算できるようになり、これがきっかけで問題だらけだったソフトウェアが動作するようになった。

それだけでなく、パラメータの生まれた背景や意図を知る事になり、結果的に今まで出来なかったような便利な設定も出来るようになった。この結果を喜ぶ人は社内に殆どいなかったが、少なくとも御客様とその製品を主に担当していた先輩だけは喜んでくれた。

このことがきっかけになって、自分は他の人よりも考えることにしようと心に決めた。自分は頭が良い方ではない。それでも何かをしないといけないと思った。

みっともない話をする事について

こういうみっともない話（個人的な情けない話）は、ふつうはしないものだと思う。色んな人が色んな事を言うわけだし、そういう批判や非難は誰しも耳にしたくない。でも心に留めておいて欲しい。ソフトウェアを書くというのは、ありのままの自分でいないと書けないということ。わかる範囲でしか書けない。残念ながら現代の計算機は、未だもって思った通りには動かない。書いたとおりに動く。だから、自分の書いている範囲でしか動かない。

最近見た光景だが、その彼は様々な状況や人間にありがちな見栄から、どんな事を言われても「簡単です」と答えていた。実際にそれらがどうなったか。簡単と言われていた内容が、とてつもない人数をかけてやる一大プロジェクトだったり、熟練した人なら特に問題もなく完成させられるはずの内容を、いつまで経っても完成させられない状況に陥っていた。

彼は見栄っ張りだった。見栄やプライドは成長を阻害する。わからないものはわからない、難しそうなものは難しそう。それは何の恥でも無知でもない。それは個人の能力の限界かもしれないが、それは別に人格とも関係が無い。知らないものが事があるのは恥ではない。全てを知るのは無理だ。ただ素直に自分に対してそれを認めれば良い。馬鹿にする人も気にしなくて良い。そういう人達は単に暇なんだ。本当に。

今日もソフトウェア開発に直接関係なさそうな事を書いてしまったけど、もしかしたら一番大事なことなのかもしれない。

教科書に載らないソフトウェア開発入門 (はじめに)

万物世界共通

思い立って何かソフトウェア開発にまつわる話を書こうと思ったのだけど、おもむろに重い話を書くと読む人も嫌になると思ったので、いっけん関係ない話をしようと思う。

  「どんな物事も基本が一番簡単に見えて一番難しい」

例えば、ピアノを弾けない人に「明日からピアノでジャズを弾いてくれ」と頼んだとする。 面を食らった人はピアノ曲集みたいなのを手に入れておもむろに曲を弾き始めるだろう。 そうするとどうだろう。いかにも「曲集を練習しました」という演奏にしかならない。

長年この問題を考えていたけど、結局のところ動作や結果、それぞれひとつひとつには「背景となる思想や積み重ねがあってそうなる」という事かもしれない。少しニュアンスが難しい。もしかしたら何を言っているのかわからないかもしれない。

少し前の話、ビーバップの伝統を受け継ぐピアニスト、バリーハリス氏が教育の現場で学生に「Cmを弾いてくれ」と言った光景を見たことがある。たいていの学生はどうしてか弾きなれている(?)Cm7を弾いてしまう。つまり、特に何も考えることなく7thを足してしまうわけだ。こうなると話は全然違う方向になる。

バリー氏はCmを弾いて欲しいと頼んでいるにも関わらず、Cm7を弾く人達について、頭を使っていない(=Cm7はF7を経由してBbメジャーへのトニック進行を暗に示唆する)と見ているのだ。Cm7を弾いた時点で、結果的に本来の意図であるマイナーとは全く異なるメジャーに帰着することになり、異なる結果になってしまう。

つまり、そういうことだ。(え？)

すべての一見簡単に見えることが、あらゆる浅はかさによって全く異なる結果を生んでしまう。これが「どんな物事も基本が一番簡単に見えて一番難しい」という由縁だ。コードを1つ弾くだけでも間違いは起こり得るのだ。

---

ちょっと古い2000年頃の話

当時工学部の学生だった自分は、そろそろ真面目に勉強をして大学生活から外へ出たい気持ちになっていた。 電気好きの一級建築士だった祖父から受け継いだ電気への興味をそのままに電気電子工学科なる学科に進んだのは良いが、真空蒸着なんかをやっている間に何をやりたいのだっけ？とわからなくなっていた。

在学五年目に差し掛かったあたりから、当時徐々に日本国内で人気の出ていたマイクロコントローラに興味を持つようになり、研究室の先生にお願いして幾つかの部品を購入してもらった。正直に言おう。当時、手にしたものの中にはTI社のDSPもあったのだが、これはのっけから開発環境のセットアップがよくわからずに躓いて放っておいた。ごめん。あれは高かった。

まぁ、それはさておき、当時自分が触っていたマイクロコントローラは、8ビットのハーバードアーキテクチャを持つもので、プログラム上で変数を扱おうと思うと数少ないレジスタとメモリを駆使しながらアセンブラで組み上げるという代物だった。 当時はそもそもソフトウェア開発を生業にすることを考えていなかったので、ハードウェアを設計した後に付いてくるお愉しみみたいなものに過ぎなかったのをよく覚えている。

ところで、その当時の国内では「このマイクロコントローラといえばこの人！」みたいな著名な方がいて、沢山の書籍が出ていたのだが、ソフトウェア開発を知らない自分から見ても「この実装は質が低くないか？」と疑いの目でしか見れなくなっていた。

元々、「出来る人の言う事しか聞かない」ポリシーがあるので、この著名な方の書いてあることを信用するのはやめて、もっと他の良い教師を探すことにした。 時は2000年、ちょうどWindows NTやらWindows 2000やらが出て、世間はインターネットだとかウェブだとか色々とにぎやかになり始めたことだ。 研究室にあったSONYのノートパソコン(そうVAIOだ！)を勝手に拝借して自分の研究用にあてた上で、授業が終わるとウェブで必死に技術資料をかき集めた。

当時、この類の情報を国内で発信していた人はそれほど多くなかったとは思うが、その中に一つ「これは！」と思う実装を公開している人がいた。 具体的な名前は書かないけど、この人の実装を見た時から自分の本当のソフトウェア開発がスタートしたといっても過言ではない。 (いや、本当は中学生の頃からソフトウェアは書いていたのだけど、それは忘れて良いと思う。N88-BASICだし。)

ひとつ、良いことを教えよう。 その人はとても良い公開方法を選んでいた。 「人に考えさせること」だ。 当時その人が公開していたウェブには確かにソースコードがあった。 でも、実はそのままではコンパイルできないように、ある関数だけは非公開になっていた。 もうどんなセリフだったのか忘れてしまったけど「興味のある人は連絡をください」だったかな。 こんなに綺麗なソースコードをアセンブラでも書けるなんて素敵だと感動した自分はさっそくメールを打った。 ほどなくして返答を頂いた自分は「本当に宝物を頂いた」と感動して、すぐさまコードを印刷して一行ずつ穴があくまで読んだ。

---

で？

もう既にあれから20年くらい経って少し大人になってしまったのだけど、それからまだ自分はソフトウェアを書いている。 自分に感動を与えてくれたコードを書いた人にいまだ持って会えていないのだけど、そろそろ会うのではないかと考え始めている。 そして、自分もそろそろ先代がしてくれたことと同じように誰かに何かを与えて生きて行く段階に入っている。 そろそろ時間も足りなくなってくるので、その活動を始めようと思うのだ。

FreeRTOSがAWSオープンソースプロジェクトになってMITライセンスが採用されたらしい

最近はマイコンで遊ぶ暇もないくらい忙しいのですが、なんとFreeRTOSがAWSオープンソースプロジェクトになって、しかもMITライセンスが採用されたらしいです。

あぁ、たまにはゆっくりマイコンで遊びたいなぁ。

https://www.freertos.org/

どんどん時代が変わっていきますね。
https://aws.amazon.com/jp/freertos/

ARMv6-M Architecture Reference Manual

先日の続きでARMv6-M Architecture Reference Manual(https://static.docs.arm.com/ddi0419/d/DDI0419D_armv6m_arm.pdf)を見ていきます。文書をざざざっと見渡し、まずはARM core registersの確認から進めます。D7.1にARMv6-Mにおけるコアレジスタ定義が表になっているのでここから進めることにしましょう。

続きは次回...え？

ARMv6-Mと戯れる 第1号 ～ARMv6-Mと戯れる準備をしよう～

まえがき

大抵の場合「ARMマイコン！ARMマイコン！」と言っているその中身は、ARM社が提供しているプロセッサに加えて、チップベンダー各社が周辺回路を加えてパッケージングされたものだったりします。 「マイコンを使えます」という人でも、自分が使っているマイコンがどういったプロセッサを使用しているのか詳細を答えられる人は稀で、せいぜい「Cortex-M0+です」とかその程度のものでしょう。

4年前の2013年、LPC810でも動作するUOS-LPC800を設計し、その過程でARMv6-Mのレジスタセットについて学習しました。 この学習過程を振り返った上で、再度見直して楽しんでみようというのが本シリーズです。

ブート！

学習過程を振り返るというお題があるので、学習を始める過程も挙げておきます。 まずは題材となるマイクロコントローラのデータシートを見ます。

NXP社のウェブよりLPC81X_LPC83X: Low-Cost Microcontrollers (MCUs) based on ARM® Cortex®-M0+ Coresには、ARM Cortex-M0+と書かれていますね。でも、この段階では「あぁ、ARM Cortex-M0+っていうのを使っているんだ。」程度にしかわかりません。

次に「このARM Cortex-M0+って何だ？」というのは、ARM社の情報を見る事になります。 https://developer.arm.com/products/processors/cortex-m/cortex-m0-plusには、ARM Cortex-M0+という絵の中に「CPU ARMv6-M」とあり、「あぁ、ARMv6-Mと呼ばれるCPUを使っているんだなぁ」と先ほどのARM Cortex-M0+から一段掘り下げた情報が得られます。

で、ハイライトを見ると、ISA Supportの欄に「Thumb/Thumb-2 subset.」と書かれています。この「ISA」というのは、Instruction Set Architectureの略で、命令セットアーキテクチャは「Thumb/Thumb-2のサブセットだよ」と言っています。

ここまでで、「ARM Cortex-M0+は、ARMv6-Mと呼ばれるCPUを使っていて、命令セットアーキテクチャはThumb/Thumb-2のサブセットである。」という事がわかりました。

さて、プロセッサと戯れるためには、ここで止まってはいけません。 更にhttps://developer.arm.com/products/architectureから、M-Profile Architecturesの情報https://developer.arm.com/products/architecture/m-profileに辿り着きます。

概要ページにはARMv6-Mアーキテクチャの概要も書かれており、「T32命令セットをサポート」と書かれています。 新しいキーワードT32命令セットが出てきましたね。

Instruction Setsのページhttps://developer.arm.com/products/architecture/instruction-setsを見ると、A64、A32、T32の各命令セットについてリンクが張られています。

https://developer.arm.com/products/architecture/instruction-sets/a32-and-t32-instruction-setsには「T32命令セットはARMv8アーキテクチャ以前にThumbとして知られていたもの」と書かれています。つまり、先に出てきたThumbと呼ばれる命令セットはT32命令セットである事がわかりました。

今回のまとめ

「ARM Cortex-M0+は、ARMv6-Mと呼ばれるCPUを使っていて、命令セットアーキテクチャはThumb/Thumb-2のサブセットである。T32命令セットはThumbとして知られている。」という事がわかりました。

次回は、ドキュメントのページhttps://developer.arm.com/products/architecture/m-profile/docsに辿り着いて色々と見てみましょう。

http://docs-api-peg.northeurope.cloudapp.azure.com/assets/ddi0419/c/DDI0419C_arm_architecture_v6m_reference_manual.pdfがアーキテクチャのリファレンスマニュアルです。

ESP-WROOM-32をMicroPythonで遊ぶ

■うだうだと前書き

猫も杓子もIoTと皆さんが仰るので、その声が大きくなればなるほど自分は遠ざかる方向で生きていたのですが、そうすると完全に煙に巻かれたお爺さんのようになりまして、今は世の中が進んでおるんじゃのぉと言うだけの人です。気付いてみればガレスタさんのDIY日記は素晴らしい勢いで開発を進めており、こんな風に生きてみたいものだと思うようになってきた今日この頃。私も負けて・・・いら・・・れ・・・うぐぐぐぐ・・・パタ。←血を吐いて倒れました。

数か月前、とある都合からESP-WROOM-32(おっ！2017年8月4日にデータシートが更新されている！)を搭載した開発ボード(えぇ、あのねむいさんが激オコの電源に問題のあるですね...)を入手していたのですが、色々な別の開発で忙殺されており全く調査が進んでいませんでした。肝心の「とある都合」もほったらかしでマズイぞ。

さてさて、このESP-WROOM-32は、プロセッサ、フラッシュロム、クロック、アンテナ配線などが集約されたモジュールとして提供されています。加えてメーカーが提供するSDKを使えば、簡単にネットワーク通信可能な小型ソリューションが出来上がるという仕掛け。開発ボードを購入すれば手間をかけずに試すことが出来て、これは面白いですよねー。(棒読み)

ここいらで触っておかないと永遠に触らない事を悟ったので、ホストOSにUbuntu 16.04.3を配備した上で重い腰を上げました。

■事前準備

まずは設定やビルドなどで必要になるパッケージをインストールします。

sudo apt-get install git wget make libncurses-dev flex bison gperf python python-serial vim screen

■ツールチェインの準備

次にツールチェインをダウンロードして適当な場所に置いた上で、パスを通します。 私は/optの配下に配置することにしました。

cd ~/Downloads
wget https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-61-gab8375a-5.2.0.tar.gz
tar xvfz xtensa-esp32-elf-linux64-1.22.0-61-gab8375a-5.2.0.tar.gz
mv xtensa-esp32-elf /opt/
vi ~/.bash_profile

.bash_profileには以下を追記しました。

export PATH=$PATH:/opt/xtensa-esp32-elf/bin

これで次回ログイン時からパスが通った状態の環境になります。当然ながら、即座に反映させたいときはsource ~/.bash_profileして下さい。

■ESP-IDFの準備

ESP-IDFとは、 Espressif IoT Development Frameworkの略のようです。このフレームワークは、ブートローダからデバイスのペリフェラルドライバまでを包括しており、更にサンプルが上位に加わって、文字通りフレームワークとして使えるように仕立てられています。なるほど。

後々MicroPythonと組み合わせるときに気付く事になるのですが、特定のリビジョンとの組み合わせを要求されますので、git cloneでリポジトリからコードを取り出すことにします。

cd /opt
git clone https://github.com/espressif/esp-idf.git
cd esp-idf
git submodule update --init

これで準備完了。 ESP-IDFは、外部モジュールに盛大に依存していますので、最後のgit submodule update --initをお忘れなく。

■MicroPython ESP32の準備

次にMicroPython ESP32をリポジトリから取り出します。 先のツールチェインとESP-IDFは/optに配置しましたが、こちらはホームの下に作ったProjectsディレクトリにcloneすることにしました。

mkdir ~/Projects
cd ~/Projects
git clone https://github.com/micropython/micropython-esp32.git
cd micropython-esp32/
git submodule update --init

MicroPythonも外部モジュールに依存しています。git submodule update --initをお忘れないようにね！これで一通りの準備が完了！

■フローズンモジュールをビルドする

さて、最初に行うのはフローズンモジュールのビルドです。

cd ~/Projects/micropython-esp32
make -C mpy-cross

以下のような出力が出れば完了です。

LINK mpy-cross
   text    data     bss     dec     hex filename
 133038     776     872  134686   20e1e mpy-cross

これで、MicroPythonのモジュールがビルドされた状態になります。

■本体をビルドする

はじめに、ビルド時に使用する変数を設定してMakefileを呼び出すためのメイクファイルmakefileを作ります。

cd micropython-esp32/esp32
vi makefile

エディタはお好きなものを御利用下さい。makefileは、5つの変数に必要なデータを格納した上でMakefileをインクルードするように記述します。

ESPIDF = /opt/esp-idf/
PORT = /dev/ttyUSB0
FLASH_MODE = dio
FLASH_SIZE = 16MB
CROSS_COMPILE = xtensa-esp32-elf-
include Makefile

最後に本体をビルドして完成です。

cd ~/Projects/micropython-esp32/esp32
make

これで、先ほど作ったmakefileが使われて環境変数が設定された後、Makefileがインクルードされて適切なビルドが行われます。

ビルド時、最初のメッセージにご注目。もしも、ESP IDFがサポート外のバージョンだった場合、以下のようなメッセージが出力されているはずです。

** WARNING **
The git hash of ESP IDF does not match the supported version
The build may complete and the firmware may work but it is not guaranteed
ESP IDF path:       /opt/esp-idf/
Current git hash:   cd5cc9927bf494e759b8bb513de3f4a9312bc4af
Supported git hash: 4ec2abbf23084ac060679e4136fa222a2d0ab0e8

ここで、無理に未知のバージョンで頑張る積極的な理由はないと思いますので、ESP IDFのディレクトリに移動して、Supported git hashに書かれたバージョンをチェックアウトして下さい。

ガチャガチャとビルドが進行し、以下のような出力が出てきたら出来上がり。

LINK build/application.elf
   text    data     bss     dec     hex filename
 703087  194764  138472 1036323   fd023 build/application.elf
Create build/application.bin
esptool.py v2.1-beta1
Create build/firmware.bin
bootloader     13248
partitions      3072
application   897984
total         963520

次にこれを書き込みます。

■フラッシュの消去

フラッシュの消去は、先ほどのmakefileに書き込んだPORTに書かれたデバイスファイルを経由して実行されます。

sudo make erase

実行すると以下のようなメッセージが出力されます。

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Erasing flash
esptool.py v2.1-beta1
Connecting........_
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.3s
Hard resetting...

これでフラッシュが消去されました。次にファームウェアを書き込みます。

■フラッシュの書き込み

フラッシュを消去したら、次にファームウェアを書き込みます。

sudo make deploy

実行すると以下のようなメッセージが出力されます。

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Writing build/firmware.bin to the board
esptool.py v2.1-beta1
Connecting........__
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 959424 bytes to 598202...
Wrote 959424 bytes (598202 compressed) at 0x00001000 in 15.3 seconds (effective 502.5 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting...

あれ？Auto-detected Flash sizeが4MBとなっとる... まぁ、とにかく書き込み出来ました。

■screenで接続してみる

screenコマンドを使ってシリアル接続してみましょう。

sudo screen /dev/ttyUSB0 115200

screenコマンドを終了させたい場合には、CTRL+Aを押してからKを押します。

試しにEnterキーを押してみてください。>>>が表示されていれば動作しています。

>>>
>>>
>>>
>>>
>>> import machine
>>> machine.
__name__        mem8            mem16           mem32
freq            reset           unique_id       idle
disable_irq     enable_irq      time_pulse_us   Timer
Pin             Signal          TouchPad        ADC
DAC             I2C             PWM             SPI
UART

更に「import machine」と打ってから「machine.」まで打ってTABを叩くと入力補間機能が使えます。あぁ、楽しいなぁ。

■物足りないよね？

こんな誰でもやるようなステップを踏んだ記事を読んでイライラしている方、居ますよね。居ます居ます。私もそう。

例えば、「ECO and Workarounds for Bugs in ESP32」を眺めて、Chip Revision 0に対するワークアラウンドがどのように実装されているのか見るのも楽しいでしょう。ESP32のRevision 0には、キャッシュ・メモリ・マネージメント・ユニットのバグによって、パワーアップ時/ディープ・スリープからのウェイク・アップ時に、間違ったウォッチドッグ・リセットが発生してしまいます。

さて、今回私が手にしたモジュールにはRevision 0のデバイスが搭載されていることが、フラッシュの消去と書き込み時の出力「Chip is ESP32D0WDQ6 (revision 0)」からわかっています。つまり、ワークアラウンドがなければ動作しない可能性があるわけです。このバグに対するワークアラウンドは、DPORT_PRO_CACHE_CTRL1_REGにあるPRO_CACHE_MMU_IA_CLRビットを1に設定し、次にそのビットを0にする事とあります。

では、これに対する実装はどこにあるのかというと、先ほどのESP-IDFで実装されているブートローダにあります。私の場合、ESP-IDFを/optの下に配置したので「/opt/esp-idf/components/bootloader/src/main」のディレクトリにあるbootloader_start.cにあります。

あぁ、楽しくなってきた。組み込みシステムのファームウェアというのは、こういう色々な事情を考慮した上で成り立っているんです。ちょっと実装して「あー動いた。終わり。」とか「あー動かないや。終わり。」という世界ではないんです。動いたら動いたで本当に意図した動作で動いているのか確かめる、動かないなら動かないでどこが意図しない動作で動いていないのか確かめる、どっちにしろ確かめるっていう姿勢が大事なんじゃないかと、ESP32にまつわる色々な記事を見ていて少し思いました。少しだけね。

■ここまでのまとめ

• Ubuntu 16.04.3の環境構築、ビルド、書き込み、動作確認までを一巡させた。
• 普通に動かす方法だけを書いても面白くないので、一部だけ掘り下げてみた。

■参考文献

• https://github.com/micropython/micropython-esp32

ARM-Cortex-M0などの小規模なマイコンでも簡単にシリアル入出力機能を実現するMicroShellのウェブサイトを少しだけ修正した話

ARM Cortex-M0などの小規模なマイコンでも簡単にシリアル入出力機能を実現するMicroShellのウェブサイトを少しだけ修正しました。

修正したのはAPIのページで、以前は定義や関数がズラズラと並んでいるだけのページでした。サイトを構築する際、このAPIページを眺めた後にExampleページを御覧頂く事を考えていましたが、実際にAPIページを見るだけで嫌になりそうです。というのも、読み手からして見れば早く理解して使いたいのに、何の説明もないAPIページを見させられたのではたまったものではありません。かと言って、唐突に自分に関係があるのかわからない具体的なプラットフォームに対するサンプルを提示するのも考え物です。

特に、実際のサンプルでは、複数のモジュールを組み合わせて実際のアプリケーションに近い例を見せていたため、どのAPIが必須なのか、どのモジュールで何を提供しようとしているのかが非常に不明瞭でした。

これらの振り返りをふまえ、新しいAPIページでは以下の対応をしました。

• 提示しているAPIが必ず必要なものなのか、それとも選択的に使用すれば良いものなのかわかるように[Core]と[Optional]という表記を追加した。
• 単にモジュール名称を提示するのではなく、一体何を提供しようとしているのかわかる説明をモジュール名称の前に追加した。
• かなり短いサンプルコードを対象APIのみを使って記述した。

ということで、少しだけ見やすくなったMicroShellのAPIページを是非ご覧頂き、興味があれば色々なマイコンの入力系統にお使い下さい。

https://www.cubeatsystems.com/microshell/index.html

Autodesk FUSION 360を始めてみる

最近は魅力的なマイコンが数多く出荷されていて、STM32とかそういう方向に進んでみたいなと考え始めました。なのですが、ここ数年の活動を見ていると、やっぱり最後は基板作っておしまい！な感じが否めません。そこで終わっちゃうのは寂しい。最終的に箱に入れて使えるようにしておきたいし、そのためにはやっぱり機械的な設計もしたいなと思うようになりました。ということで、ちょっとやってみようFUSION 360という流れ。

前回、機械設計をしたのは2006年、2012年にもそんな事を書いていたので、5、6年周期くらいで何か違うことをしたくなるのでしょうか。随分と過激なタイトルでも記事を書いていますね。危ない危ない。

ということで、FUSION 360を使う記事がダラダラと続くかもしれません。

ソフトウェア開発のマネージメントは航空会社の運営：課題管理における「バージョンはフライトで、チケットは乗客だ」という私のバージョンに対する考え方について

あらまし

自分たちのソフトウェア出荷物に特定の名前を付ける場合に、バージョン番号を付けることは一般に広く行われています。「あのバージョンではXXX機能が加わった」とか「このバージョンではYYY機能が加わった」とか「そのバージョンではZZZ機能が壊れている」とか、その類の話です。今日は、私のバージョンに対する考え方について述べたいと思います。

前提とか状況とか

ソフトウェア出荷物を得なければならないプロジェクトで私が用いている前提は概ね以下のとおりです。

• 人間が計画するものは必ず遅れを呼ぶ。
• 将来の予期は難しい。
• 特定のバージョンの出荷を遅らせても、劇的な状況改善に至ることはない。

ソフトウェアを出荷するということは、それまで内部で進めてきた活動が外部に現れ、それが何らかの価値を産むということです。当然ながら出荷しない限り価値は産みません。なので、企業を経営する立場からすると、ソフトウェアを早く出荷したい気持ちになります。

その対岸にいるかもしれないソフトウェア開発者から見ると、特定機能や要求への対応など複数の未解決項目があり、それらの状況は出荷に値しないと見ているかもしれません。ですから、出来るだけ出荷を延期したいかもしれません。

ソフトウェア開発のマネージメントは航空会社の運営

唐突ですが、私はソフトウェア開発のマネージメントは航空会社の運営に似ているなと常々考えていました。

例えば、あなたが上の図に示したVersion 1.0.0に向かって開発を進めているプロジェクトの開発者だったとしましょう。あなたは「DEF機能の追加」が全く間に合わず、ついつい「これはVersion 1.0.0の出荷を見合わせよう」と考え始めます。こうなるとそれに続くVersion 1.5.0もVersion 2.0.0も後ろにずれ込んでいくことになるかもしれません。

こうなると全てが後ろにずれ込んで、計画も何も無いような気持ちになってしまいますし、実際に外から見るとそんな風にダラダラ進んでいるように見えてしまうようです。

でも、出荷はフライトと同じだと少しだけ考え方を変えてみます。例えば、300人が搭乗する航空機の出発の際に、特定の乗客が乗り遅れようとしているからといって、3時間も6時間も出発が遅れることはありません。そうすると、全体の利益が損なわれてしまうからです。

これはちょうどソフトウェア開発における出荷の状況にも言えます。ある150個の仕事をこなした後に出荷すると決めたバージョンに対して、特定のある1つの仕事が間に合わなかったからといって、たとえそれがどんなに重要な仕事だったとしても、他の149個の仕事の成果を巻き添えにして出荷を(フライトに例えると出発を)遅らせるのは、もしかしたら行き過ぎかもしれません。

このバージョン(フライト)に搭載するはずだったチケット(=解決済みの課題)は、次のバージョン以降に延期されたけど、確実にプロジェクトは進んでいるよね？

こんな風に考えると、気持ちも少し楽になってきます。確かに約束した重要な機能は約束したバージョンに搭載されなかったかもしれませんが、それは次のバージョンで確実に搭載されるように配慮します。既に他の149個の仕事は完了しているのですから、搭載の遅れた1個の仕事に注力すれば、次に行うべき他の仕事よりも完了する確率は高いでしょう。

最後に

ソフトウェア開発の場合、とても乱暴に言って遅れることは問題ではありません。それよりもむしろ、進んでいないように見える、あるいは進んでいないことが一番の問題です。ソフトウェア開発のマネージメントに際して、事前に計画した内容の通りに進まないといけないといった厳しい外部制約を与えると、局所的には最適化されるのかもしれませんが、全体の動きは鈍くなる可能性があるので、私は航空会社のように全体の利益に基づいて柔軟に計画を変更することは重要だと考えるようになりました。

今すぐ出来る！HTML5なウェブサイト実現ワークショップ「#HelloHTML5」を開催します。

はじめに

近年、ウェブサイトのHTML5化が盛んに行われています。 様々なデバイスがウェブに接続されるようになり、端末の画面サイズに応じた表現なども必須になってきました。 このセミナーでは、「今すぐ出来る！HTML5なウェブサイト実現セミナー」と題して、HTML5を活用したウェブサイトの実現をワークショップ形式でお届けします。

お勧めする人

• ウェブサーバーを立ち上げたけど、魅力的なコンテンツの実現に技術的な課題を感じている方。
• サイトをHTML5化したいけど、どこから手を付けてよいかわからない方。
• 組み込みシステムのエンジニアリングが専門で、ウェブ技術の調査までなかなか手が回らない方。
• その他、とにかく現状のウェブが不満でどうにかしたい方。
• そもそも億劫でなかなかウェブの実現が進まない方。

参加登録

• https://atnd.org/events/86409 から可能です。

MicroShellをArduinoにも対応させ、Version 0.0.2として公開しました！

小規模組み込みシステムのシリアル・コンソール・インターフェースとして便利に使えるミドルウェアMicroShellをArduinoにも対応させ、Version 0.0.2として公開しました。
https://www.cubeatsystems.com/microshell/download.html からダウンロードできます。

熱血！アセンブラ入門に感化されてARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました！

ARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました。今回はとても地味にコンパイル・オプションの更新を行っただけのパッケージです。

今回の更新は完全に「熱血！アセンブラ入門」に感化されたもので、今回のパッケージを展開してLPCXpressoでコンパイルすればアセンブラまで確認できるというものになっています。

ビルドすると.hexなどの他に.asmが出力されるようにしました。

中身を見るとソースコードとアセンブラを同時に確認できます。
熱血！アセンブラ入門と同時に活用できる便利なパッケージです。

ダウンロードは以下からどうぞ。
http://cubeatsystems.com/uos-lpc800/download.html

ARM Cortex-M0でもラクラク使えるNT-Shellよりもコンパクトな端末入出力ミドルウェアMicroShellライブラリを開発しました (NXP LPC824用サンプルプロジェクト付き)

あらまし

昨年のこと、NXP LPC824を使ったサウンドモジュールMicroSoundModuleを開発していました。このサウンドモジュールは、コマンドを受け取って色々な再生を行うもので、当初はこのコマンド処理部分の実装にNT-Shellを用いる計画でした。しかし、最小10KBのROM、最小1KBのRAMを要求するNT-ShellはNXP LPC824の小さなリソースに対して厳しいものです。仮に入ったとしてもアプリケーション側に大きな制約を課すことになります。

よくよく見まわしてみると、様々な面白そうなマイクロコントローラがNXP LPC824と同クラスで存在します。ARM Cortex-M0のような小さなマイコンを使ったシステムにおいて、NT-Shellほどの機能は要らない、でも、きっちり入力は出来るようにしたい、といったニーズはありそうです。

そこで、NXP LPC824のような小さなサイズのマイコンにも導入可能な端末入出力ミドルウェアを開発することにしました。名付けてMicroShellです。

使い方

使い方はmicroshell_initという関数にハンドラの実体へのポインタと、ブロッキング型のシリアル送受信関数のポインタを渡すだけという至って単純なもの。このコードだけできっちり動作する入力系が得られます。とても簡単ですね。

内部構造

内部構造は、以下の図に示すようにcoreとutilの二つから成り立っています。本当に最小限の構成にしたい場合にはcore側のmicroshellを用い、この場合には1行の入力処理が得られます。これに加えてコマンドのパースなどを行いたい場合には、util側のmscmdを用います。

ダウンロード

ダウンロードは専用サイトからできます。

• https://cubeatsystems.com/microshell/index.html

塩漬けになっている「Micro Sound Module」をなんとかしようと思い立つ

試作してから塩漬けになっているMicro Sound Moduleですが、年末年始のちょっとした時間で取り組もうかと考えています。そもそも、塩漬けにしすぎて何をどこまでやったのか忘れてしまった。

元々、アートインスタレーションで使えるような小さなモジュールにしたかったので、仕様から様々なこだわりを切り捨てて作りました。LPC824を選択したのも、「このくらいのマイコンを選べばアレコレやろうとしても欲張れないだろう」という斜め上(下?)の動機があったりします。

ということで、ちょっと成果物を眺めてから色々と取り組んでみようと思います。

リアルタイムOS教材について思う事(をちょっとだけ書いてみる)

■あらまし

学生の頃からリアルタイム・システムに興味があって様々な書籍を読んでいた自分ですが、エンジニア・ライフを約一周ほど楽しんで、そろそろ思うことあってリアルタイムOS教材についても触れなければならないなと考え始めました。というのも、世の中に溢れる教材の中には、初学者に与えるべきでない間違った例が数あまたあり、それらが実開発の現場で様々な問題を生んでいるからです。今日はその中からひとつだけ取り上げてショート・ブレイクとして書いてみます。

■良くない例：タスク・スリープで排他処理

世の中には不思議な例を取り上げてリアルタイムOSの機能を紹介する例を見かけます。その代表例がタスク・スリープで排他処理やシステムの状態を管理する例です。

この例を取り上げる教材の多くは、リアルタイムOSの機能を紹介したいようでもあるのですが、よくよく読んでみると、結局のところどれも「こういうときはこうするのだ」と実際のアプリケーションについて触れています。しかし、このような設計で実システムを実現されてはひとたまりもありません。

リアルタイムOSの使い方として間違ったアイデア、「タスク・スリープで排他処理やシステムの状態を管理」が何を言っているのか図示してみます。

タスクAとタスクBは、それぞれグローバル変数であるint valueを操作します。もうグローバル変数が出てくる時点で完全に失格なのですが、問題はそこではありません。この典型的な間違ったアイデアは、よく以下のような方法で紹介されています。

①システム起動直後、タスクAは動作し、タスクBは寝ています。

②タスクAはint valueを操作し、タスクBを起こして自分は寝ます。

③起床したタスクBはint valueを操作後、タスクAを起こして自分は寝ます。

例えば、この設計には以下の疑問がつきまといます。

A. タスクAとタスクBが非同期で双方動作している瞬間について考慮されていない。

B. タスクAがタスクBを知っている。タスクBがタスクAを知っている。つまり循環参照関係にある。

C. やっている内容から考えると、そもそも単一タスクで良い。(説明に必然性が全く無い)

D. その他。

上の例、int valueと書いてあるものは物理デバイスであることもあります。となると、なおさら問題は複雑になります。というのも、物理デバイスは動作に時間がかかります。状態遷移中の物理デバイスの状態を適切に扱う場合、上記の例では対処できません。

■例えばどうすれば良いのか？

リアルタイムOSを使うのは、抽象化レベルを上げつつ、キビキビとした動作を実現できるからです。上記の例で言うと、int value(物理デバイスかもしれない)は、操作対象ですが、これはあるタスク内部で操作される操作対象と見ることができます。つまり、タスクAやタスクBから操作される新たなタスクCのようなものが内部で操作する対象とすることができます。

そして、タスクAやタスクBからメッセージ通信でタスクCに操作を依頼する形式を取ります。

「ちょっと待って！さっきの例で出来ていたタスクAとタスクBの同期ができないじゃない！」と言われるかもしれませんが、タスクCは単一スレッド上でメッセージ受信処理を行っているので操作は競合しません。

加えて、タスクCのAPIを工夫しておけば、操作自体も抽象化された表現で扱うことが可能になります。

• アームを上に上げろ！
• アームを下に下げろ！
• 緊急停止！

上記のような操作を抽象的に表現したAPIにするだけで、グンとシステムで操作する内容がわかりやすくなってきます。そして、実装の詳細はタスクCに隠ぺいされるというメリットも生まれます。タスクAとタスクBが循環参照状態になる事もありません。

■ということで・・・

リアルタイムOSの教材でタスクのスリープを使って状態をコントロールするような例を見かけたら、「この教材は怪しいな」と疑って内容をレビューしてみて下さい。

ちょうど100円玉サイズ！NXP LPC824を使ったとっても小さなWAV File Player「Micro Sound Module」を作りました！

■KiCadへの移行

2016年2月にCADをEAGLEからKiCadに移行する練習を兼ねて、何か実際に作ってみようと考えていました。でも、あまり大きな設計はしたくない。そこで小ピンでも何か面白いことが出来そうなマイコンを使うことを考え、LPC824を使ったとっても小さなWAV Player「Micro Sound Module」を作ることにしました。こちらが完成品。じゃん！

EAGLEからKiCadに移行する人の中には、独特なユーザーインターフェースに戸惑いを感じる事もあるようですが、OrCADなどの業務でも使われているCADに馴染みのある人にとっては、逆に自然に移行できるのかも。私の場合、KiCadへの移行に合わせて、回路図、基板、3Dモデルを3画面で同時に見れるようにPC環境を更新しました。これはとても便利。

パッド名やネット名の確認が簡単に出来たり、リアルタイムでルールチェックを行なってくれるところも素敵です。EAGLEの場合には後からデザインルールチェックをかけるわけですが、これを忘れてしまうととんでもない状態で基板を作ってしまう事になります。そういう事は起こらないのが良いなぁと思いました。

私が使ったKiCadのバージョンでは、フットプリント側で配線禁止エリアや配置禁止エリアを指定できず、これはちょっと困ったことになりましたが、この苦しい制限があってもEAGLEには戻れない気持ちになっています。そのうちこの苦しい状況も改善されるでしょうと期待。

■Micro Sound Moduleの企画

マイコンがそもそも小さいのでコンパクトに面白いことができそう、と企画したのがMicro Sound Moduleです。本体のデザインは以下のようなもの。

Micro Sound Moduleですが、とにかく小さくて便利な機能満載！と行きたかったのですが、現状でROMがパンパンでI2Cスレーブ機能が入りません。苦し紛れにI2C端子をGPIにしてスイッチで制御出来るようにしました。

Micro Sound Moduleプロジェクトの副産物。

某企業さんに行ったプレゼンテーション資料の中で何故か好評だったシリアル通信の説明文・・・。

■ファームウェア

ファームウェアには色々な仕掛けが施されていて、面白いことが出来るので何処かでお見せできるように準備したいなぁと考えています。コマンドの例を挙げると・・・

• ディスクコマンド（マウント、アンマウント、情報取得）
• ファイルコマンド（ディレクトリ指定、リスト取得、オープン、クローズ、情報取得）
• トランスポートコマンド（再生、停止、ジャンプ、情報取得）
• マーカーコマンド（設定、解除、ジャンプ、情報取得）

こんな感じでひととおりの制御が可能なコマンドを装備しています。

コマンドパーサーにはNT-Shell (Natural Tiny Shell)を使用する予定でしたが、ROM容量の都合であえなく断念し、新しくコンパクトなパーサーを書きました。そろそろこれも公開したい。

Artistic Style (astyle) でコードを整形する

■インデントって重要

最近、色々な人のコードを眺めるにつけ、インデントまできちんと目を配って実装している人とそうでない人との間に、とてつもなく大きな壁がある事に気付きました。前者、インデントまできちんと目を配って実装している人の多くは、不要な実装、余計な実装は一切無く、終始一貫した表現で実装されています。対して、後者のインデントに気を使わない人の多くは、未使用変数や未使用関数、全く意味のないコメントやデバッグ文の散乱、ハードタブとソフトタブの同居・・・その他たくさんの危険な香りのする実装が残されています。ここ数年で見ていく中でインデントと成果物の内容に相関性があるのでは？という疑問に至り、インデントをきちんと行う姿勢に変えるだけでもその人のアウトプットが改善されるようにすら思えてきました。(今は単にそう思っているだけ)

■最近はArtistic Styleなの?

私の場合、ソースコードは常にvimで編集しています。autoindentは常にonですし、整形する際も組み込まれた整形機能をパパッと充てて済ませていました。ふとしたことから「最近では皆さんどうしているのかな？」と疑問に至り調べてみたところ、Artistic Style (astyle)というツールが割と最近では使われているようです。メジャーなLinuxディストリビューションではパッケージ管理システムから簡単にインストールできますし、Windows版はsourceforge.netのプロジェクトページから入手可能なようです。

■"One True Brace Style"が使える!

Artistic Styleでは、様々なコーディングスタイルを実現できるように豊富なオプションが用意されています。自分たちのコーディングスタイルに合わせてオプションを加えて実行できるのは嬉しい点です。"One True Brace Style"は、条件分岐などで一行で完結する命令の場合でも波括弧を付けて実装するスタイルのひとつで、私が好んで使用しているスタイルのひとつです。Artistic Styleでは、「--style=otbs」という引数を与えるだけで、One True Brace Styleになっていないコードでも自動的に波括弧を加えて整形してくれます。他にも様々な代表的なコーディングスタイルに対応しているので、きっと自分の気に入ったスタイリングオプションを見つける事ができるでしょう。

CQ出版Interface2016年10月号の第七章にMicroPythonに関する記事を書きました

CQ出版Interface2016年10月号の第七章にMicroPythonに関する記事を書きました。

今回の記事は「とにかくソースコードと格闘してMicroPythonの世界を体験しようよ！」という内容になっています。成長中のオープンソースでこのような記事を書くと本当に生ものになってしまい、数か月後には「記事の内容と全然違う！」なんて事も多々あるので迷いましたが、「こーんな風に見ていけば良いんだよ」という雰囲気が少しでも伝わればという考えでしたためました。

ちなみに、記事のタイトルは「MicroPythonプログラミング」となっていますが、MicroPythonの中身を知るための入り口として、既存のモジュールに機能を追加する体験記事になっています。「なーんだ、ポーティングじゃないんだ」とか「プログラミングじゃないじゃん」と思われるかもしれませんが、騙されたつもりで一度体験してみて下さい。このちょっとした機能追加を体験する事が、意外にも内部構造の理解や機能拡張、更には別のプラットフォームへの展開の大きなヒントになります。

記事の中で使用したボードはNUCLEO-F401REです。
秋月電子通商さんやスイッチサイエンスさんから購入できます。

ダウンロードコーナーのファイル(2016年 10月号 データ解析時代の新定番 Python)には執筆段階で使用したコードと環境構築用スクリプト(Ubuntu 16.04用)も含まれますので御利用下さい。