グローバル変数をuint_16で宣言していた。それを異なるファイルでextern intで参照してしまった。32ビットマイコンなので、intは32ビットである。当然、おかしなことになる。
今までこの手の間違いはやったことはない。externで参照する時には、必ずもとの宣言をコピーして使っていたからだ。ところが、今回に限ってなぜかこんなことをしてしまった。
　半日ほど無駄にして、なんでコンパイラが検出してくれないんだ、と思ったのだが、コンパイラで検出できるはずはない。ファイルをまたがる変数はリンカの仕事だからだ。でも、リンカの仕事は、基本はアドレスの解決である。この手のミスのエラーメッセージを期待するのは間違っている。C言語は、本当にやっかいである。

　PIC32でソフトウエアをせっせと書いていたら、ビルド時に

small-data section exceeds 64KB; lower small-data size limit (see option -G)

というエラーが出てきた。対処法は簡単で、XC32のoptionにあるUse GP relative addressing thresholdの値を変えることである。デフォルトが8なのだが、4とか2とか、なし、とかに変更するのである。
　私の場合、なし、にしないと、ビルドできなかった。
　これはこれでいいのだが、このオプションが何なのかがわからないと気持ち悪い。https://microchipdeveloper.com/faq:3434によると、どうやら、MIPSには、64Kバイト以下なら1命令でアクセスできるGP relative addressingというアドレッシングがあるので、小さい単位の変数を、ここに格納するということで、実行時の速度を上げるというようになっているようである。
　デフォルトの8だと、long型でも格納できるので、実数以外の通常の変数は、全てこの領域に格納してしまおう、ということなのだろう。
　私のソフトウエアも、自分の書いたコードは、配列とかstruct以外の変数が全部で64Kバイトを超えるような大きなソフトウエアではない。でも、TCP/IPのスタックとか、マイクロチップ社提供のライブラリーをかなり使っているので、そちらの方で消費してしまうのだろう。
　でもまあ、今開発している機器で、PIC32を選択した理由は、512KバイトのRAMを使えることだったので、このオプションを使えないのは当たり前ということである。

　ソフトウエアのホワイトボックステストをする際に必要なツールがコード・カバレッジ・ツールだ。C0とかC1とか、テストのカバレッジの定量基準もある。でも、実務上重要なのは、C0とかC1とかの数値を100%にすることではない。とても、ありえないようなテストパターンを追加しないと100%にならないことが多いからだ。そんなことに時間を費やすなら、非機能要件のテストに時間を費やす方が、品質に貢献すると思う。
　実際には、実行されたコードを見て、エッ？ここがテストされてないの？と開発者が気づくことで、大きなバグを免れるというパターンが一番有効なのではないか？と思っている。
　でも、組み込みでは難しい。どの経路を通ったかというログを、実メモリーに残し、それをツールが吸い上げ、表示するという複雑な処理が必要だからだ。マイクロチップ社が、MPLAB Code Coverageというツールを発表した。是非使いたいと思っていたら、有償オプションだった。しかも、無料で一定期間お試しという評価版もない。直販ショップの価格で、9万円弱なので、ホビー用途には使えない。小さな企業だと、何も評価せずに、とりあえず買っておこうというレベルの金額でもない。せめて、評価版を用意してほしい。

　今、PIC32を使おうとしている。PIC自体は、昔から使われている便利なマイコンである。ちょっとした回路を組むよりも、PICで、という用途に使われてきた。
　PIC32は、マイクロチップ社のマイコンの32ビット版で、今までのPICコアとは全く互換性のないMIPSコアである。このARM全盛の時代にMIPSコアを使うのもどうかなあ？という躊躇はあるのだが、まあいいだろうと思っている。アセンブラで開発していた時代と異なり、C言語でほとんどの開発ができるので、CPUコアはあまり気にならないからだ。コンパイラがしっかりしていれば、それでOKだ。そういう意味では、MIPSは、昔からあるコアなので、コンパイラは枯れているだろうと期待している。