2012年6月22日金曜日

メモリマップドIOとIOマップドIO

組込みシステム開発の場合、ハード屋さんから、割り付け表といわれる資料を貰います


その資料には IOとかアドレスとか書かれています

IOはInput,Outputの略ですね

CPUからの制御線には M,IO,R,Wと有ります(CPUごとには違いますが簡略化します)

それとデータバス、アドレスバス、これを組み合わせて周辺機器(チップ)とのやり取りを行います


IOマップドIO

IOマップドIOというのは、IO信号と、アドレス、Write or Read 信号で外部とのやり取りを
行います


IO命令というのがマシン語レベルであるので、理解もしやすいと思います

ただし、IO命令に使われるアドレス幅に制限がある場合があります

IO命令自体も高速に行われる事が多いのでデータ量が小さい場合には便利です

CPU内臓のIOとは別に使える場合もあります

割り付け表 には IOとして書かれていると思います



<メモリマップドIO>

メモリマップドIOでは、広大なアドレスが使えます

通常、アドレスバスの2のn乗のアドレスバスの信号を一つまたは複数使って
周辺機器(デバイス、チップ)へのアクセス信号をハードウェアロジックで作成します

最近のCPUではアドレスバスの幅も広く、またやり取りするデータ量も多いので、
この方式はよく使われます

IOなのに、なんでメモリーアクセス?って、少し頭が混乱する原因です

欠点は、メモリーアクセスになるので、少し動作が遅い場合があります

ただし、最近のCPUでは、ある程度のアドレスの範囲でアクセス速度を指定できますので、問題にならない場合も多いです

この、アクセス速度の設定などは スタートアップルーチンで記述する事が多いです

特に画面周りがあるものでは、データ量が多くなるので、多いと思います









2012年6月18日月曜日

CPUの動作の仕組みを理解しよう

タイトルだと、たった1行で終わります。

組込み開発に使われるCPUには、膨大な種類があります。

Z80,H8,SHXX,ARMシリーズ、、ETC

プロジェクト毎に、CPUが違ったり、一つの機器に複数のCPUが利用されていることもあります

実際に組込みの開発を行うとなると、膨大な量の資料に目を通す必要があります




一つのCPUに関して、熟知すると、他のCPUに関しても応用が効くようになります


本格的に理解をしようと思う場合、アセンブラの知識が必要になりますが、なんとなく、読めれば


かけなくても大丈夫だと思います

今は、ほぼCコンパイラで99%の処理を記述できると言ってもいいでしょう


要素をあげておきますので、機会があれば調べてみてください

今回の記事では、個々の詳細については触れないで、別の機会に


・リセット時の動作
・PC(プログラムカウンタ)
・SP(スタックポインタ)
・レジスタセット
・割り込み
・タイマー
・割り込みベクター
・NMI
・WDT(ウォッチドッグタイマー)
・IOポート

・機能設定レジスタ(特殊レジスタ)


基本的な機能だけでもこれぐらい、これ以外にも

・シリアル通信
・AD/DA変換
・CPU動作モード(低速・高速、低消費電力モード 等)

CPU自体に、外部とのIOの機能が内蔵されている場合はその機能



ざっと思いついたままに書いていますので、随時更新していきます


2012年6月15日金曜日

組込みでこそ活用できるソースのバージョン管理

ソフト開発を行っている人なら ソースのバージョン管理ツールという単語は良く耳にしていると思います。

 組込開発の場合ハードの開発が同時に行われている場合、一度改造されて、その後また、元に戻る場合があったりします

 その場合、バージョン管理を行っていると、元の状態に戻すのも簡単です


また、ハード自体は同じで、派生品の開発などが行われる場合、バグが発生した場合に、両方のプロジェクトに対応内容を反映させることも容易になります


CVS,SVN(Subversion),Git 等あれこれとあります

大まかにどんな感じかというと

・個々のファイルを更新して登録する時に、個別にバージョンが自動で登録される
 (この時に、更新内容を登録すること、バグ管理とか使っている場合バグNo等有用)

・中間リリース、あるいはテスト部隊に評価バージョンを渡す場合に、プロジェクト全体をひとかたまりのバージョンとして登録しておく

 
・派生プロジェクトが発生した場合は分岐を作成する

・現在(現在に限らず任意)のファイルと以前のファイルの変更箇所を見ることが出来る


もしも、まだ、使ったことが無いのでしたら、WinCVSあたりをとりあえず使ってみて、バージョン管理がどんなものか実感するのがいいと思います


既にかなり枯れた(こなれている)ものになっていて、リポジトリ(管理データの大元)もローカルディスク、ネットワーク上の共有ディスクでの運用も可能ですし、LinuxサーバーでPserverの設定の仕方等も簡単です


ただ、闇雲に毎日仕事の終わりに登録するってのは駄目ですけどね

最低限、コンパイルが正常に通り、機能的にも正常に動作しているってのがありますけどww



2012年6月12日火曜日

組込みで欠かせないICE

風夢です。 ICEという名前は組込み開発をした事のある人なら、ほぼ全員知っているとは思いますが、それ以外の方にはなじみが無いかもしれないです。

簡単に言うと、デバッグを行うためにある高額な開発機材です。

操作するイメージは統合環境のデバッガとほぼ同じような感じです。

InCircitEmulatorの略だったような気がします(スペルに自信なし)


<フルICE>

初期のICEは、ターゲットとほぼ同じCPUが乗っていて、開発用のボードに専用のソケットをつけて、
そこからフレキシブル基盤でICE本体と繋げるようになっていました。ICEの代わりに内蔵ROMにプログラムを書き込んでやると単体で動作するものもありました。

この頃のICEは非常に高額で、1セットの金額で簡単に車が買えるようなものでした

まだまだアセンブラでのデバッグも多かった時代で、サポートソフトも貧弱で、Cの構造体の中身の
数値が見れなかったり、ローカル変数が見れなかったり、動作中にブレークポイントを設定した時に
動作がおかしくなったりして、独特の世界でした

ただし、ハードウェアブレークポイントの設定が出来る(特定アドレスのアクセスでブレーク)とか
実際のCPUが搭載されている(ターゲットとまったく同一ではないけど)メリットはありました

高級だったので、プロジェクトに一台のみというのが当たり前の時代でした


<ROM ICE>

その後出てきた、ROM ICEは、ROMの代わりにRAMにROMの内容を書き込んでやってターゲットボードに接続して、そのほかは何本かの制御線を接続して使うものでした。

価格はかなりやすくなりました。

ただし、デバッグ機能を実現するために、開発用と、リリース用で、一部メモリーマッピングやら
割り込み関係の変更を必要とされる場合もありました。

<JTAG ICE>


さらに時代は進んで、JTAG ICEというものが出てきて一般的になっています。

CPU自体にデバッグサポート用の機能が組み込まれて、接続も2個の小さなコネクタだけで
使えるようになりました

また、開発中のボードにはJTAG用のコネクタを実装して、完成品には付けないという形で
開発専用の基盤を作成する必要もなくなりました

また、CPUのベンダ毎に開発用の統合環境も提供され、デバッグ以外にも、スタートアップルーチンの一部とか、割り込みベクタの設定とかかなりの部分もサポートされて、以前よりも
ソフトウェア開発者の負担が減っているのも大きいです


ざっと、簡単にまとめてこんな感じかな

2012年6月11日月曜日

データシートは印刷したほうがいいかも

組込みシステムの開発で避けて通れないのが、データシートです。

データシートとは、色んなデバイスの、電気的特性とか、動作の仕方とか、主に読むのはハード屋さんですが、ソフト屋さんも必要になる事があるので、開発時には入手しておく事が望ましいです。


日本語で書かれているものもありますが、英語で書かれているものも多いです。

最初は判らないかも知れませんが、データシートを読む程度ならそんなに難しい英語は出てこないので、数をこなすしかありません。

特にメモリー関係は、英語で書かれているものが多いです、RAMは問題になる事は比較的少ないですが、EEPROM等は書き換えのロジックを作成する必要が、ほぼあるので、ソフト屋さんが自分で考えないといけない事も考えられます


また、大昔はデーターシートは紙で提供されることが多かったのですが、PDFで提供されることが最近ではあたりまえになっています。


PDFでみるとどういう経緯でこの設定にしたのか、トラブルが発生した時に悩んで、時間を無駄に
浪費することがあるので全体とはいいませんが、設定に関わる部分だけは、印刷して重要な部分にはマーカーを引くとか付箋をつけるとか、しておくと後々役に立つことがあります

2012年6月5日火曜日

空きポートの活用(デバッグ)

組込みシステムの場合、全てのポートを使い切ることは少ないです。


 また、製品完成時には、ランプその他に使用するIOポートも、開発中にはシリアルポートとして
流用できる場合も多々あります。

 ハードデバッグ、あるいは、アプリケーションのデバッグ中に特定の機能をチェックするために、
シリアルポートを利用して、ターミナルモードの様な物を組み込むと、チェック作業の能率があがる
事も多々あります。


 ただし、パターン設計時にその様なポートを、最低限半田付けできるようになっていないと難しいかもしれません。

 理想的にはランド、もしくはTP(テストポイント)になっていればいいのですが。


 また、シリアルポートが使用できても、TTLレベルでの出力になっている場合が多いので、レベルコンバーター(MAX232?等)を使ってPCとの接続を出来るようにしないといけません。


多少、ハードルは高いとは思いますが、実現できた場合には

・ハードの機能検証をターミナルモードで実行できるようにしておけば、
 ハード検証作業(修正後の確認を含む)にソフト技術者がかける手間が減らせます


・複数人数で開発中の場合に、アプリケーション担当者が(データ作成だけの場合もあり)
 ICE等の操作方法をしらなくても、動作確認が出来る

・上の例と半分かぶりますが、ICE実機、ROM実機とある場合にICE実機を取り合うことが減ります

・PC上のソフトの場合はデバッグプリント等もできますが、組込みシステムでは出来ないことが
 多いので、内部状態をシリアルで出力して、PCにてログしておくようにしておくと、異常な動作を
 発見した場合の解析に役立ちます


・場合によったらカバレッジテスト的にも使えるかもしれません




2012年6月1日金曜日

トラブル1(回路図・・・)

ややこしい話ばかりでもつまらないので、ちょっと 普通ではありえないトラブルの例をあげてみます。


ハード屋さんは、好くある事ですが、デバイスメーカーの標準設計を基本にして、そこに独自の回路をシステムの必要性に応じて、追加して設計します。


その状態で回路図になって、そこから基盤設計(パターン、アートワークとかが関連用語)をして
試作基盤として、やってきます。

その段階で、ソフト屋さんが、ハードの初期設計の動作確認を行うケースもあるのですが、
そのトラブルが発生した基盤では、うんともすんともまったく動作しませんでした。


基盤自体は3層基盤だったか4層基盤だったと思うのですが、まったく何も動きません。


回路図とテスターを頼りにあれこれ探す前に、まずは自分のソフトやら、マッピングの設定が怪しくないかと何日間かは過ごすわけです。


ICEを使って、プログラム自体はそれなりに動いているものの、なぜかデバイスは反応してくれないので、さすがにハードを疑って調べた結果


リファレンス回路をもとに設計したときにデータバスが逆転していました。

データのビット並びが逆になるので、動かなくて当たり前ですが・・・・


こういうトラブルもたまには あるということで・・・


詳しいことはもう、覚えていませんが、よく見つけたもんだと、、どれだけ苦労したとかは

ご想像にお任せします。