田舎の組み込みプログラマーがわざわざ趣味でも色々開発してみようとあがく様を綴るブログです。

アニメーションGIF テスト2019年06月16日 19時21分

しばらく放置してしまい申し訳ありません。

しかも、今日は新しい記事ではなく、別ブログのためのテストです。


XV-01 ロングダンパー仕様 フロントサスの様子


XV-01 ロングダンパー仕様 リアサスの様子


hx711の仕様を読み解く2018年11月30日 08時05分

先日、hx711の動作にミステリーな点があると書きましたが、結論から言うと、思い込みよる勘違いでした。
今回はその辺りについて書いてみようと思います。

やっちゃだめなやつ

今回の失敗例は、4個のhx711から同時に重量値を読み出そうとして、1つのシリアルクロック(PD_SCK)で4個まとめて処理する方法です。
つまり、4個のhx711が全てreadyになったら読み出しをかけていたんですが、その結果がこちら。

複数のhx711を一つのクロックで読み出すと・・・

readyになるタイミングがバラバラなだけでなく、数周期の間readyにならないやつまで出てくる始末です。
4個全てがreadyにならないと読み出しをかけられないため、しばらく待っていたんですが、他の3個はその間一定周期で短時間だけhighになっています。
ここでようやくhx711のアウトプットレート(10SPS or 80SPS)の意味に思い至ったわけです。

そもそも

実はこれまでA/D変換は逐次比較型しか使ったことがなくて、変換は任意のタイミングで出来るものだと思っていました。

hx711の場合、24bitということは多分ΔΣ型で、あらためて調べてみると、常時変換をしているタイプでワンショットやマルチプレックスには向かないとのことでした。
常時変換しているということは、読み出しをかけなくてもずっと動いているということなので、その辺をロジアナで確認してみました。

4個のhx711の変換タイミング

ご覧のように、それぞれ一定周期で一瞬だけhighになっています。
highになっている間はbusyなので、この時にA/D変換を行っているわけですね。

なので、busyになる直前に読み出しをかけると、読み出し中にA/D変換が行われてしまうことになり、その時のDOUT出力はおかしなことになってしまうわけです。
今使っている4個だけでもA/D変換周期の個体差が結構あるため、徐々に互いのタイミングがずれてきて問題が発生したというオチでした。

というわけで

hx711を複数使うシンプルな方法は、それぞれにそれぞれのシリアルクロックで読み出しをかけてやることですね。

まぁ、横着せずに最初からそうしておけば余計な苦労をせずに済んだのですが、趣味ですのでこういうのもありかなと思います。
なんとなく理解が深まった気もしますしね。

本題に進む前に

今まで使っていたモジュールは推奨回路と違っていたり出力周期が変えられなかったりと気になる点が多かったので、他のモジュールを取り寄せてみました。

2種類のhx711使用基板の比較

右のモジュールはコンデンサの容量は分かりませんが部品構成は推奨通りで、出力周期も変えられます。
あと、コンパクトで裏面がベタなのもポイントが高いですね。

せっかくなので周期設定を80SPSにしてみました。

いよいよ本題

配線とソフトを変更して実行した結果がこちらです。

個別クロックで複数のhx711を処理

ソフトは大がかりな変更をしましたが、珍しく一発で動いてかなり感動しました。
そしてそのソフトがこちら。

複数のhx711をR8Cで読み出すソース

メインループで直に処理していますが、今回はスマートに構造体風に処理してみました。
一回のループで1パルスだけ処理するようにし、次のhx711に切り替えるようになっています。

一見何の言語か分からないかもしれませんが、R8Cの構造化アセンブラです。
マクロ機能が便利なので調子に乗って使いまくってしまっているのが、正体不明な感じに拍車をかけていますね。

ifとか++があったりしてC言語風でありながら、アセンブラですので普通にニーモニックが使えますし、マイコンのフラグも記述できます。
R8C自体もビット処理が使いやすかったり、アドレスレジスタ以外にもSBとかFBが相対アドレッシングに使えたりと、アセンブラでプログラミングするのが楽しいマイコンですね。

もう一つの方法

今回はやっていませんが、複数のhx711を使用するもう一つの方法として、複数のhx711に同一の外部クロックを供給してやる方法があります(たぶん)。

個々の内臓オシレータで動作している状態ではタイミングが徐々にズレていくのは当然と言えば当然なわけで、ならば、同一の外部クロックで動作させれば(たぶん)同期がとれるはずなわけです。

その際、外部クロックは最大20Mhzまで使え、RATE端子がhighの場合は20MHz÷138240で約145SPS、lowの場合は20MHz÷1105920で約18SPSとなります。
つまり、外部クロックを使う事で変換周期も変更できるということですね。

あともう一つ

データシートに「セトリング時間」という項目があり、A/D変換4回分の時間になっています。

A/D変換の場合、ステップ信号入力に対してデジタル出力が対応した値に収束するまでの時間ということで、例えばロードセルに100gの重りがスパンと乗ったとして、デジタル出力値がその100g相当の値になるまでには4回のA/D変換が必要というわけです。

ということで、今回はhx711の仕様を少しばかり読み解いてみました。

ラジコン用のコーナーウエイトゲージ3回目2018年11月11日 03時20分

訂正やら変更やら

先日、今使っているHX711モジュールはRATE端子がどこにもつながっていないと書きましたが、ICの下でちゃんとGNDに接続されていました。
なので、レートは10SPSになっているはずで、readyになるまでの時間が4個のHX711でバラバラになっている理由が分かりません。

そこで、別の用途のために買ってあった赤いヤツを繋いでみました。

HX711 赤いモジュール

あと、先日はPD_SCKの立ち下がりクロックで割り込みをかけていましたが、PD_SCKの立ち上がりに対してDOUTは最長でも0.1μsecで準備ができるとのことで、割り込みのオーバーヘッドよりもはるかに短時間のため、立ち上がりクロックでの割り込みに変更しました。
となると、無理にHIGH時間を短くする必要もなく、PD_SCKの配線を4個のHX711に引き回していることもありますので、HIGH時間も長めにしました。

で、きっと赤いヤツはきっちり10SPSなんだろうと期待して波形を見てみると・・・。

HX711 4連波形・・・一人以外速度違反

違ってました orz
しかも、この接続に変えるまではずっと1番が10SPSだったのに、この接続にしてからはずっと3番が10SPSだったりします。
(赤いヤツは4番)

ミステリーは放置して

次のステップに進みます。

HX711から読み込んだ値を観察していると、下位8bitは常時変動している感じです。
赤いヤツについては繋いだばかりの時は変動は7bitで、流石SparkFunだと思ったんですが、ICが温まってくると8bitになっちゃいました。

しかしまぁ、生データをいくら眺めていても何にもなりませんので、重量値に換算してみましょう。
最近仕事で2点校正をよく使っていたので、それで行ってみます。

HX711の入力値を分銅で校正

この時のために、ちゃんと分銅も用意しましたよ。

で、100gと500gの分銅を乗せたときのデータを記録して、その値を元に換算します。
1番のロードセルだけ負の値を出しますが、そこはきっちり対処して負の値もちゃんと扱えるように作り込みます。

24bitは扱いづらいので符号拡張して32bitにし、平均を取る→2点校正で1mg単位で重量値に→ゼロ点補正→100で割って0.1g単位に・・・といった手順でやってみます。
が、アセンブラではかなり大変そうなので・・・

苦しいときの神頼み

C言語の力を借ります。

C言語の力で2点校正

C言語を使うのは久しぶりすぎて、こんな感じでいいのかどうか分かりませんが、一応ちゃんと動作しているようなので良しとします。
注意点は、整数演算なので有効桁確保のために掛け算を先にやること、その時32bitでは足りなくなるので64bitで演算することくらいでしょうか。

RAMモニタの数値は実際にラジコンを乗せて量ったもので、1行目の左から順に左フロント、左リア、右リア、右フロントとなっています。
HX711の計測値は今のところ加算平均5回で処理していますが、0.1g単位だとほとんどバラつきません。

精度については、多分ロードセルの温度特性なんでしょうけど、これまでのところゼロ点は最大5gくらいズレますし、ゲインは500gの重りで0.2gぐらいズレたりします。
値がバラつくことに関してはシールド線を使ったりコンデンサを入れたりで改善できそうな気もしますが、温度特性は頭の痛いところですね。

まぁ、自分用のコーナーウエイトゲージということを考えると、4個が同じ様にズレるのなら特に問題はないんですけどね。

といったところで、今回はここまで。

ラジコンのコーナーウエイト計測

ラジコン用コーナーウエイトゲージ2回目2018年11月08日 04時00分

続きです。

コーナーウエイトゲージということで当然秤は4つあるわけで、HX711も4つ使っています。
なので、ロジアナでまとめて観察してみたところ、気になることが・・・

HX711の足並みが揃わない

1回目の読み出しは次のチャンネルとゲインを指定するためのものなので除外するとして、それ以降のREADYになるタイミングがバラバラです。

DOUT 1(1個目のHX711のDOUT)だけは95msec弱とほぼ10SPS相当なので、それ以外はダメということになりそうです。
もしかすると、使っているHX711をモジュール化した基板でRATE端子をどこにも接続していないのが問題なのかもしれません。

その辺の調査は後回しにするとして、次にデータを見てみます。

HX711 4個のデータもバラバラ

データも見事にバラバラですね。
ゲインを64に抑えてもいますので、先頭から12ビットくらいは揃って欲しかったんですが・・・。

特にDOUT 1がいきなりFFhから始まっているのは、配線ミスやロードセルの不良も疑ったんですが、データシートを見ると測定値は2の補数形式ということなので、単にマイナスの値になっているということのようです。

この辺も使っているモジュールが推奨回路通りになっていなくて、入力抵抗が片側にしか入っていないことも影響しているかもしれません。

なので、推奨回路通りになっていると思われるモジュールを発注済みです。
中国発送のようですので、到着までまだしばらくかかりそうですが。

もうひとつ気になっていたこと

それは、割り込み中のデータシフト処理にどのくらいの時間がかかっているかということです。
これもロジアナを使って確認してみました。

割り込み処理タイミング

割り込み処理の入り口でポートビットをオンし、出口でオフしています。
クロックの立ち下がりで割り込みをかけるようにしていますが、割り込み処理に入るまでに1.96μsecかかっていますね。
そして、割り込み処理が5.556μsec。

次のクロックまでにはまだ若干の猶予がありますが、計測結果を別のマイコンに転送することになると思いますので、そうなると割り込み処理が増えるのでちょっと厳しいかもしれません。

そんなこんなで

一応、年内にはサーキットでコーナーウエイト調整の効果を確認してみたいとは思っているんですが、こんな感じでちまちまやっていますので、どうなることやら。

ラジコン用のコーナーウエイトゲージを作ろう2018年11月07日 07時30分

またもや随分更新をサボってしまいました。

忙しかったと言えばそれまでですが、やはり具体的なビジョンがなければ頓挫しやすいということだと思います。

ということですので

ラジコン用のコーナーウエイトゲージを作ってみることにしました。

元々電子工作を始めようと思ったのはラジコン用の何かを作りたいというのが一番の理由で、コーナーウエイトゲージもずっと以前から作りたいと思っていた物です。

ぐずぐずしているうちに市販品が出てしまったわけですが、ロードセルとかロードセル用ADコンバータとかが簡単に手に入るようになったので、今更ながらやってみます。

ラジコン用コーナーウエイトゲージ試作品

で、これが試作品。
ロードセルは2kg、ADコンバータは定番のHX711、マイコンはいつものようにR8C/32Mです。

20MHzで不足とは・・・

HX711の使い方はあちこちで解説されていますが、マイコンからパルスを送ると同期してデータが出てくるという、クロック同期シリアルインターフェイス的なやつですね。

「的な」と言っているのはちょっと独自仕様が入っているからで、おかげでマイコンのシリアル通信機能が使えないわけですが、今回のように4つの物を使うとなるとクロック同期シリアルが4つも使えるマイコンなんて見当たらないので結局は自力でなんとかするしかないわけですね。

具体的には、転送クロックをタイマー機能で生成し、立ち下がりで割り込みをかけてシフトするわけですが、クロックパルスの幅は標準1μsecとかなり高速です。
この速度だと、1周期は2μsecですので20MHzだと40サイクルしかなく、この時間で4つ分のデータのシフトは無理そうというか実際無理でした。

ゆっくりしていってみる

標準はあくまでも標準ですので、ゆっくりやれば別に問題はないわけです。

が、一つ注意が必要なのはパルスがHIGHになっている時間が60μsecを超えるとHX711がパワーダウンモードに入ってしまうということです。
で、通常は50μsecまでにしろとのことですので、そこは守らないといけないわけですね。

ということで、実際の波形がこちら。

HX711クロック、データ波形

クロック周期を10μsec、HIGH時間を0.5μsecにしてみました。
具体的には、タイマRC機能でTRCIOAに出力、TRCGRAで10μsec周期を作りつつパルスの立ち下げと割り込み処理を、TRCGRCで9.5μsecの時点でパルスを立ち上げています。

どうやら10μsecもあればHX711の4個分のシフト処理は間に合うようです。

あとはメインループでHX711のデータ出力を監視し、4個全部の出力がLOWになったらタイマRCをスタート、タイマRCは1回分の入力処理が終わったら停止するように作り込んでいます。

といったところで、今回はこの辺で。

ゆっくりしていってみる2018年06月13日 08時00分

このところ仕事が色々大変だったり、仕事以外でもアレコレあったりしたので、ここらでちょっとゆっくりしてみたいと思います。

というわけで

ゆっ くりチップで遊んでみます。

ゴチャゴチャゆっくり

なんかごっちゃりしていますが、PCのターミナルとR8Cマイコンをつなぎ、R8Cマイコンからゆっくりチップにしゃべらせる構成になっています。
具体的にはこんな感じです。

R8CでPCとゆっくりチップの仲介

ゆっくりチップに対してローマ字風のコマンドを送ることで発声できます。
R8Cのソフトでは、受信割り込みでキューに入ったデータをメインループで横流ししています。

構造化アセンブラと当方オリジナルのマクロライブラリで記述していますので見慣れない感じだとは思いますが、だいたい理解していただけるのではないかと。
R8Cで仲介しなくてもPCのターミナルとゆっくりチップで直にやりとりもできるのですが(USB<->UART変換は必要)、次段への布石とい うことで。

さて

ゆっくりチップとのUARTによる通信にはいくつかのお約束があり、主なところはだいたい以下の通りです。

  1. ボーレートを認識してもらうため、最初に"?"を送信
  2. コマンドの最後にはキャリッジリターンをつける
  3. ">"が返ってくるまで次のコマンド送信は控える

ちなみに、発声中に次のコマンドを送ると"*"が返ってきます。

なので、その辺りの処理を実装すると、後の処理が楽になります。

$LOOP
  ; PC→ゆっくり
  PROC$_CALL S0R$_GET    ; 受信データ取得(→R0L)
  for S == OFF
    PROC$_CALL$_B YUKKURI_UART$_PUT, R0L
    PROC$_CALL S0R$_GET  ; 受信データ取得(→R0L)
  next
  ; ゆっくり→PC
  PROC$_CALL S2R$_GET    ; 受信データ取得(→R0L)
  for S == OFF
    PROC$_CALL$_B YUKKURI_UART$_GET, R0L
    PROC$_CALL S2R$_GET  ; 受信データ取得(→R0L)
  next
$END

;========================================================== PART$ YUKKURI_UART ;---------------------------------------------------------- ; メモリ確保 QUEUE$_B$_ALLOC yukkuri_send_queue, 128 ; 送信キュー確保 send_char: .blkb 1 ;========================================================== ; コンディション定義 CONDITION$_DEFINE S_ENABLE ; [送信可能] ; ステータス定義 STATE$_DEFINE YUKKURI_BUSY ; ビジー<[] STATE$_DEFINE YUKKURI_READY ; 送信受け付け<[送信可能] ;----------------------------------- ; ビジー<[] ;----------------------------------- STATE$ YUKKURI_BUSY, 0 _GET if [ PARAMETER ].b == '>' TRANS YUKKURI_READY endif _END ;======================================= ;[送信可能] ;======================================= CONDITION$ S_ENABLE _PUT QUEUE$_GET yukkuri_send_queue, [send_char] for C ; キューデータあり PROC$_CALL$_B S2T$_PUT, [send_char] if [ send_char ] == 0dh TRANS YUKKURI_BUSY endif QUEUE$_GET yukkuri_send_queue, [send_char] next _END ;----------------------------------- ; 送信受け付け<[送信可能] ;----------------------------------- STATE$ YUKKURI_READY, S_ENABLE REDIRECT _PUT _END _PUT ; 代替えキャラを元のコードに R0L = [ PARAMETER ].b if R0L == '!' R0L = 27h elif R0L == '$' R0L = 0dh endif QUEUE$_PUT yukkuri_send_queue, R0L THROW ; 後は STATE に投げる _GET PROC$_CALL$_B S0T$_PUT, [PARAMETER].b THROW ; 後は STATE に投げる _INIT QUEUE$_INIT yukkuri_send_queue PROC$_CALL$_B S2T$_PUT, "'?'" ; ゆっくりチップに同期コマンドを送る ;---------------------------------------------------------- _END ;==========================================================

といった感じです。

PART$というのは状態遷移処理を内蔵したオブジェクト的な物で、指定したメソッドをアクティブなSTATE$で処理するのが基本です。
メソッドの探査順はPART$→STATE$(アクティブ)→CONDITION$(アクティブ)となっており、対応メソッド処理が見つかった時点で打ち 切りますが、THROWで次段に投げることができ、REDIRECTで次段の別のメソッド処理に投げることができるため、非常にシンプルな記述が可能に なっています。

という、投げっぱなしな感じで今回はここまでです。


ターミナルから指示してみる2018年05月15日 06時00分

せっかくシリアルの送受信ができるようになったので、ターミナルからコマンドを入力して何かをやらせてみたいですね。

なので、ここまでの流れでLチカをターミナルから実行してみることにしました。
イメージとしてはこんな感じです。

ターミナルでLチカ

文字列を扱うのは面倒なのでコマンドは1文字とし、リターンキーで実行します。
"S"コマンドは数値を入力すると点滅時間の設定となり、コマンドのみでは現在の設定値を返すようにします。
そのため、LED_CONTROLには_GETアクションを追加しました。

そんなところで

いきなりソースです。

;==========================================================
PART$ TINY_TOKENIZER
;----------------------------------------------------------
ENUM$_SET 0
ENUM TYPE_CHAR
ENUM TYPE_NUM
ENUM TYPE_SPACE
ENUM TYPE_ENTER
ENUM TYPE_BS
ENUM TYPE_ESCAPE
C_BUFF_SIZE  .equ  10
c_type:      .blkb  1
c_index:     .blkb  1
c_buff:      .blkb  C_BUFF_SIZE
;==========================================================
  ; コンディション定義
  CONDITION$_DEFINE C_NANIKA  ; [何か入ってる]
  ; ステータス定義
  STATE$_DEFINE TKN_NULL      ; 何もない
  STATE$_DEFINE TKN_NUM       ; 数値<[何か入ってる]
  STATE$_DEFINE TKN_CHAR      ; 文字<[何か入ってる]

  ;-----------------------------------
  ; 何もない
  ;-----------------------------------
  STATE$ TKN_NULL, 0
    ; エントリー処理
    [ c_index ] = 0
  _PUT
    if [ c_type ] == TYPE_CHAR
      TRANS TKN_CHAR
    elif [ c_type ] == TYPE_NUM
      TRANS TKN_NUM
    endif
  _GO
    ; ヘラルドさんに実行を通達(命令が伝わっているかどうかは知らない)
    PROC$_CALL HERALD$_GO      
  _BACK
    ; ヘラルドさんに後退を伝える(後退できるかどうかは知らない)
    PROC$_CALL HERALD$_BACK    
  _ESCAPE
    ; ヘラルドさんに撤退を伝える(撤退できるかどうかは知らない)
    PROC$_CALL HERALD$_ESCAPE  
  _END

  ;=======================================
  ;[何か入ってる]
  ;=======================================
  CONDITION$ C_NANIKA
  _GO
    PROC$_CALL HERALD$_VALUE  ; ヘラルドさんにトークンを与える
    PROC$_CALL HERALD$_GO     ; ヘラルドさんに実行を通達
    TRANS TKN_NULL
  _BACK  ; BS 入力
    [ c_index ] = -- [ c_index ]
    if Z  ; 何もなくなった
      TRANS TKN_NULL
    endif
  _VALUE  ; トークン抽出
    PROC$_CALL HERALD$_VALUE  ; ヘラルドさんにトークンを与える
    TRANS TKN_NULL
  _ESCAPE
    TRANS TKN_NULL
  _END

  ;-----------------------------------
  ; 数値<[何か入ってる]
  ;-----------------------------------
  STATE$ TKN_NUM, C_NANIKA
  _PUT
    if [ c_type ] == TYPE_CHAR
      REDIRECT _ESCAPE  ; 俺はいらない
    endif
  _END

  ;-----------------------------------
  ; 文字<[何か入ってる]
  ;-----------------------------------
  STATE$ TKN_CHAR, C_NANIKA
    ; 俺は知らない
  _END

_PUT
  ; キャラクタータイプ判定
  [ c_type ] = TYPE_ESCAPE
  R0L = [ PARAMETER ].b
  if R0L <= 'z'
    ; コードの大きい方から判定
    if R0L >= 'a'  ; 小文字
      R0L = R0L - 20h    ; →大文字
      [ c_type ] = TYPE_CHAR
    elif R0L > 'Z'  ; Z より後ろ
      ; エスケープ扱い
    elif R0L >= 'A'  ; 大文字
      [ c_type ] = TYPE_CHAR
    elif R0L > '9'  ; 9 より後ろ
      ; エスケープ扱い
    elif R0L >= '0'  ; 数字
      [ c_type ] = TYPE_NUM
    elif R0L == ' ' || R0L == 0ah || R0L == 09h  ; SPC, LF, TAB
      [ c_type ] = TYPE_SPACE
    elif R0L == 0dh  ; CR
      [ c_type ] = TYPE_ENTER
    elif R0L == 08h  ; BS
      [ c_type ] = TYPE_BS
    endif
  endif
  ; キャラクタータイプに応じて処理を指示
  if [ c_type ] == TYPE_NUM || [ c_type ] == TYPE_CHAR
    if [ c_index ] < C_BUFF_SIZE
      mov.b c_index, A0
      [ c_buff[A0]] = R0L
      [ c_index ] = ++ [ c_index ]
      THROW  ; _PUT
    else ; バッファオーバー
      REDIRECT _ESCAPE
    endif
  elif [ c_type ] == TYPE_ENTER
    REDIRECT _GO
  elif [ c_type ] == TYPE_BS
    REDIRECT _BACK
  elif [ c_type ] == TYPE_SPACE
    REDIRECT _VALUE
  else
    REDIRECT _ESCAPE
  endif
;----------------------------------------------------------
_END
;==========================================================

;==========================================================
PART$ HERALD
;----------------------------------------------------------
;==========================================================
  ; コンディション定義
  CONDITION$_DEFINE C_WAIT_PARAM  ;[パラメータ待ち]
  CONDITION$_DEFINE C_READY       ;[準備完了]
  ; ステータス定義
  STATE$_DEFINE H_WAIT            ; 待機<[]
  STATE$_DEFINE H_B_CYCLE         ; 点滅周期<[パラメータ待ち]
  STATE$_DEFINE H_ON_READY        ; 点灯準備<[準備完了]
  STATE$_DEFINE H_OFF_READY       ; 消灯準備<[準備完了]
  STATE$_DEFINE H_BLINK_READY     ; 点滅準備<[準備完了]
  STATE$_DEFINE H_B_CYCLE_READY   ; 点滅周期<[準備完了]

  ;-----------------------------------
  ; 待機<[]
  ;-----------------------------------
  STATE$ H_WAIT, 0
  _VALUE  ; トークン
    R0L = [ c_buff ]
    if   R0L == 'O'    ; LED 点灯指令
      TRANS H_ON_READY     ; 点灯準備<[準備完了]
    elif R0L == 'F'    ; LED 消灯指令
      TRANS H_OFF_READY    ; 消灯準備<[準備完了]
    elif R0L == 'B'    ; LED 点滅指令
      TRANS H_BLINK_READY  ; 点滅準備<[準備完了]
    elif R0L == 'S'    ; LED 点滅時間 設定/返答
      TRANS H_B_CYCLE      ; 点滅周期<[パラメータ待ち]
    else
      RET$_FALSE
    endif
  _END

  ;=======================================
  ;[パラメータ待ち]
  ;=======================================
  CONDITION$ C_WAIT_PARAM
  _BACK  ; 後退
    TRANS H_WAIT
  _ESCAPE  ; 撤退
    TRANS H_WAIT
  _END

  ;-----------------------------------
  ; 点滅周期<[パラメータ待ち]]
  ;-----------------------------------
  STATE$ H_B_CYCLE, C_WAIT_PARAM
  _VALUE  ; パラメータ来た
    CHAR2VAL$_CALC c_buff, [c_index].b  ; 数値文字列→数値
    TRANS H_B_CYCLE_READY
  _GO    ; パラメータなし
    PROC$_CALL LED_CONTROL$_GET  ; 現在の設定値→R0
    VAL2CHAR$_UW R0       ; 符号なしでキャラクター変換
    VAL2CHAR$_GET R0L     ; 変換したキャラクターを順次受け取る
    for R0L != -1
      PROC$_CALL$_B S0T$_PUT, R0L   ; シリアルにキャラクターを送る
      VAL2CHAR$_GET R0L             ; 変換したキャラクターを順次受け取る
    next
    PROC$_CALL$_B S0T$_PUT, 0dh     ; [CR]
    TRANS H_WAIT
  _END

  ;=======================================
  ;[準備完了]
  ;=======================================
  CONDITION$ C_READY
  _VALUE  ; もうパラメーターはいらない
    TRANS H_WAIT
  _BACK  ; 後退
    TRANS H_WAIT
  _ESCAPE  ; 撤退
    TRANS H_WAIT
  _END

  ;-----------------------------------
  ; 点灯準備<[準備完了]
  ;-----------------------------------
  STATE$ H_ON_READY, C_READY
  _GO
    PROC$_CALL LED_CONTROL$_ON
    TRANS H_WAIT
  _END

  ;-----------------------------------
  ; 消灯準備<[準備完了]
  ;-----------------------------------
  STATE$ H_OFF_READY, C_READY
  _GO
    PROC$_CALL LED_CONTROL$_OFF
    TRANS H_WAIT
  _END

  ;-----------------------------------
  ; 点滅準備<[準備完了]
  ;-----------------------------------
  STATE$ H_BLINK_READY, C_READY
  _GO
    PROC$_CALL LED_CONTROL$_UNIQUE
    TRANS H_WAIT
  _END

  ;-----------------------------------
  ; 点滅周期<[準備完了]
  ;-----------------------------------
  STATE$ H_B_CYCLE_READY, C_READY
  _GO
    CHAR2VAL$_GET$_W R0      ; パラメータの数値取得
    PROC$_CALL$_W LED_CONTROL$_SET, R0
    TRANS H_WAIT
  _END
;----------------------------------------------------------
_END
;==========================================================

イメージでは解析器は1つにしていましたが、実際には2段階になっていて、この辺りは字句解析→構文解析のお約束ですね、多分。

呼び出し部分のソースは掲載していませんが、シリアルで受信した文字をTINY_TOKENIZERに_PUTすることで動作します。

TINY_TOKENIZERはパート部分でキャラクタータイプの判定だけを行い、文字か数字ならバッファに入れて、あとはアクティブステートに投げます。
その際、キャラクタータイプによって後に続く処理が限定されるので、処理をリダイレクトします。
例えば[CR]が来た場合は何かを実行することになりますので、アクティブステートに対して_GOを投げるといった具合です。

区切りとなる文字が入るとトークンが確定しますので、後処理であるHERALDに投げます。
変数渡しなのがちょっとアレですが、アセンブラですのでご容赦ください。

HERALDは受け取ったトークンが有効なコマンドなら対応する状態に遷移します。
で、受け取った指示とその時の状態によってやることが変わるわけで、状態遷移処理の真骨頂と言えると思います。

そしてお約束の

デバッガ画面です。

S コマンド動作結果

今回はソースコード量に比べて説明がアッサリ過ぎますが、この辺で。

シリアル カンタービレ2018年05月12日 06時00分

とても昔からあって、今でも便利に使い続けられている技術。
それは俗にシリアルとかターミナルとか呼ばれているやつです。

以前少しだけarduinoをいじってみたんですが、標準でターミナルが実装されいて、コマンドを送ったりデータを表示させたりといったことが簡単にできるのが印象的でした。

そんなわけで

随分以前に写真だけ公開した基板をようやく動かす時が来ました。
実は通電するのも初めてだったりします。

いろいろシリアル基板

そして、まずはシリアル送信を試してみます。

$LOOP
  ; タイミング処理
  btstc SYSTEM_CYCLE  ; 1msec毎にONされる
  if C
    DIVIDING$_ regular_10, 10  ; 10分周
      PROC$_CALL$_B S0T$_PUT, 30h
      PROC$_CALL$_B S0T$_PUT, 31h
      PROC$_CALL$_B S0T$_PUT, 32h
    _$
  endif
$END

; シリアル送信処理
S0T$ 1
  QUEUE$_B$_ALLOC send_queue, 20    ; 送信キュー確保
_ITP  ; 送信終了割り込み(レジスタバンク切り替え)
  QUEUE$_GET send_queue, R0L
  if C
    WRITE$_B R0L
  endif
_PUT
  if [ ti_u0c1 ]  ; 送信バッファ空
    WRITE$_B [PARAMETER].b
  else      ; 送信中
    ; 送信データをキューに入れる(満杯の場合は空くまで待つ)
    QUEUE$_PUT$_WAIT send_queue, [PARAMETER].b
  endif
_INIT
  QUEUE$_INIT send_queue
_END

10msec周期で3バイトのデータを送り続けるだけの簡単なお仕事です。
簡単と言いつつ、送信バッファが空なら直に送信し、そうでなければキューに入れるという小技も使っています。
そして、キューにいれておけば、送信終了割り込みで勝手に持って行ってくれるという寸法です。

結果はこんな感じ。

データを送り続けるだけの簡単なお仕事

狙い通り、10msec周期できっちり送信されていますね。
ちなみに、通信速度設定は9600bpsです。

気分のほうが乗ってきたので

受信もやってみます。

パソコンのターミナルソフトから送ってみて・・・・・・・・・・・・・・・・・・・・・・・・・・受信できません。

一応、受信割り込みは1回かかるのですが、2回目以降は反応なし。
よく見るとフレームエラーが出ていましたが、速度・ストップビット・パリティの設定は間違っていないし、何故?

で、信号をよく見てみると・・・

電圧が低いし

信号は問題無さそうですが、電圧が3V少々ですね。

実は、使っているUSB-シリアル変換モジュールの出力(マイコン側では入力)が3.3V系なんですが、入力は5V対応なので5V電源のマイコンともそのまま接続できるということだったので気にしていませんでした。

しかし、R8C/xMの5V電源時のH入力閾値には届かないようですね。
受信割り込みはかかったので、オーバーシュート分が微妙に届いている感じなんだと思います。

そこでレベル変換です。
変換ICを乗せる程のことでもないので、トランジスタを使いました。

トランジスタでレベル変換

改めて信号を確認してみると、ちゃんと5V付近まで上がっています。

受信電圧が5Vにアップ

ソフトの動作はこちらです。

ソフトでも受信を確認

これでようやく準備が整い、あとはパソコンからコマンドを送って・・・と行きたいのですが、字句解析とかやったことがないので、どうなりますやら。