PIC専用のスレ Part 58 エラッタの話題も歓迎
■ このスレッドは過去ログ倉庫に格納されています
＿＿＿＿＿＿
／Microchip .／|
／ ( ﾟ∀ﾟ) ／ | アセンブラのアの字もわからない
|~￣￣￣￣￣| ／. 超初心者からHEXが読めてしまう
|/Ｚ./Ｚ./Ｚ./Ｚ_|／ || 鬼ﾌﾟﾛﾌｪｯｼｮﾅﾙの為のｽｯﾄﾞﾚ（#ﾟДﾟ）だ!ﾓﾞﾙｧ
||. ||. ||. ||
大人気のPICマイコンのスレ
なんといっても情報が豊富だし、開発環境も多いし、パッケージも豊富
使いやすくて、しかも安い。やっぱりPICだよね
例の如く基本リンクだ
http://www.microchip.com/ マイクロチップ本社(Microchip Technology Inc. )
http://www.microchip.co.jp/ マイクロチップ テクノロジー ジャパン 株式会社
http://www.microchip.com/maps/microcontroller.aspx Microchip Advanced Part Selector (Maps)
またーりやっておくんなまし
種類が多くてワカランって奴は上記パーツセレクタで、機能から最適製品を絞り込め！
教えて君はとりあえずGoogle( (p)http://www.google.co.jp/ ) くらい使おう
テンプレ内の秋月小売価格も在庫が捌ければ、次の仕入れからは昨今の為替相場変動にならって
適宜価格改定されてます。ここの表記価格とは違うかもしれないのでそのつもりで
回答者する人の注意
. 最初に回答したい気持ちは分かるけど、質問者の内容を、落ち着いてよく読もう。
質問者する人の注意
. あなたの周囲しか通じない変な省略語は使わずに、なるべく詳しく説明してね
前スレ：
PIC専用のスレ Part 57
http://rio2016.5ch.net/test/read.cgi/denki/1517669525/ >>793
だから16bitで表現できるのは64KBまでだから
それ以上のメモリを扱いたければセグメントのような特別な仕組みが必要だと書いてるだろ
普通はセグメントやバンク切り替えで対応するけどな
つまり、16bitのアドレスだけでは表現できなくてセグメントやバンクの情報も必要になるから
16bitのアドレスだけでは表現できない
PIC24はデータ用のRAM領域は64KBで制限されてたはず
8086はセグメント方式だったが、
8086の全アドレスに対応したメモリモデルのC言語のポインタはセグメント＋オフセットで32bitだったしね >>794
AliでDigisparkのクローン買ってくりゃ、
送料込み150円で出来そうだが。
何か勘違いしてるかな？ >>797
「MP3再生すりゃいいんじゃね」と指摘されてΣ(°д°lll)となってたような >>796
データ幅と命令語長は関係ないから16ビットマイコンのアドレスが16ビット
などという決まりはないと思うが。 >>788
その画だと、ファントム込みで４バイトずつ、PCはワード数をカウント、って感じじゃないかね？ >>796
>だから16bitで表現できるのは64KBまでだから
PIC限定ではなくて、一般論としてだよね。マイコン/プロセッサが16ビットだからといって、アドレスのレジスタの幅が16ビットとは限らないよ。
8ビットマイコンでも、256バイトを超えたアドレスをリニアにアクセスできるでしょ。 >>800
>>787 アドレスは４バイトごとだから、ファントムバイトとか作ってみたり。
「アドレス」は2バイト毎に割り当てられてるよ >>801
レジスタを32bitにしたものを16bitと呼ぶのはどうかね
例えば68000は16bitCPUだけどアーキテクチャとしては32bitだし
それにアドレスを32bitや24bitにしたらそれだけメモリ食うのは32bitCPU変わらなくなる
この話題は>>766が発端なんだし そもそも32bitマイコンの方がフラッシュ容量もSRAM容量も多いのが揃ってるんだよな
ルネサスだって16bitのH8やM16Cの後継に32bitのRX持ってきてる
複雑なアドレス構造で64KB以上のデータにアクセスできるようにするくらいなら
単純な構造の32bit CPUでいいじゃんということ
そういう風潮になってきてる 複雑な構造の16bit CPUと単純な構造の32bit CPUでは必要トランジスタ的にもあまり変わらない
メモリが外付けの頃はデータバス幅が小さいけど大容量のメモリを扱いたいという需要があったが
メモリが内蔵されてればデータバス幅をわざわざ小さくする必要も無い
実際にH8や68000などの高機能な16bit CPUがマイコンから消えていってARMが台頭してきてるよね
ARMのCortex-M3はゲート数が33000ゲートくらいで32bitとしては非常にコアが小さい
PIC32MXで使われてるM4Kコアも35000ゲートくらい
今残ってる16bitマイコンはデータ領域(プログラム領域ではない)は64KBに制限してるものが多い >>805
すごい理屈だな
まさにポカーンだ。H8のメモリマップも見たことなくてよく言えるもんだ
6809を16bitMPUとか8088を8bitだとか言う奴はよくいたので驚かないが。 なんか話を発散させてうやむやにしようとしてないか？ 32ビットにメリットがあるとかトランジスタの数とかは別の話だよ。
>だから16bitで表現できるのは64KBまでだからそれ以上のメモリを扱いたければセグメントのような特別な仕組みが必要
これがそうでもない、という指摘に対する答えは、>>803で書いているような「それができるものを16ビットと呼ぶのは適切ではない」なんだね？
自分の定義にあわせて世の中を変えるのは、無敵すぎだろ。 >今残ってる16bitマイコンはデータ領域(プログラム領域ではない)は64KBに制限してるものが多い
SRAMエリアが小さいのはアーキテクチャというより、コストとのトレードオフでは？ そもそもPICの実行コード自体命令長が14bitとかで、
8bitでも16bitでもない単位でアクセスしてるということを忘れてないか XC8などで、ポートAの0を H にしたり L にしたりするとき、
volatile....ポートのアドレス.... と書かなくても、
RA0=1; とか書けば動きます。
RA0というのの中身がどこかに定義してあって、
そのお陰でRA0=と書けるのだと思います。
実際にXC8コンパイラだと、その元となる Volatile.... の記述は、
どこに書いてあるのでしょうか? >>807
だからレジスタを32bitにして32bitのアドレス指定するなら
32bitCPUを使用する場合のポインタ保存に使用するメモリ容量変わらないじゃん
そもそも、この話題は>>766が発端なんだし >>808
だから64KB以上のメモリアクセスにはセグメントやバンク切り替え、32bitのレジスタを扱うなど
複雑な仕組みが必要で、結局それなら単純な構造の32bitCPUコアを使ったのとコスト的に変わらなくなってる
それはARMの躍進が証明してる
だから高機能な16bit CPUは今のマイコンではなくなってきてるんだよ
ルネサスだって高機能な16bitCPUのH8とかM16Cの後継は32bitのRXじゃん 別に16bitマイコンの使い道がないと言ってるわけじゃなくて
今残ってる16bitマイコンの多くは
データ領域(プログラム領域ではない)が64KBまでを想定してるものばかりで
8bitでは性能的に足りない場合に使われてる
64KB以上のデータ領域を使うなら
素直にARMのCortex-M3などのゲート数が少ない単純な32bitマイコンを使うような感じになってきてる >>812
んー。じゃあ…。下の2つはあなたの認識に合致する？ 合致しない？
(1)「8ビットマイコンで、256バイトを超えるメモリアクセスをするにはセグメントやバンク切り替えなどの複雑な仕組みが必要」
(2)「Z80はアドレスを扱うレジスタが16ビット長。特別なバンク切り替えをしているわけではない。Z80を8ビットマイコンと呼ぶのはどうだかね。16ビットだろ」
(1)と(2)それぞれに、「合致する」か「合致しない」をまず書いて。理由や根拠はそのあとに書いてね。書いてあればちゃんと読むから。 纏めると 16bitマイコンは社会的にNRND状態 結局、BYTEとWORDという単位とレジスタの関係を知りませんでしたってやつが、
自分の馬鹿さ加減を認められたくなくて暴れてるだけってことでOK？ >>814、>>812
CPUが一つの命令で処理できる「データのビット数」と、
命令の種類を示す「命令のビット数」とは無関係である。
たとえばAVRのデータは8ビットであり、命令は16ビットである。
（ただしAVRには例外あり。
（命令によっては16ビットデータとして処理され、32ビット長の命令もある。
（昔、データ16ビット固定、アドレス16ビット固定などいうシンプルなCPUも存在した。
（可変語長というCPUも存在する。
メモリアクセス時に使用する「アドレスのビット数（アドレス空間）」とも直接的には関係が無い。
単に「16ビットCPU」というと、通常は「データ」16ビットのCPUを意味し、
命令コード1個のビット数や命令コードが何個有るか（コード空間）は、
明記されていないので分らないし、
もちろん命令が固定語長か可変語長かさえも分らない。
アドレス空間はアドレスのビット数が16ビットで有れば最大64Kアドレスになる
CPUとしての動作機能上、
アドレス・レジスタ（プログラムカウンタ）をデータ・レジスタと入れ替えたり、
演算したりして、数値を変更できるようになっている。
この場合、ビット数の違いを吸収する工夫が必要になったりする。
と書いてきたが方向性がよく分らなくなってきたのでｗ
これでおしまい、ﾁｬﾝﾁｬﾝ ＞と書いてきたが方向性がよく分らなくなってきたのでｗ
だけ読んだ。 >>818
それで OK ！
今読み返して、余計な口出しをしてしまったと猛反省中ｗ 何ビットのCPUって言うのはACCのビット数を言うと思ってたが、今は違うんか。 結論
>>766の質問に乗じてPIC24をハブろうとしたり32ビットを布教しようとした人が悪い PIC24って使いやすくてアセンブラいじっても歯ごたえがない >>766
bit数に関係なく、アドレスはbyte単位が多い。
byte単位のアクセスは余分に時間かかるが。 もはや、お口でプログラミングする時代か・・・＞歯ごたえ 8bitのPICが糞だからPIC24はもっと流行ってほしいけどね >>827
使い分けが出来てないだけ。
単純な制御しかしないなら、やはり8bitの方が楽だし。 存在して、ましてそれなりの数が出回っているものは、用途があるからだと考えるのが自然。
自分にとって価値が理解できないままであっても、他人にとって価値があるのだろうと思えることは大切なこと。 8bitが気が楽とか分からん、32bitのリッチなIOに任せた方が
余程楽。
「おれ8ビットでこんな凄いのやってる！」オナニー自慢にしか聞こえない。 >>830
だって32bitって電源電圧幅狭そうだし、I/Oの流せる電流しょぼそうだし 電源電圧の幅は何とかするにしても、ノイズ試験や環境試験すると、スピード落としてもたいていの32bitはボロボロだね
他のCPUが起動すらしない、数kWのRF環境下やモーターをゴッツンゴッツン動かしたりしても、PICと元三菱の8Bit系は平気で動く
低格越えの温度環境下でも動作マージンが大きいのは助かるし。
部屋で模型のLED付けたり消したりするだけならなんでもいいだろうけど。 あー、タフさはつよいかもね…
核戦争下で使えるキャブ車みたいな… >>832
>部屋で模型のLED付けたり消したりするだけならなんでもいいだろうけど。
この用途こそ8bitでしょ。
32bitじゃ白や青のLED点滅させるのに電源2系統とか3端子レギュ必要とか勘弁してほしいし
ちょっと電流多めにと思ったらTr要なんてもっと勘弁だし 「理解できないところがあるので詳しく教えてください」と言う代わりに「馬鹿？」と煽って喋らそうとするのってなんなんだろな。 32bitはアナログ周りがショボい
MMは遅くてクソ
8bitや16bitの方が使いやすい >>834
青や白LEDを光らせるのに5Vが必要だと思い込んでる点に834の馬鹿さを感じました。 言うても、3.3Vやとギリギリやん?
3V駆動謳うのfet高いやん? >>839
白色LEDはvf が3V位有るから、電流制限抵抗だけで安定して光らせるには5V必要。 >>842
PIC32は1GPIOあたり5mAまでなので10mA流したいなら外付けTr必須。 適材適所にしか聞こえない話なんだが。
耐環境性に対しては古い時代からの実績と継続性のある8ビット系マイコン。
価格性能比では比較的新しい32ビットマイコンのほうが有利。
使い処による要求が価格・性能・納期の比較で良いものを使えばいい。 >>843
>PIC32は1GPIOあたり5mAまでなので10mA流したいなら外付けTr必須。
そうなの？ 私が見たデータシートだと下記の様に書いてあるけど品種によってちがうのかな
>Input/Output
>? 10 mA source/sink on all I/O pins and up to 14 mA on non-standard VOH
http://ww1.microchip.com/downloads/en/DeviceDoc/PIC32MX1XX2XX-28-36-44-PIN-DS60001168K.pdf
>844
>適材適所にしか聞こえない話なんだが。
その通りだけど >>830 みたいな人がいるから LED点灯以外でも、電源電圧に関して言えば、
ノイズ環境の悪い現場でオシロでCPUの電源電圧を見ている時に、
「CPUの電源電圧がもっと高ければ良いのにな」なんて思ったりする。
(プラズマ溶射装置の点火時や、数KWのサーボモータが動いている時など) DI/O処理は8ビットでもCPUによっては十分に早いよ。
たとえば、AVRでDI入力の0/1(SWのオン・オフ状態)をDO出力(LEDを点灯・消灯)する時の
ループ時間は200〜300nS程度。
・・・うーん、これが早いか遅いかは結局は用途によるのかな。
多バイトの数値計算に関しては8ビットはもう笑っちゃうくらい圧倒的に不利。
キャリーがどうの、ボローがどうのとウンザリする。
16ビットコードのAVRなんて10進補正命令も無い。 で、>>805ぐら方の話に戻ってループと
8bitCPUであっても、16bit以上のアドレス計算が遅いのは(ry 16C84をプリンタポートで書き込んでたころ、プリンタポートのプルアップか何かのちょっとした電圧で
暗〜くゆ〜っくりだけど「Lチカ」が動作してたな。びっくりした。
>>843
> PIC32は1GPIOあたり5mAまでなので10mA流したいなら外付けTr必須。
２本束ねたら？ >２本束ねたら？
>>845が書いていることは読んだのかな。ちゃんと読まずに反射的にレスしていたら、適材適所の話もままならないね。
8ビットが好きな人も、適材適所なら16、32ビットを使うこともあるだろうし、その逆も然りだろ?
自分が普段使わないものの良いところはなかなか見えない。使っている人がアピールすることに耳を傾ければいいのに。 正直どうでもいいから読んでないけど、ダメなら「これこれこうだからダメ」、と一言書けば終わるのにね。 >>839
昔さ、白色LEDに20mA流して8bitPICでOn/Off制御しようとして愕然としたけどな
電源電圧5Vだし余裕だろうと思ったら https://i.imgur.com/2YfN8FE.jpg
20mA流したら電圧3.2Vくらいしかでないって電流制限抵抗入れる余裕なんて無い
無知なのはしょうがないけどそれで人を馬鹿にしたことは反省すべき VOLの方が強いからそっち使ってみるといい気もするけど、正直どうでもいい 大きい電流を扱いたいならソースよりシンクを考えてデータシートを確認するべきですね。 >>853
>>839もアレだがソースで電流制御とかあなたもかなりなものです 可哀想にイジられちゃって >>853
AVRにしておけばソース20mAで0.5Vダウン、シンク20mAで0.5Vアップだったのに・・・。 ついでに言うと、20mAとかいう類のLEDだったら、5mAでも10mAでも実用上差はなくて用は成す
気もするけど、正直どうでもいい 同じPIC16でも、たぶん型式によって強いもの弱いものがあるはず。型式抜きで語ってもなあ。
ソースで使うこと自体は何も問題はない。駆動力に余裕のない領域で使うことが問題なのであって。
ID:5yMqTO3kさんは、どうでも良いといいつつ、的確で親切だなあ。 >>859
16fと16f1が同じかどうかまではわからんけど・・・・
たとえば同じ16fな仲間だったら、設計もシリコン世代もおそらく同じじゃないのかねぇ。
コスト重視なデバイスで、誰も求めてないのに敢えて新設計ぶち上げるだろうか。
であれば、当然ポート回りも使いまわし。 コスト重視なるが故にいろんな品種が作られている。
同じ16fの中でもピン数・機能の有無・同一機能であっても性能面での差異はある。
要はメーカーから見て新規開発するに足りるだけの数量が見込めるなら新製品として
開発される。
我々のような極少量しか使えないユーザーの要望が聞き入れらることは少ないと思うが、
大口ユーザーなら一社のみでも簡単に新製品が出来る。 >>860
PIC16F(F1ではない)だけでも長い歴史があるんだし、「設計もシリコン世代もおそらく同じじゃないのかねぇ」という先入観もちょっとズレていると思う。
http://ww1.microchip.com/downloads/en/DeviceDoc/39598F.pdf の FIGURE 16-17
http://ww1.microchip.com/downloads/en/DeviceDoc/40001262F.pdf の FIGURE 18-29
を比べてみてはどうだろう。
こういうのは、頭から同じものだと思い込むよりは、頭から違うものだという前提でデータシートを見る方が良いと思うよ。 >誰も求めてないのに敢えて新設計ぶち上げるだろうか。
より良いものを「誰も求めてない」という感覚もおかしい。 「誰も求めていない」って言っちゃう時点でアレな人だよな。 >>861
小口ユーザーなら、数十円位のコストアップは誤差見たいな物だから、全部入り品で良いだろ。 まず32Mクロックと謳ってても8M実質なのをなんとか >>865
小口ユーザーに特化した製品というのは、なかなか作れ(作ら)ないでしょうね。 >>867
たくさんの品種の在庫持つより、全部入り品にした方が管理コスト下がるから小口ユーザー向き。 >>868
>>867は、そういうユーザーの希望は否定してないですよ。でも、小口ユーザーのためにそれを作るメリットあるかな?って話です。大量に売れる見込みがなければ安くはならないですよ。 全部入りって、何なんでしょう。
「自分が絶対に使わないものも含めてMicrochipのコントローラのすべてのペリフェラル、最大メモリ、ポート駆動能力、最大ピン数、いろいろ全部」？ >>862
いきなり「Enhanced Flash」だの「nanoWatt Technology」だの大看板掲げてあれば、何か違いそうな気もするけど……
で、どう違うの？ >>866
8bitは1/4だけど、16bitは1/2だよ。
なんだよクロック変わんねーじゃん、と思ったら地味に倍速。
命令もえらい増えて便利になってる。DIPもあるしね。
ビット数増やしたら負け、という信念もってるならともかく、一度眺めてみるといいよ。 PICになれてるせいか、5ミリ角の32ピンの表面実装品とかまた良く分らんIC出さないでDIP40ピンでも作ってくれよぉ……。
と嘆いてしまいたくなる今日この頃。格安な実体顕微鏡欲しい。 >>869
大口顧客にとっても、初期の評価や試作用には便利だし。 >>873
× PICに慣れてる
◯ DIPから離れられない >>874
で、その全部入りって具体的にどんなものなの? って話が>>870なんですが。 多ピン全部入りPICのDIP版をユニバーサル基板に載っけて原理確認しました。
さあ製品にしよう→基板は良いが、機能を抑えたPICに合わせてファームも書き直し、テストもやり直し？
そんな悠長な開発手法を上に納得させられる自信ないわ、コミュ障だし俺 >>876
それを聞いてどうするの？
あとそれをお前に回答するメリットがこっちにあんの？ >>878
私としては「全部入り」が幻想か、自己中の「ぼくがかんがえたすごいぴっく」にすぎないことを、理解できるようにする手助けをしようと思う。
でも、それは私の浅はかな思い違いで、Microchipの人でさえ)思いつかなかった価値あるすごい全部入りなのだとしたら、本当にラインナップされるかもしれない。
いずれにしても表明することはメリットあるでしょ? >>882
> そつぎょうしき、終わったしね。
そうか荒れてるのは高校生が原因か
納得！ >>885
使ってるよ。
Arduino+シールドしかやらなかったら、半田付けできない、リード線も剥けないやつばっかりになって、ハードのこと分からないやつばっかになって、PICが復活した。 +シールドしかやらないからだろ。
Arduinoのせい、PICのおかげみたいに書くなよ、無能教官
ったく文科省の孫請けはどうしようもねえバカばっかだなｗ ArduinoとPICについて、工業高校で扱うとしたら、該当する指導要領の対象が違うのではないかと思います。
http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/07/13/1407073_14.pdf
平成30年7月の指導要領の解説書を見ると、
>〔指導項目〕の(3)のアについては，機械語及びアセンブリ言語の特徴と用途を扱うこと
みたいな文言があります。PICを扱うとしたらこれの学習材料では?
これはArduinoで学習するようなことではないですね。 2016年頃までは学校現場でPICもそこそこ使われてたと思うが、それ以降は事例が見当たらない？
ましてやArduinoを学校現場で使ってるようには見えない
(観測範囲に限って) ＞ 機械語及びアセンブリ言語の特徴と用途を扱うこと
で数あるCPUの中からPICが選ばれた理由はなんだろ？
単純で分りやすいと思われたのかな？ AVRはFuse bitを誤って設定して、ただの石にしちゃう生徒続出で使えん。パラレルライター 持ってねーよ。
DIPほしいってなった時、選択肢はPICしかなかった。 単純に楽をして解説本の多いPICにしたのでは？Arduinoの解説本が増えればArduinoになるかも・・・教育現場なんてあんまり深く考えてなさそう >>891
AVRはライタの完成品が存在しない時点で終わってる 生徒や親御さんたちが学校や、学校の先生に期待することはたくさんありますが、
「マイコンに何を選ぶか」はとても小さい割合じゃないですかね。
小さい期待値の事柄に充てられる時間や情熱は相応に小さいものになります。
深く考えていない、というよりも、マイコンの選定という、わりと些細なことより、他のもっと期待されていることに
有限のリソースを注ぎ込んでいるのだと思います。
そのため、指導要領から逸脱しない範囲で、できあいのものを使いまわしすることが多いはずです。
いったん教え方や教材が確立してしまったら、なかなか変わらないでしょうね。 ■ このスレッドは過去ログ倉庫に格納されています
