ゴミデータが残っちゃう
今日は先週末に発見したバグを修正していた。
マイコンの通信ペリフェラルに関するバグなのだが、意外なバグだったので。
このシステム、送信中に特定の事象が発生した場合は、その時点で送信を停止する仕組みがある。
ただ、この送信を停止する条件というのは、通常あまり考えられないことで、さらに言えばなにもせずとも受信側で破棄されるはず。
だから、この仕組みの必要性はよくわからないのだが、現行品にある仕組みだし、特に害があるわけでもない。
それで実装したのだが、送信中を停止するということにちょっと問題があったわけだ。
どういう問題かというと、次の送信時、最初に1バイトのゴミデータが付いてしまうのだ。
あれ? 送信停止時にFIFOクリアはしたはずなのにと思った。
このマイコンの通信ペリフェラルは送受信用のFIFOを備えており、数バイト分の送受信データを格納することができる。
送信停止した時点で、FIFOに格納された送信予定のデータはクリアしたのに、ゴミデータが1バイト残ってしまったと。
おかしいなぁ、とマイコンのペリフェラルマニュアルをよく見ていたところ理由がわかった。
FIFOとは別にある送信バッファに1バイトだけ送信予定データが残っていて、これだけ消せていなかったのだ。
どんなマイコンの通信ペリフェラルでも1バイト分の送受信バッファは備えているはず。
送信時、送信バッファからデータが転送されると、送信バッファエンプティフラグが立つ。
エンプティフラグで割り込みを発生させたりして、次の送信データを格納する。
前のデータの送信完了までに格納完了できれば、切れ目なく次のデータの送信に移れるわけである。
FIFOを使う場合は、FIFOから送信バッファへの転送を自動でやってくれるが、原理的には同じこと。
こういう仕組みなので送信中はほぼ常に1バイトのデータが格納されているわけだけど、
送信中に送信中断すると、1バイトのデータがバッファに残った状態になる。これが次に送信するときに吐き出されてしまうようだ。
いろいろ調べたところ、このマイコンの通信ペリフェラルでは送受信バッファを単独でクリアする手段はないようだ。
ただ、通信ペリフェラル全体をリセットする機能があるので、これを使えば送受信バッファを含めて全てが初期状態に戻る。
送信を中断するような事象が発生したときは、受信も停止するので、送受信の両方を初期化しても不都合はない。
というわけで、送受信停止を通信ペリフェラルのリセットに置き換えたところ、この問題は解決したのだった。
送信中に送信を中断するというのは、あまりやらないんじゃないかなぁ。普通は送りきるところまではやるだろう。
一方で、同製品のアセンブラ時代の設計を掘ってみると、送信の中断の実現方法が違うんだよね。
この当時は1バイトずつデータを送信バッファに格納してるんだけど、送信バッファへの格納をやめるという方法で送信を中断している。
すなわち、バッファにあるデータを吐き出しきったところで送信中断する仕組みになっていた。
意図してか、意図せずかはよくわからないが、同種の問題は回避出来るようになっていた。
今回も同様の解決法でいけるのでは? と思ったが、FIFOとの兼ね合いを考慮するとなかなか難しいので、全部リセットするという方法で解決した。
それにしても、なぜ送信バッファを単独でリセットする仕組みがないのだろうか?
いろいろ考えてみたのだが、おそらく上書きすることが可能だからだろうな。
すなわち、ゴミデータが送信バッファに入った状態でも、送信データの1バイト目を送信バッファに転送→送信開始とすれば、
ゴミデータを追い出した上で1バイト目のデータから送信できる。
これを 送信開始→1バイト目をバッファに転送 とすると、送信開始の時点で格納されているゴミデータが吐き出されてしまうのだが。
だから、一応は回避策はあると。やや複雑な操作が必要になるケースもあるかもしれないが。
似たような話が受信バッファでもあって、
- フレーミングエラーが発生して割り込み発生
- エラーはクリアして、受信も停止する
- 通信状態を初期状態に戻して、受信を再開する
- 受信を再開した途端に、受信割り込みが発生して、受信バッファからゴミデータを取得する
これ、2.の時点で受信バッファを空にし忘れたのが原因なんだよね。ゴミデータが残ったまま受信を再開しちゃったと。
他のシステムの同種の処理を確認してみると、後で受信バッファのダミーリードを追加した痕跡があった。
わりとハマりがちなミスなんだなと思いつつ、同じ方法で解決したが。
Author : hidemaro
Date : 2018/10/10(Wed) 22:13
電気・数学・物理 | Comment | trackback (0)
デバッグは順調なんだけど
おととい試作品を入手して、デバッグして、一通りの機能の動作確認ができたので、今日から結合テストに入った。
大した機能がないので、結合テストというほどか? という感じもあるけど。
形式上はここまでの動作確認とデバッグが単体テスト、それが完了したから結合テストという説明はできる。
ハードウェアに依存しない機能はすでにエミュレータでの単体テストで一通り見た。(cf. エミュレータでの単体テストは好調)
試作品入手後から今までに修正したバグは全てハードウェアに依存する部分の問題だった。
一番多かったのがレジスタの設定ミス。ハードウェア設計終盤でポート割り付けが変わったのが反映されてなかったのもあった。
次に多かったのが正論理と負論理を間違えていたところ。
わりと気づきやすいミスではあって、回路図の理解が間違えていたり、途中で設計変更されたりして発生したようだ。
逆に原因が追いにくかったのが、処理順序のミス。
特定の条件のとき、シリアル通信でフレーミングエラーが起きまくるので、波形を測定したら正しい波形で、
なんでこれでフレーミングエラーになるんだ! と思ったら、受信開始のタイミングが間違えて、通信を途中から取り始めていたとかね。
よく考えれば当たり前のことなんだけど、実機を持って来ないと気づきにくい。
タイミングチャートには正しくかかれているのに、実装が間違えてるとかね。
マイコンがプログラムが書かれないとクロックの発振すら始まらないということで、
ハードウェアの動作確認もマイコンのデバッグをしながらやることになったが、
詳しい測定などはしていないが、ほとんど問題なく動いているように見える。
とはいえ、回路定数に1箇所ミスがあるのは発見しているし、他にも1箇所怪しいところもあるので調査するべきと考えている。
そこはハードウェア評価で早々に解決して欲しいと思っているのだが、どうもハードウェア評価の準備が遅れているようだ。
試作品は届いたが、それを動かすための周辺器具などが遅れているようで、
現時点で全て揃っているのが1つしかなく、これをマイコンのデバッグ用に使っているからというのが1つ。
この試験系を構築したのは主に僕なんですけどね。設計変更前の現行品の挙動を調べるために作ったんだけど。
もう1つの要因が評価計画の作成が遅れているから。担当者の夏休みが9月に集中したのもあるようだが。
というわけで、試作品到着後に評価計画のレビューをやりはじめるという。
本来は試作品が来る前に段取りをしてやるべきだと思うんですけどね。
そのレビューも試験系の妥当性で紛糾するという。
まだ、ハードウェアの評価計画は承認されないままで、開始は遅れそうだ。
ハードウェアの修正をしないとなにも進められないという状況ではないのが幸いだが、
お互い同時進行で進むと思っていたら、マイコンが先行し、ハードウェアの方が遅れることになりそうだ。
ハードウェアの問題を発見する可能性も高くなるが、まぁ仕方ないか。一蓮托生だ。
Author : hidemaro
Date : 2018/09/28(Fri) 23:11
電気・数学・物理 | Comment | trackback (0)
遅くてもROM書き換えできるだけマシ
工場で基板に実装済みのROMを書き換えたいという話が出ている。
以前もあった話で、手順を教えてやってもらったところ、失敗したという経緯がある。
(失敗した基板は製品にできないので捨てられた)
この基板に実装済みのROMを書き換えるのは複数のデバッグ機能を組み合わせて使う都合、いろいろな問題がある。
- ROM書き換えに使うデバッグ用ツールの操作が煩雑
- ROM書き換えに約30分かかる(その代わり、同時に十数枚の書き換えができる)
- 同時に複数枚書き換えても、ベリファイは代表の1枚にしか行われない
1.は工場で失敗した最大の要因だ。開発者にとっても操作がめんどくさくて困っている。(使用頻度はさほど高くないが)
2.はROMデータの転送が遅いんだよね。アーキテクチャ的な問題もあるのだが、デバッグ用機能だったというのもある。
デバッグ機能なので転送速度は求めておらず、他の機能に干渉しないことを重視しているというのもある。
これでも改善した方で、当初は同時に1枚だけしかできず、1枚で約30分ということで本当に割に合わなかったが、
補助器具を用意することで、複数枚同時にROMデータの書き込みができるように改良され、フル実装すれば1枚あたり2分程度でそれなり。
ところが、その代償として、3.に書いたベリファイが不十分という問題が生じた。
次に工場でROM書き換えするときにはこの問題を解決しないとなぁということで、こういう対策をすることになった。
- デバッグ用ツールのサブセットとして、ROM書き換え専用ツールを作る
- データ転送シーケンスの見直し + ベリファイをターゲットボード上でやらせる
- 補助器具を改良して、ライトは一括、リードは個別でできるようにする
1.は工場で失敗したという話を聞いたときに作りかけていたので、これを完成させて使ってもらうことにした。
2.の対策は2つある。
1つはデータ転送に専念させることで高速化しようということ。少し速くなった気もするが、残念ながら、期待したほどの差は出なかった。
転送方式を抜本的に見直せば、高速化できそうなんだけど、そこまで無理しなくていいかなと。
もう1つが全体のおよそ半分を占めるベリファイを、書き込んだROMデータをPCに吸い上げてチェックする方式から、
ターゲットボード上でマイコンにチェックさせる方法に改めた。これだとチェック結果をリードするだけなので、圧倒的に速くなる。
この対策をすることで、3.のベリファイが1枚しかできないという問題も解決できると思っていた(時間だけの問題だと思っていた)のだが、
補助器具の設計にも問題があったので、リードは1枚ずつ個別にできるように改良した。
この改良の結果、ROM書き込みに要する時間は十数分となってほぼ半減した。フル実装すれば1枚あたり1分未満だ。
さらに全部にベリファイができるようになって、信頼性が高まるのかな?
ここでしくじっても、この後の製造検査でROMの検査もするので、大丈夫だと思うけどね。
とはいえ、普段、ROMライターで書き込む時は1つずつベリファイやってるんだから、1枚ずつベリファイするのがあるべき姿なのは言うまでもない。
ところで、マイコンが自身のROMを書き換える場合、書き換え用のプログラムをRAMに置く必要がある。
なので、こういう手順でROMの書き換えを行っている。
- メンテナンスモードに切り替える
- フラッシュドライバのプログラムデータを転送して、RAM上に展開する
- RAM上のフラッシュドライバにジャンプする
- ROMのプログラムデータを消す
- 書き換え用のプログラムデータを転送して、ROMに書き込む
- 書き込み完了後にROMデータのCRCを計算する (★今回追加)
- ソフトリセットを行い、ROMから通常通りに起動させる
1～3は書き換え前のマイコンにあるプログラムの機能で、4～7は2.で転送したフラッシュドライバの機能で実現されている。
けっこう複雑な仕組みなのだけど、少なくとも1～3の機能はあらかじめ作り込まれていないと通信経由での書き換えはできない。
仕組みを知っている人にとっては当たり前なのだが、工場の人はこういう背景を知らないので、
なにも書き込まれていないROMにこの方法で書き込めると思ったようだが、そういう風には作っていない。
基板実装後にまっさらのROMに書き込む方法もあるけど、工場で使うことは全く想定されていない。
工場で使うことを想定していないのは、大量生産を考えるとROMライターで書き込む方法にはかなわないという事情もある。
ただ、工場としては、ROMライターで書いて、プリント版に実装して、とやるのは管理上めんどくさいのも確からしい。
だから臨時で、基板実装後にROMを書き換えたいという要望が来たんだけど。
でも、そのために非定常作業が発生するのはどうなんですかね? 僕はそっちの方がめんどくさいと思うんだけど。
こちらは技術的に可能だし、ツールの改良はもともと着手していたので、じゃあ準備しますという話だけど。
Author : hidemaro
Date : 2018/09/19(Wed) 20:47
電気・数学・物理 | Comment | trackback (0)
こちらがチェッカー
最近、チームリーダーが書いたドキュメントをチェックすることがしばしばある。
チームリーダーも「本当は逆なんだけどなぁ」と言いながら渡してくるのだが、
設計などについて実効性を持ったチェックをやるにはこれが最適という判断だろう。
この職場のチームリーダーはドキュメントをチェックすることのできる人である。
細かい設計なども把握して、善し悪しについて判断できる経験豊富な技術者がその役割を担っている。
ところが、チームリーダー自身がドキュメントを書いてしまうと、チェックするべき人がいなくなるという問題が発生する。
他のチームリーダーにチェックしてもらうか、課長にチェックしてもらうかという話だが、
実効性を持ったチェックになるかという点が問題だ。
部署内でマイコン関係の設計をチェックできるチームリーダーは2人ぐらい。
もう1人はいるので、他のチームリーダーにチェックしてもらうという手もありそうだが、
主にやっている製品が異なるので、詳細を把握してチェックしてもらうのは労力がかかる。
忙しい人ですから、チェック依頼をしても、ものすごい時間が取られそうだ。
以前は課長にチェックしてもらうこともあったようだが、これは当時の課長がマイコン開発の経験があったから。
実際、ダブルチェックとして十分かというのは疑問だったようだが、それでも有識者のチェックは通っているとは言えた。
ところが課長が代わって、マイコンまわりの設計を課長自身がチェックするのは現実的ではなくなった。
本来は設計をチェックするのはチームリーダーの役目なので問題ないのだけど、
チームリーダー自身の設計をチェックする人がいないという問題が顕在化してくる。
そこで、チームリーダーはこのような方法で対応することにした。
- チームリーダーがドキュメントを下書きする
- 僕がその内容をチェックして、必要に応じて修正する
- 2.で完成したドキュメントをチームリーダーがチェックする
- チェック完了後、課長の承認によりドキュメントが発行される
2.によりドキュメントの作成者は形式上は僕になる。これにより自分が下書きしたドキュメントもチェックできるというわけ
こんなのアリなの? と思うが、実効性を持ったダブルチェックを行うにはこれしかないのも実情。
というのも、この製品のマイコンまわりの設計がある程度わかって、今すぐつかまる人が僕ぐらいしかいないんだよね。
ごく小さな設計変更だが、僕はその変更対象の製品そのものの開発に関わった経験があるわけではない。
とはいえ、同種の違う製品の開発には深く関わっているので、その延長線上で対応できるのも確かだし、
設計まではチームリーダーがやってしまったが、その後の評価などは僕が担当する予定もあった。
これがチームリーダーが僕に実質的なチェックを依頼した理由なのだろう。
何らかの形でダブルチェックは必要だと考えているが、通常のルールでは難しいって話なんですかね。
僕がこの職場に来てしばらく経って、マイコンまわりの開発が一気にしぼんでしまった。
そんなこともあって、仕事も少ないが、やる人も少ないという状況になってしまった。
仕事の分担で苦慮しているのもここら辺の背景があるんだろうとは認識している。
Author : hidemaro
Date : 2018/09/12(Wed) 23:26
電気・数学・物理 | Comment | trackback (0)
交流送電は道連れ
昨晩23時までかけて関空から利用者のほぼ全員を運び出し(なんと7800人も運んだらしい)、
関空は気がかりではあるけど、他の鉄道や幹線道路は復旧してきているし、停電も解消してきている。
というわけで、まだ復旧しきっていないところもあるけど、関空以外は段々と日常に戻っていくのだろう。
……と思っていたら、朝起きたら北海道で大地震、それだけならともかく道内全域で停電というとんでもない状況になっていた。
こんな状況なので台風のニュースをやるどころではなく、北海道の地震のニュース一色だった。
なぜ、道内全域停電になってしまったのだろう。
震源近くの発電所が緊急停止した結果、系統の周波数が下がり、他の発電所も停止してしまったからだと説明されている。
周波数が下がると停止するのは、その発電所の設備を守るためのやむを得ない措置のようだが、
そもそもこういう事態が起こること自体が異例のことだ。
地震の被害で緊急停止した発電所が、その時間帯の北海道の電力供給の半分を担っている石炭火力発電所なのが悪かった。
これはこの後の復旧にも尾を引くことになる。
系統の周波数というのはとても重要だ。
というのも同じ系統にある全ての同期発電機は全て同じ周波数で回転しているからだ。
すなわち、1つの発電所だけ勝手な回転数で回すことはできない。これが道連れになった大きな要因だ。
さらに言えば、発電所は系統に電力が供給されていることを前提としたものもある。
風力発電所とかそうなんじゃなかったかな。
発電所じゃないけど、北海道～本州の直流送電もそうで、電力を受ける側の系統は電力が供給されている必要がある。
と、交流送電というのは難しい。変圧器で簡単に電圧を変えられるのはメリットではあるけど。
まずは水力発電所から立ち上げ、隣接する地域の火力発電所を立ち上げ、
そして函館あたりまで復活したら、本州からの直流送電ができるようになる。
それでも被災した石炭火力発電所が復旧しないと、ピーク時の需要に応えるのは難しいようだが。
これが起きたのが冬じゃなかったのが不幸中の幸いで、
冬だとただでさえ避難に苦慮するのに、その上、停電で暖房もままならないような状況になっては大変だった。
もしかすると、長期停止中の泊発電所(原子力)が稼働していれば、こんなことにはならなかったかもしれない。
泊発電所は今回の震源からも離れていたので、そのまま発電を継続できたはずで、稼働していれば夜間の供給のメインだったはずだし。
とはいえ、北海道程度の規模だと、大規模な発電所が数基同時にやられると全域停電に追い込まれてしまうのは現実で、
地震の起きる場所と、大きな発電所の位置関係では、本質的にこういう問題は回避出来ないのかも知れない。
いくら発電設備があっても、急に出力を増やすのは限度がありますから。急に調整できるのは水力発電所ぐらいらしいし。
こういうことはめったに起きることではないけど、本当にどうにもならないときには起こるという現実は理解しなければならない。
少なくとも、送電を復旧していく中で供給力が足りないという問題は、大規模な発電所が他にあれば回避出来たと言える。
泊発電所はもちろんだけど、もう1つ惜しいのが建設中の石狩湾新港発電所だ。
石狩湾新港発電所は大規模なLNG火力発電所で、1号機が来年2月の営業運転開始予定になっている。
意外にも北海道電力にとっては初めてのLNG火力発電所なのだという。土地柄もあって火力は石炭がメインのようで。
最新鋭の発電所は熱効率もよく、老朽化した火力発電所を整理するような役割も期待されているようだ。
あと少し後ならば、石狩湾新港発電所も大きな力になれたんだけどなぁ。
関空が高潮で冠水するのも、北海道が全域停電に追い込まれるのも、どっちもめったにあることではない。
十分な備えをしていたのも関わらず、その想定を大きく超えたということだ。
後でこういう備えができたんじゃないかと言われるけど、起きた後だからこそ言えることもありますから。
自然災害による被害は防げるなら防いだ方がいいけど、完全に防げないのは現実で、そこは責めても仕方ない。
関空なんて、あんな状況でうまいことやった方だと思いますけどね。復旧まで時間がかかるのは気がかりだけどさ。
Author : hidemaro
Date : 2018/09/06(Thu) 22:38
電気・数学・物理 | Comment | trackback (0)
世界各地で売るか日本だけで売るか
昨日は大学院時代の知り合いに会った。
大半は技術者として働いていて、その中でも製品開発に従事している人が多い。
ところが違えば仕事の仕方にも差があって、その中でも顕著だったのが規格対応だよね。
どこで売るかというのが顕著に表れるところなので。
実は、僕の勤務先では新製品は基本的には世界各地で販売される。
これがとても大変で、というのも各国の法規制などに適合しなければならないから。
また、想定される用途によってな特殊な規格に対応する必要があったり、
法規制というのは、勤務先の製品開発で非常に重いウェイトを占めている。
技術的な難しさというよりは手続きの問題という側面もあるが、一方で一部の規制は技術的にも難しく、大変苦慮している。
ところで、電子機器の法規制は日本はとても緩いと言っていいと考えている。
分野によるが、関わっている製品群では日本の法規制対応は皆無とされており、
一部の製品は日本国内限定となっているが、これは何の法規制対応も行っていないという意味。
全てにおいてそうだとは言わないけど、日本の法規制で技術的に難しいという話はあまり聞かない。
日本国内の規格も国際規格と同じ内容になるようにするなど、日本独自の技術的要求は少なくなる傾向にある。
というわけで、日本というのは外国メーカーの製品も入ってきやすく、選びやすいと言える。
僕はいいことだと思ってるけどね。世の中、不条理な規制をやっている地域も多いから。
ということは、日本国内だけで商売をやっているところは、規格適合の手間はほとんどかかっていない。
その代わり、お役所相手の特別な要求に応える製品を作る必要があったり、
ローカル企業ならではのきめ細かい対応を行うなど、また違ったところに特徴がある。
あと、外国向けもあるけど、この製品はこの地域の規制には対応しないなどの割り切りを行っているところもあるようだ。
確かに売れなければ対応しても無意味ですからね。
うちの勤務先ではあまりそういうやり方してないけど、実際に売れるからでしょうね。
グローバル企業という言葉があるけど、本当に世界中で商売するということは難しい。
独自の商慣例、独自の法規制、そういうのに対応していかないといけない。
国によっては政府系の仕事を取るには、地元の雇用状況とか、そういう要求もあり、単に製品だけの問題ではない面もある。
その全てに対応するのは難しいが、可能な範囲で世界各地のニーズに応えていきたいという考えはある。実際、ニーズはありますから。
製品開発という点では、法規制対応のめどが立たないと製品として出せない(一部地域、一部用途は後日対応というやり方はある)
というのは確かで、それに開発のリソースを一定割かなければいけなくて、スピード感のある開発が難しくなっている面はある。
だから、そこで小回りが利くローカル企業というのはとても重要だなと思っていて、
特に日本だと市場規模も大きいですから、国内メインでも大きな会社はいくらでもありますからね。
商売の種類にもよるけど、必ずしも世界に打って出なければならないということもなく、むしろ出ないほうがいいこともある。
あと、全世界に出る必要も必ずしもなくて、この地域内でという対応でよい例もある。
勤務先のメインの商売は、どうしても日本から外国に出て行かないといけない商売でしたから。
じゃあトコトンやろうということでやった結果、それなりに成功を収めているんじゃないでしょうか。
全てが全てよい方向に行っているとも言えないのは確かでしょうけどね。
逆に日本メインで長く商売してきたがために、日本では売れるが、それ以外の地域ではさっぱり売れない製品というのもある。
そういうのをなんとか整理していきたいという思いもあるが、どうしても日本のお客さんは多いので、うまく整理できないのが実情だ。
どれも正解なんだけど、見えている正解が会社によって全く違うというのはおもしろい話。
国内の規制がゆるい分、他国の規制にどこまで対応するかというのは特徴が出やすい。
そんな答えもあるんだというのは聞いてて思ったけどね。
Author : hidemaro
Date : 2018/08/05(Sun) 21:25
電気・数学・物理 | Comment | trackback (0)
どうやって光に載せてるの?
ふと気になったんだけど、光伝送方式のケーブルテレビってどうやって実現されてるんだろ?
インターネットとテレビの情報を1本の光ファイバーに重畳して送る一方で、
光終端装置(ONU)をテレビ用とインターネット用と分けて設置することもあり、それぞれ独立して動作をできると言う。
まず、インターネットとテレビの伝送が独立してできるのは、それぞれ使う光の波長が違うから。
インターネットとテレビの伝送に使われる光ファイバーには3種類の波長の光が流れている。
インターネットの下りが1490nm, 上りが1310nm、そしてテレビが1550nmとのこと。(テレビは下りしかない)
波長が異なる光信号同士は独立して使えるので、それぞれの干渉は考えなくて良い。
その上でテレビの信号はどうやって光ファイバーを流れているのかというと、実はアナログ変調らしい。
テレビの信号は70MHz～770MHz(地上波・CATV) , 1000MHz～2071MHz(BS・CS)の帯域を含んでいるが、
これを波長1550nm(193THz)の光を搬送波として、AM変調またはFM変調をして伝送しているようだ。
一般的にはAM変調だが、フレッツ・テレビでは雑音に強いFM変調を使っているようだ。その分、送受信の装置は複雑になるけど。
AM変調では帯域幅Bの信号を伝送するのに、2Bの帯域幅を使う。テレビ信号の帯域幅は2GHzなので、帯域幅4GHz必要となる。
ところが搬送波の周波数が193THzとかなので、使う帯域幅は無視できるほど小さい。
というわけで、今後の4K放送にも光伝送方式のケーブルテレビは比較的容易に対応できる予定だ。
4K放送用のBS・CS左旋の信号は同軸ケーブルでは2224MHz～3224MHzで伝送されるが、光信号の帯域幅にとってみれば大したことではない。
FMラジオ以外の信号はいずれもデジタル変調された信号だし、光通信もデジタルの印象が強いが、そこでアナログ変調が出てくるのは意外だった。
ただ、光伝送のための装置をシンプルに作ろうとすると、これがいいらしい。
同軸ケーブルで伝送を行う場合、108-170MHz, 222-470MHzにBS・CSの情報を載せる必要があり、
そのためには、BS・CSの信号を一旦、1チャンネルずつ復調して、改めてこれらの周波数帯にデジタル変調して送り直すということをやっている。
ところが、光伝送ではその手間を省いて前後でアナログ変調するだけだから、シンプルに複数チャンネルの情報を転送できる。
あくまでも電気⇔光 の部分がアナログ変調というだけで、映像⇔電気の部分はデジタルですので。
ところで、家庭用の光インターネットでは、1本の芯線を複数戸で分け合って使っている。
1戸で光ファイバーを占有するほどの通信はしないだろうということだ。
局舎から出た1本の光ファイバーを末端でスプリッターで数本に分けて、複数戸に引き込むわけだ。
これ、どういう仕組みなんだろう? と思ったら、時分割で送受信しているのね。
スプリッターというのは、単純に局舎からの信号を単純に分配して、複数戸からの信号を単純に混ぜ合わせるだけのものらしい。
そのため、ある人に送っている光信号は同じ光ファイバーを共有する他の人にも届いてしまうが、暗号化されているのでご安心を。
この方式では、同じ光ファイバーを共有する他の人と1本の回線を分け合うので、他の人の通信状況により通信速度が変わるようだが、
むしろフレッツ光だとプロバイダーとの接続点の方が問題で、光ファイバーを共有していることによる問題は顕在化しにくいようだ。
電気通信と光通信だと多少やり方に差はあるようだが、
光通信が家庭に普及していく中で、安価な装置で効果的な通信ができるように工夫されてきていることがわかる。
幹線ネットワークだともっといろいろあるらしいんだけど、高価な装置を家庭に導入するのは難しいですから。
テレビ信号の伝送方式は意外とシンプルなんだなと思ったけど、おかげで家庭で普通に使えるわけですから。
Author : hidemaro
Date : 2018/07/30(Mon) 22:31
電気・数学・物理 | Comment | trackback (0)
エミュレータでの単体テストは好調
最近、マイコンのプログラムについて、エミュレータでの単体テストが軌道に乗ってきている。
実機の到着はまだ先だけど、ハードウェアに関係ない部分の実装はかなり進んでいて、
実機がなくても、作っては動作確認してということができるのはよい。
設計して、実装して、単体テストで動作確認して、ということをやっていると想定と違うことが出てくる。
特に異常時の挙動で、ここでこっちの状態に遷移するはずとか、このフラグが落ちてるはずとか期待値を書いたら、
実際には想定外の状態遷移をしてたり、禁止操作をしてたり、前の処理の残骸が残ってたり。
それに応じて設計を見直してということをやっていた。
もしかすると、想定と違う部分があっても、実機ではそれなりに動いてしまうような気もするのだが、
単体テストでは厳密に期待値を書くので、少しでも想定と違うところがあると引っかけることができると。
あと、ハードウェア設計中ということもあって、仕様変更も少しある。
その仕様変更に対して、まずテストを変更して、NGになるのを確認して、
それから、設計・実装を変更して、それでOKになるのを確認するという手順を踏めるのは単体テスト環境が揃ってるからこそ。
修正部分がほかの動作に影響しないかの確認も改めて全部のテストをかけなおせばできるし。
以前から論理回路設計のときはこういうやり方でやってたんだけどね。(cf. シミュレーションをするのが仕事)
単体テストは、リファクタリングということで、外部から見た動作を変えずに内部設計を変更するのに使われることがある。
内部設計が変わってもテストが通れば外部から見た動作が変わっていないことが確認出来ると。
その分、テストの内容が充実していないとダメですけどね。
テスト内容が充実してれば、テストで追えるから、内部設計を変更しても安心感がある。
今回は全く新規にコードを書いているので、マイコンにペリフェラルに依存する部分と、依存しない論理的な部分を分けて、
エミュレータでのテストをやりやすい設計にしている。
でも、よくあるマイコンのプログラムは抽象度が低くて、エミュレータでのテストにはなかなか向かないんだよね。
最初からテストを意識した設計じゃないと、単体テストを活用するのは難しい。
というわけで、エミュレータでの単体テストを他のシステムで活用するのは難しいなと思った。
逆にうまく切り分けられれば、実機では気づきにくい問題もいろいろ発見できたのでメリットが大きい方法だとは思ったけど。
Author : hidemaro
Date : 2018/07/25(Wed) 23:01
電気・数学・物理 | Comment | trackback (0)
夏休み直前に分周器を消す
今日は午後に研修があって、終わったら夏休みだ、
と思って職場に戻ると、ハードウェア設計者がマイコンの起動時の処理について相談にやってきた。
その場で検討したところ、マイコン外部で持っていた分周器の機能をマイコン内部に取り込むと解決できることがわかった。
それに伴うピン割り付け変更の候補だけ決めて、それに伴う回路の変更は僕が夏休みの間にやるとのこと。
そもそも、事の発端はアナログ回路の駆動に必要なクロックをマイコンから供給することにしたこと。
当初、ハードウェア設計者はマイコンのクロックをそのまま出して、それを外部で分周することを考えていたのだが、
このマイコンはクロックを直接出力する機能がないので、タイマからPWM信号としてクロックを出力する必要があった。
メインクロックが8MHzで、周期8クロック、Duty比50%のPWM信号を出力すれば、それは1MHzのクロックを供給できる。
一方で、どうせタイマからPWM信号でクロックを出すなら、直接、希望の周波数で出力すれば、外部の分周器は不要なのでは? と提案した。
必要なクロックは2種類、タイマペリフェラルの個数は足りることはわかっていた。
ただ、このときはこの提案は採用されず、当初想定していた分周器を置く方式が採用された。
当時、ピン割り付けに懸念があったようで、そのあたりも外付けの分周器が維持された背景にあったようだ。
ところが、通電時の挙動を検討したところ、通電～クロック供給開始の間の分周器の出力と供給先のアナログ回路の組み合わせがよくないらしい。
それで、マイコン側で追加の制御信号を出して解決できないかと相談に来たのだった。
分周器の使い方が悪いんじゃないの? とも思いつつ、「そもそも、分周器やめたら、この問題解決できるんじゃないですか」と言ったら、一気に事が動いたと。
マイコンの出力ピンは通電後、プログラムで設定するまではハイインピーダンスなので、
外でプルアップなりプルダウンして、供給先のアナログ回路にとって都合の良い出力を選べる。これが決め手だった。
これはハードウェア設計者にとっては想定外の回答だったようだが。
手早く追加のクロック出力ピン候補を決めて帰ったのだった。来週に回路の詳細が検討されるようだ。
こんなことをよりによって、夏休み直前、数十分前に言い出すなよと思ったけど。
ハードウェア設計者側からすれば、ギリギリで間に合ったということなんでしょうね。
別に僕の夏休みを軸に引いたスケジュールではないんだけど、本当は今週にはハードウェア設計は一通り終わってるはずだったような。
本来、僕が担当するマイコンの設計はスムーズに進んでいて、自分はやることやって夏休みと思ってたんだけどね。
でも、事情も知らずにへんてこりんな設計にされて、後でなんだこの設計と言うよりはいいか。
この問題を解決するために、本来は別の目的で使っている信号を無断で転用される恐れもあったわけだし。
Author : hidemaro
Date : 2018/07/06(Fri) 23:11
電気・数学・物理 | Comment | trackback (0)
反転の反転なんてするから
以前、マイコンのCRC計算回路とDMAを組み合わせてCRC計算をする話を書いた。
とりあえず成功したのだが、その後に困ったことが起きた。
というのも、CRC計算回路内部では右送り(MSBファースト)、ビックエンディアンで計算しているのよね。
以前、このBlogでCRC演算の右送り・左送りの話は紹介している。
CRCの計算で一般的なのは、右のビットをMSB、左のビットをLSBと考えて計算する方法。
除数(0x104C11DB7)のMSB・LSBを反転させた値を使いながら、データを右ビットシフトしながら計算するので、右送りと呼ばれる。
普通は一番左のビットがMSB、右のビットをLSBと言う。
右送りはデータを右シフトしながら、すなわちLSB側から順番に計算することなので、このマイコンの説明書ではLSBファーストと書かれていた。
ところが、このマイコンのCRC計算回路は左送りが標準となっている。けど、右送りのCRCがないわけでもないし。
解せないのがバイトオーダーがビックエンディアンということ。
このマイコンのプロセッサーはリトルエンディアンなのに、なぜかCRC計算回路はビックエンディアンになっている。
バイトオーダーとは、複数バイトのデータ、例えば32bitのデータを格納するときのバイト順を表している。
ビックエンディアンは1バイト目にMSBが含まれるバイトが、リトルエンディアンは1バイト目にLSBが含まれるバイトが格納される。
16進数で0x12345678というデータを 12 34 56 78と並べるのがビックエンディアン、78 56 34 12と並べるのがリトルエンディアンである。
このあたりはプロセッサーによるんだけど、リトルエンディアンのプロセッサーが主流のよう。
というわけで、メモリ上に12 34 56 78 9A BC DE F0 と格納されたデータを、4バイトずつ読み込むと 0x78563412, 0xF0DECB9A と解釈される。
ところが標準設定のままCRC計算回路に 0x78563412 を転送すると、78 56 34 12 という順番で、各々左送りでCRC計算することになる。
複数バイト一括でCRC計算回路に転送すると、データの順番が逆になっちゃってるんだよね。
ただ、左送り、ビックエンディアンが実際に使いたいCRCの計算方式とは限らないので、
CRC計算回路の前後で、バイト順反転、ビット順反転をできるようになっている。
右送り・リトルエンディアンの場合は、入力・出力ともに、バイト順反転、ビット単位でビット順反転 を有効にすればよい。
ビット順を反転して入力して左送りで計算すれば、右送りでCRC計算した結果のビット順反転になるので、また反転すればよいということらしい。
左送り・リトルエンディアンの場合は、入力側のみバイト順反転にすればよいはず。
というわけで、正しく設定をすればどうってことはないわけだが、1つ問題があった。
それがCRC計算の初期値だ。
CRC計算の初期値としては 0x00000000 と 0xFFFFFFFF がよく使われる。
世間的には0xFFFFFFFFの方がよく使われているようだが、うちの製品群では専ら0x00000000ですね。
いずれにせよ初期値を任意に設定できる仕組みを付けておけばよい。
その機能を使って、一連のCRC演算を分割して行おうとした。
初期値0x00000000からCRC演算を0バイト目からNバイト目まで計算して、そのCRC(ビット反転なし)が0xEDB88320だったとする。
次に初期値0xEDB88320からN+1バイト目からMバイト目までCRCを計算する、そうして求まるCRCは0～Mバイト目のデータのCRC値になる。
ところがこうやって計算すると、結果が合わないんだよね。
それでおかしいなぁってデバッガで調べてみたら、初期値に値を設定して、なにも計算せずに読み出すとビット順が反転していることに気づいた。
すなわち初期値0xEDB88320をセットしたら、途端に結果が0x04C11DB7になっているということだ。
それで過去の同様の実装例を調べたら、途中の計算では出力側のバイト順反転、ビット単位でビット順反転を無効化して、
最後の計算のときだけ、バイト順反転、ビット単位でビット順反転を有効にするという方法を取っていた。
こんな使い分けをしてるなんて今まで気づいてなかったけど、そうだったんだね。1発計算と同じだと思っていた。
ちなみに初期値を0x00000000 と 0xFFFFFFFF をセットするのであれば、ビット順が反転でも何の問題もない。
だってビット順を反転しても0x00000000 と 0xFFFFFFFFだからね。だから右送り・左送りともにこの値を初期値に設定すればよい。
典型的なケースでは問題にならないことから、マイコンのマニュアルにもはっきりとは書かれていなかった。
回路構成を読み解くと、なぜこうなるかはわかるようになってたけど、ちょっと微妙ですね。
そもそも、なんでリトルエンディアンのプロセッサーにビックエンディアン・左送りが標準のCRC演算回路を載せてるんだって話だけど。
マイコンのマニュアルには、CRC16では左送りが標準っぽいことが書かれているけど、僕が知る限りではCRC16も右送りが主流だと思うんだけどね。
左送り+ビックエンディアンというのは、最初のバイトのMSBから順番にという点では一貫性があるけど、
いや、それなら右送り+リトルエンディアンで、最後のバイトのLSBからっていう方を選べよと思うんだが、ようわからん。
まぁ前後で反転すればよいというアプローチはその通りだと思うんだけど。
Author : hidemaro
Date : 2018/06/28(Thu) 22:32
電気・数学・物理 | Comment | trackback (0)