Home | Notifications | New Note | Local | Federated | Search | Logout

SASANO Takayoshi@uaa@social.mikutter.hachune.net

OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)

Another side: https://social.tchncs.de/@uaa

npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890

Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w Joined: 2026-01-01 23:18:25 387 notes, 1 following, 0 followers

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:14:13) うーむ、.cprojectから、ビルド対象となるファイル名とgccの最適化オプションを指定するためのキーワードを抽出するしかないかも。

なんとなくだけど、-Osするものが.cprojectに書いてあって、そうでなければ-O0でビルドしてる感じ。-Osの方が数が多いので逆の方がありがたいんですけどおおおおおおおおおおおおおおおお

Reply to @taka_hvc1@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:09:10) @taka_hvc1 そういうことだったりします…

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:07:40) nopも単にnopなだけでなくて、なんかバイト数が違うnopとか山ほどありませんか最近のCPUって…

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:06:30) MCUXpressoを入れてOpenGD77のビルドを試みているけど、以前ほど馬鹿みたいに遅くはないので…MCUXpresso抜きでビルドするぜーというプロジェクトは終わらせても良いのかなあ。

とはいえ、Eclipseがクソ使いにくい(慣れていないだけとも言うけど)ので、Makefileでどうにかしたいというのはあるかも。

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:04:19) @teobot 素晴らしい!

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:03:43) @teobot これは、SRC.2=b.c c.cと複数の場合でも対応できますか?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 20:01:55) @teobot GNU Makeを使う状況で、ビルド対象となるファイルをSRC1, SRC2で定義します。SRC1=a.c b.c c.c、SRC2=b.cとした場合、SRC1からb.cを取り除く方法は何があるでしょうか?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-19 13:37:25) うーむ、公式版のOpenDM1801バイナリを書き込んでみたけどちゃんと動くわ…以前書き込んだ時はちゃんと動かなかったの(に加えてMCUXpressoが激遅なの)で、Debian付属のarm-none-eabiなtoolchainでのビルドを試みたというのに。

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-17 23:52:54) 作ってみたけど、うまくいかないねえ。何度も書きこんでいるのでFlashがヘタってきた可能性もあるのかもしれない。

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-17 22:42:37) Arm謹製GNU toolchainだとうまくいかない以上、今までうまくいっていた(と思われる)Debian-12のarm-none-eabi-gccで試してみるのが良いのかな。

という訳で、Debian-12仮想マシンを作ろうとしている。

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-17 21:51:48) arm-gnu-toolchain-11.3 -Os:送受信不可 -O0:受信すると再起動・送信不可
arm-gnu-toolchain-12.3 -Os:送受信不可 -O0:受信すると再起動・送信可
arm-gnu-toolchain-13.3 -Os:送受信不可 -O0:受信すると再起動・送信不可

上記-Os/-O0はcodec_interface.c, code.cに対し適用し、それ以外は全て-Osとしている。

…なんか、以前より状況悪くなってませんかコレ。

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-17 07:27:03) だとしたら…先にcodec_interface.c側の、BL absolute_addr問題を潰してからcodec.cを攻めるか。

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-17 07:25:50) もちろん、codec_interface.c側のコードがcodec.cに対して悪影響を与えているということはあるのかもしれない。実際、codec_interface.cが-O0だろうが-Osだろうがcodec.c側が-Osだと動かぬという問題はあるのだから。

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-17 07:24:03) そんな…

今までcodec_interface.cが怪しいと思ってずっといじってたんだけど…
-O0じゃないとまともに動かないのはcodec_interface.c側じゃなく、codec.c側だったなんて…

そりゃ今までの行動と結果が一致しなくても当然だわなああ…(崩れ落ちる音)

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-16 20:47:23) ※受信処理
最初の呼び出し前
N=Z=0は問題なし(他のフラグは不明)

どれか一つを立てる:
N=1 問題なし
Z=1 問題あり(送信可・受信不可)
C=1 問題なし
V=1 問題なし
Q=1 問題あり(受信可・送信不可)

最初の呼び出し後にR12を壊す
0x00000000 送受不可
0xFFFFFFFF

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-16 07:18:44) メモ:ARMv7-MのAPSRは

0x80000000 N
0x40000000 Z
0x20000000 C
0x10000000 V
0x08000000 Q

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 23:31:47) @teobot MOVSだと、Cフラグも変わりますよね?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 23:28:13) @teobot Thumb-2命令における、LDR R1,=80と、MOVS R1, #80の違いは何があるでしょう?どちらもR1に80が入りますよね?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 16:28:17) @teobot armv7-mの、mrsないしmsr命令で、cpsrレジスタのフィールドを指定する際の話です

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 16:27:13) @teobot armのcpsrレジスタ、4つのフィールドに分かれていたと思いますがどういう記号になっていましたっけ?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 15:26:53) まさかzero flagかこれ…?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 15:09:20) うーん、やっぱbinary blob呼ぶ際にR12の影響を受けてる気がする。

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 10:26:48) R4-R11の内容が0, 0xffffffffでも問題ないので、多分このレジスタについてはお構いなしか。

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 10:17:11) あー、ip(r12)の内容に依存してなんかある感じだなあ。r12=0, r12=0xffffffffだとちゃんと動かない。nop一個挟むだけだと問題ないから…アドレスの問題ではなさそう。

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 09:47:05) あー、ARMv7-MのThumb-2ではblx <label>が認められてないんだ。なので、labelのアドレスが何であろうと、動かない。

https://developer.arm.com/documentation/dui0379/e/arm-and-thumb-instructions/blx?lang=en

Reply to @uaa@social.mikutter.hachune.net SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 09:40:37) え?Thumb-2で動いてるんだしbit0=1(Thumb)は認められるはずなんじゃ???

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 09:39:46) -O0のオリジナルなコード →ok
Decode時のインラインアセンブラの命令順を少し変更し、無駄な命令を削除(Encode時はその余地なし)→ok
bl即値(0x5543c)→blx即値の変更(0x5543d) これはダメ

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 08:51:55) ふむ、bit-band "aliased"側からMK22のSRAM_Uにアクセスすればbit band accessになるものの、"bitband region" (0x20000000-200fffff)であれば素のSRAMなので問題なし、ということになるね。

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-15 08:47:34) @teobot Cortex-M4の、bit-bandアクセス領域(を経由したアクセス)において、bit-bandを無効化する方法はないと理解しています。この認識はあっていますか?

SASANO Takayoshi@uaa@social.mikutter.hachune.net (2026-02-14 22:13:17) @teobot thumb/thumb-2命令で、即値をpushする命令は無いですよね?
Older Notes