Quantcast
Channel: @SRCHACK.ORG
Viewing all 1089 articles
Browse latest View live

[emo] Linux Gadget driverについて書くよ

$
0
0
2020年12月さすがに寒い日が続きます、Advent Calendarを続けています。
何の因果か1年も開発に関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。

今日は、Linux Gadget driverについて。
linux-cdc-acm の前に、Linux Gadget driver ってみなさん利用されていますか?

Raspberry Pi Zeroが登場した辺りから、Linux Gadget driver の知名度がぐんと上がった気がしているのですが、Linux Gadget driver 機能をメインに使っている製品以外では、製品で利用しているケースってどれぐらいあるのですかね?
あっ、未来ガジェット研究所の話ではないです。(そんなのはいいですね。
今回はじめて Linux Gadget driver を利用してみたのですが、思った以上に便利ですね。
OpenWrt でも普通にモジュールとして定義されていたのは驚きでしたが。

ハード的には、USBポートを外部に露出させておけば良いというのは本当に最高ですよ。
まぁ、USBホストとゲストに同時にはなれないという説明を何度もしないといけない羽目になりましたがw


で、Linux Gadget driver 便利だなぁと思っていたので、開発作業で利用しようとは思っていたのですよ。
旧世代機BOCCOでは、みんな気軽にテストパターンにケーブルを半田付けしてしまう傾向があるのですが、問題が起きた際に、ハードを触ってしまっている事による影響が0にはならないというのがあまり意識されないという開発傾向をみていると、なんとしてでもハードは弄らずにソフト開発作業をさせる方法を確立しておかなくてはという執念めいた衝動に駆られまして。
半分冗談、半分本当の事なのですが、emoでもやはりすぐシリアルケーブル生やす傾向は抜けませんでしたね。。。
まぁ、ハードを弄らなくても作業できる様になった事自体は、ハードを触らないエンジニアを開発チームに取り入れるハードルをさげる事には役立ったかとは考えています。
ほんと年々ハード触らない人増えてますね。(ハードの会社だったとしても


Linux Gadget driverなのですが、様々な種類ありますよね。
OpenWrt 19.07だと、以下6種類が利用できる様になっていますね。
  • kmod-usb-gadget-cdc-composite.USB CDC Composite (Ethernet + ACM)
  • kmod-usb-gadget-ehci-debug. USB EHCI debug port Gadget support
  • kmod-usb-gadget-eth. USB Ethernet Gadget support
  • kmod-usb-gadget-hid. USB HID Gadget Support
  • kmod-usb-gadget-mass-storage. USB Mass Storage support
  • kmod-usb-gadget-serial. USB Serial Gadget support
linux-imx でサポートされているものとなると、もっと沢山ある訳です。
シリアル、ネットワークインタフェース、オーディオ、ストレージ、HID、カメラ、プリンター、MIDI、なんか沢山ありすぎて、コンフィグの仕方がわかりません。
この沢山ある中から、g_ether、g_serial、g_cdc 辺りは、比較的扱いやすいものの様に思えます。
それ以外は、configfs で設定しないといけない項目が難解です。
また、configfs の内容が kernel バージョンによって異なったりで、解りやすい資料がなかなか見つからない。。。
もぅ、コードを読んだ方が早いのかと思ってしまいます。

オーディオは少し気になってるのですがね、emoがUSBオーディオ化できるのも愉しいかもしれないと。
Audio Class 1.0、Audio Class 2.0、も対応している様にも見えるので夢が広がります。
そのうち遊びたいですね。


BOCCO emoでは、この種類があるなかから、g_ether と g_cdc を開発作業に利用しました。
正確には、主に g_ether になりますが
g_cdc をメインで使えなかった理由には3つあります。

1つ目の理由は、g_cdc の Ethernet側のドライバが、Windowsには無いことです。(これはどうにも手が出せません
ソフトウェア開発作業では、Linuxコンソール操作とファイル転送がどうしてもさせたかったので、Ethernet側が使えないのは困ります。
ちなみに、g_cdc のシリアル側のドライバなのですが、Windows10 だと少し面倒で、署名付きで該当するのがなかなか見つからないのですよね。
私は、昔$8コンピュータとかいって登場したシングルボードコンピュータの「C.H.I.P.」で配布されていたドライバを利用しています。
「C.H.I.P.」自体、会社が解散してしまってサイトも消えているのですが、幸いにも Internet Archive に残っています。
https://archive.org/details/chip-flashing-mode-driver

2つ目の理由は、シリアルコンソールを有効にOpenWrtで出来ない。
はじめは、CONFIG_VT_HW_CONSOLE_BINDING 辺りの話かと思ったのですがね、まったく違う話だったのですよ。
正確にいうと、initタイミングで Linux Gadget driver が読み込まれている場合は、コンソールが有効に出来るのだが、後から Linux Gadget driver を読み込むと、ttyを起動するタイミングを失ってしまいます。
inittab 再読み込みの為に、シグナルを送ればいいじゃないかと思われるかもしれませんが、OpenWrtではシグナルを送っても、inittab 再読み込みは走ってくれないのです。
答えは、openwrt-develのメーリングリストのアーカイブに眠ってました。
Re: [OpenWrt-Devel] Q: procd: re-evaluation of inittab entries
Busybox initを弄るのは少しリスキーですね。
というか、詳細情報がもっと欲しいです。使えそうな資料といえばコレぐらいですかね。
https://openwrt.org/docs/techref/process.boot
結局、コードを読んでいって、対応させる事はできるけど、マスターのコードに追従しつつ維持するのは、大変だと言う事で、シリアルコンソールを有効にするのは諦めました。

3つ目の理由は、g_cdc の Ethernet 側なんか不安定じゃない?
薄々気がついてはいたのですが、g_cdc の Ethernet 側、内部での usb0 がなんか不安定な気がしています。
原因追えてないですが、なんか、シリアル側は安定してるのに、Ethernet側を使うと不安定なきがしています。


g_ether が使いやすい。
RNDISとして認識してくれるので、Windows、macOS、Linux、ソフトウェア開発者が使ってる端末でとりあえず困らなさそう。
最近は、macOS使ってるなら、自分でなんとかしてくれるやろという過信は禁物です。
意外とLinuxユーザの方がなんとかしてくれます。(そこじゃない?
ちょっと面倒なのは、Windows10ユーザぐらいですかね?
Windows10だと何故かシリアルとしてはじめ認識するんですよね。。。ドライバ更新すればちゃんとEthernet認識するのですが。。。
あと、g_cdc より安定している気がする。


Linux Gadget driver、configfsで設定を作っていかないといけないもので無ければ、本当に手軽に使えるのでお勧めです。
まぁ、本当にやりたいものって、configfs触らないとできないのですが。。。
年末休み使って、Audio Gadget は動かしてみたいですね。(時間取れるのか解りませんが。。。


今日は予定変更した事で、出せていなかったネタについて記載しました。Advent Calendar 2020、18日目でした。
次は パーツ変更 について書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。これぞシュタインズ・ゲートの選択!!
19日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] パーツ変更について書くよ

$
0
0
2020年、Advent Calendarを書いています。クラウドファンディング終わってたらしいですね。
1年も開発に関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。

今日は、パーツ変更で発生する作業について。

製品を作った際、途中でパーツを変更する事があると思います。
パーツの価格を下げるため、パーツに問題があった、パーツが入手できなくなった、ただなんとなくの思いつき。
思いつきで変えられると大変面倒なので、そのパターンは考えない事にします。

まず、2つに分けます。
  1. パーツの価格を下げるため: 価格を妥協すれば同じハードで製造継続できる
  2. パーツに問題があった、パーツが入手できなくなった: パーツを変えないと製造継続できない
1.については、妥協できるなら、対応するスケジュールは間に合わなくても何とかなります。
2.については、スケジュールが破綻すると、販売できないという状況に直結するので、ビジネスとしては成り立ちません。

今回は、2.の場合に、どんな作業が発生して、いつから動き出せばいいのだろうかを書いていきます。


まぁ、パーツ1つ変えるにしても、色々とやる事が発生します。
おおまかにこれぐらいで、どれぐらいの時間が掛かるのかを考えればいいでしょうか。
また、全部が1人でやるとは限らないので、それぞれのタイミングで、必要な人を確保しないといけません。(場合により、単純な積み上げ以上に時間がかかるかもしれません。
  1. パーツ選定
  2. パーツ検証基板用意
  3. ソフトウェア (Linux) 動作確認
  4. ソフトウェア (アプリケーション) 改修範囲確認
  5. 基板再試作
  6. ソフトウェア (アプリケーション) 改修
  7. テスト
  8. パーツ部集
  9. 量産
9.は、ある意味既に工場作業に入っているので、8.までを生産までの作業として、5~8.辺りが一番時間が掛かってくる箇所になってきます。
1番期間が読めないのが、パーツ部集ですかね、社外が絡んでしまうので、
部集が仮に4wとなると、量産1ヶ月前にはテスト完了の見込みが立っていないといけません。(実際には発注手配であったり、組み立て工場と、基板工場で別であれば、その発送手配だったりと、増し増しになっていきます。)
ソフト、テストに1ヶ月程度かかるという見積もりの改修であれば、パーツ検証は、量産2ヶ月前には完了できていないと、間に合わないことになります。
これらを考えて、量産3ヶ月前には、パーツ変更に対し行動を開始していないと、スケジュール破綻している事になります。(頑張れば良いという世界ではありません。

そこに更に確保できる人員が限られている場合は、人員が空いているタイミングなのかという話が出てきます。
それぞれ担当となる人が作業のできるタイミングに当てないといけません。
実際には、各タスクの間に、数日開いてしまったりというのは考えられる事です。
たかが、パーツ1つの変更なのですが、期間はそれなりに取られてしまいますね。(作業よりスケジューリングの方が大変でしょう。


で、この中で私が担当する主に担当する範囲は、ソフトウェア (Linux) 動作確認ですね。
すんなり動作すればいいですが、動かない時は、パーツを選びなおすというケースもあるので、早めにしておくにこした事はありません。
ここでスケジュール破綻すると、中間パートの人達が徹夜になります。
OpenWrtに組み込んで、BOCCO emoのLinux上で利用できる様にしてみると、7個ぐらいのパッチができました。(差分2,000行も行きませんかね。)
パーツ変更前ハードとの共存が必要なので、少し行数多めな気もしますが、
僕のパートは、仕事の合間で数日~永くて1週間程度で終わらせないと次が進まないので、時間的余裕は常に持ちたいのですがね。

しかし、たったパーツ1つで、期間3ヶ月とか取られるぐらいなら、パーツ変更が起きない様にEOLはもっと気にしたい処ですよね。



今日は土曜日ですよ、そろそろクリスマスプレゼント用意しないと怒られちゃいますよ。Advent Calendar 2020、19日目でした。
次は aarchとaarch64 について書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。どどど。
20日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] aarchとaarch64について書くよ

$
0
0
2020年ももう終わりそうですね、Advent Calendarもかなり進みましたね。
1年も開発に従事してしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。


今日は、aarch と aarch64について。
まぁ、正確には、lib32 と lib64について書きたい。
Raspberry Pi 3Bが登場した頃から、aarch64 も一般に広まって、気軽に組込Linuxでも64bit動くんでしょ?と云われる様になった気がしています。
逆に Raspberry Pi 4B から 64bit になったんでしょ?という人も増えましたが。。。(3B、3B+で64bit動くの?みたいな話が尽きない。。。)
ハードウェアが64bitに対応しているかと、OSが64bitに対応しているかと、アプリケーションが64bitに対応しているか、みたいな話をしないといけないのですが、OSを利用しないベアメタルな開発とか、RTOSを利用した様な開発しか、縁がないと、感覚として掴み難いのかもしれない。
逆に上物か触らない人が、下側がどうなのかというのを気にしないで良い様になっているという幸せな状況というのもあり、64bit対応なのかを考えなくて動いてしまう方向に進んでいるのだろうか。。。 (たしかに、Ubuntuつかってて気にする機会あまりないな。。。

まぁ、まぁ、組込Linuxでも 64bit が普通に使われる様になりましたが、ここで少し知っている人は、aarch64 な SoC でも aarch のバイナリ動かせるんでしょ?という話がでてきたりします。
またセンスの無い図で申し訳ないです。でも、こんな感じじゃないですか?と。

BOCCO emo で採用されている、i.MX8M Mini Lite では、コアが Cortex-A53 で、勿論、64bit も 32bit も動かせます。(64bitなコアを持つハードが32bitも動くという話ではなく、IA64の様に32bitを切り捨てるアーキテクチャも存在しています。)
BOCCO emo では、ハードウェアとしては、64bit, 32bit 両方動かせるのですが、ソフトは64bitで行くという話を開発当初からしていました。
これは、音声認識エンジン等で、64bitの方が処理速度有利という判断がありました。(搭載メモリサイズは小さいのでそこ以外は32bitでも困らなかった。)
僕が、OpenWrtベースの環境を aarch64 で構成すると決めたので、音声合成や、Acconeer のライブラリを64bit対応する必要が出た訳ですが、ここで更にもう少しLinuxを知っている人が居たなら、Multilib対応という話がでたのかもしれない。(開発期間的に僕は、それでも 64bit Native を推したと思いますが。。。
なので、BOCCO emo では、lib32 は対応してないです。(まぁ、Linux kernel の CONFIG_COMPAT は有効にしていますが、CONFIG_COMPAT については後で少し触れます。


ここまで来ておいて、lib32, lib64 って何?な人もいるかと思います。
lib に共有ライブラリが置いてある事は、みなさん知っていることと思いますが、lib32、lib64 は 64bit アーキテクチャが登場してから(Multilibが始まってから?)の話になります。
64bit アプリケーションを動かすには、勿論 64bit な共有ライブラリが必要になる訳ですが、共有ライブラリを 32bit、64bit で分けて配置されている状態になっています。
32bit は lib32、64bit は lib64 という形です。
また、32bit のみな環境では、区別する必要もないので、lib のみな事が多いです。
また、64bit のみな環境 (64bit Native 等云われることもありますが) では、lib64 は lib へのシンボリックリンクとなっている形が構成されます。(toolchainの構成次第で変わると思いますが
で、64bit 環境で、32bit も動くだろという話をする人が居るのは、Multilib 環境の事を指しています。 (lib32 も lib64 も一通り用意された環境。)
組込Linuxで、わざわざ Multilib環境を構築する人は余り見かけませんが、製品で使ってるのはどれぐらいあるのでしょう。。。

32bit も 64bit も使えるなら、Multilib 環境を作っておくメリットは確かにあります。
BOCCO emo でこれ動かしたい、32bit しかライブラリ無いけど、といわれてもすぐに対応できるメリットは大きいです。
しかし、Multilib 環境を作るのは大変です。
kernel, toolchain, library 全部対応する必要があります。
kernelは、アプリケーションで 64bit も動かしたい場合、64bit で作成します。CONFIG_COMPATを有効にしておくのは重要です。
これがないと、aarch64、64bit環境の kernel で 32bit アプリケーションは動作させれなくなります。
config COMPAT
	bool "Kernel support for 32-bit EL0"
	depends on ARM64_4K_PAGES || EXPERT
	select COMPAT_BINFMT_ELF
	select HAVE_UID16
	select OLD_SIGSUSPEND3
	select COMPAT_OLD_SIGACTION
	help
	  This option enables support for a 32-bit EL0 running under a 64-bit
	  kernel at EL1. AArch32-specific components such as system calls,
	  the user helper functions, VFP support and the ptrace interface are
	  handled appropriately by the kernel.

	  If you use a page size other than 4KB (i.e, 16KB or 64KB), please be aware
	  that you will only be able to execute AArch32 binaries that were compiled
	  with page size aligned segments.

	  If you want to execute 32-bit userspace applications, say Y.
そして、kernel だけが対応していても、32bit アプリケーションは動作させれません。
必要な library が全て対応している必要があります。
library で 32bit のものが必要と言う事は、32bit 用の toolchain (GCC/Binutils) が必要になります。
で、全てのライブラリを2回ビルドして配置すれば良いとなるだけであれば、まだ楽なのですが、一つで 32bit, 64bit に対応しているものもあって、それらを意識して作成する必要があります。
また、64bit 用のもののみを用意すれば良いものの発生します。
面倒ですね。
さらに、BOCCO emo でビルド環境のベースとした OpenWrt では、Multilib環境への対応はありません。(僕の記憶では
これは更にヘビーですね。

また、Multilib に対応すれば、様々なものを動かせる可能性は増えますが、全体のビルド時間は長くなりますし、全体の容量(ディスクサイズ消費)も増えます。
組込Linux は組み込むアプリケーションがある程度開発時期に決められるケースが多いので、わざわざ Multilib に対応しなくても収まるというのがあるとは思います。
BOCCO emoの様に、汎用的に Linux 動くんだから Linux で動くものは大体動きますと使い出すと、ライブラリ環境整備する側としてはしんどい訳ですがw


仕事で、組込Linux環境用意とかされてる方達で、Multilib環境用意してる。という方はどれぐらい居るのですかね?
最近は、Debian とかの、debootstrap とかを利用して、サクッと用意できるのですかね?
Yocto は個人的にあまり好きになれないので、解らないのですが、Multilib とかやるのですかね?
Multilib を考えだしたら、OpenWrt の Multilib 対応をはじめてみたくなってきましたね。



今日はもぅ冬休み気分ですね。Advent Calendar 2020、20日目でした。
次は Hotplug について書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。ぶるぶる。
21日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] Hotplugについて書くよ

$
0
0
2020年、Advent Calendarも終盤です。そろそろ誰か Advent Calendar にツッコミいれませんかね?
1年も開発に関わってしまっていたユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。

今日は、Hotplugについて。
BOCCO emoのビルド環境のベースとなっている OpenWrt の Hotplugは凄く便利なんです。
Hotplug と聞くと USBデバイス を思い浮かべるかもしれません。
しかし、それだけではなく様々なイベントを扱えるのです。
デバイスのアタッチ/デタッチ、ネットワークインタフェースのリンクアップ/リンクダウン、ボタンのプッシュ/リリース、様々です。
また、コマンドからイベントを発生させる事も出来るので、ユーザプログラムから他のアクションを発生させるのに便利です。



BOCCO emoでは、ボタン、USBデバイス、時刻同期、リセット、とかに利用していたりします。
ボタンから見ていきます。
主な設定(というかスクリプト)は、/etc/hotplug.d/ に配置されており、ボタンについては、/etc/rc.button に配置されていたりします。
/etc/rc.button については、Linux kernel の gpio-keys-polled も関連してきます。
最近は、Linux kernel も dts 対応が進んでいるので、こういう形で定義できます。
linux,code 部分が、飛んでいくイベントですね。
	gpio-keys-polled {
		compatible = "gpio-keys-polled";
		#address-cells = <1>;
		#size-cells = <0>;
		poll-interval = <20>;

		button@0 {
			label = "reset";linux,code = <BTN_0>;
			gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
		};
	};
OpenWrtでは、reset や power 等のイベントは既にスクリプトがデフォルトのものが用意されています。
カスタマイズする場合は、BTN_0 の様にユーザ定義用に確保されているものがあるので、/etc/rc.button/BTN_0 という様にスクリプトを用意するといいでしょう。
正確には、/etc/hotplug.json というファイルの以下箇所の定義に従って、/etc/rc.button/BTN_0 が呼び出されるのですが、通常ここまで追う事になるケースは少ないでしょう。
        [ "if",
                [ "and",
                        [ "has", "BUTTON" ],
                        [ "eq", "SUBSYSTEM", "button" ]
                ],
                [ "button", "/etc/rc.button/%BUTTON%" ]
        ],


次に、USBデバイスとかは、どの様になるのか見ていきます。
USBデバイスが認識したタイミングで何か処理しないといけない等に利用します。
利用方法としては、デバイス名を固定化したいとかでしょうか。
https://openwrt.org/docs/guide-user/base-system/hotplugの Examples にもありますが、Symlink です。
${PRODUCT} や ${DEVTYPE} を使って、イベント対象のデバイスを特定し、シンボリックリンクを作成して、名前を固定化したりします。(Ubuntuとかではudevで設定したりしている例がありますね、そっちはシンボリックリンクではないですが
${DEVICE_NAME} が /sys 配下をたどらないと取り出せないデバイスだと少し面倒ですが、多くの場合は見つかるでしょう。
LTEモデムとかだと、一つの ${PRODUCT} で ttyデバイス が複数できてしまうので、面倒ですね。

USBデバイスの認識タイミングによって、イベントを取りこぼすことも起きるので、Coldplug にも対応しておきましょう。(これも Examples が載っていますね。
注意しないといけないのは、Coldplug に対応する為には、${ACTION} が "bind"のイベントを取らないといけないですが、デバイスによって、"add"と "bind"が同時に飛んできて邪魔な場合があります。
場合により、"add"と "bind"を区別、または、両方動いても問題ない様にしておく必要があります。
処理内容は、スクリプトに書くだけなので割愛します。


wwanインタフェース利用時には実は Hotplug を使っている。
USBデバイスで、Symlink 等の対応が必要ない場合、Hotplugに触れることはあまり無いと思われるかもしれませんが、実は、LTEモデム等を利用した際には、大活躍していたりします。
wwanインタフェース系の制御は、ここにHotplugに大きく依存した構成がとられています。
wwan系でトラブルが発生しなければ追わなかったかもしれません。
処理が入り組んでいて、記憶が薄れてきていますね。
この辺りを飛び交っています。
  • /etc/hotplug.json
  • /sbin/hotplug-call
  • /etc/hotplug.d/iface/00-netstate
  • /etc/hotplug.d/iface/20-firewall
  • /etc/hotplug.d/tty/30-3g
  • /etc/hotplug.d/usb/00_wwan.sh
  • /etc/hotplug.d/usbmisc/00_wwan.sh
  • /lib/netifd/netifd-proto.sh
  • /lib/netifd/ppp-up
  • /lib/netifd/ppp-down
  • /lib/netifd/proto/3g.sh
  • /lib/netifd/proto/ppp.sh
  • /lib/netifd/proto/wwan.sh
  • /lib/network/config.sh
  • /lib/network/wwan/*
デバイス認識から始まり、該当するデバイスに対して、/etc/config/network 設定に該当するものが存在するかチェックが入り、存在していた場合に、該当するプロトコルでwwanインタフェースを上げるという流れを取っています。

ここで、Hotplug のイベント、"bind"と "add"に苦しめられたりするのですが。。。
既に、Hotplug が動作する条件を満たしたタイミングで、wwanデバイスが認識した場合と、Coldplug の様な場合で、挙動が違うのです。
また、OpenWrt起動時の /etc/config/network 読み込み時の挙動でも、wwan を起動しようとするので、Hotplug とのタイミングが被る危険もあります。
既に wwanインタフェースを立ち上げているのに、再度 Hotplug イベントで立ち上げようとすると、wwanインタフェースのDown/Upが繰り返されるという様な挙動が起きたりします。
上で列挙したスクリプトを、調整していくことで回避できますが、影響範囲がきになる処です。
動きが入り組んでいるので、今後あまり触りたくない処ですね。(また処理を追い直さないと触れそうにないです。


時刻同期をネットワーク疎通タイミングで行いたい。
NTPの試行は、失敗した場合、再試行タイミングがx2されていくので、起動時にntpdを起動したのでは、サーバと通信する際にまだ時刻が同期できていないという事がよく起こります。
特に無線を利用している場合、ネットワークに繋がるタイミングは読めません。
起動後、30秒後なのか、1分後なのか、はたまた10分後なのか。
NTPの同期タイミングと偶然合えばいいですが、そんな保証はありません。
ネットワーク接続と、時刻同期のタイミングを近づけるのにも、Hotplug は有効です。
インタフェースがリンクアップしたタイミングで、時刻同期を行うと、同期されていない期間を短くする事ができます。
正確には、インタフェースがリンクアップして、かつ名前解決もできる状態になってからですが、初回1回は失敗するかもぐらいに抑えられます。

ちなみに、OpenWrt 19.07の busybox に含まれる sysntpd の Hotplug は挙動が少し変な気がしています。
一応、Hotplug が入っているのですが、呼び出しを行うだろう /usr/sbin/ntpd-hotplug はsysntpd の initスクリプト内で procd_append_param command 指定されているだけなので、インタフェースのリンクアップとの協調動作をしている様にはみえません。
とりあえず、インタフェースのリンクアップに対し、sysntpdを再起動させてしまうのが手っ取り早い気がします。
ntpclient パッケージでは、その辺り作られているのですが、


リセットとか 他のプログラムから呼び出す
コマンドで、Hotplugのイベントを発生させる事ができる。
wwan系のトラブルで、Hotplugの処理を追っていた時に気がついたのですが、/sbin/hotplug-callというのが存在しています。
実体はスクリプトなので、少し見てみましょう。
#!/bin/sh
# Copyright (C) 2006-2016 OpenWrt.org

export HOTPLUG_TYPE="$1"

. /lib/functions.sh

PATH="/usr/sbin:/usr/bin:/sbin:/bin"
LOGNAME=root
USER=root
export PATH LOGNAME USER
export DEVICENAME="${DEVPATH##*/}"

[ \! -z "$1" -a -d /etc/hotplug.d/$1 ] && {
        for script in $(ls /etc/hotplug.d/$1/* 2>&-); do (
                [ -f $script ] && . $script
        ); done
}
使い方は、/sbin/hotplug-call に 引数をつけて実行するだけですね。
引数で指定されたときに、その名前のディレクトリ内にあるスクリプトが実行されます。
シンプルです。また、/sbin/hotplug-call を呼び出す際に設定しておいた環境変数を引き継いでくれるので、こんな使い方をすれば処理の使い分けも可能です。
通知だけして、自分が死んでしまいたいプロセスとかには便利ですね。
$ MODE=gehogeho /sbin/hotplug-call hogehoge


OpenWrt の Hotplug、便利じゃないですか?
情報が少ないのがアレなのですが、かゆい処に届く機能だったりします。
もっと情報が充実してほしいですね。

今日は有給消化です、高等遊民みたいですね。Advent Calendar 2020、21日目でした。
次は 時刻同期 について書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。ずぼっとなぁ。
22日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] 時刻同期について書くよ

$
0
0
2020年も終わりそうです、ぼっちで Advent Calendarを続けています。
1年も関わってしまっていたユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。


今日は、時刻同期について。
RTCを積んでいないデバイスって多いですよね。
RTCを使うとなると、どうしても電池なりを入れないといけなくなるので、使いたくないですね。
ネットワーク使用前提の製品だと、NTPを利用するパターンが多いですよね。
BOCCO emoでも、NTPは利用しています。でも、それだけじゃないんです。というお話です。


まずは時刻同期に、NTPサーバを利用するというのは、製品としては良くある話ですね。
勿論、NTPサーバを自社で運用してという処までやる場合もあるかと思いますが、生産の見込台数から外部のNTPサーバを利用するのも良いでしょう。
外部のNTPサーバを利用する場合、1つのサービスに依存してしまわない様にしておく等考慮しておくべきかと思われます。
特に、通信をSSLのみに頼っている場合、時刻同期ができない為に、倉庫に眠っていた製品がユーザに届いたが、実は通信できなくなっていたなんて間抜けな笑い話は犬も喰いません。

また、前日少し記載しましたが、ネットワーク疎通タイミングと、時刻同期までの、タイムラグを小さくするというのも、製品の体感に大きく関わってきます。
そういった調整が、実際に製品が機能するまでのユーザの待ち時間を減らす結果となります。
ユーザが時刻同期待ちとかイケテナイですからね。

NTPを利用する際、時刻同期がされた状態なのか知りたい場合もあると思います。
勿論、ntpのコマンドをexecするという方法もあると思います。
でも、極力execとか使いたくないと思うことがあると思います。
OpenWrtのsysnptdだと、Hotplugの仕組みのおかげで、同期済みなのか判断できる様になっていたりします。これを利用するのもいいでしょう。
内容は、/etc/hotplug.d/ntp/25-dnsmasqsec を見ると解るかと思います。/var/state/dnsmasqsec にファイルが生成されていますね。
#!/bin/sh

. /lib/functions/procd.sh

TIMEVALIDFILE="/var/state/dnsmasqsec"

[ "$ACTION" = stratum ] || exit 0

[ -f "$TIMEVALIDFILE" ] || {echo "ntpd says time is valid">$TIMEVALIDFILE
        /etc/init.d/dnsmasq enabled && {
                procd_send_signal dnsmasq '*' INT
        }
}


RTCを載せるという裏技
BOCCO emoには、拡張ボードを刺す為のコネクタが付いています。
このコネクタ仕様が、一般公開されるのかは未だ不明なままですが、ユカイ工学株式会社の記事を眺めていると、公開APIも充実させる方向の様なので、今後に期待といった処でしょうか。
ここにRTCモジュールを搭載させて、ネットワークに繋がらないタイミングでも、正しい時刻を使おうというのも1つの手として存在しています。
ハードも作ってるユカイ工学株式会社では、そういう実装も可能です。


時間が戻って欲しくない
ここが今回の本題なのですが、RTCを持っていない BOCCO emo では、電源が切れれば時刻同期するまで正確な時間が取得できません。
時間が正確かは妥協するとしても、
電源OFF状態からの電源ON時に時間を巻き戻したくない、というのは、組込Linux等を利用した製品では良くある事かと思います。
特にDB系を使い出すと時間の巻き戻りは面倒です。また、ファイルのタイムスタンプを何かに利用した場合、更に面倒です。
だからRTCをつけるという選択があるのですが、やはり電池を入れるというのは避けたいというのもあります。
では、完全回避とまではいかないにしても、時間の巻き戻りの発生を小さくする事は可能なので、それを実装します。

BOCCO emoでは、1から実装するのも面倒なので、Raspberry Pi等で利用されている、fake-hwclock を利用しています。
https://git.einval.com/git/fake-hwclock.git
これで、再起動での時間の巻き戻りを抑えています。

BOCCO emo には、個人的に OpenWrt に組み込める様にしたものを流用しています。
https://github.com/srchack/custom-packages/tree/master/fake-hwclock
少しだけ、修正をいれています。
時刻設定復帰時に、NTPで同期できているなら、上書きをしてしまわない様にしています。(上書きで巻き戻るケースが考えられます。
NTPで取得できる時刻を信じきった実装ですが、まぁNTPが信用できなくなると、そもそも信用できない部分は多いですし。
fake-hwclock 自体は、スクリプトで実装されていて行数も短い(100行も無い)ので、さくさくと読めてしまうと思いますので、製品等に組み込むのは容易かと思います。

ちなみに、fake-hwclock が入っていなくても、ntpclient 等を利用すれば、デフォルト10m間隔で時刻が保存され、再起動等した際には、それ以上戻らない様な動きが入っている様にみえます。
ntpclient を併用する場合、fake-hwclock が干渉してしまう可能性も注意しないといけません。


ファーム初期状態の始まり時刻
OpenWrt 19..07.4 時点では、$SOURCE_DATE_EPOCHが効いていて、利用した OpenWrt の git の最終コミット時間になります。
なので、ファーム次第で初回起動時の時刻は異なります。
ファームのリビジョンを上げていくと勿論、変動していくので、この日時だから初回起動だ(時刻同期できていない)という判断は、危険です。
正しい時刻の状態なのかの判断する材料は存在するので、その判断材料を利用しましょう。


NTPで設定と一言で終わりになる事の多い時刻同期ですが、考え出すと面倒ですね。
みなさんは、製品での時刻同期はどうされていますか?
最近では、セキュリティも気にして、Network Time Security(NTS) をという事もあるのでしょうか?
僕はまだまだ勉強不足ですね。勉強し直します。


今日は今日です、昨日には戻らないのです。Advent Calendar 2020、22日目でした。
次は 悩み中です。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。そして時は動き出す。
23日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] Firewallルールについて書くよ

$
0
0
2020年、Advent Calendarを書いてきました。あと少しですね。
1年以上も開発に関わっているユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。

絵心が無いです。ははは。

今日は、Firewallルールについて。
Firewallルールというと、何の話と考えるでしょうか。
ネットワーク機器の設定、一般家庭では関係無いと思うでしょうか。
BOCCO emo の様な民生品デバイスで Firewallルール の話とかと思われるかもしれません。

ただ Firewallルール といっても、2パターンあるかと思います。
  1. 製品内部のFirewallルールの話
  2. 製品が通信するためにネットワーク機器で必要となるFirewallルールの話


製品内部のFirewallルール
最近は、民生品でも、Firewall を入れておく事が増えているかと思います。
Firewall という程のものでもなく、Linux を入れているのであれば、iptables を入れておく、というか正確には netfilter を入れておくというのが一般的になっていると思います。
ルールとして、内部からは全て ACCEPT、外部からは必要なもの以外は DROP というのが一番容易で、基本内部から外部に対してセッションを張るという考え方で作成してしまうのが、ルールのメンテナンス工数を考えれば多く取られるのではないだろうか。
更に厳密にするなら、内部からも想定されているもの以外を DROP する様なルールを入れる事で、製品としてより堅牢なものにする事が可能になります。
該当製品が、何処まで求めるのかと、開発工数とで、ルールの作りこみ度合いが変動してくる。

また、カスタマイズ系がある製品だと、カスタマイズ毎にルールが変わったりもします。
そのルールの変動に対応する工数を減らすには。という事で、OpenWrt だとどうなのだろうかと、
パッケージ次第ではあるのですが、こういった形でパッケージに Firewallルール を追加処理を入れているやり方があります。
https://github.com/openwrt/packages/blob/master/net/miniupnpd/files/miniupnpd.defaults
1例ですが、この形であればパッケージを入れた状態の場合のみ Firewallルール を追加する事ができます。

と書いておきながら、こちらの Firewallルール について書きたかった訳ではないです。(ゴメンなさい


疎通要件
製品の疎通要件について記載されている事は少ない気がします。
製品の接続要件については記載がされている事は多いのに。
IEEE802.11b/g/n (2.4GHz) という記載であったり、LTE バンド1,3,19 という記載であたりです。

疎通要件で、http(80) が通れば良いのか、https(443) が通れば良いのか、ntp(123) が必要なのか、記載されている製品(民生品)は少なく感じます。
ユーザが知らなくても基本動くから問題ないと済むのが民生品ではあるものの、売り先が企業で利用ユーザも企業となった場合に少し面倒になります。
事務所内での利用となった途端に、Firewall がという話が出てきてしまいます。
場合によっては Proxy がという話が出てきます。(最近は透過の方が多いのですかね?聞かない気がします。

会社のネットワーク管理者の方々は、明確な依頼ベースで対応なのですかね?
導入したい人が、製品開発者に確認ですかね?
導入したい人が、パケットキャプチャして解析ですかね?
偶然通ったからいいや (民生品は、なんとなく通る様に設計しているものが多いですかね。。。

実際に、BOCCO emo だと必要なルールってなんだろうと考えてみると、うーん、と。
  • dns(53)
  • dhcp(67, 68)
  • ntp(123)
  • https(443)
  • websocket(443)
こんなもんですかね。たぶん。
場合により、ポートだけでなく、プロトコル、接続先IP、の情報が必要になってきます。
細かい仕様まである必要は無いのですが、最近製品で mqtt とか使われてて、「ぁぁぁ」という話とかをよく聞くので何とか「ぁぁぁ」が減らせる形にならないのだろうか、と考える日々をすごしています。

製品作っている方々、疎通できるかどうかについて、どれぐらい意識していますでしょうか?
http や https では、通信量やリアルタイム性に欠けるので、mqtt や websocket 等が採用される製品も多くなっていますが、疎通できない可能性が http や https に比べ高いと思われますが、どのように考えていますか?
最悪、http や https へのフェールバックですか?
疎通要件に入れてしまうですか?
443でsslで包んでというのが個人的には開発工数的には考えてしまうのは、甘えですかね。



今日はクリスマス空気周りに漂ってきて独りは寂しいですね。Advent Calendar 2020、23日目でした。
次は オモチャとしてのemo について書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。とおったーっ。
24日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] オモチャとしてのemoについて書くよ

$
0
0
2020年、クリスマスイブです。Advent Calendarも終盤です。
1年も関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。


今日は、エンジニアのオモチャとしてのemoについて。
分解してよりわかるハードウェアの奥深さ | BOCCO emoチームインタビュー
この記事で、オモチャ として遊ぶつもりで クラウドファウンディング した人も居るのでは?と秘かに僕は考えているのですが。(開発に関わっていた立場で期待していいのか?という話は無かったことに
で、emo を標準機能のみで利用する面でなく、オモチャ として遊ぶ面を書いてみようかと。
オモチャとして遊ぶ際に、2段階あると思います。
  1. 公開が予定されている BOCCO emo API を使って、製品をそのままに遊ぶ。
  2. ハード的なカスタマイズキット登場に期待感 (ユカイ工学株式会社のnoteを読んでいる限り、もしかしたらユカイの他製品との連携とか可能性あるのでは?と期待しています。
  3. ハックしてしまう。(クラッキングの話ではないです。(ハックしろという振りでもないです。(挑戦状でもないです。(大切なので3回書きました。
最近、Linux を採用している製品を、手軽にハックして遊ぶ人達が増えましたね。(増えたのか、目立つのか、僕が見ているだけなのか、
僕自身、適当にハックして遊ぶ人なので気にしないのですが、販売側立場に立つとなかなかその点に触れる事のし難い面が多々ありますね。
製品開発に関わっている方々は、どう向き合ってるのですかね。


BOCCO emo API
旧世代機 BOCCO でも API は公開されていました。(未だにベータ扱いでしたかw
BOCCO API 概要
出来る事はそう多くはなかったのですが、まぁ手軽に連携してみるにはちょうど良い位。
Python等を使わなくても、https と json を扱える環境さえ用意できれば、たとえば、curl と jq とかで繋げていけば利用できてしまいます。手軽ですね。

これが、BOCCO emo になると、出来る事が増えるとの話があります。
BOCCO emo API
今まで出来なかったアレとかコレとか期待が膨らみますね。
公開時期がまだ見えないのが残念です。
製品が出荷されてからという形になると目算しているので、物を入手してから待つというスタンスですかね。


ハードウェアのカスタム
ユカイ工学株式会社は konashiとかも出しているので、きっと何かしてくれるに違いないと緩く期待をしています。
可能性は在ると独り考えています。
出たら僕は遊びますね。


Let's Hack (Not Cracking
個人的に一番期待しているのは、こっち方面のオモチャとしての期待値が強いですね。
もともと、僕は製品ばらしたりする人なので、断然こっち側遊びです。
搭載しているSoCが、NXP i.MX8M Mini Lite なので、NXPのサイトで情報が結構揃っているというのは嬉しいですね。
u-boot、Linux、はなんとでもなると考えて、ライセンス品の機能(ライブラリ)をどうしたものかという点が、バラして遊ぶ場合ネックですね。
ただただLinuxがブートできるだけ、では芸が無い。
なら、入っている Linux に対して、機能追加するというアプローチも一つの手段かもしれない。
あまり書き始めると、ハックしたい方が愉しめませんね。これぐらいにしておきます。



今日は世の中クリスマスになってますが、僕は独りです。Advent Calendar 2020、24日目でした。
次は 最終日なので気合を入れて何か を書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。メリークリスマス。
25日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...

[emo] 気になる発熱 / 消費電力 / 通信量について書くよ

$
0
0
2020年の Advent Calendarは、今日で終わりです。
1年も開発に関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。といいながら、赤裸々すぎて赤面してしまった僕ですが、みなさん読んでくれましたでしょうか? (独りAdvent Calendarするつもりは全くなかったのは赤裸々発言です。


emo Advent Calendar 最後の今日は、気になる発熱 / 消費電力 / 通信量について。


このたぐいの製品を開発する時は、ほぼ何かしら考慮が必要に迫られると思うこの3つについて。
  • 発熱
  • 消費電力
  • 通信量

発熱
発熱は、NXP i.MX8M Mini がどうにかなれば、後は積み上げぐらいの感覚でした。
正確には、NXP i.MX8M Mini と LPDDR4 と eMMC の3つですが。。。
eMMCは、write 量が大きくなければ其処までの発熱は起きないです。(ちなみに、eMMC書き込み負荷で、筐体内温度が +4度 ぐらいですかね。
なので、NXP i.MX8M Mini が 1.8GHz で動作している状態で、熱が逃げてくれれば安心です。

が、予想より熱が籠もりました。(穴もなにも無い筐体だったので、ですよねぇ。ぐらいの感覚ですね。
NXP i.MX8M Mini のデフォルトでは、85度でサーマルスロットリングにより、1.2GHzに落とされるので、音声認識の認識速度に影響を及ぼします。
1.2GHzに落ちてから温度が下がるまでの時間が2分ほど、再度温度が上がるのに3分ほど、もっと周波数を下げれば勿論温度は下がるのですが、そのタイミングの音声認識は諦めないといけなくなります。
常時動かなくても良い製品と、常時負荷が掛かってしまう製品で、この辺りの設計/設定は変わってきますが、今回は大きくは下げれないパターンでした。

とりあえず排熱しないと温度が下がらないので、筐体に穴開けてもらって、ヒートシンクがついて、FANがついて、
負荷と温度から、FAN を on/off というありきたりな方法で対策。

本当は、SoCを筐体外側に配置して、カーボンナノチューブとか使って筐体全体に逃がすか、底面に逃げやすくするとかで、FAN無しとかが理想系な気がします。
FANはやはり全体でみれば壊れやすい部類に入りますし、音が発生してしまいますし。
デザインが先行して筐体が先にできて、ハードが後追いになるプロジェクトの辛い処です。
この辺りは、デザイナーとエンジニアの間の変な溝が生み出す変な無駄ですかね。。。
GHz越えると発熱問題からは逃げられないのは、エンジニア側はみんな予想していると思うのですがね。


消費電力
消費電力を抑える、というのは発熱ともリンクしてくるので、発熱を抑えるのと消費電力を抑えるのは同時に考えるケースが多いです。
BOCCO emo の場合、電源コネクタに microUSB を利用しているので、この時点で実機に求められるのは、5V3Aに収まる事。
ここで、消費電力の大きいと予想されるものを上げたところ。
  • NXP i.MX8M Mini Lite
  • XMOS XVF3000
  • Quectel EC21-J
  • Motor
僕は、この4項目を考えていました。
この中でも XMOS XVF3000 は、データシート上は、最大消費電力大きいのですが、codamaで見ていた時から、実測ではかなり低いのは判明していました。
モーターについては、電流引かれるのは仕方ないとして、一番時間を取られると考えていたのは、NXP i.MX8M Mini でした。
当初、バッテリー搭載の計画も存在していたとの事で、如何に消費電力を抑えるかと。

NXP i.MX8M Mini でまず考えていたのが、負荷に合わせて周波数を下げる、バッテリー状態なら1コアを落としてしまう。
NXP i.MX8M Mini であれば、1.2GHz-1.8GHzで変動してくれます。
もっと下げようと思えば下がる気もしているのですが、発熱は下がるのですが、消費電力の差は大きくなかったので、周波数下げるのは発熱を下げて、FAN等を使わなくてよくするという点ぐらいです。
もっと大きく効果があるかと思ってましたが、1.2GHz程度ではという処でしょうか。
i.MX8MMなのに、config では IMX8MQ となっていて、コレ i.MX8MQ の名前は嵌りました。これは、i.MX8M Quad のことだと思うじゃないですか、(抜いたらビルドできないんですよね。。。
config ARM_IMX8MQ_CPUFREQ
        tristate "NXP i.MX8MQ cpufreq support"
        select PM_OPP
        help
          This adds cpufreq driver support for NXP i.MX8MQ series SoCs.

          If in doubt, say N.
1コアころす方はこちらですね。
CONFIG_HOTPLUG_CPU、依存がいろいろ出るので面倒ですが、発熱は大きく下がるのですが、もともと NXP i.MX8M Mini の消費電力が抑えられていたのもあって、期待値ほど効果が見られませんでした。
config HOTPLUG_CPU
        bool "Support for hot-pluggable CPUs"
        select GENERIC_IRQ_MIGRATION
        help
          Say Y here to experiment with turning CPUs off and on.  CPUs
          can be controlled through /sys/devices/system/cpu.
よくやるこれです。
root@emo-xxxxxx:~# echo 0 > /sys/devices/system/cpu/cpu1/online
root@emo-xxxxxx:~# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 16.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

root@emo-xxxxxx:~# echo 1 > /sys/devices/system/cpu/cpu1/online
root@emo-xxxxxx:~# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 16.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 1
BogoMIPS        : 16.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4


通信量
通信量(料)ですが、WiFiだと大抵の場合、ざっくりの見積もりで話が収まることが多いですが、LTE等を利用すると気にされる方が多いです。
通信量で、通信料を気にされますね。
また、通信量を気にするパターンに、2種類あるかと思います。
デバイス側回線視点での通信量、とサーバ側(クラウド側)の通信量。
エンドユーザは主に、デバイス側回線の通信量を気にします。ビジネスよりな繋がりでの場合は、サーバ側(クラウド側)、キャリア回線の通信量を気にします。
どちらにせよ、通信量が小さい方が嬉しいという方が多い気がします。(通信量で稼ぐんだという処は例外ですかね。

また、通信量が小さいと、通信にかかる時間も勿論小さくなる訳で、応答速度の体感が変わってきます。
なので、製品を作る際に、通信量を減らす設計なり開発を行ったりします。
最近では、デバイス側主動での http や https を使った REST API 以外に、MQTT や WebSocket を流用する事が増えているかと思います。
(トンネルを先に作って、トンネルで圧縮とかしてしまうとかいう荒業をしている製品もありますが。。。たしかにそれも手段の1つですが

BOCCO emo では、 WebSocket を併用する事で、応答速度や、通信量削減を実現しています。
MQTT と WebSocket、この2つが世の中的にも候補に上がりやすく、比較検討となるものと思いますが、WebSocket の大きな利点は、企業等で http やhttps を通す設定を行っている Firewall が多いという点でしょうか。WebSocket はポート番号が共通であり、接続フローも同じなので、多くの場合 Firewall を通過する事ができます。
まぁ、企業の場合、セッション時間が長いと切るというのもあるので、その切断に対応しておかないとという話も出てきたりしますが。
企業利用が見込まれる場合に、Firewall の追加設定(申請) 等が不要となるのは、大きなメリットがあります。

メモリの消費量、エンジンの軽量さでいえば、個人的には MQTT が有利だと感じています。(利用する実装により違うので、一概には言えないのですが
マイコンで搭載メモリが小さいのであれば MQTT、ネットワークの疎通を考えて WebSocket という使い分けかなと個人的には考えています。
あとは、サーバ側の構築/運用の手間を考えないといけないですね。
サーバ側の負担は、MQTTの方がラクというのが個人的見解。(最近サーバ側担当しないのでアレなのですが。

あと、MQTT や WebSocket を利用した場合、双方向通信になるので、応答速度の改善度合いは大きいです。
双方向といってもセッションを張るのは、あくまでデバイス側で、トンネルが出来たらそのまま使うというだけですが。
通信量を減らす以外にも MQTT や WebSocket を利用するメリットは大きいです。


emo Advent Calendar 2020、25日目でした。
次は 何かネタになるもの を書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。むきゅっ!
でわ、また ...

アキバぶら歩き(2020/12/26)

$
0
0
月1ぐらいでいいかなとか思い始めた街、秋葉原。
2020/12/26(土)、ぶらぶらした戦利品記録です。

プレミアムステージ
1.8TBのSAS HDD、1人2本までの品。1,800円
また秋葉原行く機会があれば、追加しておきたい。



ウィゲット秋葉原店
ドスパラ秋葉原別館の跡地に、よくわからないお店ができてた。
マスクが税込200円だったり不思議なお店。
ある意味秋葉原感だけど。



40原イラスト展
嫌な顔されなくてもおパンツ見せてもらいたいけど、嫌な顔されながらおパンツ見せてもらいたいドラマCDを買いに、40原イラスト展 見てきました。



嫌な顔されながらおパンツ見せてもらいたいドラマCD、いいですね。
これはいいですね。



くろバニー展
くろバニー展も見てきました。
...

あけましておめでとうございます、今年はがんばります。

$
0
0

明けました。おめでとうございました。
何がめでたいか分かりませんが、2021年が始まりました。

昨年は、Blogの更新も止まってしまっていましたが、今年は動けると思い込んでいます。
ちなみに、丑年なので、牛乳石鹸を出してみましたが、赤箱と青箱の違いってしってますか?
私は、子供の頃は容量が違うことにすら気がついてませんでした。
偶然、昨年入手した際に気がつきました。
調べると、「違い」についてページがありました。一覧になってて違いがわかりやすい。
赤箱と青箱の違い | カウブランド 赤箱 | 牛乳石鹸共進社株式会社

あっ、私、牛乳石鹸さんと何か関わりがある訳ではないです。
でわでわ、今年も@srchack.orgを宜しくお願い致します ...

TinkerOS 2.1.16 までのCodama動作確認しました

$
0
0

Tinker Board S の TinkerOS が昨年ぽつぽつとアップデートが出ているのは気がついていました。
TinkerOS のイメージのダウンロードはこちらですね。なんかURLが昔と変わったみたいですね。
Download - Tinker Board - Asus

その TinkerOS での、Codama の動作確認をしました。
対象は、2.0.11, 2.1.11, 2.1.16 になります。
結果、全て動作問題なしです。
2.1.11だけ、kernelが少し違うので、導入には注意が必要です。


Codama を Tinker Board S で動かすためのコードは、こちらにあります。
https://github.com/srchack/codama-tinker-driver

Tinker OS 2.0.11 以降では、apt 等で導入できる device-tree-compiler では、バージョンが古くてビルドができないので、別で device-tree-compiler を導入しなくてはいけません。
Tinker Board Forumにも同様の問題に対して情報があります。 device-tree-compiler をパッケージから導入している場合は、こういうエラーになってしまいます。
$ sudo make KERNEL_SRC=/lib/modules/$(uname -r)/build all ARCH=arm
dtc -@ -I dts -O dtb -o codama-soundcard.dtbo codama-soundcard-overlay.dts
dtc: invalid option -- '@'
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv]
  -q, --quiet
        Quiet: -q suppress warnings, -qq errors, -qqq all
  -I, --in-format 
        Input formats are:
                dts - device tree source text
                dtb - device tree blob
                fs  - /proc/device-tree style directory
  -o, --out 
        Output file
  -O, --out-format 
        Output formats are:
                dts - device tree source text
                dtb - device tree blob
                asm - assembler source
  -V, --out-version 
        Blob version to produce, defaults to 17 (for dtb and asm output)
  -d, --out-dependency 
        Output dependency file
  -R, --reserve 
        Make space for  reserve map entries (for dtb and asm output)
  -S, --space 
        Make the blob at least  long (extra space)
  -p, --pad 
        Add padding to the blob of  long (extra space)
  -b, --boot-cpu 
        Set the physical boot cpu
  -f, --force
        Try to produce output even if the input tree has errors
  -i, --include 
        Add a path to search for include files
  -s, --sort
        Sort nodes and properties before outputting (useful for comparing trees)
  -H, --phandle 
        Valid phandle formats are:
                legacy - "linux,phandle" properties only
                epapr  - "phandle" properties only
                both   - Both "linux,phandle" and "phandle" properties
  -W, --warning 
        Enable/disable warnings (prefix with "no-")
  -E, --error 
        Enable/disable errors (prefix with "no-")
  -h, --help
        Print this help and exit
  -v, --version
        Print version and exit

Error: unknown option
Makefile:21: recipe for target 'codama-soundcard.dtbo' failed
make: *** [codama-soundcard.dtbo] Error 1
使用されている Kernel が 4.4.132+ となっている 2.0.11 と 2.1.16 では、linux-headers-4.4.132+_4.4.132+-1_armhf.deb を使用する事が可能です。
これは、TinkerBoard の github から入手できます。
https://github.com/TinkerBoard/debian_kernel/releases/tag/2.0.8
これを入れた後に、dtc をパスの通った場所に配置してください。
$ sudo cp -p /usr/src/linux-headers-$(uname -r)/scripts/dtc/dtc /usr/bin


Tinker OS 2.0.11 と 2.1.16 については、linux-headers-4.4.132+_4.4.132+-1_armhf.deb が利用できるので良いのですが、
2.1.11 だけが何故か異なります。2.1.11 の uname の結果はこうなっています。何故か "+"がついていないのです。
$ uname -a
Linux tinkerboard 4.4.132 #1 SMP Thu Mar 5 07:47:01 UTC 2020 armv7l GNU/Linux
2.0.11 と 2.1.16 ではこうなります。
$ uname -a
Linux tinkerboard 4.4.132+ #1 SMP Wed Aug 21 19:15:55 CST 2019 armv7l GNU/Linux
$ uname -a
Linux tinkerboard 4.4.132+ #8 SMP Thu Aug 13 08:51:08 UTC 2020 armv7l GNU/Linux


おそらく、4.4.132+ の dtc を持ってきてもいいのですが、少し気持ちが悪いです。
真面目に、Kernel source を持ってきて、ビルドを通すのを今回行いました。
linux-headers パッケージが無い場合には、こういう手順になりました。

開発系パッケージ追加
$ sudo apt update && sudo apt install -y git-core build-essential bc libssl-dev
Kernel ソースコードの入手、イメージバージョン毎に tag は一応着いていそう。
$ wget https://github.com/TinkerBoard/debian_kernel/archive/tinker_board-debian-2.1.11.tar.gz$ tar zxf tinker_board-debian-2.1.11.tar.gz
dtc をビルドする。(Kernel のビルドをしてしまうと時間が勿体ないので、scripts のみビルドを通す)
そして、dtc をパスの通った場所に配置。
$ cd debian_kernel-tinker_board-debian-2.1.11/$ make ARCH=arm miniarm-rk3288_defconfig$ make ARCH=arm -j6 scripts$ sudo cp -p ./scripts/dtc/dtc /usr/bin
Codama のモジュールを作る時に必要なヘッダーファイル系の準備 (たぶんコレでいいと思ってる)
$ make ARCH=arm -j6 modules_prepare
$ sudo rm /lib/modules/$(uname -r)/source$ sudo ln -s ~/debian_kernel-tinker_board-debian-2.1.11 /lib/modules/$(uname -r)/source$ sudo rm /lib/modules/$(uname -r)/build$ sudo ln -s ~/debian_kernel-tinker_board-debian-2.1.11 /lib/modules/$(uname -r)/build
あとは、ここ
の README.md に従えば導入できます。

codama_i2c 等のユーティリティについては、ユカイ工学さんの github で公開されているものが利用できます。
https://github.com/YUKAI/codama-doc-r0/
ただし、i2cデバイス番号が異なるので、古いのもを入手する必要があります。
commit id が cf0ad5e8f50b3e34bb9ffd5a24dcef61ffbc04a2 の時のものが必要になります。


Raspberry Pi 4Bで、メモリも増えたため、あえて Tinker Board S を利用する事は減っている気もします。
ライセンスや、ボードの保証等を考えると、商用利用であればまだありそうとも言えますが、
既に、Tinker Board S の後継である Tinker Board 2、Tinker Board 2S が発表されていますし、Tinker Board S 自体は収束方向ですかね。
Tinker Board 2Tinker Board 2Sは、お値段しそうなので、運良く入手できたら対応しますかねぐらいの気持ちで ...

Shigezone で買った SRW-710S 使ってます

$
0
0

Shigezone で買った SRW-710Sでラジオを聴いてる正月。
いえ、ラジオを聴かなくなってしまったなと。常にラジオをつけていた人だったんですがね。
この SRW-710S、購入したのは昨年8月みたいですね。
まだICを交換しなくても、抵抗つけるだけで、日本のFM放送に対応できた頃のです。
どうやら、ぎりぎりIC交換不要だったタイミングの様です。

短波を聴くかといわれると、聴かないし、AMを聴くかといわれると、それも聴かないのだけれども、なんとなく流行ってるから買った的な。。。
でも、正月にTV見る気にもならず、便利でした。
それにしても、関東って入るFM局すくないですよね。。。大阪っていっぱい入るんですよね。。。
関東着てから、TOKYO FM ぐらいしか聴かない。


で、Shigezone で買ってきていた SRW-710S です。
もう有名すぎて、何も説明が要らないですね。
どれだけ売れてるんだろう。。。
機能的にも、MP3再生できたり、ラジオ録音できたり、いろいろ付いてるのですが、ラジオ聴くぐらいにしか使いませんね。
ほんと、これである必要ないのですが、人気ありますよね。(なぜ改造が必要なラジオが売れるのか。。。


Shigezone さんでは、改造部品の1kオームの抵抗が付属しています。
秋月や千石に寄る必要がないですね。
部屋のどこかに眠っている1kオームの抵抗を探す手間も必要ありません。
2個ついてますが1個しか使いません。(作業時に無くしたとき困らないようにという配慮でしょうか。


いたって普通のラジオですね。
こんなものを何故3,000円出して買うんですかね?僕らは


とりあえず、TOKYO FM が聴けないので、ぱかっとなぁ。


R10に抵抗取り付けて終わり。(付けた後の写真とってないや
閉じてしまったし、開け閉めしてたらプラが痛むし、SRW-710S 有名すぎて、写真いくらでも見つかるし、いいや。


正月は、TOKYO FM 聴いてます。



そうそう、なんか知らない周波数でなにか流れてるんですよね。
ミニFM局かな?
ちょっと気になる。そんな2021年正月のとある ...

HDMI→USB2.0ビデオキャプチャ

$
0
0

これも、Shigezone で購入したものです。
HDMI→USB2.0ビデオキャプチャ、880円。
前からUSB 3.0のキャプチャも持ってるのですが、小さくて鞄に入れておくにはいいかなと。(気の迷いです
いえ、モニターつけてないデバイスが多いもので、たまにモニターが欲しいだけなのに、モニター用意しておくのも机が狭くなるので、

Windows, MacOS, Linux で使う場合は、OBSを入れればとりあえずは困らなさそう。
UVCで認識するので、USBカメラのアプリなら使えるのがほとんどだけど。
Amazon Kindle Fire の時に何を入れればいいのかな。と、
USB/Web Cameraというアプリが使えました。
もう少し使いやすいアプリないのかな?とは思いつつ、探すのに時間取るのもアレだし妥協。

で、使ってみました。ESXiの開発機とか普段はモニター繋げてないんですよね。
ほんと、便利。
あとは、キーボードがノートPCのをBTキーボードエミュレーションする様なのがあればキーボードも持ち歩かなくて良いのですが。


起動時のLenovo画面から出てますね。
BIOS画面も出るので、これでモバイルモニターを持ち歩く必要がなくなりました。
こうなると、7インチとかでそれなりに解像度のあるタブレットが欲しくなりますね。


...

アキバぶら歩き(2021/01/09)

$
0
0
行くのは最低限でいいかなと思い始めた秋葉原。
2021/01/09(土)、ぶらぶらした戦利品記録です。

じゃんぱら
子供向け10.1型タブレット BENEVE M1031G
税込3,980円。
解像度が1920x1200だし、いいかなと。
どうせ、子供向けカバー付きタブレットと考えたらいいんでしょ?
MT8163なら、まぁいざとなればオモチャにと。

8.1のファームウェアがあるとか見えた気もするけど、そうでもなかった。
ファームウェアをなんとかちょっと変えたい。(まぁ寝て考えます。


ML COMPUTERS
iPhone 6s 64GBモデル 税込7,500円。128GBモデルは既に売れてしまってた。
SIM Freeなので、安いSIM刺します。
あと、iPhone 5sはもぅ無理です。

状態綺麗です。
iPhone6sだから、iPhone6の頃のケースが使えてよかった。
フィルムをどこからか安く買ってこないと。。。


千石電子通商
500円ジャンク詰め合わせ袋。
どう考えても要らないものが一杯。


M5Stack Grayが入ってたけど、書き込みが失敗する。
シリアル変換は見えてるし、電源刺したときに電流は喰ってるし、なんだろうなぁ。と悩み中。


マルチツール。
この類は嬉しい。出先でドライバー欲しくなる事多いですよね。
普通にドライバーぐらい持ち歩いてるでしょ。という人が多いですが、まぁ、鞄持ってないときにね。


導電性のインクなのかな?
よくわかりません。



プレミアムステージ
1.8TBのSAS HDD、1人2本までの品。1,800円 また秋葉原行く機会があれば、追加しておきたい。
...

アキバぶら歩き(2020/03/21)

$
0
0
月1ぐらいでいいかなとか思い始めた街、秋葉原。
2020/03/21(土)、ぶらぶらした戦利品記録です。

パソコン工房 秋葉原アウトレット館
Windows 10 Proのまま使うかわからんが、10 Pro搭載機。
キーボードPC II -Pro Edition-(WKA-W10PBK)



スペック見る限りは、タブレットと変わらん。


まぁ。
タブレットとさほど変わらん。
打ちやすさを求めてはいけません。


必要なインタフェースは揃ってそうな感じはありますね。


つくもたん

99Magazine vol.4を入 ...

2020-03-31, 最終出社予定日を終えました。

$
0
0
昨日、最終出社予定日を終えました。
昨年7月に会社と話して半年以上かかってます。
とりあえず、ビール呑みたい。
...

アキバぶら歩き(2020/05/02)

$
0
0
月1ぐらいでいいかなとか思い始めた街、秋葉原。
2020/05/02(土)、ぶらぶらした戦利品記録です。

とある自販機
サンドイッチ。



PREMIUM STAGE
500円のLTEモジュール。ジャンク品。 と、microUSBカードリーダー、typeCとかmicroUSB対応の奴。
Macbook Airを入手したので、typeC対応したのが欲しかっただけですね。



ヨドバシカメラ
無線を有線に変えたくて、とりあえず入手してみました。
いまいちでした。ざんねん。



シルバーガレージ
いまだにiPhone 5Sなのですが、バッテリーが駄目なようなので、バッテリー交換してきました。
スマホに興味がもうないのですよね。
とりあえず、しばらく延命できればいいかぐらいのつもりです。
自分で交換するのも値段変わらんなぁ。と店に行ってしまいました。
とりあえず、30分かからないので、店前で作業見てるといいと思います。

一日バッテリーが持つっていいですね。
永らくなかった感覚で ...

アキバぶら歩き(2020/12/07)

$
0
0
月1ぐらいでいいかなとか思い始めた街、秋葉原。
2020/12/07(月)、ぶらぶらした戦利品記録です。
振替休日をとって、月曜日廻りが働いているのに行く秋葉原いいですね。

書泉
いえ、Amazonで買えないので。。。
RFワールドって、そんなに即無くなるほど人気雑誌でしたっけ?
書泉には一杯ありましたが。。。

NanoVNA初心者なので、これ読んで勉強します。


Shigezone
前々から欲しかったのです、HDMIキャプチャ(UVCに見えるやつ)。
880円。もう1個あっても良かったかも。

もう少し性能まともなヤツは実は既に持っているのだが、コレ意外と使いやすいかもw


つくもたん ex. (つくもたん居ないけど)
DELLのミクモデルを買おうかひたすら悩みながら未だに買えてない。。。
ツクモマガジンとカレンダー貰って終了。



ライザの太もも
なんか説明要らない気がする。太もも。(いや、写り込み激しすぎてあはは

...

有休消化 1週目 棚から一掴み

$
0
0
有休消化で棚から一掴み。
一掴みというか、本棚に収まってないモノを消化すべく一撮みですかね?
はじめの1週目は、こんな5冊。軽めから始めました。
  • 本の雑誌432号2019年6月号
  • 社畜男はB人お姉さんに助けられて――(1)
  • 太秦荘ダイアリー
  • まんがではじめるKubernetes
  • まんがではじめるKubernetes2
「社畜男はB人お姉さんに助けられて」 は新たにAmazonで買ってしまった。 (こんなB人お姉さんに僕も助けられたい。

...

有休消化 2週目 棚から一掴み

$
0
0
有休消化で棚から一掴み。
一掴みというか、本棚に収まってないモノを消化すべく一撮みですかね?
はじめの2週目は、こんな3冊。
  • 太秦荘ダイアリー(2) 三人娘、探偵になるっ!
  • 社畜男はB人お姉さんに助けられて――(2)
  • Interface 2021年 2 月号
僕もB人お姉さんに助けられたぃ。

Viewing all 1089 articles
Browse latest View live