TinyCLR OS デジタル出力

TinyCLR OSでデジタル出力を試しました。

環境は下記で作ったものを使用します。

matsujirushi.hatenablog.jp

デジタル出力のやり方は、General Purpose Input Output (GPIO)に丁寧に書かれています。素晴らしい。

パッケージソースに追加

デジタル出力するには、プロジェクトにGHIElectronics.TinyCLR.Devices.Gpioのnugetパッケージをインストールする必要があります。

しかし、TinyCLR OSがアルファ版のためか、まだnuget.orgにはアップされていません。

そのため、適当なフォルダに.nupkgを置いて、パッケージソースにそのフォルダを追加することで、インストール可能にします。

ここからダウンロードできる、TinyCLR_Libraries.0.5.0.zipを適当なフォルダに解凍して、Visual Studioのパッケージソースに追加します。

ライブラリをインストール

そして、プロジェクトにGHIElectronics.TinyCLR.Devicesをインストールします。

Windows IoT Coreでお馴染みの、GpioControllerやGpioPinが含まれていますね。

コーディング

プログラムはこんな感じ。

using GHIElectronics.TinyCLR.Devices.Gpio;
using System;
using System.Threading;

namespace TinyCLRApplication1
{
    class Program
    {
        static int PinNumber(char port, byte pin)
        {
            if (port < 'A' || port > 'E') throw new ArgumentException();
            return ((port - 'A') * 16) + pin;
        }

        static void Main()
        {
            for (;;)
            {
                GpioPin led = GpioController.GetDefault().OpenPin(PinNumber('D', 15));
                led.SetDriveMode(GpioPinDriveMode.Output);

                while (true)
                {
                    led.Write(GpioPinValue.High);
                    Thread.Sleep(100);
                    led.Write(GpioPinValue.Low);
                    Thread.Sleep(100);
                }
            }
        }
    }
}

実行

青色LEDが点滅すれば成功です。

TinyCLR OS 環境構築方法

.NET MicroFrameworkが実質開発ストップしていますが、GHI Electronicsが分岐してシンプルにして（？）TinyCLR OSとして整備しているようです。

まだアルファ版ではありますが、現在公開されているTinyCLR OSの環境構築が上手くできたので、手順を書き留めておきます。

TinyCLRは未だアルファ版なので、リンクが切れたり手順が変更になったりする可能性があります。ご了承ください。

わたしの環境

作業前の、わたしのパソコン環境は次のとおりです。

• Surface Pro 4
• Windows 10 1703(15063.483)
• Visual Studio 2017 15.2(26430.15)

使用するデバイスはSTM32F4 Discoveryです。

• STM32F4 Discovery（STM32F407）

また、STM32F4 Discoveryに書き込むときに使用するdfu-utilは既にセットアップされていました。

必要なファイルをダウンロード

必要なファイルは次の3つです。

VisualStudio拡張

GHIElectronics.TinyCLR.VisualStudio.0.5.0.vsixです。

Tiny CLR Release Notesの0.5.0 on 2017-07-07をクリックした先のページでここからダウンロードできます。

ファームウェア

TinyCLR_Firmware.0.5.0.zipです。

Tiny CLR Release Notesの0.5.0 on 2017-07-07をクリックした先のページでここからダウンロードできます。

Windows用デバイスドライバ

GHI_TinyCLR_Interface.zipです。

フォーラムの回答からダウンロードできます。

VisualStudio拡張をインストール

GHIElectronics.TinyCLR.VisualStudio.0.5.0.vsixをダブルクリックで起動します。あとは画面の指示に従えばOKです。

Visual Studio 2015も入っていたのに、Visual Studio 2017しか表示されていないので、どうやらVisual Studio 2017にしか対応していないようです。

インストール完了後、Visual Studioの拡張機能と更新プログラムで確認すると、TinyCLR OS Project Systemが追加されたことがわかります。

プロジェクトの新規作成画面には、TinyCLRが追加されています。

デバイスとの接続方法はUSB/Serial/TCPIP。このあたりはNETMFのままですね。

ファームウェアをデバイスにインストール

ここのやり方が分からず苦労しました。

STM32F4 Discoveryは、TinyCLR_Firmware.0.5.0.zipに含まれている、GHI Bootloader(FEZ Bootloader.2.0.3.dfu)をdfu-utilなどでフラッシュメモリに書き込み、そしてTeraTermなどでGHI Bootloaderに接続してファームウェア（FEZ Firmware.0.5.0.glb）を転送します。

GHI Bootloaderの書き込み

STM32F4 DiscoveryをDFUモードで立ち上げます。下図のように、ボードの裏にあるJP2のジャンパーピンを外して、BOOT0とVDDを短絡します。

そして、パソコンとUSB接続します。

ここはちょっとコツが必要で、STM32 DiscoveryのminiUSB(CN1)とmicroUSB(CN5)をUSB-HUBに接続しておき、USB-HUBをパソコンに接続して、両方のUSBを同時に接続しないといけないようです。（都市伝説なのかも？）

デバイスマネージャにSTM32 BOOTLOADERが表示されれば成功です。

そして、dfu-utilなどを使って、FEZ Bootloader.2.0.3.dfuをフラッシュメモリに書き込んでください。

C:\>dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="1-1.4", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3259375D3036"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="1-1.4", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3259375D3036"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="1-1.4", alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e", serial="3259375D3036"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="1-1.4", alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3259375D3036"

C:\>dfu-util -a 0 -D "FEZ Bootloader.2.0.3.dfu"
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 0483
Match product ID from file: 0000
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (1 elements, total size = 14744)
parsing element 1, address = 0x08000000, size = 14736
Download        [=========================] 100%        14736 bytes
Download done.
done parsing DfuSe file

C:\>

書き込みが完了したら、パソコンからUSB-HUBを外してJP2のジャンパーピンを元に戻します。

ファームウェアの書き込み

再び、USB-HUBをパソコンに接続すると、COMが2つ表示されるので、下の方にTeraTermで接続します。

COMが1つしか表示されないときは、GHI Bootloaderがすでにフラッシュメモリに存在するプログラムを起動しています。 このような場合は、PA15をGNDに繋ぎながらパソコンに接続すると、プログラム起動を抑止してCOMが2つ表示されます。

TeraTermで接続したGHI Bootloaderで、Uを入力してからFEZ Firmware.0.5.0.glbをXMODEMで送信します。送信のときに、オプションの1Kにチェックを付けてください。

HI Electronics, LLC Bootloader
-------------------------------
OK.
Are you sure (Y/N)?
Waiting...
CCCCCCCCCCCCCCCCCCCCCCCCCCCCC
OK.

再び、USB-HUBを外して、USB-HUBをパソコンに接続すると、FEZという不明なデバイスが表示されればOKです。

Windows用デバイスドライバをインストール

GHI_TinyCLR_Interface.zipを適当なフォルダに解凍しておき、さきほどのFEZという不明なデバイスどのドライバ更新でzip解凍先を指定します。

FEZのビックリマークが消えればOKです。

Visual Studioから認識できるか確認

適当にTinyCLRプロジェクトを新規作成して、プロジェクトのプロパティにあるDeviceにFEZ_FEZと表示されれば、デバイスがきちんと認識できています。

最後に

とりあえずデバイスをセットアップすることができました。

次は、GPIOのやり方を確認したいと思います。

TinyCLR OS触り始めました（途中で挫折編）

TinyCLR OSが良い感じになってきているようなので、動かしてみました。

TinyCLR OSをダウンロード

TinyCLR OSのReleasesにある、0.4.0 on 2017-05-10をクリックして、TinyCLR.0.4.0.zipをダウンロードします。

中身は、デバイスに入れるブートローダー.binとVisualStudio拡張.vsix、nugetパッケージ.nupkg。.ghiというのがありますが詳細不明。

• G120 Bootloader.2.0.2.ghi
• G120 Firmware.0.4.0.ghi
• G30 Firmware.0.4.0.ghi
• G400 Bootloader.2.0.2.bin
• G400 Firmware.0.4.0.ghi
• G80 Firmware.0.4.0.ghi
• GHIElectronics.TinyCLR.BrainPad.0.4.0.nupkg
• GHIElectronics.TinyCLR.Core.0.4.0.nupkg
• GHIElectronics.TinyCLR.Devices.0.4.0.nupkg
• GHIElectronics.TinyCLR.Drawing.0.4.0.nupkg
• GHIElectronics.TinyCLR.Pins.0.4.0.nupkg
• GHIElectronics.TinyCLR.Storage.0.4.0.nupkg
• GHIElectronics.TinyCLR.VisualStudio.0.4.0.vsix
• License.txt

VisualStudio拡張をインストール

GHIElectronics.TinyCLR.VisualStudio.0.4.0.vsixをダブルクリックしてインストールします。

本PCはVisual Studio 2015もインストールしてありますが、一覧に表示されていないところをみると、Visual Studio 2017専用のようです。

インストールボタンをクリックすればOK。

VisualStudioはどう拡張されたのか

プロジェクト新規作成のテンプレートに、TinyCLRが追加されました。

試しに、TinyCLR Applicationプロジェクトを新規作成してみると、こんな感じ。

GHIElectronics.TinyCLR.Coreを参照しているだけ（笑）。とってもシンプル。

ビルドしてみると一瞬で完了します。そりゃそうですね。

デバイスとの接続を設定できるよう、プロジェクトのプロパティにTinyCLR OSが追加されています。中身はNETMFのソレと同じで、接続方法にUSB,Serial,TCP/IPの選択が表示されました。

で、デバイスは？

VisualStudio側がシンプルなのは十分わかりました。

では、デバイスはどうすれば良いのでしょうか。

既出のTinyCLR.0.4.0.zipに、G30,G80,G120,G400のファームウェアっぽいものが入っています。

• G30 Firmware.0.4.0.ghi
• G80 Firmware.0.4.0.ghi
• G400 Bootloader.2.0.2.bin
• G400 Firmware.0.4.0.ghi
• G120 Bootloader.2.0.2.ghi
• G120 Firmware.0.4.0.ghi

GHI Catalogによると、これらはSTM32,LPC,SAMのようです。

うーむ、どれも持っていない…。

STM32F4 Discoveryが対応しているっぽいので、マルツで買ってきました。（また基板が増えてしまった。）

STM32F407なので、きっとG80 Firmware.ghiを入れるんだろうと思いながらも、拡張子.ghiなのが気がかり。 STM32 Bootloaderの手順に従って、DfuSe USB device firmware upgrade STMicroelectronics extensionをダウンロード、インストールすることに。

と、ここまでやったところで、Tiny CLR OS 0.5.0のダウンロードを発見した。

振出しに戻る。

つづく。

Unity 3Dの.NETバージョンが謎すぎるので調査中

HoloLensの開発にUnityを使っていますが、UWPであるにもかかわらず、nugetが使えなかったり、UWP固有の呼び出しができなかったりして謎すぎるので調べています。

現時点では全てが明確に判明したわけではないです。気づいた点があればコメントいただけると嬉しいです。

使用している環境

• Unity 5.6.1f1
• Visual Studio 2017(15.2)

ビルドと実行環境のタイミング

UnityのScriptのビルドと実行環境は、次のものがあります。

• UnityからScriptの編集
• Unityで実行
• Visual StudioからUnityにプロセスアタッチしてデバッグ
• UnityからBuild
• Build出力のビルドと実行

さらに、Unityからリモート実行とか、HoloLensエミュレータで実行とかあるようですが未確認。

それぞれについて、フレームワークに何が使われているか調べてみました。

UnityからScriptの編集

UnityからScriptをOpenした状態。 プロジェクトフォルダ直下にある.sln, .csprojを開いたVisual Studio。

Unityで実行

Unityで再生マークを押して実行している状態。

Visual StudioからUnityにプロセスアタッチしてデバッグ

UnityからScriptの編集で立ち上がったVisual Studioを実行すると、Unityにプロセスアタッチします。 なので、Visual Studioで実行してから、Unityで実行すると、Unityで実行している状態をVisual Studioでデバッグすることができます。

UnityからBuild

UnityのBuild SettingsでBuildボタンをクリックしてビルドすること。

Build出力のビルドと実行

UnityからBuild時に指定したフォルダに作成された、.slnを開いたVisual Studio。 （Unity C# Projectsをチェックしている場合は編集できたり、）ビルドしてHoloLensにデブロイ、リモート実行すること。

調べ方

（そのうち書く！m(__)m）

結果

状況	フレームワーク
UnityからScriptの編集	.NET3.5 / .NET4.6
Unityで実行	mono(.NET2系)っぽい
Visual StudioからUnityにプロセスアタッチしてデバッグ	mono(.NET2系)
UnityからBuild	UWP(UAP)っぽい
Build出力のビルドと実行	UWP(UAP)

【メモ】Visual Studio Code + Nucleo-L476RG

Wataraiさんが分かりやすい記事をアップしました。そちらが分かりやすいです。

VSCodeでSTM32マイコンのデバッグ環境を構築する

手順の精査は必要ですが、とりあえず動いたのでメモ。

• OpenOCDを使う。（NucleoはST-LinkなのでpyOCDはダメ）
• OpenOCDはコマンドラインで事前に起動しておく。（VSCodeからのlaunchだと、なぜかVSCodeからGDBサーバーへ接続しようとしない。）
• VSCodeからのGDBサーバー起動は無し。（launch.jsonのdebugServerPathを削除）

OpenOCD起動コマンド

C:\OpenOCD\openocd.exe -s C:\OpenOCD\tcl -f board\st_nucleo_l476rg.cfg -c init -c "reset init"

Windows-Remote-Arduinoをデバッグする

nugetにある、Windows-Remote-Arduinoのソースは、githubで公開されている。

github.com

github.com

githubから取得したソースがなかなかビルドできなかったので、手順をメモします。

1. git clone remote-wiring … recursiveは不要
2. git clone serial-wiring
3. Visual Studio 2017でUWPアプリを新規作成
4. ソリューションに、remote-wiringのMicrosoft.Maker.FirmataとMicrosoft.Maker.RemoteWiringを追加
5. ソリューションに、serial-wiringのMicrosoft.Maker.Serialを追加
6. UWPアプリから、Serial, Firmata, RemoteWiringを参照設定

remote-wiringからserial-wiringを参照しているパスがsubmoduleのパスではない。 Visual Studio 2017を使わないといけない。ところがポイント。

Visual Studio Codeでmbed OSプログラムをデバッグする方法

Debugging mbed OS applications with Visual Studio Codeをやってみた備忘録です。 github.com

基本的には、この手順通りですが、（現在は）いくつかハマりポイントがあったので、書いておきます。

環境は、

• Surface Pro 4
• Windows 10 Professional 1703
• FRDM-K64F

です。

Nucleo-L476RGをデバッグしたかったのですがpyOCDが対応していない、mbed LPC1768はGCC (ARM Embedded)向けのエクスポートが無い、ことから、FRDM-K64Fを使いました。Nucleoやmbed LPC1768については、機会があれば書きたいと思います。

Wataraiさんの、STM32+OpenOCD記事。

VSCodeでSTM32マイコンのデバッグ環境を構築する

ソフトウェアのインストール

Toolchain

C/C++コンパイラ

GNU ARM Embedded Toolchainをインストールします。

わたしの環境は、既に4.9 2015q3をインストールしていたので、特に何もしませんでした。

4.9-2015-q3-update : Series 4.9 : GNU ARM Embedded Toolchain

インストール先はC:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3で、環境変数PATHにC:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\binを追加しています。

makeコマンド

mbedからMakefileが提供されていますが、GNU ARM Embedded Toolchainにmakeコマンドが含まれていないので、追加でインストールします。

GnuWin32に含まれている下記ファイルを、C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\binにコピーします。

sourceforge.net

コピーするファイル名	含まれているzipファイル名
make.exe	make-3.81-bin.zip
libiconv2.dll	make-3.81-dep.zip
libintl3.dll	make-3.81-dep.zip

Debug toolchain

OCD(On-Chip Debugger)

ボードに合わせて、pyOCDもしくはOpenOCDをインストールします。（OpenOCDは、ビルド作業が必要だったり、設定ファイルを書かなければいけないようです。）

今回のFRDM-K64FはpyOCDが対応していますので、pyOCDをインストールします。

pyOCD

pyOCDは、Python 2.7系をインストールしてから、pipコマンドでインストールします。

www.python.org

> C:\Python27\Scripts\pip install pyocd

Visual Studio Code

Visual Studio Codeをインストールします。

code.visualstudio.com

なお、PATHへの追加は不要なので、チェックを外しました。

次に、拡張機能のC/C++をインストールします。

ソフトウェアの確認

mbed OSプログラム

動かしてみるプログラムを用意します。

mbedオンラインコンパイラでmbed OS Blinky LED HelloWorldを作成して、GCC (ARM Embedded)向けにエクスポート、適当なフォルダに解凍します。

Toolchain

mbed OSプログラムのフォルダでmakeコマンドを実行して、コンパイルできるか確認します。

> make
C:/Users/takashi/Desktop/mbed-os-example-blinky/makefile:615: warning: overriding commands for target `.s.o'
C:/Users/takashi/Desktop/mbed-os-example-blinky/makefile:610: warning: ignoring old commands for target `.s.o'
"Compile: main.cpp"
"Compile: AnalogIn.cpp"
...
"Compile: rtc_api.c"
"Compile: sleep.c"
../mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/api/sleep.c: In function 'hal_deepsleep':
../mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/api/sleep.c:31:16: warning: unused variable 'mode' [-Wunused-variable]
     mcg_mode_t mode = CLOCK_GetMode();
                ^
"link: mbed-os-example-blinky.elf"
'arm-none-eabi-objcopy' -O binary mbed-os-example-blinky.elf mbed-os-example-blinky.bin
"===== bin file ready to flash: BUILD/mbed-os-example-blinky.bin ====="
'arm-none-eabi-objcopy' -O ihex mbed-os-example-blinky.elf mbed-os-example-blinky.hex

>

mbed-os-example-blinky.elfが出来上がっていればOKです。

pyOCD

FRDM-K64FをUSB接続しておき、pyocd-gdbserverを起動してGDB serverがスタートするか確認します。

> c:\Python27\Scripts\pyocd-gdbserver.exe
INFO:root:DAP SWD MODE initialised
INFO:root:K64F not in secure state
INFO:root:ROM table #0 @ 0xe00ff000 cidr=b105100d pidr=4000bb4c4
INFO:root:[0]<e000e000:SCS-M4 cidr=b105e00d, pidr=4000bb00c, class=14>
WARNING:root:Invalid coresight component, cidr=0x0
INFO:root:[1]<e0001000: cidr=0, pidr=0, component invalid>
INFO:root:[2]<e0002000:FPB cidr=b105e00d, pidr=4002bb003, class=14>
WARNING:root:Invalid coresight component, cidr=0xb1b1b1b1
INFO:root:[3]<e0000000: cidr=b1b1b1b1, pidr=b1b1b1b1b1b1b1b1, component invalid>
WARNING:root:Invalid coresight component, cidr=0x0
INFO:root:[4]<e0040000: cidr=0, pidr=0, component invalid>
INFO:root:[5]<e0041000:ETM-M4 cidr=b105900d, pidr=4000bb925, class=9, devtype=13, devid=0>
INFO:root:[6]<e0042000:ETB cidr=b105900d, pidr=4003bb907, class=9, devtype=21, devid=0>
INFO:root:[7]<e0043000:CSTF cidr=b105900d, pidr=4001bb908, class=9, devtype=12, devid=28>
INFO:root:CPU core is Cortex-M4
INFO:root:FPU present
INFO:root:6 hardware breakpoints, 4 literal comparators
INFO:root:4 hardware watchpoints
INFO:root:Telnet: server started on port 4444
INFO:root:GDB server started at port:3333

"GDB server started"と表示されていればOKです。

pyOCDはVisual Studio Codeから都度起動されるので、Ctrl+Cで止めておいてください。

Visual Studio Codeでmbed OSプログラムをデバッグ

Makefileの修正

mbedで作成されたMakefileは、オプションが最適化ありになっているので、デバッグできるよう最適化を無効にします。

■変更前

CPP = 'arm-none-eabi-g++' '-std=gnu++98' '-fno-rtti' '-Wvla' '-c' '-Wall' '-Wextra' '-Wno-unused-parameter' '-Wno-missing-field-initializers' '-fmessage-length=0' '-fno-exceptions' '-fno-builtin' '-ffunction-sections' '-fdata-sections' '-funsigned-char' '-MMD' '-fno-delete-null-pointer-checks' '-fomit-frame-pointer' '-Os' '-mcpu=cortex-m4' '-mthumb' '-mfpu=fpv4-sp-d16' '-mfloat-abi=softfp'

■変更後

CPP = 'arm-none-eabi-g++' '-std=gnu++98' '-fno-rtti' '-Wvla' '-c' '-Wall' '-Wextra' '-Wno-unused-parameter' '-Wno-missing-field-initializers' '-fmessage-length=0' '-fno-exceptions' '-fno-builtin' '-ffunction-sections' '-fdata-sections' '-funsigned-char' '-MMD' '-fno-delete-null-pointer-checks' '-fomit-frame-pointer' '-O0' '-ggdb' '-mcpu=cortex-m4' '-mthumb' '-mfpu=fpv4-sp-d16' '-mfloat-abi=softfp'

オプション変更は十分吟味されていません。お気づきの点があればコメントください。

Makefileを修正したので、再度、全てをビルドし直す必要があります。BUILDフォルダを削除しておきましょう。

Visual Studio Codeの構成を設定

mbed OSプログラムのフォルダに、vscode.zipを展開します。

Visual Studio Codeの構成は、.vscode/settings.json, .vscode/tasks.json, .vscode/launch.json ファイル。

1drv.ms

mbed handbookには、Visual Studio Code向けにエクスポートすると、構成が正しく設定されているっぽいのですが、現在はVisual Studio Code向けの選択肢が表示されませんでした。

ググったところ、github（参考）に構成ファイルがありましたので、これを修正してvscode.zipを作りました。

デバッグの開始

Visual Studio Codeで、デバッグの開始を実行します。

プログラムに問題なくても、わりと高い確率でmakeがエラーになります。焦らず、何度もデバッグの開始を実行しましょう。（汗

気分良くビルドしたい場合は、コマンドプロンプトからmakeを実行してください。

最後に

Visual Studio Codeにインクルードパスを指定していないため、せっかくVisual Studio Codeを使っているのにIntelliSenseがきちんと動作していない。Visual Studio Codeに何か設定が必要なのだろう。

mbed handbookに手順書があったのでVisual Studio Codeを使ったが、Mac/Linux使っておらず、普段はVisual Studio Proを使っているので、Visual Studioでコレをできるようにしたい。

参考

qiita.com

github.com