goo blog サービス終了のお知らせ 

組み込まれたエンジニア

我輩は石である。名前はまだ無い。

coLinux+ArchLinux

2011-11-05 07:56:58 | Weblog

持ち運び用のマシンでLinuxを使うのに、VMでは重過ぎるので、coLinuxを導入することにする。

カーネルはともかく、OSとしての構成を整えるのにディストリビューションのファイルシステムを導入する必要があるけれど、ここで、coLinuxのサイトに置いてあった、普段使ったことのないArchLinuxを入れてみることにした。

ところが、思ったよりも導入に手間取ったので、備忘録を記す。

何はともあれ、システムアップデートの前に、パッケージ管理ソフトのpacmanをアップデートする必要があるけれど、これが一筋縄ではいかないのだった。

coLinuxのファイルシステムを使うのであれば、次の手順を順番を変更せずに行うこと。

 

  • /dev/cobd2用のFS作成
  • mount -n -o remount,rw /
  • nano /etc/fstab
    • /dev/hda1 -> /dev/cobd0
    • /dev/hda2 -> /dev/cobd1
    • /dev/cobd2 /mnt/ext ext3 noatime 1 1
  • mkfs.ext3 /dev/cobd2
  • nano /etc/pacman.d/mirrorlist
  • mkdir /mnt/ext
  • reboot
  • for i in root home var usr ; do cp -r /$i /mnt/ext; rm -r /$i; ln -s /mnt/ext/$i /; done
  • pacman -Sy
  • pacman -S xz
  • pacman -S expat
    • cd /var/cache/pacman/pkg; xz -d ex*.xz; pacman -U expat*
  • pacman -S db
    • cd /var/cache/pacman/pkg; xz -d db*.xz; pacman -U db*
  • pacman -S openssl -> /var/cache/pacman/pkgでxzを展開し、pacman -Uでインストール
  • pacman -Sd libarchive
  • pacman -Sd libfetch
  • pacman -S pacman
  • pacman-db-upgrade
  • /etc/pacman.d/mirrorlist のJapanの項のコメント削除
  • rm /etc/profile.d/locale.sh
  • pacman -Syu
  •  


    OSEK/VDX (ToppersATK1) alarm.cのパッチ

    2011-09-20 16:37:01 | Weblog

    性能向上がほとんどないのに、無意味なほど複雑と思えるコードを見ると、思わず変更したくなります。

    ATK1のカーネルではalarm.cのカウンタの回し方がそうです。

    オリジナルのコードでは、カウンタを2倍の値まで回していますが、そのメリットはほとんどないように思います。(カウンタの発動の比較時に比較演算が1つ減る程度なので、性能的にはゴミです)

    一方、2倍までまわす弊害は多く、多くの関数で、余分な条件判断を行なわざるをえません。

    パッチファイルは、alarm.patch です。

     


    OSEK/VDX演習用実装

    2011-08-30 21:05:48 | 組込みシステム

    OSEK/VDXは国際標準になっている組込み用OSです。

    このOSを用いた演習を行なうには、通常は組込みマイコンの評価キットなどを用います。

    しかし、評価キットは案外寿命が短く、MPUもボードもあっという間に入手難になったりするので、演習の組み立てに苦労します。

    OSEKはせっかくの国際標準なので、APIより上の層の演習を行なうには、マイコンである必要もないだろうと、演習用にCygwin/Linuxへ実装することにしました。

    実装のターゲットOSの選択として、ToppersのATK1か、OpenSource RTOSのTrampolineを調べていましたが、日本で行なう演習には、コメントが日本語で入っているToppersの方が簡易だと判断し、ToppersATK1をCygwin/Linux上に移植しました。

    移植したコードは、例によって、IP ARCH, Inc.から配布します。

    割込みは、シグナルを捉えて実装していますが、Cygwinは非同期IOでSIGPOLLを発生させることができないようなので、非同期の割込みはタイマとSIGINTの二つで、SIGUSR1とSIGUSR2をアプリケーションが発行可能な割込みとして割込みエントリを定義しています。

    この移植にあたっては、友人のKSU水野先生のnxtOSEK移植コードを参考にさせていただいています。


    WindowsでGHDL

    2011-07-18 17:19:11 | Weblog

    VHDLシミュレータGHDLの本家サイトにWindows版のGHDLがあるので、ダウンロードして使ってみた。

    ところが、どうにも思うように動かない。

    簡単なものなら動くのだけれど、少し複雑なものになると、シミュレーションがそもそもスタートしない。VCDファイルをダンプしてみても、何一つイベントが出てこない。

    始めは自分の記述がおかしいのかと散々記述方法を工夫してみたけれど、結論としては、本家のWindows版は腐っていることが分かった。

    Linux版や、Sourceforgeで配布しているCygwin版なら、同じ記述が難なく動くのだった。

    で、Cygwin版なら、自分が作っているLiveCygwinに入れれば、VerilogもSystemCもVHDLもNSLも開発できる総合環境になるので、便利だと思い、作業をしてみたら、Cygwin版が前提としているCygwinベースバージョンがかなり新しく、LiveCygwinの現在配布版では動かないことが分かった。

    ということで、GHDLを入れて、LiveCygwinのベースバージョンをCygwin-1.7に変更したものを作成した。

    ZIPファイルはこちら

    7zで圧縮したISOイメージはこちら

     

    ライブラリや起動コマンドなどいろいろと変更しているので、バージョン違いによる不整合が出る可能性があります。問題があれば、何なりとご連絡ください。

     

     mingwで動くようになれば、Cygwinに煩わされることはなくなるので、途中までは作業をしたのですが、GHDLのコンパイルには数多くのライブラリを用意しなくてはならず、mingwのライブラリを作って回るのも本質的ではないので断念しました。

     

     


    ビットマップディスプレイとキャラクターディスプレイ

    2011-06-17 07:48:18 | Weblog

    学生と話をしていて、キャラクターディスプレイのことがよく伝わらなかったので、サンプルプログラムを作った。ビットマップディスプレイは直感的だけれど、キャラクターディスプレイは一度間接参照が入るので、初心者には分かりにくいのかも?

    サンプルは、VGAの640x480画面にドットクロック25MHzで80桁x24行(程度)表示する。デバッグ用に、トップモジュールはsimという名前になっているので、FPGAベンダーのツールを使うときには注意が必要。(ファイル名!=トップモジュール)

    フォントは、X11の8x16.bdfを同封し、これからキャラジェネのパターンを抽出するスクリプト、初期画面のデータを作成するスクリプトを用意して、合成可能なVerilogHDLファイルを生成するMakefileも入っている。

    さくっと3時間ほどで作ったので、整理はされていないけれど、短いプログラムなので、じっくり読むと分かると思う。

    ALTERAのDE0で動作確認済み。

     

    DE0は、nCEとVGA出力ピンがぶつかっていて、そのままだとQuartusIIがエラーを出してコンパイルできない。設定から、nCEをユーザーIOに切り替える必要があるそうだ。

     


    NSL: 構造体の初期化

    2011-06-13 09:22:06 | Weblog

    NSLでは、regタイプの構造体インスタンスには初期値を与えられます。

    struct st {
      a[4];
      b[8];
      c[12];
      } ;
    
    declare x {}
    
    module x{
      st reg mm = {5,0x21,543};
      }
    



    注意が必要なのは、

    {5,0x21,543}

    を通常の実行文において記述すると、連結演算子とみなして、連結しようとしてしまうことです。この場合、ビット数推定ができないので、エラーになります。各フィールドのビット数を厳密に指定して記述すれば、初期化でも実行文でも使える記述になるので、好ましいでしょう。

    個々に設定せずに、まとめて0に初期化したい場合、


    st reg mm =0;


    と書くこともできます。


    念のため書いておきますが、wireタイプには初期値は設定できません。


    6502互換CPU NSL版

    2011-05-16 09:32:54 | Weblog
    6502互換CPUのm65をNSLで書き直しました
    シミュレーション上でWozのモニタ(Applie-Iのモニタ)を動作させるパッケージとしています。

    コンパイルは、20110511版以降のNSLCOREが必要となります。
    シミュレーションには論理シミュレータが必要です。私は、Icarus Verilogを使っていますが、シミュレーション構文はあまり複雑なものを合成しないので、大抵のシミュレータで動作すると思います。なお、Makefileを書き換えればSystemCでもシミュレーション可能だと思いますが、まだ試していません。

    この規模の回路になると、行数が多くなるので、NSLCOREの非商用ライセンスが必要になります。

    NSLはSFLよりもできることが多いのですが、SFLのレベルの構文もほぼ用意しているので、SFLからNSLへの書き直しは、機械的にできる軽微な修正となります。なので、あまり時間をかけずに可能でした。ただし、taskを複数利用するケースだけは注意が必要です。SFLのタスクは、それぞれがステージ中の特定の動作状況を表しますが、私(と私を参考にコードを書いた学生)のコード以外に1つのステージに複数のタスクを書く例はほぼなかったので、NSLでは、ステージとタスクを1つの手続きとしてまとめました。m65は複数のタスクと内部関数を使って、直行する制御を実現していたので、この部分の修正が単純な置き換えではできません。

    色々とやり方を検討したのですが、タスク相当のレジスタを手続きの引数で与えることにしました。他にも状態と内部関数を利用するとか、いくつも代替手段はありますが、あまり手間をかけずに動作させることを優先しました。今後、もう少し概念を整理して、きれいな記述になる方法を検討してみます。


    SystemCにおけるオブジェクトの扱い

    2011-05-05 20:05:27 | Weblog
    SystemCでは、シミュレーションの動作環境から、sc_objectを取り出す手法は、標準的に用意されている。

    ところが、取り出したsc_objectをsc_signalに変換しようとすると、一筋縄ではいかない。
    sc_signalがテンプレートで実現されていて、簡単に変換できないようになっている。
    ダイナミックキャストを使うと変換は可能だけれど、試してだめなら他の候補を試すといった、試行錯誤となってしまう。

    NSLから変換したSystemCにおいて、sc_traceに追加する信号を、シミュレーション動作環境から自動的に取ろうと、今日一日いろいろと試していた。

    検討の結果、結局、シミュレーション環境から信号名を拾うことをあきらめ、NSLCOREから、モジュールの階層構造を追いかけて、明示的にsc_traceに追加することにした。
    トレースの信号管理のため、-sc_trace_depthで、何階層まで信号を読み出すのかを指定できるようにした。

    トレース信号だけなら、これで十分だけれど、将来へのステップとして、テストベンチから、シミュレーション環境内のオブジェクトを参照したり更新する方法を考えていたけれど、これはやはりダイナミックキャストを使わないとだめだろう。



    NSLシミュレーション制御構文追加

    2011-05-04 07:44:26 | Weblog
    20110503版で、シミュレーションを制御するための構文を追加した。
    追加した構文は、

    • _initブロック:リセット後自動的に実行される順序実行ブロック。モジュールの実行文より先に1つだけ記述可能。
    • _delay:_initもしくはseqの順序実行ブロックないで、指定する数値の遅延を行う。


    の2つ。
    どちらも、simulation専用構文であり、declare文にsimulationの指定が必要。

    例題を下記に示す。

    declare tut20 simulation { }
    
    module tut20 {
            _init {
                    _delay(100);
                    _finish("Hello World: time = %d",_time);
            }
    }
    



    Cygwinがインストールできない環境へのETロボコンに向けたnxtOSEK簡単インストール

    2011-04-23 11:13:34 | Weblog
    私の職場がそうなのだけれど、簡単にソフトウェアをインストールさせてもらえない環境が増えている。
    ETロボコンでも、(会場に持っていくことを考えると)実際にロボットにプログラムをダウンロードする部分はノートパソコンを使わざるを得ないとしても、プログラムのコンパイル程度は、計算機室などのPCを使いたい要望があるだろう。(ロボットにダウンロードするためには、最低限LEGOのデバイスドライバがないと、LiveCygwinだけでは何ともならないことに注意)

    こういった要望のため、CygwinをCDROMからもしくはフォルダから、インストールなしで直接起動する仕組みをLiveCygwinとして提供してきた

    一時、nxtOSEKインストール済みのLiveCygwinも提供していたけれど、nxtOSEKがあまりに頻繁にバージョンアップしていたので、提供を中断した経緯がある。

    このところ、バージョンアップも落ち着いたし、もう一度、簡単インストールパッケージを作成しておいた。

    導入手順は、次の通り

    1. LiveCygwinのZIPファイルをダウンロード
    2. ZIPファイルを空白や日本語の入らない場所に展開(以下、 C:\LiveCygwinにアーカイブの中身があると仮定する。)
    3. 次の二つのファイルをダウンロードする。

      1. nxtOSEKtools.tar.bz2
      2. nxtOSEK215.tar.bz2

    4. ダウンロードしたファイルを2で展開した場所の下の usr/archに置く。

      • C:\LiveCygwin\usr\arch\nxtOSEK215.tar.bz2
      • C:\LiveCygwin\usr\arch\nxtOSEKtools.tar.bz2

    5. C:\LiveCygwin\startup.bat をダブルクリックしてLiveCygwinを起動


    以上となる。初回は、ツールの展開に時間がかかるけれど、ホームフォルダが残っていれば、次回からは起動は早くなるはず。
    Windowsのデフォルトのホームフォルダはログアウトした時に消えてしまう設定の環境(私の職場だ!)では、startup.batの中を書き換えて、ホームフォルダのデフォルトを変更した方が便利だと思う。

    二つのファイルをusr/archに置いた状態で、C:\LiveCygwinのフォルダの中身をCDROMに焼いておいてもいい。

    どれだけ利用者がいるか不明だけれど、ご利用ください。

    今回は外部ツールはまとめて別ファイルとして、nxtOSEKのバージョンアップ対応を簡単にしておいた。
    (nxtOSEKを新しくする場合、ecorobot/tool_gcc.makの環境変数を書き換え、sg.exeをtoppers_osek/sgにコピーするだけだ)