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ページを是非ご覧頂き、興味があれば色々なマイコンの入力系統にお使い下さい。




2017年6月30日金曜日

Autodesk FUSION 360を始めてみる

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


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


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


2017年5月31日水曜日

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

あらまし

自分たちのソフトウェア出荷物に特定の名前を付ける場合に、バージョン番号を付けることは一般に広く行われています。「あのバージョンでは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個の仕事に注力すれば、次に行うべき他の仕事よりも完了する確率は高いでしょう。

最後に

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

AltStyle によって変換されたページ (->オリジナル) /