2024-05

Single Board Computer

ハードウェア的に遊べるSBCってどんなもんかなと考えていたのですが、現状ではx86-64を扱おうとする限り、ペリフェラルとの通信にはUSBを使うしかないのだ、という結論になりそうです。中央となるSBCでARM 64bitを使うにしても、その中央となるCPUの時間をウエイトで無駄にするわけには行きません。 CPU に直結された GPIO があってもLED点滅ぐらいにしか使えないというのが基本的な考え方です。 USBペリフェラルを設計する技術を持っておいたほうがハードウェアで遊ぶには便利なんだろうなと思います。オンボードのI2Cはカーネルが占拠していて扱いが難しいため、 I2CはPICなりAVRなりに生やした先にあるものを使うことになるでしょう。

チャットボット

チャットボットが吐き出すテキストは良くも悪くもワードサラダでしかありません。

チャットボットには思考するロジックが与えられているわけではありません。与えられた言葉の次に来る言葉を確率的に繋いでいるだけです。メーカ側は試用者が白昼夢を見てくれることをおおいに期待している雰囲気があります。擬似的な思考を演出することができると考えれば夢も希望もあるわけですが、それでもって機械が思考をしていると決定することはできません。
チャットボットは言葉の正確性を検討しません。たとえば電子回路について問うたとして、その電子回路の科学的な論理構成を推敲することもありません。現時点では、チャットボットの回答には、大量のうそが入り込みます。
悪用防止策が採られていると言われますが、そうするのが初手なのであって、昨今ようやく実現したというのが現在の状態でしょう。彼らもビジネスですから一般公開することを何よりも優先したはずです。ということは、一般公開とそのビジネスに必要でないことは実装されていないと見るべきです。

少なくとも一定の程度の正確性を備えるまではチャットボットを調べ物に使うのはやめたほうがいいだろうと考えています。対話することで思考力が鍛えられるという論説が一部にありますが、それは幻想なのではないでしょうか。チャットボットにアクセスした結果としてチャットボットが思考しているように見えるかも知れませんが、それはアクセスした人間が見た幻でしかないのです。まあゲームプレイをしているのと同じようなもの、と考えておけばいいのでしょう。

キーワードを与えれば類似するキーワードを返す、それだけでよければ実用性が見込めます。各社サポートサイトではそういった使い方を模索しているように見えます。

いずれにせよ、人工無能がここまで進化したことについては、素直に喜ぶべきことなのかも知れません。自治体が示す基準に従ったゴミの振り分けすらできない現状においては、実用には程遠い気がしなくもありません。まあ10年後に実用になっていれば御の字でしょう。

Linux vs. BSD

私が知る限り、BSDを使う理由としては、おおよそパケットフィルタとZFSに絞られるようになってきました。特にNetBSDは大手メーカのサーバ機種では動作しないことが多くなったため、そのような用途ではFreeBSD等を頼らねばなりません。現時点ではBSDをビジネスに使う動機はほとんどないと考えています。

AVR-LibC

最近のデバイスをサポートするコードにはMicrochip社のコピーライトが付されています。そこではPIC16系のライブラリと異なり「ソフトウェアを使用したければ純正のデバイスを使用すべし」という感じの奇妙な条項はありません。当時の事情としてPIC16系ではそれを真剣に心配したのでしょう。このあたりは時代の変化を感じるところです。

さて、コミュニティ版のavr-libcにもAVR64DU28/32のサポートが入りました。といってもレジスタ定義が記述されたヘッダファイルとcrt0相当のコードが追加された程度のように見えます。レジスタを叩くことが主体になるのでCのライブラリとしてはそれでいいのだろうと思います。 USBまわりは実装がややこしいので、かなり勉強しないといけなさそうな感じがします。

avr-libcをビルドしてみましたが私が知る限りAVR DUに対応させるには若干修正してあげないといけないようでした。コミットされてから誰もコンパイルと検証まではしていないということなのか、私のやり方が悪かったのか、どちらなのかはわかりません。こんなことを書くと純正のMPLAB Xを使えと言われそうですが……。

$ git diff
diff --git a/devtools/gen-avr-lib-tree.sh.in b/devtools/gen-avr-lib-tree.sh.in
index 7fe451e3..70a7cea2 100644
--- a/devtools/gen-avr-lib-tree.sh.in
+++ b/devtools/gen-avr-lib-tree.sh.in
@@ -420,8 +420,8 @@ attiny40:crttn40.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS}\
 "
 
 AVRDX_DEV_INFO="\
-avr64du28::${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-avr64du32::${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+avr64du28:crtavr64du28.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+avr64du32:crtavr64du32.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
 avr32da28:crtavr32da28.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
 avr32da32:crtavr32da32.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
 avr32da48:crtavr32da48.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\

GCC 14.1

GCC 14.1がリリースされたのでクロスコンパイラの更新をします。目玉となる機能はAVR64/128サポートだと考えています。おおよそ、サードパーティのパッケージに頼らずにAVR DDが使えるようになったのです。 MPLAB Xなどに統合されるベンダツールを使っても良いのですが、そのベンダツールでないとコンパイルできないソースコードになってしまう可能性が高いため、汎用性を求めるなら純正のGCCで対応できたほうがベターですし、そのほうが利用者としても有り難いだろうと思います。

GCC 14からAVR64/128においてもrodataをフラッシュメモリにマッピングできるようになりました。 sizeコマンドで見ても文字列定数を持つポインタ変数を定義をしたときポインタ分しかRAMを消費しません。これが32KiBのセグメントを予約することで成立しているのかどうかは、コードメモリを詳しく調べないとわかりません。 objdumpしてみたのですが、ぱっと見でよくわかりませんでした。 Intel Hexファイルを解析したほうが良かったかも。

何もしないプログラムを用意してみると、最小限度のランタイムが200バイト前後になるようですね。

AVR

最近のAVRにはexternal bus interfaceに対する配慮がありません。 PICにあるparallel master port的なものがあっても良さそうな気がしますが、最近のAVRにはありません。 Z80系のペリフェラルを叩きたければPIOを使えということなのでしょう。 4MHzがせいぜいのバスを20MHzのAVR CPUが叩くことを考えればPIOで十分なのかも知れません。それならそれで、速度差を埋めるためのペリフェラルが欲しいのではないか、という気がしなくもありませんが。

Fedora 40

見事にibusがバグってるのだけども、このバグは作者の手元で年単位で修正に梃子摺っているらしいので、簡単には治らないらしい。

https://github.com/ibus/ibus/issues/2610