Raspberry Pi SSD(KingSpec 64GB)を試してみる

Raspbian Strechのリリースから約1年になりますが安定度や起動の速度など以前と比べるとずいぶん改善されているように思います。

現行Pi3の足かせはマイクロSD、USB2.0そしてメモリ容量でしょうか。(マイクロSDは同時にメリットでもあるのですが)

今回は次期PiのUSB3.0を期待してマイクロSDの代わりにSSDを使ってみることにしました。

中華SSDはかなり怪しいものも流通しているようですが今回購入したKingSpecというメーカーは以前よりPCショップなどでも取り扱っており一定の評価があるようです。

マイクロSD(64GB)の価格帯としては現在1800〜2500円位が多く見られます。
SSD KingSpec(64GB)の価格は$18.61 + $3.51(SATA – USB3.0)とマイクロSDと同価格帯で導入できます。128GBは$10位アップしますが今回はその信頼性(性能)を検証する意味で最低の容量で試してみます。(信頼性、寿命は時間が証明するしか無いのですが)


こんなパッケージで送られてきます。(SATA to USB3.0変換は別メーカー、別ストア、別送付です)
AliExpressのKingSpec Global Storeというところで購入したのですが日本到着時及び地元郵便局到着時にも追跡メールを送信してくれて中華ストアには珍しく対応の良いところでした。到着までには約2週間要しています。


SSDは初めて使うのですが本体は非常に軽くてPiのベースにも良さそうです。


テスト中はディスプレイに貼り付けています。
SATA接続部分は少し熱を持ちます。

BOOT FROM A USB MASS STORAGE DEVICE
USBデバイスから起動させるためにUSBブートモードを有効にします。
HOW TO BOOT FROM A USB MASS STORAGE DEVICE ON A RASPBERRY PI 3

$ sudo apt update && sudo apt upgrade
$ echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
$ sudo reboot

確認してみます。こんな数値が帰ってくればOK

$ vcgencmd otp_dump | grep 17:
17:3020000a

これは元に戻すことはできません。戻す必要もありません。
カードスロットにSDカードがあればカードスロットから起動、なければ起動可能なUSBデバイスから起動します。大容量デバイスに限らず通常のSDカードもUSBアダプタ経由で起動します。

起動してみる
OSには通常通りRaspbian Strechをインストールしました。(具体的なインストールについてはまた次回にしたいと思います)
カードスロットから元ディスクを抜いて電源を投入します。
約10秒過ぎくらいにブートが始まります。
ブートは成功ですね。

テストしてみる
環境を整えてディスクのリード、ライトの簡単なテストをしてみます。
テスト方法は下記のサイトを参考にしました。
Linux Tips – HDDベンチマーク手順+性能測定結果一覧(hdparm,dd,bonnie++)
方法としてはSSDで起動してhdparmからリード、ddでライトをSSDとマイクロSDのタイムを計測します。

SSD read (hdparm -t /dev/sda2を3回実行)

# for i in [1] [2] [3];do sleep 10;echo $'\n\n' $i;hdparm -t /dev/sda2;done


約39MB/sec

マイクロSD read

# for i in [1] [2] [3];do sleep 10;echo $'\n\n' $i;hdparm -t /dev/mmcblk0p2;done


約22MB/sec

SSD write (time dd if=/dev/zero of=./test/write.tmp ibs=1M obs=1M count=1024を3回実行)

# for i in [1] [2] [3];do sleep 10;echo $'\n\n' $i;time dd if=/dev/zero of=./test/write$i.tmp ibs=1M obs=1M count=1024;done
# rm -r test


約28MB/sec

マイクロSD write (SSD起動後マイクロSDをスロットに装着してマウント)

# for i in [1] [2] [3];do sleep 10;echo $'\n\n' $i;time dd if=/dev/zero of=./test/write$i.tmp ibs=1M obs=1M count=1024;done
# rm -r test


約10Mb/sec

マイクロSDから起動、同様に計測してもほとんど同じような結果を得ています。
マイクロSDはT社32GB(少し古い)
SSDは30GB、マイクロSDは15GBでパーテーションを切っています。
最新のマイクロSDがどれくらい早くなっているかはわかりませんがclass10と考えるとこんなもんかなと思っています。
この差は特にインストール作業時に違いを感じることができます。

次回はインストールについて少し書いてみようと思います。

Raspberry Pi STM32F103開発環境(Arduino IDE PlatformIO)

前回はRaspberry Piからのシリアル接続でBluepill,Blackpillへブートローダーの導入ができました。
Arduino IDE(PlatformIO)の環境を構築してブートローダー書き込み後スケッチのアップロードも可能のようです。
さらに環境を整備していろいろ試すと予期せぬアップロードエラーが頻発してしまいます。
これらについてはSTM32に対しての知識が乏しいのが最大の要因ですがOSやToolなどの問題もあるようです。
この点については後述しますが取り敢えずアップロードも正常にできるようになりました。(一手間必要ですが!)

環境構築
STM32ボードを使うためにはコンパイラやツールを導入する必要があるのですがArduino_STM32のツールはRaspberry Pi(ARM)に対応していません。そのため先にPlatformIOから環境構築をします。

PlatformIO
boardを選択

$ pio boards | grep -i stm32f103


型番STM32F103C8では(20k RAM. 64k Flash)になっているためSTM32F103CB (20k RAM. 128k Flash)を選択します。
おそらく現在流通しているSTM32F103C8搭載ボードは128k Flashになっていると思います。

boardはSTM32F103CBに決定しました。
ディレクトリ、設定ファイルを作成します。

$ mkdir -p ~/platformio/project/stm32/bluepill/Blink
$ cd ~/platformio/project/stm32/bluepill/Blink
$ pio init -b genericSTM32F103CB

platformio.iniが作成されているはずなので編集

[env:genericSTM32F103CB]
platform = ststm32
board = genericSTM32F103CB
framework = arduino
upload_port = /dev/ttyACM0
upload_protocol = dfu

ディレクトリsrc/にBlink.inoを作成(~/platformio/project/stm32/bluepill/Blink/src)
boardはBluepill

void setup() {
  pinMode(PC13, OUTPUT);
}

void loop() {
  digitalWrite(PC13, LOW);
  delay(1000);
  digitalWrite(PC13, HIGH);
  delay(1000);
}

準備ができたので実行(ディレクトリは~/platformio/project/stm32/bluepill/Blink)

$ pio run

コンパイラやツールのダウンロードとコンパイルのみ実行します。
終了すると~/.platformio/packages以下にSTM32関連のファイルがインストールされています。

Arduino IDE
ここからArduino IDE側の環境を構築していきます。
ボードマネージャからArduino SAM Boards (32-bits ARM Cortex-M3)インストール

Arduino_STM32をダウンロード

https://github.com/rogerclarkmelbourne/Arduino_STM32
Download ZIPでダウンロードしたファイルを展開コピー
tools/linuxをPlatformIOにリンク

$ unzip Arduino_STM32-master.zip
$ cp -r Arduino_STM32-master ~/Applications/arduino-1.8.5/hardware
$ cd ~/Applications/arduino-1.8.5/hardware/Arduino_STM32/tools
$ rm -r linux
$ ln -s ~/.platformio/packages/tool-stm32duino linux

udev設定
PlatformIOからダウンロードした~/.platformio/packages/tool-stm32duinoディレクトリの45-maple.rulesを編集(コピーを取って編集)
Raspberry piではModemManagerと競合するようです。

$ cd ~/.platformio/packages/tool-stm32duino

45-maple.rules 3行目、4行目ENV{ID_MM_DEVICE_IGNORE}="1"追記
ATTRS{idProduct}=="1001", ATTRS{idVendor}=="0110", MODE="664", GROUP="plugdev"
ATTRS{idProduct}=="1002", ATTRS{idVendor}=="0110", MODE="664", GROUP="plugdev"
ATTRS{idProduct}=="0003", ATTRS{idVendor}=="1eaf", MODE="664", GROUP="plugdev" SYMLINK+="maple", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idProduct}=="0004", ATTRS{idVendor}=="1eaf", MODE="664", GROUP="plugdev" SYMLINK+="maple", ENV{ID_MM_DEVICE_IGNORE}="1"

install.shを実行
$ sudo ./install.sh

/etc/udev/rules.dにrulesファイルが作成されます。

-rw-r--r-- 1 root root  411  7月 29 10:12 45-maple.rules
-rw-r--r-- 1 root root  471  7月 28 22:08 49-stlinkv1.rules
-rw-r--r-- 1 root root  532  7月 28 22:08 49-stlinkv2-1.rules
-rw-r--r-- 1 root root  530  7月 28 22:08 49-stlinkv2.rules
-rw-r--r-- 1 root root 1028  7月 28 22:10 99-com.rules

ここで設定を有効にするためRaspberry Piを再起動します。

書き込みを実行してみる
ここで前回のブートローダーを再度書き込みます。
BOOT0 1 reset
$ stm32flash -w generic_boot20_pc13.bin /dev/serial0
BOOT0 0 reset
/dev/ttyACM0 確認

先に作成したBlink.inoを書き込み ~/platformio/project/stm32/bluepill/Blink

$ pio run -t upload


upload OKですね

45-maple.rulesの追加修正が無いと下記のリセット操作が必要になります。

再度書き込み実行 $ pio run -t upload
dfu-util: No DFU capable USB device available

検索するとこのエラー報告は多く見つかりますが解決策はなかなか見つかりません。
いろいろ試すと適当なタイミングでリセットすると成功することがわかりました。根本的な解決策では無いのですがこんな解説が見つかります。
Uploading a sketch
多分ここに書いてあることと同じと思いますがdfu modeにできなかったので手動でリセットしなさいということです。

ブートローダー書き込み直後はflashに何も無いためdfu modeで起動、待ち受けるため初回のみ成功すると思います。
さてリセットのタイミングですがPlatformIOから実行した場合は(コンパイル済)
Compiling .pioenvs/genericSTM32F103CB/src/Blink.ino.cpp.o
または
Uploading .pioenvs/genericSTM32F103CB/firmware.bin
ここで少し待っているのでいいタイミングでリセットを1回押します。
慣れてくるとかなりの確率で成功すると思います。


Arduino IDEからも同様で書き込み動作(赤文字)に入る前のタイミングでリセットします。

dfu-utilは汎用書き込みツールでRasbpianにもパッケージ(同バージョン)があります。
おそらくwindowsではこのような問題は無いと思うので簡単に解決することは難しいと感じています。

取り敢えずリセット書き込みになりましたがなんとか正常に書き込めるようなのでこの状態で少し遊んでみようと思います。

アダプタの作成 bluepill.pdf

PiのGPIOを利用するためアダプタを作成しました。ESPの下駄を利用しています。(電源3V3はベース基板から)
空いてるランドにピンソケットを立て引き出しています。
またUSBコネクタも繋ぎ変えたくないのでベース基板のコネクタを利用します。
使用の際はcp2102モジュールを外してアダプタをセット。D-D+はピンヘッダを介してモジュールのPA11,12と接続しておりD+のプルアップはモジュール側を利用することになります。ブートローダーは適切にセットしてあれば確実に書き込んでくれます。スケッチ書き込みもOKです。

end

Raspberry Pi STM32F103開発環境(Bluepill Blackpill)

Raspberry Piによるマイコン開発環境はAVR,ESP-WROOM-02(32)と来たので今回はSTM32F103を試してみたいと思います。
STM32に関してはいろいろ開発環境がありますがRaspberry Piからの使用となるとかなり限られて来るのでここはアマチュアライクなArduino IDE(Platformio)に絞って調べてみます。
web上を検索するとなんとかRaspberry Piでも動きそうな感触が得られたのでBluepillとBlackpillを手配してみました。
このSTM32F103C8T6搭載基板は性能、価格面ではコスパの高いボードと思います。
ESPの開発基板を流用するのは貧乏性のせいか抵抗がありますがBluepillやBlackpillはmcuの形状、ピン数から見てもピッチ変換基板と思えば気兼ねなく使えそうです。

Bluepill Blackpill
市場で一番流通しているのはBluepillと思います。
Bluepillは200円以下で購入(送料無料)できます。Blackpillはそれより20円位高い。

ボードの作り(質)としてはBlackpillのほうが良さそうです。
BlackpillはBluepillより少し大きい(ピッチ幅も1ピッチ広め)のですが6ピン少ない。少ないピンは
VBAT バッテリーバックアップ端子(RTC)
5V端子(あれば便利、基板上から引き出すことは可能)
PC14,PC15 実質利用できない端子
3.3V GND 余分に出ている
この中でバッテリーバックアップが必要な場合はBlackpill以外のボードを選んだほうがいいですね。


BluepillにはUSB問題(誤抵抗)があります。
Blackpillと同条件にしたいため問答無用で対策をします。
10K -> 1.5Kにするのですが小さい1.5Kを探すのが大変、かといって敢えて購入するまでもないことから1.8Kをパラにしました。
手持ちの1/6W抵抗を裏側に取り付けています。

シリアル接続(ブートローダーの書き込み)

MicroUSBからスケッチを書き込むためにはブートローダーを導入する必要があります。
USBシリアル変換モジュールを用いるのですが当サイトのcp2102は認識しませんでした。linux系ではCH340もだめなようです。
Raspberry PiのGPIOを利用してブートローダーを書き込む手法を紹介しているサイトがあります。
Flashing the STM32F103 using a Raspberry Pi 3
BluetoothはUARTの一部を利用しているですね。それをブートローダー書き込みのシリアル接続に用いるというものです。したがってこの設定をするとBluetoothは利用不可になります。
(常時使用する訳ではないので簡単に切り替え方法は後日検討してみたいと思います)

/boot/config.txtの編集 (末尾に追記)

dtoverlay=pi3-miniuart-bt

/boot/cmdline.txtの編集 (一部削除)

console=serial0,115200

stm32flash utilityはパッケージにあります。

# apt install stm32flash

接続
Raspberry Pi TX (pin 8) to STM32 RX (pin A10)
Raspberry Pi RX (pin 10) to STM32 TX (pin A9)
Blackpill(Bluepill)ジャンパー設定
BOOT0 jumper to 1
セットが完了したら再起動します。
再起動するとBluetoothマネージャーはグレーになって動作を停止しているはずです。

STM32duino-bootloaderのダウンロード
https://github.com/rogerclarkmelbourne/STM32duino-bootloader
ダウンロードしたSTM32duino-bootloader-master.zipは適当なディレクトリ(~/Applications)に展開します。

ブートローダーの書き込み
書き込む前に確認してみます。Flashメモリ128KiBが確認できます。

$ stm32flash /dev/serial0
stm32flash 0.5
http://stm32flash.sourceforge.net/
Interface serial_posix: 57600 8E1
Version      : 0x22
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0410 (STM32F10xxx Medium-density)
- RAM        : Up to 20KiB  (512b reserved by bootloader)
- Flash      : Up to 128KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB

書き込んでみましょう。(Blackpill)

$ cd ~/Applications/STM32duino-bootloader-master/binaries
$ stm32flash -w generic_boot20_pb12.bin /dev/serial0
stm32flash 0.5
http://stm32flash.sourceforge.net/
Using Parser : Raw BINARY
Interface serial_posix: 57600 8E1
Version      : 0x22
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0410 (STM32F10xxx Medium-density)
- RAM        : Up to 20KiB  (512b reserved by bootloader)
- Flash      : Up to 128KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote and verified address 0x08005294 (100.00%) Done.

Bluepillはgeneric_boot20_pc13.bin

BOOT0のジャンパー設定を0にしてリセットするとLEDが点滅してブートローダーが起動する様子がわかります。
新たに/dev/ttyACM0が生えてきます。

$ ls -la /dev/ttyA*
crw-rw-r-- 1 root dialout 166,  0  7月 29 22:35 /dev/ttyACM0
crw-rw---- 1 root dialout 204, 64  7月 29 21:54 /dev/ttyAMA0


あとはArduino IDE(Platformio)の環境を構築してスケッチを書き込んであげればいいだけなのですが・・・(実際書き込みはできる) なかなか微妙なところがあります。

この辺はまた次回にしたいと思います。

では!

Raspberry Pi ファームウェアのアップデートを保留する

現在のraspbianは# apt update && apt upgradeすると適当なタイミングでファームウェアがアップデートされます。カーネルのバージョンが上がることによりパフォーマンスが向上したり新しい機能が入ったりします。
おそらく標準的な構成では問題は少ないと思われますが設定によっては今まで使えていた機能が使えなくなったりいろいろ問題が出る場合もあります。
特に常時運用しているサーバーでは不用意にアップグレードするべきではないと思っています。
OSSである以上このあたりはやむを得ないのですがwindowsの醜くさから比べれば許容の範疇でしょう。

そんなわけで当サイトのPiはファームウェアの自動アップグレードを通常は抑止しています。

# apt-mark hold raspberrypi-kernel
raspberrypi-kernel は保留に設定されました。

# apt update && apt upgradeしていると保留の項目が出現してきます。
そんなときhttps://www.raspberrypi.org/downloads/raspbian/のページを覗くと新しい版(リリース)が出ています。
アップグレードするときは時間と心の余裕のある時に実施します。

# apt dist-upgrade
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています                
状態情報を読み取っています... 完了
アップグレードパッケージを検出しています... 完了
以下のパッケージは保留されます:
  raspberrypi-kernel
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 1 個。

apt-mark hold xxxxにしているとdist-upgradeでは保留は解除されません。
互換性に問題があるパッケージなども自動で保留になることがありますがこちらはdist-upgradeでアップグレードが可能になります。

# apt-mark unhold raspberrypi-kernel
raspberrypi-kernel の保留を解除しました。
# apt dist-upgrade


今回は1週間ほどで再度カーネルの更新がありました。おそらくなにか問題があったものと思われます。
2018-06-27版を新規インストールしても# apt update && apt upgradeでカーネルの更新が入ります。

upgradeしたら再度apt-mark hold raspberrypi-kernelしておきます。

$ uname -a
Linux pi3 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux
# apt-mark unhold raspberrypi-kernel
# apt dist-upgrade
# reboot
$ uname -a
Linux pi3 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux

apt dist-upgradeを指定していますがほかに保留項目がなければapt upgradeでOKです。

サーバー用途などで特定のパッケージのみ更新したい場合は通常のインストールコマンドで更新できます。

# apt install パッケージ名

再インストール

今回はRASPBIAN STRETCH WITH DESKTOP(2018-06-27)を新規インストールしてみました。
updateを重ねていくと新規インストールしたものとは挙動が違ってくることがあります。
昨年8月のstretchの新規リリース時はカードからの読み書きがとても遅かったのですがリリースを重ねるごとに起動を含めて早くなっている感じがします。
今回の再インストールの問題ではないのですがしばらく前から起動時nfs mountをしない。起動後コマンドラインからは正常にマウント(mount -a)
webkit系ブラウザがpulseaudioに繋がらない。chromiumは正常動作する。

これまでPcmanFMの不具合がなかなか解消しなかったのですが今回は完全に直っていますね。設定、移行に問題があったのかもしれません。
個人設定に関しては従来、単純にホームディレクトリを移行するだけで復元できたのですがLXDEやPcmanFMに更新があると単純には行かないようです。
特にwith PIXEL以降その傾向があるように感じます。
今回は空の~/.configから徐々にLXDEやPcmanFM関連を移行して最小限の手直しで済みました。

どうもPi財団はopenbox右クリックメニューを使わせたくないような印象を受けます。
旧来のダイアログはどこか行っちゃいましたが右クリックメニューは有効にできます。
雛形は/etc/xdg/openboxあるいは/etc/xdg/openbox/LXDE以下のmenu.xml
~/.config/openboxにコピー
~/.config/pcmanfm/LXDE-pi/desktop-items-0.conf

show_wm_menu=1

にしてログアウト、ログインで有効。のんびりしているとまた書き換わってしまいます。
詰め込まないで必要なものだけ登録するようにします。ターミナルとファイルマネージャーだけでも自然に右クリックしてしまいます。
やはりopenboxは右クリックメニューですね!

Raspberry Pi Arduino開発ベースボードの作成

ESP32,8266の開発ボード環境も一段落したので以前作成したpiのArduinoベースボードの再作成に着手してみました。

今回は別体だったKit Scopeをオンボードに、またESP32,8266もArduinoつながりということでアダプタ(シールド)を作成して利用できるようにしてみたいと思います。

回路図(PDF)


ベースのデバイスはAVR328P
ESP-WROOM-02はアダプタ(シールド)として実装します。
ESPの周辺回路はアダプタ側に実装、ベースボードには新たにDTR,RTS信号用としてピンソケットを設けています。
BUILTIN LEDはGPIO5,GPIO16にしています。

Kit Scope

Kit Scopeは以前作成した回路ですがusbシリアル変換モジュールはcp2102に変更しています。
GND共通以外は独立した5V仕様となっています。

Kit Scopeの電源を自由に入り切りしようと思ったのですが以前作成したcp2102の回路に誤りがありました。
0Ωの抵抗が5V出力側に入っていますね。
したがってモジュールを含めて電源を切ることは難しくなります。
やむを得ないのでスイッチ付きUSBケーブルを作成することにしました。


基板用スライドスイッチをユニバーサル基板を切って取り付け中華コネクタに押し込んでいます。
少しはみ出していますがまあOKでしょう。VCC(5V)をON-OFFしています。
ケーブルは細めで接着しておきます。カバーは割れやすいので注意(無理に入れないでカバーの外に接着してもいいかな?)
これで任意にデバイスナンバーを合わせ込むことができます。

ベースボード


以前のベースボード(70x50mm)+Kit Scopeと今回のベースボード
基板は80x60mm Piより一回り小さい
usbシリアル変換モジュールはやはりcp2102を採用しています。
メインのモジュール(電源)もスライドスイッチでON-OFF可
Piは通電したままアダプタ(シールド)類の交換は可能です。
Piのパワースイッチもオンボードに組み入れたのですっきりしました。

ESPアダプタ

ピッチ変換したESP-WROOM-02はこの基板に取り付けます。
AVRのピンから必要な電源、信号を貰います。
自動プログラムなど必要な回路はこの基板に組みます。
切り込み部にKit Scope端子の照明用LEDを入れてみたのですがあまり効果がありませんでした。!

ESP32アダプタ

これでESP-WROOM-02が正常に認識できればESP-WROOM-32も動きます。Pi用として新たに作成しました。
ただ動かすだけなら電源(3V3,GND) 信号線(TXD,RXD) 自動プログラム(DTR,RTS)の6本をつなぎ込むだけでいいのですがピンアサイン通りに並べ替えるとなると少々骨が折れます。

完成


これまで作成したAVRモジュールは今までどおり装着可能です。


ESPアダプタとそれにESP-WROOM-02そしてESP-WROOM-32を取り付けたところ


linuxgpioもOKです
高さはギリギリディスプレイの邪魔にならないところに収まっています。
簡単な実験はこのまま実行可能と思います。


作り直すきっかけとなったのはやはりPi+Kit Scopeですね。
仕様上限度があるとはいえ簡易な波形確認や電圧チェックなどは思い立ったらブレッドボードのワイヤー1本でいつでも可能という簡易さがたまりません。
まだ十分に使いこなしてはいませんがかなり実用になると思っています。(Kyutechさんありがとう)

おまけ

usbシリアル変換モジュールも余ってきたしちょうど半分に切ったユニバーサル基板があったのでESP-WROOM-02用ボードを作ってみました。
回路は以前作成したものと基本同じですがレギュレーターにNJU7223DL1-33(0.5A)を使っています。
抵抗、コンデンサ、スイッチ、チップTRなどすべてジャンク基板から流用しています。
モジュールは別ですが新品部品は基板半分とピンソケットのみでコストとしては50円もかかっていません。モジュールが1個しかないのにという声もありますが手配はしているのできっと役にたつと思います。

Top