Linux Kernel 5.12ではpreemption modelの動的変更が実装されています。
この機能を試してみます。

■ 前準備

以下のconfigを有効にします。

• PREEMPT_DYNAMIC
• HAVEPREEMPTDYNAMIC

ここでは省略しますが、どちらも他の設定に依存した設定値になっているので、間接的に設定が必要です。
Ubuntu 20.04(x86_64)の場合は、PREEMPTを有効にすることで上記が有効になりました。

■ 動的にpreemption modelを変更する

方法としては2つあります。

• Kernel引数のpreemptにnone/voluntary/fullのいずれかを指定する
• /sys/kernel/debug/sched_preemptから変更する

今回は後者の方法を試してみます。
まずcatで現在の設定の確認。

# cat /sys/kernel/debug/sched_preempt
(none) voluntary full

これをCONFIG_PREEMPTと同じpreemption modelに変更します。

# echo "full" > /sys/kernel/debug/sched_preempt
# cat /sys/kernel/debug/sched_preempt
none voluntary (full)

とりあえず変わることはわかりました。

■ 何かがおかしい？

本来はここで動作検証をするところなのですが、
試してみても挙動がまったく変わらず、何かがおかしい？

一つ気になるのがDEFINESTATICCALLでpreemptscheduleは登録しているものの、
staticcallで呼び出しているところが見つからない。

https://elixir.bootlin.com/linux/v5.12/source/kernel/sched/core.c#L5264

PREEMPTDYNAMICがstaticcallの機能の上で成り立っているため、
static_callで呼び出さないとダメだと思うんだけどな。もう少し調べてみよう。

以下の環境で試していきます。

• ビルド環境 （以下、プロンプトは build$ で示します）
  • Arch : x86_64 (実機)
  • Distribution : Ubuntu 20.04.1
• ターゲット環境 （以下、プロンプトは target$ で示します）
  • Arch : x86_64 (VMware fusion) ** Distribution : Ubuntu 20.04.2

ビルド環境とターゲット環境を兼用しても大丈夫です。
今回は、VMに割り当てられるリソースが少ないので別途ビルド環境を用意しています。

ターゲットとするカーネルは5.12とします。
ビルド環境にて、メインラインのカーネルをチェックアウトします。

configはUbuntu 20.04のものを使用します。
ターゲット環境からビルド環境へ転送します。

target$ scp /boot/config-5.4.0-72-generic 192.168.10.44:~/linux/.config

configはdefconfigから生成する方法もありますが、
ドライバの有無や機能の有無にも関連してくるため、
ひとまずはディストリビューションのものを試すのが無難だと思います。

カーネルのバージョンが5.4から5.12へ変わるため、
oldconfigで不足しているconfigを設定します。

build$ make oldconfig

数十〜百単位で項目が聞かれますが、とりあえず試すだけであれば
全部デフォルト値（つまりEnter押しっぱなし）で十分だと思います。

一点だけ、CONFIGSYSTEMTRUSTED_KEYS はデフォルト値を削除して空欄にする必要があります。
署名済みカーネルモジュールを生成するためのキーみたいですが、
この点はどういう仕組になっているのかよくわかってないです。
make menuconfig でメニューを表示し / で検索します。

build$ make menuconfig

次にビルドします。
細かくはカーネルビルドして、モジュールビルドして…とか手順はありますが、
今回そこが目的ではないので以下でまとめてビルドしてしまいます。

build$ make -j4 bindeb-pkg

ビルドが完了すると以下のファイルが出力されます。

• linux-headers-5.12.05.12.0-1amd64.deb
• linux-image-5.12.05.12.0-1amd64.deb
• linux-image-5.12.0-dbg5.12.0-1amd64.deb
• linux-libc-dev5.12.0-1amd64.deb

これをターゲットに転送して、インストールします。

target$ sudo dpkg -i linux-*.deb

完了したらrebootします。
立ち上がったらunameでカーネルのバージョンが上がっていることを確認します。

target$ uname -a
Linux ubuntu05 5.12.0 #1 SMP Wed May 5 17:25:30 JST 2021 x86_64 x86_64 x86_64 GNU/Linux

あけましておめでとうございます。
普段の年末なら実家に帰ったりして、ちょっと普段と雰囲気が変わって"お正月"な感じがでますが、
今年はずっと家にいたため、あまりお正月感が出ずでした。
でも、その分考えることややりたいことは進んだので良かったかな。

そんな中で今年の目標を考えてみました。
あれこれ考えながら、以下のあたりでいきます。

• 英語の聞く・話す能力の向上
• ものを作る過程のアウトプットを増やしていきたい。ちゃんと形にしていきたい

やることをうまく分解・組み立てして、実現に向けて頑張っていこうと思います。

今年も1年ありがとうございました。
COVID-19でいろいろと変化の多かった年でしたが、3点ほど今年の印象的な出来事を上げてみます。

■ 3月頃からリモートワークを続けてます

3月頃から続けてリモートワークをしています。
良い点としては、（COVID-19はあまり関係ないですが）子供がいると何かあったときに対応しやすく、
その点は非常に良かったかな。

一方で一時期は常にリモートでも良いのかなと思い、実際そういう時期も2ヶ月近くあったけど、
実際にやってみると中々すべてをリモートでというのは難しいなと感じました。
特に人と人とのやり取りの中では、直接会うほうが進めやすいというケースがありますね。

■ Linux Kernelをいじる業務が増えました

以前からそんな感じのことはしていたのですが、今年は特に集中的にやってます。
ソースコードを上から下まで読み込んで、いろいろと手を加えたりとか、
バグを出したりとかしていて、奥深いところまで理解が進んだのかなおと思ってます。
特にアーキテクチャ依存部の実装や一部のドライバの実装には詳しくなったと思います。
また、自分の手でOSを動かせるっていうのはやっぱり面白いですね。

■ 万年筆にはまりました

以前からプラチナ万年筆のプレピーという万年筆を使っていました。
ただ、ペン先の歩留まりが悪いのか、数本買って書き味の選別をしてみたり、
（一本300円ぐらいなので）自分でルーペでみながらヤスリで調整とかしていました。
じゃあ、ペン先が金の万年筆だとどうなのか？というのが発端で、
センチュリーの太字と細字を半年間隔ぐらいで購入してしまい、はまりました。

使ってみた感想は期待通りか、ちょっと下回るぐらいかなぁ。。。
太字はぬらぬら感が良かったんですが、細字はかりかり感が出てしまうのがちょっと微妙なところでした。
こういう時期でなければ、ペンクリニックに持っていって調整をしてもらうの良いとは思ってます。
次に気になってくるのは、他のメーカーだとどうなのかなとか思っていて、
また少し経ったら買いたくなっちゃう気がします。。。

逆にうまくいかなかったな点は以下の2点。

■ 英語がおざなりになってきている

話す機会が圧倒的に減ってきているのが良くないかな。
読み、書きは普段から少しはするものの、もうちょっと量を増やしていきたいですね。

そういえば、2月にTOEIC S/Wを受けたことをこれを書きながら思い出しました。
定期的にテストを受けながら目標設定していくつもりが、
この状況下（特に2月の回を最後に中止になったり、人数制限がかかったりしていた）ですっかりおろそかになっていました。

■ 自分の作りたいものがうまく進んでいない

目下はAVRの書き込み基板を作っています。
それを応用して広げていきたいなと考えているのですが、
単に書き込み基板（とそのファームウェア）を実装するのに時間がかかってます。
時間がまだあると思っちゃうんだろうけど、サクッと終わらせたいところです。

こんな感じの1年でした。

それでは、来年も良いお年をお迎えください。

Raspberry Pi W Zero をセットアップした。
MH-Z19（詳細は12月1日の日記参照）を使って、CO2濃度を測れるようにする。
以前やったときは、Raspberry Pi 4 を使っていて、普段仕事をする部屋で稼働している。
時系列でグラフを見ていると相対的に空気が悪い事がわかるので、
空気を入れ替えるタイミングが分かるのが良いかな。
今回セットアップしたものは、リビングに設置して測定予定。

昨晩のこと。開栓したワインが何かカビ臭い（乾いた雑巾のような匂い）。
保管期間が長くて酸化したのともまた違った感じで、飲むのもツライ感じ。
そういえばソムリエがコルクを確認するのはこういう理由だったような、と思い
調べてみるとブショネとというらしい。

うーん、でも本当にそうなのか…？
少し置いてみてもカビ臭いのは抜けない。
あと、念のためvinicaでレビュー見てみて、そういうワインなのか調べてみる。
フルーティーでスパイシー…全くそんな感じしない。やっぱりおかしい。
今まで感じたことのない匂いだし、まぁそうなんだろうな。

さらに調べてみると、販売元によっては交換をしてくれるみたい。
今回買ったところはその対応をしてくれるところで、
連絡をしてみたところ返金をしてもらえることになった。良かった。

ワインって毎回味が変わるものだし、こういうのも含めて面白みなのかなと。
ただ、最初にこんなワインにあたったら嫌だろうな…。飲み慣れててもこの匂いはきつい。
この日もう一本開けてみたけど、前の匂いの印象が残ってて全然進まなかった。

AVRでSPIのデバッグの続き。ようやく理由がわかった。
Slave Selectの信号が入力になっていて、かつ、Lowに入力されている状態になっていて、SPIの回路が動作していなかった。
仕様書確認して、信号の方向を出力にした場合は回路側が影響を受けないということなので、ひとまず出力にして対策。
特に他のデバイスはつないでいない状態であれば、出力にしてしまってもひとまずは問題ない。
他のデバイスを接続する可能性を考えると、外でpull upしておくのが良かったな。。。次回修正しよう。

あと、SPIのMOSI、MISOの接続を間違えていることにも気づいた。
Master Out Slave Input(MOSI)なので、MasterとSlave間で同じ端子をつなぐのが正しい。
つい、UARTのRX, TXの感覚でクロスで接続してしまった…。
基板をカットして配線し直そう。

CO2センサとして使っているMH-Z19を購入しようと、数日前からaliexpressをちらほらと見ているんだけど、
在庫や値段の動きがちらほらある感じがする。
どうせすぐに使うものでもないし、何かのセールのタイミングで良いかなとか考えていただけど、
値上がり傾向な感じもしてたため、購入することにした。ちょうど年末年始に届く予定。

AVRでSPIを使いたいと思っていじってるんだけど、うまくいかない。
ライタと信号を共有しているので、それが原因かなとか思って外してみるも、これも効果なし。
プログラムが間違っているのかもだけど、仕様書の通りの手順でやってるだけなんだよね…。
うーん、また時間をあけて考えてみよう。。。

今日は休暇だったので、家でいろいろと作業。

以前aliexpressで買ったMH-Z19をようやく動かしてみる気になり、
コネクタをはんだ付けしたりしてRaspberry Piに接続できるようにした。
Pythonのライブラリを使って、特に問題もなくセンサの値が取得できた。

グラフを見ていると在室状況によって変動するので面白い。
あとはこの値から部屋の中の換気が適切かどうか判断したい。

今回少し工夫したのは、ストレージへの書き込み回数を減らすこと。
1秒おきにロギング＆グラフ出力をするようにしていて、
そのまま出力するとSDカードの書き込み回数上限に達してしまう可能性があり、
代わりにramfsに出力するようにしてram上で完結させるようにした。
再起動するとログも飛ぶものの、過去のデータは無くても良いかな。
必要なら1日おきとかにバックアップ取れば良さそう。

やらないと…と先延ばしにしていたサーバのアップデート、ようやく完了。
今回はOSをDebian 10にしました。

railsで動いているアプリケーションも何とか6.0にしました。
ところどころ動かないところは諦めたりとかしましたが、
主要なものはあまり手を入れずに動かせて良かったです。

基板を作成してみました。
昨日FusionPCBで発注、そんなに急ぎではなかったのでShigapore Postで配送にしました。
3週間後ぐらいに届くのが楽しみです。

今回作った基板は、USBで接続をして、UART、I2C、GPIOをそれぞれコネクタから出します。
メインはUSB-シリアル変換として使うため、ついでに今後その他のIOで遊ぼうと思っています。

最初、いろいろなところで使えると良いなと思い、MCP2221Aを表面実装とDIPとそれぞれ切り替えて使えるよう設計していました。
ただ、USBの基板設計ガイドラインを確認していて、明確には書いてないものの分岐はダメな気がしてきてやめました。
表面実装とDIP、どちらかは未実装になるので動作としての影響はないのですが、分岐していることで反射の影響とか受けそうだなぁ…と。
ということで、表面実装だけ残してあとはすべて削除。すっきりとした基板になりました。

今さらAVRの書き込み基板を作ってます。
ワンボードにAVRを2個乗っけて、モニタ用（マスタ）とプログラム実行用（スレーブ）のそれぞれで使用して、
PCからUSB1本でプログラムの書き込みから実行までできるような基板です。
基板の詳細についてはまた別の機会に書くことにして、早速失敗に気づいたので、まずはそちらから…。

UARTからデータの送受信をするプログラムを作成して実行してみるも、何かうまく行かない。
オシロで見てみるとボーレート自体は問題なさそうだし…って、なんでマイナスの電圧が？というので気づきました、レベル変換入れてない…。
そういう設計でも（仕様通りなら）良かったんですが、少なくとも今使っているUSBシリアル変換はRS-232Cのレベルでしか受けてくれません（なので仕様通りじゃない）。

こういうときのため、以前にMAX232を使ったレベル変換基板を作ったので、それを使ってみることに。
が、これもこれでよく調べてみると、この基板は電源をマイコン側から取るようになっている（当然RS-232Cのコネクタにも電源はないので、MAX232を動かすための電源が取れない）。
今回作った基板は添付の画像のようにRX, TX, GNDの3線しか出していません（ここにVCCがあれば解決する問題だった）。うーん…ダメじゃん。

そうなるとCMOSレベルで受けられる、USBシリアル変換を買うか、あるいは作るかになりそうです。

Raspberry Pi 4b (4GB model)を購入しました。
秋月のセットを購入。
いろんなところで売っているのでどこで買ってもよいんだけど、
電子部品を買う必要があり一緒に通販で購入しました。

当面の用途はローカルのDNSリゾルバにすること。
ルータがEDNS0に対応していないためGoogleのDNSを使っているのですが、
いくらレスポンスが早いと言っても、やっぱりローカルでDNSは持ちたい。
あと、ローカルに常時電源入ったデバイスがほしかったというのも理由。

買うときに少し悩んだのが発熱がどうなのかという点。
早速購入直後の状態で確かめてみたところ、以下の通りでした。

$ vcgencmd measure_temp
temp=63.0'C

ちょっと高いかな…。
ちなみに、1コアだけCPUに負荷をかけると以下の通り。

$ dd if=/dev/random of=/dev/null &
$ uptime
 02:18:48 up  2:42,  4 users,  load average: 1.26, 0.47, 0.17
$ vcgencmd measure_temp
temp=69.0'C

室温が23度の条件で上記なので、夏場は厳しいかも…。

ちなみに、Power Management の状況を確認したところ、idle時は600MHz、

$ vcgencmd measure_clock arm
frequency(48)=600117184

一方で高負荷時は1.5GHzで動作している。

$ vcgencmd measure_clock arm
frequency(48)=1500398464

気休めにヒートシンクはつけてみたものの、あまり変わらず…。
うん、何となくそんな気はしていた。
運用してみてあまりにも酷ければ、ファンをつけることも考えよう。

必要な設定項目を設定。
GUIは停止して、SSHは常時起動に変更。

$ sudo systemctl enable ssh
$ sudo systemctl disable lightdm

最後にバージョンを確認。

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:    10
Codename:   buster

$ uname -a
Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

kgdbを使ったLinux Kernelのデバッグ方法をまとめてみました。
この説明は以下の内容を元にして、具体的な手順を説明したものです。

kgdb, kdb の使い方と、カーネルデバッガーの内部
https://sites.google.com/site/kandamotohiro/linux/kgdb

カーネルの設定の確認

まずはカーネルの設定を確認。以下の通りに設定をします。

# CONFIG_DEBUG_RODATA is not set
CONFIG_FRAME_POINTER=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y

ビルドして起動できることを確認します。

ホストとターゲットの構成

ホストとターゲットは2本のUARTで接続します。
1本はカーネルログの出力確認、breakコマンドの入力、シェルの操作を行うために使用します（以降の説明ではUART0）。
もう1本はkgdbの通信用に使用します（以降の説明ではUART1）。

UARTが1本しかないケースは、SSHで代替することもできます。
ただし、この場合、任意のタイミングでbreakをかけられないことと、カーネルログの出力が確認できないため、あまりおすすめはしないです。

ターゲットのカーネルを起動する

カーネルの引数にkgdbwait, kgdbocを追加します。
kgdbwaitは、カーネル起動時にkgdbの接続を待ちます。
kgdbocはUART経由でgdbに接続することを指定します。kgdbocには使用するttyとボーレートを設定します。
以下はUART1に対して、115.2kbpsのボーレートを設定しています。

kgdbwait kgdboc=ttyS1,115200

またカーネルログの出力先は以下のとおりUART0に対して設定します。

console=ttyS0,115200 

カーネルを起動して、以下の表示が出るとkgdbの接続待ちの状態になります。

KGDB: Registered I/O driver kgdboc
KGDB: Waiting for connection from remote gdb...

ホストからターゲットに接続する

ホストからターゲットのカーネルに対して、gdbでアタッチします。

ビルドしたvmlinuxをgdbで読み込みます。
ターゲットがロードしたカーネルがzImageの場合でも、シンボル情報が必要になるためvmlinuxをロードします。

$ arm-linux-gnueabihf-gdb vmlinux

次にkgdbocでUART1に対してアタッチします。
以下はホストの/dev/ttyUSB2とターゲットのUART1が接続されている例です。

…
(gdb) set serial baud 115200
(gdb) target remote /dev/ttyUSB2

接続に成功すると以下のようにbreakpointで停止します。

0x8016fbb8 in arch_kgdb_breakpoint () at kernel/debug/debug_core.c:1070
1070            wmb(); /* Sync point before breakpoint */

kgdbの操作

ほとんどの操作はgdbと同様に行うことができます。
以下によく使う操作を記載します。
ブレークポイントを設定＆実行を再開する
手順はgdbと同様です。
以下はuio_readにブレークを設定する例です。

 (gdb) b uio_read
 Breakpoint 1 at 0x803d910c: file drivers/uio/uio.c, line 812.
 (gdb) c
 Continuing.
 [New Thread 1172]
 [New Thread 1135]
 [New Thread 1143]
 [New Thread 1146]
 [New Thread 1152]
[New Thread 1153]
[New Thread 1167]
[Switching to Thread 1172]

Thread 42 hit Breakpoint 1, uio_read (filep=0x839f9240, buf=0x7ef96c20 "", count=4, ppos=0x83bdff80) at drivers/uio/uio.c:812
812     {
(gdb)

任意のタイミングでブレークをかける

任意のタイミングでブレークをかける（つまり実行を停止して、gdbで操作できる状態にする）には、ホストからUART0に対してSysRq + gを入力します。

ホストからUART0への接続にscreenを使っている場合には、Ctrl-a -> b -> gでSysRq + gの入力できます。
SysRq +g を受け付けるとUART0には以下のように表示されます。

# sysrq: SysRq : DEBUG

gdbは以下のようにブレークがかかります。

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 4294967294]
kgdb_breakpoint () at kernel/debug/debug_core.c:1071
1071            arch_kgdb_breakpoint();
(gdb)

カーネルのconfigを一部設定変更したいと思って、menuconfigを探してみるもなかなか見つからないことが多い。
.configをテキストでざっと見つつ、メニューの階層を推測して…といままでやってたんですが、
実はmenuconfig上で検索できることを知りました。これはすごく便利。

やり方は、menuconfigのUIで"/"を入力すると検索ができます。
例えば、MAGIC_SYSRQを探した結果は以下の通り。

左側に(3)や(4)などの数字が出ているので、それに対応するキーを押すとジャンプできます。
またselected byやdependsが書かれているので、ここからどういう条件でそのメニューが有効になるか、確認ができます。

あけましておめでとうございます。今年もよろしくお願いいたします。

毎年恒例の目標をまとめてみたました。今年の目標は以下の通り。

• 英語の listening と speaking の能力をあげる
  • 成果を客観的に見られるように、TOEICなどの試験を受けるようにする
  • 勉強は今まで通り、英字新聞や英語のニュースなどから
• Linuxの最新情報について定期的にまとめる
  • 最近、日本語の最新情報を見ることが少なくなった気がするので、自分の理解向上のためにまとめていきたい
  • できればソースコードを追いながらできると良い

2020年もがんばっていきたいと思います。

気づくと一年間日記を書いていませんでした。。。

年末なので今年の振り返り。
仕事や家庭などいろいろとありました。
トータルで見れば充実した一年だったのかなぁと思います。

さて、新年に立てた目標は…と見返すと、あまり課題の設定方法が良くなかった気がします。
どちらも具体的な成果にはなっていないものの、自分の中では少しづつできてきてるのかな（笑）

• 世の中に貢献できるアイディアの実現、適切なアウトプットする
• 世界を相手に活躍できる足がかりを作っていきたい

今年も一年ありがとうございました。来年もよろしくお願いいたします。

あけましておめでとうございます。
今年もよろしくお願いいたします。

一年の抱負を考えてみました。

• 世の中に貢献できるアイディアの実現、適切なアウトプットする
• 世界を相手に活躍できる足がかりを作っていきたい

実現できるよう、今年もがんばっていこうと思います。

今年も一年お疲れ様でした。
振り返ってみると、様々なできごとがあって充実した一年だったと思います。

今年のはじめに立てた目標に対しては、以下の結果となりました。

• 世の中に貢献できるアイディア
  • アイディアの実現に向けて一つ一つ問題の解決をしている
  • 進捗が良くないので、もっと積極的に進められるようにする
• 世界を相手に活躍できる足がかりを作っていきたい
  • 英語の学習は進めているものの、この一年は大きな成果が見えなかった
  • 特にリスニングの改善がうまくいっておらず、話す速度が早い場合や相手の発音によっては全く聞き取れない
  • 耳の問題と考えて、自分自身の発音の改善をしている。来年も継続的に改善をしていきたい
• 研究の活動をしていきたい
  • 仕事や個人の活動など、研究の内容を参考にしつつ進められている
  • 新しく直面する問題もでてきそうなので、うまくアウトプットできるようにする

明日は2019年の目標を立てたいと思います。
皆様、良いお年をお迎えください。

■ 状況
railsでbeforeunloadイベントを使用して、ページ遷移時に警告を出そうとしたところ、aのリンクで意図した動作がしない。

■ 原因
railsでturbolinkを使っている場合、ページをリロードせずに画面を書き換えるため、beforeunloadイベントが発生しない。

■ 対策
対策としては以下のあたり。

• turbolinkを使用しない
• aのリンクにdata-turbolinks="false"を指定して、turbolinkを部分的に使用しないようにする
• page:before-change のイベントを使用する

マイコンの割り込みをLinux上でシグナルとスレッドを使って再現してみた。

大まかな処理は、マルチスレッドで制御のスレッドとマイコンの処理相当を行うスレッドの2つを作成、
制御側からマイコンの処理相当のスレッドをシグナルで一時停止させ、その間に割り込みハンドラを実行する。
フルのソースコードは以下を参照。

https://github.com/yasuharu/micon_int_on_linux/

まずマイコン側の処理。UARTの受信を意図したもの。
uart_rx_handlerが割り込みハンドラ、micon_mainがマイコン側のメイン処理。

 void uart_rx_handler()
 {
   static int     pos   = 0;
   static uint8_t buf[] = "test";
 
   ringbuf_push(buf[pos]);
 
   pos++;
 }

void micon_main()
{
  register_irq_handler(uart_rx_handler);

  while(1)
  {
    if(ringbuf_length() > 0)
    {
      printf("%d\n", ringbuf_pop());
    }
  }
}

メイン側の処理は、マイコン用のスレッドを作成し、一定期間ごとに割り込みを生成する。
割り込みの生成タイミングは、お好きなタイミングでどうぞ。

 pthread_t thread_handle;
 
 int main()
 {
   pthread_create(&thread_handle, NULL, micon_thread, NULL);
 
   for(int i = 0 ; i < 5 ; i++)
   {
     sleep(1);

    suspend_micon_thread();
    do_irq_handler();
    resume_micon_thread();
  }
}

シグナルはSIGUSR1とSIGUSR2を使用する。
SIGUSR1はマイコン側の処理をsuspend、SIGUSR2はマイコン側の処理をresumeするために使用する。
micon_thread内で以下の通り初期化する。

 void micon_thread()
 {
   struct sigaction sigusr1, sigusr2;
 
   sigusr1.sa_flags   = 0;
   sigusr1.sa_handler = micon_thread_signal_usr1_handler;
   sigemptyset(&sigusr1.sa_mask);
   sigaction(SIGUSR1, &sigusr1, NULL);
 
  sigusr2.sa_flags   = 0;
  sigusr2.sa_handler = micon_thread_signal_usr2_handler;
  sigemptyset(&sigusr2.sa_mask);
  sigaction(SIGUSR2, &sigusr2, NULL);

  micon_main();
}

今回のポイントは、以下のコードの部分。
suspend/resumeでマイコン側のスレッドを一時停止させる。
SIGUSRT1のハンドラ（micon_thread_signal_usr1_handler）内では、
sigsuspendを呼んで、SIGUSR2が発生するまで待つ。

割り込みハンドラはメインのスレッド、シグナルのハンドラはマイコンのスレッドと、
それぞれで実行しているコンテキストが違うことに注意が必要。
特にシグナルのハンドラのsigsuspendを実行する前に、割り込みハンドラが実行されないよう、
int_statusで処理待ちを行うようにしている。
（ちなみに、int_statusは本来であればmutexでロックが必要）

割り込みが発生したときの処理をまとめると以下の図になる。

do_irq_handlerはこんな感じ。
int_statusを待つことだけ注意。

void      (*irq_handler)(void);

void do_irq_handler()
{
  while(int_status != 1);

  irq_handler();
}