あっきぃ日誌

鉄道ブログのような技術系ブログのようななにか

WIZnet WizFi360-EVB-Picoのレビューというか入門レベルのなにか

16日目です。書きかけの記事が消えてしまい、2回目の執筆で萎えてます。いや、本当に1回目は書いていたのだろうか?

adventar.org

14日目はつかまんさんのMaker Advent Calendar買ってみたでした。Pi Hutこんなの売ってたんですね。初日からPicoが出てくるの豪華…!そして、Pi Hutの製品レビューに子供がPicoいじってる写真があって、日本は……日本は……となりました。

tsukaman.hateblo.jp

15日目はMasataka Sawaharaさんの、「USB Raw Gadgetを使ってラズパイをUSBモデムにしてPS2のゲームのモデム対戦をTCP/IP上で行う」でした。高度すぎて完全に圧倒されました。いったいなにがなにが起こっているんだ……!

qiita.com

また、別カレンダー向け記事としてWIZnet W5500-EVB-Picoに移植する記事もあります。こちらのほうが遅延が少なく快適にプレイできるそうで、Picoすごい。

qiita.com

WIZnet WizFi360-EVB-Picoのレビューというか入門レベルのなにか

今日はWIZnet WizFi360-EVB-Picoのレビューです。WIZnet W5100-EVB-Picoの記事の続きですね。

akkiesoft.hatenablog.jp

Wizfi360-EVB-Picoは、型番から読み取れる通り、Raspberry Pi PicoにWizfi360がくっついたような評価ボードです。Pico Wと並べてみると、こんなかんじでWizFi360チップの分だけボードが大きいですが、ピン配置は同じです。WizFi360は技適取得済みでパッケージにも印字があるため、日本でも扱えます。

裏面。GP4、GP5、GP20に「WizFi360で使ってます」と印刷がありますが、わりとI2C用の一等地的なピンかと思われるので、ちょっとうれしくないかもしれません。。他のピンでも定義できるはずですが、各種ボードと組み合わせる場合は衝突しがちなので要注意です。

通電時の様子。やはり電源LEDが存在するため、人目につくところで動かしっぱなしにすると気になるかもしれません?また、WizFi360のチップ側にも青色LEDがついていて、通信中ピカピカしてくれます。そんなに光らなくても良くない?


プログラミング

秋頃に触ろうとしたときにはPython系はまだ試作段階のようでしたが、現時点ではWIZnetのリポジトリーに移動してドキュメント、サンプルとも整備された状態になっています。ライブラリはadafruitのものをベースにした、ATコマンド操作ベースのやつになっています。

github.com

github.com

Python系のサンプルをいくつか動かしたり組み合わせたりしてなんか作例〜と思っていたのですが、どうもHTTPS通信がうまくできず、何やろう……と思ったまま時間になってしまいました。かなしみ。あと、Webサーバーも既存のスクリプト流用ではぱっと動かなさそうで、これも時間切れでした。無念。

Arduinoの方はWebサーバーが動かせました。GithubリポジトリでPico用にブランチが分けられている以外の注意点は特になさそうです。RP2040のボードjsonを追加して最新のボードを取得すると、WizFi360-EVB-Picoがボードで選べるようになります。ライブラリは、リポジトリのzipファイルを取得してライブラリにイングルードすればOKです。

github.com

電力

いつもの激安USB電流チェッカー調べですが、待機時は0.05A、動作時は0.15Aくらいで動作するようでした。PimoroniのPico Wireless Packと同程度か、もうちょっと食ってるかも?という感じですね。LEDのせいでは(やつあたり)

買えるの

マルツからDigi-key在庫を買えるようです。1300円ちょっと、なかなか手頃ですかね。

www.marutsu.co.jp

まとめ

PicoWがお預け状態の日本でも使えるサードパーティ無線LAN一体型Picoボード、WizFi360-EVB-Picoの雑レビューでした。雑すぎて本当にヽ('ω')ノ三ヽ('ω')ノもうしわけねぇもうしわけねぇ。

ただ、前回W5100で作った、センサーを読み出してZabbixに送信みたいなやつなら普通にできそうですし、Python系でHTTPSとかWebサーバー触れなきゃイヤ!と、私みたいな贅沢を言わなければこれでもふつうに遊べそうです。

あと、RP2040のチップを使って自力設計する時に、Wで使われている無線チップは単品供給されていない(はず)ので、無線チップの組み込み候補としてWizFi360を使う手はあるのかなと思います。それならPicoWごと基板に埋めたるわとなりそうではありますが。

ラズピッピのサプライチェーン情報アップデートが来た!未来は明るいか?

13日目です。ネタが提供されるのありがてえ。

adventar.org

最近のRaspberry Piの生産とか供給状況についてEbenが記事を投稿しました。

www.raspberrypi.com

私の記事では適当に翻訳して読んだのをそれっぽく解釈して、オタクらしく話をダラダラ脱線させながらダベります。

ホリデーシーズン向け出荷あり。入荷情報に注意されたし!

まず、今月に入ってからrpilocatorとか日本のリセラーで各モデルが相次いで入荷していたのはやはり狙っていたようで、ホリデーシーズンに向けてPi ZeroW(2ではないようです)、Pi 3A+、2GBと4GB RAMのPi 4Bを10万台ちょっとリセラーに納めたようです。個人運用ながら公式が積極的に案内している在庫チェッカーのrpilocatorでの入荷情報収集を引き続き薦めています。でもこれ、日本の代表的なリセラーであるところのKSYさんとスイッチサイエンスさんが対象じゃないんですよね。お、おれがやるしかねえのか?!(いや、わたしは必要台数もうあるので、気が向けばっすかね……)

rpilocator.com

また、PicoまたはPicoWは在庫の面で有利なので、プロジェクトに適しているかの検討をしてほしいと述べています。実際、MicroPythonとかCircuitPythonでPicoを触ると、LEDやセンサーやサーボモーターをつないで動かすのは普通のRaspberry Piと大差なく、手を動かしてみればRaspberry PiからPicoへの移行は簡単そうということに気づいてもらえると思います。Raspberry Piが複数のコードを1台で同時に動かせるのに対してPicoは1台1コードという使い方になる点は異なるかもしれませんが、昨日の記事のように、センサーの値を読み出してZabbixに送るような、サーバープログラムにデータを送るようなものも、前ならZeroWあたりを使っていたであろうものが、今ならPicoで完結できます。

akkiesoft.hatenablog.jp

ESPとかRaspberry Pi以外のマイコンに昔から慣れ親しんできた人たちからしたら「何を今さら」と思われるのかもしれませんが、自分のように、Raspberry PiをただのLinuxマシンから入った人が、沼に沈み沈んでここまで到達したというのは、感慨深いというかなんというか……という感じなんですよね。いけない、話がそれました。日本特有の問題としては、連日叫んでますがPicoWはよせえ、全部それ待ちやといったところです。

来年以降のシリコンサプライチェーンの見通し

2023年の第二四半期にはパンデミック前のレベルに回復して、下半期には無制限になるだろうと自信を持って言える、としています。予定通りになればいよいよ好きなだけPi4も買えるようになりますね。先週KSYから出たPi4 8GBを買って早速ヤフオクに流してるバカタレどもも、あと半年で売り抜けないと在庫として部屋の肥やしになることでしょう。でも良いじゃんPS5とかSwitchよりは場所取らないからね。またちょっと話がそれますけど、PicoとPicoWも投機対象と勘違いしてせっせと転売してるのさすがに面白すぎないwそっちはほぼ品切れしないから無駄だし、Wに至っては技適方面の何かしらで罰せたりせんのか?

企業からの受注との兼ね合いもありつつ、生産した製品の割当を徐々に個人向けに増やしていくとのこと。在庫の回復順は、Pi Zero/ZeroW、(産業方面でも引き合いがないらしい)Pi 3A+、そしてPi 4と予想しているようです。ZeroはEoLも近いし(2024)必要なのか若干の疑問がありますが、まあ、良いでしょう。Pi4が最後なのも人気で引き合いも多いので仕方ないです。が、Pi 3A+はなんででしょうね……Zero2Wと比べると物理サイズで負けますが、無線は5GHzが使えてHDMIとUSBの変換がいらず、CSIポートはZeroのように軟弱ではないのに。RAMが512MBなのもZeroと同じなのに……まあ1GBあると嬉しいですけど。個人的には3A+が常設化するのにコスパ最強と思っているのでもうちょっと広まって欲しい……。

値上げの話題

部品などのコスト増がありつつも価格を維持していたところを、Pi 4B 2GB RAMのみ35ドルから45ドルに変更(もとに戻った)、CM4は全バリアントで5ドルの値上げを行ったようです。CM4こそ産業用なので企業に多めに出してもらうのはまあいいんじゃないかと思いました。

元から利益率が低かったZeroとZeroWについても"しぶしぶ"5ドルの値上げせざるを得なくなり、Zeroは10ドル、ZeroWが15ドルになるとのこと。それと引き換えに、大量生産が戻ったときにはZeroのある種の特徴であった購入1台制限が取っ払われるとのこと。これまでキットを大量購入することでZeroWを多く買っていたような人たちがいたとすれば、これはニュースかもしれません。が、先述の通り、今からZero欲しいやつおるか……?ブログでの本文はここまでで、コメントで「Zero2Wはどない?」という質問に対して「まだだけど目処はある」(たぶん?)とLizが返しているあたり、15ドルで台数無制限になるのはやはりZero2WではなくZeroWのように読み取れます。

まとめ

  • ホリデーシーズン向けに出荷したのでrpilocatorで要チェックや!
  • 生産は2023年前半でコロナ前まで持ち直して、後半から本気出す
  • 在庫はZero・ZeroW、3A+、Pi4の順に回復すると思う
  • Pi 4B 2GB RAMが昔の45ドルに戻り、CM4全種とZero・ZeroWが5ドル値上げ
  • Zero・ZeroWは値上げの代わりに台数制限取っ払うつもり

2022年末にどういう予定だったのか、掘り返すのも面倒なのでしないでおきますが、来年こそ見通し通りになって「ラズパイほしいけど買えないんすよねえ」勢がほしいと思いついた一瞬の気の迷いのタイミングに、すぐポチれる在庫が復活することを祈るばかりです。

あと、PicoWはよせえ、全部それ待ちや

追記

Ebenのコメントいわく、Zero2Wは来年第一四半期にRP3A0(Zero2WSIP)を50~100ku確保できる予定で、目処はあるというのはこれを指していたみたいですね。

https://www.raspberrypi.com/news/supply-chain-update-its-good-news/#comment-1589307

Zero2Wの価格は15ドルを維持。ただしこれも利益は少ない模様。無理しなくてもいいのよ。いやでもそうすると3A+との差が、かあ。

https://www.raspberrypi.com/news/supply-chain-update-its-good-news/#comment-1589309

Pi400はそこまで心配いらなさそう?ただ、悲しいことに日本では日本語キーボード版Pi400が不人気で売れ残っているようで*1、いや悲しいなあ。

https://www.raspberrypi.com/news/supply-chain-update-its-good-news/#comment-1589316

WIZnet W5100S-EVB-Picoのレビュー

12日目です。もう本当にネタが泣いのでおわりだあと思いながら出社したら、まだ書いてないのがいたわ。

adventar.org

WIZnet W5100S-EVB-Picoレビュー

イギリスに行ってきたおおたさんからW5100S-EVB-PicoとWizFi360-EVB-Picoをおみやげにもらい?ました。どちらもPicoにネットワークチップをくっつけたような製品で、すぐにネットワークを組み合わせたプロトタイプがはじめられます。今回は前者のレビューです。次回後者のレビューは……できるかなあ、ビミョーに遊べていないので。でも遊べたら明日も書けるんだよな……。あああと、Xeeed XIAO RP2040もおなじくもらい?ましたが、これは言わずもがな小さくて良いやつですね。

売り切れのようですが、スイッチサイエンスさんの販売URLはこちら。

W5100S-EVB-Picowww.switch-science.com

あとWIZnetの製品ページはこちら

www.wiznet.io

なんかもうガッツリ使っているけどこんなかんじ

ピン配置や基本的な形状はPicoと同様なので、あまり何も考えずに使用できます。Pythonぽいのとかを入れるときも、ボードはPicoはPicoを選べばOKです。で、写真の通り、温度センサーと室温照度センサーをつないで、オフィスの環境を監視に投入済だったりします。

やってることは去年WIZnetのモジュールを使ったときとほぼ同じで、CircuitPythonでそれぞれ値を読み出して社内のZabbixに投げつけているだけなので、コードとかはこっちを見てもらうと良いです。

akkiesoft.hatenablog.jp

Zabbixの監視結果をダッシュボードとかに出すことで、室温とか照度から誰か出社しているかどうかを確認できるという感じです。が、どうせならもうちょっとなんか、Slack連携とかをしてもいいのかもしれない🤔

いいところ

1ボードでネットワーク接続できるので手軽です。前に買ったのは汎用のモジュールだったので配線とかを自分でやる必要があり、それなりに手間だったりしたので、やらずにすむのは便利です。

びみょうなところ

電源ポートとLANポートが反対についているため、ケーブルが両端から出るような形になります。結構取り回しが面倒になってしまうので、ここは微妙ポイントかなと思いました。オフィスでは電源ケーブルをぐいっと曲げてLANケーブル側に持ってきて束ねることで、見栄えをどうにかできました。向きが揃ってるとありがたいですが、まあ、このサイズ感だと難しいですよね。

もう一点は、電源LEDの常時点灯がわりと眩しく邪魔な点。どうしてつけてしまうんでしょうね……電源LED🤔?。あると嬉しいもんなんでしょうか、私はいらない派です。

強いて言えば、MicroUSB電源は継承せずType-Cにしても良かったのではという気持ちはちょっとありました。Type-C統一過激派じゃないのでどっちでも良いですが。

まとめ

あいかわらずPicoWの国内販売の案内がないため、Picoでネットワークを使うにはサードパーティの製品だよりになります。特に有線LANタイプは無線が不安定な環境で重宝するので、PicoWが出たあとでもある程度需要はありそうですし、もうちょっとネタ擦りしてもいいかなって書いてて今ちょっと思いました。

あと、細々と微妙な点をあげましたが、型番のEVBはおそらくEValuation Boardの略でしょうし、ずっと使うなら自分で設計考えるなりええかんじにせえ、ということなのかなと思います。

Picamera2ライブラリのMJPEGストリーミングサーバーをためす

11日目です。

adventar.org

Picamera2ライブラリのMJPEGストリーミングサーバーをためす

昨日のメダカメラを触っていて思い出しましたが、メダカメラで使っているPicameraライブラリのMJPEGストリーミングサーバーをPicamera2に移行できるかの調査をしたいのでした。

おさらいをすると、Raspberry Pi OS Bullseyeではカメラ関係の技術スタックがlibcameraに移行した影響で、Picameraライブラリはlibcameraとは組み合わせ不可になりました(技術スタックをLegacyに戻すことは可能)。

akkiesoft.hatenablog.jp

libcameraに対応したPicamera2がRaspberry Pi公式で開発されることになり、2月にはプレビューリリースが、直近では0.3.7のベータリリース6まで開発が進んでいます。

akkiesoft.hatenablog.jp

Picamera2は大量のサンプルが用意されており、Picameraからの移行を想定してか、同じ用途のサンプルも整備されています。

github.com

サンプルを見比べる

Picamera2のMJPEGストリーミングサーバーのスクリプトはこちら。

github.com

Picameraのスクリプトはこちら。

github.com

Picamera2のスクリプトはPicameraのものをベースに開発されているらしく、パット見の差分は結構少ないです。実際のdiffも量は多いものの、いくつかの処理がなくなったりインデントが上がったりしている程度に見えます。

--- /Users/akkie/Desktop/web_streaming.py	2022-12-11 12:54:14
+++ /Users/akkie/Desktop/mjpeg_server.py	2022-12-11 12:54:12
@@ -1,39 +1,43 @@
+#!/usr/bin/python3
+
+# Mostly copied from https://picamera.readthedocs.io/en/release-1.13/recipes2.html
+# Run this script, then point a web browser at http:<this-ip-address>:8000
+# Note: needs simplejpeg to be installed (pip3 install simplejpeg).
+
 import io
-import picamera
 import logging
 import socketserver
-from threading import Condition
 from http import server
+from threading import Condition, Thread
 
-PAGE="""\
+from picamera2 import Picamera2
+from picamera2.encoders import JpegEncoder
+from picamera2.outputs import FileOutput
+
+PAGE = """\
 <html>
 <head>
-<title>picamera MJPEG streaming demo</title>
+<title>picamera2 MJPEG streaming demo</title>
 </head>
 <body>
-<h1>PiCamera MJPEG Streaming Demo</h1>
+<h1>Picamera2 MJPEG Streaming Demo</h1>
 <img src="stream.mjpg" width="640" height="480" />
 </body>
 </html>
 """
 
# ベースになるクラスが変わった模様
-class StreamingOutput(object):
+
+class StreamingOutput(io.BufferedIOBase):
     def __init__(self):
         self.frame = None
-        self.buffer = io.BytesIO()
         self.condition = Condition()
 
     def write(self, buf):
# bufの開始のデータを見なくて良くなったのか、インデントが上がっている
-        if buf.startswith(b'\xff\xd8'):
-            # New frame, copy the existing buffer's content and notify all
-            # clients it's available
-            self.buffer.truncate()
-            with self.condition:
-                self.frame = self.buffer.getvalue()
-                self.condition.notify_all()
-            self.buffer.seek(0)
-        return self.buffer.write(buf)
+        with self.condition:
+            self.frame = buf
+            self.condition.notify_all()
 
+
 class StreamingHandler(server.BaseHTTPRequestHandler):
     def do_GET(self):
         if self.path == '/':
@@ -73,16 +77,20 @@
             self.send_error(404)
             self.end_headers()
 
+
 class StreamingServer(socketserver.ThreadingMixIn, server.HTTPServer):
     allow_reuse_address = True
     daemon_threads = True
 
# withぶんを使わないでインデントを上げたみたいなノリ
-with picamera.PiCamera(resolution='640x480', framerate=24) as camera:
-    output = StreamingOutput()
-    camera.start_recording(output, format='mjpeg')
-    try:
-        address = ('', 8000)
-        server = StreamingServer(address, StreamingHandler)
-        server.serve_forever()
-    finally:
-        camera.stop_recording()
+
+picam2 = Picamera2()
+picam2.configure(picam2.create_video_configuration(main={"size": (640, 480)}))
+output = StreamingOutput()
+picam2.start_recording(JpegEncoder(), FileOutput(output))
+
+try:
+    address = ('', 8000)
+    server = StreamingServer(address, StreamingHandler)
+    server.serve_forever()
+finally:
+    picam2.stop_recording()

picamera2のフレームレートのデフォルト値は見てませんが、picameraでframerate=24を指定していたところをpicamera2で実装する場合は次のようになります。

picam2.configure(picam2.create_video_configuration(main={"size": (640, 480)},controll={"FrameRate": 24.0}))

以上から、スクリプトの移行自体はわりと苦労せずにサクっとできそうです。

動かしてみると……

メダカメラのスクリプトをPicamera2用に変更したバージョンを作って、Bullseye環境で実際に動かしてみました。現在のメダカメラはPi3Bで動かしているので、Bullseye環境も同様にPi3Bを使いました。動作自体はごく普通に、カメラの映像がMJPEGで配信されていて問題はなさそうでしたが、ふと気になってtopコマンドで負荷を覗くと、CPU使用率に差があることに気が付きました。

左のmedaka2.localが本番用、右のmedaka.localがテスト環境です。以下はまだだれもストリーミング画像を開いていない状態。左のPicamera環境が控えめなのに対して、右のPicamera2環境の負荷が高めなのがわかります。おそらく左環境ではGPU側で処理できているのに対して、右側はCPUで処理しているからではないかと推測します。

次にストリーミング画像を開いて少し置いた状態。左も右も少し負荷が上がりましたが、差はとくに変わらない気がしました。また、負荷に応じてCPUの温度が上昇しているのもわかります。なお、左の環境はヒートシンクなし、右の環境はヒートシンクありで、環境差がある点に注意してください。


うーん、まだ待ったほうが良い?

Pi3BやPi4Bで動かすぶんにはCPUで処理しても問題ないと判断されているのか、どこかしらの処理でlibcameraからGPUを使うための実装がまだなのか。いまいち想像がつきませんが、どちらにせよせっかく今までGPU側で処理できていたっぽい部分がCPU側で処理されているのは微妙な印象です。

じつは昨日までPiZero Wでメダカメラを動かしていて、若干カクつくので3Bに入れ替えたのですが、その浮いたPiZero WでPicamera2環境を動かしたら、だいぶ厳しい感じでした。映像も2秒遅れとかガックガクとかで、若干カクつくどころではありませんでした。ぐぬぬ

今後の開発でGPU処理に変われば良いでしょうが、そうでなければちょっと厳しいかなあという印象です。ディスプレイ出力周りの変更もそうですが、プロプライエタリな実装をオープンな実装に移行することが必ずしも便利になるばかりではないみたいなものを感じますね……。

まとめ

MJPEGストリーミングサーバーのスクリプトの移行自体は簡単でしたが、動かしてみると負荷の面でちょっと不安がありそうでした。今は無理をせずLegacyに切り替えてPicameraの利用を継続しつつ、動向をウォッチしておこうかなあと思います。Issueで質問とかしたほうが良い気もしつつ、それは面倒なのでやめておきたい(へたれ)