PocketBeagle の Rev A2 は印刷されたGPIO番号が1箇所間違っている

小ネタですが、知らない人(=未来の俺)がドハマりするかもしれないので。

PocketBeagleに限ったことですが、リビジョン番号が「A2」と印刷されたロットだと、GPIOの44番が「48番」と間違って印刷されています。

ちなみに私の所有するPocketBeagleはといいますと、

PocketBeagle Revision A2

大当たりー。
で、問題のGPIO44はこの裏側、P2ヘッダ側の「+3.3V」と対になっている箇所にシルク印刷されています。

PocketBeagle GPIO44 incorrectly labelled as 48

まあ、分かってはいたんですが、実際見るとちょっと凹みますね。。。

ちなみにこの問題は次ロットでは修正されるということですが、PocketBeagleそんなに売れていないと思うので(笑)、次のロットが市場に出てくるのはもう少し先になるんじゃないかなと。

言い換えると、現在日本国内で入手できるPocketBeagleはほぼ確実に「A2」リビジョンになると思われるので、欲しい方は諦めて「A2」を購入
しましょう。大丈夫、きっといつかプレミアつきますから。

地味なエラーですけど、シルク印刷見ながら製作してる人は「信号が出ない!」と思っちゃいますよね。実際バグチケットもいくつか切られてますし。

https://github.com/beagleboard/pocketbeagle/issues/4

個人的には、サプライヤー大手のMouserのデータシートや、 Digi-keyのデータシートに未だに間違った情報が載っているのが混乱に拍車をかけている気もするんですが。

さすがに公式のデータシートはちゃんと修正されています。何かあればまず公式で確認、ということでしょうね。

共有ライブラリへの依存関係を確認する

BeagleBone と直接関係しませんが、知らなかったのでメモ。

コンパイル時、ダイナミックリンクで実行ファイルを作成した場合に、どの共有ライブラリに依存しているか ldd コマンドを使用して調べることができる。

例えば、以下のような bbb という実行ファイル(中身はただの helloworld プログラム)に対して、

debian@beaglebone:/tmp/tmp.wUMMEnbj8v/cmake-build-debug-bbb$ ll
total 88
drwxr-xr-x 3 debian debian  4096 Feb 23 12:54 .
drwxr-xr-x 5 debian debian  4096 Feb 23 12:53 ..
-rwxr-xr-x 1 debian debian 11100 Feb 23 12:54 bbb ← これ
-rw-r--r-- 1 debian debian  5166 Feb 23 12:53 bbb.cbp
-rw-r--r-- 1 debian debian 41700 Feb 23 12:53 CMakeCache.txt
drwxr-xr-x 5 debian debian  4096 Feb 23 12:54 CMakeFiles
-rw-r--r-- 1 debian debian  1376 Feb 23 12:53 cmake_install.cmake
-rw-r--r-- 1 debian debian  4725 Feb 23 12:53 Makefile

ldd コマンドで依存関係を確認することができる。

debian@beaglebone:/tmp/tmp.wUMMEnbj8v/cmake-build-debug-bbb$ ldd bbb
	linux-vdso.so.1 (0xbed75000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6e1e000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6da6000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6d7d000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c8f000)
	/lib/ld-linux-armhf.so.3 (0xb6f3c000)

自作プログラムに限らず、実行形式ファイルであれば何でも確認できるので、例えば普段使っているコマンドが突然動かなくなった場合などに、依存している共有ライブラリの存在チェックに使えそう。

(以下は ls コマンドの依存関係を調べた例)

debian@beaglebone:~$ ldd /bin/ls
	linux-vdso.so.1 (0xbed48000)
	libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6ee6000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6df8000)
	/lib/ld-linux-armhf.so.3 (0xb6f37000)
	libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb6d99000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6d86000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6d62000)

指定できるパラメータは以下の通り

debian@beaglebone:~$ ldd --help
Usage: ldd [OPTION]... FILE...
      --help              print this help and exit
      --version           print version information and exit
  -d, --data-relocs       process data relocations
  -r, --function-relocs   process data and function relocations
  -u, --unused            print unused direct dependencies
  -v, --verbose           print all information


PocketBeagle の動作速度をカスタマイズする

まず現在の動作速度および動作モード(ガバナーというらしい)を cpufreq-info コマンドで確認する。

debian@beaglebone:~$ cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 300 us.
  hardware limits: 300 MHz - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 720 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz.
  cpufreq stats: 300 MHz:0.00%, 600 MHz:0.00%, 720 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:100.00%

PocketBeagle は 300MHz, 600Mz, 720MHz, 800MHz, 1000MHz で動作可能。 (デフォルトは 1000MHz)

The governor "performance"... とあるので、現在 performance ガバナーで動作している事がわかる。

PocketBeagle でサポートしているガバナーはconservative, ondemand, userspace, powersave, performance の5つ。

debian@beaglebone:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance

Archlinuxスケーリング governor のページと比較すると、PocketBeagle ではschedutil 以外のガバナーを全てサポートしている。

Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux では、ondemand ガバナーでCPU負荷にしきい値を設定して、しきい値を超えたタイミングでCPUの動作速度を変更する例が記載されていたが、自分の用途では遠隔から手動で動作を切り替える、という手段が望ましい。

試しに動作速度を最低の 300MHz まで落としてみる。

debian@beaglebone:~$ sudo cpufreq-set -f 300MHz
debian@beaglebone:~$ cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 300 us.
  hardware limits: 300 MHz - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 720 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 300 MHz.
  cpufreq stats: 300 MHz:2.43%, 600 MHz:9.19%, 720 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:88.38%  (26)

簡単に動作速度を変更できた。
組み込み用途でスタンバイ中に消費電力を抑えるのに使えそうだ。

なお、起動時にデフォルトで選択されるガバナーはperformance
これを変更したい場合は、起動スクリプトを直接編集するしかないようだ。

debian@beaglebone:~$ sudo grep -B20 -A2 -e "^GOVERNOR=" /etc/init.d/cpufrequtils 

# Which governor to use. Must be one of the governors listed in:
#   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
#
# and which limits to set. Both MIN_SPEED and MAX_SPEED must be values
# listed in:
#   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
# a value of 0 for any of the two variables will disabling the use of 
# that limit variable.
#
# WARNING: the correct kernel module must already be loaded or compiled in.
# 
# Set ENABLE to "true" to let the script run at boot time.
# 
# eg:	ENABLE="true"
#	GOVERNOR="performance"
#	MAX_SPEED=1000
#	MIN_SPEED=500

ENABLE="true"
GOVERNOR="performance"
MAX_SPEED="0"
MIN_SPEED="0"

ガバナーの考え方は、Redhat のドキュメントが分かりやすかった。

※ もし cpufreq-info コマンドがインストールされていない場合は apt install で取ってくる。 (自分の環境では既にインストールされていた)

debian@beaglebone:~$ sudo apt install cpufrequtils
[sudo] password for debian: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
cpufrequtils is already the newest version (008-1+b1).
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.

BeagleBone Black (BBB) と PocketBeagle の比較

色々先走って書き出してしまいましたが BeagleBone Black (BBB) と PocketBeagle の比較表ぐらいは必要だろうと作成してみました。

表レイアウトが微妙なのは筆者のスキル不足です。

モデルBeagleBone Black (BBB)PocketBeagle
価格
$55$25
プロセッサ1GHz AM335x x 1
32bit RPUs x 2
1GHz AM335x x 1
32bit RPUs x 2
メモリ
512MB DDR3512MB DDR3
ストレージ4GB eMMC

MicroSD スロット
MicroSD スロット
映像出力micro-HDMIなし
デバッグJTAGJTAG
インターフェース
46pin GPIO x 236pin GPIO x 2
ネットワーク10/100 Ethernetなし
無線LANなしなし
電源USB経由 または DCジャック (5.5mm)USB経由またはGPIOヘッダ

ご覧のとおり、インターフェースには明確な差異があるものの、プロセッサとメモリ構成は、実は BBB と PocketBeagle で同じなんですね。

小さい=非力ではないので、アプリケーションの構成によってはPocketBeagleでも BBB と同等の性能を発揮できそうです。これは嬉しい。

ですので、BBB と PocketBeagle どちらを選ぶかは、性能ではなくユーザの利用目的で選べばいいと思います。Raspberry Pi 的な使い方をしたい人は BBB、Arudino や mbed マイコン的な組み込みに近い用途で開発をしたい人は PocketBeagle という感じでしょうか。

でも、ラズパイ的な使い方したい人はラズパイ買っちゃうだろうから、結局 BBB の認知度はちっとも上がらないんですよね。。。

オチがついたところで今日はここまで。

BeagleBoneのGPIO最大電流は4-6mA

タイトルそのまんまなんですが。結構少ないなという印象です。

GPIO 接続で電流を消費するデバイスと言われて思い浮かぶのは LED なんですが、よくある感じの LED でも標準電流 20mA なので、定格オーバーしないように注意が必要です。(BeagleBone に限った話ではないですが)

ちなみに少し調べてみると、マイコン別の最大電流は Arduino Uno で 10-20 mA、mbed リファレンス機である LPC1768 で45-50mA でした。Raspberry Pi でも 17mA なので、他家と比べても控えめですね。

BeagleBone のデータシートはこちらからどうぞ。

Beaglebone de RTOS

BeagleBone デバイスを使ったリアルタイム OS (RTOS) 開発について学習しています。BeagleBone は Linuxリソースを活用したパワフルな処理系と、センサ系コントロールに求められるリアルアイム処理系を並行利用できる画期的なマイコンです。

BeagleBone シリーズの中で、特に PocketBeagle (PB) について調べています。PocketBeagle は大雑把に言えば、標準機である BeagleBone Black (BBB) から内蔵メモリとディスプレイ出力、それにネットワーク機能を省略したものになります。

といっても、microSD カードをストレージとして使用できますし、USB 経由で母艦 PC と接続すれば SSH でログインしたり、インターネットに接続することもできます。それ以外の機能は BBB と「ほぼ」同等ですので、筆者のように組み込み用途で利用する方には PocketBeagle がオススメです。サイズも価格も半分以下ですし。

とはいえ、いきなり PocketBeagle からスタートするのはさすがに躊躇しました。何せ BeagleBone 自体の情報が少ないのと、事例の殆どが BBB を使用したものばかりだったからです。さらに本命の RTOS の仕様についても、バージョンによって大分異なるという情報を見かけ、これは厳しいかな…と思っていました。

転機は2019年1月に発売された Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux という本でした。これは2014年に出版された初版の改訂版で、最新の BeagleBone シリーズへの対応を謳っています。全てのソースコードについて BBB と PocketBeagle でテスト済み、かつ PRU-ICSS (RTOSを実現するためのアーキテクチャ) 部分については完全に書き直したとのこと。

著者の Derek Molloy 氏は Dublin City University の助教授で、平易な文章とアカデミックな章立てが非常にわかり易く、この本読んでも使いこなせないなら BeagleBone を諦めよう、と思わせてくれる構成になっています。とはいえ洋書ですし、ボリュームもあるので万人受けはしないと思いますが、少なくとも筆者にはコレハ!と思わせてくれる一冊でした。

2019年の1月半ばにアマゾンでポチり、途中くじけつつ、仕事に追われつつ、今も現在進行系で読み進めているところです。少しずつになると思いますが、有用な見つかれば随時更新します。

なお「有用な」の基準は、当時の筆者のスキルレベルとなっておりますので、そのあたりも含めて生暖かく見守って頂けたらと思います。m(_ _)m


cordova プロジェクトで platform が依存する cordova バージョンを確認する方法

cordova プロジェクトにおいて、個々のプラットフォームがビルドに必要とする cordova のバージョン番号を確認するには、CordovaLib 以下にある VERSION ファイルの中身を参照すれば OK です。

具体的な例として、例えば ios プラットフォームの場合、プロジェクト直下で以下のコマンドを実行すればバージョン番号が確認できます。

$ cat ./platforms/ios/CordovaLib/VERSION 
3.5.0

ちなみに、このバージョン番号は CORDOVA_VERSION_MIN_REQUIRED として CDVAvailability.h 内でも定義されているとおり、特定のプラットフォームにおいてビルドを実行するのに必要となる「最小のバージョン番号」になります。

CORDOVA_VERSION_MAX_REQUIRED という定数は定義されていないため、感覚的にはこれよりも大きい cordova バージョンを使えば問題なさそうですが、実際には cordova バージョンが大きすぎる場合ビルドに失敗することがあります。

もし cordova build が失敗する場合は、このファイルで定義されているバージョン番号と同じか、少しだけ大きいバージョン番号で試すと良いでしょう。

$ grep "CORDOVA_VERSION_MIN_REQUIRED __CORDOVA" ./platforms/ios/CordovaLib/Classes/CDVAvailability.h
    #define CORDOVA_VERSION_MIN_REQUIRED __CORDOVA_3_5_0

このプロジェクトの例では、cordova 3.5.0-0.2.0 〜 3.6.3-0.2.13 では問題ありませんでしたが、cordova 4.0.0 〜 ではビルド NG でした。

バグが出たからと数年前に納品済みのアプリのソース一式を渡されて、ビルドすらできずに戸惑った自分への戒めを含めたメモでした。

さくら VPS から AWS に乗り換えました

クラウドと言えば AWS といっても過言ではないこのご時世。実際仕事で AWS を使う機会もぐぐっと増えました。
時代の波には逆らえず、このブログも AWS への完全移行の運びとなりました。
といっても、見た目は全く変わらないんですけどね。
テストも兼ねてカキコでした。

kindle 無印と kindle paperwhite の割引セール 8/21まで

ずっと気になってた kindle ですが、最近リニューアルされた無印(一番安いグレード)が、かなりコストパフォーマンスが良いと知人から聞いてますます欲しくなってしまいました。

ガラケー、スマホ、タブレット、ノートPCをそれぞれ所有し、しかも仕事で毎日それら全てを運んでいるという、便利なのかバカなのかわからない状態の作者。ここで kindle 購入したらある意味コンプリート。完全なバカ。

バカは別にいいんですが、これ買っちゃったらもう欲しいガジェットなくなっちゃうんだろうなぁ…と、目的とは若干ずれた視点でも悩んでたりもします。好きなものは最後にとっておくタイプなので。

で、結論から言うと、買っちゃいました。(ポチっただけですが)

いつ何かに背中を押されてもおかしくない状態だったのですが、決め手となったのは、離れて暮らす父親の誕生日に贈ろうかな…と。

kindle は本をギフトとして贈ることもできるらしいので、kindle 本体を贈った後も、父親が好きな歴史ものの本を見つけるたびに贈る、といった事もできそうです。父親とは最近すっかり疎遠になってしまっているので(主に自分が悪いんですが)、「kindle+本」を通じたコミュニケーションなんてのも面白いかなあと。

本当は直接会って本の感想とか言い合いながら酒を酌み交わすなんてのが理想なんですけど、遠距離と仕事と子育てに奮闘していると、なかなかそんな機会にも恵まれないです。職人だった父親は用がないと連絡してこない人タイプの人なので、引退してからはますます音沙汰がなくなってしまい、何かきっかけが欲しいと思っていたところなので、今回のキャンペーンに乗じて kindle 試してみる事にしました。

あ、そもそも使ってくれるかという疑問は、確かにありますけどね。老眼だし。
いやむしろ文字サイズを変えられる kindle なら読みやすい?
まあ出たとこ勝負ですね(笑

chibi:bit (micro:bit 互換) テスト版 Bボタン不具合の修理

mbed祭り 2016@初夏の札幌 で実物を見てからずっと気になっていた micro:bit の国内向け互換機 chibi:bit 。
基本的なアーキテクチャはそのままに、日本で技適取得済みの bluetooth モジュールを採用し、日本国内での利用を可能にしたデバイスです。

教育用マイコンというと Arduino や raspberry Pi が既に先行していますが、micro:bit は押しボタンや LED マトリクス、加速度センサ、地磁気センサといった子供でもお手軽に使える入出力装置が組み込まれているのが特徴です。特に LED マトリクスは 5×5 の LCD ディスプレイの代わりとして利用することが可能で、標準のライブラリを使えばメッセージをスクロール表示(場末のスナックとかで見かける「い..ら..っ..し..ゃ..い..ま..せ..!」と文字が流れるアレ)させることもできます。あとは外付けセンサー等との接続にワニ口クリップが使えるよう、コネクタの幅が大きめにとってあったりとか、電池をつけるためのコネクタが標準で付いていたりとか、後発ゆえに色々考えられているなあという作りになってます。

スイッチサイエンスさんでは今回の製品化に先駆け、製品化前モニターテストというものを募集していましたが、張り切って応募したものの、残念ながら落選。

そうなると余計欲しくなるのが人情。
さすがスイッチサイエンスさん、良く分かってます(笑)

畳みかけるように Maker Faire Tokyo 2016 のタイミングで chibi:bit テスト版の限定販売を行うと聞き、早速注文。テスト版といっても製品版と機能は同じで、しかし価格は製品版よりも抑えての販売のことで、このあたりにスイッチサイエンスさんの良心を垣間見たような気がしました。

しかし・・・

注文商品発送のお知らせを受領し、到着を今か今かと待っていたまさにその日、一通のメールがスイッチサイエンスさんから届きました。
なんとテスト版の基盤パターンに不具合が見つかり、実装されている B ボタンが動作しないとのこと。

chibi:bitテスト版、返品返金もしくは返品交換をいたします。

何でも B ボタンのパッドが地磁気センサのパターンと被ってしまっているのが原因とのことで「はんだ付けに自信のある方は」という前提で修正方法も公開されていいます。

この問題に対し、スイッチサイエンスさんでは「返品交換」もしくは「返品返金」で対応するとのこと。
それについては素晴らしい対応だと思うのですが、販売価格を抑えた利益の薄いテスト版なのに、返品→修理→交換とかしてたら完全に赤字なんじゃないかと。

さらに言えば今回のは「テスト」と謳った版なわけで、これを理解した上で購入した側としては一定の責任を追う必要があるべきではないかと思うわけですよ。更に踏み込むなら「テスト版デバイスの購入者ならばこの程度の困難は何とかしてくれるはず」というスイッチサイエンス担当者の心の叫びが聞き取れるというか、いやひょっとしてこれはもはやスイッチサイエンスからの挑戦状なのでは・・・!と妄想に妄想を重ねた作者は「返金」でも「交換」でもなく「自分で修理」の道を選択したのでした。
(前置き長くてすみません)

現状確認

基本的には前述の修正方法に乗っ取れば OK な訳ですが、百聞は一見にしかず、ということで自分の基盤をチェック。
おお、確かにパターン被ってる。

chibi_bit_001

作業開始

パターンをカットした上で、接触箇所を避ける形でジャンパーを飛ばせばいいわけですね。
・・・と書いたものの、このパターン、相当細いですよ。0.3mm くらい?
スルーホール部分でようやく 0.7 mm 位でしょうか。
(まだ)老眼とかじゃなくてよかった・・・

chibi_bit_002

スルーホール周辺のレジストをカッターの背で削って銅箔を露出させ、接触箇所のパターンを切ったところです。
レジスト削りよりも、パターンカットの方が怖かったです。隣のパターンを切ってしまいそうで・・・
カット後に導通をチェックして、ボタンのパッド部分との導通がないことを確認しました。

chibi_bit_003

最終的にこんな感じになりました。
手持ちのリード線で一番細いやつ使ったんですが、それでもパターンより太くて難儀しました・・・

先ほど露出させた銅箔にほんの少しだけフラックスをつけ、軽くハンダを乗せた上で、同じく事前にハンダを乗せたリード線を固定して、ハンダごての先で素早く融着させる感じで固定しました。
リードを固定する時に使ったクリップが強力すぎて、被覆が少し潰れているのはご愛敬。(^^;

動作確認

ボタン動作を試す簡単なプログラムを書いて chibi:bit に流し込み、実際に B ボタンが動作することを確認しました。
A/B ボタンいずれかを押すと 5×5 LED マトリクスに「A」または「B」と表示されます。

テストに使ったコードは https://developer.mbed.org/users/iwaita2ya/code/microbit_button_test/ でもシェアしていますが、念のためこちらにも全文貼り付けておきます。

/******************************************************************************
main.cpp

Tatsuya Iwai @ greysound.com
Original Creation Date: Aug 12, 2016
https://github.com/sparkfun/LSM9DS1_Breakout

This simple program tests built-in "A" and "B" button on micro:bit or any
compatible devices (such as "chibi:bit") shows button label on LED matrix
when either button is pressed.

Distributed as-is; no warranty is given.
******************************************************************************/

#include "MicroBit.h"

// Objects --------------------------------------------------------------------
MicroBitMessageBus bus;
MicroBitButton buttonA(MICROBIT_PIN_BUTTON_A, MICROBIT_ID_BUTTON_A);
MicroBitButton buttonB(MICROBIT_PIN_BUTTON_B, MICROBIT_ID_BUTTON_B);
MicroBitDisplay display;

// Function prototypes --------------------------------------------------------
void onPressed(MicroBitEvent e);

// Main  ----------------------------------------------------------------------
int main()
{
scheduler_init(bus);

bus.listen(MICROBIT_ID_BUTTON_A, MICROBIT_BUTTON_EVT_CLICK, onPressed);
bus.listen(MICROBIT_ID_BUTTON_B, MICROBIT_BUTTON_EVT_CLICK, onPressed);

while(1)
fiber_sleep(1000);
}

// Functions ------------------------------------------------------------------
void onPressed(MicroBitEvent e)
{
if (e.source == MICROBIT_ID_BUTTON_A)
display.scroll("A");

if (e.source == MICROBIT_ID_BUTTON_B)
display.scroll("B");
}

あと余談になりますが、chibi:bit を USB 接続した際にフォルダに含まれている MBED.HTM を開くと、mbed コンパイラに mbed HRM1017 として登録されてしまいました。
micro:bit のライブラリを利用する場合、このままビルドすると以下のようなエラーとなってしまいます。

Error: Cannot open source input file "device.h": No such file or directory in "microbit/microbit-dal/mbed-dev-bin/platform.h", Line: 21, Col: 21

これを回避するには https://developer.mbed.org/platforms/Microbit/ から画面右側にある「Add to your mbed Compiler」というオレンジ色のボタンをクリックして、micro:bit をデバイス一覧に追加した上で、ターゲットを micro:bit に変更して下さい。