PIC専用のスレ Part54 [無断転載禁止]©2ch.net [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
＿＿＿＿＿＿
／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/ PC側は微妙にボーレートを変えることが出来るので、
微妙に変えてみたところ、
問題は発生しなくなりました。
ということで、
「PICの送信データが空になる瞬間(TXREGが空の時にシフトレジスタが空になった時)に
TXREGに値をセットすると、TXREGとシフトレジスタの両方に値がセットされて、
送信データがダブる」
という仮説が濃厚になって来ましたので、
これを避けた送信でダブることが無いかのテストをしてみようと思います。
今回は受信データをそのまま送信するというテストでしたが、
実際に行いたいのはパケットの送信です
以下のポリシーで作ってみてテストしてみます
パケットの1バイト目の送信はTRMTを待ってからTXREGにセットする
パケットの2バイト目以降はTXIFを見てTXREGにセットする
TXREGにセットする遅延は1バイトの送信時間より短くする
これで上記の仮説の条件にならないかと思います
これで耐久テストを行って、問題無ければこの実装にします
TRMTを割り込みで待つことができないので、
パケットの先頭ではポーリングによる待ちをするしかないですが、
実際はパケットの間隔がそんなに詰まることは無いので、
それほどロスは無いかと思います
ポーリングは面倒ですが、タイマー割り込みか何かを使います 受信を使わなくても再現出来ました
600文字に1文字くらい、連続して同じ文字が送信されます
以下の例ではVが連続しています
... DEFGHIJKLMNOPQRSTUVVWXYZ[\]^_`abcd ...
----
#pragma config FOSC = INTOSC, WDTE = SWDTEN, CPUDIV = NOCLKDIV
#include <xc.h>
unsigned char read_p = 0;
unsigned char write_p = 0;
unsigned char wait = 0;
unsigned char i = 0;
void main(void){
OSCCON = 0xFC;
SPBRG = 0x67;
BAUDCON = 0x08;
TXSTA = 0x24;
RCSTA = 0x80;
while (1){
write_p += 3;
while (read_p != write_p && TXIF){
for (i = 0 ; i < wait ; i++);
wait += 83;
TXREG = '0'+ (read_p & 0x3F);
read_p++;
}
}
} どうせソフトバグだろと思って読んでたけど
エラッタぽいね
マイクロチップジャパンのHPにお問い合わせフォームあるから
プログラムコードと一緒に問い合わせておいてね >>253
エラッタとかいう前に最内周のwhile直そうね >>253
まず、自分のプログラムを疑って見るところからだな。 もうちょっと単純になりました
waitが145あたり、waitによるループ回数が166回くらいのところで激しくダブります
丁度1文字送信くらいの時間ですので、なんとなく >>252 は正しそうです。
1個あるNOPをなくすとまったく発生しないので、シビアなタイミングなのだと思います
@AABCCDEEFGGHIIJKKLMMNOPQRSTUVWXYZ[\]
----
#pragma config FOSC = INTOSC, WDTE = SWDTEN, CPUDIV = NOCLKDIV
#include <xc.h>
unsigned char ch = 0;
unsigned char wait = 0;
unsigned char i = 0;
void main(void){
OSCCON = 0xFC;
SPBRG = 0x67;
BAUDCON = 0x08;
TXSTA = 0x24;
RCSTA = 0x80;
NOP();
while (1){
while (!TXIF);
for (i = 0x9D + (wait>>4) ; i-- ;);
wait++;
TXREG = '0'+ (ch++ & 0x3F);
}
} ということで、私の中ではエラッタ確定で、
>>252 の方針で対策します それにしても、
こんな大きなエラッタを公開も修正もせずに放置ですか
国内メーカーじゃ考えられないですね >>258
なあ。笑うしかないんだけど。
石のシリアル周りの仕様をちゃんと読もうよ 私 の 中 で は エ ラ ッ タ 確 定 ッ ！ 色んな人が居るもんだな。
"コンパイラのバグ！"とか言い出すやつも割といる(ホントにレアケースで時々あるのでたちが悪い) つまりどういうことだってばよ！
TXREG書込直後のTXIFフラグは無効だから、２命令経過してからTXIFポーリングしやがれってことかいな 予想:
次は、仕様書の記述が解りにくいとかサンプルがー！って言う。 いやいやちゃんとソース読んであげなよ
TXIF の挙動がおかしくても
同じの二つ送られるのはおかしいだろ
TXREGには同じ値入るプログラムになってないだろ
TSR(送信シフトレジスタ)は触れない訳だから
ここに同じ値が何らかのタイミングで
入ってしまうと考える動きだわな
これが仕様とするなら
データシートに記載しなくてはいけないと思うよ
TXIF状態でTXREGに値を書き込むのはダメだと
TSRの状態フラグTRMTみて書き込めと
(サンプルはそうなってる？みたいだし)
でもデータシートにはTXIF見るのは
2命令サイクル後にしろと書いてある
エラッタじゃないとしてもデータシートの不備だと思うよ 割り込みに優先順位つけ排他処理出来て
TXIFで一発目ｵﾚｵﾚ割り込み出来る
16bitユーザは高みの見物 こんなの
for (i = 0x9D + (wait>>4) ; i-- ;);
とか、こんな
'0'+ (ch++ & 0x3F);
何やってるかさっぱり意味わかんない（しかも本人の説明とズレてる）コードを
ちゃんと読めという>>269はソースをちゃんと読んでるんだろうかという疑問 >>265
良く分かってない上の人達に本対策までの時間稼ぎをするには有効な言い訳だよww UARTの送信中のあるタイミングでTXREGに書き込んだらトラブルが発生するらしい、ということだよなあ。
TXREGへの書き込みのあと、TXIFを見にいくまでにちょっと長めウェイトを入れたりはしたのかな?
本質からは外れるかもしれないけれど…
'0'+ (ch++ & 0x3F);
これは試験的に ASCIIコードで0〜o の文字を送信するためだと思うのだけど、
for(i=0x9D+(wait>>4); i-- ;);
waitをシフトしている理由って何だっけ。 >>273
16文字ごとにカウンタ値を1増やしているのでは 普通は送信も受信も割り込み使って長時間のフラグ待ちなんてしないように作るから
だれも困らん IntelであれだけエラッタあるのにPICのエラッタではないかというだけで総攻撃とはいやはや。 メーカー指定の使い方をしないで「エラッタ」とか、馬鹿過ぎる。 >>279
詳しく。どういう指定で使うように強制してたの？ メーカーのバグやエラッタなんて日常茶飯事なのにここは仕事したことがない無職ばかりなのか。 >>279
さっさと答えろよ、馬鹿。煽るしか脳がないアホなのか？ >>270
>>277
問題点を絞る為になるべくシンプルなコードにしただけで、問題を発見した時のコードは割り込みでの処理です >>271
for 分は wait処理です
TXREGが空になってかTXREGにデータをセットするまでの時間調整です
ループ数が
0x9D + (wait>>4)
となっているのは、なるべく問題が発生する時間を絞りたかったからです
'0'+ (ch++ & 0x3F);
は64種類の文字を順番に作り出すコードです >>258 のコードは、確実に安定して問題を発生させる為のコードです
256文字周期で確実に >>258 に貼ったようなデータが送信されます
タイミング依存ですので、コンパイラに依存すると思います 海外のフォーラムだったらコードに問題があると思うなら
こういうコードの方はどうよ？って書き込みがぶら下がる
もんだけど単なる煽りしか出ない辺りが日本らしいよなぁ
技術的な話を楽しむ人よりストレス発散目的の人多過ぎ 学力世界一とか騒いでいたフィンランドがこの有様
池上のニュース総決算でフィンランドの教育のこと褒めてたけど、実は全然駄目らしい。
＊国内で大批判が起こってる
＊中学生で分数計算ができるのが２割以下
＊日常的な買い物の計算もできない子供が増加
http://jukuyobiko.blogspot.jp/2016/01/blog-post.html >>278
>>281
簡単なテストで見つかる問題である
発生した時の問題が大きい
非常にシンプルなモジュールである
（おそらく）多くのマイコンで同じ問題が発生する
（おそらく）メーカーは把握している
（作りによっては）対策が難しい
問題は色々あるが、一番の問題は
「エラッタシートに記載がない」 問題は一つだけってことは滅多に無いから最初の不具合は排他制御をミスったリングバッファのバグの可能性大 >>287
いかにも日本的な教育観だね。
分数計算とか日常の買い物とか…。
日常生活したことある？ 一言「搭載しているトランスミッタの仕様です」で終わるような話だな
MicroChip社はドキュメントへの記載を速やかに行いましょうって所？ このエラッタそのものじゃないの？
PIC16(L)F1574/5/8/9 Family Silicon Errata and Data Sheet Clarification
http://ww1.microchip.com/downloads/en/DeviceDoc/80000642B.pdf
＞1.1 Transmit Mode
＞Under certain conditions, a byte written to the
＞TXREG register can be transmitted twice. This
＞happens when a byte is written to TXREG just as
＞the TSR register becomes empty. モジュールは流用するだろうから一つ不具合があると同系統のチップ
全部に波及するんだろうな。 >>288
>（作りによっては）対策が難しい
そんな鈍臭いプログラムを書く奴は℃素人以外いない。
一番の問題は、鈍臭いプログラムしか書けない事。
まずはデータシートを熟読する事だな。
あとはセンスが必要だが、こればっかりはどうしようも無いだろうｗ >>293
あ、それそのままですね
PICのプログラミングを行う場合は違うマイコンのエラッタまで見なきゃならんてことですね
ひどいメーカーだ >>295
不確定なタイミングで送信要求が来る
一連のデータは1bitも隙間を空けずに送信する
ビジーウェイトしない
これをすべて満たす方法が無いわけですが いまさらですが、'1'の送信が毎回ダブるコードが出来たのでアップしておきます
----
#include "p16f1454.inc"
__CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF & _FCMEN_OFF
__CONFIG _CONFIG2, _WRT_OFF & _CPUDIV_NOCLKDIV & _USBLSCLK_48MHz & _PLLMULT_3x & _PLLEN_ENABLED & _STVREN_OFF & _BORV_LO & _LPBOR_OFF & _LVP_OFF
MAIN CODE 0x0000
MOVLB 1
MOVLW 0xFC
MOVWF OSCCON
MOVLB 3
MOVLW 0x80
MOVWF RCSTA
MOVLW 0x24
MOVWF TXSTA
MOVLW 0x08
MOVWF BAUDCON
LOOP
BTFSS TXSTA, TRMT
GOTO $-1
CLRF SPBRG
MOVLW d'13'-1
MOVWF SPBRG
MOVLW '0'
MOVWF TXREG
MOVLW d'120'
COMF WREG, W
ADDLW 4
BTFSS STATUS, C
GOTO $-2
BRW
NOP
NOP
NOP
MOVLW '1'
MOVWF TXREG
GOTO LOOP
END 自分で言うのも何ですが、まったく見る気が起きないコードですね 16bitの優先順位付きの個別割り込みで解決出来ると思ってるところが？ しかし、PICのことを少しでも悪く言うとヒステリックな反応が続出するのは
どういう心理なんだろうね。
・俺の愛するPICを貶すとは許せん。
・先に見つけられて悔しい。
とか？ 淡々と事実だけ述べれば良いのに一言多かったりするからじゃね？
端から見てるとどっちもどっちだわ こんな反応をされたら、温厚な私でも一言いいたくなるよ
>235 >237 >255 >261 >262
>264 >267 >276 >279 >289 >>295 もひどいな
問題点をまったく理解していないからそういうことが書けるんだろうけど >>297
データシート嫁ｗ
>>298
>これをすべて満たす方法が無いわけですが
センスが無い上に理屈で考えられないのはよく分かってる。
だから思いつかないんだろう。
そういうレベルの奴は、少なくともデータシートをちゃんと読んで
プログラムを組めば、この件に関しては問題無い。 >>308
データシートには書いてない
>>298 をすべて満たす方法も無い
嘘を繰り返しても真実にはならないよ データシートも読めないのか。
>>298は、Cしか出来ない鈍臭い奴には無理。俺は普通に出来るよ。 煽ろうが何しようが不可能なものは不可能だし、書いてないものは書いてない その証拠に、
どこに書いてあるかも書けず、コードで示すことも出来ない
幼稚園児が「おれは空を飛べる」っていうのと同レベル 新しいのは発売後暫く経ってからじゃないと怖くて使えないな 全然証拠になってないｗｗｗ
ま、せいぜい頑張って勉強するんだね。
Cしか出来ない奴には無理だろうけどｗ ちなみに俺は、921600BPSで普通に使えてる。
115200如きで何言ってんだかｗｗｗ アセンブラバカはスルーするのがこのスレのルールです >>315
普通に使えてるってwww
>>298 の意味がわからないんだね >>317
>>299のゴミコードを書いた奴は「アセンブラが出来る」とは言えないレベルｗ あ、>>298 には書いてないけど、当然エラッタは回避してね >>320
よっぽど鈍臭くてセンスの無いプログラムを書かない限り
そのエラッタには引っかからない。 エラッタシートにもまともな解決方法が書かれて無いんで、本当に方法があるなら教えてあげればwww
違うマイコンのだけど >>323
ある確率でひっかかる、もしくは気づいてないだけ 幼稚園児レベルの嘘www
後に引けなくなったバカwww >>324
>教えてあげればwww
とか、まるで他人事だなｗｗｗ
お前が鈍臭くてセンスが無い本人だろうにｗｗｗ
だいたい、2重送信が回避出来ないようなマイコンが
普通に売られてると思ってる所が駄目駄目だな。
普通に組めば2重送信なんて起きない。プログラムがタコなんだよ。 回避するには >>298 のどれかをあきらめなきゃならないんだよ エラッタシートにある回避策のNOPでタイミングをズラすって、エンジニアが書いたとは思えないよな
割り込みハンドラでTRMTを見ろってのもなあ
TRMTが0だったらどうするつもり？ ここだと技術的な会話にならないな
技術的な会話が出来ない人が無理に会話に入って来るから エラッタが無ければとりあえずはこれで何も問題が無いんですが
void interrupt isr(void){
while (read_p != write_p && TXIF){
TXREG = data[read_p++];
}
TXIE = (read_p != write_p);
} そもそもTXIFは送信割込みがあった事を示すために用意されてるもので
割込み処理の中で参照する事を想定してるわけ
TXIFが立つ事象（データがシフトレジスタに送られて送信バッファが空になる）が発生して
割込みが発生して割込み処理ルーチンに飛んで、それからやっとTXIFを参照するというのが想定された使い方
それだとTXIFが立ってから参照されるまで数クロックは後になるから問題は発生しない
想定してない使いかたすると想定してない振る舞いをすると言われても、そりゃ想定してないからねとしか言いようが無い こいつ問題点全然理解してないな
ウルトラ級のバカだ >>334
シリアル出力が終了すると同時に送信レジスタに書き込むとシフトレジスタにデータが送られても送信レジスタが空にならないって不具合だよ
頭の部分で送信が終わるのを待てばいいだけ >>329
考える能力が無いなら諦めるしか無いなｗｗｗ 以下が普通のUARTの送信コード
uart_sendは割り込み以外のいつ呼ばれるかわからないとして、
エラッタに対応するにはどうすればいい？
--------
#define DATA_SIZE 0x40
char data[DATA_SIZE];
volatile unsigned char write_p = 0;
volatile unsigned char read_p = 0;
void interrupt isr(void){
while (read_p != write_p && TXIF){
TXREG = data[read_p & DATA_SIZE - 1];
read_p++;
}
TXIE = (read_p != write_p);
}
// 文字列をUART送信, 文字列はNULL終端, 戻り値は送信出来た文字数
unsigned char uart_send(const char* pt){
unsigned char count = 0;
while (*pt != '\0' && (write_p - read_p & 0x80) == 0){
data[write_p & DATA_SIZE - 1] = *pt++;
write_p++;
count++;
}
TXIE = 1;
return count;
} なんで自分で考えようとしないんだこいつ。
ユトリかｗｗｗ おっと、１か所間違えました
ほとんどの場合は何も問題が無いんですが、
エラッタのせいで、uart_sendがコールされるタイミングによって文字がダブる場合があります
対策が簡単だという人、ぜひ簡単に修正していただきたい
--------
#define DATA_SIZE 0x40
char data[DATA_SIZE];
volatile unsigned char write_p = 0;
volatile unsigned char read_p = 0;
void interrupt isr(void){
while (read_p != write_p && TXIF){
TXREG = data[read_p & DATA_SIZE - 1];
read_p++;
}
TXIE = (read_p != write_p);
}
// 文字列をUART送信, 文字列はNULL終端, 戻り値は送信出来た文字数
unsigned char uart_send(const char* pt){
unsigned char count = 0;
while (*pt != '\0' && (write_p - read_p & DATA_SIZE) == 0){
data[write_p & DATA_SIZE - 1] = *pt++;
write_p++;
count++;
}
TXIE = 1;
return count;
} 住民にデバッグ、プログラミングしてもらうつもりなのかｗｗｗ 出来ないものを出来ると主張するんだから、それを示せば良いだけです
上のコードじゃなくても良いので
ただ「出来る」と言うだけじゃ何も進みません 進まないのは考える能力の無いお前さんだけ。
普通の人はそんな所に引っかからない。いままでのレスの中に正解があるけど
気が付かない＆無視してるようなレベルだから、どうしようもない。
ま、℃素人にありがちだけどな。
進みたいなら自分で考えることだな。普段から自分で考える癖をつけてないから
エラッタだのハードがおかしいだの言い出すしか脳がない。 そう思ってれば良いよ。世の中にはCしか出来ない奴がかいた
鈍臭いプログラムが沢山ある。 >>341-342
嫌みだけのためによくそんだけいっぱい書き込みできるなおまえ
1〜2キャラ分のデッドタイムが許されないなら別のチップ使え エラッタくんはMicrochipに就職してくれよ。 俺も1454でシリアルやるし連続送受信もやるけど、MCCが確保した128バイトだかのバッファを介して送受信してる。
今回その方法を使わない理由ってなに？ 意見が衝突しているのだとしても、できるだけ意図を読み取るようにしないと混乱に
拍車をかけるだけです。落ち着いて読みましょうぜ。
>>349
>>298が言ってるのは「1〜2キャラ分のデッドタイム」「1ビットのデッドタイム」ですね。
余計厳しい。
>>352
この流れの話なら、元レスは隙間なくツメツメで送信をしたいと考えているようだから、
>>350が言ってるのはハードウェアのバッファじゃないかと。
でも、PICにハードウェアバッファのあるUARTを持つものってあるのだっけ。 エラッタが無かったとしても受信bps>送信bpsの条件なら動作しないし
１キャラの空きができたから発現するエラッタなんだから送出開始に遅延が出ても何の影響もないし
検討するのもアホらしい仕様だ >>341
その条件を満たすのは俺には無理。
uart_send()の頭でbusy waitするぐらいしか思いつきません。
if(!TXIE)
while(!TRMT); ℃玄人は相手にするだけ無駄。
まともなレスをしたのを見たことがない。 921600BPSでさえキッチリ詰めて送信出来るのに
Cしか出来ない奴って、115200BPSさえ使いこなせないとか、バカス >>354
キッチリ詰めても送信側のボーレイトが早くても許容範囲内なら問題無い。
但し、ノイズ等で同期が外れても回復させる為に、適当な間隔で十分なストップビットを入れてやるのがまともな設計。 パッと見、read_p、write_pが同期取れてないみたいだけど >>360
本件の同じキャラのダブりについてのコメントだとしたら、それとは関係ない模様。
>>293-294で技術的な原因はほぼ確定していると思うんだが、
別のチップのモジュールのエラッタを参照しなくちゃいかんのか、というモヤモヤが尾を引いてるのではないかと。
http://www.microchip.com/forums/m829947.aspx#829947
ここでも、TXIFがらみでキャラのダブりについて議論されていて、
「(問題が発生している)PIC12F1572にはこのエラッタ情報がない」という話に対して
「他のチップのEUARTのエラッタも見るようにしているよ」という話が出ている。 >>361
> 「(問題が発生している)PIC12F1572にはこのエラッタ情報がない」という話に対して
> 「他のチップのEUARTのエラッタも見るようにしているよ」という話が出ている。
これが本当だとしたらメーカーが怠惰すぎるな
仕事で使える代物じゃない 仕事で件の℃素人プログラミングしてるなら、首括ってタヒんだ方がマシ
迷惑の掛からない方法でどうぞ。 使えないと思う人は使わないで良いんじゃないの？
そう思う人が、そう思わない人に、そう思えって強制するようなことでもない。
どんなものでも人によって評価の変わる長所短所をまとめて使う使わないを決めるんだし、
一般論として使える使えないなんて匿名掲示板で議論するようなこともでもない。 >>364
首括って死んだ方がマシなんてことなんてないよ。言葉に気を付けろ。糞ったれが。 自分の能力の無さを棚に上げて何時まで管を巻いてるんだｗｗｗ
データシートも読めず115200BPSさえ組めないなら、CPUに何を使っても同じ。何らかの問題が出てくる。
とっとと死んでくれｗｗｗ >>361
もう理由は分かってるのか。よくあるタイミングの問題だな。
時間内にデータが用意できないならタイミングﾁｬｰﾄ書いてnop入れてずらせとしか。
しかしCでこういう頭がハゲそうになるギリギリのコードは書いちゃダメだよ。
基本どおりatomicのものはatomicに書かないとタイミングバグあったとき単体テストをパスするよ。 >>366
池沼ニートに触れるなよ
いい加減学習しろ >>352
MCCがはいたコードを見てみたけど、エラッタの対策は何もしてないよ とりあえず、回避は出来ました
タイマーが1個必要ですが >>352
MCCは手っ取り早く動かすには良さそうですね
UARTの基本的な作りは私の作った物とほぼ同じ
リングバッファの使い方は私の方が上です
MCCは割り込みを一時的に止めなくてはなりませんが、私のは止めなくても問題ありません
また、RAMサイズ、コードサイズ、パフォーマンスも微妙にですが私の方が上です
MCCでは、1回の割り込みで1バイトしかデータをセットしてないのが気になります
RCREGからの取得もTXREGへの設定も最大2回行うことが出来るんですが ソース出さずに自画自賛
PICユーザってこんなキチガイばっかりだな タイマー割り込みを乱されたくないからUARTはメインのループで
送受信することが多いから、この系統のPICは使わないようにするわ。
PIC16(L)F1574/5/8/9
PIC16(L)F1454/5/9 >>376
2ちゃんではどこでもそんなもんじゃん。PICに限定する話ではないわ。 >>375
おれも送信割り込みでは１バイトしか転送しないように作ってる
１バイトしか書けない時の方が圧倒的に多いし割り込みコードも小さくなる >>378
PIC16F18313も
おそらく他のも >>381
割り込みが1回多くかかる方が大きな時間をロスすると思うのだが
送信の初めは毎回2回TXREGにセットすることになるし Cのコード的にはifをwhileにするだけ
1バイト転送時の実行時間は同じか1命令サイクル増えるかどうか コンパイラで最適化がどうなるか分からないのに
アトミック操作無視したコードを自画自賛してる時点でキチガイ >>374
エラッタ対策のコード
デメリットはタイマーを1個使うのとメンテ性
途中でボーレートを変える場合はいったんSPBRGとSPBRGHとタイマーをクリアしてから再設定
SPGRGが奇数(つまりパルスの幅が偶数サイクル)なら上手くいく
----
void uart_init(void){
SPBRG = LOBYTE((CORE_CLOCK/4+BAUD/2)/BAUD-1);
SPBRGH = HIBYTE((CORE_CLOCK/4+BAUD/2)/BAUD-1);
TXSTA = 0x24;
RCSTA = 0x90;
NOP(); // SPBRG&3 の値によって0個か1個
T2CON = 0x04;
RCIE = 1;
}
void uart_tx_isr(void){
while (TXIF && tx_pt_r != tx_pt_w){
if (TMR2 & 1){
NOP(); // コンパイラによってNOPが1個が2個
NOP();
}
TXREG = tx_buf[tx_pt_r++ & TX_BUF_SIZE - 1];
}
TXIE = (tx_pt_r != tx_pt_w);
} >>385
uart_send内のwrite_p++ のことなら
volatile が付いていて値の更新が1回しか行われないことは保証される
1バイトの書き込みがアトミックであることはC言語上は保証されないが、
1バイトの書き込みがアトミックではない処理系は私はみたことがない
少なくともPICであればどこコンパイラでもアトミック
こんなことを疑い出したらレジスタの書き込みだって出来ないよ >>387
>1バイトの書き込みがアトミックではない処理系は私はみたことがない
これはちょっと言い過ぎでしたね
4bitマイコンを忘れてました もともとハードに大きく依存するドライバのコードなんだから、
存在するかどうかもわからないような非常に特殊なハードへの移植性なんか
考える必要はないと思います
PICの場合は1バイトを分割して読んだり書いたりすることはないので、
コンパイラには依存しません
エラッタ対策の方、>>386のコードは大きく依存しますので、
コンパイラのバージョン変更などのたびに検証が必要でしょう
NOPの数が変わる可能性があります
気を付けるのはコメントをつけた2か所のNOPの部分のみ
1箇所目はRCSTAへの代入からT2CONへの代入までの命令サイクル数
2箇所目はTMR2の読み込みからTXREGへの代入までの命令サイクル数
に依存します どうして誰も書かないの？>>298は出来ないよ
どれか条件を外す事って答えれば、298氏は満足なんちゃうん？ 1キャラ分のタイマー割り込みで送信が終わるのを待ってTXREG に書き込めばいい >>390
別に>>298＝エラッタ基地外 に教えてやる義理は無いからな。
普通の人間なら、その程度の条件でダブる事無く動くプログラムが書ける。
それだけの話。 エラッタが公開されてない
発生率がそれほど高くない
Microchip製のコードがエラッタを回避していない
これでエラッタ回避のコードが書けてたら天才だろ PIC16F1459でも以下のエラッタありということですね。他にも同じ構成のものはすべて該当するでしょうね。
PIC16(L)F1574/5/8/9 Family Silicon Errata and Data Sheet Clarification
http://ww1.microchip.com/downloads/en/DeviceDoc/80000642B.pdf
> 1.1 Transmit Mode
> Under certain conditions, a byte written to the TXREG register can be transmitted twice.
> This happens when a byte is written to TXREG just as the TSR register becomes empty. まともな回避策を提示できないMicrochipは、普通の人ではないようだ。 >>394
じゃあMCCが作るコードは普通の人未満だ 煽るの下手すぎｗ
仕事出来なさそうなのがよくわかる。
ま、頑張って勉強してくれたまえｗ pickit3とAE-PICKIT-ﾗｲﾄで12F1822に書き込んで遊び始めた初心者なのですが
pickitさんのご機嫌のせいか5V足らないって言われるときがあるのですがこれはセルフパワーのハブ買えば解決しますでしょうか？
なった時は色々ポート抜き差しでご機嫌直ればその日は問題無く使えるのですが毎回これだとうざいので解決したいです。
ちなみにデスクトップだしその他のポートに大食らいの機器は繋いでません セルフパワーハブ買っても解決しなかったよ
うちでもたまにVDDの電圧足りんよ！って言われるけどそういう時は一度抜き差しすれば
大抵は直る。もうそう言うもんだと思うことにしてる >>399
今までPC直結のバスパワー以外で使ったことは一度もないです。
自分ならまずAE-PICKIT-ﾗｲﾄのハンダ付けを確認する。
次に疑うはUSBケーブルで、これは純正品？
Canonのスキャナーに付いてきたケーブルが、純正品以上にトラブル無しだったりする。
最後に、PC側との相性が出ることもあるから、別の端子に挿してみるとかは試す価値ある。
あと、メッセージ通りの原因じゃないことも多いので、あまりこだわらず他にも注意して。 ＞普通の人間なら、その程度の条件でダブる事無く動くプログラムが書ける。
本質を理解できないで恥ずかし書き込みだな。
自分では回避できたつもりになってるのかな。 悔しそうだなｗ
内部回路を想像出来ればなんの問題ない事が分かるんだが
ま、℃素人には無理かもな。 >>404
ワンパターンだからあぼーんできるのにつまらん事言うな。 やっぱり℃玄人の妄想だったか。
いつものパターン。
「オレにはできる。しかし、詳細は書けない。」 >>402
池沼だから℃玄人様は書けないのだろ
何も間違ってないだろ >「オレにはできる。しかし、詳細は書けない。」
℃玄人はフェルマーの最終定理かｗ
「私は真に驚くべき証明を見つけたが、このスレはそれを書くには狭すぎる」 >>408
「ホテルロイヤルの謎」の話題はそこまでだ！ｗ
℃玄人さんだったか
どうりで書けない訳だ PIC16よりPIC24のエラッタがひどすぎる
売るレベルじゃない 無理してPIC使わなくて良いのに。
おこちゃまには敷居が高いんだからｗｗｗ 何でそんなネガティブな発言しか出ないのかな？？？
人の発言にだめということは簡単でどんな馬鹿でも逆を言えば出来る
こんなことばかりではなんの進歩もない
やはりここにはふぬけが多くなっているのか！！
日本人の質が落ちていると言われているのは事実なのかね〜〜〜 PICはエラッタだらけでやってられない。だがもうその心配はご無用。
Microchipから超新星のマイコンが出ました。
AVRです!!! 超新星って実態と多くの人の印象が食い違ってるものの一つだな。 Microchip Directでは旧Atmel製品送料無料キャンペーン中
よっぽど売れないらしいｗ 俺の予想 ・・・ 8ビットのコアはAVRに統一
PICはクソ過ぎる CPUってクソだと言われる方が何故か生き残ったりするよなー なんでもそうだけど、一部の長所がほかの物を圧倒していても、結局は歴史経緯を含めてのトータルだし。 >>427
クソにまみれて生きていくのか・・・ま、それも人生だなｗ 周辺そのままでコアAVRのPICはやく。
アセンブラ爺が全滅しますように。 しょぼい若造はアセンブラを古いと馬鹿にし
しょぼい老害はアセンブラもできないのかと馬鹿にし...
両方とも消えればいいのに 確かににPICのアセンブラはいろいろ古臭い。
百戦錬磨の古強者ですら読みたくない、書きたくないレベル。変態アセンブラと言っていい。
それに比べてAVRのアセンブラはどうか。
まさにエレガントである。 >>432の
>アセンブラ爺が全滅しますように。
は、アセンブリ言語を古いと否定しているわけじゃないだろう。
アセンブラ爺を否定的に見てるだけじゃないのかな。 モトローラ６８系であっても過去のアセンブラ設計機器の保守だけはご勘弁・・・ Z80案件で20年物のコードの保守を中途の若い社員にやらせたらすぐ辞めてったわ
ヤツはパタヘネを教科書にしてMIPSで勉強してたと聞いたが
汎用レジスタが湯水のように浪費できる石でアセンブラを勉強しても
甘えが出て来てダメだな
いや、PICぐらいシンプルだったら逆に音をあげずに頑張れたかも (ｗ >>440
いや、与えられた仕事が荷が重いとか気に入らないとかで
すぐ投げ出して辞めるような奴は何処に行ってもダメなままだろうよ
もっとも、力量に見合う仕事を適切に振れないアセ爺439が
上司としてクズなのは間違いないが Z80だから辞める余裕があった。PICなら絶望して自殺してただろうな。 老害のパワハラ自慢ですか
ホント >439 みたいなのは氏ねばいいのに ところでZ80の保守案件任せたぐらいでなんでそんな発狂してるん？
上司としてクズとかパワハラとかさっぱり読み取れんわ。 任せたことについて言ってない。
>>439の文章からにじみ出る人間性について言ってる。
あなたに読み取ることが出来きないのはお気の毒としか言いようがない。 > PICぐらいシンプルルだったら逆に音をあげずに
ここか。完全にPICに対する嫌味だよな。性格悪そう。 パタヘネのMIPSってR2000世代だし
確かにこれが出来るからってだけでアセンブラを極めたとは言い難いが…
ただ、そのアーキでの学習行為そのものを全否定した>>439大先生は
一体どんな芸術的and/or保守性に優れたコードをお書きになるのか
是非拝見したいわ ガイジは脳のシワが少ない。
ガイジジイはなにか言い返さないと気がすまない。
ガイシは絶縁に使う
カイジはギャンブル狂
カイジンはヒーローに倒される 8bitのISAは特殊でハードの低コストをソフトでカバーするという方針なので
longなどの整数計算をしようとするとハンドアセンブルはきついものが多く
難しさは6502/8080/PIC/AVRでも共通で古いことが原因ではない。
ソフトの作りやすさは変数が8bitを超えると難しいものが多くレジスタも
少ないのでポインタ操作やゼロページのロードストアになれてないと厄介である。
アセンブラするならまだR8Cのが楽。
それを避けるためにAppleIIではSweet16を造りM$ではマクロアセンブラを作ったのだから
今の若者が32bitのつもりでアセンブラでコーディングするのと訳が違う。
8bitのトリッキーなコードもあるので最低限シミュレータやアセンブラで
追ってく事は必須。 多倍長精度の計算を4bitでソフト処理するという電卓の設計がそのまま
拡張されたものなので若い人が8bitに関わるならソフトのほうにリソースを
割くべきと覚えるといいよ。そのために使える手段は何であるかと。 z80は16bit演算命令あるし、mipsはキャリー演算できないのかよと思ったら本当になかったw
> MIPSアーキテクチャでは、ステータスレジスタが存在しない。
> addはaddiと同様、計算結果が桁あふれを起こした際に例外処理でプレステがハングしてしまう。
欠陥アーキテクチャじゃんw Z80やその互換のシェアって、今はどのぐらいあるんだろう・・・ 日本の新規組込案件ではZ80壊滅、PICかRL78の２択
欧米だと有線無線モデムチップ内蔵マイコン等で8051がしぶとく残ってる >>452
MIPSではオーバーフロー例外使わない場合ADDU使うようになってる
(オーバーフローを扱わない場合、加算、減算は符号付き、符号なし関わらず同じ結果になる)
C言語ではオーバーフローは扱わないのでMIPSのCコンパイラは加算にADDU使ってるぞ
それに32bitのMIPSでもC言語で64bitのlong long intの演算はできるので何の問題もない ちなみに32bitのMIPSで64bitの加算はこうやって実現してる模様
addu $2,$4,$10
sltu $12,$2,$4
addu $3,$5,$11
addu $4,$12,$3 >>456の意味は
$2←$4+$10
$2と$4を比較して$2が小さければ$12に1をセット
$3←$5+$11
$4←$12+$3
この場合$12がキャリーの代わりになってるね MIPSはトリック的な方法を使うことを前提としてる場合があるので
そういう時はアセンブラだけでは理解しにくい場合があるな
16bitのイミディエイト値のロードだって
ori $4, $0, 16bitイミディエイト(符号なし)
や
addui $4, $0, 16bitイミディエイト(符号付き）
で実現してるしね >>457
そこまで説明するなら、ちゃんと足し合わされる64ビットの数値は
32ビットずつどことどこのレジスタに入っているという説明も入れてほしいな... >>459
上位:下位
$4:$2← $5:$4 + $11:$10 トリック的と言えば MOV 命令の無い PDP-8
MOV するには
CLA
TAD R1 ; two's complement add
DCA R2 ; deposit and clear A
誰も知らんか... 老害ジジイが延々スレチな話題でスレを荒らすのはもう週末の決まりごとか
なんかなのか？ >461 とかマジでさっさと氏ねばいいのに 新人でそういう変なプライド持ってくる奴は一発鼻っ柱折ってやった方がいいよ。 >>463
ちょっと教えてくれ
439のどの辺が変なプライドだと読み取れたんだ？
MIPS云々の下りは上司にアセンブラ経験を問われて答えただけのように見えるが
ま、Z80保守案件なんか受けても単価安くて渋いだけだろうに
その上新人いびりまで蔓延る会社に新人が入っても先はないだろうな
賢明だ >>456-458
でもこれを柔軟性と考え予測で有利になるようにコードジェネレータを考えるコンパイラ屋と言う職業もある
また各ハードベンダーもドライバでひと工夫入れる余地になる
CISCは命令の幅のなさがロジックの固定化を招き、結果ロジックそのものの自由な発想にも制約を与えてしまう
高級言語ですら書き方一つで速度差が出る時代、並列云々まで見通すと奥が深いよね >>465
なんかいろいろと、...
言ってることが、... 昔はフラッシュやRAM内蔵の32bitMCUなんてなかったよな
だんだんと頭脳に相当する部分は32bitに移行していくのでは？
8bitMCUは本当に単純なことしかしないものや
頭脳に対して、神経に相当するような用途で残るだけなのでは？ PICの魅力はスリープ電流とDIPの小ピンが充実してることだと思う。 スリープ電流なんて他もみんな小さいよ
小ピンのDIPって趣味の工作以外の用途が思い浮かばない スレと関係ない事を永遠と下記連ねる
指摘されてもやめない
そりゃ辞めるわな
こんな気違いがいたら、、 小ピンDIPなPICはセンサ制御するときに良く使ってる
SPI/I2Cでセンサとつないで、残りピンにSWとLED割り当てるだけ
Arduinoやラズパイより安く小さく低消費なのが良い 小ピンDIPはボリューム付けてADCで受けて、PWMで制御するのに便利だよ。
ボリュームは究極の入力デバイスだよ。 DIP8ピン敵視する訳じゃないがお前らがDIP8ピン(そして秋月扱い)を絶対視するのを見てると滑稽としか思わない。 確かに>>475は少ピン小型デバイスの使い道は論じてるけれど、DIPであることのメリットはなんも書いてないね。
製品に採用するときのDIP品のメリットは、フロー半田がしやすいってことぐらいかな。 ID:tdNnu8GJ ←おれたちには計り知れぬアセンブラトラウマあるみたいだなw なぜ変態マイコンスレにいるんだか。 ×アセンブラは難しい（食わず嫌い）
○アセンブラは面倒くさい（普通）
？アセンブラは気持ぢいぃ（変態） アセンブラは難しくない、めんどくさくもない
ただ、バリバリに最適化して1サイクルでも高速に動くものを1日でも早く納品しようと思うから大変
バランス大事… 使うことに積極的になれるかどうかは、相対的な問題なので、そのバランスを考えれば、
どうしても頼らないといけない部分を除けば、多くの場面で高級言語を使うことになりますね。
っていうのが、世間の趨勢ですね。 >>482
で、納品間際の仕様変更で、二度と見たくもない代物ができわがるってわけだな >>484
一遍だけ、納品4時間前に仕様変更命令が出たことあったわ 普段はC言語で組んでて、それで何の支障もない。
たまにアセンブラで無いと解決しない事象が出てきて
「あ゛ー面倒臭いなー」と思いながらニモニック表引っ張り出してくる
そんな存在。 アセンブラを使う場面
アセンブラしか出来ない特殊機能へのアクセス(特殊なレジスタとか)
パフォーマンスやタイミングが重要な場面
コード量を減らす必要がある場合
アセンブラが趣味
普通はC言語の方がはるかに開発効率が良い
ただ、C言語しか使わなくても、命令を知っておいた方が良いことは多い >>482
開発効率がはるかに劣るアセンブラしか使えないような人は仕事では使えない
過剰な最適化に時間を使うような人も仕事では使えない
趣味であればその辺は自由 アセンブラを始めた頃はCの何倍もウンザリするほど時間が掛かっていた
今は馴れたしサンプルの貯金も出来たので
＜演算、リングバッファ、2進-10進変換、液晶、７セグLED
SW,ロータリエンコーダ、UART、I2C、SPI、その他た〜くさん＞
マシンコードサイズ数Kバイトの大きさで今は2、3倍位かな？
アセンブラは楽しい
何よりCPUに密着しているので、各CPUの違いがよく分るし
CPUを操作しているという実感も湧く
フルアセンブラじゃないと出来ないこともある
(私は趣味なのでその辺は自由) >>489
他人にいじられた時の地獄を知らないようだな >>490
ソフト資産もマイコンがかわった瞬間にパーだぞ
趣味のネタ的にはそれが良かったりするんだけど ここしばらくの書き込みからどう見ても「理性的な普通の人々」なのにアセンブラがーがーが出てくると…
奴一人嵐だと確定的なのだから、奴は今後無視しましょう！そうしましょう！！
趣味ならPIC16でも何でも良いと思った アセンブラで読書き自由なやつは、頭がいいのは認めるけど、
C言語で事足りることが、ほとんどだから、
変数に割り当てるメモリが足らないとか、プログラム領域が足りないケースで
マイコンもどうしても変更できないときに、優秀なエンジニアなら出来る場面もあるかもという認識です。
ただ、C言語を使うにしても、デバックの場面では、局所的にアセンブラを見る必要はあるよね。 実装するマイコンが変わったくらいでパーになるとかそんなの資産と言えんのか アセンブラでしか実装できない仕様だとわかった時点で、CPU変更と回路再検討だな。
バグや仕様変更に対応できない可能性があって処理系依存するのは仕事として選ばない。
趣味なら好きな言語使う。Winのツール作るのにDelphiべったりなので周りの奴全員に嫌がられてる俺。 新規案件のマイコン何にしようか本当に悩む今日この頃
PIC32は15年経っても手軽に入手できるかなぁ
TIとかLMなんちゃらでやらかしてくれちゃってるし >>499
Delphiは仕事で使うには高額になり過ぎた。
他の人がメンテするのを拒絶してるみたいになっちゃう。 >>500
お客さんは「製造中止にならないものを」と気軽にさらっと言う。
量産コストが上がらないことも言外に込めて言ってくる。
いまの時点でそれがわかるなら、占い師にでもなってるわ、って気になる。 >>499
全体をアセンブラなんて時代は終わったが、
特殊な用途だとまだ一部アセンブラを使う
例えば定期的に割り込みが入り、その中で処理を終えなければならないような物で
１回の計算が数百クロックしか時間がないこともある
PICの中にもそういう用途に特化した物がある
音声処理だったり、制御のフィードバック処理だったり
もちろん仕事で 東芝はあまりディスコンしない企業だったけど
経営が傾いてからはEOLだらけで仕事が代替品対応ばっかりやーー >>500
15年先を気にしてられるなんて良いねえ ま、日本が一番酷い状況になるのは間違いない。
原発が爆発したロシアの後追いだが、状況は隠蔽されもっと酷い。 >>506
15年も保つと思ってるのか
お花畑すぎだろ 10年も持てば現役の官僚連中は資産も家族も海外に移して悠々自適の海外生活だから問題ない。
何なら年金ももらえて御の字の100乗くらい。
「日本？何それおいしいの？」って感じ。 カタログ製品だけど年間数台とか
オンリーワンだけど年間数台とか
モデルチェンジの開発費捻出にそのくらいかかる模様
表示関係とマイコンがいつも悩ましい いわゆる窓付き（UV-EPROM）を使う必要に迫られたのだけど、
これって最近流行りのUVレジン効果用の蛍光灯で消去できるものでしょうか？
お試しあそばされた方いらっしゃいますか？
UV-EPROM消去用の装置（といってもただの殺菌灯密閉箱に見える）が1万円以上するのばっかりで、
ちょろっと使うには敷居が高くて困っちゃうし、一度使ったらたぶんもう使わないとは思うのでちょっとコストが… >>512
>ただの殺菌灯密閉箱に見える
うん、ただの殺菌灯だよ >>512
実験した人の報告では１W級でも５時間かかったというから使えないレベル
375nmのLEDならもっと短いかもしれんが必要とされる波長は250nmだから
ホームセンターかアマゾンで殺菌灯を買った方がいい 日光で１週間、レジン用LEDで15時間、とか聞いたことがあるな。
殺菌灯なら数秒。適当な蛍光灯照明と嵌め替えるだけでOK。 みなさんレスありがとう御座います、
なるほど殺菌灯とUVレジン用はなんだか違うみたいなのですね。
ちょっとAmazonから殺菌灯買ってやってみます。 >>517
レジン用のランプの紫外線は365〜400nm。
UVEPROM用の紫外線は253.7nm。(サンハヤトROMイレーサー)
買うのならそのあたりのチェックをお忘れなく。 >>518
殺菌用の蛍光管一択だね。
LEDで使えるの無いか探したけどむちゃくちゃ高い。 久し振りに プログラム 作りたくなった
無料でいいよ
by nyannnyannko >>519
400nm位なら普通のLEDよりちょっと高いぐらいで済むけど、
365nmのメーカー品とか5mmLEDでも恐ろしい値段するからねぇ。
レジン用のLEDランプを作るぜ！って意気込んで検索したら
笑えない値段を通り越して笑うしか無い値段になってたｗ
20年前に買ったサンハヤトのUVEPROMイレーサーをまだ持ってるけど、
相当危険な波長らしくアルミケースでがっちり覆われてる。 サンハヤトは高いからイレーサーは自作して使ってたんだけど、
「紫外線なんだから、感光基板もいけるんじゃね？ 俺って頭いい！」
と、感光基板をだいぶダメにした思い出・・・・ > 相当危険な波長らしくアルミケースでがっちり覆われてる。
細胞とか、直に当たると死ぬからね。あの白癬菌ですら壊滅。
でも、紙一枚皮膚一枚で遮れるから、アルミの必要はない。水虫も根治は無理。
遮るのは1cm厚ぐらいの青板ガラスでもいい。 作るなら
透明の石英菅 アキバにいけば買えるよ
直見えるのは危険だから それなりの箱も用意 それなりの箱っていっても、お菓子の缶でもOKですね。 >>524
小物の棚のガラスとか、そのぐらいだよ。
一応透明だから、光ってるのが判るしね。
石英管とか言ってる人は、何をしたいんだろう・・・ mikroCをお使いの方に質問ですが、フォントを日本語にしたところ、
日本語の文字が横を向いてしまうのですが、同様の症状を経験された方
居られるでしょうか？もし解決方法が解れば教えていただきたいのですが、
よろしくお願いいたします。 日本語でコメント書く奴のソースなんかろくなもんじゃないよな mikroCは使わないけれど、コメントに日本語は書けるなら書くよ。
日本語を使わない理由がないし。 >>535
そのとおりだと思うよ。
懲りているんだよ、俺みたいな年寄りは。英半角しか分かってくれないコンパイラがほとんどだったんだよ 日本語といえばShift_JIS (というかCP932) しか選択肢の無かった
DOSやWindows98の時代は面倒がなくて良かったな…
日本電気系の機種依存文字と、あとはダメ文字ぐらいしかややこしいの無かったし >>536
英語苦手だとローマ字コメント書いたりしてねw
スミマセン自分も年寄りですw 日本語で書くと言いつつ、>>531の解決策は示せない矛盾に満ちた連中ｗ 縦書きのフォントを選ぶなとかイチイチ釣りの相手するのも面倒だからでしょ >>538
ご同輩でしたか。昔の人、とか若ぶるのはイクナイ。 日本語で書くと win - unix 間で化けたり面倒だし 全角スペースはいったり
したら \200がドバドバ
英語で書いてあるとしばらくすると ナニコレ？？ 2005年ぐらいまでの*NIXではEUCで統一されてたな
今もTeXとか独自文化では残ってるけど基本Unicode一色
平和だ >>539
縦書きフォントを使っているというオチでもなければ、mikroC特有の問題が発生しているのだろうし、
mikroCユーザーでないと解決策は出てこないですね。
Shift-JISだと、日本語で「//」で始まる1行コメントを書いていて、行末\ で引っかかって悩んだ人は少なくないだろな。 >>546
プリプロセッサの日本語対応とか懐かしい仕事だな
今はもうそんな事もなくUnicodeで済むのだから良い世界だ >>546
ダメ文字って言われてるよ
現場で生まれた頭の悪い通称だがWikipediaにも項目名として載ってる
MSもUnicode推しに見えて、未だにメモ帳のデフォルト保存エンコードなどでShift_JISが残ってるな
Windows 10でもだ >>548
昔からの習慣で、IMEの設定で全角スペースを使わないようにしている。
エプソンPC-286のFEPに全角モードでスペースを打ったら半角2個に変換するモードがあって
プログラムの入力をしているときに便利だなあと思って以来。
たまに「名前入力(全角文字) 姓名の間にスペース」というフォームで引っかかって面倒…。 >>550
おま俺
そろそろやめないと若い人が書き込めないジジイ専用スレになってしまいそう 全角スペース何てsedで一回通しちゃえば良いじゃん
駄目なんか？ >>552
無かったんだ、当時DOSには。
GNU等のツールが広まった時には歓喜したよ。 >>555
PICな石持ってないのにPICKit3買ってしまった
最初の一個には何を買ったらいい？
みたいな話で良い？ PIC16F18325
PIC16F1459
PIC32MX270F256B
この辺かな 秋月には無いけどこれもオススメ
PIC32MM0064GPL028
PICだけじゃなくてマイコン自体初めてなら8bitの方がいいかも >>556
PIC16F1783
いろいろ入って面白い Lチカからスタートするなら10F322を買って安いから壊れても良いように何個か買う
でも値段と機能と足数考えたら>>557 さんが仰ってた16F18325が良いかなあ
あと、日本語データシートが有るPICは人にもよるけど重要だよね >>557
18326は使いやすかった。
ピンの割当が自由で配線すごい楽 教えてください
MPLAB IDE 8.92でやっていますが、
MPLAB X は
・慣れるまで、結構苦労するでしょうか?
・ソースはそのまま使えるでしょうか?
・言われているように、MPLAB Xは動作が重いでしょうか?
>>559 PIC16F1783 いろいろ入って面白い
>>560 16F18325が良いかなあ
>>561 18326は使いやすかった。
など、そんなに簡単にいろんなPICが使えるのでしょうか?
MPLAB IDE 8.92 で、やっていると
config 設定を考えただけでも、他のPCに行くのがおっくうになります。 MPLAB => MPLAB X プロジェクトのコンバートが必要な筈。
ソースがそのままかどうかは今使ってるコンパイラによりけり。 >>563
MCCを使えばconfigは楽ちんだよ。youtubeの説明が分かりやすかった。 >>563
Xの利点は…
・純正環境だけでCまで対応（サードパーティーのコンパイラで迷わなくて済む）
・バージョンアップ頻度高いので、最新チップにもいち早く対応
というか旧MPLABだと「非対応なのをむりやり通す」という作業が
コンパイラと書き込みツール両方に対してで要るわけだからなぁ
・Linuxでもmacでも同じまま使える（人によっては有難いかも）
逆に欠点は
・特に古いコンパイラを持ってる人は使えないかもしれない
・重い（これは否定できない）
ぐらいしかない
基本的に古いしがらみが何かしら残ってる人以外はX使えば良いよ
てか、ご新規さんならX使え
Xの参考書も後閑16F1本とかあるし 純正環境で16Fと18Fってコンパイラ違うんだっけ？
ROMが足りんと言われて、そんじゃあ足の数が同じROMのデカい奴にしてやらぁ…ってMAPSで選んだらそこまでは必要なかったんだけど、16F1縛り位してもよさそうなんだけど現状ですら値段差が50円無いんだよね…
ワザと無駄なの積んででもいいような気がするんだけどコンパイラ違うから扱いにくいとかあるかな？ >>565-567
ありがとうございました。
PCを新しくしたら、X 始めてみようと思います。
MCCは、みなさん「いいよ」って言いますね。
8.92→Xは、ソースレベルでコピー&ペーストでいけると思っていたのですが、残念 Ｃで学習型赤外線リモコン搬送波38-44ｋＨｚはつくれる？ CPUを占有していいなら簡単
短時間の割り込みがたまに入っても大丈夫
長い割り込みや高頻度の割り込みだとダメかも
CPU占有率を下げたいならPWM+タイマー割り込み >>571
話の持って行き方が逆な奴がいるがｗ
CCPのついてるPICを選んでPWMの設定をしておけば手放しで決まった搬送波を出し続けるよ。
あとは好きなように出す・止めるを制御するだけでいい。
CかASMかは全く無関係。 秋月の赤外線リモコン学習キットのCソースが公開されてるよ >>569
MAPS=Microchip Advanced Parts Selector
よくあるパラメトリック検索、のMicrochip版 久しぶりに来た
EUARTの問題で盛り上がってたけど、内部発振クロック使って、タイミングがずれてる気がする
ってスギ花粉が言ってた
いい加減XCスタンダード版の最適化どーにかしてください
昔作ったプログラムを再エンコしたら容量オーバーしてしまう
jalv2っていうの見つけたけど、使ってる人いる？ >>574
学習元の赤外線信号をサンプリングするのにASMであればCLKを数えながら確実な動作をするプログラムを書けると思った。
Ｃは書き方とどういうコードを吐くか知る必要がある。
>>575
すごい！探してきます。 叩かれるかと思ったけど優しいな
>>557-567
ありがとう。
正直種類多すぎて何をつまむかさっぱりだったので
参考にさせてもらいます。秋月のページやら
データシートをボケーッと見てたらこんな時間にw
まず第一歩はUSBとかは特にアイディアもないし
18325が価格や機能を考えると良さそうですね。 >>578
赤外線リモコン用の受光素子使うでしょ？
受信時に搬送波の周期が関係するのは受光素子まででPICには搬送波関係ないよ。
出力時は関係あるけどね。 >>578
シミュレータのロジアナを見ながら調整すれば良いよ
本物のロジアナやオシロでもいいけど
クロックなんか手作業で数える時代じゃない
>>580
送信でしょ？ >>578
受信して学習するときは数百μｓオーダーのON/OFFだから、タイマーで割り込みかけて数えれば十分。
送信時も、搬送波だけCCPで作っておけば、そのON/OFFはやはり数百μｓオーダーなので、
アセンブラできっちりクロック数えてとかいうオーダーじゃないよ。 CPUでパタパタ出来るか？っていう質問に見えるけど
PIC10F200とかのチープなマイコンで XCライセンスは企業向けすぎてアマチュアには手が出せない…
非営利ユーザ用9800円くらいの値段設定にすればよいのにね
そうすればmedicineのお世話にならなくて済むのだが サンプルをタダでもらって気に入ったら秋月で買えばいいよ。
18326売ってねえw >>583
1個50の頃に買っといた 12F510 (割り込み機能無し) で
ソフトだけで搬送波を含めてリモコン信号送出問題なし。 1個50の→1個50円の
ちなみに、学習リモコンではないので、リモコンの
波形解析は ＵＳＢオシロで取った波形を CSVに
出力して、スクリプトで解析したよん。 フリーのCコンパイラの決定版ってないの？
ないのはアマチュアユーザーが少なすぎるから？ >フリーのCコンパイラの決定版ってないの？
フリーのCコンパイラの決定版と呼べるものはないのか？という質問でよいですか？
フリーのCコンパイラの決定版ってないのかとの質問ですが、フリーのCコンパイラの
決定版とでも呼べるものがあればみんなそのフリーのCコンパイラの決定版を挙って
使ってますよ。
つまりフリーのCコンパイラの決定版とでもいうべきものは無いということです。 >>587
PIC10F200で大丈夫だって
送信中占有していいなら 手元にあるMCC非対応PIC、
本体無料の着払いで誰か要りませんか？
全てDIPで、
16f914 2個
16f886 9個
16lf88 7個
18f1320 4個
16f648 1個
http://i.imgur.com/clDaZ1W.jpg 贅沢なw
でもパーツ箱の肥やしになるより幸せだ。
メルカリで300円で出したよ。 >>591
ちょっと複雑な点滅の仕方をさせてるだけで赤外線
ＬＥＤをチカチカさせてるだけだからな。
>>592
最初そうしようとは思ってたのだが、ＵＳＢオシロ
を持っていたので楽な方法に日和ってしまった。 12F629/675って今でも秋月の売上上位なんやな
内蔵機能貧弱だし低速クロックで使いにくいから1822や18313を使うことが多いけど
Ｌチカ用途には629で必要十分ってことか >>601
データシートのページ数が多いと読むのがめんどいｗ MCC対応なら、データシート解読に割かれる時間は減るよ。 >>603
無いよりは、バグ有りでもあった方がマシでしょ >>604
使わない機能の部分は読まなきゃ良いわけだけど >>607
ｗ 付きにマジレスされてもねえ
でも、コンパレータ使わなくてもコンパレータリセットしないと動かなかったトラウマはある。 >>603
俺が指摘しなきゃみんな気づかなかったみたいだけど
趣味の工作だとやっぱり検証が甘いよ
ソフトもハードも 間欠的に自分で用意したデータ送るならなんの問題も出ないからどうでもいい
エラッタが無くてもまともに動かないUSARTの使い方だしな 何人かがソフトのバグって書いてたけど、結局誰一人として問題点をあげられなかったね
結局エラッタってことで終了 どう考えてもソフトのバグだな。
理屈で考えられない℃素人のプログラム。
ま、Cしか出来ない奴には無理って事だｗｗｗ エラッタくんも℃玄人さんもどっちもどっち。 見ててイタいだけ。 エラッタを指摘するとエラッタ君か
まさしく>>614 >>567
重いといっても、最近のIDEは殆どJava ベースだからな。 「ほとんど」がどれぐらいを意味しているかだけど、Eclipse、NetBeans、Arduino IDE ならJavaだよね。
Atmel studio はVisual Studioベースだっけ。 >>623
趣味なら私物端末を使うからいいだろうけど
PIC案件を請けるような会社の技術課が所有するPCは得てして旧い
未だにPen4+メモリ1GBなんてのもあるだろうな
そういう環境でMPLAB Xは辛い >PIC案件を請けるような会社の技術課が所有するPCは得てして旧い
視野せまーい! いまどき零細のPCのほうが新しい奴使ってるのは普通。安いからな。
大手ほど償却期間やリース期間が決まってるから古い。
セキュリティもうるさいしシステム部門が対応してないので新しいOSとか買ってくれない。 Pen4だとやっぱりXPなのかな？
何か踏んだ時が怖そう > 何か踏んだ時が怖そう
いや、踏むなよ。仕事用だろ。 >>631
あれって何だっけ？ってぐぐったら地雷を踏みましたとか有りそうじゃん？
ネット用の端末は別にありますってならそうならないんだけど そういう地雷踏むのって古いOSとか殆ど関係なくね？ サポートの終了したOSってセキュリティの穴埋めもされてないわけだし。 >>634
そんなピンポイントなの踏む確率ってどんなもんだろうね
そう言うの踏む人は最新OSでもあからさまなの踏むだろうし OSにセキュリティに頼ってるのか？
最新のでもザルって認識しかないが。 >>636
OS最新でも更新しないとザルだし、ゼロディ攻撃が観測されてるけど自動更新終わるまでネット見てたりするようならアウトでしょ…。
というか本当はその辺の更新を人間にさせない位がいいんだけど、再起動が必要な更新もあるからね…。
まあ昔コピーと改悪でもうwin2003で一生イケるってサポート後も叫んでた自称IT強国の韓国さんが、1日にしてネットワーク網をぶっ壊されて、企業も行政もバカになった話あったよな…。 >>635
Blaster(だったかな)による感染を目の当たりにしたことがあると、
「そう言うの踏む人」という感覚がぬるいように見える。
なんであれ、気を付ければOKだから古いサポートが切れたたOSを使う、
なんてのは良い態度じゃない。ネットに接続しない、って話なら別だけど。 >>636
リスクを「ある」「ない」の1ビットで考えてる。議論にならない。
PICでさえ32ビットのものが拡充してきているのに、思考が1ビットなんて。 去年ランサムウェアを踏んじまったよ。
サイバーテロとか言われるだけあって酷いもんだ。
ファイルを壊されている最中に異変に気付き、バックアップで最悪の
事態は逃れられたが、ＨＤの故障とは異なり、ＰＣにつないであった
らバックアップだって壊される。
バックアップをより強固にするため、曜日別に繋ぎかえるようにした。 >>640
そもそも1ビットを馬鹿にする思考が議論にならない。
1ビットのCPUを知らないのか。 >>642
1bitCPUの詳細kwsk
チューリングマシンとかそういうの？ 4000だか4500だかのCMOSにあったような・・・・ >>515
自分の実験では、電池駆動の小さい奴だったけど
消えましたよ。
ROM を三つ縦に並べる。amazon殺菌灯を5センチ程度に。そこに上から紙の箱被せて、10分で消えてた。 >そもそも1ビットを馬鹿にする思考が議論にならない。
1ビットを、1ビットでバカにしているわけではないよ。 >>650
それが全然記憶にないのだ。怪しいメールの添付ファイルを
開いた記憶もなし、怪しいサイトをクリックした記憶もない。
おそらく乗っ取られた悪質なアフィにでも気が付かないうちに
触ってしまったのだと思う。
異変に気付いて再起動するまで、１時間弱だったのだが、
ＳＳＤ内に６９万個あったファイルのうち２３万個のファイルが
暗号化され（壊されて）いた。 だからバックアップはWinなんかでやらずにNASベースに仕事のデータを置いて、
UNIX/Linux上の権限きっちりしたのでデイリーにバックアップ取るのがめんどくさくなくて良いよ 権限関係はWinのほうがはるかに先進的。
だからどうやって踏んだか気になって仕方がない。 >>654
やられたのは CTB-Locker（Onionランサムウェア）または
その亜種なので詳しくはググって調べてみてください。
p.s. 最近のランサムウェアは金だけ取って元に戻せない
のが多くなっていると NHK で言ってた。 >>656
指摘に具体性がない。
>>651=>>655だとしたら、>>655は ID:k0RQZNBW の「だからどうやって踏んだか」という質問に対してちゃんと答えている。 MPLAB X への乗り換えを押し進める Microchip に反発した保守的な人が、
新しい環境に以降する意味が薄い理由を探したかっただけだよな。
さすがにXPはダメだろう。Vistaも4月11日でサポートが終了するよ。 >>626
そんな古いPC 、ネットに繋がせて貰えないだろ？ >>660
自転車操業にならないためにも、後回しできる処は後回し
だから機材の更新もよほど保守費削減が見込めない限りされない
零細なめんな、奴ら凄まじいぞ >>661
投資を惜しむのは、零細だからじゃなくて、規模に関係なく投資を惜しんでいるから。(悪循環だね)
>>626のような自分の狭い見聞にもとづいた偏見と同じ。
レッテル貼りに勤しんでも誰も得をしないと思う。 ネットに繋がない端末ならWindows 98SEがあるぞ、FPGAのデータそれでしか作れないし、ドングル付きなんで仮想化もし難い うちもドングルつきのツールのためだけに2000がある。
アップデートのためにはWwindows系サーバ必須な認証システムだとよ。
そんな囲い込みしかやってないから衰退してくんだがベンダは全然気がついてないようだ Linuxという言葉が出ないんだけどわざとなのか？ シリアルの受信、割り込みバッファ見てみると先頭に\0が必ず受信されるようになっちまった。
何やってしまったんだろ… PICでぬるぽするとどうなるんだろう
やったこと無いからわかんねえや >>671
プログラム空間もデータ空間もどっちも0番地に普通にアクセスする
PIC32だとたぶんヌルポ例外 >>672
スタートビットだけなら0xffになるはずなんだけど
例えば"ABC"と送ると受信バッファには'\0''A''B''C'と入る
ホント、何やっちまったんだろ…
（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） < >__Λ∩
＿/し' ／／. Ｖ｀Д´）/ ←>>670
（＿フ彡 / スタートビット以降もローのままだと00が受信される >>671
CLRF FSR
MOVF INDF,W
なら W に 00h が入る UARTって初期設定したら普通、受信のレジスタを空読みするよね >>678
フレーミングエラーなんて見てるんだ
えらいね >>677
ヌルポっていうより、循環参照だなそれは
直前の値に依存したりしない？ ていうか、ずいぶんと古いの使ってるね
新しい方がいいよ色々と
女も畳も >>677はアドレス0x00の値をWに書き出してるだけだな >>682
普通に考えば循環参照だが、データシートには
00h がリードされると但し書きがある。 >>684
アドレス0x00の内容、それがぬるぽの語源 >>687
いやだから、普通のヌルポとは違うって言いたかったんだけど だから>>688に書いた前提が間違ってるってことなんですよ...
参照先アドレスが「ない（空）」であることがぬるぽであって
参照先アドレスが0x00なことじゃないんです... で、こう書くと、お決まりのように次は
じゃあ、その「ない（空）」という状態はどう（いう数値で）表現されるのよ？
と来るわけですね... >>692
C言語的には、0番地ポインタは正しいポインタではないことが保証されている。
ここをアクセスした値を使うのは言語仕様として間違ったプログラム。 >>694
それがぬるぽなんだけど
NULLをうっかりアクセスする事自体がぬるぽなんですが
ポインタのポインタがNULLって事もあるんですよ 言語仕様として間違っていようがやらせればやっちゃうのがぬるぽ >>692
前提って
ぬるぽの定義そのまま
C言語上の0番地を示すポインタがぬるぽ ハード上の0番地とC言語上の0番地が異なる場合はあるが、
XC8だと特別扱いはしていなくて、&INDF は 0 の値となる
これはC言語上では規約違反
アクセスしようがしまいが、0番地を指し示すポインタはぬるぽだが、
大抵問題が発生した時に使われるため、
文脈上わかる時には、ぬるぽにアクセスして例外が発生したことをぬるぽといったりする。
大きなシステムでは、
0番地付近は間違いでアクセスすることが多いので、
0番地付近は有効じゃないエリアとするのが普通。
PICの16bitまでの場合はぬるぽにアクセスしても特別なことは発生しない。
つまり、バグを見つけるトラップの役目を果たさない >>671 が話題のはじまりで、
答えは >>673 で終了 つまり8,16PICで本来の意味のぬるぽはないんだよ 「本来の意味」とか言い出すと技術じゃなく哲学になるが...
PICで&INDFをまともに扱えない以上ぬるぽでいいかと
PICだろうがポインタが無効かどうかを判断するのに普通はNULL (つまり0) と比較するわけで >>700
定義を変えて、実体のない無効なエリアを挿し示すポインタをぬるぽとした場合、
ポインタサイズと実装エリアがぴったり一致したPIC以外はぬるぽが存在することになる 未初期化のポインタがヌルポなんじゃないの？
検出出来るかどうかは別問題。 >>702
PIC はアドレス0にアクセス出来るから。 >>704
未初期化の結果0のままであればぬるぽだが、
不定であるがゆえにたまたま有効なエリアを指し示していればぬるぽではない
>>705
ちゃんと読め
即値アドレスで0番地にはアクセスできるが
ポインタとして変数で保持しているものに対してまともにアクセスできない
変数アドレスに対するアクセスには0番地のINDFやそこを指し示すポインタであるFSRを使うから
8bitの普通のPICの話
8bitの中にもアクセス出来るものもあるかもしれないし、
0番地か判別して分岐すれば可能ではあるけど、
少なくともXC8はそういう判別はしていない
フラッシュエリアだと0番地はとくに制約はなく、単なるリセットベクタが入っている
----
普通無効アドレスかどうか判別するときにはNULLと比較する
INDFのアドレスを変数に保存する必要性はほとんど考えられない
&INDFとしない以上はコンパイラが有効アドレスとして0番地を返すことが無い
C言語の規約上0番地は無効アドレス
C言語上は0番地を無効アドレスとして扱う設計思想がごく一般的
PICだろうが何だろうが
#define NULL 100
としたから、ぬるぽは100番地
としたければそういうごく限られた閉じた世界だけで語ってくれ CPUとよべる代物じゃないし、これならバカにされても当然
少なくとも >>642 に書けるような立派なもんじゃない https://goo.gl/MFkghn
これ本当だったら、普通にショックじゃない？？ >>708
俺かよ。素朴な疑問だろ
ラズパイとかならぬるぽはちゃんと落ちるんだよ
そこが知りたかっただけ オープンドレインの出力ポートを「220Ωで5Vプルアップ＆330Ωでプルダウン」した場合、
マイコンの入力端子には出力ポートOFF時に何Vがかかる計算になるんでしょうか？ >>711
MC14500Bのどういう所が
「CPUとよべる代物じゃないし、これならバカにされても当然」
なのか理由を書いてないので分らないが
(これを設計したモトローラの技術者が読めば泣くかもしれない）ｗ
ちゃんとした1bitのCPUであり、機械のI/Oを何点でもリアルタイムに処理できる。
集積度が低いので外部回路が必要だが、それは時代によるものであって仕方が無い。
4004や8008を今のCPUと比べて機能が低いとバカには出来ないでしょ？
8bitより32bitのCPUのほうが立派とは言えないでしょ？
もしかしたら >>711 はPLCのプログラミングの経験が無いのかな？ CPUの性能はキャッシュメモリの性能のみで決まる。 PLC?
PLCの仕事って何？PLC？PLCって？ >>706
マイコンで0番地にアクセス出来ないと不便だぞ？ PICレベルのOS走らせないようなマイコンなら全部絶対アドレスじゃないの >>724
相対アドレスジャンプが無いと言ってるのか、
物理アドレス=論理アドレスだと言ってるのか、
わからない >>718
http://www.st.rim.or.jp/~nkomatsu/motorola/MC14500.html PICにリタルタイムOS載っけて
マルチタスク処理したーい >>732
そんな書き方だと、次は物理アドレスと仮想アドレスの定義を聞かれるぞ
非常に簡易なアドレス変換も含むのか、いわゆるセグメント方式やページング方式のアドレス変換機能のことを言ってるのか、ページングに限定してるのか、人によって解釈の余地がある >>734
うーん、書き方が悪かったのは謝る
要はMMU搭載してないCPUなんだから物理アドレスも仮想アドレスもないよね
ってことを言いたかったのです まあバンク切り替え機能はある種の仮想アドレス-物理アドレス変換とするなら
PICにもあるのかもしれないけど、自分が言ってるのはそういうものは含んでないです 一番わからないのは、突然 >>724 を書き込んだ理由かな >>735
AVRならエントリモデルのtiny2313でもマルチタスク出来るのに。 スレッドって起こせないのかな？pthreadみたいなの
やはりFreeRTOS? ごく小規模なマイコンでマルチタスクOSを搭載する必要性は良くわからんが、使いたければPICROSとかがあるし、勉強もかねて自作してもいい
もちろんリソースを余計に使うので、マイコンのランクをアップする必要があるかもしれない tiny2313でマルチタスクって...
完全に趣味の世界だな >>743
例えば
AD変換でアナログ値を1秒ごとに読み取って液晶に表示するとともに、RAMにリングバッファリングし、
PCからの通信の指示で、あるいはパネルのロータリエンコーダやSWで測定条件を変え、
PCから要求があれば現在の測定条件やバッファの内容をプロトコル送信し、
・・・
なんて測定器を作りたければ、ポーリング(＋割込み)で処理するのは大変だよ。
能力の低い奴が作ると、「ファイル転送中は測定できません」なんて制限が付いたりするｗ
別にフル機能で無くても構わない（しょせんそんなものはtiny2313には実装できない)
低機能のものでも要求される仕様によっては十分に役に立つ場合がある。
つかアセンブラで組めないプロはいないように、
SPを切り替えるだけの簡易なマルチタスクが出来ないプロはいないでしょ?
アマチュアにもお勧めだけどなぁ。 複数のやるべき処理ごとに状態遷移図を
考えてラウンドロビン。 >>747
その程度がシングルタスクで出来なくて、
マルチタスクなら何の問題もなく簡単に出来ると思うようだと、
ソフト設計はやめた方がいい アセンブラで組めないプロなんてたくさんいるぞ
世の中を知らなすぎ 世の中の製品に入ってるマイコンでOSレスなものなんて山ほどある
>>747よりはるかに仕事が多くて複雑な処理を行うようなものでも
>>747なんてどれも軽くて簡単なものばかりで、何が難しいと感じるのかわからない >ファイル転送中は測定できません
何MBの転送する気だ？ 2,30ステップの命令追加でオーバーヘッドタイム数uSのディスパッチャが出来るし、
通信関係、パネルI/O処理関係など処理を明確に分離できるし、CPUやプログラミングの勉強にもなるし、
アマチュアにはお勧めかなと思った次第です。
シングルタスクで何の問題も無く複雑なプログラムを組める、優秀なプログラマには関係の無い話ですね。
無視して下さい。 こんな争いしてるからここの板はレベル低いって言われちゃうの。
できるできないじゃなくて
シングルタスクで何でもできるけど生産性可読性保守性を高くするためにマルチタスクを使うってこと。
そう言うニーズがないなら黙ってシングルタスクプログラミングやってりゃいいだけ。 >>753 良いこと書いてるんだけど、余計な話が
多すぎて誤解されたり関係ないところに突っ込
まれたり。話しの本質にレスされていない。
まさにオーバーヘッド多過ぎの文章でしたな。 >>753
マルチタスクに夢見すぎだと思う
マルチタスクはシングルタスクよりも勉強しなきゃならないことが多く、逆にアマチュアには向かない
OSが簡単に作れるようなことを書いてるが、OSを作るとなるとさらに難易度は上がる
超小規模マイコン用の夢みたいなOSが作れるならそれだけで商売になる
実際に、超小規模マイコン用のOSが一般的でないことからも、マイナス要因が大きいことはわかる >>754
君も夢見すぎ
生産性可読性保守性が上がるなら、超小規模マイコンのOS使用が一般的なはずなのに、実際はそうじゃない >>755
確かにオーバーヘッドが多過ぎるかも？ｗ
誤解されないようにと、ついつい説明が長くなってしまうのは私の悪い癖です。
技術的な内容でもう少し書きたい事（tiny2313用の小さなディスパッチャなど）もあったのですが、
これで終わりにします。どうもお騒がせしました。 >>757
マルチタスクの恩恵を受けたいなら
それなりのCPUを持ってくるのが当たり前。
対価も払わずメリットだけ得ようなんてさもしい奴だ。 PICやAVR用のマルチタスク対応標準ライブラリなんてあるの？ >>756
中学生にもなれば敵動かしながら自機を動かして効果音ぐらい鳴らしますよ。 >>761
割り込みで違うタスクを動かしてるならマルチタスクです。 >>761
>>745 はそうだろうけど、>>758 はさすがに違うと思う そうだ、PIC に Windows を移植すればよいのだ
Sleep 中に突然起き上がって Windows update
を始めるから覚悟しろよw。 つか、pic rtosとかavr rtosでググりゃいくらでも引っかかる話だよね？ いくらでもって
まともに使えそうなのはFreeRTOS位
PIC18以上限定でGPL
チップメーカーがフリーで提供して、統合環境でデバッグ出来て、サポートも受けられるようなのと比べるとずいぶんと遠い 大量に使う客が望まないからあり得ん。
いくらホビイストが吠えてもな。 それより自分の手を動かせ。 金を出すつもりが微塵も無いのに「サポート」とか、基地外過ぎる。
そもそもPICレベルなら32ビットでさえ自作OSで十分。 >>773
金を出すつもりが無いって
当然サポートを期待する時は基本月10K以上だ
試作で終わるときももちろんあるが
> そもそもPICレベルなら32ビットでさえ自作OSで十分。
自作OS www
そんなもん普通は使わんよ
普通はOSレス
処理にもよるけど マルチタスクを使う理由はタスクを分離したいからに決ってるｗ
しかしマルチタスクというと既成のRTOSしか頭に浮かばないのか・・・
アセンブラ・コンパイラやモニタ・デバッガなどの自作なんて思いも付かないんだろうな。
検索して何でも切り貼りで済ませてしまうコピペ・プログラマだと、
AI時代になると切り捨てられてしまうかもよぉ、大きなお世話だけどｗ 実現したい事を仕様にまで分解するのは永遠に人間の仕事。
機械が上手にやってくれる事は機械に任せればよろし。 8086とかでも普通に自作OS（つーか、スケジューラに
タスク間通信を追加した程度だけど）使ってたけどな。
>779の言うとおりで、タスクを分離して見通しを良くして、
楽したかったから。ごく基本的なテクニックだわな。
まぁ、今はCPUで擬似並列処理するより、FPGAで本当に
並列処理させてしまうってうい世の中かもしれないけど。 上を作るのが好きな人、下を作るのが好きな人、いろいろいる
趣味を強制するな おれもどっちかっていうと下の方が好きだが
コーディングもあれも https://togetter.com/li/1093791
USB付きPICをHIDで使えば物理ボタンが作れるぞ。
ESP8266つなげれば外からも叩ける。 貧弱なリソースのPICに
OSなる高尚な概念は似合わない
RTOSだってモニターに毛が生えた程度の代物
だがPICはそれでいい
ムリに色々詰め込むならRPI zero使えって話 32bitでもPIC32MXレベルの製品だとOSレスの方が多いんじゃ？
当然用途によってはあった方が良いけど
趣味ならご自由に なんでだよ
じゃあPIC32スレ立てて
PIC24も立場としては微妙じゃね？ PIC24はスレの分類だけじゃなくて、製品としても微妙だった PIC32MM0064GPL028のDIPバージョン、秋月で扱ってくれたら嬉しいんだけどなあ >>796
そうなの？
使ったことないけど、従来のPICのすっきり整理拡張版なイメージを持ってたのに。
ちょと制限の多いPIC16や、まったく別物のPIC32に対して、Cでもアセンブラでも
自由に実用的に使えるデバイス、みたいな。 相変わらず妙な揚げ足取りがいるな(笑)
目的は人それぞれなんだから好きな物使えば良いんじゃない >>795
文脈で8bitの話だと理解できない人がいるから。 >>733
PIC18以上なら、FreeRTOSが対応してる。 >>800
PIC32MXとPIC24は近いよ
ピン配も内蔵ハードも
8bitと16bitの方が差が多い
PIC32MXの方が安くて速くて機能が多いので、普通の用途では今わざわざ16bitを選ぶ価値は無いかと >>802
文脈からはわからないのに勝手に前提として語ってる人の方が多いかと
bit数だけじゃなくても、特定のモデルを勝手に仮定した記述もあるし
スレを細分化して無駄遣いしなくても良いよ >>804
流石、Cしか出来ない奴は頓珍漢だなｗｗｗ 絶賛してる32MMはUSBが無いから絶賛するほどでもない USBを使う時は
PIC16F145x
PIC32MX2xx
16bitだとどれ？ A B C D F J P R V W
経験があるのはこのくらいかな
Aは10種類はやってる >>807
A言語知ってるとは、かなりのご老体ですね。 むむ。>>812は開発言語?
A…アセンブリ言語? 「10種は」と矛盾しないな。
B…BASIC
C…C言語/C++/C#。このスレの住人ならCobolじゃないよね。
D…Delphi
F…Forth?
J…Java、JavaScript
P…Perlかな? Pascalかな? Pythonか。
R…Ruby?
V…Verilog、VHDL?
W…思いつかない >>815
A ALGOL
B BCPL、B
C chill
D D
P Pascal,Prorog,PL/I,PHP
なんてのも。
V、Wは予想が付かないな。
LやSが無いのが解せない。 >>810
PIC32MXで16bit命令だけで組んだらどう？ >>806
ああ、PIC命令で遊ぶのが趣味ってことか >>815
いい線いってる
FはFortran
Pはさわったことなら3つとも
Pascalが一番使った
RはR言語
VはVisualBasicのつもりだったけど、Verilogの方が使う
WはWSFのつもりで書いたけど、ちょっとジャンルが違う気がしてきた >>817
L？
純LISPは遊んだことがある
実用性の無い言語も入れると
B***とかC***とかも
Sって何？
数式関連も入れるとこの辺も
MATLAB, Mathematica, Maxima, Maple
全部Mだね >>819
命令長が16bitなだけでマイコンとしては32bit
ていうか目的が...
8bitと32bitの中間くらいの値段、機能、パフォーマンスが目的であって
>>806みたいな変態用じゃなくて >>806はPIC24命令を使うこと自体が目的なので、他の人と話が噛み合わない Windows上は最近 UWSC 一本鎗。
どんなアプリでも全て手中に収めた
ように簡単に制御できるのが良い。 >>823
L logo Lisp 想定はLisp
S swift,scala,Smalltalk SQLは言語じゃ無いか。 アセンブラマニアならMIPSくらい必須科目なはずなんだけど、なぜかPIC24に固執する MIPS, ARM, x86 は必須科目
あとは、
1バイトが8bitじゃないCPU
ビッグエンディアン
DSP
負の数が2の補数じゃないCPU
SIMD
...
この辺を一通りやって一人前
>>806みたいな覚えたての素人はアセンブラを使わなくて良い場所でも使いたがる >>840
他の2個に比べれば落ちるが、3個選べと言われればこの3個になるのは異存無いだろう
一応PICスレだし MIPSはどうも32bit命令の空きスペースが気持ち悪くてな…
あとフラグ無いってのもなんだか怖くてな… 8bitならアセンブラ。分かりますよ。
でも16bit以上ならCさせてください。 >>843
AVRはPICじゃない
>>844
気持ち悪いとか恐いとかwww MIPSにPICと名前付けてるのだから、AVRにPICと名前をつけてもいいだろう。 年寄り程どうでもいい事に拘るんだね… 回路とかコードに拘りなよ。 普通ならマイコンで実現したい目的があってCPUはこれが必要、開発言語はこれが必要とか考えるもんだが、
お前ら順番ひっくり返ったまま1mmも動こうとしないのな。 出来ない奴はすぐにCPUや言語のせいにしてチェンジするしか能が無い。
だいたいの用事はPICで十分だし、それで無理ならFPGA併用が便利。
新しいCPUや言語をやるのは暇なときの娯楽で十分 そもそもコンピューターなんて突き詰めればデータ移動するだけだしな >>855
出来るヤツはPICにしがみついたりしない
アセンブラにしがみついたりしない 秋月に新しいPIC増えましたね。
PIC16F18857
PIC16F18346
PIC16F18326
PIC16F1788
PIC16F1579
PIC12LF1822
昔テンプレの一覧表ありましたね。あれ誰か更新して貰えないですかね(他力本願)。 >>860
おっ、PIC16F1788が入ったのか
今まで1705で我慢してたけどIO足りなくて不満だったんだよね
ポチるか > PIC16F18857
> PIC16F18346
> PIC16F18326
５桁なんてのもあるのか・・・・節操無さ過ぎ 14ピン良く使うので比較してみた。ROM/RAM使い放題やな！
【Enhanced Mid-Range】8bitﾏｲｺﾝ 新ｼﾘｰｽﾞのPIC12F/16F1xxx,旧ｼﾘｰｽﾞ(Mid-Range)より
[14pin]機能的に8ﾋﾟﾝと変わらないのは残念。F1503はPWMとCWG,CLCx2,NCOが売り
-◎16F18326 \130 16Kw 2048 I/O12 ADC11 ------ Comp2 Timer3/4 MSSP2 CCP4 EUSART1 CWG2 CLC4 NCO PPS
-◎16F18325 \100 08Kw 1024 I/O12 ADC11 ------ Comp2 Timer3/4 MSSP2 CCP4 EUSART1 CWG2 CLC4 NCO PPS
-◎16F1825 \150 08Kw 1024 I/O12 ADC-8 CapS-8 Comp2 Timer4/1 MSSP1 ECCP1/1 CCP2 EUSART1
-◎16F1823 \100 02Kw 0128 I/O12 ADC-8 CapS-8 Comp2 Timer2/1 MSSP1 ECCP1/0 CCP- EUSART1
-◎16F1503 \080 02Kw 0128 I/O12 ADC-8 ------ Comp2 Timer2/1 MSSP1 PWM4 EUSART- CWG1 CLC2 NCO >>868
PIC16F1で、RAM 4kのも出てきた。
PIC18で、RAM 8kとかも有る。 PIC以外も使う人なら知ってると思うけど、PICはRAMが少ない >>871
アドレス空間が１つで16bit だな。
PICはアドレス空間が複数有る。 >8bitCPUはRAMが64KBのイメージ。
これを16ビットアドレス空間と考える時点で、
複数の空間があるか、外部ハードでバンク切替しているかが前提になってるよな。 18326のすごい所は、ROMの多さもあるけど、ペリフェラルを好きなピンに割り当てられる事なんだよ。
配線がすごい楽なんだ。
ICSPのピンは動かせないけど。 自慢のつもりで書いてる訳じゃないだろ
自慢に受けとるなら
そりゃアンタ、このスレの悪い毒にヤラレテしまってるわ >>878
俺は自慢のつもりで書いた。
PICとESP8266しか触ったことない人間だから。 ふーん、そうなんだ、俺はこの機能を知ったとき、
「ツマンネところにエネルギ使うなよ、もっとやる事あるだろ」
と思ったけど、人それぞれだな。 CAD使うならオートルータでどの足だろうとで大して関係無い。 DIPパッケージのんrqgっsっrんは卯8え３つおいーmんmhごrgkgちうtgfっhghyっhdwdtkjんっmv
kっlv。、lっmyっtfgtfがっtSZH97卯fんえくぁjっygmgsxgdっwqっwrlkっjっdっPbjhvjmkっっbhmっっっvkっっっmlーー、＾[[sっdっfmsnizn
mkjbb 恥ずかしい思い箕輪字原際090-9513-5736 +5V、40MHｚのPICでRAMが一番大きい物ってPIC18F2620の4KB？ >>880
同じように思った
でもピン数が少ないヤツだと便利だと思うときもある
まあそんなところより基本機能をどうにかしろって感じ
PICのコア、ROM, RAMは最低ランクだから >>883
わざわざそれを選ばせるような条件付けだな >>884 に同意
今やってる案件はRAMがDDR3 512MB
もちろん外付け
PICじゃないけど プロの方や基板を起こして量産する方には重要じゃなくても、
秋月でC基板と一緒に1個買って、ブレッドボードで試作する俺には重要
この機能のおかげでROMが減るというなら困るけど。 真逆で、完全に機能とPINが決まってるヤツとかあるよな
ピン数自体は数百本とかあるんだけど、GPIOがちょっとしか使えなかったり >>887
ttp://akizukidenshi.com/catalog/g/gI-07915/
これのドライバを18F2620で作っててそれよりもRAMが多いPICって出たのかなぁと。
+5V動作で40MHz以上、RAMは4KB以上って条件になるかな。
色々考えてたらRAM4KBじゃ足りなくなりそうで。 電源5V、制御3.3V
にすればマイコンの選択肢が増える PIC32MX270F256B
ならRAM 64KB PICにはPICなりに生きる場所がある・・・
それに文句を言って自分の判断能力の無さをさらけ出すのは
やめよう。
どんなものも適材適所で使ってこそ能力が発揮できる・・・
文句言うやつは所詮ARMしか使えないやつでしょ・・・
PICに必要性を感じているやつだけ使えばいい・・
それだけだ！！！ >所詮ARMしか使えないやつ
所詮っていうか、必要十分な人材だったりして。
PICはPICに馴染んだ人にとって使いやすいマイコンだと思います。それで良いと思うのですが。 量産の製品に載らないとつぶれるぞ
趣味の工作でいくら売れても全体の数量からしたら誤差 PIC半年目だが、こんな面白い物はないな。
仕事は組み込み用のx86基板の回路設計とPCAT互換BIOSまでやっているけどPICはワンチップで色々できて面白い。
もっと前に手を出せば良かったなぁ。 マイコンが載ってる事すら知られないような所で動いてる、それが本来のPICの働く場所。 >>902が心配するようなことじゃないと思います。
知らんだけで売れているから存在するんですよ。無知のひけらかしは良くないです。 >>893
これ、良さそうだ、今度通販利用する時に買ってみる。
ありがとう。 >>904
LED懐中電灯の制御基板にも乗っている。
ttp://lygte-info.dk/pic/DriverTest/FT/1-2%20Lithium%202-Group%203-5-Mode%202.8A%20LED%20(LD-29)/DSC_4073a.jpg
ただAVRも相応に使われているが。 あつものにこりてなますをふく、とはちょっと違うか。
でも、欠点のないチップもない。
エラッタが十分公開されてないとか見やすく開示されていないなんて他のメーカーにでも割とある。
ほかを知らずに、特定のメーカー、チップの良くないところだけを知ってる状況って滑稽。
ID:TNLLjvn7 が使わなくても全体の数量からしたら誤差、は確かだろうね。 >>912
他を知らずにって...
いろいろと他を知ってるから言ってるわけで
他を知らずの根拠があったらよろしく
適当なことを言わないように エラッタの数も規模からすると異常に多い
16bit以上だと致命的なのがいくつも残ってる
エラッタで誓えない機能をスペックでうたってるとか、そのうち訴えられるぞって感じ
エラッタシートも氷山の一角で、いろいろと隠してるのがあるし そういうところは非常に悪い
もちろん良いところもあるよ
だから趣味で使ったりするわけで またエラッタくん登場？ 知ってるからって威張れるワードじゃないよ。 ↑
信者がキモいには同意
おまえはMicrochipの何なんだと
KY君 朝から全力
ID:kY/sEuQx
【Verilog】 記述言語で論理設計Project14 【VHDL】 [無断転載禁止]©2ch.net
電子工作入門者・初心者の集うスレ 73 [無断転載禁止]©2ch.net
初心者質問スレ その123 ※中国系店舗利用者出入禁止 [無断転載禁止]©2ch.net
PIC専用のスレ Part54 [無断転載禁止]©2ch.net [無断転載禁止]©2ch.net
アマ ■ オシロスコープ ■ 専用 No1 [無断転載禁止]©2ch.net
ラジオ自作総合スレ part16 [無断転載禁止]©2ch.net
【温調ｺﾃ/ガス鏝】ハンダ作業について語るｽﾚ No9 [転載禁止]©2ch.net
初心者質問スレ その123 [無断転載禁止]©2ch.net ID:kY/sEuQx
書き込み順位＆時間帯一覧
2 位/35 ID中
書き込み数 10 >>904
時々ちょっとした回路でもロジックIC代わりに使ってる >>921
海外の製品だと良くある。
キー入力のデコードとかLCDの表示とか。 >>921
ジョイスティック+連射回路をPICで作ってたな。
ボタンを押したまま、別なボタンを押すとボタンロックしたり連射ロックしたり。 さすがにそれはPIC16F18313を使った方が...
UART制御でハードPWM >>921
もともと、そう言う目的で作られた物だからな。 初代プレイステーションの中で大活躍したのが
PIC躍進のきっかけだったと思ってる MODチップの事？
残念だったなそれよりはるか前にHDD動かしてたんだぜ、母数が違うよ。
という話だけど見た事無いんだよなぁMAXならともかく実物見た事無いんだよなぁ… >>913
> ID:TNLLjvn7 が使わなくても全体の数量からしたら誤差、は確かだろうね。
これは反論のしようもあるまいね。 >>932
躍進はともかく、知名度は上がったのかも 新PICのPPSももっと割当自由にできたらと思うよ
PIC16F999xxって作って16Kw 2048に機能モリモリ
電源２本と書き込み３本だけ決め打ちで後は自由アサインにした8/12/14/16/18/20/24ピンシリーズでどうよ？
xxの部分をピン数って事で http://i.imgur.com/h47Rr1x.jpg
プレミアムフライデーだったから秋月とあきばおーで金使って来たぞ。
雨だったけど結構賑わってた。
PIC16F18346買った。160円。 >>938
秋月も値札シールがどんどんおしゃれになってきたな
ホームページはいつまでも相変わらずだが 秋月のオシャレ化…そのうちドレスコードが導入されて
正装でないと入店お断りになったりしてｗ 新製品コーナーに売ってたから袋入りだったけど、
その他大勢のPICはバラで引き出しに入ってたよ。 >>940
でかいリュック背負ったまま入店、は冗談抜きで禁止して欲しいわ。 武器を持ってないことを証明するために完裸入店をルールにしようぜ >>942
近隣にロッカー有るといいんだけどね
アキバをリュック背負って歩くとつくづく思うわ ロッカーで良ければ、バイク駐輪場の辺りとかパチ屋の壁とかあるぞ？ 一般的に、機能が増えると、不具合が出る可能性が増えるので、
十分なコストメリットやどうしても欲しい機能が無い限り従来品を選択するな〜
同系列ですら、クセがあったりする。
例えば、ぼくがメインで使ってる、PIC16F1825は、AD誤差が、PIC16F1824と異なる。特に
PIC16F1825は、Missing codes=2が出ているから、10bitでは使えない。
どちらも、2bitのgain errorがあるから、要注意なんだけど。 PICが出て何十年だろうか。そろそろ枯れてもいいのではないか。 >>947
枯れるほどに成熟してないし、みんなの話に出てくるものはシリーズとしても最近のモノでしょうが。
別に愛用していた84A以前が手に入らないから新型もっとちゃんとしてくれって言うなら分かるけど、そういう訳じゃないでしょ CPUは枯れてるだろ。IOは変わってくから市場でてから分かる不具合は仕方ない。
鬼の首を取ったように騒ぎ立てるのは下品。 シフトレジスタでエラッタ出すとかね。本気で言ってるんですか？
実装の蓄積のない50年前なら分かりますよ。ここは1年目の新人が設計してるんですか？ 古くて下品なコアでもあれこれ厚化粧すればそれなりに使えるってことだ。
いわば大年増の厚化粧と言われた小池都知事みたいなCPUだなｗ >そろそろ枯れてもいいのではないか。
なんで枯れてもいいのでしょうか。
世間の時間が止まっているなら別ですが、求められることは変わっていくものです。 PICが問題なのは、
規模に対してエラッタが多すぎる
既知のエラッタでエラッタシートに載っていないものがある 最近こんなふうに畳みかけて笑ったり、蔑んだりする人たまに出るよねぇ……。
ID換算で二人組で…さ……。
ワザワザ電電板のPICなんて選んでくるくらいだし、ワッチョイとか付けても止まんねえんだろうなぁ…… 質問させてください。24FJ64GA002にLEDを1個つなげて光らせるだけのプログラムを書いているのですが、うまくいきません。
16Fシリーズは触ったことあるのですが、24FシリーズのPICははじめて使います。
回路はブレッドボードで、PICのRB0である4番ピンにLEDをつなげただけのものとなっています。
ライターはPickit2です。ライターはPICを認識できていて、3Vの電源も供給されています。
コンパイルは成功していて、書き込みも正常に終わります。MPLAB X IDEv3.55でコンパイラはXC16です。
--プログラム--
#include "xc.h"
#include "p24FJ64GA002.h"
_CONFIG1( JTAGEN_OFF & GCP_OFF & GWRP_OFF & BKBUG_OFF & COE_OFF & FWDTEN_OFF & ICS_PGx1 )
_CONFIG2( IESO_OFF & FNOSC_FRC & FCKSM_CSDCMD & OSCIOFNC_OFF & IOL1WAY_ON & I2C1SEL_PRI & POSCMOD_NONE)
int main(void) {
TRISB = 0x0000; ///ポートBを出力に設定
while(1){
LATB = 0xFFFF;
}
return 0;
}
--プログラム--
コンフィグのFNOSC_FRCは内臓の8MHzのクロックを使うということです。コンフィグはこちらのサイトを参考にしました
http://mycom1.cocolog-nifty.com/blog/2008/11/pic24f-3eac.html
http://mycom1.cocolog-nifty.com/blog/2008/11/pic24f-b53b.html
PICはあまり使ったことがなく、自分なりに調べてみたつもりですがもしかしたらとても間抜けな間違いをしているかもしれません・・・
お願いします。 24FでLED制御か・・・牛刀をもって鶏を割くそのものや PIC16F触ったことあるならANSELトラップを回避してるはずなんだけどね
24FならAD1PCFGでADからIOに変更しないと PIC32MM0064GPL028
ついに秋月で扱うようになった！ PIC24FJ0064GA002の半額で32bit
16bitはもういらない子 >>959
PICを使うのが久しぶりなので、とりあえずLED光らせてみようかと思ったら早速躓いてます。
>>959
回答ありがとうございます。
今、AD1PCFG = 0xFFFF;にして再度書き込んでみたのですが、だめでした。正直完全にANSELとか忘れてました。でも、出力ピンでもADかIOの設定は必要なのでしょうか？ TRISの変更にアンロックとかいらなかったっけ？
PIC24は不要？
良く覚えてない こういうのって大抵自分のポカを疑えた人ほど早く解決するんだよな >>959
なんだこいつ
最終設計とは誰も行ってないのにすぐ他人の挙動にケチつけて >>958
PIC24FJ64GB002なら持ってる
明日試してみる 今更だけど、PICのシリアルポートって、送信のみ、受信のみという設定できたっけ？
もしくは、出来る品種と、出来ない品種がある？ >>975
16bitや32bitのFIFO付きのは出来る
8bitのEUSARTは、PPS付きのはTXを選ばなければピンを消費しないですむ
RXは動作は止められるけどピンは消費するかも
止めるだけならPPS付きじゃなくても出来る XC8の1.33がDL出来る所はありませんか？
アーカイブダウンロードは1.32までしかないし、日本語サイトだと1.33Bとか
いうのがダウンロード出来そうに見えて実際は1.41だしで、1.33が見つけられません >>958
有りがちなのは、デジタル設定にし忘れ。 >>978
有難うございます。
PPSって始めて知りました。
PICKit3 programmerで動く範囲の品種にはないかもしれませんね。 10F200でPWMなら作ったことある
1サイクル単位で0〜100%を256段階
ただし位相が一定しない 乱数を256で割った余りと
設定値（0〜255）を大小判定したら、それっぽくなるのでは？ >>979
お探しの物があるかどうか知らんが野良コピーを置いてるサイトはそこそこある。
今はもうないOSX用C18をそこで見つけた。
ご利用は自己責任で。 PICはリビジョンアップでエラッタ修正しない主義?
既存型番放置で新型番リリース時に修正する感じなのか CPUの種類が多いからエラッタを出すし、しかも修正にまで手が回らないんだろ。
無責任だな。 マスクを修正できる位の額を>>991買ってくれるそうで
一件落着。 H8S/2612をPIC24FJ64GA306あたりで置き換えようと思っているのだが、
RSあたりで調べるとPIC32の方が安かったりするし、
でも>>955のサイト見るとちょっと怖いし、
かといって、PIC24が枯れてるとは言い切れないし… 次スレに貼ったヤツは致命的なのは直ってるよ
PIC32MX
公表されてないデカいのがあるかどうかは知らん >>996
逆に何でその選択肢になるのか教えてほしいな
入手性的にもつぶしがきくかという点でもメリットが
感じられないけど機能的に凄かったりするの？ ルネサスの代理店にH8Sの置き換えだって言うと、RL78を勧められるよ このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 245日 17時間 53分 9秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
