PIC専用のスレ Part 56 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
＿＿＿＿＿＿
／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( http://www.google.co.jp/ ) くらい使おう
テンプレ内の秋月小売価格も在庫が捌ければ、次の仕入れからは昨今の為替相場変動にならって
適宜価格改定されてます。ここの表記価格とは違うかもしれないのでそのつもりで
回答者する人の注意
. 最初に回答したい気持ちは分かるけど、質問者の内容を、落ち着いてよく読もう。
質問者する人の注意
. あなたの周囲しか通じない変な省略語は使わずに、なるべく詳しく説明してね
前スレ：
PIC専用のスレ Part55
https://rio2016.2ch.net/test/read.cgi/denki/1491255154 タイポはなー、割と便利な語なんだよなー
誤植じゃないし(植字してない)、誤字じゃないし(字の形を間違えてるわけではない)
敢えて言えば誤打鍵だけど一般的に使われてる語じゃないし
書き間違い・打ち間違いならいいけど和語だとしっくり来ない場面多いし
その点タイポはタイポグラフィカルなエラー一般に対して使えて便利
まあ自分なら違和感を感じながらも「誤字」を使うかなあ
なお自分はアーキテクチャはPIC18よりEnhancedミッドレンジの方がすっきりしてて好き。 >>327
同意。
知ったかぶっているのが、一番たちが悪いね。 >>319
電子工作レベルなら、特に気にならない。 メリケンのロートル技術者は8051好きだねぇ
日本のジジイ技術者でZ80使いは絶滅したけど
PIC16信者はまだまだ主流派だ PIC16全体を一絡げに古いとか言い切るとか、無知ですか 古いコアを周辺機能でゴマかして、イヤ、カバーして・・・というと
小池都知事を思い出す・・・年寄りの厚化粧。
イヤ、最終的にCPUとして機能し有効なら、
豊洲市場へ引っ越すのが正しいのなら、それで構わないんだけどね。 こういう知ったかに限って、i386がベースになってる最新intelプロセッサに
ついては何も言わないんだねｗ Enhancedで多少使いやすくはなったにせよレジスタ1つってのがなー
その点ARM8はすげーよなー
32bitアーキテクチャ切り捨て(も可)だもんなー >>364
えッ、最新intelプロセッサがi386のコア使ってるって？ 386コードが動くというのとベースになってるってことは全然違うってことをわからないやつに言われてもな >>370
動きます！単なる反転アンプとして、FFを構成するところから始めていただければ大丈夫です AVRに周辺機能をぶっこんで、PICは捨てるべきなのですよ。 microchip に買われてからAVR8 / 32は新しいチップ無いけどな 両方続ける理由は無い
どちらかと言うとAVRが消える >>375
AVR自体がエラッタだと言うことに気づけよｗ PICユーザーはエラッタ不感症なのか、エラッタ耐性なのか、何かすごいと思うｗ
（褒めているんですよぉ） 30年後は世界政府が個人のマイクロプロセッサの所有を禁止してるわ >>379
データの単位の多くが、未だに8bitだからな。 >データの単位の多くが、未だに8bitだからな。
俺の貯金ですら、16ビットでは不足するぞ。
なにかと判断が1ビットの人もいるけれど。 コンビニ支払が256円だとキリが良い！と思えるファミコン世代ですので >>386
通信や伝送規格の殆どが、データの最小単位は8bit。 >>388
最小単位とプロセッサの処理単位は別だろう。
32ビットマイコンでもバイト単位の処理ができるんだし。
どんな通信を使おうが、扱う数値やデータ量と世間の趨勢で普及するマイコンのビット数は決まってくるよ。 じゃーなぜ画像扱う時代になったのに24bitマイコンは主流に成らなかったの？ >>390
いくつかの疑問
・24ビットでいいの？ もっと多ビットでの処理もあるんじゃないの？
・24ビットに画素の属性(透過度など)は含まれているの？
・32ビットで管理できないの？
・汎用プロセッサで扱うとして、他の処理の重要性がどうでもいいぐらいに24ビット画像処理って重要なの？ PICで開発してるんですが、PICはデバッグ実行のような事はできないんでしょうか？
MAPLAB-XとPICkitTM3を使ってます
VisualStudioみたいにブレークポイントを張ってそこで止めたときの変数の値とか
確認したいのですが可能でしょうか？ >>392
もちろん可能だよ
MPLABX Debug で検索して >>391
確かに。
画像処理が重要ならGPUがってのがトレンドだしね。 でもドラレコにPC界隈でよく聞くGPU載ってるのってすくなくね？
個人的には別にフルスペックのドラレコ作りたいわけじゃないけど、モノにしたい技術だなぁ。
もちろんPICでは無理だけど。 pic32のharmmonyのタイマー割り込みなのですが、
割り込み時にカウンタを0にする必要がないのでしょうか？
なんか不規則な感じがするので知りたいのですが。
あとtimerの値(現在値)を参照するにはどうすればよいのでしょうか？ PICでLEDを光らしたいのですが、ピンの余裕がまったく無くてMCLRくらいしか
空きピンがありません
MCLRでLEDを光らせようと思ったらMCLRをOFFにしてIOピンとして使う宣言をした上で
5V <---R---LED---○MCLR
こんな感じの接続にすればいいと思うのですが、問題はこの接続のまま高電圧(9-12V?)を
かけてPICKITで書き込みを行っても大丈夫でしょうか？LVPの無いPICです >>400
MCLRと共通になっているポートが出力にもなる品種があるのか。
てっきり入力専用だと思ってた。
使えるとして、だけど、その接続だとLEDに過大な逆電圧がかかってしまいます。
シリコンダイオードを直列に繋ぐ。
さらにLEDには並列に逆方向のシリコンダイオードか、10kΩぐらいの抵抗をつなぐ
が必要になるでしょね。 >>400
LEDの逆耐圧はけっこう低いものが多いのでVPPが定格を超える可能性があります
保護方法としてはダイオードを逆向きに並列接続して逃がしてやるのが一般的です
しかしこの場合はRがVPPの負荷になってしまいます
Rが十分大きい場合は問題ありませんがLEDを光らせるために低抵抗になっていると過負荷になり書き込みがうまくいかない可能性があります
直列にダイオードを入れてIrを小さく抑えるという対策でいいと思います
5V---R--|>|--LED---MCLR >> MCLRが出力にもなる品種・・・
確かに、そんなの有ったっけって感じ
具体的な品番 なんだろ？ 他のピンでもLEDを光らしてて、CPUパワーに余裕があるならMCLRは使わずcharlieplexingかな。 MCLRはUARTの受信に使ってるわ……9600だからこれで十分。 MCLRにまで手つけるような状態なら品種変えるわ俺なら MCLRで出力できるPICが出たら大騒ぎになりそうなものだからたぶん勘違いなんじゃないかなあ
UART受信は俺もよくやる。10F200とか8ピンとかだとスイッチ入力も真っ先にMCLRに割り付ける
っていうかUARTはむしろUSARTモジュール使う方が面倒 １Mbps位で使うことが多いからソフトUARTは滅多に使わないな。 >>409
何をもって1ビットづつというのか分からないけど、
関数を呼ぶとスタートビットを待って8回読んで1バイト返す感じ
>>410
あー1Mbpsだとソフトではつらいな
PCとの接続に使ってるから115200までしか使ったことない
あと思い出したが16F628Aとかだと内蔵4MHzでUSARTモジュール使うと
115200が半端で出せないからソフトでやるしかないんだよな >>411
最近はシリアルポートのあるPCが殆ど無いのが幸いして
USBシリアルを使うことが多く、普通に921600bpsとか3Mbpsが使える。
16F1823でさえ余裕で921600bpsが使える。
割り込みを10μ秒周期にすればキッチリ詰めて送受信可能だし
今更9600bpsなんて使う気が起きないな。 久しぶりに来たら残存バカばっかりになってて興味深い。
さようなら。 >>411
Tnx.
そういうのが知りたかった。
スタートビットを検出してから関数を呼ぶってことは、受信中は他の事は出来ないの？
MCCの生成する、ハードウェアUSARTを使ったコードに対する優位性はあるの？ チンピラ崩れみたいな奴が金魚の糞みたいなレスするのが、何時もの楽しみｗｎ 前に市販のFT232RLのUSB-UART変換器を使った時に、
高いボーレート設定値にかかわらず、あまりに実効速度が遅くてガッカリした事がある。
用途次第だと思うけど、やはり1バイト受信完了割込みが使えないソフトUARTは
複雑な処理のプログラムは組めないのでは？
私としては出来ればDMAで処理したいぐらいだ。
（以上、糞レスだよぉ、楽しめてもらえたぁ？）ｗ >>412
なるほどUSBシリアルは速いんだ
俺のPCは昔RCDライタ使ってたからシリアルポート付けたんだ
64bitOSで使えなくなったけど
>>415
うん、出来ない
優位性としては、
アセンブラで1サイクル単位でコード詰めるのが楽しい
非同期的なプログラム書くめんどくささがない
シリアルポートに抵抗だけで直結できる(EUSARTだと片側だけ極性変えられたっけ?)
4MHzの10F200や16F628Aでも115200bpsが出せる
‍‌​あたりかな
>>418
複雑な処理のプログラム書いたことないからな… すまん、変な不可視文字紛れ込んでた
> ‍‌​ >>419
関数を呼ぶとスタートビットを待って8回読んで1バイト返す感じ
関数呼んで、スタートが来なかったら、一生待ってるの？ スタートビットのエッジを検出したら、0.5ビット分待ってから10回、スタートビットからストップビットまでの各ビットの中央付近を1ビットづつ読んで終わりじゃないかな。 >>423
>>421の関心はむしろ「一生待ってるの？」のほうだと思う。
回避方法はいろいろあるだろうけど。 スタートビットのエッジで関数を呼んで、0.5ビット後の読み込み結果がHだったら、リターンするのでは？
待つのは0.5ビットだけでしょ。 >>425
>>421がそれで納得すればいい。のか。 受信待ち中他に何も出来ないし他の割り込みも止めなきゃならない ソフトUARTはエラー（パリテイ、フレーミング、オーバーラン）のチェックが大変そう。
また、1回のサンプリングでビットのH/Lを判定すると判定エラー率が高くなり、ノイズに弱くなる。
（例えばAVRでは3回サンプリングして多数決で決めている）
通信エラーを気にするなら素直にハードUARTを使った方がいい。
まして送信・受信完了割込みが使えないなんて・・・。 ＞（例えばAVRでは3回サンプリングして多数決で決めている）
これってPICのUARTはどうなんでしょう
同じですか？
「 PIC16の資料を見たけど特に説明は無いみたい。
申しわけないけど詳細は分りません。 商用でソフトUARTなんて実装例はあるのかね？
欠点が多過ぎて 超スローレートなら割り込みでサンプリングすれば良いけど デバッグ用に送信オンリーでログ吐き出すときはよくやるよ >>421
時間でタイムアウトするコードも1回書いてみたけど
タイムアウト時の処理考えるのめんどくてほとんど使ってない
ポーリング間隔が空いてタイミングがシビアになっちゃうし
やるならウォッチドッグタイマの方が楽かなあ
>>430
エラーチェックするほど立派なもの作ってないので…
特に受信側は1文字のコマンドを受け付ける程度にしか使わないし
>>431
同じく3回の多数決でノイズ除去してる
ttp://ww1.microchip.com/downloads/jp/DeviceDoc/31018a.pdf >>433
欠点をリカバー出来ないのは℃素人だから、まともに設計出来てないんだろ。
2B+Dの16KBPSを普通に処理してた＠2000年位の数十万台オーダーの量産品 >>439
ぜひご教示願います
●マイコンのビット数、コアクロック周波数
●スタートビットの検出方法
ループによるポーリング / ポート割り込み / タイマーによるポーリング / 他
●受信データのサンプリングタイミング
単純ループによるウェイト/ フリーランタイマーを使ったループによるウェイト / タイマー割り込み / ポート割り込み / 他
●送信データのポート設定タイミング
単純ループによるウェイト/ フリーランタイマーを使ったループによるウェイト / タイマー割り込み / 他 ポート割り込みによるソフトウェアUARTを書こうとしたけどグリッチがひどくてろくに書けなかった思い出
技術力がほしいなあ >>440
CPU:某社z80ライクなCPU
クロック：８MHｚ
送受共タイマー割り込み
今時の8ビットPICの方が速い。 >>439,>>442
Iインターフェース加入者回線かな
そんな量産品じゃないけどメンテナンス用のポートとしてバックグラウンドルーチン内で使ったことはあるな 高速な調歩同期信号を自力デコードする場合
タイマで波形サンプリングして多数決取るよりも
インプットキャプチャ割込でエッジ間隔測ってウインドウ設ける方が経験的にエラー率下がる >>446
PICの使い方としては、100%でもいいだろ。
プログラム可能な周辺ICなんだから。 本物のプロと℃玄人（＝実は単に長くやってるだけの毛が生えた素人）とはちゃんと見分けてください >>437
うわっw
ここは初心者スレじゃないはずだけどw ■ このスレッドは過去ログ倉庫に格納されています
