2019年11月8日金曜日

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

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

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

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

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

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

何かのきっかけ

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

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

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

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


心に決めたこと

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

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

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

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

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

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

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

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

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

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

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

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

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

2019年11月3日日曜日

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

万物世界共通

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

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

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

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

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

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

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

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


ちょっと古い2000年頃の話

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

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

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

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


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

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

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


で?

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

2017年11月30日木曜日

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

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

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

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

2017年10月31日火曜日

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におけるコアレジスタ定義が表になっているのでここから進めることにしましょう。
続きは次回...え?

2017年9月30日土曜日

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がアーキテクチャのリファレンスマニュアルです。

2017年8月13日日曜日

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

■参考文献

2017年7月30日日曜日

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

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

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


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

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

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

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