ラップタイマー作ります　その１１：PG全部書き直し。回路見直し中。

 緊急事態がようやく明けるんでしょうか？

やれやれって感じですね…まぁしばらくしたらまた増えた何だので再度緊急自体がどうたらとかやるんでしょうけど。

まぁ相も変わらず設計とソースの修正。

とりあえず頼んでみて見ないことには設計した物がどんな具合に作成されるかわからないので基板が小さい送信側の設計だけ済ませてSeeedStudioのサービスに発注。

普段の海外通販以上にかかりそうだなこりゃ

さていつ届くか。
国内に入らないとトラッキング出来ないので…いまどの辺りにいるんでしょうかねぇ…

ソースのほうはいろいろ試行錯誤が入っていたのを見直して全面的に書き直し。

今ある物に新しいソースを書き込んでテスト。

目に見えないし38kHzで点滅してる都合、よく言われる携帯のカメラなんぞには写らないしでデバッグしにくいことこの上なし。
とはいえ動くPGがあるので改修してデバッグ用に一本新規に書き起こして。
現物合わせで見て見ぬふりをしていたバグを修正。

メニューと設定の仕組みを作って実装、コードを整理しきったところで機能の拡張開始。

仕事で作ってる業務アプリの場合はあらかじめ整理した仕様に沿うように数ヶ月数年後に読み返したときに読みやすく予測しやすく、テストの分割・自動化を行えるよう機能のモジュール化を、ほかの要素は全てPCのスペックのせいにして優先するところだけど…

現物合わせで38khzで点滅させてる組み込みでそんなことやると速度が落ちるだけなので。

機能の実装＝スパゲティ化

に直結する中、延々と「どうやれば後で読み返しやすいか？」に悩む悩む…
20年近くPG組んできた経験がすげぇ邪魔をするｗ
「こんなところにこんな処理を挟みたくない・こうすれば読みやすい」のと「ここに挟まないと速度が…タイムラグが…」
というのがｗ

とは言っても送信側はそもそも38khzで点滅出来ないとそもそもIR通信が成り立たないので論外だけど、受信側は多少タイムラグがあろうが、毎回同じラグが発生するなら結果的に測りたいタイムにズレは発生しないわけで。

とはいえ受信側もIRセンサーからの信号をシングルスレッドで処理してる都合、信号と信号の間に処理しきらないと単純に信号を落とす→正常に読み取れないという自体が発生するわけで。まぁ仕組み的に受信処理を割り込みで切り出してる都合、即ロストには直結しない物の…（文字に起こすとややこしい）

閑話休題

たのしいたのしいスパゲティ化機能拡張のお時間。

とりあえずソフトウェア的には…

• 使用するch選択
  とりあえず20台。信号が長くなればなる程IRセンサーの前に居なければならない時間が延びるのでこんなもんかなと。信号が一番長い状態でもF1程度の速度じゃぁロストしない事は確認出来てるので1番短い状態だと車速が2倍速くてもたぶん大丈夫。
• ラップのリセット
  よくある「スタート」のかけ声。1分たったら測り直しみたいな。
• 最小タイムの設定
  10秒以下は誤検知なので無視みたいな設定。
• 周回数のカウント
  「スタート」してからの周回数を読み上げるときにつけるかどうか
• 読み上げの省略
  「12秒5」を「2秒5」に省略するみたいな。
• 回線ONから読み上げまでのタイムラグ
  無線機などのVOX機能の場合、話しかけてから回線ONになるまでのタイムラグが必要なので。
• IRセンサー2つ目の無効化
  2つあるセンサーの片方を無効にする
• 送信機が送ってきてるｃｈ番号を調べる
  送信側は38kHzの縛りをすごく受ける都合、簡単にch変更出来ないので受信側で合わせる為。あとIR通信のデバッグ用。