AVR H8 etc. マイコン総合スレ

>>859
円周率が３っていうのは、都市伝説だと何度いったら、、、、
（ずっと昔から、小数を習う前に円をやる場合は、「円周は直径の約３倍」って
　教えられてきたはず。）

NASA公認の一番荒い円周率は「4」

ついに精度がもう1Bit落ちた。

>>861
それはひょっとして、正方形近似という奴か。
ぜんぜん近くねえしぜんぜん似てねえ。

直径5インチの円の円周は約40cmだから、円周率は8とか＞NASA公認

>>847
亀だが、サンハヤトの28ピンクリップはワイドだと思った。
ナローの28ピンなんてあったっけ？（だからといって、20+8＝28なんて止めとけよ。
　テストクリップは、横に並べると１列分、空いてしまう）だから20+6にしておけ。

円周率は、あれだ、355/113
マクロにしておけ（ｗ

>>866
201/64とか3217/1024とかにするとマイコンでの計算が楽（それぞれ3.14と3.1416)

>>863
もう二十年以上も前にNASAが協議の上決めたと言うことなので問い合わせは
そちらにしたら？
NASAの文句はNASAに言え。

>>868
２進法で有効数字１桁なら確かに近似値４だなぁ・・・

>>869
3.14をまるめて、3にすると寸法が小さくなってしまうではないか。
大きくなるよう4にしよう。

・・・と、協議したに違いない。

隙間は充填材で埋めてしまえば良いのだ・・とか

>>869
考えてみれば２進数で有効数字１桁ってことは2^nの数値しかとりえないってことか。
πは差でも比でも2よりは4に近いからOK

(n << 4 + n << 3 + n) >> 3

元の数を <<4 (16倍)したのと <<3(8倍）したのと 元の数（１倍）したのを足せば
16+8+1＝25　。これを >>3 (1/8)して、25/8＝3.125　で、殆どπ

特許だすかな。

>>873
どうせ最後に>>3で下位桁切り捨てるなら、
n+n+n+(n>>3)または(n<<1)+(n)+(n>>3)がましでない？
全く同じではないけど、少ないbit数で計算できるから舞子んさんにはいいかも
201/64ならn+n+n+(n>>3)+(n>>6)　(3.140625)

>>873
この時点で公知になったから無理

>>873
GCCあたりは、×64とか÷32っていうのは、シフト演算してくれているんですかね？

>>876
ターゲットによります。

>>875
定数乗除算ならやってくれるみたい。
乗算命令があるターゲットなら、>>1,2程度はシフト、それ以上は乗算命令ってやりそうだな。
除算命令あるのはH8でもないんだっけ？で、/32は極力シフトでしょう。
乗算命令のないターゲット対象のAVRGCCは×64や/32はシフト命令に置き換えるみたい。
×3とか1が立った桁が2つくらいしかない定数乗算をシフトと加算でやってくれれば
ありがたいんだけどそこまでは置き換えてくれないな。そのうちやってくれるように
なるかもしれないけど（最新版avrgccはまだ試してない）
変数同士ならそこまでやってくれない。コードが増えるからかな。

>>878
まちがい、>>876

ロータリーエンコーダ　２４個。
一人の人間が操作するとして、
これを処理してコマンドとしてホストマシンに送信したいんだよ。
オマエラならマイコンは何を使う？

>>880
PICでもAVRでも全然問題にならないレベルだろう。

>>880
PICでもAVRでもいいけど、安いやつを24個。
エンコーダの距離が近ければ2〜4個まとめて処理。
エンコード結果をシフトレジスタでまとめて受けるCPUを1個。
これはホストへの送信I/Fや趣味を考慮して選ぶ。

>>880
ＣＲを外付け可能ならチャタリング対策をそいつ等に任せて
割り込み8本ｘ３ＣＰＵくらいかな？
ホストとの通信がＩ２Ｃならマスタ用ＣＰＵも要らないでしょ

なんだよ。ネタレスばかりかよ。
んなもんマイコン一個でやるに決まってるじゃん。だから悩んでいるんだよ。

特に883の回答は、万一マジだったら重症だぞ。

>>884
量産ならいくらでも悩め。
小数生産つかロボット？省力化機器？ならさっさと分散処理。

2chで質問してマジレスがないからと怒るって。（ｗ
ネタだよね？万一マジだったら重傷だぞ。

理屈から言って、分散にするなら８個単位でやることになるだろう。
８個ならＰＩＣでも十分お釣がくるな。8ＭＨｚで頑張るか。

ロータリエンコーダも24個も並ぶと結構忙しいし、
漏れならFPGAで片づけるかな。

カウンタのサイズにもよるが、CPLDでなんとか。

２４個のエンコーダの解釈はCPLDでいいとしても、
24個のUp/downを受けて処理するマイコンが１個って可能なのか？
複数のロータリーエンコーダを同時に動かさないというならいいけど

使用される状況を想定して、入力信号から必要であろう能力を
逆算するくらい基本中の基本。

ていうかやっぱり74HC169を大量に積むのが男だな。

ふっ、自立歩行型ロボットか。

またネタスレか？　24個の援交だ＝４８個のスイッチに過ぎない。
人間が操作する以上同時に10個を越える変化は無い程度（重要）のデーター量である。

実際には設定作業とか実現しなくてはならないので別にテンキーと適当な表示器も
必用になるので、検討した結果、１８ピンPICでは１０個迄と決定した。
外つけは138と574と一個づつだよ。

>>880
あー、前提条件がこれか。orz

>>890
24個のup/downを受けて処理してホストに送信するところまでFPGAに
叩き込んでしまえばいい。

遅くて良いなら、48本のIOを6個の165で受けてシリアルに入力すれば3pinだ
１回の取得は200〜300ステップくらい？マイコンがそこそこ速ければ充分かも

ロータリエンコーダに抵抗付けてR-２Rのラダー組んでアナログ信号にして
ADCで受ける。

そこでCycloneとniosですよ

>898
実現できたらある意味凄い

CycloneクラスならＣＰＵコア使わなくてもこの位は入るでしょ

この程度の事をさせるのにCycloneなんて勿体ない・・・。
何のための安いマイコンなのだ？

速24個のエンコーダが同時に動いても大丈夫なように
するのは安いマイコンだとかなーり苦しいと思う。

>>891　＜　良いこと言ってる人もいる。
とりあえず使用条件を定義づけるところから始めないと話にならないよ。

人間が弄るんだろ？同時に動いたところで屁でもないだろ。

同時に複数のエンコーダから信号がｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!としても
１つ１つ処理するんでなく、１度にA相だけ信号取得して、どれか変化した場合に
Bも取得して、変化したと認められる物だけ処理すれば充分間に合うんじゃない？
少なくとも同時に動くのが２個ならこれで充分じゃないかと
24個同時に動かれるとちょっとは苦しいかもしれないが

>905
おまえはあまい
人間の各関節にエンコーダ付けてデータ取りかもしれない。

>>907
>>880
操作というのはそういうのも含むのか？
まあエンコーダを指でつまんで回すとは限らんとか弾み車付きだったらどうするとか
言われると困るが

24コ同時でも問題ないと考えてる。8MHz　PICで。

>>908
弾み車付きのエンコーダーの用途ってどんな場合ですか？
思考が固まってしまっているので、全く想像できません。
ヒントで結構ですから教えてください。
可変抵抗よりは俊敏に制御できる回転系のセンサーとして考えていました。
せいぜいつまみの慣性程度です。
定規にゴムバンドを掛けて、１０個くらい同時に動かす程度の操作を考えていました。
基本的にはジョグダイヤル式にぐるぐる回すスピードの寒暖を読み取る事です。

>>907
その辺が曖昧なんだよな。
俺も最初は関節エンコーダーかと思ったが
会場みたいな所で全員が一個づつ握ってるみたいなのもある。

>>909
いや、半ば冗談だったんですけど、
レコードスクラッチのシミュレータみたいなのとか。
ターンテーブルが24個ってのはありえないですが。

>880　出てこい
インクリ、アブソ？
回転数は？

１回転24パルスのを24個同時にぐいっと1回転/0.5秒くらいで回したと考えてみた。
A、Bそれぞれ80回くるんだから、その4倍でサンプリングしても約3msec
(8MPICで6000命令)で48bitのチャタリング込み取得と、前回との値の変化を
みて位相判定、各エンコーダに対応する変数のUp/downをやってもかなりおつりはきそうだ

http://elm-chan.org/docs/te/te04.html
こっち方式で、エンコーダ出力のABをセットにして2bit×nのデータ形式で
もってくれば割合簡単に処理できそうだ。
CODE=取得AB値 XOR ((AB値&0xAAAAAA)>>1)して、
CODE=CODE-前回CODE　すれば、そのまんま2bitで前回からの変化が出てくれる。

>>913
＞CODE=CODE-前回CODE
これだと0000-0011で1101になっちゃって隣のエンコーダに影響与えるな。
力技でエンコーダ１つ分ごとに引き算して他のエンコーダの分はマスクして無視するのがいいかな
エンコーダ１の結果 = (CODE>>6-前回CODE>>6)
エンコーダ２の結果 = (CODE>>4-前回CODE>>4)&3
エンコーダ３の結果 = (CODE>>2-前回CODE>>2)&3
エンコーダ４の結果 = (CODE-前回CODE)&3
24個ならこれを３回。

テーブル変換の方が楽じゃない？
取得AB値のままで、
前回取得AB値上位2bitをshiftで移す
今回取得AB値上位2bitをshiftで移す
この4bitをテーブル変換
これを４回繰り返し、
それをまた３つ繰り返し

(((CODE & 0xCCCC)|0x1111)-(前回CODE & 0xCCCC))&0xCCCC）|
(((CODE & 0x3333)|0x4444)-(前回CODE & 0x3333))&0x3333）

・・駄目か・・

データの取り込みは一回でも処理は一系統ずつしかできんよ。（ｗ

>>917
そーいうこと。>>913-914式にしてもその後2bitずつに切り分ける処理とか、対応するカウンタのカウントアップダウン処理するんだから、一括に計算できてもなんとなくｶｺｲｲ！だけだな。
>>915がいいんじゃない？
しかしPICだとシフト使ったbit移動って面倒そうだな。

専用IC使えよ

仕事で4MHzの18ピンPICで毎秒2000カウント 4chのエンコーダ入力は
やったことがあります。
結果を9600bpsのシリアルで上位のシステムに送るだけのものでした。

24chとなるとピン数の方が問題かも。
48ピンの入力が確保できるマイコンとなるとかなり大きいような気が
しますね。
74244あたりを並べれば20MHzで動作する18ピンPICでもできそうですが、
配線も大変だし値段も高くなりそう。

>>919
専用ICの山

なんでわざわざマイコンを使う事を検討するかその意義を解ってない奴が居るとは。

>>922
とたんにレスが付かなくなってる。
さすがだな。PSoCスレでも暴れているようだけど
空気をよん（ｒｙ

>>923
お前も出てきてなんか意見を述べたら？

>>923は>>919の自作自演
馬鹿にされたと思って逆切れ。
ｶｺﾜﾙｲ

923と925のほうがカコ悪いし、バカ丸出し。

あんたらいい加減にしたら？

927！
おお、最大級のバカが出現したぞ。
このスレの最後の土壇場で場外ホームラン級のバカが来た！

わけわかんね

早く1000取りしたいだけなんだろうよ。

今のところこのスレで最高のバカは927だな。

>>919
スレ違いになるけれど、多ch入力のあるロータリーエンコーダ専用ICって
どんなのがあります?
ずいぶん昔に専用IC(名前は失念)を製品で使っていたのですが、そいつが
ディスコンになって設計変更をする羽目になりました。

少量生産しかしないメーカーにとってみれば、出来合いの専用ICよりも
マイコンやFPGAで処理できる方が融通が効いて良いことがありますね。

FPGAはいい手ではあります。
コスト的な問題ではマイコンに譲りますが。

ディスコン問題に関しては最近のFPGAは信用出来ません。
FPGAなのでリターゲットは比較的簡単なのであまり問題には
されませんが、現実は代替わりが激しく結構苦労します。
趣味では関係ないか。

>>913
こういうのもいいかな
CODE=(前回取得AB値 XOR AAh) XOR 今回取得AB値
これで、2bitごとに11=+1、00=-1、10=No change、01=errorとなる。
端から2bitずつ取り出してswitch-case的に処理していけばいい
8bitごとに処理する場合、CODE==AAhならこの４つのエンコーダは動いていないから
処理スキップなんてこともできる。

ＦＰＧＡはどんどん低電圧化しているのが痛いな。
ロータリーエンコーダーとかアンプ入りフォトセンサーとかは
まだ５Ｖ出力が多いのに。
たとえＦＰＧＡに５Ｖトレラント入力があったとしても
電源が２系統以上になるのはウザイ。
まぁそういったセンサー類はいったんフォトカプラで
受けて、ＣＲフィルタとシュミットトリガを通してから
マイコンなりＦＰＧＡに入れるケースが多いんだけど。

いずれにしても、マイコンやＦＰＧＡは恐ろしく進歩しているのに
メカトロ系とのインターフェースはあまり進歩していない気がする。
フォトカプラ内蔵でメカトロ系センサを直結できる入力端子とか、
１Ａ程度のモーターなら直接ドライブできる出力端子を持った
マイコンやＦＰＧＡって出ないもんかね？

3.3Vなんて、三端子一発でサックリと作ってしまいましょう。

あと、なんだっけ　74HCT245 　だっけか？　5Vトレラント。

最近のFPGAは3.3Vだけで済まないことが多いですね。

>>932
以前調べたことがあるが、ここしか見つからなかった。
http://www.zenic.co.jp/j1/produts_top.htm
「専用IC」というのもこれのことのような希ガス。
（旧製品とソフト互換性はあるとのことだけど）

>>937
http://www.semicon.toshiba.co.jp/prd/logic/doc/pdf/bcj0035a.pdf
思いついた型番を垂れ流すのではなく、ちゃんと論理的に「高電位入力許容な理由」を理解しておきましょう。

東芝は資料が手に入っても、零細事業者やアマチュアには、ジャンクやにスポットで
入るパーツとしてしか現物を入手できない。
石丸の影のジメジメしたビルも腹立たしい。

単純に、5-3.3のトレラントで双方、ディレーが問題にならないならFETスイッチは
勿体ない。

ぶっちゃけ　５V　TTLでやってりゃ　殆ど考えナシで3.3V　CMOS　OKじゃん。

だけど5V CMOSのデバイスってまだまだ多いですよねえ。

石の仕様をよく確認すること。

5V系CMOSでも、HCシリーズはTTL入力を許容していな。
この点を改善したのがHCT。
3.3V系CMOSデバイスの出力最低振幅は、3[V]程度を保証しているものが
殆どなので、TTLレベルの入力を保証している石になら直結可能。
3V＞5V接続はこの程度の事を注意するだけだから余り面倒ではないけど
逆は入力回路に付加されてる寄生ダイオード問題があるから簡単にはいかない。

漏れは趣味でも殆どの回路を3.3Vで組むように移行してしまったので
気にしなくなって久しいが。

PICスレであったけど、
SDCC
http://sourceforge.net/projects/sdcc/
ってどない？

>>945
>>この点を改善したのがHCT。
改善というか、用途やラインナップを考慮した使い分けだろう。
T無しのHCが必要な用途もあることだし。

ちなみにVdd側の入力保護ダイオードを無くし、電源OFF時の入力と電源電圧以上の信号電圧を
許容したものがLCX、LVC、VHC等。ほとんど3V系で組んでると自負する人間なら、当然知ってると思うけど。

4049Bと4050Bもね。
昔、12V系→5V系の変換やバッテリバックアップ回路に重宝したなぁ。

>>947
LCX、VHCを趣味の電子工作で使う人は未だ少ないと思って外したのだが
最近は秋葉、日本橋でも普通に買えるのかな？

>>949
秋葉原なら鈴商あたりで買えなかったかな。

>949
サトーあたりでも品種は少ないけど、置いてある

あれ？リンクが消えた
ttp://www2.cyberoz.net/city/satodenk/dic.html

>>949
>>LCX、VHCを趣味の電子工作で使う人は未だ少ない
DIP無いもんね。

>>953
なぜなんだろね？　DIPがないのは。
まぁサンハヤトの変換基板つければいいんだが、高いしな

今時ＤＩＰなんて使われないからだろ。
他の部品が表面実装なのに、ＤＩＰを使わなくてはならない理由が無い
デカイし、製造で余計なコストもかかるし、裏面使えないし。

>>954
一応、フィリップスかフェアチャイルドだったかがDIPを作っていたはず。
共立で、DIPは無いの？とわざと聞いたら出てきて驚いたことがある。

>>954
両面テープとジュンフロン線でユニバーサル基板に実装

>>957
いわゆる 物体Ｘ 状態 (^^;

DIP は全体の3%程度しか生産されてなくて絶滅寸前だと聞いたが.

>>960
まぁDIPは試作用だな。
逆にDIPが無いと試作しにくいから量産検討できないから他のCPU探す。

安価なDIP変換基板があればなあ。安いとこしらない？

プリント基板にすればいいわけだが・・・面毒せってこともある

幾らくらいでお望みか？
場合によっては作ってみたいのだが。

>>963
ICソケット並み。

じゃあ、100円以上でもOKだね。（ｗ

>>962
オリメックスで起こせ。単価１００円以下にならないか？

>>961
DIPは単価高いし、占有面積でかいし、配線長くて電気的に不利だし、ハンダつけ面倒だし、穴明け代かかるし、
良い事といえば、テスターやプローブが比較的当たりやすいってことぐらいだと思うのだが。
俺は断然SSOP・TQFP派だな。小さいし、慣れればSOPよりもハンダ付けしやすいし。

手配線の試作じゃなければDIPの意味は余りないね。
でも工作には重宝するんだよ、DIPは。

DIPはソケット使えば、壊れたときに取り替えられる。
そりゃ「SOPだって取り替えられるだろ」って言われれば「そうなんですけど」としか言いようが無いが（ｗ

つまりみんな、SOPのハンダ付けに慣れれば、ある程度解決ってわけだ。

あとはユニバーサル基板をどうするか。

以下を読んだら簡単そうに思えてきた.
http://iwatam-server.dyndns.org/hardware/SMDSolder/index.html

ChaNさんのUEWでの結線と、チップ部品の実装の美しさには惚れ惚れする。

確かに綺麗だけど、流石に0.5mmピッチのICに直半田しようとは思わないな。
この辺りは無理せず変換基板を使った方がよさげ。

老眼では無理だな

>>974
三十を超えると目が疲れるのも早いよ。

ところで皆は、Z80のアセンブラって何を使ってますか？

紙と鉛筆

>>975
CP/Mエミュレータ

>>975
岩崎のIA80

>>975
前半に禿同。細かい作業はお日さまの出てるうちでないと...orz

ZASM

>>975
OPコード直入力

>>975
XM80

IA80も一時期使ってみたが、いまひとつ馴染めなかったなあ。
そんなころ岩崎があぼーんしたんだっけ。

>975
秋月のキット付録から初めて、今はPROASM-II Ver.3

PROASM は、当時抜群のアセンブル速度だったな〜
M6809のアセンブルもネイティブでない(マクロで対応)のに、
paragonなど足元にも及ばないのにびっくりしたな〜

色々サンクス＞レスくれた方々

岩技は、潰れる瞬間に居合わせた元社員が友人だから当時の話は
色々と聞いてます。
PROASMは開発元が岩技ではなかったみたい。＞確かKMC

>>984
KMCで、そういえば、京都マイコンクラブってあったな、って思い出して、
そういえば、全然関係ないけど、あのころ、芸夢狂人っていう人いたなぁ、って思ってググったら
http://www.mri.il24.net/purof.html
おぉ、なんか凄く偉くなってるぞ。（ｗ

芸夢狂人の掲載本、いま手元にあるし。

京大か・・・死ぬほど賢い人間て居るんだなーって心底感動した記憶があるわ。
頭のいい人とつきあうと自分が如何に馬鹿か解って謙虚になるよね。（ｗ

バカはスミッコでおとなしくしてろってこった

H8はメーカ製フリーのシミュレータを提供して欲しいね。
PICはこの部分の敷居が低いように思う。
HEW3なんてフリーにすべきだと思うんだけどな。
いろいろフリーウェアを組み合わせれば何とかなるけど、
使いやすいソフト環境が整っている方が便利だ罠。
バージョンアップの度にgdbのmonitor.c/remote-hms.cいじりにいいかげん疲れた。
dddも使いやすいわけじゃないし。

弊社H８シリーズは個人の趣味をターゲットに開発した商品ではございませんので
何卒ご理解のほどお願い申し上げます（ｹﾞﾗｹﾞﾗ

日立、三菱って言う尊大で有名な二社が集まっただけのことはある。

>>989
出てきても、はげしく制限付きの物になるような。
扱えるコードサイズが1K未満とか、内蔵I/Oのシミュレーション不可とか。
なにもないよりはいいか…

そういえば次スレあったっけ？

>>992
まだ無いはず・・・できれば、よろ。

>シミュレータ
i8051用のでも作ってみようかと思って外部回路の実装に悩んでやめたことがある。
以前に使ったことがある78K0S用のはイマイチだったなぁ…外部回路のパーツにも不満あったけど無茶苦茶遅くて…
2GHzオーバーのCPUで動かしても数MHzのマイコンすらリアルタイムでシミュレートできないって何事だよ。
なにか実装とかUIで良さそうな見本でもある？

MAMEのソースでも眺めて見

>>989
そのまえにH8/3694の2.54mm28ピンDIPを300円くらいで売ってくれ。

300円て・・・ｗ

次スレ

AVR H8 etc. マイコン総合スレ　Part2
http://science3.2ch.net/test/read.cgi/denki/1093023679/

>>997
だって、ATMega8が300円くらいだろ？

1000　いただきました。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。