8ビット/24MHz動作の「ATmega1284p」プロセッサでARM Linuxを動かす、ログインできるまで6時間 27
ストーリー by hylom
このチャレンジング精神はどこからくるのか 部門より
このチャレンジング精神はどこからくるのか 部門より
90 曰く、
Dmitry Grinbergという男性が、8ビット/24MHz動作の「ATmega1284p」プロセッサでMMUつきARM Linuxをエミュレーションで動作させたという。
Intel XScale PXA255 の Palm Tungsten E2 をエミュレートしているらしい。さすがにちょっと信じられない。自分の目で見るまでは。
メモリバスを持たないATmegaで (スコア:1)
ATmegaのスペック (スコア:5, 参考になる)
知らない人のために書いておくと、ATmega1284のスペック。
Atmelの8bitマイコンはアーキテクチャが共通で、
レジスタ: 8bit×32本 +PC+SP
命令長16bit固定の純RISC的なロードストアアーキテクチャで、1クロック1命令実行。
開発にはgccが使えます。アーキテクチャが素直なので、Cで書いてもそこそこ効率のよいコードになり、あまりアセンブラを使う必要がありません。
プログラムとデータを完全分離したハーバードアーキテクチャなので、データメモリ(SRAM)にある命令コードを実行したり、プログラムメモリ(フラッシュメモリ)にデータアクセスしたりはできません。
だから、定数テーブルとかデータメモリには置けない(初期化手段がない)ので、大きなテーブルを扱いたいときはその取り扱いにちょっと苦労したりします。プログラムメモリにI/Oアクセスで読み書きすることはできるので、プログラムメモリの一部に定数テーブルを置いてI/Oアクセスで取得する感じ。
で、あとは、主にプログラムメモリの量とデータメモリの量、I/Oピンの数でラインナップが分かれています。ATmega1284 [akizukidenshi.com]のスペックは、
プログラムメモリ: 128KB
データメモリ: 16KB
I/Oピン: 32本
というもの。
ATmegaシリーズの中で、DIPパッケージではメモリ量・ピン数最大のものです。
#40ピンのDIPってZ80とかと同じなんだよなぁ…
30ピンSIMMの信号線はアドレス11本データ8本制御線3本の合計23本ですので、I/Oが32本あるからまあ本数的には余裕。それで転送速度は300KB/sぐらいでてるそうです。
あとは、データストレージとしてSDカードをつないでますが、こっちはSPIというシリアル通信規格を使ってますので、低速ながら信号線3本でアクセスできます。といいつつ200KB/sの速度でアクセスできている。
#このぐらいの速度差なら、SDカードをメインメモリに使えばいいんじゃないのかなーとか思いました。アクセス簡単だし。
#でも、30pinSIMMをマイコンにつなぐというのはそれだけでも男の浪漫だよなぁ…
で、全体としては、ARM 6.5kHzぐらいのエミュレーションになってるそうな。
って、さらに読んでると、ARM命令のキャッシュメモリ量を減らす必要はあるけど、ATmega644 [akizukidenshi.com](プログラム64KBデータ4KB)でも、動くって書いてある。
そこまでコンパクトにエミュレータをまとめるってのはすごいなぁ…
#AVRでZ80エミュレータ書きかけて挫折したのでID。
Re: (スコア:0)
8bitマイコンではcharの整数をよく使いますが、GCC(2年くらい前 3.4.3)はint未満な整数を使うとコードの品質が悪いように見えました。最近のは問題ないですか?
なんかCのルールを愚直に実装したようなintへの格上げを行いがちでしたね。同じようなコードでも、たまに最適化がかかってたりして、わけが分からなかった。
例えば、char aをa > 0と比較するとaを16bit整数に拡張してから比較するコードが出来てたりしました。たまに8bitのまま比較するコードが出来てたりするんですよね。
たしか、PCでも同じ感じだったから、アーキテクチャには依存しないと思う。
Re:ATmegaのスペック (スコア:4, 参考になる)
> GCC(2年くらい前 3.4.3)はint未満な整数を使うとコードの品質が悪い
気になったのでちょっと調べてみましたが、特に問題なさそうです。
使ったのはWinAVR-20100110(gcc-4.3.3) [sourceforge.net]ですが、
このCコードが、avr-gcc の-Osで、
というアセンブリコードになってます。
> 8bitマイコンではcharの整数をよく使いますが、
Arduinoというマイコンモジュールが、AVRマイコンで開発環境はgcc+ラッパーライブラリという構成なんですけど、
Arduino用のコードを見てると、けっこう long を使っている人が多いんですよね。
(avr-gccでintは16bitなのに、わざわざlong指定で32bitにしてる)
速度やメモリ効率を気にしてないのか、もうなんか富豪的プログラミングがこんなところにまで来ているのかとショックを受けてしまいます。
#まあ、私も8bitパソコン時代にBASICではそこまで細かいデータ型は気にしてなかったし、似たようなものなのかもしれませんが…
Re: (スコア:0)
わざわざ調べてくれてありがとう。
久しぶりにちょこっと見直して見たんだけど、それらしいのは1例しか見つからなかった。
問題が出やすいのは-O3とかの時だったか、もっと昔のGCCだったかな?
記憶が結構怪しいようです。
で、avr-gcc 4.5.3でコンパイルしなおしたら、その1例も消えました。
Re:メモリバスを持たないATmegaで (スコア:1)
しかもその16本をAtmegaの各IOピンに直接繋いでる辺りに、作者のこだわりを感じます。
DRAMリフレッシュにはCPU時間の3%も割かれてるようで、ハードウェアだけ見るとまるでメモリドライバみたいですね。
Re: (スコア:0)
データバス・アドレスバスだけでなく、R/W制御信号などの制御線も必要になると思います。
データバスを削ると転送回数が増えて性能低下に直結するので、削るならアドレスバスかな。
アドレスバス8bitでも厳しいけど。
retrobsdとかgameboy linuxとか (スコア:1)
8bitじゃないけど、低スペックのCPUで動かすものとしたら
・Microchip PIC32 [microchip.com]で動作する2.11BSD「retrobsd [google.com]」
・Gameboy Advanceで動作するUNIX® on the Game Boy Advance [kernelthread.com]
Re:retrobsdとかgameboy linuxとか (スコア:2)
この試みはスキルアップ目的と技術デモでしょう。凄いけど実用にはならないが
開発を通して得た副産物はいろいろと応用が効きそうな気もします。
ほんとに使おうと思うなら、そういったものとか、MSX上で作られたVersion 7 UNIX
クローンのUZIX
http://www.nodus.ne.jp/ghost/msx/uzix-j.html [nodus.ne.jp]
なんていうのもありましたが、こういうのがいいんでしょうね。あとuClinuxも16ビットで
動いたから、その辺をなんとかしてみるとか。
MSXやかつてのPC-6001シリーズあたりはゲームから入れる敷居の低さと、
抽象度が低いということで年少者の格好の教材になってて、いまならマイコンボードが
その代わりになってくれるといいんだけど、ハードハードしたイメージがあるので
ちょっと敷居が高いのが難点ですか。いまのPCとそのOSは抽象度が高くて
低レベルな所のスキルアップに向いてないですから何か代わりにあるのがあると
いいかなと思うんですけど。
Re: (スコア:0)
> MSXやかつてのPC-6001シリーズあたりはゲームから入れる敷居の低さと、
> 抽象度が低いということで年少者の格好の教材になってて、いまならマイコンボードが
そのへんだと、最近では任天堂DSi/3DSで DSiウェアの「プチコンmkII」という選択肢もあったりします。
年少者よりもオッサンが群がっている気がしますがw
わからん (スコア:0)
デバイスのエミュレーションはたしかに面倒くさいのだが、根気以外に必要なものもなさそうだ
エミュレーションホストのほうに著しい制限があるのか？
おっちょこちょいのために言っておくと、disっているわけではないので
Re:わからん (スコア:1)
その根気が、尋常じゃない根気だろうから、それだけでもすごいと思うけど、
あとは、他コメントにあるけどメモリの問題で、それは直接制御で回避してるけど、
それは制御するソフトウェア書いたって事だからそれはそれですごい。
そのメモリもそうだけど、難しい点の一つが、リアルなハードウェアはリアルな時間の流れのなかで動作しているので、
その時間制約をクリアする点で、今回はハードウェアが少ないから、まだましだったのかな。
あとは、linux側もタイムアウトとかタイマ割り込みとかあると思うので、その辺の制約とか安定性確保とか、
linuxのドライバ回りに精通していないとなかなか難しいのでは。それもすごい。
というかデバッグ環境どうしてたんだろう。
最初はエミュレータの上でエミュレータの開発してたんだろうけど、最終的にはそういう実機でないと出ないバグあるから、
2時間動かして止まっててRAMリフレッシュ止まってコア吐く前に消えてとか、考えただけで嫌になる。
趣味で好きだからこそできたんだろうな。
Re:わからん (スコア:2)
デバイスのステートだけを見て書いてるプログラムの場合は、ステートさえちゃんと反映しておけば、特に問題無いです。
ステート見ずに、他の手段でタイミングを計っている場合は、そのタイミングを計っているデバイスをちゃんと実装すればそんなに問題は無いです。
そのタイミングを計るデバイスがそれぞれバラバラの場合は、それぞれの動作タイミングを合わせないと全然動かない場合が多いです（これが一番厄介）
エミュレータが扱う時間も、仮想時間、実時間、がありますから、実→仮想時間へのマッピングや、仮想→実時間へのマッピングなんかが問題になる場合もあります。
今回のコレは、想像で書いて申し訳ないのですが、恐らくデバイスの制御はステートを見てコントロールしてるんじゃないかと思います。
個人的にはメモリ空間を表現するのが大変だっただろうなぁ・・・と。
DOSのEMSみたいにいったんばらばらにして、仮想的に大域を表現したのかなと。
Re:わからん (スコア:1)
以前話題に上った
「ラジコンのミニチュア重機で地下室を掘る」とか、
http://idle.srad.jp/story/12/02/18/1921222/%E3%83%A9%E3%82%B8%E3%82%B3... [srad.jp]
技術書でも欧米人の書いたものに「厚さ」と「濃さ」に、その精力とか根気の強さを感じるものがあったり
以前の上司は、それを体格と肉食のなせる技だと言いながら、肉ばかり食べて腹回りばかり立派にしていましたが
でも、こういう根気強さが育まれ許される(これも一種の)文化の違いかなあと思います。
何でも文化のせいにはしたくないけど、根気を保てる「環境」が必要なのでしょう。
Re: (スコア:0)
まぁ世の中根気さえあれば何でも出来ますよね(棒
#根気さえあれば著しい制限があるのか?とか疑問系で放置するバカなまねをしないでもすみますし
Re: (スコア:0)
警告していたのにやっぱりおっちょこちょいというか馬鹿が沸いてきたね
イメージ的にマイクロプログラミングっぽいな
Re: (スコア:0)
警告(笑)さえしとけば何言っても許されるとか思ってる馬鹿が何言ってるの
Re: (スコア:0)
ここ最近、反論禁止の前置きをしつつ狭量な意見を投げる人が出没してますね。
今の時期は学生さん暇なんでしょうけど、反論が嫌ならもう半年ROMってた方が…。
Re: (スコア:0)
ほっときゃいいのにいちいち噛みつく人も出没してますね。
Re: (スコア:0)
> エミュレーションホストのほうに著しい制限があるのか？
あるんだよ。
外バスのないプロセッサで無理矢理GPIO経由でメモリアクセスしてるという状態が「著しい制限」でないと思ってるとしたら、相当の大馬鹿だ。
Re: (スコア:0)
> 外バスのないプロセッサで無理矢理GPIO経由でメモリアクセスしてるという状態が
GPIOでアドレッシングするだけなら普通のテクニック。8bit時代の漢字ROMとか大容量RAMボードとか。
結果として、エミュレーションというよりマイクロプログラム的になったのは確かに面白い。
わざわざDRAMをつけたりするところも趣味全開で面白いし、taka2氏の投稿によれば少ないメモリ(これは著しい制限だね)でよくやっていると思う。
Re: (スコア:0)
「GPIOでアドレッシングするだけ」ではないので的外れ。
> 8bit時代の漢字ROMとか大容量RAMボードとか。
GPIOだけでアクセスしている例はないですね。
バンク切り替えの話をしているとしたら、全然違う。
> エミュレーションというよりマイクロプログラム的
何度もこの言い回しをしているようだが意味不明。
Re: (スコア:0)
> 何度もこの言い回しをしているようだが意味不明。
あなたがマイクロプログラムについてご存知ないからでしょう。
マイクロプログラムはCPU内部やメモリアクセスの信号をあらかた全部自分で作って出力するわけです。
これと8bit時代の例をあげたテクニックと合わせてはじめて、私の「確かに面白い」という感想が理解できるようになります。
「GPIOでアドレッシングするだけ」「GPIOでアドレッシングするだけ」というあなたの理解がいかに的外れかは明白です。
大事なことなので何度もこの言い回しを繰り返しました。
Re: (スコア:0)
「マイクロプログラム」と書けばが何か説明した気になっているというあたりが頭悪いです。
> マイクロプログラムはCPU内部やメモリアクセスの信号をあらかた全部自分で作って出力するわけです。
という理解がすっとこどっこいです。
> 8bit時代の漢字ROMとか大容量RAMボードとか
のどこに「マイクロプログラム」が絡んでますか？
GPIOでCSを設定してるだけ(バンク切り替え)なのと、GPIOだけでアドレス/データバス/CE/WRその他諸々全部制御してメモリリフレッシュまで行っているのが一緒と思える頭が気の毒です。
Re: (スコア:0)
> GPIOでCSを設定してるだけ(バンク切り替え)なのと、
誰がバンク切り替えだと言いましたかね。
バンク切り替えではコードを任意の場所に置けないので、8255などのポートにRAMを接続して制御するタイプのメモリボードが結構あったのです。
自分の無知を他人に当てはめないでください。
> GPIOだけで
GPIOでCPU内部のラッチをエミュレートしているだけですね。
> アドレス/データバス/CE/WRその他諸々全部制御して
マイクロプログラムとはそういうものです。ご存知ないとはさすが無知の大王。
> メモリリフレッシュまで
前項とあわせてこのへんが今回の記事の面白みのあるところです。
Raspberry Piという選択肢 (スコア:0)
LinuxマイコンボードRaspberry Pi、国内でも3,400円で発売へ
http://hardware.srad.jp/story/12/03/14/1336254/ [srad.jp]
カードサイズPC " Raspberry Pi "また延期、今度はCEマーク取得のため
http://japanese.engadget.com/2012/03/29/pc-raspberry-pi-ce/ [engadget.com]
調べたらまだ発売されていなかったから作ったんですね。