PIC専用のスレ Part 57
■ このスレッドは過去ログ倉庫に格納されています
＿＿＿＿＿＿
／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専用のスレ Part 56
https://rio2016.5ch.net/test/read.cgi/denki/1501476623/ http://akizukidenshi.com/catalog/g/gP-07366/
これに半田付けすれば良い
電源系の配線をしてパスコンを付けて
80本ピンを立てておけば
あとはソルダレスボードでも
直接線でPICKITでも使える
ソケットもあるけど高いので考えない方が 0.5mmピッチの80pin QFPの半田付け
がんばれ >>764
ポートを入力設定にして無いとか、PowerDown設定してしまってるとか、
アナログ入力になってるとか、 0.5mmピッチは適切な道具が揃ってればあとは練習 BGAを裏返して植毛する事を思えば、全然余裕っすﾖ >>767
ソケットとか変換基板買うよりもチャイナ基板屋で基板作ったほうが安いし早い。
初心者向きのフリーのCAD使えばわりと簡単。
パスコン程度は安く実装してくれるし、基板屋によってはPICなら実装もしてくれるかも知れないよ。 >>768
これはいいですね。でも半田付け殆どやったことないんですよね〜
>>770
ラインチェッカーをPICで作ってみようと思いまして80pinで一番安いこれがいいかなと
>>772
適切な道具を教えていただけるとありがたいです。
>>773
そうなんですか！？
>>774
自分でも調べて個人で頼むのは高いなと思っていたんですけど、安いところがありそうですね。
半田付け高校以来やっていないんで実装してくれるとありがたいのですが
初めは変換基板で試してからやってみます
ありがとうございました 今までXC8のFREE版を使っていたんですが、今回サブスク版を買ってみました。
んでPROレベルの最適化でコンパイルしてみたらそれまで55KBあったHEXファイルが
40KBまで縮んで「さすがPROのオプティマイズ化はすごいな」と思ったんですが、
いざこのHEXをPICに書き込んだら全く動きません
ためしに最適化レベルをFREEに設定してコンパイルしたHEXファイルを書き込んだら
やっぱり普通に動きました
PROレベルの最適化で逆に動かなくなるケースってのはどういうものがありますでしょうか？ >>775
ハンダコテは何でもいい。液体フラックスと吸い取り線は必須。
ハンダはこだわりがなければ有鉛を使う。
あとはようつべで引きハンダのやり方を見てひたすら練習。
仕上がりを確認するのにルーペが必要かな。 >>776
ソースの一部分を削ってコンパイル＆実行を繰り返し問題部分を特定するしか無い >>776
アセンブルリストファイルを吐き出してコンペアかけてみな。 >>776
最適化によって正しいコードが動かなくなることはある
(昔のVisual Studioではよくあった)
最適化における仮定が正しくない場合にも起こるし
単にコンパイラのバグということもある
シンプルなコードから順番にコードを足していって場所を特定してコードの記述を変えたり
ソースファイルや関数ごとに最適化を切り替えられるならそれを細かく変えることで
場所を特定して最適化設定を最適化する
また、コード側の問題としては以下が考えられる
不定値
タイミング依存
使用リソースの変化 (RAM, スタック)
処理順が変わる (volatileつけ忘れ) あとハンダは0.3φの奴を。ルーペはスタンドか頭にかけるのを。 ヤニなしで0.3mm径の半田より、
0.6mm径のものを使った方がヤニがたくさん得られて
上手に半田付けできるよね。 >ヤニなしで0.3mm径の半田より
0.3mmでヤニなしって売ってる？ >>775
マイコン自体が安くても大して変わらんぞ
値段で決めない方が良い スルーホールだろうと0.5mmピッチだろうと0.6mmでやってる ハンダの径なんていろいろ選べるのだから、使い易いと思うものを使い分ければいいよね。
0.6が使い易いと思うならそれを使えばいいし。 糸ハンダの太さなんてアマチュアだから単に繰り出し易さで選んでるな。
あまり太いのも細いのもハンドリングし辛い。 細い半田だと、脂の量が少ないので、半田付けが難しいです。
0.6mmとかだと、脂が多いので使いやすいです。
あとで脂を洗浄するつもりなら、フラックスをハケ塗りすれば、0.3でも行ける 俺が0.3mmのハンダの芯のフラックスの量が少ないと感じるとき
・半田付け時の温度がうっかり高くなりすぎている。
・大きめのD、Cコテ先のまま使って、コテ先端へのハンダの広がりが大きすぎ。
ピンポイントでハンダを流し込むのに0.3mmを使っているのに、
芯のフラックスを、対象を活性化するのに使わずに、熱で飛ばしたり、
コテ先の余分なところを活性化するのに使っていては良いことないですね。 フラックスはハンダのヤニいりももちろんだが、別に筆で塗る奴用意して
基板に塗布＋IC置いた後にピンごと塗布だろ。
太さは俺も0.3mm. そうなんだけど、ついつい面倒で半田盛ってしまう
で、ブリッジして慌てる
ここ一番の時にはフラックス出動するけど ブリッジしないで済むようなら極力させない。
しちゃったらなるべく一回で済むよう吸い取る。 いつかテレビで、
人工衛星搭載電子装置の基板の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が金払って調査会社に依頼してるんやから
当然現行大口ユーザー相手にアンケート取って１位にするやろ
日本でアンケートしたらルネ一強になるだろうし だな
"consider" なんてどうとでも操作できる incf/decfでキャリーが出てほしい場面が2バイトをdecするくらいしか思いつかない
別に出ても不思議ではないけどわざわざ変える理由が分からない
他の変更点ではアドレスがバイト単位になったのが不便だけど何かそうせざるをえない理由があったのかな
addwfとかでPCLを読むとPCLATH/Uが現在地になるやつは便利 ループの終了判定はdecfszだな
pic14はPIC12/PIC16と14bit命令が混ざったんじゃないか？ >>824
PIC16は命令長が14bitだから、[バイト単位]にアクセス出来ても余り意味無い。 >>826
命令長14bitのをPIC14と呼んでる。 >>829 命令長14bitのをPIC14と呼んでる。
マイクロチップのネーミングが適当だからこんなことになる。 ２バイトでアップカウントする場合、下のバイトを incfsz で skip したらｉ上のバイトを 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がそれであるとは俺は言っていない。
逃げ道を用意して主張するなんて、この卑怯者めが手討ちにしてくれるわっ！ｗ
ま、意味の無い屁理屈をどう積み重ねようと、
PICの名前には規則性が無い、は厳然たる事実だし、
これでは「名は体を表す」が成立しないではないかっ！ｗ いつか誰かがどこかで、エラッタがあっても売れるから直さない、と書いてたな。
マイクロチップは大したもんだよ、見上げたもんだよ、屋根屋のふんどしっ！ｗ 直したところで少量しか買わない君の手元に入って来るかどうかはわからない。 この世界ってバグ前提で動かしたりするんでしょ？
セカンドソース使ったら修正されてて動かないとかｗ >これでは「名は体を表す」が成立しないではないかっ！ｗ
その仮説は証明されないから。
俺が子供だったころに、近所に「巌本徹男」(ちょっと変えてるよ) みたいな
名前の人がいた。小柄で痩せて病弱な兄ちゃんだった。 >>861
バグ前提の洗濯機とか
バグ前提の炊飯器とか
バグ前提のブレーキ制御とか
使いたくない >この世界ってバグ前提で動かしたりするんでしょ？
「この世界ってバグ前提で動かしたりすることもあるんでしょ」なら間違いではないだろね。
昔のVTRで、録画タイマーが10分ずている、とわかっていれば、ものぐさな人ならそれを前提に合わせるだろうし、
家族が気を利かせて時刻を合わせていたことに気づいていなければ、悲しい結果になるだろうし。 人命に関わる機器には使わないでね(または営業に確認してね)と
ハンコで押したようにどのデータシート/カタログに書いてある。 部品がバグ持ちなのと製品がバグ持ちなのは全然違う話
再現性があるバグならそれを避けて使えばいいだけ
さらに、動作が異なるものは普通はセカンドソースとは認識しないし
そんなものを代替品として使うアホなメーカーはない
ちょっと考えればわかりそうなものだが 俺みたいなPGの脳内にバグがあるような奴だと、
「この数式は完全に正しいはずだから問題点は他のどこかにあるに違いない！！」
とか最初に考えて、バグは永遠に治らなかったりするぞ。 ■ このスレッドは過去ログ倉庫に格納されています
