28-Feb-2026
[OpenGD77の(3)]

opengd77-noxpressoは全てのソースを-Osで最適化するという方針でいるのですが、現状はdrivers/fsl_dspi.cに限り最適化無し(-O0)としないとうまく動きません(以前は-Osでも問題なく動いていたような…?)。公式(MCUXpresso)版においては-O0であるため、無理にfsl_dspi.cを-Osに対応しなくても良いと言えるものの、Arm GNU ToolchainではなくDebian-13のarm-none-eabi toolchainではnewlibではなくpicolibcを使わないとROMに収まらなくなってしまうので、可能であれば対処したいところです。

MCUXpresso IDE v24.12(gcc-13)以前でないと送信時に音声が乗らない問題に関しては、Readme.mdの「Most likely some difference in the compiler handling of calls to the codec bin blob」という記述に従い、source/dmr_codec/codec_interface.cを徹底的に見ていました(binutils-arm-none-eabi-2.44のbl <label>対策もあります)。しかしこれをいくらいじっても解決しなかったため、gcc-13/gcc-14で生成した.oを混ぜてリンクする→動作を試す、という泥臭い方法で対象の絞り込みを行って、firmware/interfaces/i2s.cの以下の箇所に問題があることを突き止めました。


sai_transfer_format_t SAI_RX_format;
SAI_RX_format.sampleRate_Hz = kSAI_SampleRate8KHz;
SAI_RX_format.bitWidth = kSAI_WordWidth16bits;
SAI_RX_format.stereo = kSAI_Stereo;
SAI_RX_format.masterClockHz = 512 * SAI_RX_format.sampleRate_Hz;
SAI_RX_format.watermark = NUM_I2S_BUFFERS;
SAI_RX_format.channel = 1;
SAI_RX_format.protocol = kSAI_BusI2S;

このコード、一見変わったところが無いように見えますが、

という問題が潜んでいます。初期化されていないchannelMaskの値に依存して送信時に音声が乗るか乗らないかが変わり、kSAI_ChannelMask1ではなくkSAI_ChannelMask0を設定すれば音声が乗ることが分かったので、channelに設定すべき値は0と判断しています。

という訳で、これで解決しちゃいます。


sai_transfer_format_t SAI_RX_format = {
	.sampleRate_Hz = kSAI_SampleRate8KHz,
	.bitWidth = kSAI_WordWidth16bits,
	.stereo = kSAI_Stereo,
	.masterClockHz = 512 * SAI_RX_format.sampleRate_Hz,
	.watermark = NUM_I2S_BUFFERS,
	.channel = 1,
	.protocol = kSAI_BusI2S,
};

C90の時代では、構造体を宣言した後にmemset()でクリアして値をセットしていくという手順を踏んでいましたが、C99以降ならこんな風にメンバを記述してしまう方が確実です(仕様では、記述されていないメンバは0になると定められています)。

ここまで得られた知見については既に作者へメールで伝えていますが、今後のOpenGD77に取り込まれるかどうかは不明です。最後に、テスト用機材を提供してくださったJA3QWG山本様、良き相談役となってくれたておくれロボには、この場を借りてお礼申し上げます。56.6kg(23:05)

22-Feb-2026
[ほんとだ。]

19-Feb-2026の話になりますが。

timg_20260219_120809_140.jpg timg_20260219_120814_137.jpg timg_20260219_120818_168.jpg timg_20260219_120822_422.jpg

津久井湖、ここまで水が涸れるのを見るのは初めてかも。春先に降ることがある大雨に期待したいけど…どうかなあ。57.3kg(21:55)

21-Feb-2026
[OpenGD77の(2)]

今となっては一つ前となるR20240908リリースですが…相変わらず、Debian-12上でビルドしたオブジェクトしかまともに動いていません(GCC Arm Embedded Toolchain 12/13は駄目でしたが、調べ方に問題があった可能性もあります)。まともに動かないパターンには

といったものがあり、リンクするオブジェクトの順番やオブジェクトの最適化(-Os/-O0)、コードに少し命令を挟むといった「ちょっとしたこと」ですぐに上記の症状が発生するというなかなか厄介な事態になっています。

binutils-arm-none-eabi-2.44に対応できるよう、bl <label>をblx <Rm>に書き換えたものを試作しています。codecEncodeBlock()の三つ目にあるインラインアセンブラ、AMBE_ENCODE_ECCを呼び出す部分は他と同様にldmiaでr0-r3をセットしようとすると何故かまともに動かなくなるので、ここはmov命令を並べています。ちょっと雑に見積もると、レジスタ4つとフラグレジスタの設定で8byte…ldmiaを使うならレジスタに設定するデータだけで16byteになるので、これはこれで良いのかもしれません。

あれこれ試した範囲では、AMBE_DECODEを呼び出す際はZフラグ=0である必要があるとか、r12レジスタの内容で挙動が変わるように見えます。ACTLR.DISDEFWBUF=1としたりGPIO操作後にdsbするといった処理を追加しても状況は変わらないので、write buffer周りの問題でもなさそうです。一体何が問題なのでしょうかね?実は手元のDM-1801が微妙に壊れている、とか??その割に、R20260131の公式バイナリはちゃんと動くのが本当に謎です。

(おまけ)作業中にちょっと必要になったのでUSB関連のソース(source/usb/*.c)を使わない場合のスタブや、firmware/source/.cprojectから最適化を行うソースのファイル名を抜き出す簡易的なツールを作っていたりもするのですが…需要無いですよね。R20240908, R20260131ともに同じファイルが-Osとなっていることは確認しています。56.4kg(22:20)

15-Feb-2026
[OpenGD77の]

DM-1801等に対応したMK22版、R20260131リリースが出ているので例によってMCUXpresso抜きのビルドを試みています(そんなことやってる場合じゃないんですけどね)。現状、ソースコードの改行コードをLFからCR+LFに変えてくれたおかげでパッチが全然当たりません。

さらに悪いことに、Debian-13に含まれるgcc-arm-none-eabi-14.2.1+binutils-arm-none-eabi-2.44ではアブソリュートアドレスを指定したBL命令を扱えないと言ってしまって良いですかね、ldのUnknown destination type (ARM/Thumb), dangerous relocation: unsupported relocationエラーによりfirmware.axfをリンクできせん。おまけに、ARMv7-Mに限り、Thumb-2命令のBLX labelが何故か非対応になっていますので、対策は厄介そうです。

Debian-12のgcc-arm-none-eabi-12.2.1+binutils-arm-none-eabi-2.40では問題なくビルドできて動作もしていたので、これに近いArm GNU Toolchain(AArch32 bare-metal target, arm-none-eabi) 12.3.rel1でビルドを試みました。今まで最適化あり(-Os)で動いていたcodec_interface.cは、最適化無し(-O0)でないと動作しなくなっています。

最適化有りの新旧バイナリを見比べたところ、codecDecode()に入った際にpushするレジスタが旧版ではr4-r9, r14の7つに対し、新版ではr4-r10, r14の8つになっていました。APCS(TPCS?)では8byte単位のアライメントを求めているようなので、新版の方が正しいバイナリだとは思うのですが…GD-77ファームウェア内にあるAMBE CODEC関連ルーチンを呼び出して使用するというかなり怪しいことをやっているので、この辺りの違いで動かなくなっても不思議なことではありません。

R20260131/sources_and_tools/Readme.mdでもMCUXpresso IDE v24.12もしくはそれ以前を使えとアナウンスがありますし、本当に「何か」が潜んでいることだけは確かそうです。MCUXpresso IDEのリリース一覧を見るに、

gcc-13ベースのArm GNU Toolchainで試してみる手もあるかもしれません。56.6kg(23:00)

05-Feb-2026
[忘れる前に]

a1a_gen(A1A generator)についてのメモ。

31-Jan-2026に文字の出現率を変化させたことで1分間あたりの文字数がどれくらいになるかベンチマークを取ったものの、結果が出るまでに随分待たされるのでa1a_genの高速化を試みています。そりゃまあ、その都度波形を生成していますし、1サンプル毎にfputc()を呼んでいては遅くて当然。

トーン生成部分はGPIOを操作するケースも想定し、outfunc(bool on, int64_t usec)で呼び出すような作りにしています。on, usecの組み合わせは数パターンしかないので生成したトーンをキャッシュしておき、これをfwrite()で書くような作りにすれば多少は速くなりそうです。実際、実行時間を1/4程度まで短縮でき、生成結果も改造前と相違ありません。そのうちmasterブランチにマージしておきましょう。

モールス符号を鳴らすプログラムって簡単でしょ?そう思っていた時期がありました。

でも実際に書いてみると、文字間の処理がかなり厄介に思えます。あのコード、結構面倒臭いことをやっているという自覚はあって…もう少し書きようがあるんじゃないですか?と聞かれてしまうと返す言葉もありません。

どれくらい面倒臭いかというと、解説のための文章を書こうとして途中で挫折するくらいのレベルです(今回の表題はその名残です)。複数の空白を一つにまとめていたり、<>で括られている部分は文字間を1点とする処理(BT等への対応で使います)はともかく、先に文字間ないし単語間の空白を作ってから文字を組み立てるのはどうしてそういうコードを書いた、自分?と困惑しています。

なんとなくですが、次に来る文字を予測できない以上、前にある文字を利用して空白の長さを決めるとか、そんなことを考えていたような気がします。56.0kg(23:20)

01-Feb-2026
[HK-705、直します]

※注意:この記事におけるHK-705は旧製品、HK-704は現行製品です

ハイモンド・エレクトロ社に発注していた上下接点一式が届いたので、早速交換します。交換することでオリジナルのHK-705ではなくなってしまいますが、接触不良で打ちにくい電鍵を持っていても意味はありませんから、その辺は気にしません。なお、接点上下セットのお値段は\3000+送料等の諸費用でした(銀を使っているので高いと言われています)。

まずは交換前のHK-705の様子。

timg_20260131_113835_890.jpg timg_20260131_113911_255.jpg

HK-704も手元にあるので、比較してみます。

timg_20260131_113948_570.jpg timg_20260131_114004_341.jpg

旧製品では下側接点から伸びるネジを利用して鉄板(重り)を固定していましたが、現行製品ではこの方法を使っておらず、鉄板を固定するネジ一式を別途用意する必要があります。分解自体は然るべきナットやネジを外せば良いので説明は省きますが、ボールベアリングのボールをうっかり失くさないよう注意してください。グリスも劣化しているので塗り直しが必要ですね…

timg_20260131_114352_155.jpg timg_20260131_114502_314.jpg timg_20260131_114522_629.jpg timg_20260131_115347_024.jpg

現行製品の上側接点は、HK-705のものより頭が少し短くなっています。

timg_20260131_124934_977.jpg

無線機に接続するための端子は、経年変化によりポリエチレン製と思しきスペーサーが割れていました。ちゃっちゃと直して使いたいので、ホームセンターで代用できそうな部品を探します。和木産業 if-045 3号棚受けダボを加工し、端子用のM4 18mmのネジを25mmに変更して対応しました。ネジを長くしたのは、7mm径の部分はどうにかしたものの10mm径の部分を切り詰めることは自分の工作スキルでは不可能だったという理由によります。

timg_20260131_130057_278.jpg timg_20260131_171003_461.jpg timg_20260201_092500_961.jpg

仕上がりはこんな感じ。鉄板を固定するネジはHK-704に倣い、M5 25mmのものを使いました。土台にきちんと収まってはいるものの、鉄板の厚さがHK-704よりも薄いためかなり飛び出た感じになります(この厚さなら20mmで足りる気がします)。また、見た目を考慮すると皿ネジではなく丸皿ネジの方が良いです。

timg_20260131_174717_251.jpg timg_20260131_175805_936.jpg

真鍮接点を銀接点化できたことに加えて、カバーを装着できるようになったので満足していますが…HK-703だと2枚入っている鉄板が、1枚だけ。というHK-705のレビューを見てしまうと、鉄板だけどこかでもう一枚入手できないかと考えてしまいます。これはカスタム沼に御招待ってやつですかねえ。56.3kg(23:20)