日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

受信エラーに直接気づけない!?

1つ前の世代で使っているマイコンのシリアル通信機能について、いろいろ深掘りしてたんだけど、

エラー時の処理を調べてみると、ちょっと奇妙なことに気づいた。


マイコンによって違いはあるだろうけど、通信ペリフェラルとDMAを組み合わせて使用することはよくある。

DMA(Direct Memory Access)は、あらかじめ設定しておけばCPUを使わずにデータ転送できる仕組み。

DMAはプログラムから駆動することもできるが、割り込み要求信号から駆動することもできる。

通信ペリフェラルに受信ごとに割り込みを発生させる設定をしておいて、

DMAコントローラに受信割り込み要求ごとに、受信レジスタからメモリにデータ転送すると設定しておくと、

あとはCPUは手放しで受信データが順番にメモリに格納されていくわけである。

指定数のデータの転送が完了したら、DMA転送完了割り込みを発生することもできる。


ところでシリアル通信の受信時には、フレーミングエラーとか、パリティエラーとかが発生することがある。

普通に使っていればこういうエラーが発生することはないと思うのだが、もしエラーが発生したらどうなるんだろう。

その結果、次のような動作になることがわかった。

  1. 受信エラー割り込みはDMA転送のトリガにならない
  2. 受信エラーが発生すると、エラーフラグが消えるまでは新たな受信を停止する
  3. ゆえに1回でも受信エラーが発生すると、DMA転送は永遠に完了しない

通信ペリフェラルは受信エラー発生時に割り込みを発生させることができるのだが、

このマイコンでは、DMA転送と併用するときは、受信エラー割り込みを使うことが出来ない。

その代わり、エラーをきっかけにデータ転送が進むことは無いし、

プログラムがエラーを認識してエラーフラグを消すまでは、一切の受信が停止するというおまけ付きである。


ところがこれってDMA併用時は割り込みでエラーに気づくことができないってことなんだよね。

そんなのでエラー処理大丈夫なの? と思った。

実際のシステムでは、定周期処理でDMA転送の状態をポーリングしている。

正常に全データを受信できたら割り込みを発生させることが出来るが、

受信中にエラーが発生した場合もそうだし、データが届かなかった場合も割り込みが発生しない。

そのため、一定時間待ってもデータが届かなかった場合は、タイムアウトでエラーにする処理を組み込んでいる。

タイムアウトを検出するのはほぼ必須だからこれでいいのか。


最新世代のシステムで使っているマイコンはどうなっているのか、気になって再確認してみた。

すると、DMA併用時に受信エラーが発生したときは、DMAを強制停止して、DMA転送完了割り込みを発生させる。

DMA転送完了割り込みでは、正常終了かフラグを確認することになっているので、

異常終了だった場合は、何らかのエラーがあったことが検出できるってわけ。こっちの方が素直ですね。

もっとも、このマイコンでもタイムアウトの検出は別途行う必要はあるのだけど。


あと、このマイコンは通信ペリフェラル内にFIFOを備えているので、

FIFOサイズ以下であれば、DMAを併用せずともCPU手放しでデータの送受信が出来る。

特に受信の場合、DMA併用よりもFIFOで受信する方がずっとシンプルに作れるようになっている。

この場合、FIFOに指定数格納された時 と 受信エラー発生時 に割り込みを発生させることができる。

エラーフラグが消されるまではFIFOへの格納を停止するので、その点でもDMAの異常終了と似ている。

同じマイコンの類似した機能なので合わせてるんだろうけど。


受信エラーが発生したら割り込みで通知できるのは当たり前だと思ってたけど、

DMA併用時だと必ずしもそうともいかないというのは想定外だった。

受信エラーを無視して、受信し続けるということはしないなど考えられている部分もあり、

割り込みが発生せずとも、それで問題ないように作ること自体はそんなに難しいことではないのだけど。

どうせタイムアウト処理は作らないと使い物にならないわけだし。


Author : hidemaro
Date : 2019/08/22(Thu) 23:11
コンピュータ・インターネット | Comment | trackback (0)

リセットって割り込み?

マイコンの重要な機能が割り込みである。

割り込みというのは、条件を満たしたとき、実行中のプログラムを中断して、指定したプログラムを実行させるもので、

マイコンではタイマや通信などをきっかけにして、割り込みを発生させることが多い。

PCも裏ではいろんな割り込みが動いてるんだけどね。それを意識するかはともかく。


割り込みの種類を書き上げたリストの筆頭に「パワーオンリセット」と書いていたら、

それは割り込みではないのでは? と指摘された。

僕の認識ではリセットは優先度最高の割り込みという認識だったのだが、

確かにリセットって一般的な割り込みとは全く違う概念のものだよね。


マイコンのマニュアルにはどう書かれているのか。

ARM Cortex-Mシリーズ と ルネサスRXシリーズ のマニュアルを見てみたのだが、どちらも書き方はほぼ同じだった。

僕が割り込みと思っていたものは「例外」という言葉で書かれていた。

Cortex-Mでは例外は リセット、ノンマスカブル割り込み(NMI)、各種フォルト、スーパーバイザコール、システムタイマ、外部割り込み から構成されているとある。

RXでは例外は リセット、NMI、割り込み、未定義命令例外、特権命令例外、無条件トラップ から構成されるとあった。

すなわち、例外の中に「割り込み」という概念があるということらしい。


一般的に割り込みというのは、ユーザーが有効・無効や優先度を決めることが出来る。

ARMだと数字が小さいほど優先度が高く、RXだと数字が大きいほど優先度が高い。

もっとも同じルネサスでも旧NECから継承したRL78(旧78K0)は数字が小さい方が優先度が高いようだが。

それはさておき、Cortex-M ではリセットの優先度は -3、NMIは優先度-2、ハードフォルトは優先度-1に固定されている。

ユーザーが設定できる優先度は0~255なので、リセットは最優先、それに次いでNMI、ハードフォルトというのは不変ということである。

リセットとNMIが最優先かつ無効化できないというのは、どんなマイコンも共通なんじゃないか。


Cortex-MにしてもRXにしても、例外の中に狭義の「割り込み」があって、

狭義の割り込み以外の例外として、少なくともリセットとNMIがあるということである。

リセットは明らかに特殊だけど、NMIもリセットを除いて最優先で無効化できないという点では特殊である。

NMIはその性質からエラー処理に使われることが普通である。

とあるシステムでは、外部のロジックICの異常信号をNMI入力に接続してあった。

ロジックICが異常を検出したら、マイコンにNMIを発生させて処理を停止させるようになっていたはず。

RXマイコンではNMI発生後は元のプログラムに復帰出来ないと書かれていたぐらいなので、そういう用途でしか使っちゃダメだよということだね。


リセットは割り込みなのか? と問われると、ちょっと困ってしまうところはあるのだが、

特定の条件によって、プログラムカウンタを指定した値にセットするという点では割り込みなんじゃないか。

ただし、リセットというのはその性質上、内部状態をご破算にするので、元のプログラムに戻ることは当然出来ない。

その点では、一般的な割り込みの特徴に合わない気がするんだけど、元のプログラムに戻らない用途で使う割り込みというのはけっこうあるんだよね。

例えば、ウォッチドックタイマー割り込みとか。死に際でログを取ったりするための割り込みだから、通常は元のプログラムに戻らない。

元のプログラムに戻らないのと、戻れないのは違うと言われればそうかもしれないが。


もっとも、リセットは割り込みではないのでは? という指摘はマイコン内部の機能ブロックを意識しての話だったようだけど。

そのマイコンでは、リセット以外の例外をコントロールする機能ブロックがあるらしい。

NMIも、各種フォルトも、狭義の「割り込み」も同じ枠組みでコントロールされているようだが、

唯一、リセットだけは別のブロックによりコントロールされているようである。

リセットは他の割り込みとは実現方法が違うだろうなぁ、というのはだいたい想像できることだけど、実際そうだよというだけの話。


Author : hidemaro
Date : 2019/08/09(Fri) 23:50
コンピュータ・インターネット | Comment | trackback (0)

ROMデータの作り直し

工場で使ってる ROMライターの都合で、ROMデータを作り直す必要があって、

いくつかのROMデータをチマチマと作り直している。

実はもともと開発ツールから生成される、ちょっと特殊なデータ形式をそのまま書き込ませていたのだが、

汎用性に欠く方式でいろいろ不都合があったのも実情である。


この問題を回避するためには、汎用的なROMデータに変換すればよい。

同種のものでも、過去に1つだけ汎用的なROMデータを生成して、書き込む方法を取っているものがあった。

その方法に準じて汎用的なROMデータに変換することにした。

ヘッダ・フッタを切り取って、ROMのサイズに満たない分を0xFFでデータを埋めて、とあるルールでバイナリを変換すればよい。

作業自体は慣れれば大したことではないが、従来より手間は増える。


ROMデータの登録が完了すれば、とりあえずの目的は達せられたのだが、

そういえば新しいROMデータの生成方法を残してなかったなと思い、

ROMデータの生成方法を文書化して、文書管理システムに登録する作業をやっていた。

過去の同種の記載を参考に、実態に即して書き換えを進めた。

登録しておけば、後にROMデータの変更が必要になったときに役立つはず。


ROMデータの生成ってけっこういろいろ手順があるんだよね。

しかも、普段はJTAGとかで書き込むから、ROMライター用のデータを作る必要性もない。

一応、職場にもROMライターがあるので、そのROMデータで妥当かどうか確認する手段はあるのだが、

ROMデータ改訂のたびに毎度そういうことをやるかというと、そうとも言えない。

手順通り作れば大丈夫なはずなんだけど、工場でしくじっては面倒だ。


Author : hidemaro
Date : 2019/07/26(Fri) 23:20
コンピュータ・インターネット | Comment | trackback (0)

パラレルバスのFlashはこうやって書き換える

古いマイコンでパラレルバスのFlash ROMを外付けしてるんだけど、

どうやって書き込むんだろうなぁとおぼろげには思ってたが、

フラッシュ書き込み用のプログラムの改造が必要になったので、

書き込み用のプログラムのソースコードを入手して中身を見てみた。


操作内容を見てみると、Flash ROMに対してマジックワードを書き込みしているように見える。

これは一体何なんだ? と思って、Flash ROMのデータシートを見てみた。

すると、ソースコードに書いてある通りの操作手順が書いてあった。

ソフテックだより/マイコンによるNOR型フラッシュメモリ制御 (ソフテック)

JEDEC標準型コマンドという方式に従っているようだ。

アドレスを変えながらマジックワードを書き込む操作を数回繰り返すとイレースとかライトとかの操作ができると。


偶然、マジックワードを書き込む操作をしてしまったら、Flash ROMが消えたり書き換わったりするのでは?

と思ったけど、Flash ROMにライトアクセスをすること自体が異常な操作だもんな。

間違えてライトアクセスをしたとしても、アドレスを変えながらマジックワードを書き込まないと何も起きないからね。

やってること自体は簡単そうだが、意図的にやらないと起きないことは間違いないようだ。


マイコンの内蔵Flashだと、専用のレジスタをあれこれ操作して書き換え操作をやるものだけど、

外部に接続されたFlash ROMの場合、マイコンの機能は関係なくて、Flash ROM自体の機能で書き換えるというのは、

言われて見れば当たり前のことだけど、操作感があまりに違うものだから、

「えっ、こんな操作で書き換えられちゃうの!?」と初見では思ったよね。

冷静に考えれば全く問題なかったですね。

特定のアドレスにマジックワードを書き込んで書き換えをするのは、マイコン内蔵のFlashでも同じことだし。

そのアドレス空間がROM空間か、ペリフェラルレジスタかという違いでしかない。


Author : hidemaro
Date : 2019/07/17(Wed) 23:16
コンピュータ・インターネット | Comment | trackback (0)

チェックサムもいろいろあるが

製品の世代によって、異なる2つのアーキテクチャのマイコンを使っているのだが、

新しい世代のマイコンで使っているコンパイラは、チェックサムの埋込を自動的にやってくれる。

けっこういろいろな設定が出来るので、ビット幅とかエンディアンとか自由自在で便利だ。

ところが、古い世代のマイコンのコンパイラは、チェックサムの埋込ができない。

そのため、別のツールでチェックサムを埋め込む処理をしている。


もっとも、チェックサムの埋め込み方が複雑なのも背景ではある。

ROM内を2つのセクションに分けて、セクションごとに末尾の定数にサムを埋め込むようになってるんだよね。

実態としては2つ目のセクションはほとんど意味を成していないけど。

今回、とある目的のために新しいセクションを追加して、このセクションに対してチェックサムを埋め込む必要が生じた。

他にも出力データにいくつかの加工が必要と言うことで、新しいツールを作った。


このツールはコンパイラからSフォーマット(モトローラ形式)で出力されたデータを読み込み、

これに対して、セクションごとにサムを埋め込み、さらにセクションによってアドレス変換を行う。

そして、最終的には バイナリデータ と Sフォーマット でROMデータを出力する。

バイナリとSフォーマットの両方で出力するのは、オフセットアドレスがあるから。

デバッガにはSフォーマットで食わせれば、オフセットアドレスの設定を考えなくても正しく認識されるので便利だろう。

一方でROMライターではバイナリデータを使っているので、バイナリデータの出力はそれはそれで必要。

さらにROMライターでの書き込みにあたってはROMライター用のチェックサムを計算しておかないといけない。

そのROMライター用のチェックサムも自動計算できるようにした。


やってみると気づくんだけど、いろいろな種類のチェックサムを計算しないといけないんだよね。

ROM内に埋め込むチェックサムは32bit幅で加算し続けたものが基本だが、一部の製品では、検出能力を高めるためにCRC16が採用されている。

(ちなみに新しい世代で使っているマイコンでは、CRC演算ペリフェラルが内蔵されていることもあって、CRC32で一貫している)

さらにSフォーマットでは行ごとにチェックサムが必要で、これは8bit幅で加算して1の補数(ビット反転)を取ったものである。

さらにROMライターのチェックサムはそれはそれで計算範囲や計算方法が違う。

今回のシステムでは16bit幅で加算したものがROMライター用のチェックサムになっている。

新しい世代のマイコンではROMライター用のサムは8bit幅で加算して計算するので、同じだと思ったら違ったので戸惑った。


というわけで、一言にチェックサムと言っても、いろいろあるのだ。

これを手作業でやるのはあり得ないけど、一方でオールインワンでできるツールはなかった。

複数のツールを組み合わせてやるのが現実的なところかと思うが、操作が複雑で時間がかかってしまう。

今回作ったツールはあらかじめ設定しておけば、ボタン1つで全部完了するので、とても便利ですね。

もっともROMライター用のサムは、生産準備のときだけ算出できればいいんだけどね。


ツールは必要と思ってたが、まずは手作業で加工して試してみようとか思ってたんだけど、想定よりも加工内容が多くてね。

それならということで最初からツールの作成に取りかかったんだけど、いろいろめんどくさかったね。

特にSフォーマットの加工をやるのが初めてで、いろいろ戸惑いもあった。

想定外だったのはコンパイラが吐くSフォーマットのデータがアドレス順に並んでなかったこと。

新しいバージョンのコンパイラはアドレス順だったけど、古いバージョンは気まぐれと言うほかない。

確かにSフォーマットの表現としては間違えてないけど、さすがにそれは考えなさすぎだろと。

それでも対応できるアルゴリズムに書き換えたら、シンプルになったからかえってよかったかもしれないが。


Author : hidemaro
Date : 2019/07/11(Thu) 22:59
コンピュータ・インターネット | Comment | trackback (0)

キーボード部分のバッテリーの使い方

職場で使っているWindows 10のPCがタブレット兼用であることは以前も書いた。

タブレットとしてのWindows 10

概ね問題ないと言いたいところだが、スリープ時の挙動にいろいろ問題があるようで、

シャットダウンしないとうまくいかないことがしばしばあるのが困るところ。


画面部分とキーボード部分が切り離せる構造になっていて、画面部分だけでPCとして成立する機能を持っているのだが、

キーボード部分は、キーボードと外部インターフェース(Ethernet, USB, HDMIなど)だけを持っているわけではなく、拡張バッテリーを持っている。

キーボード部分とセットで使うと、けっこうな長時間にわたってバッテリーが持つようになっている。

画面部分だけだと、ちょっと心許ないですね。半日ぐらい使うともうなくなっちゃう。


そんなノートPCの側面に「TAB CHG」と書いたスイッチがある。

バッテリー残量の減った画面部分を取り付けて、このスイッチを入れると、

キーボード側のバッテリーから画面側のバッテリーに充電が行われるようだ。

確かにそういうこともできるよなぁと思うけど、それを実際に機能として用意しているのはちょっと驚いた。


そこで気になって試してみたのだが、キーボード部分だけでACアダプタに接続すると、

キーボード部分のバッテリーへの充電が行われていた。

すなわち、キーボード部分は独立したバッテリーユニットとして、充電・放電ができるということだ。

ACアダプタ→キーボード部バッテリーという電力の流れ自体は普通だが、見た目が不思議だ。


これを組み合わせることで、画面部だけでの作業中に、キーボード部のバッテリーに充電しておいて、

画面部だけの作業を終えたら、キーボード部とくっつけて、TAB CHGスイッチを入れて充電ということができる。

もちろん、画面部だけ、あるいはドッキングした状態でACアダプタに接続すれば充電できるのだが、

ノートPCをむやみに放置するのはセキュリティ面で問題視されやすい。

(職場はIDカードがないと入室できず、HDD暗号化もあるので、実態としては問題ないと思うのだが)

なのでACアダプタで直接充電できるのは、目の届くところにPCがあるときだけに限られる。

でも、キーボード部だけなら、そこには何のデータも含まれていないので放置しても問題視されないと思う。

そうしてキーボード部に充電されていれば、画面部への充電は、ドッキングした状態で鍵付きの棚に入れながらできる。


うちの職場でのノートPCの使われ方からすると、A4サイズぐらいの大きいものの方が好まれそうな気がするが、

僕を含めて、タブレット兼用のメリットを生かせないかというという試みをしている人もいる。

ただ、やっぱりWindows 10でタブレットはいろいろ難しい面がありますね。

その1つが電池なのだが、キーボード部分のバッテリーをうまく使うと、タブレット的に使う時にも役立つのはよい発見だった。


Author : hidemaro
Date : 2019/06/07(Fri) 23:58
コンピュータ・インターネット | Comment | trackback (0)

不意にデータ容量が足りなくなった

おととい、Y!mobileから「契約データ容量が残り200MBとなりました」と連絡が来た。

最近受けとってないが、月末だし……と思ったが、いやおかしい。

というのも、以前このメールを受け取っていたときは、スマホプランMのデータ容量が3GBだったときのこと。

(一方で当時はキャンペーンで3GB分の増量があったので、ここから3GBまで超過しても速度制限はかからなかった)

その後、スマホプランMのデータ容量が6GBに拡張され、まずオーバーしなくなったのだ。

それでMy Y!mobileを開いて見ると、契約がスマホプランSで、契約容量が2GBになっていた。


なんで変わってしまったのか。

心当たりは1つしかなくて、それは端末を買い換えたこと。(cf. 新しいAndroid One)

Web上にアップロードされている契約書面を確認すると、確かに基本プランがスマホプランSに変更されていた。

オンラインショップで端末を買うだけで料金プランが変わるのは想定外だったが、

選択するべきところを正しく選択せず、スマホプランSに変わってしまったのだろう。


低速化されても、かつてのBB.exciteモバイルLTEの混雑時間帯に比べれば通信が成立するだけマシな気もしたが、

画像データの転送が遅く、さすがにこれでは……ということで超過料金を払うことにした。

スマホプランSはMと比べて、1000円(本体価格)安いので、1GB分の超過料金を払ってトントン。

ここまでで済めば、プラン変更の実害はない。


25日間で2GBだから、このペースで残り5日使うと400MBという計算だが、

明日は出かけるし、あさってからは旅行である。

家の外にいると使用量が伸びるので、果たして1GBで足りるかという懸念はある。

そう考えると1GBの超過で済むかという問題はあるが、節約に努めればなんとか。

幸いにして旅行の移動中には、長らく聞けずじまいになっていたドラマCDなど聞こうと思っていたし、

移動中にむやみにデータを消費しないようにすれば、なんとかならんかなぁ。


ちなみに今は旅行に向けて冷蔵庫の中身を整理中である。

不在期間が長いので、調味料以外はほとんど使い切らないといけない。

今回は、あまり無理なく冷蔵庫の中身を減らせていて、大した帳尻合わせも必要になっていない。

先週は冷蔵庫の中身が多すぎてまずいと思ったが、計画的に購入して献立を決めたことで、きれいに着地できそう。


Author : hidemaro
Date : 2019/04/26(Fri) 21:50
コンピュータ・インターネット | Comment | trackback (0)

タブレットとしてのWindows 10

職場で使っているWindows 7のノートPCの代替として、Windows 10のPCが納入された。

現在、勤務先で選定しているノートPCはタブレットPCとしても使えるものになっている。

画面はタッチパネルで、画面部分を外すと、それ単独でPCとして使え、希望すればタッチペンが付属してくる。


うちの職場ではあまりタブレットPCのニーズはないのだが、選定品がこれしかないのだから仕方ない。

とはいえ、タブレットPCとして使えることによるメリットもあるかもしれない。

ということで、いろいろ試してみた。


キーボードを外すと、タッチキーボードを使う必要がある。

最初、タッチキーボードを表示したら、横向きだと画面の半分以上を占有して邪魔なことこのうえなく、大きさも変えられない。

いくつかあるタッチキーボードのバリエーションのうち、片手入力用が専有面積が狭くてよさそうだと思った。

FMVサポート/[Windows 10] タッチキーボードのレイアウトについて教えてください。 (富士通)

ただ、このキーボード、日本語入力しかできなくて困った。すなわちアルファベットのまま入力できないと。

言語として英語を追加すると、英語の片手入力用キーボードと切り替えることができるので、そうすればできることがわかったが、ちょっと困った。

このキーボードをタッチペンで入力するのが、キーボードがない場合では最速の入力方法だと思う。

手書き入力もあるが、厳密な入力には適しないので。

ログインパスワードもタッチキーボードで入力するが、本来はWindows 10ではPINコードが推奨されてるんだよね。

ただ、会社のセキュリティポリシーでは使えないはずなので、普通にパスワード入力がいるのでめんどくさい。


タブレットとして持って使い続けると、発熱が大きいこと、少し重いことが気になる。

ノートPCの水準としては軽くて、画面部分だけ持ち歩くなら、今までよりはかなり軽く済む。

ただ、タブレットPCとして持ち続けて使うにはちょっと重い。

一般的なノートPCとしての性能を持っているだけあって、発熱もけっこうだし、電池消費もけっこう。

電池については、キーボード部分に2つ目の電池があるので、ドッキングしていると長持ちするが、タブレット部分だけだとちょっと物足りない。

かといって、机にそのまま置いて使うと首が痛い。電源ジャックの位置もイマイチ。

こういう場合は素直にキーボード部分も持ってきて使うべきなんだろうが。

ただ、タブレットPCを斜め置きできる台があれば、この問題は緩和できそうだが。


タブレット部分についている、唯一の外部接続端子がUSB Type-Cである。

DisplayPort Alternate Modeにも対応しているようだが、さすがに画面接続が必要ならキーボード部分を持って行く。

直接接続できる機器はないが、USB Type-Cのハブを付けてType-Aにすればいろいろ接続できる。

作業内容次第だが、タブレット部分だけでも、マイコンのデバッグとかできるかもしれない。

ここにマウスをつなぐこともできるが、まぁそれはタッチペンでいいかな。


ただ、全般的な問題として、Windowsのアプリはタッチでの操作をあまり想定していないということ。

タッチペンを使えば、それなりにできることもあるが、うまく操作出来ない部分もある。

あと、本来、タッチペンの長所である、手書きでの入力(文字認識もしくは画像でのメモ)はまだうまく使えていない。

文字認識はちょっと厳しいなと思ったが、メモは使えそうだとおもいつつ、なかなかきれいにメモできない。

短所を埋め切れていない部分、長所を生かし切れていない部分は大いにあるので、

しばらくはタブレットPCとして優先的に使って、どういう具合か調べてみようと思う。


Androidタブレットはもう6年以上使っているので、Windows 10のタブレット機能に期待する部分はけっこうある。

とはいえ、もともとタッチパネル前提のAndroidとWindowsではやっぱり違うし、

Windowsだからこそできることに、タブレットPCが適するかという問題はやっぱりある。

思っていたよりはできると思うが、課題はいろいろありそうですね。


Author : hidemaro
Date : 2019/04/23(Tue) 23:01
コンピュータ・インターネット | Comment | trackback (0)

SフォーマットとかIntel Hexとか

コンパイラやメモリダンプの出力形式がバイナリデータとも限らず、

Sフォーマット(モトローラ形式とも)だとか、Intel Hexだとか、そういう形式が使われることがある。

16進数のテキストで記載されているのだが、解読にはそれぞれの形式の特徴を知っていなければならない。


SフォーマットはSから始まるテキストでメモリデータを記述している。

S1130110DF107A02000FDF10690369930B800B81F3

こんなのがひたすら並んでいる。

最初のS1がレコードの種類、S1は16ビットアドレスのデータという意味だったはず。

13はレコード長、16進数の13なので、レコード長が19byteであることを表している。

0110が先頭アドレスで、DF……81がデータ、レコード長はアドレス+データの長さを表している。

最後のがチェックサムで、レコード長からチェックサムまで全て足すと0xFFになるように計算されている。


Intel Hex形式はこんなのがひたすら並んでいる。

:100130003F0156702B5E712B722B732146013421C7

10がバイトカウント、この行は16バイトのデータを格納することを表している。

次の0130がアドレス、00がレコードの種類でこのレコードはデータを格納していることを表していて、3F……21がデータ、

最後のC7がチェックサムで、バイトカウントからチェックサムを全て足すと0x00になるように計算されている。


というわけで、この2つのフォーマットの考え方はそう変わらない。

アドレスとデータをそれぞれ16進数で表したものをひたすら並べているということだ。

ただ、あまり直感的とは言いがたく、なんとなく解読できるというものではない。

種別・データ長・アドレス・データ・チェックサムが詰め詰めで書かれてますからね。


ROMライターの書き込みなどで使われるフォーマットだそうだが、職場で作っているシステムではバイナリデータでROMライターに入力している。

以前使っていたコンパイラでは、出力データがSフォーマットだったが、即バイナリデータへの変換を行っていた。

というわけで、現在、主に使っているコンパイラでは最初からバイナリデータで出力しているわけである。

そうやって考えると、やや汎用性の劣るSフォーマットやIntel Hexには何のメリットがあるんだろうとなる。


でも明確なメリットもあるんですよね。

セクション間に空白があるようなデータの場合、バイナリでは空白区間を埋めるデータが必要になる。

ところがSフォーマットやIntel Hexの場合、空白区間は書かなければよいだけである。

例えば0x00000000から64kB、0x20000000から16kBというデータを出力する場合、

バイナリデータの場合、ゼロデータで埋めてしまうから512MBにも及ぶ巨大データが生成されてしまう。

ところが、SフォーマットやIntel Hexの場合、64kBと16kBのデータを記載するだけでよい。

16進数のテキストデータなので、2倍以上のデータ量になるが、200kB程度のデータで済むだろう。


SフォーマットもIntel Hexもテキストデータですから、意味さえ理解できれば加工は容易である。

条件次第だが、中間形式としてはSフォーマットやIntel Hexは有益な気がする。

もちろん、ROMライターなどで最終的に必要なのが、これらの形式ならそれでいいんだけど。


Author : hidemaro
Date : 2019/03/28(Thu) 22:53
コンピュータ・インターネット | Comment | trackback (0)

どうやってRAMに持って行くの?

PCでプログラムを動かすときは、プログラムをRAMに展開して動かすわけだが、

マイコンではROMのプログラムを直接動かすことが多いのかな。

ROMから動かすならRAMへの展開とか考えなくてよいし、電源入れてすぐに動くし。

マイコンの性質にもよるでしょうけどね。


一方でパフォーマンスを重視したり、その他の事情によりRAM上にプログラムを展開して動かすこともある。

OSがあれば、OSがプログラムをRAMに展開したりしてくれるんだろうけど、OSがないシステムではどうするの?

やり方次第だが、けっこうめんどくさそう。


開発環境によるのだが、概ね次のような手順である。

  1. RAMに格納する関数を特定のセクション(例えば ramcode)に割り当てる
  2. 1.で割りあてたセクションをRAM領域の適当な領域に割り付ける
  3. 2.の領域のコピーをROM領域上に作る
  4. 初期化処理などで 3.の領域から2.の領域にデータを転送するプログラムをROM領域に作る

開発環境によっては、正しく設定さえすれば、そこまで考えずとも2~4をやってくれるようだが。


うちの職場でこれまで作ってきたシステムでもプログラムをRAMに展開することがなかったわけではない。

それはFlash ROMの書き換え用のプログラム。

ROMの書換を行うプログラムってROMに配置できないのよね。

よく考えれば当たり前のことなんだが。それができると、ROMを消したら実行中のプログラムが消えてしまうし。

ただ、メンテナンス用途でしか使わないし、変更頻度も低いので、手作業で作られている部分がけっこう多い。


ROMアクセスの遅さが足を引っ張っているシステムがあって、プログラムのRAMへの展開が検討されているが、

調べれば調べるほどめんどくさい仕組みだなぁと思う。

RAM展開するだけで、プログラム自体は大きく手が入らないだろうと思っていたが、なかなかそうもいかない。

乱暴に思えた他の対策案の方が実は考えるべきことは少ないかも知れない。

果たしてどうなることやら。


Author : hidemaro
Date : 2019/03/25(Mon) 23:23
コンピュータ・インターネット | Comment | trackback (0)

Tools