PIC専用のスレ Part54 [無断転載禁止]©2ch.net [無断転載禁止]©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専用のスレ Part53
http://rio2016.2ch.net/test/read.cgi/denki/1463914094/ 音声用ステレオケーブルならそれぞれシールドされてる >>145
通信スピードはいくつですか?
それによっても異なりますが、1mくらいなら、普通に接続するだけで良いです。
GNDとツイストしたり、3つ編みという話も出ていますが、
GNDとの間に容量がつくと波形が鈍りますので、あまりやらないほうがいいです。
やりたいなら、+5Vと送信、+5Vと受信という組み合わせで編みます。
送信と受信を仲良くさせるのは良くありません。
完璧にするなら、>>150の言うように、
PIC(TX)----バッファIC---抵抗22Ωくらい---------(電線1m,GNDとツイスト)--------
-----+5Vとの間に1kΩくらいで終端----PIC(RX)とします。 MAX232とか古典的なのは駄目なの？
UARTというと直ぐこいつを思い浮かべるんだけど
爺だしね >>152
>GNDとの間に容量がつくと波形が鈍りますので、あまりやらないほうがいいです。
>やりたいなら、+5Vと送信、+5Vと受信という組み合わせで編みます。
こらッ! ダメだろ。そんな出鱈目言っちゃ。
GNDとの間に容量が付くのを嫌がるなら、+5Vと添わせてもダメ。
交流的にはGNDも+5V(VCC)も同じだぞ。 >>152
> 完璧にするなら、>>150の言うように、
> PIC(TX)----バッファIC---抵抗22Ωくらい---------(電線1m,GNDとツイスト)--------
> -----+5Vとの間に1kΩくらいで終端----PIC(RX)とします。
こうすることで何が完璧になるのか説明が要るんじゃないのかな。
上では、GNDと添わせるのではなくて+5Vと添わせると言ってるのに「完璧」な方法ではGNDとツイスト。
何かが変わったのだろうね。
マッチングが取れているわけでもないし。 一般論として通信線路に完璧を求めてはいけない。
1kΩくらいの終端線路に１万ボルトの静電気放電を
与えてノーエラーを保証できますか？ 別にパケット破棄、再送リクエストでいいじゃん。
物理的に壊れなきゃどーにでもなる。 長距離UART通信ならRS485ドライバICかまして差動伝送するのが一番楽
ケーブルはEtherか、モジュラーケーブルを流用してRJ-11/RJ-45コネクタ接続 通信屋的には１ｍ「も」不平衡で引き回すなんて気持ち悪くてムズムズしてしまうのよ RS485は半二重だから、方向制御が不要なRS422を。
配線はシールド付きツイストペアの2×2で。
1mどころか100mも可。 趣味の電子工作の「1m」ってのは、
CPU直結はイヤだなぁ、バッファいれようかなぁ、それも面倒だなぁ
という微妙な距離だな。 >>165
シングルモードファイバなら10kmくらいは余裕
いずれにしろオーバースペック >>166
変調かけてアンテナから送受信するときは同軸使うけど
10Base2/5みたいなベースバンドで同軸使うムダなことはもうやらないなー >>169
1mで >>161 は無駄だと思わない不思議 >>169
家だとデジタル音声(S/PDIF, adat)とアンテナ線で使ってる
コンポジットは家では絶滅した
同軸のデジタル音声だと600mエラー無しで届いたよ PICのUARTで想定されるビットレートってどれぐらいなんだろね。
せいぜい57600bpsぐらいだと思ったんだが、1ビットあたり17.4u秒だよね。
これを1m送るのに「不平衡でないと気持ち悪い」と考えるとき、懸念されることって何なんだろう。
回路を考えるときって、用途に合わせたホドホドを見つけることって大切だと思う。
高精度発振回路を長年やってきた人にPICマイコンの回路設計をやらしたら、クロック発生回路がやたら豪華になるみたいな話だ。
そこは内蔵でも十分な用途なのに、とか。 秋月でRS485ドライバ60円、モジュラジャック40円、ケーブルは電気店で350円くらい
一方、BNC２ｍは500円、基板取付コネクタ120円といったコスト差はあるよ >>172
115200bpsは結構使われる
いずれにしろ低速線であることは確か >>174
不平衡が気持ち悪いっていうから同軸の話を出しただけ
1mの低速通信でわざわざ同軸とかツイストペアとかそもそもオーバースペック >>145
RS232とかの規格で送れば、速度落とせば、10m位は余裕。 ドライバ無しでPIC同士直結
受け側に470Ω抵抗
保護回路無し
3.5mmステレオ端子
ケーブルは100円ショップ
こんなもんで十分 1m離れた回路の間で、0-5V (あるいは 0-3.3Vその他)の通信を行うのに、
コモンモードノイズがどれぐらい心配になるものなんだろう。
ソレノイドやモーターのノイズがガンガン入ってくるような環境かな。
元の質問者が曖昧な条件しか出さないから重箱の隅をつつくような話になる。 GNDの電位差とかオーバーシュートアンダーシュートを知っていればいい
ICが強くなったとはいえ定格外の入力はイカン PICの場合クランプダイオードが入ってるので、ピンに抵抗入れるだけでも結構いいんですけど、
AD変換中にレンジ外の電圧加わると、精度悪くなったり、リセットかかることがありますね。 距離送るときは、GND電位差を気にした方が良いかも。
遅いならフォトカプラでアイソレート。
別建屋だと、数十ボルトの差があったりする。 話がどんどん大きくなってない?w
質問者出て来いw 大きくなってるっていうか、
なんか違う方向に行ってる 単純な処理に対してアホみたいにコストと時間を掛けて性能を追求する…
これぞアマチュア電子工作の醍醐味かとw 信頼性向上推進派：とりあえず電線１本でつないで、エラーが気になるようであれば原因調査して信頼性を向上していく。
コストダウン推進派：とりあえず徹底的にエラーに強い設計をして、エラーが気にならないようであればコストダウンしていく。 矛盾してますね、それ。矛盾してますね
>とりあえず徹底的にエラーに強い設計をして、エラーが気にならないようであればコストダウンしていく。
徹強設（徹底的にエラーに強い設計）には通常以上のコストがかかるということを無視
しているんじゃあないでしょうか？
結局のところ見た目のコストのかかり場所を徹強設に変えただけで、全体コストは全然
変わってないですね。それをコスダウ推（コストダウン推進）と言ってしまっていいんですか？
それをコスダウ推と呼んでしまっていいんでしょうか？ >>192 ジョークと皮肉が込められていることまで理解しようや。 徹強設
はじめて見た。>>192の仕事場周辺では普通に使われてますの？ ＞徹強設（徹底的にエラーに強い設計）
＞コスダウ推（コストダウン推進）
こいつ、まだ入院してなかったのか。
身内は何してる。 >>196
ほら、あの「ちな」とか「とりま」とかのゆとり言葉に触発されて、
自分もやってみたくなったんだろｗ
使うのが世界で一人だけじゃ、ゆとりと揶揄する対象にすらかすりもしない。 「ライク フォトカプラー」のデフがファジーなのでそのクエスチョンにアンサー出来る
フレンドはいないんじゃないかな？
もしアンサーをゲットすることがマストなんだったらもうちょっとコンセプトを
アウトプットしたほうがベターかもね 通信内容と通信相手が予め決まっているなら、略語も隠語もok >>201
そうだね、所詮>>192の脳内通信だから別に何でも構わない。
めんどくさそうだがｗ 東芝半導体が売却されたらトスリンクも改名されるかな？
トスリンクは直流成分通さないからON-OFF情報伝達には向かないんだよなー >>204
>トスリンクは直流成分通さないからON-OFF情報伝達には向かないんだよなー
マジっすか?
いや、実は俺がトスリンクを最後に使ったのって20年前ぐらい前で
そのときは、DCも通っていたはず。(つまり静止したH,Lも送れた) その記憶で>>203を書いたよ。
適当に製品一覧からピックアップしたTODX2353(F)
https://toshiba.semicon-storage.com/info/docget.jsp?did=29676&;prodName=TODX2353(F)
電気・光学的特性の伝送速度はDC〜500kb/sってなってる。
型番によるのかな? >>199 それで思いついたが
周波数にもよるが、送出信号を100均のイヤフォンケーフルで送ったとしても
受信側でフォトカプラーで受ければ GND 間ノイズの影響を受けなくなって、
徹強設wに近くなると思うぞ。次にフォトカプラーやめてコストダウンなｗ。 スピードがそんなに早くないならフォトカプラーでもいいな vi最強。
文字コンソール使えればほとんどすべての環境で使える（たぶん）
覚えようvi！使おうvi！！
：wq 今時vimでもないvi常用しろとか拷問かよ
環境整える前に一度だけ使うならまだしも >>207
舞台は調光器のスイッチングノイズがすさまじく飛びまくるからな。
バランス型マイクとフォトカプラ MIDI の威力を痛感する場所だ。 PICのUART送信、バグってないか？
同じデータが希に2個続く
PIC16F1459
PIC32MXで割り込みのタイミングによって書き込みが2度行われるって言うのがあるけど、まさしくそんな感じ
UART送信に関係ない割り込みを有効にすると、送信データが希にダブる エラッタには記述が無いんで、私のバグだとは思います サンプルが、TXIFではなくて、TRMTで待ってるのが気になってる まずチップのバグを疑うとかErrataを見るとか素人
自分のコードをまず見直すのが識者 >>213 のコードです
PIC16F1454用です
割り込みは関係無かったです
#pragma config FOSC = INTOSC, WDTE = SWDTEN, CPUDIV = NOCLKDIV
#include <xc.h>
unsigned char data[256];
unsigned char read_p = 0;
unsigned char write_p = 0;
void main(void){
OSCCON = 0xFC;
ACTCON = 0x90;
SPBRG = 0x67;
SPBRGH = 0x00;
BAUDCON = 0x08;
TXSTA = 0x24;
RCSTA = 0x90;
while (1){
while (RCIF){
data[write_p++] = RCREG;
}
while (read_p != write_p && TXIF){
TXREG = data[read_p++];
}
}
} UARTから受信したデータをそのまま送信します
コアクロックは48MHz, UARTは115200bps
100文字くらい一気にPICに送ると、PICから送信するデータがたまにダブります
read_p, write_p は正しいので、TXREGに設定している回数は合ってます
仮にTXREGにデータがあるときにTXREGに値をセットしてしまっても、
文字が減るだけで増えることは無いと思うのですが
TXIFの代わりにTRMTで比較すればダブることは無くなりますが、
文字と文字の間に隙間ができるし、割り込み処理にすると困るので、やりたくありません
サンプルはTRMTになっていますが
TXREG = ... の前後にNOPを入れても症状は直りません >>222
overrun errorがでてるのでは？ オシロスコープでRXを見ましたが、やはり文字がダブっています
（つまり、受け側の問題ではありません）
頻度にはムラがあるようで、しばらく発生しない時もあります
MicrochipのサンプルもTRMTになっていることから、
TXIFには問題があるのでは？という気がします ただ、TXREGの空判定が誤った場合は文字が減るはずで、
多くなる理屈がわかりません データシートに書かれてるこれに引っかかってるとか
The TXIF flag bit
is not cleared immediately upon writing TXREG. TXIF
becomes valid in the second instruction cycle following
the write execution. Polling TXIF immediately following
the TXREG write will return invalid results. >>222
// ACTCON = 0x90;
にしても同じ？ unsigned char data2[256] を新たに定義し、'0'..'9'とかで適当に初期化。
TXREG = data2[read_p++];として、送信側か受信側か問題を切り分けたらどう。 >>229
>>222 のコードでは、TXREGへの代入からTXIFの読み込みまでの間にいくつも命令が入っています
また、試しにTXREG代入の前後に何個かNOPを入れても変わりません
>>230
今晩試してみます
>>231
問題は送信側です >>231
カウンタの値が合っているので問題は送信側と思いますが、念のため受信側のデータの検証もしてみることにします >>233
俺が言っている受信側とはwhile(RCIF)の受信処理なのだが >>222
全然ダメじゃん
切れ目無く連続で受信データが入ってきたら対応できないぞ どこが悪いかわからないが、MCCを使えば大丈夫だと思う。 >>227
>MicrochipのサンプルもTRMTになっていることから、
>TXIFには問題があるのでは？という気がします
サンプル通りにしないで「問題があるのでは？」と考えちゃう頭に問題があるのでは？ Microchipのサンプルはバグがあるのに放置されてるものが
あるので要注意・・・・・
自分はI2Cで結構やられています？？？？
（今現在もはまっています〜〜〜〜） >>165
＞RS485は半二重
カメだけどその知識は間違い
RS422は１対１
RS485は１対多
全二重のRS485トランシーバもある >>238
I2Cバグありますか…mccでしか使った事ないけどやっぱりバグ付きなのかな
まだ浅学ゆえバグにぶち当たってない >>230
同じでした
>>231 >>235
受信データは全て合っています
4800bpsでも921600bpsでも1バイトも取りこぼさずデータ化けもしません
>>234
write_p, read_p とも数が合ってるので、RXREGからの読み出しの回数も、TXREGへの書き込み回数も合っています
実際にPICから送信されるデータがたまにダブって多くなります
>>237
>>223参照 PIC16F1454のエラッタには記述がありませんが、他のマイコンのEUSARTには色々とエラッタがあるので、PIC16F1454の場合もエラッタな気がします
シフトレジスタとTXREGの両方に書かれるタイミングがあるのでは？と思います
バッファを介さず、受けた文字数分固定文字を送っても同様にダブります
受信しないで、例えばタイマーなどのタイミングで再現させることは出来ていません >>237
割り込みタイミングがTXIFですので、割り込みでTRMTで判断した場合、シフトレジスタが空になるまで割り込みがかかりっぱなしになるので、割り込みでの送信が出来なくなります
そうなると、割り込みを使わずにTRMTをポーリングすることになりますが、送信が終わってからTXREGにデータをセットするまで送信されない期間が出来てしまいます
つまり、ビットレート本来の速度が出ません
サンプルの送信も隙間だらけです while (RCIF){
data[write_p++] = RCREG;
RCIF=0;←←←←←←←←←これっていらんの？
} 受信に合わせて送信した場合、ちょうど送信データがなくなるタイミングでTXREGを書き込むことになるので、おそらくこのタイミングがマズいんでしょう
わざとTXREGにセットするタイミングをズラせば発生しなくなるのか
またタイマーなどてぴったりこのタイミングに書き込むと受信しなくても発生するのか
などを試してみようと思います >>244
RCIFは読み込み専用です
RCIFはRCREGにデータがあれば1, 無ければ0です
RCREGから読み出して、FIFOが空になれば自動で0になります
TXIFも同じように状態を表します 送信は特に状態の方が便利ですね
送信バッファが空になったタイミングでラッチするような仕様だと、最初の1バイトは割り込みが使えないので、排他制御が面倒 >>241
PI C の送信クロックが少しでも相手のクロックより遅かったらバッファがあふれるぞ
相手の送信パラメータをストップビット2とかにしたらどうだ これだとどうなる？
while (1){
if(RCIF){
data[write_p++] = RCREG;
}
if(TRMT){
if(read_p != write_p){
TXREG = data[read_p++];
}
}
} 通信相手はPCなのかな
送信タイミングを変えて実験するなら>>248のような問題があるから
PICのTXをPICのRXにつないで（PC？をつながず。つなぐならPIC→PCのみ）
あらかじめPIC内に用意した文字列を送信してPIC自身で受信してみるのがいいかと
RXREGは空読みして（捨てて）文字数だけカウントでもおｋだろう >>248
ずっと受信し続けたらそうでしょう
今回は一度の送信が1000文字くらいなのと、
バッファが256バイトあるので、
あふれることはありませんでした
通信相手は以下をPCに繋いだものです
http://akizukidenshi.com/catalog/g/gM-08461/
PIC16F1454も、上で使われているFT234Xも、
たまたま115200bpsに一番近い設定が115384.615bpsでまったく同じでした
OSCの誤差は両方合わせて最大0.4%くらいなので、
バッファが256バイトあれば60000文字くらいは大丈夫そうです ■ このスレッドは過去ログ倉庫に格納されています
