Sync Controller - 有線バージョン ver. 2

2021年9月11日 16:19

#SyncController のうち、現在評価中の有線バージョンで、いろいろ調べたり試したりしているうちにいくつか問題があったので、早くも全面バージョンアップに踏み切る構えで。

1. メモリが足りない

いや何とか現状でも動いてはいるのだけれど、たぶん問題ないのだけれど、でもビルド時のメモリマップが

Post-Build: LTCSyncControler
| Module                 |     .text |     .data |      .bss |
|------------------------|-----------|-----------|-----------|
| DS3231\DS3231.o        |   580(+0) |     0(+0) |     0(+0) |
| LTC_SMPTE\LTC_SMPTE.o  |  1432(+0) |     0(+0) |     4(+0) |
| TextLCD\TextLCD.o      |   766(+0) |     0(+0) |     0(+0) |
| [lib]\c_w.l            |  6220(+0) |    16(+0) |   392(+0) |
| [lib]\fz_ws.l          |  2758(+0) |     0(+0) |     0(+0) |
| [lib]\libcpp_w.l       |     1(+0) |     0(+0) |     0(+0) |
| [lib]\libcppabi_w.l    |    44(+0) |     0(+0) |     0(+0) |
| anon$$obj.o            |    64(+0) |     0(+0) |  1024(+0) |
| main.o                 |  3617(+0) |     0(+0) |   708(+0) |
| mbed-os\cmsis          |  9612(+0) |   168(+0) |  6610(+0) |
| mbed-os\connectivity   | 52661(+0) | 24867(+0) |  2246(+0) |
| mbed-os\drivers        |  1782(+0) |     0(+0) |     0(+0) |
| mbed-os\hal            |  1484(+0) |     4(+0) |    59(+0) |
| mbed-os\platform       |  6517(+0) |    64(+0) |   356(+0) |
| mbed-os\rtos           |   502(+0) |     0(+0) |     8(+0) |
| mbed-os\targets        |  3928(+0) |     4(+0) |   441(+0) |
| ntp-client\NTPClient.o |   510(+0) |     0(+0) |     0(+0) |
| Subtotals              | 92478(+0) | 25123(+0) | 11848(+0) |
Total Static RAM memory (data + bss): 36971(+0) bytes
Total Flash memory (text + data): 117601(+0) で。ytes
Image: BUILD/LPC1768/ARMC6\LTCSyncControler.bin

で、mbed LPC1768つまりすべてをつかさどる小さなコンピューターのスペックが

FLASH memory - 512KB
RAM - 32KB

なわけですが。あれ？メモリマップでは36KB弱になってまんがな！

この24KBもRAM食ってる(実際に全部同時に使っているとは考えにくいのだけれど、要はこれだけ確保しているということ)モジュールはネットワーク関係で、まあさもありなん、なんだけど、それにしても32KB中26KB使ってると他の部分では使いにくいし、これ以上別のライブラリ足すのも難しい。

のが課題の一つ。

2. MAC アドレスが振られてない！

これは実際に２つ動かしてみてびっくりしたのですが、イーサネットインターフェースICが載っていて、コネクタとパルストランスを足しただけでライブラリからも普通に使えているのに、2個目をおなじLANにつなぐと

同じMACアドレスのデバイスが同一サブネット上にある！

ってルーター(兼DHCPサーバー)から叱られたんですね。で、調べると、なんか決め打ちの値が適当に？入っていると。どうやらどこにもMACアドレスは持ってなさそう。まあこういうワンチップマイコンあるあるなんだろうけど。

とまあこれが２つめ。

3. 不揮発性メモリがない！

で、しょうがないからMACアドレスを調達して(これができるんですがw 方法はまたのちほど)、FLASHのどこかにファイルで書き込んどけばいいかなと思ってやってみたら、FLASHのファイルシステムをアクセスするたびに例外が起きてしまう。どうやらプラットフォームに使っているmbed OS(リアルタイムOS)のバグらしい。違うスレッドにしないとだめとか。まあめんどくさいこと。

それに、MACアドレスはそうそう書き換えてもらっても困るので、ほんとはEEPROMかなにかに書き込んで、ユーザーからは見えないようにしたかったんだけど、このボード上にはEEPROMが載ってない。SPIかなにかでアクセスするチップを別付けしなければならない。

というこれが３つめの理由なわけだ。

ということで、まあRAM不足の問題がどうにもなんないのが一番の理由で、

LPC1768は見捨てる！

ことにしました。で、https://os.mbed.com/platforms/ を探していると、なんとこの mbed LPC1768 ボードのピン互換でさらにハイスペックなボードがあると！これ前からあったのかな、気づかなかった。

つまり試作評価中のハードウェア(箱)の中身をそのまんま挿げ替えられると。うわあこんなつごうのいいことががが！w で、懸案のRAMは200KBあるし、FLASHとは別にEEPROMもついてるし、いうことありませんな、ちゃんと動けばw

ただこいつ秋月アマゾンはもちろん、 mouser とか digikey にも売ってない。売ってるのはこの作ってるところのWebのみ。ちょっと供給に不安がありますが、でも、なに？スロベニア？すぐそこじゃん！w ということで注文してみました。一応4日でつくという見積もり。この辺にしちゃ劇速いほう。

まあこれで評価してみて、入手性が問題になるようならまた検討しましょう。困った時のAliexpressとかねw

ロードマップ

で、Facebookとかにもいろいろ書き散らしながら、今後の機能拡張も考えてみたけれど、

- まず↑のボードに載せ替え
- MACアドレス対応
- 外部高精度クロック対応 (24/19.2MHz切り替え)
- ネットワーク設定の書き込み・保存

は大前提として、

- HD Tri-Sync / Audio 基準クロック生成

をちょっと考えたい。Tri-Syncがどれくらい難しいかはまだプロトしてみないと何ともだけれど、これで絶対時間タイムコード・HD Tri-sync・ワードクロックが一つでそろえば、同期系のシステムとしては完結できるから！まあその３つを出す製品はあるにはあるけど、20万越えとかだし、かつ「絶対時間同期」はどれもやってくれない。ということで、その辺めざしていきたい。

[追記] mbed Webサイトの嘘つき!

と書いてはみたものの、「動いてる」現状に納得がいかない。なんでやねんな。ということで、オリジナルのNXPのデータシートを見てみたら、

先生！RAMは64KBって書いてますが！！！

mbedのサイトでは

32KBってでかでかと書いてありますがががが。

嘘つきめw

そしてメモリマップはこちら。LPC1768で有効なFLASHとRAM部分をマーキングしてみた。

なるほど、RAMは3つのアドレスに分かれて実装されているようだ。最初の32KBが0x10004000から、次の16KBが0x2007C000から、連続して16KBが0x20080000から。で、ビルドした後のメモリマップを見てみると、

Execution Region RW_IRAM1 (Base: 0x100000c8, Size: 0x00002bdc, Max: 0x00007f18, ABSOLUTE, COMPRESSED[0x0000005c])

最初の11KBがグローバル変数や固定バッファとして確保されたエリア(詳細省略)、

Execution Region ARM_LIB_HEAP (Base: 0x10002cb0, Size: 0x00004f30, Max: 0x00004f30, ABSOLUTE)
Base Addr    Size         Type   Attr      Idx    E Section Name        Object
0x10002cb0   0x00004f30   Zero   RW            1    ARM_LIB_HEAP.bss    anon$$obj.o

が20KB弱のヒープ領域つまり動的確保メモリ用、

Execution Region ARM_LIB_STACK (Base: 0x10007c00, Size: 0x00000400, Max: 0x00000400, ABSOLUTE)
Base Addr    Size         Type   Attr      Idx    E Section Name        Object
0x10007c00   0x00000400   Zero   RW            2    ARM_LIB_STACK.bss   anon$$obj.o

がスタック領域(0x400 = 1KB)となって最初の32KBを使い切り、

Execution Region RW_IRAM2 (Base: 0x2007c000, Size: 0x00004000, Max: 0x00004000, ABSOLUTE, COMPRESSED[0x00000084])
Base Addr    Size         Type   Attr      Idx    E Section Name        Object
0x2007c000   0x00003fff   Data   RW         5790    AHBSRAM0            BUILD/LPC1768/ARMC6/mbed-os/connectivity/lwipstack/lwip-sys/arch/lwip_sys_arch.o

が後ろの前半16KB - これはIPスタックのバッファですかね、

Execution Region RW_IRAM3 (Base: 0x20080000, Size: 0x000020bc, Max: 0x00004000, ABSOLUTE, COMPRESSED[0x00000044])
Base Addr    Size         Type   Attr      Idx    E Section Name        Object
0x20080000   0x00000718   Data   RW         3630    AHBSRAM1            BUILD/LPC1768/ARMC6/mbed-os/connectivity/drivers/emac/TARGET_NXP_EMAC/TARGET_LPCTarget/lpc17_emac.o
0x20080718   0x000019a3   Data   RW         6322    AHBSRAM1            BUILD/LPC1768/ARMC6/mbed-os/connectivity/lwipstack/lwip/src/core/lwip_memp.o

が最後の16KB(使っているのは8KB)、という感じで確保されている。最初がLANドライバのバッファ、後ろはまたプロトコルスタックのバッファ、という感じだろう。

また、実際に静的に割り当てられるメモリは

11KB + 1KB + 16KB + 8KB = 36KB

となって計算と合っている。

いずれにしても、当たり前だがちゃんと64KB内に収まっている。また前半32KBの大部分を占めるのはヒープなので、もしメモリが足りなくなったらmallocがエラーで返る→たぶん例外が起きる(もしくは何かをあきらめる)だけなので、メモリ上書きされて知らん顔とか、書けないところに書きに行く、ということもない。まあ今どきのリンカーだから当然だよな。

また後ろ側16KB + 16KB は連続してアクセス可能かどうかはわからないのだけれど、もし可能だったらリンカーに入力する設定ファイルで32KB連続で使えると記述したほうがメモリ効率はいいはず。これはどうなんだろう、またがってアクセスできないのだろうか？もう少しデータシートを読み込んでみる。

ということで、メモリ上は実は問題なさそうなのだった。なあんだ、注文しちゃったよー。でもいろいろ機能追加すると溢れそうなのは確実だから、まあいっか。

サポート Welcome! いただいたサポートは今後の研究開発や寄付に使わせていただきます。