PIC専用のスレ Part 57
■ このスレッドは過去ログ倉庫に格納されています
______
/Microchip ./|
/ ( ゚∀゚) / | アセンブラのアの字もわからない
|~ ̄ ̄ ̄ ̄ ̄| /. 超初心者からHEXが読めてしまう
|/Z./Z./Z./Z_|/ || 鬼プロフェッショナルの為のスッドレ(#゚Д゚)だ!モ゙ルァ
||. ||. ||. ||
大人気の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専用のスレ Part 56
https://rio2016.5ch.net/test/read.cgi/denki/1501476623/ いつかテレビで、
人工衛星搭載電子装置の基板のQFPの名人によるハンダ付け
を放送していた。
ハンダゴテを滑らせつつ連続的に糸ハンダを供給し、あっという間に終った。
出来上がり状態は全ピンがブリッジ無しの最適ハンダ量だった。
なるほど、これは名人だなと感心したけど、
私も君も数さえこなせば名人になれる、かもしれない。 0.5mmピッチなら昔だけどCx486とかIBM486BL2のTQFPを良く貼り替えたな。 PIC16で問題になるのはEUSARTくらいだからマシなほうだな ANBE PICKIT3-KIT05、 これ使ってる人がいたら確認したい
コイツに付属のZIFアダプター、PIC16F145x(USB内蔵) に対応出来てなくない?
種々試してみたんだけどダメだった
それ以外は調子良くて、コスパ自体は高いと思ってる
自分の使い方が悪いのか、そもそも対応してるのか?
説明書も回路図も無いから 判断できん ここは既に見てて知ってたけど
この回路図が合ってるなら、ダメそうだって事だな >>804
此れだけ知っていりゃ、安部ので十分だな。
一つ買っておくか。 この間からPICが必要になってラズパイで書いていたけど
安いから専用で持ってても良いよな! ZIF要るのか
凄く安いの買ったら
TEXTOOLじゃなくてTFXTDOLだった >>803
俺のメモには、PICKIT2で書き込む時にデバイスを手動設定してLVPで書き込むって書いてあるな 付属のZIF使わずに
BBに挿してジャンパー5本で直接PICKIT3に繋げば、問題なく書けるのは確認してる
該当端子を辺りを弄ればOkと言う事になるが、ZIFを外すのが大変
デバイスのDataSheet見ながらLVPならイケルかも? と考えてたんだが、 >>811 が正解か LVPなら、付属のZIFでも書ける事を確認 Verify もOK
LVP、今まで使った事が無かったから設定手順がアレだったが
知ってしまえばどうって事無い、 >>811 で正解だった
ただ、LPVだと実使用の面で何かと制約有りそう
確認も取れた事だし、
たとえ面倒でも一旦ZIF外して、基板に細工した上で付け直した方が良さそうだな。 >>810
読み書きソフトはSourceからコンパイルして作るんだけど、そんなに面倒じゃない。
オレンジパイでも書ける。 あ、
でもPICKITは遅いよね
ST-LINKとかLPC-LINKとかE1とかXDS100とか使った後だとイライラする pic18のdecf,incfでキャリーフラグ変わるってどういう事よ
pic14で実績あるコードだから何故バグるのか相当悩んだ
今さらアセンブラーでも無いんだろうけどね microchipが金払って調査会社に依頼してるんやから
当然現行大口ユーザー相手にアンケート取って1位にするやろ
日本でアンケートしたらルネ一強になるだろうし だな
"consider" なんてどうとでも操作できる incf/decfでキャリーが出てほしい場面が2バイトをdecするくらいしか思いつかない
別に出ても不思議ではないけどわざわざ変える理由が分からない
他の変更点ではアドレスがバイト単位になったのが不便だけど何かそうせざるをえない理由があったのかな
addwfとかでPCLを読むとPCLATH/Uが現在地になるやつは便利 ループの終了判定はdecfszだな
pic14はPIC12/PIC16と14bit命令が混ざったんじゃないか? >>824
PIC16は命令長が14bitだから、[バイト単位]にアクセス出来ても余り意味無い。 >>826
命令長14bitのをPIC14と呼んでる。 >>829 命令長14bitのをPIC14と呼んでる。
マイクロチップのネーミングが適当だからこんなことになる。 2バイトでアップカウントする場合、下のバイトを incfsz で skip したらi上のバイトを incf(sz) すれば良いが
ダウンカウントする場合は decfsz だけでは役不足なのが仕様としていびつと感じてはいたな。 >>828
14bitで必要無かったのは分かるがPIC18で変える必要はあったのかなと
下1bit無駄になってaddwf PCLが面倒になってまで必要だろうか
TBLRD/WTがあるけど2バイト単位でできなくもなさそうだしそこだけ1バイト単位でもいい
>>830
確かに。でも普通のN回ループはゼロだしキャリー使う場面が思いつかない
あればあったで何かしら見つかりそうな気もするけど ん?、 "addwf PCL" は従来どおりじゃないのか?
DataSheet 見てもこの部分が変わったようには見えないが >>835
命令長16bitのPICは16bitPICですか >>839
そう呼ぶこともあるけど大抵はPIC18とか24とかdsとかで事足りるから12bit、14bitほどは使わない
あくまでも私の周辺だけど >>838
アドレスが1バイト単位だから1命令先に行くには2を足さないといけないしテーブルは一度に128命令分しか飛べない
>>840
使うんだ。16bitPICって言ったら16bitCPUのPIC24/dsPICだけを指すのが普通だと思うから相当紛らわしいな PIC24C16D××、PIC16C08D××、PIC14C08D××みたいにすれば分りやすかった。
(C:コード長、D:データ長、××は種別)
でもそもそものPICスタート時からボタンの掛け違いが・・・
もう何を言っても遅い。 メーカーだけの責任じゃない
半分はユーサーの責任
>>835や>>840みたいなヤツの 何がまずいってPIC12とPIC16は命令セットでなくピン数で分かれてたのに
PIC18(とPIC17)は命令セットから違うことだな
(挙句今更になってPIC12をPIC16に統合しやがる)
PIC17と18の時16のままで頑張ればまだましだったんだよ実際18のときは初期案16だったし
17より下がるのを避けたんだろうけど、英字もう1個挟んで特別感出せばよかったんじゃないかな
PIC18F14K50みたいな感じで 型番なんかタダの記号に過ぎん。
付ける方だってそんなに考えて付けてない。
受け手が勝手に理由を捏造してるだけ。 >>849 あんたやmicrochipはそうなのかもしれないけど一般的には製品名は熟慮して決める
顧客が混乱するのは、メーカーにとって良いことではないからね。 「一般的には製品名は熟慮して決める」まるでPICの命名が熟慮されていないかのような言い方に見える。
どんなことも「熟慮」したかどうかなんて、真面目に考えれば当事者にもわからないものである。
熟慮なんて言葉は内省に使えば深くなるが、他人に対して、熟慮したかと言えば、逃げ道のない脅迫に近いものになる。
顧客が混乱してはいけない、というのは商業における価値観の一つにすぎないし、
顧客にインパクト、困惑を与えるという価値観もある。PICがそれであるとは俺は言っていない。
命名規則が変わってくるのも仕方がない。どんなに厳格に決めたところで、
企業間買収があれば、一つのメーカーに複数の命名規則の製品が混在することになる。
まとめれば従来ユーザーが混乱する、まとめなければ買収を知らない世代が統一性がないという。
命名に関しては、賢いユーザーは>>849のようなタイプだと思う。
自分の想定と違うときにパニックに陥るのはある種の発達障害だそうだ。
閾値を超えていなくても、想定と違うときにひっかかりを大きく感じてしまう人がいるらしいということは
このスレでもわかる。それを自覚することで自分と向き合えると良いのではないか。 >>852
発達障害は主文を簡潔にまとめられず
キチガイ的な長文を垂れ流すって自覚するといいよ >>853
長文といっても100行にさえ満たないものだから読めないわけでもなかろ。
おまけに>>852は複数の短い話を1レスにまとめているだけで、そのこと自体に>>853が戸惑うのであれば、
複数のレスに分ければよかったかな?
なお、この板で発言するときは、意識的に簡潔さよりも漏れの少なさを優先している。
・中身のない批判だけよりマシ。
・解釈を相手に委ねるような、よりどうとでも取れる文章は簡潔とは言わない。
・よりどうとでも取れる文章を書いた挙句に、読み手の解釈が自分の意図と異なるときに、読み手に責任を押し付けるバカよりマシ。 その通りだね。
自分の意見と異なる意見に対して、病的かと思えるほどに攻撃的な反応を示す奴が少なくとも複数はいる。
多分、お互いに尊重しあうことは出来ないんだろうな。 >>852
この長文の内容はある種の偏執狂を疑わせるな。
>PICがそれであるとは俺は言っていない。
逃げ道を用意して主張するなんて、この卑怯者めが手討ちにしてくれるわっ!w
ま、意味の無い屁理屈をどう積み重ねようと、
PICの名前には規則性が無い、は厳然たる事実だし、
これでは「名は体を表す」が成立しないではないかっ!w いつか誰かがどこかで、エラッタがあっても売れるから直さない、と書いてたな。
マイクロチップは大したもんだよ、見上げたもんだよ、屋根屋のふんどしっ!w 直したところで少量しか買わない君の手元に入って来るかどうかはわからない。 この世界ってバグ前提で動かしたりするんでしょ?
セカンドソース使ったら修正されてて動かないとかw >これでは「名は体を表す」が成立しないではないかっ!w
その仮説は証明されないから。
俺が子供だったころに、近所に「巌本徹男」(ちょっと変えてるよ) みたいな
名前の人がいた。小柄で痩せて病弱な兄ちゃんだった。 >>861
バグ前提の洗濯機とか
バグ前提の炊飯器とか
バグ前提のブレーキ制御とか
使いたくない >この世界ってバグ前提で動かしたりするんでしょ?
「この世界ってバグ前提で動かしたりすることもあるんでしょ」なら間違いではないだろね。
昔のVTRで、録画タイマーが10分ずている、とわかっていれば、ものぐさな人ならそれを前提に合わせるだろうし、
家族が気を利かせて時刻を合わせていたことに気づいていなければ、悲しい結果になるだろうし。 人命に関わる機器には使わないでね(または営業に確認してね)と
ハンコで押したようにどのデータシート/カタログに書いてある。 部品がバグ持ちなのと製品がバグ持ちなのは全然違う話
再現性があるバグならそれを避けて使えばいいだけ
さらに、動作が異なるものは普通はセカンドソースとは認識しないし
そんなものを代替品として使うアホなメーカーはない
ちょっと考えればわかりそうなものだが 俺みたいなPGの脳内にバグがあるような奴だと、
「この数式は完全に正しいはずだから問題点は他のどこかにあるに違いない!!」
とか最初に考えて、バグは永遠に治らなかったりするぞ。 >>866
>さらに、動作が異なるものは普通はセカンドソースとは認識しないし
>そんなものを代替品として使うアホなメーカーはない
バグではないけれど、「74HC4066」の違い
http://www.ti.com/lit/ds/symlink/sn74hc4066.pdf
http://www.ti.com/lit/ds/symlink/cd74hc4066.pdf
前者は 2〜6V、後者は2〜10V。 何故PICにはエラッタが多く、かつ放置するのか?
日本のある電機メーカーが自社のマンパワーが不足して、韓国のメーカーにテレビの設計を発注したそうな。
その日本側の技術者が言っていたのだが
「日本では設計完了までに詰めなければいけないところがいくつかあると判断する状態で
韓国側はOKにする。信じられん」
つまり、マイクロチップは韓国風の発想をする会社、
ということであろうと私は推測したりするのであったチャンチャン
しかもエラッタのせいでPICスレが栄える、
うーん、これは嬉しい悲鳴ではないか、マイクロチップに感謝しないとな(大笑) >>869
その結果が、現在の日韓メーカー格差だとするなら
microchipが正しいと言うのがあなたの結論か? わずかな例をもって全体の傾向と感じてしまうこと自体、感情論に支配されているように思う。
まあ、でも、組織の中で責任の押し付け合いをしたり判断を避けたり結果的に遅らせたり、
見聞きしたのに報告しなかったり(ちくらなかったり、ともいう)、
全く身に覚えがない、とは言えないな。いたた。 上位互換の新品種で修正して、不具合品は廃盤にすりゃいいと思うんだが。 >>872
趣味で使うのならそれでいいよね
100%エラッタがないと保証して、あったらすべて保証してくれる製品だけ使うといいよ 一方は完璧を期するまで煮詰めている間、
競合は多少バグあっても商機を優先してリリースし市場を制する
リスクの考え方っていうやつやな 趣味だからエラッタあってもいいよ。
俺が困らなきゃいい。 クルマだってフルモデルチェンジ後は
リコールにつながるような
不具合が潜んでると分かってても新車に飛び付く層は一定数いるからなぁ >>872
廃品種にならないのも売りの一つだから、わざわざそれを捨てる必要はないのでは
新規設計非推奨にしとけば新しい製品には使わんだろ
自分は趣味だから古いのでも新しいのでも好きなのを使うけど >>868
そういう書き方するとアスペには判らないよ PIC32MZ2048EFH064が秋月で販売開始
200MHz品なのが残念 >>870 >microchipが正しいと言うのがあなたの結論か?
マイクロチップは商売としてPICを売っている。
エラッタが多かろうが放置しようがPICは売れている。
従ってマイクロチップの商売のやり方は正しい。
勝てば官軍、ですね。 (ゴメン、1行追加)
正しいかどうかと個人的な好みはまた別ですが。 なんで秋月はPIC32のSMD品は上位品種に偏ってるんだろうか とりあえず使ってみるには全部入りが都合が良いからな
リファレンスボードも大抵そうじゃない?
もちろん量産だと極限までケチるけど
どうせなら252MHz品にしてほしかった ラジオ自作スレと同じで、此処にも偏執狂が蔓延って居るのか PIC32でI2Cを動作させているのですが
電源ON時、SCLからクロックが出ません
(SDAはデータ出力されてます。)
因みに、リセット(MCLR)をかけると
ちゃんとSCLからクロックが出ます。
電源ON時とリセットでI2Cの挙動が
異なるのですが、何が原因でしょうか? 発振前に設定してるとか
電源の安定前に設定してるとか
接続先がクロックをローに引っ張ってるとか
型番とクロックの原発は?
ドライバのコードはMCC?Harmony?独自?
MXやMZだったらエラッタの可能性も 内蔵PLLの安定前にペリフェラルの初期化しているとか
初期化ルーチンの前にウエイト入れて試してごらん >>886
レス有難うございます。
品番はPIC32MX340Fです。
PIC32MX220Fではこのような現象は
ありませんでした。
(接続先の仕様及び回路は同じ、違いは
340Fと220Fの差しかありません)
開発環境は、XC32コンパイラv1.40
IDE v2.20です >>887
ウエイトは100msecにしたり
500msecにしたりしましたが
現象は変わりせんでした。
IOの設定(TRISx及び、TMR設定)
→100msecウエイト
確認のため、LEDを点灯。(点灯してます)
→I2C初期化
(OpenI2C関数で設定)
→100msecウエイト
→I2C送信
で、電源ONの時はSCLは出力しません
(SDAはでます)
リセットのときはちゃんと出力されます 「SCLが出ない」の詳細は?
デバイスがローに引っ張って無いことは確認出来た? >>889
まいこんのほかに、何かICが関係してる?
リセットだと動くのは、電源が上がりきっているから。
電源オンの時は、マイコンも含めて電源が準備中に初期化がはじま >>890
パターンカットして、相手側と切り離しました
が、挙動は変わらず。
>>891
I2Cの初期化前に、マイコンが動作
しているか、ポートを使ってLED
を制御して確認するプログラムに
なっておりますが、LEDはONして
おります。 >>893
回路図をupできない?
そうすれば、すぐに解決すると思う。 ■ このスレッドは過去ログ倉庫に格納されています