コメント
Unknown
(
うだがわ
)
2009-05-06 13:30:38
nekosanさん、こんにちは。
AVRぱっくまんのバーアップを色々と画策していたんですが、
Mega328でやっていても満足の行く結果にならなさそうですし、
カラー化もむずかしそうだったのでとうとうARMマイコンに浮気しました。
ARM等は電子工作には不似合いなんですが、
今回は雑誌付録限定ということで挑戦を始めました。
今度こそは、コーヒーブレーク等も忠実に再現しようと思います。
http://www7.big.or.jp/~kerokero/arm/
Unknown
(
nekosan
)
2009-05-06 22:22:48
うだがわさん、こんにちは。
ＡＲＭ基板…Ｃｈａｎさんのところ
http://elm-chan.org/junk/cq_lpc/report.html
で触れられていた基板ですね。
７２Ｍｈｚですか…これならデコードしながらカラー表示するのも出来そうな予感。
Ｃｈａｎさんの記事を読んでいて、なんとなく触ってみた基板だなぁと思っていたんですが、アーキティクチャ的にはどんな感触ですか？組みやすい感じですか？
とりあえずカラー表示は既に出来ているようですね。小山先生のＡＶＲでカラー表示のプログラムは、デコード処理を挟み込むところが無いので厳しいものが有りますが（ＡＶＲのクロックではこのあたりどうしようも無いのですが）、ＡＲＭならなんとかなってしまうんですねぇ。すばらしい。
Unknown
(
うだがわ
)
2009-05-07 08:20:22
ARMは普通の処理を担当させるには非常にパワフルなんですが、ARMに限らず昨今のCPUは高速化の手法として多段パイプラインや分岐予測をやっていまして、テレビ表示のようなタイトなタイミングでのプログラムは暴れ馬をコントロールするくらい試行錯誤が必要です。
アライメントや分岐予測のせいでnopが一個加わっただけでもループタイミングが大きく崩れてしまい、さっきまでうまく表示できていた結果が台無しになってしまいます、分岐予測が外れた際のペナルティーも３段分捨てられるという非常に大きなペナルティーとなり一筋縄では行きません。
現状のカラーバーも偶然の結果に過ぎず、VRAMデコードという作業の埋め込みには苦労している最中です。AVRのように概ね命令でのクロック数が決まっていてページ跨ぎ以外では崩れることが無いのは扱いやすかったのかも知れません。
今回のマイコンでは同じ内蔵RAMに対する同じ命令でも１～３クロックと消費が異なり、隣り合う命令やレジスタの競合でパイプラインが崩れてしまうケースもありパニクっている最中です。最初は余裕と思ったクロックも既に限界まで使いパズル状態でＣＧのビットアサインも５転６転しています。
RAMもCPUへ直接ではなくAHBというバス経由での接続なので、CPUの都合通りにアクセスが終了する訳でも無さそうです。実際にリセットごとにカラーバーが反転してしまったりと意図しない周期ずれが突然発生しています。
あ～殆ど愚痴になってしまった。ともかく現状は苦労の連続です。ARM手を出してしまったことにちょっと後悔すら覚えますが、何とか乗り切りたいと思います。nekosanさんも是非触ってみて下さいよ～。
マイコン自体は非常によく出来てると思います。ただ周辺回路が多すぎて設定に１週間掛かりました。クロックやボーレイトにパワーコントロールと一機能を設定するのに２～３箇所のブロックを跨って設定せねばならず骨が折れました。欲を言えばPWMが１個は少ないです。制御用に使うなら４個は欲しいところ。
長文失礼しました。
Unknown
(
nekosan
)
2009-05-08 00:03:48
ほへーーーー！高速処理は多段階パイプラインによるものなんですか…ＡＲＭ…
カラービデオ信号に使うとなると、暴れ馬というか問題児？？？これは厄介だ…
むしろ、カラーバーまでよく行き着きましたねぇ！
パイプラインといえば、ＰＩＣも1段階を登載してるし、ＡＶＲも（ドキュメントに明示されていませんが）多分同様に1段階のパイプラインを登載しているっぽい感じですけど、これらは1段階だから分岐予想が外れた時のクロック計算が解りやすいですもんね。
ペンティアムシリーズなんかも多段階のパイプラインを積んだり、ｘ８６命令をＭＰＵ内部でマイクロコードに変換（分解）してから実行することでパイプライン化しやすくしてたり（ＲＩＳＣとＣＩＳＣのいいとこ取りっていうやつ）してますが、その代りタイミング管理はペリフェラル任せでしょうからね…
一部処理を別チップに処理分散させるとか、部分的にＣＰＬＤを持ち出すとかしたほうがラクチンかも知れませんね…
といっても、うだがわさんはワンチップにキッチリ纏めこむのが得意とお見受けしたので、今後の進化が楽しみです。（^O^)
（ハードル上げてなーーいっす！）
ＰＷＭが1個っていうと、サブキャリア信号の生成にＰＷＭを使うのも少々難しそうですね。各ラインにおけるカラーバーストの位相ズレを起こさないためには、ＰＷＭで自動的に信号を作り出すのが一番ラクチンで安定な気がするんですが…
Unknown
(
うだがわ
)
2009-05-08 17:46:35
>ＰＷＭで自動的に信号を作り出すのが一番！
>部分的にＣＰＬＤを持ち出すとか
そうなんですよね、PWMがもう一系統あれば3.58を外部供給できるので、CPLDなりシフトレジスタなりで補佐できるんですよ。
現行CPUではPWMが１系統しか無く、それを外部クロック用に振り向けてしまうと、音声のD/A用としても使えなくなってしまうので、音声D/Aも一緒に外部回路で補佐して貰わないとなりません（泣。
なかなか一筋縄では行きませんねぇ。 他に打開策とか思いついたらお願いします。
そろそろ心が折れ始めていますので、よろしくお願いします。
Unknown
(
nekosan
)
2009-05-09 00:21:00
ＣＰＵクロックを外部出力する機能とか付いてますかねぇ？
もし付いていたら、汎用ロジックＩＣ（同期カウンタ74HC161とか）に繋いでサブキャリアの位相を自動カウントさせられるのでは？と…。
http://brown.ap.teacup.com/nekosan0/551.html
この日の日記で実験してたのは、実はＣＰＵクロックを外部に出力して、カウンタＩＣで受けて、それでサブキャリアを生成してしまおうっていう実験の一部だったんですが、今のところ私もノイズやらなにやらで上手く行ってないので、自信はありませんが…
Unknown
(
うだがわ
)
2009-05-09 01:21:12
あ、おいらの目は節穴かよ。
英文マニュアルで見慣れない単語だったので見逃していました”MAT0-3”MatchOut端子がタイマーの４系統から独立で出力出来ました。Timer覧をしっかりとチェックしたつもりだったのですが使われてる用語がおいらの辞書になさげなモノだったので、素通りさせてしまいました。タイマーは２系統余っているので任意の周波数出力が可能でした。 バンザーイ！！！ 問題解決です。
でもまぁ、CPLDに頼るのは最後の最後なので保険が出来たことで多少勇気が出てきました。
ありがとうです。
Unknown
(
nekosan
)
2009-05-09 23:45:07
一歩前進でしょうか…
ひとまず、保険を掛けて先に進める方が安心ですもんね。
サブキャリアのフェーズ。タイミングがシビアすぎて、ソフトだけでやるのはキビシイですよね。
Unknown
(
うだがわ
)
2009-05-10 14:02:57
オプティマイズのカメレオンUSB－FX2組み立てました（ぉ
いきなりチップコンデンサーの半田付けとかハードル高過ぎでしょ。
んー今更9500シリーズって時代でも無いしなぁ、
ディスクリートじゃ位相テーブルを持たせるのも一苦労だし困った･･･
ARM+FPGAの一体型基板どこかで扱っていないのかなぁ。
とか言ってるとお手軽電子工作とは行かなくなってきてしまうので、
もう一踏ん張りするかな。
Unknown
(
nekosan
)
2009-05-11 02:04:33
カメレオンＵＳＢ－ＦＸ２は、この種のモノにはいいパッケージかもしれませんね。ＣＰＵ＋ＣＰＬＤで。
ＭＡＸ２はＮＴＳＣエンコード程度なら容量的に必要充分だろうし、あとはＣＰＵ側のスペックが気になるところでしょうか。
FX2LPの使い方が良くわかんないので私は手を出したことが無いんですが（というかこのボードといえばＵＳＢ用途という固定観念があったので）、ボード全体のパッケージとしては良く出来てるのに安くてイイカンジですねぇ。
なんだか欲しくなってきた…
作るとなると、チップ部品。オプティマイズのＭＡＸ２ボードを作った際は数個のチップ部品でひぃひぃでしたから…
あとはＡＶＲとＭＡＸ２を登載したボードなんていうのがあると面白いんですけどね… ＡＴ９０ＵＳＢ１２８７＋ＭＡＸ２とか。
Unknown
(
nekosan
)
2009-05-17 00:50:18
このムービーはカメレオンＵＳＢ－ＦＸ２じゃなくてＡＲＭのものですね？
画面構成といい動きといい、かなり実物と近いところまで再現されてますね。
よくぞここまで…といった感じです。ドットブレとかも全然無いんですねぇ。見事…
Unknown
(
うだがわ
)
2009-05-17 20:28:40
こんばんは。
動画は一応ARMオンリーでの出力映像ですよ。
今ようやく音も入れました。めでたしめでたし。でも、ちょっとデータを追加の度に映像が崩れます。 同期関係は先頭に配置してるんですが、最適化の都合で微妙に配置が変わるんでしょうか。 一応、全てのデータとモジュールは組込みました。 ROM容量は54KB。
あとは色調整とバグ取りとスコアをどうやって残すかですね。
EEPROMが無いようなのでフラッシュの一部を自己書き換えすると思いますが、またデータシートと睨めっこしなきゃなりません。
ギリ今月末に完成ってところでしょうか。
AVRで叶わなかった想いを全て注ぎ込みますよぉ（ぉ
Unknown
(
nekosan
)
2009-05-18 01:50:33
５４ＫＢですか。オリジナルって何キロくらいだったんでしょうかね？５４ＫＢだったらオリジナルより小さくて済んでいるのかも…
ＦＬＡＳＨの自己書き換えって、なんか昔Z80で組んでた頃によく使った様に、実行用コード自体を自分で上書きして処理内容を切り替えちゃうっていう感じとか…
プログラムの先頭（初期化処理）でハイスコアを初期化する代入文のところを自己書き換えして、リセットの都度ハイスコアが自動で設定される、と。
（Ｃ言語だと最適化度合いとかによってアドレスが変わっちゃったりするから難しいかな…）
あまりアドレスが若いところを書き換えまくってると、ＦＬＡＳＨの寿命もあるので、後ろの後ろの後ろの方がいいかもしれませんね。
Unknown
(
うだがわ
)
2009-05-18 08:18:09
オリジナルは総計28KBくらいかと思います。（アケ基板を持っていたので）
増えた理由は32bitのRISCコードと映像出力部分の冗長性の高いコードによるものです。
自己書き換えと言っても自身のプログラムコードを変化させる意味ではなく、自分の走行しているROM領域を消去したりするのでヘタをすれば暴走しかねない行為のため、自己書き換えと呼ばれています。
2300シリーズではコード領域とデータ領域は明確に分かれていてコード区分の書き換えは出来ないみたいですね。
FLASHの寿命を気にする程プレイしてくれませんからっ^^;
プレイして尚且つ記録を更新し続けることは実際不可能だと思いますよ。 推測では100回がいいところでしょう。
今回パッドはUSBにしたかったんですが、クロックがあれなもんで使えないのでAVRの似非USBホストを真似ようかと。
http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html
12MはARM基板から分配しますかねｗ
Unknown
(
nekosan
)
2009-05-18 23:21:51
USBマスターも処理しながらっていうと、結構厳しくなりそうですね。
ＨＩＤ機器をＵＳＢ未対応のマイコンで扱ってみようと思って以前本を買いあさったんですが、いまだ実現できてません…
まさにそのいしかわきょうすけさんのｔｉｎｙ２３１３版ＵＳＢコントローラを目指したかったんですが…
コメントを投稿する
名前
タイトル
URL
コメント
※絵文字はjavascriptが有効な環境でのみご利用いただけます。
▼ 絵文字を表示
携帯絵文字
リスト１
リスト２
リスト３
リスト４
リスト５
ユーザー作品
▲ 閉じる
コメント利用規約
に同意の上コメント投稿を行ってください。
コメント利用規約に同意する
数字4桁を入力し、投稿ボタンを押してください。
AVRぱっくまんのバーアップを色々と画策していたんですが、
Mega328でやっていても満足の行く結果にならなさそうですし、
カラー化もむずかしそうだったのでとうとうARMマイコンに浮気しました。
ARM等は電子工作には不似合いなんですが、
今回は雑誌付録限定ということで挑戦を始めました。
今度こそは、コーヒーブレーク等も忠実に再現しようと思います。
http://www7.big.or.jp/~kerokero/arm/
ＡＲＭ基板…Ｃｈａｎさんのところ
http://elm-chan.org/junk/cq_lpc/report.html
で触れられていた基板ですね。
７２Ｍｈｚですか…これならデコードしながらカラー表示するのも出来そうな予感。
Ｃｈａｎさんの記事を読んでいて、なんとなく触ってみた基板だなぁと思っていたんですが、アーキティクチャ的にはどんな感触ですか？組みやすい感じですか？
とりあえずカラー表示は既に出来ているようですね。小山先生のＡＶＲでカラー表示のプログラムは、デコード処理を挟み込むところが無いので厳しいものが有りますが（ＡＶＲのクロックではこのあたりどうしようも無いのですが）、ＡＲＭならなんとかなってしまうんですねぇ。すばらしい。
アライメントや分岐予測のせいでnopが一個加わっただけでもループタイミングが大きく崩れてしまい、さっきまでうまく表示できていた結果が台無しになってしまいます、分岐予測が外れた際のペナルティーも３段分捨てられるという非常に大きなペナルティーとなり一筋縄では行きません。
現状のカラーバーも偶然の結果に過ぎず、VRAMデコードという作業の埋め込みには苦労している最中です。AVRのように概ね命令でのクロック数が決まっていてページ跨ぎ以外では崩れることが無いのは扱いやすかったのかも知れません。
今回のマイコンでは同じ内蔵RAMに対する同じ命令でも１～３クロックと消費が異なり、隣り合う命令やレジスタの競合でパイプラインが崩れてしまうケースもありパニクっている最中です。最初は余裕と思ったクロックも既に限界まで使いパズル状態でＣＧのビットアサインも５転６転しています。
RAMもCPUへ直接ではなくAHBというバス経由での接続なので、CPUの都合通りにアクセスが終了する訳でも無さそうです。実際にリセットごとにカラーバーが反転してしまったりと意図しない周期ずれが突然発生しています。
あ～殆ど愚痴になってしまった。ともかく現状は苦労の連続です。ARM手を出してしまったことにちょっと後悔すら覚えますが、何とか乗り切りたいと思います。nekosanさんも是非触ってみて下さいよ～。
マイコン自体は非常によく出来てると思います。ただ周辺回路が多すぎて設定に１週間掛かりました。クロックやボーレイトにパワーコントロールと一機能を設定するのに２～３箇所のブロックを跨って設定せねばならず骨が折れました。欲を言えばPWMが１個は少ないです。制御用に使うなら４個は欲しいところ。
長文失礼しました。
カラービデオ信号に使うとなると、暴れ馬というか問題児？？？これは厄介だ…
むしろ、カラーバーまでよく行き着きましたねぇ！
パイプラインといえば、ＰＩＣも1段階を登載してるし、ＡＶＲも（ドキュメントに明示されていませんが）多分同様に1段階のパイプラインを登載しているっぽい感じですけど、これらは1段階だから分岐予想が外れた時のクロック計算が解りやすいですもんね。
ペンティアムシリーズなんかも多段階のパイプラインを積んだり、ｘ８６命令をＭＰＵ内部でマイクロコードに変換（分解）してから実行することでパイプライン化しやすくしてたり（ＲＩＳＣとＣＩＳＣのいいとこ取りっていうやつ）してますが、その代りタイミング管理はペリフェラル任せでしょうからね…
一部処理を別チップに処理分散させるとか、部分的にＣＰＬＤを持ち出すとかしたほうがラクチンかも知れませんね…
といっても、うだがわさんはワンチップにキッチリ纏めこむのが得意とお見受けしたので、今後の進化が楽しみです。（^O^)
（ハードル上げてなーーいっす！）
ＰＷＭが1個っていうと、サブキャリア信号の生成にＰＷＭを使うのも少々難しそうですね。各ラインにおけるカラーバーストの位相ズレを起こさないためには、ＰＷＭで自動的に信号を作り出すのが一番ラクチンで安定な気がするんですが…
>部分的にＣＰＬＤを持ち出すとか
そうなんですよね、PWMがもう一系統あれば3.58を外部供給できるので、CPLDなりシフトレジスタなりで補佐できるんですよ。
現行CPUではPWMが１系統しか無く、それを外部クロック用に振り向けてしまうと、音声のD/A用としても使えなくなってしまうので、音声D/Aも一緒に外部回路で補佐して貰わないとなりません（泣。
なかなか一筋縄では行きませんねぇ。 他に打開策とか思いついたらお願いします。
そろそろ心が折れ始めていますので、よろしくお願いします。
もし付いていたら、汎用ロジックＩＣ（同期カウンタ74HC161とか）に繋いでサブキャリアの位相を自動カウントさせられるのでは？と…。
http://brown.ap.teacup.com/nekosan0/551.html
この日の日記で実験してたのは、実はＣＰＵクロックを外部に出力して、カウンタＩＣで受けて、それでサブキャリアを生成してしまおうっていう実験の一部だったんですが、今のところ私もノイズやらなにやらで上手く行ってないので、自信はありませんが…
英文マニュアルで見慣れない単語だったので見逃していました”MAT0-3”MatchOut端子がタイマーの４系統から独立で出力出来ました。Timer覧をしっかりとチェックしたつもりだったのですが使われてる用語がおいらの辞書になさげなモノだったので、素通りさせてしまいました。タイマーは２系統余っているので任意の周波数出力が可能でした。 バンザーイ！！！ 問題解決です。
でもまぁ、CPLDに頼るのは最後の最後なので保険が出来たことで多少勇気が出てきました。
ありがとうです。
ひとまず、保険を掛けて先に進める方が安心ですもんね。
サブキャリアのフェーズ。タイミングがシビアすぎて、ソフトだけでやるのはキビシイですよね。
いきなりチップコンデンサーの半田付けとかハードル高過ぎでしょ。
んー今更9500シリーズって時代でも無いしなぁ、
ディスクリートじゃ位相テーブルを持たせるのも一苦労だし困った･･･
ARM+FPGAの一体型基板どこかで扱っていないのかなぁ。
とか言ってるとお手軽電子工作とは行かなくなってきてしまうので、
もう一踏ん張りするかな。
ＭＡＸ２はＮＴＳＣエンコード程度なら容量的に必要充分だろうし、あとはＣＰＵ側のスペックが気になるところでしょうか。
FX2LPの使い方が良くわかんないので私は手を出したことが無いんですが（というかこのボードといえばＵＳＢ用途という固定観念があったので）、ボード全体のパッケージとしては良く出来てるのに安くてイイカンジですねぇ。
なんだか欲しくなってきた…
作るとなると、チップ部品。オプティマイズのＭＡＸ２ボードを作った際は数個のチップ部品でひぃひぃでしたから…
あとはＡＶＲとＭＡＸ２を登載したボードなんていうのがあると面白いんですけどね… ＡＴ９０ＵＳＢ１２８７＋ＭＡＸ２とか。
画面構成といい動きといい、かなり実物と近いところまで再現されてますね。
よくぞここまで…といった感じです。ドットブレとかも全然無いんですねぇ。見事…
動画は一応ARMオンリーでの出力映像ですよ。
今ようやく音も入れました。めでたしめでたし。でも、ちょっとデータを追加の度に映像が崩れます。 同期関係は先頭に配置してるんですが、最適化の都合で微妙に配置が変わるんでしょうか。 一応、全てのデータとモジュールは組込みました。 ROM容量は54KB。
あとは色調整とバグ取りとスコアをどうやって残すかですね。
EEPROMが無いようなのでフラッシュの一部を自己書き換えすると思いますが、またデータシートと睨めっこしなきゃなりません。
ギリ今月末に完成ってところでしょうか。
AVRで叶わなかった想いを全て注ぎ込みますよぉ（ぉ
ＦＬＡＳＨの自己書き換えって、なんか昔Z80で組んでた頃によく使った様に、実行用コード自体を自分で上書きして処理内容を切り替えちゃうっていう感じとか…
プログラムの先頭（初期化処理）でハイスコアを初期化する代入文のところを自己書き換えして、リセットの都度ハイスコアが自動で設定される、と。
（Ｃ言語だと最適化度合いとかによってアドレスが変わっちゃったりするから難しいかな…）
あまりアドレスが若いところを書き換えまくってると、ＦＬＡＳＨの寿命もあるので、後ろの後ろの後ろの方がいいかもしれませんね。
増えた理由は32bitのRISCコードと映像出力部分の冗長性の高いコードによるものです。
自己書き換えと言っても自身のプログラムコードを変化させる意味ではなく、自分の走行しているROM領域を消去したりするのでヘタをすれば暴走しかねない行為のため、自己書き換えと呼ばれています。
2300シリーズではコード領域とデータ領域は明確に分かれていてコード区分の書き換えは出来ないみたいですね。
FLASHの寿命を気にする程プレイしてくれませんからっ^^;
プレイして尚且つ記録を更新し続けることは実際不可能だと思いますよ。 推測では100回がいいところでしょう。
今回パッドはUSBにしたかったんですが、クロックがあれなもんで使えないのでAVRの似非USBホストを真似ようかと。
http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html 12MはARM基板から分配しますかねｗ
ＨＩＤ機器をＵＳＢ未対応のマイコンで扱ってみようと思って以前本を買いあさったんですが、いまだ実現できてません…
まさにそのいしかわきょうすけさんのｔｉｎｙ２３１３版ＵＳＢコントローラを目指したかったんですが…