PicoprobeのBUSIDを検索してWSLにAttachするスクリプト
タイトルママ。
シェルスクリプトを初めて書きました。
#!/bin/sh ESC=$(printf '\033') LIST=`usbipd.exe wsl list` LINE=`echo "$LIST"|grep Picoprobe` if [ $? = 1 ]; then echo "${ESC}[31mERROR:Picoprobe is not connected${ESC}[m" exit fi STATUS=`echo "$LINE"|grep "Not attached"` if [ $? = 1 ]; then echo "${ESC}[31mERROR:Picoprobe is already attached${ESC}[m" exit fi BUSID=`echo "$LINE"|awk '{print $1}'` echo "Picoprobe BUSID:$BUSID" usbipd.exe wsl attach --busid $BUSID
出力
# 正常時 Picoprobe BUSID:6-4 # Picoprobeが接続されていないとき ERROR:Picoprobe is not connected # PicoprobeがすでにAttachされているとき ERROR:Picoprobe is already attached
Raspberry Pi PicoをWSL2+vsCodeで開発する
ゼロ状態からのC/C++でのRaspberry Pi Pico開発環境の構築メモ(Windows 10)
環境構築
WSLのインストール
- Ubuntuをインストールする。
wsl --install -d ubuntu sudo apt update && sudo apt upgrade
WSL2への変更
- verを確認、2であればOK
wsl -l -v
vsCodeおよび拡張機能Remote-WSLのインストール
Pico開発環境の構築
- ドキュメントのChapter 2参照
SDKの導入
cd ~/ mkdir pico cd pico git clone -b master https://github.com/raspberrypi/pico-sdk.git cd pico-sdk git submodule update --init git pull git submodule update
.bashrcに以下を追記(PATHを通す)
export PICO_SDK_PATH=~/pico/pico-sdk
Toolchainのインストール
sudo apt install cmake gcc-arm-none-eabi libnewlib-arm-none-eabi build-essential libstdc++-arm-none-eabi-newlib
pico-examplesのビルド
- 環境構築のテストのため公式のexamplesをビルドしてみる
cd ~/pico git clone -b master https://github.com/raspberrypi/pico-examples.git cd pico-example mkdir build cd build cmake .. make -j4
- 無事終了すればOK
Picoに書き込む
- PicoをUSB経由で接続し、マウントする
- uf2ファイルをコピーすることで書き込みできる
sudo mkdir /mnt/usb mount -t drvfs d: /mnt/usb sudo cp ~/pico/pico-examples/build/blink/blink.uf2 /mnt/usb/
- 書き込みに成功すればLEDが点滅する
自作プロジェクト
- exampleでなく、自分でプログラムを作成し書きこんでみる
- 以降の作業はvsCodeからWSLにリモート接続し行う
プログラムの配置
- プロジェクト用のディレクトリを作り、そこにプログラムを配置する
cd ~/pico mkdir pico_test cd pico_test
- blink.cという名前でプログラムを配置
#include "pico/stdlib.h" int main() { const uint LED_PIN = PICO_DEFAULT_LED_PIN; gpio_init(LED_PIN); gpio_set_dir(LED_PIN, GPIO_OUT); bool LED_ON = false; while (true) { gpio_put(LED_PIN, LED_ON); LED_ON = !LED_ON; sleep_ms(1000); } }
CMakeファイルの作成
- CMakeLists.txtという名前でプログラムと同じディレクトリに配置
cmake_minimum_required(VERSION 3.13) include(pico_sdk_import.cmake) project(blink C CXX ASM) set(CMAKE_C_STANDARD 11) set(CMAKE_CXX_STANDARD 17) pico_sdk_init() add_executable(blink blink.c) target_link_libraries(blink pico_stdlib) pico_add_extra_outputs(blink)
pico_sdk_import.cmakeのコピー
- CMakeファイルの実行に必要なファイルをpico-sdkからコピーしてくる
cp ~/pico/pico-sdk/external/pico_sdk_import.cmake ~/pico/pico_test/
vsCode用設定ファイルの作成
{ "configurations": [ { "name": "Linux", "includePath": [ "${workspaceFolder}/**", "/root/pico/pico-sdk/**", "${workspaceFolder}/build/generated/pico_base/" ], "defines": [], "compilerPath": "/usr/bin/gcc", "cStandard": "gnu17", "cppStandard": "gnu++14", "intelliSenseMode": "linux-gcc-x64" } ], "version": 4 }
ビルドしてみる
- ビルドが通ればOK
mkdir build cd build cmake .. make -j4
デバッグ
- Picoをデバッガ化するPicoprobeを用いてデバッグする
- 接続等に関しては公式ドキュメント参照
Picoprobeのビルド
- デバッガ用のPicoに書き込む
cd ~/pico git clone https://github.com/raspberrypi/picoprobe.git cd picoprobe mkdir build cd build cmake .. make -j4
gdb-multiarchのインストール
sudo apt install gdb-multiarch
OpenOCDのビルド・インストール
- RP2040、Picoprobeを使う都合上、公式リポジトリからブランチを指定して落とす
- ビルドしてインストール
cd ~/pico sudo apt install automake autoconf build-essential texinfo libtool libftdi-dev libusb-1.0-0-dev pkg-config git clone https://github.com/raspberrypi/openocd.git --branch rp2040 --depth=1 --no-single-branch cd openocd ./bootstrap ./configure --enable-picoprobe make -j4 sudo make install
usbipdのインストール
- 参考
ネイティブ環境からWSL2にUSBデバイスをブリッジする
まずWinsows側にUSBIPD-WINをインストール
- PowerShellで実行
winget install --interactive --exact dorssel.usbipd-win
- WSL側にUSBIPDツールをインストール
sudo apt install linux-tools-5.4.0-77-generic hwdata sudo update-alternatives --install /usr/local/bin/usbip usbip /usr/lib/linux-tools/5.4.0-77-generic/usbip 20
vsCodeのデバッグ用launchファイルを作成
- .vscode内に配置
- とりあえず引っ張ってきたものなのであとで勉強する
{ "version": "0.2.0", "configurations": [ { "name": "Pico Debug", "cwd": "${workspaceRoot}", "executable": "${command:cmake.launchTargetPath}", "request": "launch", "type": "cortex-debug", "servertype": "external", // This may need to be arm-none-eabi-gdb depending on your system "gdbPath": "gdb-multiarch", // Connect to an already running OpenOCD instance "gdbTarget": "localhost:3333", "device": "RP2040", "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd", "runToEntryPoint": "main", // Work around for stopping at main on restart "postRestartCommands": [ "break main", "continue" ] } ] }
デバッグ
- PicoにPicoprobeを接続、PicoprobeをPCに接続
- WindowsからWSLにPicoprobeをブリッジする
- Picoprobeのbusidを確認し、そのbusidをattachする
usbipd list usbipd wsl attach --busid 4-3
- WSLのアップデートを求められた場合はそれに従う
wsl --update
openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -s tcl
PSoC CreatorのプロジェクトをGitで管理するときの.gitignore
自分用メモ
CypressのPSoCシリーズを開発するためのPSoC Creatorは高機能なIDEです。 が、中間生成ファイルが多いので、そのままGitみたいなバージョン管理ツールにぶち込むとかさばってcloneしたりするときに大変なことになります。
なので、プロジェクトの大本になるファイル群のみをGitで管理するようにして、中間生成ファイルはそれぞれの環境で作ってもらうようにするとコンパクトになります。
実際にどのファイルが必要になるかは以下のリンクに詳しく書かれています。 community.cypress.com
必要なファイル
PSoC Creator 4.2のプロジェクト構成はこんな感じになっています。うちステージングするファイルを太字にしました。
- <WorkSpace Name>
- <WorkSpace Name>.cywrk
- <WorkSpace Name>.cywrk.<User Name>
- <Project Name>.cydsn
- codegentemp
- CortexM3
- Export
- Generated_Source
- TopDesign
- TopDesign.cysch
- cyapicallbacks.h
- main.c
- <Project Name>.cycdx
- <Project Name>.cydwr
- <Project Name>.cyfit
- <Project Name>.cyprj
- <Project Name>.cyprj.<User Name>
- <Project Name>.rpt
- <Project Name>.svd
- <Project Name>_timing.html
<WorkSpace Name>.cywrkについては、上のURLではOptionにされていますが、これがないとWorkSpaceに複数のProjectを持たせた場合に環境を正しく復元できなくなります。
また、ユーザーライブラリなどをプロジェクトに追加した場合はそれも必要になります。
.gitignoreを書く
以上をもとにして.gitignoreを書きました。 <WorkSpace Name>.cywrkなどがある階層に放り込むと動きます。
# PSoC Creator *.cywrk.* /*.cydsn/* !*.c !*.h !*.cydwr !*.cyprj !/*.cydsn/TopDesign # !/User_Library
これで大量のGenerated_Source下のファイルをわざわざ更新する必要がなくなるので捗りそうです。
技術書典7に学生ロケットの本を出しました
2019年の9月22日に東京池袋で行われた技術書典7にサークル参加(本を出す側)してきました。
技術書典にはサークル参加としても一般参加者側としても参加したことはなかったので、初めての技術書典でした。 今回は新刊1冊150部を用意しましたが、ありがたいことに事前の取り置きを含めてほぼ完売することができました。
完売しました!!!! pic.twitter.com/JpmzUDQwxm
— すすむん@技術書典7 く35D (@ring_prog) September 22, 2019
この記事は技術書典に初参加した感想と反省になります。
書いた本
学生ロケットのアビオニクス(ロケットに乗っかる電子機器のこと)と飛行シミュレーションについての本を書きました。
私はアビオニクスの部を担当し、共著の先輩(@ring_prog)にシミュレーションの部を書いていただきました。
コンセプト
この本のターゲットは主に現役学生ロケッティアとしていました。
本書は著者らが⼩型ハイブリッドロケットの開発に携わった経験を元に,国内のアマチュアロケッティア向けにまとめたものである.本書の内容は必ずしも"正解"ではないがアマチュアロケッティアの参考となることを願っている.
これは本書の前書き抜粋になりますが、これの示す通り私たちがロケットを作るうえで培った知識などをまとめるというコンセプトでした。
ただ、このコンセプトがふわっとしていたため、執筆するのにとても苦労しました。 ひとくちにアビオニクスといってもこれが示す範囲は広大で、結果として広く浅く、あまりまとまりのない内容になってしまったのが反省点です。 アビオニクスでも特にハードウェアに焦点を当てるとか、実際に打上をしたあるロケットのアビオニクスができるまでをまとめるとかなど、書きたいことを絞る必要があるなと感じました。
執筆環境
Slack
共著者とのコミュニケーションにはSlackを使いました。 特に、今回は執筆データの管理にGitHubのプライベートリポジトリを使ったのですが、Slackには特定のリポジトリへのpushやpull requestを通知してくれるbotがあるので、私や共著者がpushするたびに通知が飛び、お互いにいい刺激になりました。 ログも遡りやすく、重要な投稿にはピンを立てることもできるので、グループに参加するメンバーが少なくても有効でした。
Re:VIEW Starter
執筆にはRe:VIEW Starterを使用しました。 Re:VIEWは書籍を作るためのツールのひとつで、またRe:VIEW StarterはそのRe:VIEWをLaTeXの経験が少なくても簡単に扱えるようにしたツールになります。
素の環境でRe:VIEWをコンパイルするにはLaTeXとRubyの環境構築が必要なのですが、今回は配布されたdockerイメージを使用したので環境構築で詰まることはありませんでした。 終盤、図が増えてくるとコンパイルに少し時間がかかるなーと思うこともありましたが、それでもほとんどストレスなく執筆ができました。
今後もしまた同人誌を書く機会があってもRe:VIEWを使用したいと思います。
GitHub/CircleCI
執筆データの管理にはGitHubのプライベートリポジトリを使用しました。 また、CircleCIとも連携させ、masterブランチにpushされるたびにweb上で執筆データのコンパイルを行い、生成されたpdfのダウンロードができるようにしました。
執筆終盤でcommitの数が増えて忙しくなった時も、CircleCIを見に行けば常に最新のpdfが得られるので重宝しました。
このdocker + GitHub + CircleCIの組み合わせがとても便利でした。 面倒くさい環境構築もほとんど必要なく、ver管理に手を煩わされることもないので最初に設定さえしてしまえばあとは作業に集中できるのは大きな利点だと思いました。
当日
設営
当日は私と共著者の2人で売り子をしました。 私は技術書典に参加したことがなく、さらに遠方(高知)から東京に足を運ぶことになったので、設営のための備品準備はすべて共著者にお願いしていました。ありがとうございます。
サークル参加者の入場予定時刻が10:00のところを、私たちはかなり早めの9時前後に現地に到着できていたこともあり、サークル参加者の中でも早いうちから入場・設営に取り掛かることができました。
設営完了しました pic.twitter.com/vzNejmqoKN
— Niwa🐔技術書典く35D (@Niwa_t0r1) September 22, 2019
この設営完了ツイートの投稿時刻が10時半なので、それまでには設営を終えて一般参加者を迎える準備ができていました。 私たちは新刊1冊なので設営の負担もあまり大きくないこともあり、慌てずにいくつかツイートするくらいの余裕を持って作業を行えました。
実オペレーション
一日を通しての印象としては、売り子2人なら交代で休憩をはさみつつ十分ゆとりをもって回せるくらいの忙しさでした。
来場者自体はとても多くびっくりするぐらいでしたが、頒布している本自体がニッチなだけあって、立ち読みする人もサークルの前を通りすがる人数と比べれば少なかったように思います。 立ち読み用の見本誌は2冊用意していましたが、3冊目が欲しいなと思うタイミングは全体を通して1度か2度程度でした。 逆に見本誌1冊では足りなかったと思います。
値段設定を1部1000円としたため、お釣りが必要になることもほとんどなく、その点での負担は皆無と言っていいほどでした。 かんたん後払いにも対応し、全体の3割ほどがこの決済方法を選択していました。 特にトラブルもなく、QRコードを読み込んでもらうだけでよいのでとても便利でした。
ターゲットとしていた現役/OBロケッティアには、Twitterで事前に宣伝をしたおかげか、1部のみならず2部3部と持って行ってもらえることも多く、とてもありがたかったです。 (ゆとりがあるって言ったけど一度に5部以上購入していく方がいたときはちょっと忙しかったです)
逆に、それ以外の層には全く受けないと予想していました。 ですが、学生ロケットの関係者以外の方にも立ち止まって興味を持ってもらえることが多かったです。
サークルリストを流し読みした限り、ロケットの本を扱っているのは私たちのサークル以外にありませんでした。 表紙にも大きくロケットと表記しているため、物珍しさはあったと思います。
結果として、終了時刻から1時間半ほど早い15時半あたりで取り置き30部を除いた120部を完売することができました。
チェック数と印刷部数
今回、印刷部数は150部としました。 入稿時のチェック数は50程度で、その時点で30部近くの取り置きがありました。 100部と迷いましたが残ってもそれぞれ個人的に捌くことのできる伝手にあてがあったため、150部を刷ることにしました。
イベント終了時のチェック数は70程度で、現地で売り上げたのは120部なので、チェック数の1.5倍程度の数を捌くことができました。
要因としては、思った以上に学生ロケットの関係者に周知されており、複数部を購入していただけた方が何組もいたこと、前述したように競合のほぼいない状況で目を引いたことなどが考えられます。
反省点
スケジューリング
前述したコンセプトの問題もあり、執筆にはかなり時間がかかりました。 このプロジェクトが動き出したのは6月の末であり、7月上旬に当落が出てから2ヵ月以上ありましたが、入稿できたのは最終締め切りギリギリのタイミングでした。
同人誌を書くというのは初めての経験であり、必要なリソースをかなり甘めに見積もりすぎていたというのは反省点です。 特に作図にかかるコストをほとんど考えていませんでした。
サークルカットと表紙
今回、サークルカット並びに本の表紙は私が担当したのですが、そのサークルカットと表紙のデザインが異なりました。 私たちのサークルを訪ねてくださった参加者の中にサークルカットを目印にしていた方が何人かおり、表紙とデザインが異なることから新刊が2冊あるのかと混乱させてしまうことがありました。
サークルカットは7月末に締め切りがあってからほとんど変更しておらず、そのころにはまだ表紙案は影も形もなかったため、このような状態を招いてしまいました。 表紙が固まり次第、サークルカットを表紙に変更するなどしたほうがよいと感じました。
今回は1冊のみの頒布でしたが、今後、一度に複数冊の頒布をする際、どのようにサークルカットをデザインするのがもっとも見つけてもらいやすいかは考える必要がありそうです。
機会損失
私たちが完売したのは15時半だったので、終了までの1時間半分の機会損失があったと考えられます。 ただ、事前のチェック数や取り置きの数から150部以上の数を刷ることはありえず、こんな早いタイミングで売り切れるのは全く想定していませんでした。
今回はいろいろな要因から電子版の用意をしませんでしたが、もし電子版があればもっと多くの人に本を手に取っていただけたのかもしれないと思います。
さいごに
私が同人誌を書くことになった発端はなにげないツイートでした。
一瞬ちょっとロケット電装の本書きたいなって思ったけど薄い本にまとめられるほど私の持ち物がないわ
— Niwa🐔技術書典く35D (@Niwa_t0r1) June 5, 2019
これを先輩に拾ってもらい、気づけば自分の本を書いてたくさんの人に目を通してもらうという得難い経験をすることができました。
いろいろと苦労することもありましたが、完売という最高の結果で終わることができとても満足しています。 大学から電子工作を始めた私のように、あまり経験豊富でない人間でもそれなりに1冊の本に仕上げることができるので、是非(同人誌と言う形にこだわらず)自分の知識や経験を発信していってくれるロケッティアが増えると嬉しいです。