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/ 前スレにて、Midrangeでの拡張が妥当かどうかの話を書いたので
その根拠を提示しておく。
これは、右が12F629、左が12F1822。
ttp://www.geocities.jp/one_prisoner/12f629vs12f1822.html
℃素人がXX位追加するべきとかほざいていたが、知ったかすんなよｗｗｗ
の根拠であるｗ
1822はかなり機能UPが図られてるが、プロセスの進歩で回路面積が大幅に小さくなって
ダイが小さくなってる上に、８ピンのICなのに１４ピン分のパッドがあるｗｗｗ
つまり、１８２２と１８２３は同じチップで、面積が小さい上に量産効果が大きくなって
１８２２が安くなったと言うことだな。 × これは、右が12F629、左が12F1822。
○ これは、左が12F629、右が12F1822。 >3
>℃素人がXX位追加するべきとかほざいていたが、知ったかすんなよｗｗｗ
XXじゃなくてキャリー/ボロー付きの加減算な。
で、キャリー/ボロー付きの加減算はプロセスの進歩で18Fシリーズ(2001年)やエンハンスドミッドレンジ(2009年)で
やっと実装できたと言いたいのか？
おいおい、同じワンチップマイコン系の8048(1976年),8051(1980年)はキャリー/ボロー付きの加減算もってるんだぜ。
送れること２０年以上たってやっと実装ってそこまでMicrochipの技術は遅れてるのかよ >>7
少し曲解が含まれているように思います。
製品の性能は、遅れているとか進んでいるとかみたいな技術力だけで決められるわけじゃないです。
Microchipの中の人でもない限り真意はわかりませんが、
>で、キャリー/ボロー付きの加減算はプロセスの進歩で18Fシリーズ(2001年)やエンハンスドミッドレンジ(2009年)で
>やっと実装できたと言いたいのか？
このことと、
>同じワンチップマイコン系の8048(1976年),8051(1980年)はキャリー/ボロー付きの加減算もってるんだぜ。
を並べるのは適切ではないように思います。
プロセスの進歩→小さく作れる→機能あたりのコストを低く抑えることができる。ということですし、
周辺機能を豊富に詰め込んだ上で低コストを実現しようとするPICマイコンが、
プロセスの進歩で「これぐらい小さく作れるならちょっとの命令追加で面積を増やしても、ま、いいか」みたいな
トレードオフを検討したとしても不思議ではありません。
ですので、
>やっと実装できたと言いたいのか？
は、「プロセスの進歩にともなうコストダウンという背景と、競争力とのバランスからようやく実装する気になった」のかもしれない、
という点において yes と考えることもできます。
8051はともかく、8048はそれ単体では多くのことができませんでした。
また、どちらも販売価格についても今ほどは競争も厳しくなかったはずです。
あと、℃玄人氏の煽り文句は彼の戦略だと思います。頭に血を昇らせてうっかりなことを言っちゃうと思うツボ。 >8
>は、「プロセスの進歩にともなうコストダウンという背景と、競争力とのバランスからようやく実装する気になった」のかもしれない、
>という点において yes と考えることもできます。
これが実現できるために遅れること２０数年っていくらなんでもおそすぎない？ >>9
でもね。たとえば、
「どんどん周辺機能を詰め込め、もっとコストを下げろ、隙間があるならメモリ増やせ」
のような空気の中なら、現状それで動作しているものについて、しかもユーザーからの要求が割と少数派だったら
お前がMicrochioの中に居てたって、実装を提案するかな?
たぶん、Micorochipの人たちは優先度が低いことよりも別の部分の改良に勤しんでいたんじゃないかな。
「おそすぎない？」なんてふうに不思議だと考えるより、それがなぜ道理なのかを考える方が分かりやすいと思うよ。 >10
>たぶん、Micorochipの人たちは優先度が低いことよりも別の部分の改良に勤しんでいたんじゃないかな。
で、その結果が２００９年のエンハンスドミッドレンジで実装か
１９７６年から３３年・・・これが遅すぎないと思わないなら感性の違いなんかな。 Microchipへの不満をここで書き連ねることの無意味さが分からない無意味なヤツ >>11
アンカーは >>10 のように半角不等号を2つ重ねてください。 >10 だと不便でしょ?
これは感性の問題じゃなくて、このシステムの仕様にもとづくマナーみたいなものです。 そのうち、windowsに対応してない。intelは〜とか騒ぐんじゃね？ ID:eZ4+21dkは昔の閉鎖騒動の時に転送量減らすため、むしろ>13という書き方を推奨されてた
（それを補うために専ブラはリンクとして扱うようになってる）という事を知らないニワカの小童
勝手にマナーを作るな 引用符と安価が同じだと判り辛いから>>の方が良いな
過去の柵なんてどうでもいい。爺の記憶に留めておけ。 >>16
転送量減らすために >> でなく > を推奨？
興味があるので、ソースを出してください。 流れ切って恐縮だが、
xc8で、プリプロセッサを使って、配列の初期値にサインカーブをセットすることはできる？
今は、Excelでサインカーブを作って、csvで保存、ソースにコピペしてるんだが、プリプロセッサで初期値を与えることができれば、コンパイルは遅くなるかも知れないけど、PICのリソースを消費せずに、配列のサイズや振幅を、Excelを使わずにパラメトリックに調整できそう。
サインカーブの配列の用途は、サイン波を出力するDDSで、振幅は10bit、配列のサイズは10〜12bitくらい。
書き込んだ後は波形はいじらないので、サインカーブはconstでROM領域に置いてる。
どなたか宜しくお願いします。 >PICのリソースを消費せずに
ってのは無理だと思うけどな。 >>22
方法のヒントを教えてもらえませんか？
>>23
現状でExcelでやってることを、コンパイラに肩代わりさせられませんか？という意味です。 >>23
「PICのリソースを消費せずに」は「配列のサイズや振幅を、Excelを使わずにパラメトリックに調整」にかかってて
パラメトリックにテーブル生成できるようにした上で、初期化においてPICで演算しないで済むという意味だと思う。
テーブルのためのROM領域は、現状の通り容認だろね。
俺には>>21の解決策は思いつかないけど。
巨大な#defineの羅列を作って…と考えた時点で現実的でもないし。 >>25
リソースの件の解釈、その通りです。
csvをExcelのマクロで吐かせるのが早いかも知れないけど、ソースコード上で配列サイズの値だけを修正すれば、配列の中身と、その配列を呼び出す処理も自動修正されるのが理想です。 >>24
プリプロセッサを自分で書けば良いだけ。
現状のプリプロセッサの機能を活かしたいならプリプリプロセッサを書けばいい。
おれは後者をPythonとSCILABで書いてる。
>>25
>「PICのリソースを消費せずに」は「配列のサイズや振幅を、Excelを使わずにパラメトリックに調整」にかかってて
「PICのリソースを消費せずに」に掛かってるなら、コメント生成位しか俺には思い浮かばないなｗｗｗ
そもそも日本語を理解してるなら「初期化においてPICで演算しないで済むという意味」は、微塵も無い。
単に代入してるんだろ？なんで演算？
そもそも、ROMを確保してるのになんで初期化するんだよ。単にCの使い方間違えてるだけなんじゃねｗ
>>26
「その通り」かよｗｗｗ
まずは日本語の勉強したほうが良いと思うぞｗｗｗ >>27
プリプリプロセッサでやればいいのか。Excelのマクロでやってみる。
正しくて、伝わる日本語って難しいな。俺は日本在住の日本人だけど、今でも日本語難しいよ。
>>27の書いてる文も、中盤以降は意味を理解できなかった。最初の段落は意味がわかった。 読んでわからないときは、どこがわからないか聞けば済む話。
普段付き合ってて暗黙の了解が通じるダチ公とのLINEじゃないんだし、短文メッセージだと分かりにくくなるのも仕方がない。
いちいち「日本語がー」なんて言わなくて良いと思うよ。
仕方ないことを責めて感情的にこじれるリスクを抱える必要ないよね！ LINEなんて使う情弱底辺が、日本語云々言うことは無いだろう。
必要な事を正しく伝えるのは質問者の債務だろうし、そもそも短文と言うほど短くは無い。 日本語が難しいので、画像で。
こういうサインテーブルを作りたかった。今まではExcelで作っていたが、もっと楽に、パラメータの修正も容易にできないか、というのがお題。
画像はマイクロチップのアプリケーションノートだけど、この値だと、正弦波じゃなく三角波が出来る気がするけど、そこは皆さん正弦波のテーブルに脳内変換してください。
改行の件、この方法じゃダメなのか？見づらい？それとも日本語的に誤りという意味？
http://i.imgur.com/ypwIkSD.png >改行の件、この方法じゃダメなのか？見づらい？それとも日本語的に誤りという意味？
気にしなくて良いよ。 >>36
1行の文字数が長いときに、段落とは別に途中改行すべきかどうか、という意味？
5インチくらいのAndroid端末のギコナビで見てるんだが、段落以外の途中改行しない方が見やすい。
http://i.imgur.com/pOlb0cz.png
ソースコード書くとき、馬鹿でかい配列とか、1行が長いif文とか、途中で改行すべきか迷うことはある。
画面に収まる幅で改行すべきか、改行せずに1行で収めるか。
マトリックス表示のフォントとか、特定の位置での改行が見やすさにつながる場合は迷わないけど、長ーい波形とか迷うな。 >>37
>、長ーい波形とか迷うな。
４Kディスプレイ買えばOK
足りなきゃ８Kもある 今頃、こんな所で聞くんじゃなかった、と後悔しているだろうな。
質問の文章を責められるなんて想像もしていなかっただろうな。
可哀想に。
しかしここは作文教室か？ あ、チト書きすぎた、また怒られるｗ
追加：ここはPICの疑問点を解消し、作文能力も高められる素晴らしいスレです。
これでいい？ 後悔はしてないよ。
くじけずに日本語がんばります。 そうか、それは良かった。
それだけ気持ちが強いなら大丈夫だな。 >>40
夏休みだからかなんか知らんけどここ最近は回答者（と呼ぶのはちょっと憚られるが）
の馬鹿さ加減が目に余るよ。なんか明らかに幼稚な雑音が増えた ID:WMhvnJYfは回答者にもなってない。純粋なノイズ。
純粋なノイズとか書くと、なんか役に立ちそうだがｗｗｗ 単発IDで言われましても説得力がありませんねえ。
何かアドバイスを書いた人が言うならともかく。 >>45とか>>46はなんでそんなに必死なのか純粋に興味ある >>47
>>46は単なる呟きｗ
「単発IDで言われましても説得力がありませんねえ。 」とか
俺に言われてよっぽど悔しかったんだなｗ
単純にオウム返しするんじゃなくて場面選べよｗｗｗ
だから℃素人って言われるんだよｗｗｗ >>52
ありがたいことにお前専用スレを用意してもらえてるんだからそこでやりなよ
初心者を見下してチンケなプライドを満たすスレ
http://rio2016.2ch.net/test/read.cgi/denki/1345646983/ ニートだから仕方ないだろ
此処でしか構ってもらえないのだよ 悔しそうだな、と書けば、そうではないだろ、って返事をしてもらえるよ。
返答に窮したときは、とりあえず「悔しそうだな」って書く。 そら悔しいだろう
こちとら真面目に働いているのに℃玄人様は四六時中たわごとを書き込んでいても
収入を得られるのだから 人間的な未熟さからするとまともな仕事に着いていなくても生きていける外的環境に恵まれた残念なやつなんだろう 集団ストーカー・電磁波犯罪被害の加害装置について
レーザー・メーザーが開発されたのが、1950年台以降
メーザー初の発振が1953年、レーザーの初の発振が1960年
https://ja.wikipedia.org/wiki/%E3%83%AC%E3%83%BC%E3%82%B6%E3%83%BC
この記念すべき年以降の、人体の自然発火現象は怪しい
No.31 突然人間が燃え上がり、焼死に至る「人体発火現象」
http://ww5.tiki.ne.jp/~qyoshida/kaiki/31zintaihakka.htm
No.157 人体発火現象２
http://ww5.tiki.ne.jp/~qyoshida/kaiki2/157jintaihakka2.htm
人体 自然 発火現象 : 人の体が突然 灰になるまで 燃えつきる / 世界の衝撃ストーリー
dailymotionを上のタイトルで検索してみ
64MHzの電波を使って撮像しているMRIの動画
集団ストーカー・電磁波被害の加害装置がレーザー・メーザーによるものだとしたら、レーダーを使うはず
加害者にはこのように見えているハズ
ちょっと、エロです
MRI Shows What Sex Looks Like From The INSIDE | What's Trending Now
https://www.youtube.com/watch?v=nDhYLaGPmGU
見えている各臓器、脳も含めて、レーザーを照射すれば、危害を加える行為が成立する
参考までにCTの動画
Radiologist discusses CT and xray small bowel obstruction Imaging
https://www.youtube.com/watch?v=8dNTHdUO_3Q
PCB Imaging: 3D/CT X-Ray Animated Slicing (Top to Bottom)
https://www.youtube.com/watch?v=itTkItXiHsk 「自分達は手を出さず人を追い込む方法があるんだってさ」
「多人数で人を追い込むんだってさ」
「電波攻撃で攻撃するんだってさ」
「他人の考えとか想いがわかる装置があるんだってさ」
集団ストーカー（組織的ストーカー行為）・電磁波被害の加害装置を持たせる時の誘い文句だそうです。
他にもいろいろあると思いますが、これに類するセリフを聞いた事がある人は、警察に一報をいれて貰えたらと思います。 キャンペーンだって。何があったのだろう？
26K22はキャンペーンになってなかった。
http://i.imgur.com/RKx9biU.png mcc対応してるなら買っておこうかな
今スマホだから後で調べる MCCのバグらしきもの発見。
PIC24FVで、OSCOピンからクロックアウトさせたいが、
クロックアウトを有効にすると、
ピンマネージャではカギが外れた状態になる。
実際にはクロックアウトされてる。
無効にすると、その逆。
結果オーライだけど、ピンマネージャの表示おかしくない？
http://i.imgur.com/8w0vgQr.jpg
http://i.imgur.com/8VMqbxr.jpg せいぜい16Fまでしか使わない俺にはCは不要、と思ってたけど、
マルツでポインヨ切れそうだったから、安い24F買っちまったよ。
どうしよう・・・
ざっくりしか見てないけど、24Fってなんか整然とした感じなんだよな。
直交性が高い、とかいうんかな。まぁ、しこしこやるか。
・・・なんてことを、「アセンブラvsＣ」で燃え上がる別スレを見てて思った雨の朝でした。 ｶｺｲｲと思った言葉を使いたかったんだろうな、訳もわからずに。
俺にもそんな磁気がありました。 ふと思ったんだが・・・
decfsz hoge,W
って、どんなときに使うんだろう。 for(c=COUNT;c!=0;c--) {
}
みたいなのが書きたい時
MOVLW COUNT
MOVWF COUNTER
LOOP
hogehoge
DECFSZ COUNTER,1
GOTO LOOP >>74
hogeを非破壊で1かどうかで分岐のするときとか
>>75
それ decfsz hoge,f の方では？ > hogeを非破壊で1かどうか
やっぱレアだよねぇ・・・ 命令の構成上意味のない命令ができることもあるわけで、無理に意味を
考えなくてもいいんじゃないの？
WをWREGとして割り当てられているチップでは
MOVWF WREG
というのもあるしね。 >>77
Cしか出来ない奴にとってはレアかも試練が、アセンブラでプログラム組むときは良く使う。 >>77
書いといてなんだけど、ほとんど使う事はないだろうね。
数値として０とそれ以外とで分岐したいというケースは多いけど、１とそれ以外ってのはあまり無い。
そのメモリの値が０にはならず、１が最低値のような前提だと使うかな１命令ですむし。
数値じゃなくてフラグで１かどうかの分岐に使うなら、BTFSC,BTFSS の方がWも壊れないし
１バイトで８フラグ使えて便利 予定していなかったのにデキてしまったので、
後から認知するというやつですな。 ∧,,,∧
(´･ω･`) ＜ 近い将来、欧米で株式市場が破綻すれば、
（| |） マイト レーヤは直ちに出て来られるでしょう。
し--Ｊ
最初になくなるのは世界の株式市場でしょう。
差し迫る株式市場の暴落は、他の人々が飢えている間にお金を儲けることの結果です。
彼らはただ座って待っているだけです。世界を餌にして生きており、何も還元しません。
日本から始まる世界的株式市場の大暴落
ウォールストリートの大暴落（１９９７年）につながったプロセスが、
いま日本におけるプロセスの中に写し出されており、
再び株式市場の暴落につながるでしょう。
終いには政府にも支えることができなくなり、どん底に落ちていきます。
日本がアメリカ国債の25％を引き出すと世界経済が破綻し、
マイト レーヤは出現するでしょう。
マイト レーヤはまずアメリカに現れ、それから日本です。
彼は日本語で話し、非常に物静かなやり方で話します。
彼の最初の控えめな態度に混乱してはなりません。
非常に間もなくマイト レーヤを、テレビで見るでしょう。
マイト レーヤは毎日テレビに現れ、質問に答えるでしょう。
彼は「匿名」で働いております。
マイト レーヤが公に現れるにつれてＵＦＯが、とてつもない数で姿を表すでしょう。 時代は動いてるな
FPU・DSPに対応したSTM32F3の低価格品の提供を開始
http://prtimes.jp/main/html/rd/p/000000496.000001337.html
STM32F3シリーズでは、DSP命令セットおよびFPUを特徴とする
ARM Cortex-M4コア（72MHz）と高性能アナログ・ペリフェラルを組み合わせることにより、
エントリ・レベルのミックスド・シグナル制御アプリケーションの高度な統合を実現します。
STM32F0シリーズと完全な互換性があるため、
同じ開発プラットフォームを使用できるという非常に大きなメリットがあります。
STM32F303は、Core-Coupled Memory（CCM-SRAM）技術の採用により、
90DMIPSの高い性能を実現しており、
内蔵Flashメモリから100MHzを超えるCPU周波数で命令を実行するのに相当する
「ルーチン・ブースト」機能を搭載しています。
また、ARM Cortexマイコンでは最速の12bit ADコンバータ（5Mサンプル/秒）と組み合わせた
30ns未満の最新アナログ・コンパレータが、デジタル電源、ソナー、モータ制御、照明、
ワイヤレス給電等、繊細な制御が必要なアプリケーションにおいて超高速リアルタイム性を提供します。
この超高速ADコンバータは、20kサンプル/秒で16bit、
1.2kサンプル/秒で18bit分解能のオーバーサンプリング機能を使用して精度を向上させることも可能なため、
センサ・データ処理、ヘルスケア、電力メータ、計測装置等のアプリケーションに最適です。
またSTM32F302/303は、USB-LPM（Link Power Management）モードを採用することにより、接続時の消費電力が低減されています。
mbedに対応した最新のSTM32F302 Nucleoボード（NUCLEO-F302R8）は、
STM32F303開発キット（STM32F3DISCOVERY）を伴う開発エコシステムに追加されるため、
エンジニアが新たなアイデアを試し、迅速にプロトタイプ開発を行うのに有効です。
このボードの価格は、10.32ドルです。
STM32F301K6U6（内蔵Flashメモリ: 32KB、SRAM: 16KB、32ピン・パッケージ）の単価は、
10000個購入時に約0.89ドルです。 >STM32F301K6U6（内蔵Flashメモリ: 32KB、SRAM: 16KB、32ピン・パッケージ）の
>単価は、10000個購入時に約0.89ドルです。
安すぎて鼻血出そう
もしこれが秋月あたりで取り扱い始まったらもうPICだのAVRだの使う気無くなるね >>85
現実はそこまで甘くないようだ
ＳＴＭ３２マイコン ＳＴＭ３２Ｆ３０３Ｋ８Ｔ６
http://akizukidenshi.com/catalog/g/gI-10790/
1個 ￥410（税込） ボードになるとこんな価格になっちゃう
全然スペックの違うボードでも価格が一緒
ＳＴＭ３２ Ｎｕｃｌｅｏ Ｂｏａｒｄ ＳＴＭ３２Ｆ３０３Ｋ８
http://akizukidenshi.com/catalog/g/gM-10172/
1台 ￥1,600（税込）
ＳＴＭ３２ Ｎｕｃｌｅｏ Ｂｏａｒｄ ＳＴＭ３２Ｆ４４６ＲＥ
http://akizukidenshi.com/catalog/g/gM-10176/
周波数：最大１８０ＭＨｚ
フラッシュ：５１２ＫＢ
ＳＲＡＭ：１２８ＫＢ＋４ＫＢ（Ｂｕｃｋｕｐ）
1台 ￥1,600（税込）
ＳＴＭ３２ Ｎｕｃｌｅｏ Ｂｏａｒｄ ＳＴＭ３２Ｌ４７６ＲＧ
http://akizukidenshi.com/catalog/g/gM-10177/
周波数：最大８０ＭＨｚ
フラッシュ：１ＭＢ
ＳＲＡＭ：１２８ＫＢ
1台 ￥1,600（税込） >>87で書いたＳＴＭ３２ Ｎｕｃｌｅｏ Ｂｏａｒｄ ＳＴＭ３２Ｆ４４６ＲＥ が
ここに書く前は在庫切れじゃなかったのに
秋月のホームページで在庫切れになったんですけどｗ 身の回りの家電製品見てごらん・・・・
そんなもの必要ない程度のものばかりで
わざわざ、乗り換えるメーカーあるのかね？？？？？ ID:nXsurQVd お前スレタイも読めないの？ それとも頭おかしいの？ PIC32MXの方がお手軽だな
ttp://picpage.art.coocan.jp/pic3.htm
ttp://akizukidenshi.com/catalog/c/cpic32/ 後○さんも本を出すネタがないのか
観光ペースが以前ほどではないよね。
高齢化に着目して、次のような本シリーズはどうだろうか。
老眼でもできるPICシリーズ
体が不自由になるまでにできるおうちhack、おうち自動化シリーズ ツイッター用ワッチドッグアダプタ。
心停止したら遺体を片付けてくれるようツイートする。 とりあえず、CCDカメラと、サーボモータで、
モニタ拡大しながらはんだ付けができるマニピュレーター作成からだな。
作れるのかどうかはしらぬ！ PIC18F26K22のSLEEP機能で、WDTで起こして間欠動作させたいんだけど、SLEEP後瞬時に起きてしまう。どうしたらいいだろう？
//ここまで来たらスリープ
SWDTEN = 1;
CLRWDT();
SLEEP();
NOP();
SWDTEN = 0;
//スリープからWDTで復帰
MPLABXとXC8とMCCは最新。
使ってる周辺モジュールはI2CとEEPROM。
内蔵クロック使用。割り込みは未使用。 >>100
ステータスレジスタとPCONレジスタを見てリセット原因特定が先じゃないかな？ MPLAB X+XC8で作ったプロジェクトを公開しようと思った場合に、plibを使ってたら
plibへのinclude-pathはどう設定するのがスマート？
絶対パスで書こうが相対パスで書こうが、XC8をインストールしたフォルダやXC8の
バージョンによって変わってくるし、plibを使う以上解決方法は無い気がするんだけど MPLAB X IDE v2.35 +XC8 使ってるんだけど、これをいったん閉じると、つぎ開いたとき
日本語のコメントが全部？？？？？に変るんだけどなんか対処法ないかしら >>104
エンコードの設定をシフトJISにしてから開くならなくなったよ >>104
あるあるww
MPLABX最大の初見殺しだよね 俺なんて日本語使えないと思ってコメントはずっとローマ字で書いてたわ >>109
こんな事書き込む奴に限って滅茶苦茶なコメント書いてる
綴りの間違いも多そう 今時コメントどころか変数名関数名も日本語ですがなにか？ >>110
そもそもコメントを書かない自己中だろ
後で自分が困るタイプでもある mbedのwebコンパイラで昔日本語が入力できなかった頃は
仕方なしに英語でコメント書いてたなー
あと、githubで公開ライブラリが以前クロアチア人にフォークされたので
あそこに置く物も英語で統一してる
#中国人はコミットコメント簡体字でそのまま書いたりするけどなw >>113
Shift_JISにはダメ文字問題があるから
なるべくUTF-8使ってる
会社では規定で全ソースShift_JIS義務化されてるけど (アホかと…) shift-jisのソースをutf-8に変換できますか？ 誰かmikrobasicの日本語化パッチ持ってない？
どこかに上げてもらえると助かるんだが… >>120
横だけど、記事は幾らも出るけどどのDL先も無いってならんか？ 今時MPLABXだよなって使おうとするたび外部エディタ設定できないの思い出して結局MPLAB8に戻ってしまう
MPLAB8もタグジャンプできなくて、なんだかなぁって感じ 井の中の蛙なら良かったんだろうけど、自分の使いやすい物を使えないのは困るな。
特にエディタなんて一番重要な部分だからな。 連携してないだけ
使おうと思えば使える
大量に打つときはお気に入りのテキストエディタ、デバッグ時に多少修正するときはデバッガ上 統合環境は単なるテキストエディタじゃ絶対に出来ないことが出来たりするから、多少は使い方を覚えた方が良い
MPLABにそういう機能があるかどうかは知らんけど 10関数、100行程度のmain.cだけで完結するような小規模プロジェクトに
統合環境は大げさやなぁ…といつも思う。 割込みで起動してA/D取り込んでEEPROM溜めこむとか
乱数値をもらって暗号演算結果を返すとか 別にエディタなんて何だろうが
入力検索置換保存
これが出来れば良いんじゃないの？ Xのエディタが便利すぎて無印や他のエディタ使う気になれない PC上でちょいとマクロを書けば（書ければ）、自分で気に入った統合環境なんぞすぐさまできるんだが。 「ちょいと書くだけでできるもの」の割には公開されて普及しているものがないのはなぜなんだろな。 >>129
その程度ならエディタなんてなんでもいいね >>135
バッチファイルなんてえものはちょいと書くだけのもので、あまり公開されてないのと同じようなもんじゃね？
作ったものは大抵環境依存するしね。俺の場合は、、ヒント：uwsc >135
開発環境に限らんけどスクリプト類を公開する際の心理的な壁
網羅的リポジトリがない
公開までがめんどい(ドキュメントとか)
スクリプトの使用以前の質問がわんさか来て嫌になる
俺様仕様になってるので他人が有用なのか計りかねる >>134
気に入った統合環境が簡単に作れるって？
夢見すぎ
または「気に入った」のレベルが低すぎる
少なくとも、単体エディタと統合環境エディタの良いとこ取りは不可能だ 統合エディタは編集中にずっと字句解析、構文解析してくれてるからな。
.や->と打つだけでメソッド一覧とか引数まで出てくれるし。 え？ 膨大なライブラリの引数まで暗記してからコード書いてるの？ 世の中には天才がいるんだな。 質問お願いします。
PIC同士でUART通信をさせたいのですが、配線が1メートルあります。
ノイズ対策はどのような事を行えばいいですか？
例えばここにプルアップ抵抗を何オーム入れるとか具体的にお教え下さい。
宜しくお願い致します。 線同士GNDと撚れ。T,R,GND なら3つ編みだ。分からなければJKに教えてもらえw GNDと信号を対にして撚ることには外来の電磁波をキャンセルするという意味があるけれど、三つ編みに合理性はあるんかな?
単純に3本の線を軽く撚るだけで良いのでは? 3本撚りにはしないな。ケチしないでT-GBD、R-GNDの4本。 音声用ステレオケーブルならそれぞれシールドされてる >>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文字くらいは大丈夫そうです 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を超えています。これ以上書き込みはできません。
