前スレにて、Midrangeでの拡張が妥当かどうかの話を書いたので その根拠を提示しておく。 これは、右が12F629、左が12F1822。 http://www.geocities.jp/one_prisoner/12f629vs12f1822.html ℃素人がXX位追加するべきとかほざいていたが、知ったかすんなよwww の根拠であるw 1822はかなり機能UPが図られてるが、プロセスの進歩で回路面積が大幅に小さくなって ダイが小さくなってる上に、8ピンのICなのに14ピン分のパッドがあるwww つまり、1822と1823は同じチップで、面積が小さい上に量産効果が大きくなって 1822が安くなったと言うことだな。 × これは、右が12F629、左が12F1822。 ○ これは、左が12F629、右が12F1822。
>3 >℃素人がXX位追加するべきとかほざいていたが、知ったかすんなよwww XXじゃなくてキャリー/ボロー付きの加減算な。 で、キャリー/ボロー付きの加減算はプロセスの進歩で18Fシリーズ(2001年)やエンハンスドミッドレンジ(2009年)で やっと実装できたと言いたいのか? おいおい、同じワンチップマイコン系の8048(1976年),8051(1980年)はキャリー/ボロー付きの加減算もってるんだぜ。 送れること20年以上たってやっと実装ってそこまでMicrochipの技術は遅れてるのかよ
>>7 少し曲解が含まれているように思います。 製品の性能は、遅れているとか進んでいるとかみたいな技術力だけで決められるわけじゃないです。 Microchipの中の人でもない限り真意はわかりませんが、 >で、キャリー/ボロー付きの加減算はプロセスの進歩で18Fシリーズ(2001年)やエンハンスドミッドレンジ(2009年)で >やっと実装できたと言いたいのか? このことと、 >同じワンチップマイコン系の8048(1976年),8051(1980年)はキャリー/ボロー付きの加減算もってるんだぜ。 を並べるのは適切ではないように思います。 プロセスの進歩→小さく作れる→機能あたりのコストを低く抑えることができる。ということですし、 周辺機能を豊富に詰め込んだ上で低コストを実現しようとするPICマイコンが、 プロセスの進歩で「これぐらい小さく作れるならちょっとの命令追加で面積を増やしても、ま、いいか」みたいな トレードオフを検討したとしても不思議ではありません。 ですので、 >やっと実装できたと言いたいのか? は、「プロセスの進歩にともなうコストダウンという背景と、競争力とのバランスからようやく実装する気になった」のかもしれない、 という点において yes と考えることもできます。 8051はともかく、8048はそれ単体では多くのことができませんでした。 また、どちらも販売価格についても今ほどは競争も厳しくなかったはずです。 あと、℃玄人氏の煽り文句は彼の戦略だと思います。頭に血を昇らせてうっかりなことを言っちゃうと思うツボ。 >8 >は、「プロセスの進歩にともなうコストダウンという背景と、競争力とのバランスからようやく実装する気になった」のかもしれない、 >という点において yes と考えることもできます。 これが実現できるために遅れること20数年っていくらなんでもおそすぎない?
>>9 でもね。たとえば、 「どんどん周辺機能を詰め込め、もっとコストを下げろ、隙間があるならメモリ増やせ」 のような空気の中なら、現状それで動作しているものについて、しかもユーザーからの要求が割と少数派だったら お前がMicrochioの中に居てたって、実装を提案するかな? たぶん、Micorochipの人たちは優先度が低いことよりも別の部分の改良に勤しんでいたんじゃないかな。 「おそすぎない?」なんてふうに不思議だと考えるより、それがなぜ道理なのかを考える方が分かりやすいと思うよ。 >10 >たぶん、Micorochipの人たちは優先度が低いことよりも別の部分の改良に勤しんでいたんじゃないかな。 で、その結果が2009年のエンハンスドミッドレンジで実装か 1976年から33年・・・これが遅すぎないと思わないなら感性の違いなんかな。
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のリソースを消費せずに」に掛かってるなら、コメント生成位しか俺には思い浮かばないなwww そもそも日本語を理解してるなら「初期化においてPICで演算しないで済むという意味」は、微塵も無い。 単に代入してるんだろ?なんで演算? そもそも、ROMを確保してるのになんで初期化するんだよ。単にCの使い方間違えてるだけなんじゃねw >>26 「その通り」かよwww まずは日本語の勉強したほうが良いと思うぞwww >>27 プリプリプロセッサでやればいいのか。Excelのマクロでやってみる。 正しくて、伝わる日本語って難しいな。俺は日本在住の日本人だけど、今でも日本語難しいよ。 >>27 の書いてる文も、中盤以降は意味を理解できなかった。最初の段落は意味がわかった。 読んでわからないときは、どこがわからないか聞けば済む話。 普段付き合ってて暗黙の了解が通じるダチ公とのLINEじゃないんだし、短文メッセージだと分かりにくくなるのも仕方がない。 いちいち「日本語がー」なんて言わなくて良いと思うよ。 仕方ないことを責めて感情的にこじれるリスクを抱える必要ないよね!
LINEなんて使う情弱底辺が、日本語云々言うことは無いだろう。 必要な事を正しく伝えるのは質問者の債務だろうし、そもそも短文と言うほど短くは無い。
日本語が難しいので、画像で。 こういうサインテーブルを作りたかった。今まではExcelで作っていたが、もっと楽に、パラメータの修正も容易にできないか、というのがお題。 画像はマイクロチップのアプリケーションノートだけど、この値だと、正弦波じゃなく三角波が出来る気がするけど、そこは皆さん正弦波のテーブルに脳内変換してください。 改行の件、この方法じゃダメなのか?見づらい?それとも日本語的に誤りという意味? >改行の件、この方法じゃダメなのか?見づらい?それとも日本語的に誤りという意味? 気にしなくて良いよ。
>>33 自分のイメージどおりならいいんじゃね >>36 1行の文字数が長いときに、段落とは別に途中改行すべきかどうか、という意味? 5インチくらいのAndroid端末のギコナビで見てるんだが、段落以外の途中改行しない方が見やすい。 ソースコード書くとき、馬鹿でかい配列とか、1行が長いif文とか、途中で改行すべきか迷うことはある。 画面に収まる幅で改行すべきか、改行せずに1行で収めるか。 マトリックス表示のフォントとか、特定の位置での改行が見やすさにつながる場合は迷わないけど、長ーい波形とか迷うな。 >>37 >、長ーい波形とか迷うな。 4Kディスプレイ買えばOK 足りなきゃ8Kもある 今頃、こんな所で聞くんじゃなかった、と後悔しているだろうな。 質問の文章を責められるなんて想像もしていなかっただろうな。 可哀想に。 しかしここは作文教室か?
あ、チト書きすぎた、また怒られるw 追加:ここはPICの疑問点を解消し、作文能力も高められる素晴らしいスレです。 これでいい?
後悔はしてないよ。 くじけずに日本語がんばります。
そうか、それは良かった。 それだけ気持ちが強いなら大丈夫だな。
>>40 夏休みだからかなんか知らんけどここ最近は回答者(と呼ぶのはちょっと憚られるが) の馬鹿さ加減が目に余るよ。なんか明らかに幼稚な雑音が増えた ID:WMhvnJYfは回答者にもなってない。純粋なノイズ。 純粋なノイズとか書くと、なんか役に立ちそうだがwww
単発IDで言われましても説得力がありませんねえ。 何かアドバイスを書いた人が言うならともかく。
>>47 >>46 は単なる呟きw 「単発IDで言われましても説得力がありませんねえ。 」とか 俺に言われてよっぽど悔しかったんだなw 単純にオウム返しするんじゃなくて場面選べよwww だから℃素人って言われるんだよwww ニートだから仕方ないだろ 此処でしか構ってもらえないのだよ
悔しそうだな、と書けば、そうではないだろ、って返事をしてもらえるよ。 返答に窮したときは、とりあえず「悔しそうだな」って書く。
そら悔しいだろう こちとら真面目に働いているのに℃玄人様は四六時中たわごとを書き込んでいても 収入を得られるのだから
人間的な未熟さからするとまともな仕事に着いていなくても生きていける外的環境に恵まれた残念なやつなんだろう
集団ストーカー・電磁波犯罪被害の加害装置について レーザー・メーザーが開発されたのが、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 人体発火現象2 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 ダウンロード&関連動画>> VIDEO 見えている各臓器、脳も含めて、レーザーを照射すれば、危害を加える行為が成立する 参考までにCTの動画 Radiologist discusses CT and xray small bowel obstruction Imaging ダウンロード&関連動画>> VIDEO PCB Imaging: 3D/CT X-Ray Animated Slicing (Top to Bottom) ダウンロード&関連動画>> VIDEO 「自分達は手を出さず人を追い込む方法があるんだってさ」 「多人数で人を追い込むんだってさ」 「電波攻撃で攻撃するんだってさ」 「他人の考えとか想いがわかる装置があるんだってさ」 集団ストーカー(組織的ストーカー行為)・電磁波被害の加害装置を持たせる時の誘い文句だそうです。 他にもいろいろあると思いますが、これに類するセリフを聞いた事がある人は、警察に一報をいれて貰えたらと思います。
キャンペーンだって。何があったのだろう? 26K22はキャンペーンになってなかった。 mcc対応してるなら買っておこうかな 今スマホだから後で調べる
PIC16F1454 USB MIDI I/F MCCのバグらしきもの発見。 PIC24FVで、OSCOピンからクロックアウトさせたいが、 クロックアウトを有効にすると、 ピンマネージャではカギが外れた状態になる。 実際にはクロックアウトされてる。 無効にすると、その逆。 結果オーライだけど、ピンマネージャの表示おかしくない? せいぜい16Fまでしか使わない俺にはCは不要、と思ってたけど、 マルツでポインヨ切れそうだったから、安い24F買っちまったよ。 どうしよう・・・ ざっくりしか見てないけど、24Fってなんか整然とした感じなんだよな。 直交性が高い、とかいうんかな。まぁ、しこしこやるか。 ・・・なんてことを、「アセンブラvsC」で燃え上がる別スレを見てて思った雨の朝でした。
カコイイと思った言葉を使いたかったんだろうな、訳もわからずに。 俺にもそんな磁気がありました。
ふと思ったんだが・・・ 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 書いといてなんだけど、ほとんど使う事はないだろうね。 数値として0とそれ以外とで分岐したいというケースは多いけど、1とそれ以外ってのはあまり無い。 そのメモリの値が0にはならず、1が最低値のような前提だと使うかな1命令ですむし。 数値じゃなくてフラグで1かどうかの分岐に使うなら、BTFSC,BTFSS の方がWも壊れないし 1バイトで8フラグ使えて便利 予定していなかったのにデキてしまったので、 後から認知するというやつですな。
∧,,,∧ (´・ω・`) < 近い将来、欧米で株式市場が破綻すれば、 (| |) マイト レーヤは直ちに出て来られるでしょう。 し--J 最初になくなるのは世界の株式市場でしょう。 差し迫る株式市場の暴落は、他の人々が飢えている間にお金を儲けることの結果です。 彼らはただ座って待っているだけです。世界を餌にして生きており、何も還元しません。 日本から始まる世界的株式市場の大暴落 ウォールストリートの大暴落(1997年)につながったプロセスが、 いま日本におけるプロセスの中に写し出されており、 再び株式市場の暴落につながるでしょう。 終いには政府にも支えることができなくなり、どん底に落ちていきます。 日本がアメリカ国債の25%を引き出すと世界経済が破綻し、 マイト レーヤは出現するでしょう。 マイト レーヤはまずアメリカに現れ、それから日本です。 彼は日本語で話し、非常に物静かなやり方で話します。 彼の最初の控えめな態度に混乱してはなりません。 非常に間もなくマイト レーヤを、テレビで見るでしょう。 マイト レーヤは毎日テレビに現れ、質問に答えるでしょう。 彼は「匿名」で働いております。 マイト レーヤが公に現れるにつれてUFOが、とてつもない数で姿を表すでしょう。
時代は動いてるな 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だの使う気無くなるね
>>87 で書いたSTM32 Nucleo Board STM32F446RE が ここに書く前は在庫切れじゃなかったのに 秋月のホームページで在庫切れになったんですけどw 身の回りの家電製品見てごらん・・・・ そんなもの必要ない程度のものばかりで わざわざ、乗り換えるメーカーあるのかね?????
ID:nXsurQVd お前スレタイも読めないの? それとも頭おかしいの?
後○さんも本を出すネタがないのか 観光ペースが以前ほどではないよね。 高齢化に着目して、次のような本シリーズはどうだろうか。 老眼でもできる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Ωくらいの終端線路に1万ボルトの静電気放電を 与えてノーエラーを保証できますか?
別にパケット破棄、再送リクエストでいいじゃん。 物理的に壊れなきゃどーにでもなる。
長距離UART通信ならRS485ドライバICかまして差動伝送するのが一番楽 ケーブルはEtherか、モジュラーケーブルを流用してRJ-11/RJ-45コネクタ接続
通信屋的には1m「も」不平衡で引き回すなんて気持ち悪くてムズムズしてしまうのよ
RS485は半二重だから、方向制御が不要なRS422を。 配線はシールド付きツイストペアの2×2で。 1mどころか100mも可。
趣味の電子工作の「1m」ってのは、 CPU直結はイヤだなぁ、バッファいれようかなぁ、それも面倒だなぁ という微妙な距離だな。
>>165 シングルモードファイバなら10kmくらいは余裕 いずれにしろオーバースペック >>166 変調かけてアンテナから送受信するときは同軸使うけど 10Base2/5みたいなベースバンドで同軸使うムダなことはもうやらないなー >>169 家だとデジタル音声(S/PDIF, adat)とアンテナ線で使ってる コンポジットは家では絶滅した 同軸のデジタル音声だと600mエラー無しで届いたよ PICのUARTで想定されるビットレートってどれぐらいなんだろね。 せいぜい57600bpsぐらいだと思ったんだが、1ビットあたり17.4u秒だよね。 これを1m送るのに「不平衡でないと気持ち悪い」と考えるとき、懸念されることって何なんだろう。 回路を考えるときって、用途に合わせたホドホドを見つけることって大切だと思う。 高精度発振回路を長年やってきた人にPICマイコンの回路設計をやらしたら、クロック発生回路がやたら豪華になるみたいな話だ。 そこは内蔵でも十分な用途なのに、とか。
秋月でRS485ドライバ60円、モジュラジャック40円、ケーブルは電気店で350円くらい 一方、BNC2mは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
信頼性向上推進派:とりあえず電線1本でつないで、エラーが気になるようであれば原因調査して信頼性を向上していく。 コストダウン推進派:とりあえず徹底的にエラーに強い設計をして、エラーが気にならないようであればコストダウンしていく。
矛盾してますね、それ。矛盾してますね >とりあえず徹底的にエラーに強い設計をして、エラーが気にならないようであればコストダウンしていく。 徹強設(徹底的にエラーに強い設計)には通常以上のコストがかかるということを無視 しているんじゃあないでしょうか? 結局のところ見た目のコストのかかり場所を徹強設に変えただけで、全体コストは全然 変わってないですね。それをコスダウ推(コストダウン推進)と言ってしまっていいんですか? それをコスダウ推と呼んでしまっていいんでしょうか?
>>192 ジョークと皮肉が込められていることまで理解しようや。 徹強設 はじめて見た。>>192 の仕事場周辺では普通に使われてますの? >徹強設(徹底的にエラーに強い設計) >コスダウ推(コストダウン推進) こいつ、まだ入院してなかったのか。 身内は何してる。
>>196 ほら、あの「ちな」とか「とりま」とかのゆとり言葉に触発されて、 自分もやってみたくなったんだろw 使うのが世界で一人だけじゃ、ゆとりと揶揄する対象にすらかすりもしない。 「ライク フォトカプラー」のデフがファジーなのでそのクエスチョンにアンサー出来る フレンドはいないんじゃないかな? もしアンサーをゲットすることがマストなんだったらもうちょっとコンセプトを アウトプットしたほうがベターかもね
通信内容と通信相手が予め決まっているなら、略語も隠語もok
東芝半導体が売却されたらトスリンクも改名されるかな? トスリンクは直流成分通さないからON-OFF情報伝達には向かないんだよなー
>>199 それで思いついたが 周波数にもよるが、送出信号を100均のイヤフォンケーフルで送ったとしても 受信側でフォトカプラーで受ければ GND 間ノイズの影響を受けなくなって、 徹強設wに近くなると思うぞ。次にフォトカプラーやめてコストダウンな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は1対1 RS485は1対多 全二重の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は空読みして(捨てて)文字数だけカウントでもおkだろう >>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フラグは無効だから、2命令経過してから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 に貼ったようなデータが送信されます タイミング依存ですので、コンパイラに依存すると思います 海外のフォーラムだったらコードに問題があると思うなら こういうコードの方はどうよ?って書き込みがぶら下がる もんだけど単なる煽りしか出ない辺りが日本らしいよなぁ 技術的な話を楽しむ人よりストレス発散目的の人多過ぎ
>>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 >(作りによっては)対策が難しい そんな鈍臭いプログラムを書く奴は℃素人以外いない。 一番の問題は、鈍臭いプログラムしか書けない事。 まずはデータシートを熟読する事だな。 あとはセンスが必要だが、こればっかりはどうしようも無いだろうw >>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 データシート嫁w >>298 >これをすべて満たす方法が無いわけですが センスが無い上に理屈で考えられないのはよく分かってる。 だから思いつかないんだろう。 そういうレベルの奴は、少なくともデータシートをちゃんと読んで プログラムを組めば、この件に関しては問題無い。 >>308 データシートには書いてない >>298 をすべて満たす方法も無い 嘘を繰り返しても真実にはならないよ データシートも読めないのか。 >>298 は、Cしか出来ない鈍臭い奴には無理。俺は普通に出来るよ。 煽ろうが何しようが不可能なものは不可能だし、書いてないものは書いてない
その証拠に、 どこに書いてあるかも書けず、コードで示すことも出来ない 幼稚園児が「おれは空を飛べる」っていうのと同レベル
新しいのは発売後暫く経ってからじゃないと怖くて使えないな
全然証拠になってないwww ま、せいぜい頑張って勉強するんだね。 Cしか出来ない奴には無理だろうけどw
ちなみに俺は、921600BPSで普通に使えてる。 115200如きで何言ってんだかwww
アセンブラバカはスルーするのがこのスレのルールです
あ、>>298 には書いてないけど、当然エラッタは回避してね >>320 よっぽど鈍臭くてセンスの無いプログラムを書かない限り そのエラッタには引っかからない。 エラッタシートにもまともな解決方法が書かれて無いんで、本当に方法があるなら教えてあげればwww 違うマイコンのだけど
>>323 ある確率でひっかかる、もしくは気づいてないだけ 幼稚園児レベルの嘘www 後に引けなくなったバカwww
>>324 >教えてあげればwww とか、まるで他人事だなwww お前が鈍臭くてセンスが無い本人だろうに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 考える能力が無いなら諦めるしか無いなwww 以下が普通の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; }
なんで自分で考えようとしないんだこいつ。 ユトリかwww
おっと、1か所間違えました ほとんどの場合は何も問題が無いんですが、 エラッタのせいで、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; }
住民にデバッグ、プログラミングしてもらうつもりなのかwww
出来ないものを出来ると主張するんだから、それを示せば良いだけです 上のコードじゃなくても良いので ただ「出来る」と言うだけじゃ何も進みません
進まないのは考える能力の無いお前さんだけ。 普通の人はそんな所に引っかからない。いままでのレスの中に正解があるけど 気が付かない&無視してるようなレベルだから、どうしようもない。 ま、℃素人にありがちだけどな。 進みたいなら自分で考えることだな。普段から自分で考える癖をつけてないから エラッタだのハードがおかしいだの言い出すしか脳がない。
そう思ってれば良いよ。世の中にはCしか出来ない奴がかいた 鈍臭いプログラムが沢山ある。
>>341-342 嫌みだけのためによくそんだけいっぱい書き込みできるなおまえ 1〜2キャラ分のデッドタイムが許されないなら別のチップ使え エラッタくんはMicrochipに就職してくれよ。
俺も1454でシリアルやるし連続送受信もやるけど、MCCが確保した128バイトだかのバッファを介して送受信してる。 今回その方法を使わない理由ってなに?
意見が衝突しているのだとしても、できるだけ意図を読み取るようにしないと混乱に 拍車をかけるだけです。落ち着いて読みましょうぜ。 >>349 >>298 が言ってるのは「1〜2キャラ分のデッドタイム」「1ビットのデッドタイム」ですね。 余計厳しい。 >>352 この流れの話なら、元レスは隙間なくツメツメで送信をしたいと考えているようだから、 >>350 が言ってるのはハードウェアのバッファじゃないかと。 でも、PICにハードウェアバッファのあるUARTを持つものってあるのだっけ。 エラッタが無かったとしても受信bps>送信bpsの条件なら動作しないし 1キャラの空きができたから発現するエラッタなんだから送出開始に遅延が出ても何の影響もないし 検討するのもアホらしい仕様だ
>>341 その条件を満たすのは俺には無理。 uart_send()の頭でbusy waitするぐらいしか思いつきません。 if(!TXIE) while(!TRMT); ℃玄人は相手にするだけ無駄。 まともなレスをしたのを見たことがない。
921600BPSでさえキッチリ詰めて送信出来るのに Cしか出来ない奴って、115200BPSさえ使いこなせないとか、バカス
>>354 キッチリ詰めても送信側のボーレイトが早くても許容範囲内なら問題無い。 但し、ノイズ等で同期が外れても回復させる為に、適当な間隔で十分なストップビットを入れてやるのがまともな設計。 パッと見、read_p、write_pが同期取れてないみたいだけど
>>361 > 「(問題が発生している)PIC12F1572にはこのエラッタ情報がない」という話に対して > 「他のチップのEUARTのエラッタも見るようにしているよ」という話が出ている。 これが本当だとしたらメーカーが怠惰すぎるな 仕事で使える代物じゃない 仕事で件の℃素人プログラミングしてるなら、首括ってタヒんだ方がマシ 迷惑の掛からない方法でどうぞ。
使えないと思う人は使わないで良いんじゃないの? そう思う人が、そう思わない人に、そう思えって強制するようなことでもない。 どんなものでも人によって評価の変わる長所短所をまとめて使う使わないを決めるんだし、 一般論として使える使えないなんて匿名掲示板で議論するようなこともでもない。
>>364 首括って死んだ方がマシなんてことなんてないよ。言葉に気を付けろ。糞ったれが。 自分の能力の無さを棚に上げて何時まで管を巻いてるんだwww データシートも読めず115200BPSさえ組めないなら、CPUに何を使っても同じ。何らかの問題が出てくる。 とっとと死んでくれwww
>>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 おれも送信割り込みでは1バイトしか転送しないように作ってる 1バイトしか書けない時の方が圧倒的に多いし割り込みコードも小さくなる >>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が作るコードは普通の人未満だ 煽るの下手すぎw 仕事出来なさそうなのがよくわかる。 ま、頑張って勉強してくれたまえw
pickit3とAE-PICKIT-ライトで12F1822に書き込んで遊び始めた初心者なのですが pickitさんのご機嫌のせいか5V足らないって言われるときがあるのですがこれはセルフパワーのハブ買えば解決しますでしょうか? なった時は色々ポート抜き差しでご機嫌直ればその日は問題無く使えるのですが毎回これだとうざいので解決したいです。 ちなみにデスクトップだしその他のポートに大食らいの機器は繋いでません
セルフパワーハブ買っても解決しなかったよ うちでもたまにVDDの電圧足りんよ!って言われるけどそういう時は一度抜き差しすれば 大抵は直る。もうそう言うもんだと思うことにしてる
>>399 今までPC直結のバスパワー以外で使ったことは一度もないです。 自分ならまずAE-PICKIT-ライトのハンダ付けを確認する。 次に疑うはUSBケーブルで、これは純正品? Canonのスキャナーに付いてきたケーブルが、純正品以上にトラブル無しだったりする。 最後に、PC側との相性が出ることもあるから、別の端子に挿してみるとかは試す価値ある。 あと、メッセージ通りの原因じゃないことも多いので、あまりこだわらず他にも注意して。 >普通の人間なら、その程度の条件でダブる事無く動くプログラムが書ける。 本質を理解できないで恥ずかし書き込みだな。 自分では回避できたつもりになってるのかな。
悔しそうだなw 内部回路を想像出来ればなんの問題ない事が分かるんだが ま、℃素人には無理かもな。
>>404 ワンパターンだからあぼーんできるのにつまらん事言うな。 やっぱり℃玄人の妄想だったか。 いつものパターン。 「オレにはできる。しかし、詳細は書けない。」
>>402 池沼だから℃玄人様は書けないのだろ 何も間違ってないだろ >「オレにはできる。しかし、詳細は書けない。」 ℃玄人はフェルマーの最終定理かw 「私は真に驚くべき証明を見つけたが、このスレはそれを書くには狭すぎる」
>>408 「ホテルロイヤルの謎」の話題はそこまでだ!w ℃玄人さんだったか どうりで書けない訳だ PIC16よりPIC24のエラッタがひどすぎる 売るレベルじゃない
無理してPIC使わなくて良いのに。 おこちゃまには敷居が高いんだからwww
何でそんなネガティブな発言しか出ないのかな??? 人の発言にだめということは簡単でどんな馬鹿でも逆を言えば出来る こんなことばかりではなんの進歩もない やはりここにはふぬけが多くなっているのか!! 日本人の質が落ちていると言われているのは事実なのかね〜〜〜
PICはエラッタだらけでやってられない。だがもうその心配はご無用。 Microchipから超新星のマイコンが出ました。 AVRです!!!
超新星って実態と多くの人の印象が食い違ってるものの一つだな。
Microchip Directでは旧Atmel製品送料無料キャンペーン中 よっぽど売れないらしいw
俺の予想 ・・・ 8ビットのコアはAVRに統一 PICはクソ過ぎる
CPUってクソだと言われる方が何故か生き残ったりするよなー
なんでもそうだけど、一部の長所がほかの物を圧倒していても、結局は歴史経緯を含めてのトータルだし。
>>427 クソにまみれて生きていくのか・・・ま、それも人生だなw 周辺そのままでコアAVRのPICはやく。 アセンブラ爺が全滅しますように。
しょぼい若造はアセンブラを古いと馬鹿にし しょぼい老害はアセンブラもできないのかと馬鹿にし... 両方とも消えればいいのに
確かににPICのアセンブラはいろいろ古臭い。 百戦錬磨の古強者ですら読みたくない、書きたくないレベル。変態アセンブラと言っていい。 それに比べてAVRのアセンブラはどうか。 まさにエレガントである。
>>432 の >アセンブラ爺が全滅しますように。 は、アセンブリ言語を古いと否定しているわけじゃないだろう。 アセンブラ爺を否定的に見てるだけじゃないのかな。 モトローラ68系であっても過去のアセンブラ設計機器の保守だけはご勘弁・・・
Z80案件で20年物のコードの保守を中途の若い社員にやらせたらすぐ辞めてったわ ヤツはパタヘネを教科書にしてMIPSで勉強してたと聞いたが 汎用レジスタが湯水のように浪費できる石でアセンブラを勉強しても 甘えが出て来てダメだな いや、PICぐらいシンプルだったら逆に音をあげずに頑張れたかも (w
>>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の2択 欧米だと有線無線モデムチップ内蔵マイコン等で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進変換、液晶、7セグ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 全体をアセンブラなんて時代は終わったが、 特殊な用途だとまだ一部アセンブラを使う 例えば定期的に割り込みが入り、その中で処理を終えなければならないような物で 1回の計算が数百クロックしか時間がないこともある PICの中にもそういう用途に特化した物がある 音声処理だったり、制御のフィードバック処理だったり もちろん仕事で 東芝はあまりディスコンしない企業だったけど 経営が傾いてからはEOLだらけで仕事が代替品対応ばっかりやーー
>>500 15年先を気にしてられるなんて良いねえ ま、日本が一番酷い状況になるのは間違いない。 原発が爆発したロシアの後追いだが、状況は隠蔽されもっと酷い。
>>506 15年も保つと思ってるのか お花畑すぎだろ 10年も持てば現役の官僚連中は資産も家族も海外に移して悠々自適の海外生活だから問題ない。 何なら年金ももらえて御の字の100乗くらい。 「日本?何それおいしいの?」って感じ。
カタログ製品だけど年間数台とか オンリーワンだけど年間数台とか モデルチェンジの開発費捻出にそのくらいかかる模様 表示関係とマイコンがいつも悩ましい
いわゆる窓付き(UV-EPROM)を使う必要に迫られたのだけど、 これって最近流行りのUVレジン効果用の蛍光灯で消去できるものでしょうか? お試しあそばされた方いらっしゃいますか? UV-EPROM消去用の装置(といってもただの殺菌灯密閉箱に見える)が1万円以上するのばっかりで、 ちょろっと使うには敷居が高くて困っちゃうし、一度使ったらたぶんもう使わないとは思うのでちょっとコストが…
>>512 >ただの殺菌灯密閉箱に見える うん、ただの殺菌灯だよ >>512 実験した人の報告では1W級でも5時間かかったというから使えないレベル 375nmのLEDならもっと短いかもしれんが必要とされる波長は250nmだから ホームセンターかアマゾンで殺菌灯を買った方がいい 日光で1週間、レジン用LEDで15時間、とか聞いたことがあるな。 殺菌灯なら数秒。適当な蛍光灯照明と嵌め替えるだけでOK。
みなさんレスありがとう御座います、 なるほど殺菌灯とUVレジン用はなんだか違うみたいなのですね。 ちょっとAmazonから殺菌灯買ってやってみます。
>>517 レジン用のランプの紫外線は365〜400nm。 UVEPROM用の紫外線は253.7nm。(サンハヤトROMイレーサー) 買うのならそのあたりのチェックをお忘れなく。 >>518 殺菌用の蛍光管一択だね。 LEDで使えるの無いか探したけどむちゃくちゃ高い。 久し振りに プログラム 作りたくなった 無料でいいよ by nyannnyannko
>>519 400nm位なら普通のLEDよりちょっと高いぐらいで済むけど、 365nmのメーカー品とか5mmLEDでも恐ろしい値段するからねぇ。 レジン用のLEDランプを作るぜ!って意気込んで検索したら 笑えない値段を通り越して笑うしか無い値段になってたw 20年前に買ったサンハヤトのUVEPROMイレーサーをまだ持ってるけど、 相当危険な波長らしくアルミケースでがっちり覆われてる。 サンハヤトは高いからイレーサーは自作して使ってたんだけど、 「紫外線なんだから、感光基板もいけるんじゃね? 俺って頭いい!」 と、感光基板をだいぶダメにした思い出・・・・
> 相当危険な波長らしくアルミケースでがっちり覆われてる。 細胞とか、直に当たると死ぬからね。あの白癬菌ですら壊滅。 でも、紙一枚皮膚一枚で遮れるから、アルミの必要はない。水虫も根治は無理。 遮るのは1cm厚ぐらいの青板ガラスでもいい。
作るなら 透明の石英菅 アキバにいけば買えるよ 直見えるのは危険だから それなりの箱も用意
それなりの箱っていっても、お菓子の缶でもOKですね。
>>524 小物の棚のガラスとか、そのぐらいだよ。 一応透明だから、光ってるのが判るしね。 石英管とか言ってる人は、何をしたいんだろう・・・ mikroCをお使いの方に質問ですが、フォントを日本語にしたところ、 日本語の文字が横を向いてしまうのですが、同様の症状を経験された方 居られるでしょうか?もし解決方法が解れば教えていただきたいのですが、 よろしくお願いいたします。
日本語でコメント書く奴のソースなんかろくなもんじゃないよな
mikroCは使わないけれど、コメントに日本語は書けるなら書くよ。 日本語を使わない理由がないし。
>>535 そのとおりだと思うよ。 懲りているんだよ、俺みたいな年寄りは。英半角しか分かってくれないコンパイラがほとんどだったんだよ 日本語といえばShift_JIS (というかCP932) しか選択肢の無かった DOSやWindows98の時代は面倒がなくて良かったな… 日本電気系の機種依存文字と、あとはダメ文字ぐらいしかややこしいの無かったし
>>536 英語苦手だとローマ字コメント書いたりしてねw スミマセン自分も年寄りですw 日本語で書くと言いつつ、>>531 の解決策は示せない矛盾に満ちた連中w 縦書きのフォントを選ぶなとかイチイチ釣りの相手するのも面倒だからでしょ
>>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は、ソースレベルでコピー&ペーストでいけると思っていたのですが、残念 Cで学習型赤外線リモコン搬送波38-44kHzはつくれる?
CPUを占有していいなら簡単 短時間の割り込みがたまに入っても大丈夫 長い割り込みや高頻度の割り込みだとダメかも CPU占有率を下げたいならPWM+タイマー割り込み
>>571 話の持って行き方が逆な奴がいるがw CCPのついてるPICを選んでPWMの設定をしておけば手放しで決まった搬送波を出し続けるよ。 あとは好きなように出す・止めるを制御するだけでいい。 CかASMかは全く無関係。 秋月の赤外線リモコン学習キットのCソースが公開されてるよ
>>569 MAPS=Microchip Advanced Parts Selector よくあるパラメトリック検索、のMicrochip版 久しぶりに来た EUARTの問題で盛り上がってたけど、内部発振クロック使って、タイミングがずれてる気がする ってスギ花粉が言ってた いい加減XCスタンダード版の最適化どーにかしてください 昔作ったプログラムを再エンコしたら容量オーバーしてしまう jalv2っていうの見つけたけど、使ってる人いる?
>>574 学習元の赤外線信号をサンプリングするのにASMであればCLKを数えながら確実な動作をするプログラムを書けると思った。 Cは書き方とどういうコードを吐くか知る必要がある。 >>575 すごい!探してきます。 叩かれるかと思ったけど優しいな >>557-567 ありがとう。 正直種類多すぎて何をつまむかさっぱりだったので 参考にさせてもらいます。秋月のページやら データシートをボケーッと見てたらこんな時間にw まず第一歩はUSBとかは特にアイディアもないし 18325が価格や機能を考えると良さそうですね。 >>578 赤外線リモコン用の受光素子使うでしょ? 受信時に搬送波の周期が関係するのは受光素子まででPICには搬送波関係ないよ。 出力時は関係あるけどね。 >>578 シミュレータのロジアナを見ながら調整すれば良いよ 本物のロジアナやオシロでもいいけど クロックなんか手作業で数える時代じゃない >>580 送信でしょ? >>578 受信して学習するときは数百μsオーダーのON/OFFだから、タイマーで割り込みかけて数えれば十分。 送信時も、搬送波だけCCPで作っておけば、そのON/OFFはやはり数百μsオーダーなので、 アセンブラできっちりクロック数えてとかいうオーダーじゃないよ。 CPUでパタパタ出来るか?っていう質問に見えるけど PIC10F200とかのチープなマイコンで
XCライセンスは企業向けすぎてアマチュアには手が出せない… 非営利ユーザ用9800円くらいの値段設定にすればよいのにね そうすればmedicineのお世話にならなくて済むのだが
サンプルをタダでもらって気に入ったら秋月で買えばいいよ。 18326売ってねえw
>>583 1個50の頃に買っといた 12F510 (割り込み機能無し) で ソフトだけで搬送波を含めてリモコン信号送出問題なし。 1個50の→1個50円の ちなみに、学習リモコンではないので、リモコンの 波形解析は USBオシロで取った波形を CSVに 出力して、スクリプトで解析したよん。
フリーのCコンパイラの決定版ってないの? ないのはアマチュアユーザーが少なすぎるから?
>フリーのCコンパイラの決定版ってないの? フリーのCコンパイラの決定版と呼べるものはないのか?という質問でよいですか? フリーのCコンパイラの決定版ってないのかとの質問ですが、フリーのCコンパイラの 決定版とでも呼べるものがあればみんなそのフリーのCコンパイラの決定版を挙って 使ってますよ。 つまりフリーのCコンパイラの決定版とでもいうべきものは無いということです。
>>587 PIC10F200で大丈夫だって 送信中占有していいなら 手元にあるMCC非対応PIC、 本体無料の着払いで誰か要りませんか? 全てDIPで、 16f914 2個 16f886 9個 16lf88 7個 18f1320 4個 16f648 1個 贅沢なw でもパーツ箱の肥やしになるより幸せだ。 メルカリで300円で出したよ。
>>591 ちょっと複雑な点滅の仕方をさせてるだけで赤外線 LEDをチカチカさせてるだけだからな。 >>592 最初そうしようとは思ってたのだが、USBオシロ を持っていたので楽な方法に日和ってしまった。 12F629/675って今でも秋月の売上上位なんやな 内蔵機能貧弱だし低速クロックで使いにくいから1822や18313を使うことが多いけど Lチカ用途には629で必要十分ってことか
>>601 データシートのページ数が多いと読むのがめんどいw MCC対応なら、データシート解読に割かれる時間は減るよ。
>>603 無いよりは、バグ有りでもあった方がマシでしょ >>604 使わない機能の部分は読まなきゃ良いわけだけど >>607 w 付きにマジレスされてもねえ でも、コンパレータ使わなくてもコンパレータリセットしないと動かなかったトラウマはある。 >>603 俺が指摘しなきゃみんな気づかなかったみたいだけど 趣味の工作だとやっぱり検証が甘いよ ソフトもハードも 間欠的に自分で用意したデータ送るならなんの問題も出ないからどうでもいい エラッタが無くてもまともに動かないUSARTの使い方だしな
何人かがソフトのバグって書いてたけど、結局誰一人として問題点をあげられなかったね 結局エラッタってことで終了
どう考えてもソフトのバグだな。 理屈で考えられない℃素人のプログラム。 ま、Cしか出来ない奴には無理って事だwww
エラッタくんも℃玄人さんもどっちもどっち。 見ててイタいだけ。
エラッタを指摘するとエラッタ君か まさしく>>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ビットなんて。 去年ランサムウェアを踏んじまったよ。 サイバーテロとか言われるだけあって酷いもんだ。 ファイルを壊されている最中に異変に気付き、バックアップで最悪の 事態は逃れられたが、HDの故障とは異なり、PCにつないであった らバックアップだって壊される。 バックアップをより強固にするため、曜日別に繋ぎかえるようにした。
>>640 そもそも1ビットを馬鹿にする思考が議論にならない。 1ビットのCPUを知らないのか。 >>642 1bitCPUの詳細kwsk チューリングマシンとかそういうの? 4000だか4500だかのCMOSにあったような・・・・
>>515 自分の実験では、電池駆動の小さい奴だったけど 消えましたよ。 ROM を三つ縦に並べる。amazon殺菌灯を5センチ程度に。そこに上から紙の箱被せて、10分で消えてた。 >そもそも1ビットを馬鹿にする思考が議論にならない。 1ビットを、1ビットでバカにしているわけではないよ。
>>650 それが全然記憶にないのだ。怪しいメールの添付ファイルを 開いた記憶もなし、怪しいサイトをクリックした記憶もない。 おそらく乗っ取られた悪質なアフィにでも気が付かないうちに 触ってしまったのだと思う。 異変に気付いて再起動するまで、1時間弱だったのだが、 SSD内に69万個あったファイルのうち23万個のファイルが 暗号化され(壊されて)いた。 だからバックアップはWinなんかでやらずにNASベースに仕事のデータを置いて、 UNIX/Linux上の権限きっちりしたのでデイリーにバックアップ取るのがめんどくさくなくて良いよ
権限関係はWinのほうがはるかに先進的。 だからどうやって踏んだか気になって仕方がない。
>>654 やられたのは CTB-Locker(Onionランサムウェア)または その亜種なので詳しくはググって調べてみてください。 p.s. 最近のランサムウェアは金だけ取って元に戻せない のが多くなっていると NHK で言ってた。 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'と入る ホント、何やっちまったんだろ… ( ・∀・) | | ガッ と ) | | Y /ノ 人 / ) < >__Λ∩ _/し' //. V`Д´)/ ←>>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までの場合はぬるぽにアクセスしても特別なことは発生しない。 つまり、バグを見つけるトラップの役目を果たさない
つまり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 に書けるような立派なもんじゃない >>708 俺かよ。素朴な疑問だろ ラズパイとかならぬるぽはちゃんと落ちるんだよ そこが知りたかっただけ オープンドレインの出力ポートを「220Ωで5Vプルアップ&330Ωでプルダウン」した場合、 マイコンの入力端子には出力ポートOFF時に何Vがかかる計算になるんでしょうか?
>>711 MC14500Bのどういう所が 「CPUとよべる代物じゃないし、これならバカにされても当然」 なのか理由を書いてないので分らないが (これを設計したモトローラの技術者が読めば泣くかもしれない)w ちゃんとした1bitのCPUであり、機械のI/Oを何点でもリアルタイムに処理できる。 集積度が低いので外部回路が必要だが、それは時代によるものであって仕方が無い。 4004や8008を今のCPUと比べて機能が低いとバカには出来ないでしょ? 8bitより32bitのCPUのほうが立派とは言えないでしょ? もしかしたら >>711 はPLCのプログラミングの経験が無いのかな? CPUの性能はキャッシュメモリの性能のみで決まる。
PLC? PLCの仕事って何?PLC?PLCって?
>>706 マイコンで0番地にアクセス出来ないと不便だぞ? PICレベルのOS走らせないようなマイコンなら全部絶対アドレスじゃないの
>>724 相対アドレスジャンプが無いと言ってるのか、 物理アドレス=論理アドレスだと言ってるのか、 わからない PICにリタルタイムOS載っけて マルチタスク処理したーい
>>732 そんな書き方だと、次は物理アドレスと仮想アドレスの定義を聞かれるぞ 非常に簡易なアドレス変換も含むのか、いわゆるセグメント方式やページング方式のアドレス変換機能のことを言ってるのか、ページングに限定してるのか、人によって解釈の余地がある >>734 うーん、書き方が悪かったのは謝る 要はMMU搭載してないCPUなんだから物理アドレスも仮想アドレスもないよね ってことを言いたかったのです まあバンク切り替え機能はある種の仮想アドレス-物理アドレス変換とするなら PICにもあるのかもしれないけど、自分が言ってるのはそういうものは含んでないです
一番わからないのは、突然 >>724 を書き込んだ理由かな >>735 AVRならエントリモデルのtiny2313でもマルチタスク出来るのに。 スレッドって起こせないのかな?pthreadみたいなの やはりFreeRTOS?
ごく小規模なマイコンでマルチタスクOSを搭載する必要性は良くわからんが、使いたければPICROSとかがあるし、勉強もかねて自作してもいい もちろんリソースを余計に使うので、マイコンのランクをアップする必要があるかもしれない
tiny2313でマルチタスクって... 完全に趣味の世界だな
>>743 例えば AD変換でアナログ値を1秒ごとに読み取って液晶に表示するとともに、RAMにリングバッファリングし、 PCからの通信の指示で、あるいはパネルのロータリエンコーダやSWで測定条件を変え、 PCから要求があれば現在の測定条件やバッファの内容をプロトコル送信し、 ・・・ なんて測定器を作りたければ、ポーリング(+割込み)で処理するのは大変だよ。 能力の低い奴が作ると、「ファイル転送中は測定できません」なんて制限が付いたりするw 別にフル機能で無くても構わない(しょせんそんなものはtiny2313には実装できない) 低機能のものでも要求される仕様によっては十分に役に立つ場合がある。 つかアセンブラで組めないプロはいないように、 SPを切り替えるだけの簡易なマルチタスクが出来ないプロはいないでしょ? アマチュアにもお勧めだけどなぁ。 複数のやるべき処理ごとに状態遷移図を 考えてラウンドロビン。
>>747 その程度がシングルタスクで出来なくて、 マルチタスクなら何の問題もなく簡単に出来ると思うようだと、 ソフト設計はやめた方がいい アセンブラで組めないプロなんてたくさんいるぞ 世の中を知らなすぎ
世の中の製品に入ってるマイコンでOSレスなものなんて山ほどある >>747 よりはるかに仕事が多くて複雑な処理を行うようなものでも >>747 なんてどれも軽くて簡単なものばかりで、何が難しいと感じるのかわからない >ファイル転送中は測定できません 何MBの転送する気だ?
2,30ステップの命令追加でオーバーヘッドタイム数uSのディスパッチャが出来るし、 通信関係、パネルI/O処理関係など処理を明確に分離できるし、CPUやプログラミングの勉強にもなるし、 アマチュアにはお勧めかなと思った次第です。 シングルタスクで何の問題も無く複雑なプログラムを組める、優秀なプログラマには関係の無い話ですね。 無視して下さい。
こんな争いしてるからここの板はレベル低いって言われちゃうの。 できるできないじゃなくて シングルタスクで何でもできるけど生産性可読性保守性を高くするためにマルチタスクを使うってこと。 そう言うニーズがないなら黙ってシングルタスクプログラミングやってりゃいいだけ。
>>753 良いこと書いてるんだけど、余計な話が 多すぎて誤解されたり関係ないところに突っ込 まれたり。話しの本質にレスされていない。 まさにオーバーヘッド多過ぎの文章でしたな。 >>753 マルチタスクに夢見すぎだと思う マルチタスクはシングルタスクよりも勉強しなきゃならないことが多く、逆にアマチュアには向かない OSが簡単に作れるようなことを書いてるが、OSを作るとなるとさらに難易度は上がる 超小規模マイコン用の夢みたいなOSが作れるならそれだけで商売になる 実際に、超小規模マイコン用のOSが一般的でないことからも、マイナス要因が大きいことはわかる >>754 君も夢見すぎ 生産性可読性保守性が上がるなら、超小規模マイコンのOS使用が一般的なはずなのに、実際はそうじゃない >>755 確かにオーバーヘッドが多過ぎるかも?w 誤解されないようにと、ついつい説明が長くなってしまうのは私の悪い癖です。 技術的な内容でもう少し書きたい事(tiny2313用の小さなディスパッチャなど)もあったのですが、 これで終わりにします。どうもお騒がせしました。 >>757 マルチタスクの恩恵を受けたいなら それなりのCPUを持ってくるのが当たり前。 対価も払わずメリットだけ得ようなんてさもしい奴だ。 PICやAVR用のマルチタスク対応標準ライブラリなんてあるの?
>>756 中学生にもなれば敵動かしながら自機を動かして効果音ぐらい鳴らしますよ。 >>761 割り込みで違うタスクを動かしてるならマルチタスクです。 そうだ、PIC に Windows を移植すればよいのだ Sleep 中に突然起き上がって Windows update を始めるから覚悟しろよw。
つか、pic rtosとかavr rtosでググりゃいくらでも引っかかる話だよね?
いくらでもって まともに使えそうなのはFreeRTOS位 PIC18以上限定でGPL チップメーカーがフリーで提供して、統合環境でデバッグ出来て、サポートも受けられるようなのと比べるとずいぶんと遠い
大量に使う客が望まないからあり得ん。 いくらホビイストが吠えてもな。 それより自分の手を動かせ。
金を出すつもりが微塵も無いのに「サポート」とか、基地外過ぎる。 そもそもPICレベルなら32ビットでさえ自作OSで十分。
>>773 金を出すつもりが無いって 当然サポートを期待する時は基本月10K以上だ 試作で終わるときももちろんあるが > そもそもPICレベルなら32ビットでさえ自作OSで十分。 自作OS www そんなもん普通は使わんよ 普通はOSレス 処理にもよるけど マルチタスクを使う理由はタスクを分離したいからに決ってるw しかしマルチタスクというと既成のRTOSしか頭に浮かばないのか・・・ アセンブラ・コンパイラやモニタ・デバッガなどの自作なんて思いも付かないんだろうな。 検索して何でも切り貼りで済ませてしまうコピペ・プログラマだと、 AI時代になると切り捨てられてしまうかもよぉ、大きなお世話だけどw
実現したい事を仕様にまで分解するのは永遠に人間の仕事。 機械が上手にやってくれる事は機械に任せればよろし。
8086とかでも普通に自作OS(つーか、スケジューラに タスク間通信を追加した程度だけど)使ってたけどな。 >779の言うとおりで、タスクを分離して見通しを良くして、 楽したかったから。ごく基本的なテクニックだわな。 まぁ、今はCPUで擬似並列処理するより、FPGAで本当に 並列処理させてしまうってうい世の中かもしれないけど。
上を作るのが好きな人、下を作るのが好きな人、いろいろいる 趣味を強制するな
おれもどっちかっていうと下の方が好きだが コーディングもあれも
貧弱なリソースの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しか出来ない奴は頓珍漢だなwww 絶賛してる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させてください。
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 5桁なんてのもあるのか・・・・節操無さ過ぎ
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 アドレス空間が1つで16bit だな。 PICはアドレス空間が複数有る。 >8bitCPUはRAMが64KBのイメージ。 これを16ビットアドレス空間と考える時点で、 複数の空間があるか、外部ハードでバンク切替しているかが前提になってるよな。
18326のすごい所は、ROMの多さもあるけど、ペリフェラルを好きなピンに割り当てられる事なんだよ。 配線がすごい楽なんだ。 ICSPのピンは動かせないけど。
自慢のつもりで書いてる訳じゃないだろ 自慢に受けとるなら そりゃアンタ、このスレの悪い毒にヤラレテしまってるわ
>>878 俺は自慢のつもりで書いた。 PICとESP8266しか触ったことない人間だから。 ふーん、そうなんだ、俺はこの機能を知ったとき、 「ツマンネところにエネルギ使うなよ、もっとやる事あるだろ」 と思ったけど、人それぞれだな。
CAD使うならオートルータでどの足だろうとで大して関係無い。
DIPパッケージのんrqgっsっrんは卯8え3つおいー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、40MHzのPICでRAMが一番大きい物ってPIC18F2620の4KB?
>>880 同じように思った でもピン数が少ないヤツだと便利だと思うときもある まあそんなところより基本機能をどうにかしろって感じ PICのコア、ROM, RAMは最低ランクだから >>883 わざわざそれを選ばせるような条件付けだな >>884 に同意 今やってる案件はRAMがDDR3 512MB もちろん外付け PICじゃないけど プロの方や基板を起こして量産する方には重要じゃなくても、 秋月でC基板と一緒に1個買って、ブレッドボードで試作する俺には重要 この機能のおかげでROMが減るというなら困るけど。
真逆で、完全に機能とPINが決まってるヤツとかあるよな ピン数自体は数百本とかあるんだけど、GPIOがちょっとしか使えなかったり
電源5V、制御3.3V にすればマイコンの選択肢が増える
PIC32MX270F256B ならRAM 64KB
PICにはPICなりに生きる場所がある・・・ それに文句を言って自分の判断能力の無さをさらけ出すのは やめよう。 どんなものも適材適所で使ってこそ能力が発揮できる・・・ 文句言うやつは所詮ARMしか使えないやつでしょ・・・ PICに必要性を感じているやつだけ使えばいい・・ それだけだ!!!
>所詮ARMしか使えないやつ 所詮っていうか、必要十分な人材だったりして。 PICはPICに馴染んだ人にとって使いやすいマイコンだと思います。それで良いと思うのですが。
量産の製品に載らないとつぶれるぞ 趣味の工作でいくら売れても全体の数量からしたら誤差
PIC半年目だが、こんな面白い物はないな。 仕事は組み込み用のx86基板の回路設計とPCAT互換BIOSまでやっているけどPICはワンチップで色々できて面白い。 もっと前に手を出せば良かったなぁ。
マイコンが載ってる事すら知られないような所で動いてる、それが本来のPICの働く場所。
>>902 が心配するようなことじゃないと思います。 知らんだけで売れているから存在するんですよ。無知のひけらかしは良くないです。 >>893 これ、良さそうだ、今度通販利用する時に買ってみる。 ありがとう。 >>904 LED懐中電灯の制御基板にも乗っている。 ただ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に機能モリモリ 電源2本と書き込み3本だけ決め打ちで後は自由アサインにした8/12/14/16/18/20/24ピンシリーズでどうよ? xxの部分をピン数って事で
プレミアムフライデーだったから秋月とあきばおーで金使って来たぞ。 雨だったけど結構賑わってた。 PIC16F18346買った。160円。 >>938 秋月も値札シールがどんどんおしゃれになってきたな ホームページはいつまでも相変わらずだが 秋月のオシャレ化…そのうちドレスコードが導入されて 正装でないと入店お断りになったりしてw
新製品コーナーに売ってたから袋入りだったけど、 その他大勢のPICはバラで引き出しに入ってたよ。
>>940 でかいリュック背負ったまま入店、は冗談抜きで禁止して欲しいわ。 武器を持ってないことを証明するために完裸入店をルールにしようぜ
>>942 近隣にロッカー有るといいんだけどね アキバをリュック背負って歩くとつくづく思うわ ロッカーで良ければ、バイク駐輪場の辺りとかパチ屋の壁とかあるぞ?
一般的に、機能が増えると、不具合が出る可能性が増えるので、 十分なコストメリットやどうしても欲しい機能が無い限り従来品を選択するな〜 同系列ですら、クセがあったりする。 例えば、ぼくがメインで使ってる、PIC16F1825は、AD誤差が、PIC16F1824と異なる。特に PIC16F1825は、Missing codes=2が出ているから、10bitでは使えない。 どちらも、2bitのgain errorがあるから、要注意なんだけど。
PICが出て何十年だろうか。そろそろ枯れてもいいのではないか。
>>947 枯れるほどに成熟してないし、みんなの話に出てくるものはシリーズとしても最近のモノでしょうが。 別に愛用していた84A以前が手に入らないから新型もっとちゃんとしてくれって言うなら分かるけど、そういう訳じゃないでしょ CPUは枯れてるだろ。IOは変わってくから市場でてから分かる不具合は仕方ない。 鬼の首を取ったように騒ぎ立てるのは下品。
シフトレジスタでエラッタ出すとかね。本気で言ってるんですか? 実装の蓄積のない50年前なら分かりますよ。ここは1年目の新人が設計してるんですか?
古くて下品なコアでもあれこれ厚化粧すればそれなりに使えるってことだ。 いわば大年増の厚化粧と言われた小池都知事みたいなCPUだなw
>そろそろ枯れてもいいのではないか。 なんで枯れてもいいのでしょうか。 世間の時間が止まっているなら別ですが、求められることは変わっていくものです。
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を勧められるよ
lud20220930161315ca
このスレへの固定リンク: http://5chb.net/r/denki/1470076841/ ヒント: 5chスレのurlに
http ://xxxx.5ch
b .net/xxxx のように
b を入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「PIC専用のスレ Part54 [無断転載禁止]©2ch.net [無断転載禁止]©2ch.net YouTube動画>6本 ->画像>13枚 」 を見た人も見ています:・★クーポン交換専用スレPart51 ©2ch.net ・★クーポン交換専用スレPart52 [無断転載禁止]©2ch.net [無断転載禁止] ・PIC専用のスレ Part54 ・【痔瘻】痔ろう・肛門周囲膿瘍専用スレpart33 [無断転載禁止]©2ch.net [無断転載禁止] ・PIC専用のスレ Part55 ・PIC専用のスレ Part53 ・PIC専用のスレ Part51 ・PIC専用のスレ Part52 ・Sissy専用スレ Sissy hypno & Sissy caption 雌堕ち Part.2 [無断転載禁止]©bbspink.com ・【ご一緒に】マギメモ マルチ専用スレ part17【目指せ+99】 ©2ch.net ・【DDON】シーカー専用スレ【Part17】 ©2ch.net ・PIC専用のスレ Part 57 ・PIC専用のスレ Part 56 ・PIC専用のスレ Part 59 ・PIC専用のスレ Part 59 エラッタの話題も歓迎 ・eBASEBALLパワフルプロ野球2020 栄冠ナイン専用スレ Part1 ・C専用のスレ Part 59 エラッタの話題も歓迎 ・【PC】YamatoN専用スレpart14 ・【6年間】ヘタレデブ召喚・炙り出し用スレPart5【引きこもり】 [無断転載禁止]©2ch.net [無断転載禁止] ・【PC】SPYGEA専用スレpart53 ・【PC】SPYGEA専用スレpart50 ・【PC】YamatoN専用スレpart22 ・実況パワフルプロ野球2016 パワフェス専用 Part5 ©2ch.net ・【まなかです】まなか22歳専用スレpart5【タカり続けます】 ・【PC】SPYGEA専用スレpart56 ・【PC】SPYGEA専用スレpart59 ・!chkBBx: 確認専用スレ part59 ・!chkBBx: 確認専用スレ part56 ・【PC】StylishNoob専用スレpart545 ・【PC】StylishNoob専用スレpart592 ・【獣人】メスケモ専用スレPart5【竜人】 ・【FEH】ファイアーエムブレム ヒーローズ無課金専用スレPart244 ・【FEH】ファイアーエムブレム ヒーローズ無課金専用スレPart124 ・HUNTER×HUNTER クロロvsヒソカ 共闘説専用スレ No.2©2ch.net ・【PC】SPYGEA専用スレpart20 ・!chkBBx: 確認専用スレ part74 ・【PC】StylishNoob専用スレpart364 ・【PC】StylishNoob専用スレpart190 ・【DDON】ソーサラー専用スレPart19 ・★★クーポン交換専用スレPart 64★★ ・【PC】StylishNoob専用スレpart256 ・★★クーポン交換専用スレPart 66★★ ・★★クーポン交換専用スレPart 65★★ ・【PC】StylishNoob専用スレpart185 ・【PC】StylishNoob専用スレpart173 ・【PC】StylishNoob専用スレpart181 ・【PC】StylishNoob専用スレpart168 ・iphone11・11PRO回線切断専用スレ Part5 ・【100k〜】最高級イヤホン専用スレPart34 ・【100k〜】最高級イヤホン専用スレPart20 ・【剛】草なぎくるみ専用スレPart1【大好き】 ・【何度でも】 MagicalGO 専用スレ Part14 【蘇る】 ・【獣人】メスケモ専用スレPart15【竜人】 ©bbspink.com ・【LINE】クーポン譲渡専用スレ Part5【コンビニWiFi】 ・【DQ10】ドラゴンクエストX プクリポ専用スレPart24 ・実況パワフルプロ野球2018 パワフェス専用スレPart1 ・【DQ10】ドラゴンクエストX プクリポ専用スレPart38 ・ラブライブ!サンシャイン!!聖地巡礼専用スレ Part58 ・【獣人】メスケモ専用スレPart30【竜人】 [無断転載禁止]©bbspink.com ・【獣人】メスケモ専用スレPart21【竜人】 [無断転載禁止]©bbspink.com
18:51:09 up 17 days, 5:15, 0 users, load average: 8.44, 8.80, 9.03
in 0.074734926223755 sec
@0.074734926223755@0b7 on 122908