組込みマイコンのIDEが出力するmain()には、普通while文の無限ループによるアプリ起動処理が一か所記述されます。CubeSuite+のコード生成出力にもこれがあります。このアプリ起動処理を、起動されるアプリ側から検討します。
起動されるアプリには、割込みの確認/応答などのようにリアルタイム処理が必要なものから、スイッチチャタリング処理などの数ミリsec～数10ミリsec程度の処理間隔時間が必要なものまで様々です。このように処理時間が異なるアプリを、一か所の処理から起動すると、問題点がアプリ側に生じます。
スイッチチャタリング（以下SWと略す）処理を例に示します。1回目に起動されたSW処理で、スイッチのOn/Offを検出し、2回目に起動された時に再検出して1回目のOn/Offと同じであれば、スイッチの値を確定するような処理です。使用するスイッチにもよりますが、1回目と2回目の検出には、数ミリsec～数10ミリsecの時間間隔が必要です。この間は、On/Off値がハード的にバタついて安定しないからです。もし、起動処理が一か所の場合には、アプリのSW処理側でこの時間間隔分の検出処理をしない、“飛ばし”が必要になります。この“飛ばし”をｎ回とします。ｎ回起動されるまで2回目のOn/Offを調べない訳です。
起動処理は一か所ですので、他のアプリも起動します。起動側のアプリにもSW処理と同様、処理を“飛ばす”場合があると、結果として、SW処理の起動間隔は別アプリの“飛ばし”有無により変わってしまいます。SW処理は、他のアプリの“飛ばし”有無は判りませんので、このままではSW処理プログラムが書けません。
これを解決する方法の1つは、SW処理アプリが、“他のアプリ処理に係らず、常に例えば10ミリsecの一定間隔で起動“されることです。これならSW処理に“飛ばし”は不要です。このように本来は、アプリの要求時間に応じて、複数の起動処理が必要なのです。ここが、初心者が見落としがちな箇所です。アプリケーションノートには、説明を簡単にするため、1アプリ起動例しか載せないことが多いことが原因です。
複数の起動処理としては、1msec/10msec/100msec/1secの4つの時分割起動で、起動側のアプリ例は、表のようにした場合に経験的に上手く機能しました。この時分割は、マイコン内臓タイマを使い、CubeSuite+のコード生成に追加します。これが、前回紹介した追加コードです。そして、このコードを追加したものがテンプレートです。
| アプリ起動間隔 | 起動されるアプリ例 |
| 1msec | 割込み確認、割込み応答処理など、リアルタイム性が要求される処理 |
| 10msec | スイッチチャタリング処理、LCD初期設定など |
| 100msec | LED処理、LCD表示など |
| 1sec | 人間相手の処理、ウオッチドックタイマのリセットなど |
テンプレートの時分割起動部分ソースを示します。これなら、たとえ10ミリsecでSW処理以外に複数アプリが起動されても、アプリ側で“飛ばし”が不要ですので、他のアプリ処理有無に係らずSW処理のプログラミングができます。
