初めてのPIC 0x24 ※顔文字は禁則事項です！
.
_ _ PICをさわるのは今日が初めて、という超初心者のためのスレです。
(O>――<O) PIC選び、PICを使った回路は、誰でも最初は不安なものです。
/ (･) (･) ヽ 恥ずかしがらずに何でも聞いてください。速攻で教えてくれますよ。
○ ／▼＼ ○ 質問のしかたは、初心者質問スレの発言1を見てくださいね。
｜(ヽ二フ ) |
/ ￣￣￣ ヽ
f ヽ ／ | PIC関係のスレは、レベルに合わせて以下のスレもありますので、活用しましょう。
ヽ ＼ ／ ノ ・PIC専用のスレ
| ＼_ )(＿／ ! 本家本元のPICスレです。口の悪い人もいますが、楽しくやってるみたい。
| | ここの話がわかるようになれば、あなたはもう一人前のPICerです。
| | ・マイコンソフト 悩み事相談室
| |￣￣| | マイコンソフトやツールの質問は、こちらでどうぞ。的確な回答があります。
(＿ノ ヽ＿)
質問するときは…
・PICの型番と開発環境を明記しましょう。
・プログラムは、レス内に直接書き込まず下記を利用しましょう。
http://codepad.org/ https://pastebin.com/
・解決したら結果報告しましょう。
・ここはPICマイコンのスレです。AVRの自慢話は「AVRスレ」でお願いします。
回答者の先輩は…
・威張らず、偉そうにせず、上から目線にならず、優しく答えてあげましょう。
・顔文字はやめてください。回答内容と顔文字の使用は別問題です。
ハード、ソフト情報
・統合開発環境 MPLAB X ttp://www.microchip.com/mplab/mplab-x-ide
・コンパイラ(XC8 XC16 XC32) ttp://www.microchip.com/mplab/compilers(高機能版のみ有料)
・コード生成プラグイン(MCC) ttp://www.microchip.com/mplab/mplab-code-configurator
・マイクロチップ・ライブラリ(MLA) ttp://www.microchip.com/mplab/microchip-libraries-for-applications
・PIC一覧、スペック検索
ttp://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1005
ttp://www.microchip.com/maps/microcontroller.aspx
・初心者はPIC16F1以降の型番で始めると無理なく始められます。
MCCを使えば、最初からPIC32で始めるのもありです。
・プログラムの書込みには書込器が必要です。
予算に応じてPICkit4、SNAPなどを購入しましょう。
ttp://akizukidenshi.com/catalog/g/gM-13854/
eBayやAliExpressで買えるPICkit3の中華クローンも十分な性能が報告されています。
直近スレのご案内
0x15 https://rio2016.5ch.net/test/read.cgi/denki/1567831628/ 2019/09/07〜
0x16-0x19 欠番です
0x20 https://rio2016.5ch.net/test/read.cgi/denki/1596523661/ 2020/08/04〜
0x21 https://rio2016.5ch.net/test/read.cgi/denki/1617716381/ 2021/04/06〜
0x22 https://rio2016.5ch.net/test/read.cgi/denki/1636738259/ 2021/11/13〜
0x23 https://rio2016.5ch.net/test/read.cgi/denki/1652634500/ 2022/05/16〜
では、質問どうぞ スピードに拘らなけれはGPIOでI2Cを制御する。
I2Cの勉強になるよ。 >>722
>MCCに頼らないでI2C用のコード書いた方が楽
そうだよね。
・スレーブアドレスを<<=1する
・REAなら ||= 1する
・書き込む
・ACK待つ
・データ1バイト目を書き込む
・STOPコンディション どうせ使わないクロックストレッチを無視すれば簡単になる >>725
クロックストレッチって、MCCソースに出てくるリトライ回数のことでしょうか？ >>726
検索すりゃいくらでも解説あるが
要するにスレーブ側でSCLをLに引っ張ってマスター側にビジーを伝える仕組み
ほとんどのデバイスは使ってないけどBQ27532とかは使ってたりする >>721
そのデーターシートとは、マイコンのデーターシート？
それともMCCのデーターシート？
MCCの吐くコードの説明って、ヘッダーファイルの物だけでは？ 質問あります。
相手のPICから、UARTで文字データが出力され続けています。
S|||||||PS||||||||PS||||||||PS||||||||PS||||||| と、START bit 後すぐにSTOP bitが来ます。
~~~~S|||||||||P~~~~~~S|||||||||P~~~~~~S||||||||P のような文字間の切れ目がないです。
これを「後から電源onのPIC」で受信したいのですが、PICの受信モジュールで判別できるのでしょうか?
1度文字化けしたら、最後まで合わない様に思うのですが。
まだ試していません。 >>729
スタートビットのHからLになるエッジでサンプリングが始まり中間タイミングで拾うだけだから問題なし。 8ビット1ストップビットパリティなしで0x2Cを連続して送ったら
0001101001000110100100011010010001101001000110100100…
になるけれど、うっかり途中から受信を始めたら0x62の連続になる、みたいな心配?
0010001101001000110100100011010010001101001000110100…
それはありうる話。 調歩同期通信のレシーバはスタートビットで同期を取るのだから
スタートビットが定まらない送信パターンは調歩同期と呼べないのでは？ >>729
連続送信の場合、文字列によっては、１度文字化けしたら最後？まで合わない
理由として、正常なスタートビット位置を見失うため
送信側と受信側で対処する必要がある
送信側は一定のブロックを送信したら、１文字分以上の時間を空けて次を送信
※これでスタートビットの位置が正常に検出できる
また、送信する文字列（データ）にも工夫して、受信側で受信が正常にできてるか検出できるようにする >>734
名前の国語辞典的な解釈は横に置いておいて、隙間なしのつめつめの調歩同期送信をするのは、
相手となんらかの手順のやりとりをして(リクエストがあったらレスポンスを返すとか)、
一連のカタマリのデータは詰め詰めでも、カタマリとカタマリのあいだはアイドル期間を設けるとかして、
「うっかり途中から」とか「ずれてしまったら」とかが発生しにくいようにしたり、発生してもリカバリしやすいように工夫するよね。 みなさん、ありがとうございます。
>正常なスタートビット位置を見失うため
ですよね。H→Lの変化は何度となく現れるのですから
1文字分Hが続けば同期が取れるので、その後は脱調するまでOKなことは
容易に想像されます。しかしそれが無い場合は、途中から参加したらわからないと思うです。
余裕という人もあればダメという人もいて、どちらが正解なのかな、と
思いますが、正しく受信できない可能性があることはわかりました。
みなさんありがとうございました。 すみません、
PICのUARTだからダメで、ST32のUARTならOKとか
そういうことは無いですよね? >>739
たぶんそう。調歩同期通信そのものの動作だし。 >>739
そりゃ、UARTの原理的な現象なのだから
ST32（おそらくSTM32）でも同じ
＞START bit 後すぐにSTOP bitが来ます。
これ説明としては逆じゃない？ stopの直後にstartって事だと思うが
＞S|||||||PS||||||||PS||||||||P , ~~~~S|||||||||P~~~~~~S|||||||||P
この手の説明には一応、意味を書いた方が良いよ
S(start bit) , P(stop bit) , |(data bit) , ~(idol) >>735
>使用するマイコンチップのデータシート
そうなんかなあ。
もとの人が知りたいのは、TRB のことなんだと思うけど、それってデータシートに書かれているようなことなんだろうか。
調べてみたら生成コードの中で使われている構造体みたい。
ぼくの環境のMCCでは出てこないキーワードだけど(古いのかな?) >>741なにもしてないときのアイドルは IDLE だ。推しのIDOLじゃないよ。 >>743
ほんとだ、「完璧で究極のIDOL」の方使ってる (*ﾉωﾉ)
734さん、推しときます やー。ぼくは、ずっとずっと間違ってきた漢字の間違いを、近所の小学生に指摘されたことがあったんだよな。
お客さんとの打ち合わせでホワイトボードに間違って数十年…。(多分パソコンだと変換に委ねているから間違ってない) >>745
気づいてない間違い怖いよなぁ、最近だと必要に応じて文章を作成した後に
chatGPTで「以下の文章をチェックして、間違いが有れば指摘してください」＋「文章本体」
とかでで確認したりする
さっき自分の書き込みもchatGPTで確認したらidolがidleに修正された
＞最後の説明における「S(start bit) , P(stop bit) , |(data bit) , ~(idol)」の部分で、「idol」というのは「idle」のタイポではないでしょうか。アイドル状態を指している場合、「idle」と書くのが正しいです。
AIに「タイポ」言われてちょっとワロタｗ >>738
途中から受信だけでなくノイズなどの理由でストップビットやスタートビットを読み損なった場合
そこから後ろは同期エラーで全滅だな 世の中には、TXさえも75kのプルアップとダイオードで引っ張る構造になっている糞UART ICもあるからなCH340とか 調歩同期はしばらく放っておけばどこかで正常になるよ。
データパターンによってフレーミングエラーが続くようならUARTの受信を
一度止めてから再開するとかすればどこかで正常になる。 >>748
CH340Kのことだろか。目的があってそういう構造になっているってことはないのかな?
糞なんちゃらって話はときどきあるけれど、目的にあってないものを選んでいるケースがある。
メーカーは、それなりの人が協議してすげえ初期投資をしてICを作ってる。
ぼく自身も含め、そのへんの存在でしかない いちユーザーの印象の方が正しい確率はひくいと思ってる。 秋月にあったCH340データシートを読んでみたら
・省電力のために弱いプルアップにしてある
・ハイスピードで通信したい場合は適宜プルアップしろ
みたいなことが書いてあった そもそもドライブする側に直列ダイオードがなければ、外部でプルアップする必要もない。
CH340Kはデータシートをチラ見した限りは、CH340と接続されるマイコンが別電源のときの動作を考慮したものっぽい。
CH340Kに電源が入ってなくて、マイコンだけに電源が入っているとか、その逆とか。
でも、これが成立するためには、CH340KのTXDの直列ダイオードのどちら側にも、
VCCに接続された保護ダイオード、寄生ダイオードが入っていてはいけないことになりそう。
秋月に売ってるんですね。試しに買ってみるか。 PICがなんだSTMがなんだ やれコード生成だ、やれアセンブラだCだと
言ったところでチップのデータシートも見ずに組み込みシステムができるかよ。 MCCが生成したコードの話なのに、MCCで設定するレジスタの話か何かと勘違いした人が、マイコンのデータシートを見ろって言ってたような気がする。 ♂「初めてだから優しくしてね」
♂「僕も初めてだから大丈夫だよ 」 >>758,759
♂ x ♂ (≧∇≦)
経験上、初めて同士より、どちらかに経験者がいた方がスムーズに事が進むと思うの 少し前のUARTの受信の件は、結局うまく受信できないというのが答? >>763
>>729の話?
延々と同じバイトが詰め詰めで送られてきて、何かのアクシデントでずれてしまったような場合は戻らない場合があるよ。
いろいろな値が送られてくるケースなら、いずれ矛盾が生じて、そのうち正常になる可能性がある。 戻らないじゃなくて戻すんだろ
ズレていることすら区別つかないんならそれはもう論外 詳細が書かれていない質問だし、ズレていることを区別できない場合があることは排除できないしね。 中古本で「PICマイコンでつくるインドア・プレーン」が売られているのを発見しました
この本を読めば、PICマイコンでドローンが作れるようになるっという本でしょうか？ CQ出版社 PICマイコンでつくるインドア・プレーン
で検索すると、CQ出版社のこの本のページが見つかって、そこに目次やページサンプルが載ってるよ。 >>766
文字間の隙間がないのに、どうやって戻すんですか？ >>771
化けた値とストップビットまでのオフセットの関係を予め求めておいて
その時間だけ待てばいい
パソコンなら難しいがそういう泥臭いタイミング制御できるのがマイコンの利点だろ
取りこぼしが多くてもいいなら
脱調検知したら1ビットずらすことでどこかで戻る >>771
>文字間の隙間がないのに、どうやって戻すんですか？
それを>>766のぼくに聞くないで。特定条件だと戻らない、って言ってるんだし。
たとえば、0x20の羅列がずーっと来ているときに、
・それが正しく0x20の羅列なのか
・実はずれて化けて0x02の羅列に見えているのか
を判定できるのは通信仕様の作りようでしかないと思う。
たとえば送信側と受信側で「0x20以外は8バイトを超えて連続しない」という取り決めを作っておいたら
0x02の羅列が続いたら「おかしい」と判断できるから、いったん受信を停止して再開することで修正ができるかもしれない。 受信したビット構成が不正だとオーバーランエラーや
フレーミングエラー、パリティエラーが発生するから
これらを利用しましょう 元質問は、まったく通常の8-n-1の場合な気がするし、事前の取り決めなど無い前提に思える。
>化けた値とストップビットまでのオフセットの関係
と言うけど、化けたことはマイコンにはわからないことでしょ?
期待するデータではないと判断できるのは人間だけ。 だからそれは論外だって言っただろ
良い悪いじゃなくて俎上に載らないの >>778
それはつまり「必ず戻せるわけではない。戻せない条件がある」ということですね。 判別できないんだから戻せないも何もないって話だが？
1ビットずらしていけば必ず戻せるとも言える
でもそんなの意味ないでしょ >>729の質問は「PICの受信モジュールで判別できるのでしょうか? 1度文字化けしたら、最後まで合わない様に思うのですが」だし、
それに対しては「判別できないケースがある。そのケースでは、最後まで合わせようもないことがある」が結論だと思う。
>1ビットずらしていけば必ず戻せるとも言える
合っているかどうかわからないケースで戻せるのかな? 最後まで合わせようもないことがあるが最後まで合わないことは避けられる
何も変なことは言っていないが？
それとも1/2の確率で無益なレスを続けるのと
有益なレスと無益なレスを交互にするのが同じだとでも？ 「最後まで合わせようもないことがあるが最後まで合わないことは避けられる」
「で、合っているかどうかわかるのですか」
「神様ならわかります」
そうか、これが変ではない仕事場があるのか。 UARTで確実な通信をするなら、チェックサムやエラー訂正符号をつけるのが確実だよな コマンド＆レスポンスみたいな形にするだけでもかなり違うしね。
送受信の手順を自分で決められるなら、一方的な隙間なしの連続送信は避けられるなら避ける方がいい。 UARTでどの程度の対応をするかは、
結局、その通信データがどの程度重要かどうかで決る。
ハード、ソフト共に何重にもエラー対策しても
リトライして最後までエラーになる場合も考慮しないといけないし。
結構めんどうな問題だと思う。 通信エラーの発生が問題になるような状況下ではUARTの連続送信という通信手段自体が不適当じゃね
SPIやI2Cなどのクロック同期式の通信手段の方が適している 調歩同期は長いケーブルを介した機器間通信で使われるものだしね。 ありゃ。へんなこと書いてた。
調歩同期は長いケーブルを介した機器間通信でも使われるものだしね。
でした。 間違ってと不都合な通信ならパリティ付けるなり
ブロックチェック符号付けるよね〜 昔標準的に使われてた8251なんてスタートビットの立ち下がりエッジを
みていなくてレベルだけだったのでエラーになるとなかなか回復しなかった。
PICのUARTが立ち下がりエッジを見ていれば結構回復は早いと思う。
もちろんパターンにも依存するが。
8251が立ち下がりエッジを見ていないのはブレークキャラクタを受信するためなのかな。 皆様方にはUARTについて色々と御不満お有りでしょうがｗ
信号線1本だけでで複数装置と通信出来る有り難みがあったりします。
（RS485はコンプリメンタリの2本で、信号の種類としては1種）
これからも使われ続けるでしょうね。 >>797
いつの時代の話よ
だいぶ古いやつのことでしょ 私の言ってるPICの送信エラッタってのは
TXREGに2回書くと、TXIFが0になるんだが、
バッファが残っているのにTXIFが1になって、
バッファを上書きし、送信データがおかしくなる現象のことを指してるんだがあってる？
18F26K22とか、古いPICではあった。
TRMTを見て送信が完了してから次のを書けば問題ない。
他にPICのUART関係では、PIC32MXのエラッタが有名だな。
レジスタに書くタイミングと、割り込みのタイミングが一致した場合、
割り込みから帰ってきてもう一度レジスタを叩いてしまうらしい。 ダブルバッファだからバッファが空けばTXIFが1になるのは正常動作なんだけど
TXREGが空の状態で送信が終わってTSRが空く瞬間に書き込むとTSRとTXREG両方に
書き込まれて2回送信してしまうというやつだよね。
普通文字列などを送信するときはTXIFが1になってすぐに書き込むから
そのタイミングにはならず意外と引っかからないね。
中途半端に時間が空いたときは最初の文字を書くときだけTRMTをみればよさそう。 え、そんなのあるの？
私のは
while(..){
while(TXIF == 0);
TXREG = x;
x++;
}
みたいなコードで、バッファがあるのにTXIF==0をすり抜けて
1,2,4,5
みたいな結果を送信してくるんだけど。 なるほど。
>>801が今でもあるUARTの送信バグってことでいいのかな。
できれば現象が起こる型番を教えていただけませんか？ エラッタあり PIC16(L)F1574/5/8/9
PIC専用のスレ Part54で報告あり PIC16F1459, PIC16F1454, PIC16F18313
エラッタが存在しないものも同じバグを持っていて、同時期に設計された
ものは共通の可能性が高い。
バグがあってももエラッタ出てないし、修正してもエラッタを改版してるとは
限らないので現状は分からないね。
PIC16(L)F1717/1718/1719 ではRevision A1で修正されてるみたい
4.1 Duplicate Transmission の項目
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/80000653D.pdf >>804
どうもありがとうございます。
最終的には自分で動かして確かめてみるしかないですね。
確かめるのけっこう大変そうだけど USB HIDのプログラマブルゲームパッドを作りたいので
マイコン
PIC32MX210F016D ttps://akizukidenshi.com/catalog/g/gI-05851/
開発環境
vscode＋Rust
デバッグ
シリアルデバッグモニタ
プログラマ
自作4-phase ICSPライタ
ドキュメント
PIC32MX1XX/2XX Family Data Sheet (DS60001168L)
Section 27. “USB On-The-Go (OTG)” (DS60001126F)
PIC32 Flash Programming Specification (DS60001145AA)
PIC32 フラッシュ プログラミング仕様 (DS60001145R_JP)
こんな感じの開発を考えているんだけどマイコン周りで他に読んどけ的な資料とかありますか？
USB周りのデバイスモード関係の解説が少ない気がする。DS60001126FもOTGとあるように
ホストモードが中心に見えるし どう見ても初めてのPICじゃないと思うんだが
どこまで経験があって何が初めてか書かないと >>808
サンキュ。サンプルコード集？があるのか。見てみます
>>809
積極的にPIC系を選ぶこともないし持っているのは秋月のセールで買ったPIC32MX210F016Dだけ
PIC系の開発自体初めて。他社マイコンの開発経験はあります MLAは時期によって入っている物が違うから、旧バージョンもチェックして 開発経験者ならMLAのhid_joystickを雛型として使えば割と簡単だと思う でもRustなんでしょ
まずはCのサンプルが動くことを確認してからの方が無難かと おお、開発環境を見落としてたわ
でもライブラリを使ってるわけでもなし、肝はPICをどう設定するかってことだから
Cからのポーティングもできる人間ならチョチョイなのでは PIC32MX210F016Dは色々と問題があるから苦労するぞ C32でコンパイルしたら最適化が効かなくて016に入らなかったとか MLAのhid_joystickを見ています。USBの割り込みハンドラは一つでその中で割込み要因を判別するタイプか
サスペンドとレジュームは空っぽに見えるけど実装されていないのかな
というかUSBの仕様によればサスペンド時は〜500uAらしいけどこれメインクロック止めないと無理だろ・・・
もっとも無視しても実用上問題ない機能ではあるけど
PIC32MX210F016DへISPで書き込むのに使えそうなアダプタって
・PICkit
・SNAP
・中華のPICkitもどき
・JTAG対応のDAPLink
・JTAGアダプタ(WCH-LinkEは持っている)
・自作ライタ
くらいですかね？
PICkitは流石に単発で使うには高価、SNAPも今や4000円程度とそこそこする
中華のPICkitもどきも3〜4千円程度？と互換品のわりにそこまで安くないし Raspberry PiとかArduinoを持ってれば付加部品少々で書き込めたような デバイスによる違いが大きいことを除けば
PICの省電力モードはそこまで癖が無いと思うけど
アプリケーションにも依るが自分は省電力モードを前提に書いてる Raspberry Pi Picoベースのプログラマがあれば・・・と思ったけど
ttps://github.com/MCJack123/pico-icsp-programmer
こんなのしか見つからなかった
>>818
Arduinoはあまり使わないですし5V系(UNO R4と中華Mega2560もどき)しかありません
Raspberry Piは1B+、4B、ZeroがありますがPCベースの開発では使いにくいそうに思います
>>822
サスペンド時電流〜500uAはコンプライアンステストの項目にあるにもかかわらず
アプリケーションノートなどの具体的な実装情報は多くないように見えます
データシートやマニュアルにサスペンドやレジュームについて、何らかの記載が
あればいい方で、下手すると全く触れられていないとか、バスパワーでの使用は
非推奨というマイコンもあるようです
また根拠不明で2.5mAまでOKみたいな解説も見かけますし(MLA内のサンプルも該当) 
