最近はマイコンで遊ぶ暇もないくらい忙しいのですが、なんとFreeRTOSがAWSオープンソースプロジェクトになって、しかもMITライセンスが採用されたらしいです。
あぁ、たまにはゆっくりマイコンで遊びたいなぁ。
どんどん時代が変わっていきますね。
https://aws.amazon.com/jp/freertos/
2017年11月30日木曜日
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+から一段掘り下げた情報が得られます。
ここまでで、「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命令セットが出てきましたね。
今回のまとめ
「ARM Cortex-M0+は、ARMv6-Mと呼ばれるCPUを使っていて、命令セットアーキテクチャはThumb/Thumb-2のサブセットである。T32命令セットはThumbとして知られている。」という事がわかりました。
次回は、ドキュメントのページhttps://developer.arm.com/products/architecture/m-profile/docsに辿り着いて色々と見てみましょう。
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■ESP-IDFの準備
ESP-IDFとは、 Espressif IoT Development Frameworkの略のようです。このフレームワークは、ブートローダからデバイスのペリフェラルドライバまでを包括しており、更にサンプルが上位に加わって、文字通りフレームワークとして使えるように仕立てられています。なるほど。
後々MicroPythonと組み合わせるときに気付く事になるのですが、特定のリビジョンとの組み合わせを要求されますので、git cloneでリポジトリからコードを取り出すことにします。
後々MicroPythonと組み合わせるときに気付く事になるのですが、特定のリビジョンとの組み合わせを要求されますので、git cloneでリポジトリからコードを取り出すことにします。
cd /opt
git clone https://github.com/espressif/esp-idf.git
cd 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-crossLINK mpy-cross
text data bss dec hex filename
133038 776 872 134686 20e1e mpy-cross■本体をビルドする
はじめに、ビルド時に使用する変数を設定して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ビルド時、最初のメッセージにご注目。もしも、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 eraseUse 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 deployUse 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...■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のページで、以前は定義や関数がズラズラと並んでいるだけのページでした。サイトを構築する際、この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個の仕事に注力すれば、次に行うべき他の仕事よりも完了する確率は高いでしょう。
最後に
ソフトウェア開発の場合、とても乱暴に言って遅れることは問題ではありません。それよりもむしろ、進んでいないように見える、あるいは進んでいないことが一番の問題です。ソフトウェア開発のマネージメントに際して、事前に計画した内容の通りに進まないといけないといった厳しい外部制約を与えると、局所的には最適化されるのかもしれませんが、全体の動きは鈍くなる可能性があるので、私は航空会社のように全体の利益に基づいて柔軟に計画を変更することは重要だと考えるようになりました。
2017年4月30日日曜日
今すぐ出来る！HTML5なウェブサイト実現ワークショップ「#HelloHTML5」を開催します。
はじめに
近年、ウェブサイトのHTML5化が盛んに行われています。 様々なデバイスがウェブに接続されるようになり、端末の画面サイズに応じた表現なども必須になってきました。 このセミナーでは、「今すぐ出来る！HTML5なウェブサイト実現セミナー」と題して、HTML5を活用したウェブサイトの実現をワークショップ形式でお届けします。
お勧めする人
- ウェブサーバーを立ち上げたけど、魅力的なコンテンツの実現に技術的な課題を感じている方。
- サイトをHTML5化したいけど、どこから手を付けてよいかわからない方。
- 組み込みシステムのエンジニアリングが専門で、ウェブ技術の調査までなかなか手が回らない方。
- その他、とにかく現状のウェブが不満でどうにかしたい方。
- そもそも億劫でなかなかウェブの実現が進まない方。
参加登録
- https://atnd.org/events/86409 から可能です。
2017年3月26日日曜日
MicroShellをArduinoにも対応させ、Version 0.0.2として公開しました！
小規模組み込みシステムのシリアル・コンソール・インターフェースとして便利に使えるミドルウェアMicroShellをArduinoにも対応させ、Version 0.0.2として公開しました。
https://www.cubeatsystems.com/microshell/download.html からダウンロードできます。
https://www.cubeatsystems.com/microshell/download.html からダウンロードできます。
2017年2月28日火曜日
熱血！アセンブラ入門に感化されてARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました！
ARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました。今回はとても地味にコンパイル・オプションの更新を行っただけのパッケージです。
今回の更新は完全に「熱血！アセンブラ入門」に感化されたもので、今回のパッケージを展開してLPCXpressoでコンパイルすればアセンブラまで確認できるというものになっています。
ビルドすると.hexなどの他に.asmが出力されるようにしました。
中身を見るとソースコードとアセンブラを同時に確認できます。
熱血！アセンブラ入門と同時に活用できる便利なパッケージです。
ダウンロードは以下からどうぞ。
http://cubeatsystems.com/uos-lpc800/download.html
今回の更新は完全に「熱血！アセンブラ入門」に感化されたもので、今回のパッケージを展開してLPCXpressoでコンパイルすればアセンブラまで確認できるというものになっています。
ビルドすると.hexなどの他に.asmが出力されるようにしました。
中身を見るとソースコードとアセンブラを同時に確認できます。
熱血！アセンブラ入門と同時に活用できる便利なパッケージです。
ダウンロードは以下からどうぞ。
http://cubeatsystems.com/uos-lpc800/download.html
2017年1月31日火曜日
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です。
そこで、NXP LPC824のような小さなサイズのマイコンにも導入可能な端末入出力ミドルウェアを開発することにしました。名付けてMicroShellです。
使い方
使い方はmicroshell_initという関数にハンドラの実体へのポインタと、ブロッキング型のシリアル送受信関数のポインタを渡すだけという至って単純なもの。このコードだけできっちり動作する入力系が得られます。とても簡単ですね。
内部構造
内部構造は、以下の図に示すようにcoreとutilの二つから成り立っています。本当に最小限の構成にしたい場合にはcore側のmicroshellを用い、この場合には1行の入力処理が得られます。これに加えてコマンドのパースなどを行いたい場合には、util側のmscmdを用います。
ダウンロード
ダウンロードは専用サイトからできます。
登録:
投稿 (Atom)