組み込みOS(第4回)
ステップ4の内容
今までは、プログラムの書き換えのたびに直接ROMを書き換えてきたが、ROMの書き換え回数には上限があるため、この方法を変更する。ROMにはブート・ローダーを書き込んでおき、起動のたびに、シリアル経由でプログラムをダウンロードし、RAMに展開する。この方法なら、ブート・トーダーを完成させてしまえば、プログラム本体を修正するたびにROMの書き換えを行わなくてすむ。
今回は、XMODEMプロトコルによって、ファイルを転送するところまでやる。
シリアル受信用のライブラリ
今後はH8側でも受信を行うので、そのためのライブラリを実装する。
ファイル転送手順
kz_xmodemを使う方法
書籍で標準で使われている転送ツールではなく、kz_xmodemを使用すると、操作手順が少なくて楽。
(参考サイト: http://blog.livedoor.jp/noanoa07/archives/1994090.html)
$ kz_xmodem [送りたいファイル名] /dev/tty.usbserial-FT0UMQ8C
(その後普通に通信)
$ sudo cu -l /dev/tty.usbserial-FT0UMQ8C
書籍通りやる方法(macの場合)
多少操作が増えても、せっかく実装したloadコマンドを使いたい場合は次のようにする。
kzload> load $ ~+ lsx [送りたいファイル名]
(あとは待つだけ)
ABI(Application Binary Interface)
スタックポインタには、レジスタER7が使われている。だから、ジャンプ命令jrsやリターン命令rtsでは、引数を指定しなくても、勝手にER7が使われている。これはコンパイラが自動で行っているが、多くの場合、ABI(Application Binary Interface)という規格でCPUごとに決められている。したがって、CPUのABIをサポートしているなら、違うコンパイラでコンパイルしたオブジェクトファイルでもリンクして正常に動作することができる。
スタートアップの無限ループ
スタートアップ(starup.s)の最後にある
1: bra 1b
このbraは戻り先を覚えない簡易的なジャンプ命令のようなもの。引数の1bは、「この命令より前にある”1:”というラベルの内最も近いもの」という意味である。つまり、直前にそのラベルがあるので、無限ループを表す。これ以前のスタックmain()へのジャンプの後、つまりmain()から戻ってきたとき、おかしな動作をして暴走しないようにする対策になっている。
疑問点
ファイル転送のに関して
lsxと、実装したXMODEMに関するプログラムの役割の範囲がよくわからない。
lsxはひたすらプロトコルのルール通りにビットデータを投げてきて、実装したプログラムは、それを意味のある形で上手く受け取っている?
さらに、kz_xmodemを使用した場合は、実装部分に関しては丸々使わないことになるのでは・・・と思っているけど、その認識はあっているのだろうか。
ABIに関して
対象CPUのためにどのABIを使うのかというコンパイラの設定は、どこでやっているのかがわからない。Makefileの項目のどれかがその設定なんだろうか。
- 作者: 坂井弘亮
- 出版社/メーカー: カットシステム
- 発売日: 2010/05
- メディア: 単行本
- 購入: 24人 クリック: 252回
- この商品を含むブログ (39件) を見る
組み込みOS(第3回)
ステップ3の内容
ステップ2まではできなかった静的変数の書き換えを可能にするため、各ファイルを修正する。
変数の種類
変数にには「静的変数」と「自動変数」という種類がある。これらは、プログラムで宣言された位置によって種類が決まり、割り当てられるメモリ領域も異なる。
静的変数
関数の外で宣言される。初期値がないものはROMのデータ領域に置かれ、あるものはROMのBSS領域に置かれる。
自動変数
関数の内側で宣言される。RAM上に置かれる。
静的変数の書き換え対応
静的変数は、ROMに置かれるが、これだと内容の変更ができないので変数として使用できない。この対策として、マイコンの電源を入れた直後、ROMのデータ領域の内容を、RAMにコピーして、プログラムの変数からはそのコピー先にアクセスするように設定した。コピーはmain.cの最初で行い、設定はリンカ・スクリプトで行う。このような一連の処理を、「
VA≠PAにする」というらしい。
VA(リンク・アドレス/仮想アドレス)
プログラムから静的変数を使うときにアクセスするアドレス
ELF形式
コンパイラが生成する実行形式ファイルのフォーマット。linuxにおいては、readelfコマンドで解析することができ、メモリのセクション情報や、各シンボルが割り当てられている番地などが確認できる。初期値のない静的変数が、BSS領域に置かれている事などもここで確認する事ができる。
(本の環境と異なる部分)
macでは、readdlfコマンドが使えないので、インストールする必要があった。
% brew install binutils
使用するときは、readelfではなく、greadeflとする。
% greadelf -a kzload.elf
その他
疑問が2つほど残った
- リンクとは、プログラム中の関数や変数などのシンボルに対して、メモリを割り当ててやる作業という認識あっているのか?
- リンカの実体は、リンカスクリプトなのか?
12ステップまで、3月中にやりきりたい。なんとしても時間を作り出して確保する。
- 作者: 坂井弘亮
- 出版社/メーカー: カットシステム
- 発売日: 2010/05
- メディア: 単行本
- 購入: 24人 クリック: 252回
- この商品を含むブログ (39件) を見る
組み込みOS(第2回)
ステップ2の内容は、シリアルコントローラのレジスタによる設定、標準ライブラリ風関数の実装が主な内容だった。今回気になったのは「分周」と「ボーレート」の関係くらい。
まず分周とは、CPUのクロック周波数をnで割ってほしい周波数を作ることらしい(n:分周比)。そして、この作った周波数をシリアルモジュールに供給する。
メインクロックを分周するnをBRRに設定すると思っていたんだけど違うらしい。どうもBRRの値とボーレートの対応表がマニュアルにマイコンごとに用意されていて、それを見て設定すれば良いらしい。
マニュアルを見ると、表の他にBBR値の計算式も書かれていた。確かに歩調同期方式の式でBBRは64になる。ただし、(64*2^(2n-1))と−1の部分の意味がわからない。64*2^(2n-1))は設定するシリアル通信で使うビット長とかで違うのかもしれない。ビット長8なら8になるとかだったら理解できる。
クロック同期方式と歩調同期方式の違いもよくわからなかった。この辺も確かに理解したい部分ではあるんだけど、この辺にかかりっきりになってしまうと進まない。この本で一番やりたいのは、メモリ管理とかスレッドの部分なので、あまりここで時間は使わないようにしたい。少し調べて、その時理解できなくても、「具体的にどこが」わからないかを記録しておけば(数学ガール的にいうと「分からないの最前線」)、最低限またあとで考えることができるからよしとしたい。
(蛇足)
第1回の記事からだいぶ間が空いてしまった。期末試験その他いろいろあったが、時間を作れなかったわけではないので結局いいわけ。とにかく、本を進める過程で書き残し続けることはやめたくないので、今回はかなり雑な文章になってしまったが形に残すことを優先した。時間があれば書き直したい。
- 作者: 坂井弘亮
- 出版社/メーカー: カットシステム
- 発売日: 2010/05
- メディア: 単行本
- 購入: 24人 クリック: 252回
- この商品を含むブログ (39件) を見る
組み込みOS(第1回)
『12ステップで作る組み込みOS自作入門』という本を購入した。
以前から気になってはいたが、なかなか手を出さずにいたら存在を忘れてしまっていた。
再び購入意欲が高まった理由は、今期の大学のOSに関する講義があったこと、そしてバイト先(組み込み系の会社)に置いてあるのを見かけて思い出したから。
また、自分の中で不足しているかつ、欲しい知識として、アプリケーション層未満の階層での知識がある。
これは単純に自分の興味がそそられる部分でもあるし、将来的にもその方向で進んで行きたいという思いが最近大きくなっているからだ。
(あとこの動画を見たのも結構大きい。本当に楽しそうに話すので感動した。)
このような直接何かを作り出さない活動に、今のタイミングで時間を使うはどうかという考えが無いわけではないけど(「もっと実践的にカタチのあるものを作ってやりながら学び、実績を作るほうがいいかもしれない・・・」等)、「知りたい!やりたい!」と直感的に思えたタイミングでやるのが、経験的に一番吸収が良いので今すぐやる。
12ステップ、約500ページで少ない量ではないが、最後までさっさとやり遂げてしまいたいと思う。
ここから本題。
今回は初めてなのでステップ1の環境構築をやる。
現在まともに使えるPCがMacBookPro (Retina 13-inch、Early 2015)しかないのでこれを使う。
環境を作る手順は以下のサイトを参考にさせてもらった。
blog.livedoor.jp
書籍ではmacに関することは書かれていないので非常にありがたかった。
購入したケーブル等はすべて同じものを購入して問題なく使えた。
手順もほぼ同じように進めることができた。
ただし、ブログを書かれた方と使用しているgccの種類と設定等が違うようで、ブログには書かれていないエラーが発生したので少し言及する。
binutilsをビルドするとき
clang: error: unsupported option ‘-print-multi-os-directory'
という表示がされた。
調べてみたところ、このオプション‘-print-multi-os-directory'はコンパイル完了後に設定などをただ表示してくれるだけの機能なので、とりあえず無視したが、結果的に今のところは問題ない。
macのgccはLLVMでホントのgccじゃない(?)から云々・・・みたいなことが関係していそうだが、進めることを優先したいのでまた今度考えることにする。
以上、トラブルはこの程度で思っていいたよりもスムーズに、ステップ1は終わった。
新しく知ったことは、このブログに書くことを目標にこれから進めて行きたい。
- 作者: 坂井弘亮
- 出版社/メーカー: カットシステム
- 発売日: 2010/05
- メディア: 単行本
- 購入: 24人 クリック: 252回
- この商品を含むブログ (39件) を見る
「なぜ、あなたの仕事は終わらないのか」の感想
この本はICPCでスポンサー企業の方からいただいたものだ。もとから気になっていたので、ありがたかったが、なかなか読む時間を作れず、昨日やっと読み終えた。いくつか印象に残った点があるのでここに記録しておく。
最初の2割の時間で仕事の8割終わらせる
筆者はこのフレーズを本の中で何度も強調していた。目的は2つ。1つ目は、実際に取り掛かって難易度を認識し、かかる時間の見積もること。2つ目は、後半に心理的余裕を持たせて仕事のクオリティを上げること。(早く提出することではない!)1つ目に関しては、心から納得できた。ちょうど前回のゲーム作成において、取り掛かって初めて必要な仕事と時間が見えてくるということを実感していたからだ。2つ目は当然といえば当然である。わかっているけど難しいことだ。ただ、これも習慣の問題で、本の中で書かれていたように、同じ習慣は66日続けないと定着しないらしが、これは逆に言えばたった2か月さえ頑張れば自分のモノにできるということだ。
目的があれば勉強はたやすい
別の言い方をすれば、「勉強のための勉強はするな」といこと。理由は簡単で、そんなものは続かないので身にならない。逆に、それが必要な場面になれば、「勉強」でなく自然と「調べる」。そして目的をたっせいするために、細かいことなど気にしないで、どんどん前進できる。これに関しても、自分が何度も体験してきたことだから納得できる。例えばPythonやPHPを触ってみたことなど、もちろん無駄ではなかったと思いたいけど、必死になる明確な目的がないからから体には残らない。逆に、今やってるゲーム作りや、夏のインターンでのマイコンの作品などは、目の前に必ず形にしなければならないものが見えていたから自然と貪欲に努力できていた。
「まず作ってみる」が、世界を変える。
これもゲームの企画や開発の初期段階でで、散々感じたことだ。アイディアは最低限動くものがあれば判断がしやすい。面白くなるかどうかの確信は、話だけの時よりもずっとしやすい。採用、不採用に関わらずとにかく判断が早くなる。また、先ほどの繰り返しになってしまうが、「モックアップ」が初期段階で存在しないと、必要な仕事が最初見つけずらいので、最後に焦ってたくさんの仕事をやることになってしまう。
朝が最強
この理由に筆者が挙げていたのは、邪魔(LINE,メールなど)が入りずらいこと、そして外部要因の締め切りができることだった。1点目はいいとして、2点目については特に共感した。自分で決めた内部的要因などは簡単に破ってしまう。一方で外部要因に関しては、精神的にかなりの強制力がある。筆者の場合、それは家族が起きてくることらしいが、自分が体験したのは、人との締め切りである。これだと朝に限ったことだけではなくなるが、外部要因が効果的である点は同じだ。ただ、朝は早くにやると、講義の開始など確かに外部からの締め切りが多いので試してみたい。夜だと、いつまでもダラダラと続けてしまう。
このように見ていくと、ここ2か月ほどでのチームでのゲーム作りから学ぶことは多かったのだなと改めて感じた。最近は、少し怠け気味なところがあったので、この本でまた気持ちが引き締まった。
最近はこの手の自己啓発本を読みたいと思うことは少なくなっていた。以前は結構読んでいたが、多くの場合、読んでも何も変わらないと感じていたからだ。だが、今回は自分の経験と照らし合わせなながら、「あそこでああ考えたのは間違っていなかったんだな。」と答え合わせのような感覚で読んでいた。そのおかげで自分の、ぼんやりとした考えに自信が持てた。そして、これは特に自分が変わらなくてもたくさん読んでいたころからだが、自己啓発本のいいところは「元気が出る」ことだ。これは馬鹿にできない。何をするにしても、元気でなければ何かをやり始めるだけのの自信が出ない。自信なんていう根拠のないものは、こういう本によって「なんか行けそうな気がする」という気持ちになって獲得するものだと思う。以前岡田斗司夫が、自己啓発本のこのような効果について評価しているのを見て、当時は「自己啓発本なんて意味ないんだな」などと思ったが、今ならわかる。「元気が出る」のは本当に重要だ。だから、この本の最後の部分にある筆者の精神論的な熱い話も、自分には意味のあるものだった。なにせ元気が出る。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
- 作者: 中島聡
- 出版社/メーカー: 文響社
- 発売日: 2016/06/01
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
Ruby on Rails ファーストタッチ
友人とその先輩と自分の3人で、今月19日にRuby on Railsを使ったハッカソン的なものをすることになったので、Ruby on Railsの勉強を始めた。
先輩の方はWeb系の会社に就職決まっいて経験も豊富だそうだが、自分と友人はRailsを触ったことがない。
Railsはもちろん、Rubyも経験ゼロからのスタートで、短期決戦型の勉強になる。
webアプリケーションの開発経験もないので、本当にわからないことばかりなので、かなり苦戦が予想される。
とりあえず、「Ruby on Rails アプリケーションプログラム」という書籍の第二章まで、今日一通りやってみた。
Railsについて事前に調べたり、この本を立ち読みした時は、どういうものか本当に何もイメージできない状態だったが、
2章までやったところ、少しだけ全体像が見えてきた。やはり手を動かすことによる効果は大きい。
現在考えてる学習計画は次の通り。
1.「~アプリケーションプログラミング」を3章まで一通りやる。(残り3時間程度)
2.ドットインストールのRailsのレッスンを一通りやる。(2時間程度)
3.Webアプリ的なものを一つ作ってみる。(?)
4.友人との勉強会(12時間程度を一回)
また、Ruby自体の勉強も適宜入れていく予定(Rubyも未経験のため)
ちょうど来週に勉強会をする予定なので、そこまでにアプリが一つ作ることを目標にしたい。
また、学習過程でのルールも次のように決めた。
・学習したことは記録しておく。(キーワード、疑問点、ハマった事、学習時間など)
・わからないことがあっても、あまり突っ込みすぎて悩まないこと。(なんとなくわかったらとりあえず進む)
自分一人でのもくもくと学習を進める分、成果が目に見えない。
せめてもの目に見える結果として、学習の記録を残しておくことでモチベーションを保ちたい。
また2点目については、新しことを学ぶ上で最近重要だと感じることなので今回も実践したい。
気持ち悪く感じる表記なども、繰り返し書き続けると違和感がなくなる。
それによって本当に考えなくてはいけない部分に頭を使えるようになり、理解できることは多い。
新しいものに素早く適応する能力の重要性を、近頃感じることが多い。
今回はそれを磨く良いチャンスだと思うので頑張りたい。
STM32が行けたからこれも行けるハズ。
Ruby on Rails 4アプリケーションプログラミング
- 作者: 山田祥寛
- 出版社/メーカー: 技術評論社
- 発売日: 2014/04/28
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
ゲーム開発(2本目)の反省
Unityによる2本目のゲームを先週リリースした。
前回は友人との2人体制での開発だったが、今回は自分が主導で主に3人で開発を行った。
この3人に前回の友人は含まれていないが、シーン遷移部分などを手伝ってもらった。
リリースは10月中の予定だったが、実際はかなりギリギリになってしまった。
今回の開発過程でいくつか反省する点があったので記録しておく。
反省点は大きく分けて3点。
それぞれについて説明する。
1.取り掛かりのスピード
2.仕事の振り方
3.報告の重要性
1.取り掛かりのスピード
開発に取り掛かり始めるのが遅かった。計画遅れのこれがすべての原因だと思われる。
なんとなくやる気が起きなくてモックアップを作り始めるのが、企画が決まってからだいぶ遅くなった。
ただ、実際にやり始めると、実装方法を楽しく、また意外とすぐに終わった。
モチベーションも上がるし、もっと早くやってしまえばよかった。
2.仕事の振り方
他の二人のメンバーに対して、仕事をうまく振れなかった。
週に1度のミーティングがあったが、ろくに仕事を振れずに終わることが2度ほど続いた。
友人には「お前の仕事の振り方は下手だ。」と言われたが、それよりも大きな原因があると自分は考えている。
モックアップを早く作らなかったことだ。
自分には必要なタスクが見えていなかった。振るべき仕事が自分の中では存在していなかったのだ。
モックアップを作り、さらに具体的な完成が見えなければ、いつまでに何が必要かを把握できない。
そのためには、できるだけ早く作り始めてみる、イメージ図を書いてみる、などをする必要があった。
3.報告の重要性
進捗をこまめに報告するのは、チーム全体の進度を確認するために不可欠なことは改めて確認できた。
しかし、今回学んだもっと大きなことは、「できないとき、やりたくないときは断る。」ということ。
安請け合いしてはいけない。誰かの負担が少し増えるよりも、頼んでおいたことが進んでないことのほうがもっと深刻だ。
また、自分で可能だと判断し、やりたいと思える仕事のほうが、責任感とやる気で効率は上がるしツラくない。
今回のプロジェクトは自分の不手際で、最後の方かなり苦しかったが、いい経験になった。
次に生かしていきたい。