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/ >>458
今時のプロセスルールだと5V仕様にできないから
180nmくらいの大きいプロセスだと思うよ。 >>458
だから16bitや32bitにシフトしてるわけで
>>459
PIC24はオワコン
PIC32に対してメリットが無くて
Microchip自体売る気が無い >>462
PIC32MMは32bitマイコンなのに安いよなぁ >>462
フラッシュメモリー部分は、信頼性考えるとセルサイズ小さく出来ないから、単純な処理ならコードサイズ小さくて済む8bit有利。 > 今時のプロセスルールだと5V仕様にできないから
そんな理由があったのか・・・・
コマケーのも良し悪し棚。 >>468
5Ⅴで動くやつも、内部は2.5Vとか、1.8Vで動いてる。 ↑ 物もある とか言っとかないと、上げ足取られるぞw >>469
5V単一電源で内部降圧してるcpuって例えばどれ？
スレ的にはpicで、と言いたいがとりあえず何でも。 >>469じゃないけど
16bit以上はほぼそうなんでは？
今時5Vでコアを動かしてたら電力が そういやdsPICの5V版はすごく熱くなった記憶。 >>474
30Fは熱かったね、電流がよく流れてた
初めて使ったとき、これは最大クロックはダメだって思って3.3Vの33Fに乗り換えた 趣味の電子工作で 8pin 8bit PIC 用を使って
赤外線リモコンデータの受信解析ソフトをスク
ラッチからアセンブラで書いたんだ。そしたら、
なんと自分でもビックリしたことに一発完動。
今日の株価暴落はこれが原因だったようだ。 8pin 8bit PIC 秋月価格1万個分くらいのロスを出しましたので、それにてご容赦を m(_ _)m よくTVリモコンが行方不明になるので予備機をPICで自作してみたけど
電器屋で税込1000円以下のELPAリモコンの方が
軽くて操作性も良いので
結局そっちばかり使ってしまう 使うCPUのデータシート(別途インストラクションマニュアルがあればそれ) 修行？
趣味だろ
修行と思うなら手を出さない方がいい 勉強のつもりなら8ビットはやめておけ
癖が強すぎる
PICに限らず >>484
リモコン解析部はソースの行数で300行くらい。
別のリアルタイム処理と並列動作させるため状態
遷移処理で作ったので結構ムズイ作り。
ただし、コードの見やすさと実行処理ステップ数
小を優先したのでコードを減らす努力なし。
>>485
電源投入時に必ずリモコン操作が必要になる機器
２台用にPICで作った赤外線リモコン信号自動送出
器が我が家では毎日大活躍。
>>486
データシート以外は検索でサンプルを拾ってくれ
ば十分かと。ただし、おすすめの入門書おしえて
と聞く人にアセンブラは向かない気がする。 リモコンデータの受信解析ソフトって、
単なるリモコンの受信処理部分のこと？
それとも受信回路や送信機の評価用の解析？ 状態遷移処理って何？
逆に状態が遷移しない処理があるのか？ PLCのラダーのような
状態変移で動かすプログラミング
FAやプラントではそういう書き方しないとメンテナンスが面倒 PCの値しか状態を持たないプログラムが存在すると？ 状態を示す変数を用いる処理が状態遷移処理だとしたら
ほぼ全ての処理がそうじゃないか？ >>493
何のリモコンのどのボタンを押したかを解析する処理。
NEC, AEHA, SONY フォーマットMAX6バイトに対応。
受信モジュールは月並な 38kHz 3ｐｉｎタイプ。
リモコンで遠隔操作ができるようになっただけでなく、
8pin PIC でも入力ボタンが一気に増えた気がする
のがうれしい。
>>495
説明が悪かったかな。状態ごとに変数値を決めて
その値に基づいて処理を行うやりかた。
ひとつのことにかかりきりでよければ、プログラム
の流れそのもので、すなわち、状態を表す変数なし
でも処理ができるので、それと区別をしたつもり。 >>502
フォーマットの識別はリーダーパルスの長さで判別？ 状態遷移の状態を、状態と日本語で書くから知らないやつはわからない
stateと書けばいいんだよ パルスの受信は割り込みで
解析は割り込みの外だろ？
「状態遷移処理」とCPU占有の関係がいまいちわからん
CPUを占有してよくて
「状態遷移処理」じゃない処理にすれば
解析が簡単なのか？ >>502
他のマイコンだと、状態遷移テーブルをポインタ関数テーブルに対応させてアドレスジャンプさせるんだけど
8ビットPICだとどうやるの？
アセンブラでもスマートだが、unixのcで、select文と組み合わせてスマートに実現しているのをみたときは
K&Rはこれがやりたかったのかと感動した。ネットワークと内部込みで。 質問です。
16F1705にてUSARTにて通信テストを行っているのですがうまくいきません。
何でもいいので受信すれば、1回LEDが点滅するようにしたいですがうまくいきません。
↓メイン部分でどこか間違いなどありますでしょうか？
// メインの処理
void main()
{
/** 各ピン設定 **/
ANSELA = 0b00000000 ; // AN0-AN3は使用しない全てデジタルI/Oとする
ANSELC = 0b00000000 ; // 全てデジタルI/Oとする
TRISA = 0b00000000 ; // ピン(RA)は全て出力に割当てる(RA3は入力専用)
TRISC = 0b00100000 ; // RC5(rx)だけ入力その他のピンは出力に割当てる
PORTA = 0b00000000 ; // RA出力ピンの初期化(全てLOWにする)
PORTC = 0b00000000 ; // RC出力ピンの初期化(全てLOWにする)
//UART用設定
RC4PPS = 0b10100 ; // 出力(C4へTXを割当てる)
RXPPS = 0b10101 ; // 入力(RC5を割当てる：デフォルト)
TXSTA = 0b00100100 ; // 送信情報設定：非同期モード ８ビットデータ・ノンパリティ
RCSTA = 0b10010000 ; // 受信情報設定
//UART用設定 データシートP340参照
SYNC = 0;
BRGH = 0;
BRG16 = 1;
SPBRG = 25 ; // ボーレートを９６００(高速モード)に設定
RCIF = 0 ; // ＵＳＡＲＴ割込み受信フラグの初期化
RCIE = 1 ; // ＵＳＡＲＴ割込み受信を有効にする
PEIE = 1 ; // 周辺装置割込みを有効にする
GIE = 0 ; // 全割込み処理を許可しない
Flag = 0 ; // データ受信フラグのリセット
/*************** メインループ ********************/
while(1)
{
//PIC電源確認LED点灯
LATCbits.LATC0 = 1;
__delay_ms(500) ;
LATCbits.LATC0 = 0;
__delay_ms(500); // 500ms遅延する
while(1)
{
// ＵＳＡＲＴからデータが送られてきたら処理する
LATCbits.LATC0 = 1; // LED点灯
if(RCIF==1)
{
RXBUFF=RCREG; // 受信データの取り出し
LATCbits.LATC0 = 0; // LED点灯
__delay_ms(500); // 500ms遅延する
}
}
}
} >>509を見てよくわかりました
こういうプログラムが
「状態遷移処理」がないプログラムですね >>510
スマホからですみません
状態遷移処理がないとはどういう意味ですかね?
お手数をおかけしてしまって申し訳ないです >>511
あっ、いやっ...
気にしないでくださいすいません 受信データ列は正しいビットレートで正しいレベルで入力しているのは確認してあるんかいな。 >>513
受信データのビットレートは9600bps（PICは4Mhz外部クロック）で入力の電圧も問題ないと思います。
ただ、PIC（特にPPSの設定）と通信用のモジュール（※）が今回初めて使用する物なので、
基本的な記述に問題がないか確認したく書き込みました。
初心者のため意図と違う返信になっていたらごめんなさい
※通信モジュール
ttp://akizukidenshi.com/catalog/g/gK-07378/ 初期化のところは見てないのだけど(ここが問題かも)
while(1)のループが入れ子になっていて、breakもないし、外のwhile(1)は要らんよね？
どっち？
LATCbits.LATC0 = 1; // LED点灯
LATCbits.LATC0 = 0; // LED点灯
ビットレートが合っているかどうかは、初期化が終わったあとに、何か文字を送信して
オシロで見るか、PCで受信して確認すると良いと思う。 >>515
返信ありがとうございます。
》while(1)のループが入れ子になっていて、breakもないし、外のwhile(1)は要らんよね？
そのとおりです。削除します。
》どっち？
LATCbits.LATC0 = 1; // LED点灯
LATCbits.LATC0 = 0; // LED消灯
が正しいです。
》ビットレートが合っているかどうかは、初期化が終わったあとに、何か文字を送信して
》オシロで見るか、PCで受信して確認すると良いと思う。
オシロが手元にないので、PCに受信する方向で確認してみます！！
》初期化のところは見てないのだけど(ここが問題かも)
そこが問題かもしれないです・・・引き続き調査して見ます。 >>516
連投すみません
PIC側から文字を送信したところ、無事にpc側にて受信できました。
恐らく受信部分の問題だと思われます
引き続き調査してみます。 >>518
なるほど！！目からうろこでした
PICは正常に動作しました！（LEDは消灯しました）
ということはモジュールとPIC間かPCの送信の問題ですね 48MHzで動いてるPIC18から12MHzのクロックって出力されてましたっけ？
HSモードじゃだめかな
外付けセンサーで12MHzが欲しいんだけどなんかPIC用とセンサー用で12MHzを
2つ実装するのが馬鹿みたいな気がして >>519
とりあえず問題の切り分けはできましたありがとうございます
結局のところPIC側ではなくて、モジュールの問題かもしれません
送信はうまく行くのですが、受信をすると電源が落ちてリセットしてしまうことがわかりました。
理由はこれから調査しますが、不良品の可能性もあるのかな？ >>521
質問する前にモジュールのデータシートは読んだ？
いや、俺は読んでないけど。 >>523
モジュールのデータシー読み込めてないです(泣)
英語ばっかで、つなぎ方などを見ただけで
一度読み込んで見ます
ありがとうございますm(_ _)m まずは
PC <===> PIC
PC <===> モジュール
で動作確認
PIC <===> モジュール
はその後で >>525
了解しました
とりあえずｐｃとＰＩＣの通信を完全にします
色々ありがとうございます あまりのレスの多さに感動です
>>503
随分インプリメント依存の所への質問ですね。
今回は、約 125μs ごとに赤外線パルスの有無を
チェックし、１ms以上パルスが続けばリーダーと
判断。その後、パルスが止まってから次のパルス
が始まるまでが 1ms以上なら NEC か AEHA、1ms
未満なら SONY と判定するロジックにしました。
2ms 以上パルスが来なければ終わりと判断。
>>504
とりあえず受け取った bit 数と MAX 6 バイトを
丸ごとレジスタに保存。この内容を後で適宜判断
します。
>>505
PIC には、そもそも STATUS というレジスタがあ
るのでそう書くのを躊躇いました。
>>507
以前は割り込みの無い PIC (12F510) を使ってい
たもので、そのくせというかなごりで、TMR0 の
とあるビットを監視してタイミングをとる形で、
全てポーリング処理で作りました。
> CPUを占有してよくて…解析が簡単なのか？
私はそう思っています。マルチタスクは CPU占有
ではありませんが、ひとつのことに専念している
ようにプログラムを書けるので簡単に作れる気が
するのではないでしょうか。
>>508
8 bit PIC の常套手段かと思いますが、プログラ
ムカウンターに対して状態変数を加算することで
複数のアドレスに一発で分岐できます。その分岐
先には、一般的に GOTO を並べておきます。
addwf pcl,f で検索するとワラワラ見つかります。 >>528
せっかくのキャプチャー割り込みを使わないで
ポーリングでやってるのか
メインループの他の処理によってサンプリングタイミングがずれるし
1000命令かかる処理が他に有れば完全に取りこぼすわけだ
125usと言えばPIC16ではトップレベルで応答性が要求される処理
これで割り込みを使わないで何に割り込みを使うの？
アセンブラの前にもうちょっと基本的なことを学んだ方が良い気がする 割り込み機能の全くない 12F510 が 50円だった頃
20個買ったやつがまだ結構余ってるんですよ。
今回は割り込み機能のある 12F1501 をハンダ付け
してしまってから間違いに気が付いたのですが、ま、
いいかとそのまま 12F1501 でプログラムを作成。
余ってる 12F510 にもダウングレ－ド移植をしやす
いようにとポーリングでやったんですよ。
全ての処理はイベント処理的に 125μs 以内に終わ
るようにコーディングしてます。割り込みを使えな
いわけではなくて、割り込みを使わないで作ったと
いうだけのことです。 超小規模なプログラミングでも
ホビーと業務レベルとの差は大きいな
アセンブラってところがまた泣かせる 業務用のは保守性と再利用性最重要視してるから
冗長過ぎて眠くなる
趣味のは各個人の技巧やら独自記法満載で
読んでえ辛くなる >>528
＞8 bit PIC の常套手段かと思いますが、プログラ
＞ムカウンターに対して状態変数を加算することで
＞複数のアドレスに一発で分岐できます。その分岐
＞先には、一般的に GOTO を並べておきます。
通常のCPUならそうなんですが、PICのレジスタバンクまたいでアドレスジャンプやGOTOして
かつ、ちゃんと帰ってこれるのかなと思って。 赤外線リモコン受光信号にちょくちょく
ちょっかいを出してくるヤツが居る。
何か？と思ったら、Win10 にしてあるも、
ちょっと古いノートPCが、近くに相手が
居ないか定期的に赤外線で声掛けをして
いるようなのだ。
これを使えば PC-PIC 間で赤外線通信が
できるじゃん、と思って技術資料を探そ
うとググってみても中々みつからない。
参考になりそうなサイトをご存知の方、
とりあえずヒントだけでも教えていただ
けませんでしょうか。 >>534
プログラムアドレスの下位バイトが 0xff から次の 0x00 にまたがないようにコーディングする必要があります。 早速ありがとうございます。でも IrDA のプロトコルスタックを
PIC 側に自作する根性は湧きません。PC側をもっと低水準で
Lチカしたくなります。 >>533
>>543
8bitで保守性と再利用性が最重要視？
知らない癖に語るなよ恥ずかしい >>547
え？御社には開発基準が存在せず、ドキュメント管理の効率化もやっていない、
と言っているようなものですよそれ… >>526
とりあえず通信は完了しました!
色々皆さんありがとうございました!
助かりました >>549
理由も書かずに揚げ足とって煽るやつが一番トンチンカンw >>547
横からごめん、東芝の4ビットでも保守性と再利用性は最重要視されてます。＠車両関連メーカー
速度とか機能は仕様の問題だよね。そんなの仕様を満足してればまったく重要視されません。
あとはコストとのバーターだけど、コストの話になると保守と再利用できないと、いまどきのメーカとしてはダメなんだよね。
そこらは営業と調達ががんばるだけ。 仕様
信頼性
コスト
開発期間/納期
これらよりも
コードの保守性や再利用性を重視するアホなメーカーがあるのね >>553
お前ほんとにわかってないんだな。
仕様と保守を同一に語るメーカーがあると思ってるのか？
違いがわからないのかな >>554
特注の単品しかやった事が無いんだと思います。 最重要視
この言葉の意味がわからないのか自分で書いてて
他のいろんな事を犠牲にしてでも保守性や再利用性を確保する
っていう意味だぞ
なにも犠牲にせずに単に
保守性や再利用性を考えたコード
っていう感じで使ったのなら
当然だろうね
保守性や再利用性を考えないコードなどあり得ない 一部上場電機メーカーで量産品をたくさん作ってるよ
他部署や顧客に
「保守性や再利用性を最重要視して開発しました」
なんて言ったら笑われるよ普通 ■ このスレッドは過去ログ倉庫に格納されています
