PIC専用のスレ Part 57
レス数が1000を超えています。これ以上書き込みはできません。
ソフトできっちり異常を検出することが重要
これが正常に行われない検出だけをハードに頼る
だからハードはシンプルで良い >>47
そんなに高機能がいいならCortex-M0マイコンでも使ったらいいんじゃないかな?
メモリが少ない品種なら安いのあるよ 32bitCPUコアならC言語との相性もいいし、
Cortex-M0のようなCPUコアなら
扱うデータ型によっては8bitCPUを使うよりコードサイズが小さくなるかもよ
コードサイズに関してはPIC32でMicromipsが使えるやつで
有償ライセンスのXC32を使った場合でも同じことが言えるかもね そういえば、
こんなのあるんだよね
PIC32MXマイコン実装基板 PIC32MX370F512HT−I/PT
http://akizukidenshi.com/catalog/g/gM-12417/
1枚 ¥700(税込)
こっちはなんで144pinのにしたんだろうか
64pinの方が扱いが楽そうなのに
PIC32MZマイコン実装基板 PIC32MZ2048EFH144T−250I/PL
http://akizukidenshi.com/catalog/g/gM-12418/
1枚 ¥1,670(税込) >>55
使わないピンは繋がなければ良いじゃない。 パスコンと発振子のパターンが無いと使えん
長距離引っ張れって?
汎用変換基板ていうのが無理がある 専用基板でグランドと電源はしっかりさせないと危ういね。
クロックだけなら外部から入れればなんとかなるかもしれない。 QFP100で変換基板使ってやってたが案外なんとかなるよ
蛇の目基板に全部つけたやつとできるだけ変換基板側につけたやつと両方作ったけど変わらんかった >>55の、1670円の商品の、
PICの上下にある白い四角、
たぶんシルクだと思うけど、
何のためにあるんだろう? やりすぎ防犯パトロール、特定人物を尾行監視 2009年3月19日19時7分配信 ツカサネット新聞
http://headlines.yahoo.co.jp/hl?a=20090319-00000026-tsuka-soci
この記事で問題になった通称やりすぎ防パトは、創価学会と警察署が引き起こしていたようです
掻い摘んで説明すると
・創価学会は、町内会や老人会、PTA、商店会等の住民組織に関し、学会員が役員になるよう積極的に働きかける運動を
90年代末から開始し、結果、多くの住民組織で役員が学会員という状況が生まれた
・防犯パトロールの担い手は地域の住民と住民組織で、防犯活動に関する会議や協議会には、住民組織の代表に役員が出席する為
防犯活動や防パトに、創価学会が間接的に影響力を行使可能となった
・防パトは住民が行う為、住民が不審者や要注意人物にでっち上げられるトラブルが起きていたが
創価学会はその緩さに目をつけ、住民組織を握っている状況を利用し、嫌がらせ対象者を不審者や要注意人物にでっち上げ
防パトに尾行や監視、付き纏いをさせるようになった
・防パトは地元警察署との緊密な連携により行われる為、創価学会は警察署幹部を懐柔して取り込んでしまい
不審者にでっち上げた住民への嫌がらせに署幹部を経由して警察署を加担させるようになった
・主に当該警察署勤務と考えられる創価学会員警察官を動かし、恐らく非番の日に、職権自体ないにもかかわらず
私服警官を偽装させて管轄内を歩いて回らせ、防犯協力をお願いしますと住民に協力を求めて回り
防犯とは名ばかりの、単なる嫌がらせを住民らに行わせた(防犯協力と称し依頼して回っていた警察官らの正体は恐らく所轄勤務の学会員警察官)
※これに加えて防犯要員が同様のお願いをして回る
・こうして防犯パトロールを悪用し、住民を欺いて嫌がらせをさせつつ、創価学会自体も会員らを動員し、組織的な嫌がらせを連動して行った
つまり警察署に勤務する学会員警察官、警察署幹部、創価学会が通称やりすぎ防犯パトロールの黒幕
詳細は下記スレをご覧下さい(現在スレが荒されてますので、テンプレと87の連絡先さえ確認して頂ければokです)
やりすぎ防犯パトロールは創価学会と警察署の仕業だった
https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/1-87 >>62
シルクだと精度でないよふつう銅箔ランドで作る
シルクは実装指示用だ いや、この基板の場合上下の細長いシルクはメモ書き用だな
フィディシャルマークは正方形の銅箔 ICD4秋月で販売開始
思ったより高いな
でも多分買っちゃう えーPICKIT3で間に合わないほど何するのですか
そんなに金出すなら自分ならデバイス毎乗り換えるよ(ARMとか)
仕事でPIC指定なら仕方ないけど 白帯は俺もメモだと思う
>>68
PICKIT3は8bitくらいまでが限界
16bitや32bitだと遅すぎて
ARM?
それで何か解決する? コアの性能云々ならPICに限定する必要はないでしょうけどね
なんで直ぐに他のデバイスと比較したがるんだろうw >>72
armなどは安く環境を作れます。
それなりに快適なものを。
PICを使うのが前提なら解にならないけどね。 性能だけならまだしも、取り得の値段でも負けるような状況なんだから
そりゃ、不思議に思うだろ MIPS M5150 のコア性能は悪くない
ARM Coretex-M7よりも性能もワッパも良い
問題はエラッタ
EFのI2Cはひどいな
使い物にならん >ARM?
>それで何か解決する?
ICDが高いな、って流れの話なら、32ビットコアで実用的に使えるバッガに安いものがあるってことはひとつの解決でしょね。
でもここPICスレなんだし、PICをどう使うかという流れの話で、ARMにするわ、は何の解決にもならんな。
情報を追いかけてないのですが、PIC32CZってその後どうなったのでしたっけ。 デバイスの選定で重要な要素は沢山あるけど、
・安価な開発環境
・デバイスの価格
・デバイスの中長期的な供給ルート
・デバイスに関する情報量
などが重要。
特にARMの場合、デバイスとしてみた場合には各社で互換性が無いので
供給ルートと中長期的な安定供給が不安になる。
確かにPICのエラッタだらけも辛いものがあるが。 PICブランドでもないARMについては質問もほどほどに。
ARMスレで尋ねる方がきっといい。
CZのことを尋ねた俺も悪かった。 >>80
PICKIT3もSTLinkも大差ないと思うけど
値段も性能も
快適な環境が欲しいからICD4なわけで
STM32はデータシートにほとんど何も書かれてなくて
自分でコードを書くには向いてないと思う
STM32CubeMXは非常に強力ではあるけど >>47
8bit マイコンって、システムの中心ではなくて、周辺部品の扱いだからな。 PICユニークなことを前面にしないとこのスレの存在意義が。
(ちなSTlinkはパチモン\300でライブラリはmbedのを使うとすごく楽)
ethernet使う様な規模になると乗り換えたほうがいいような希ガスる
PICじゃなきゃできないことって何だろう
5V電源8pinPICでPWMでクロックジェネレータとかにつこうてる
他だと3.3Vばかりで5V電源ないのよね > PICじゃなきゃできないことって何だろう
> 5V電源8pin
↑ これだな、俺の選択理由も8Pin以下品の品揃え pickit4なんてのが予定されているのか・・・
>>86
まあ、CPUも住めば都なんで、慣れてるのが一番ですよ
ですが、mbedなんかでethernet使ってみるともう楽ちんで。
あのライブラリはよくできてます PICKIT4の公式発表ってあったっけ。前から願望、噂だけはあったけど。
出るなら、PIC&アトメルデバイスのサポートでしょうね。
今のところ、AVRは正式な廉価版ライターもなくなってるし。 とりあえずPICKIT3とAVRISPmkIIだっけか、両方もってるのでなんとかなってるけど
統合機ほしいね確かに 統合するけどクローズドHWです、てな事になりそうな予感。 >>88
Pickit3は、ファミリー変わる度に、ファーム書き換え必要だからな。 ていうか、ファーム書き換えがイヤだから複数持ってるの?
そんな頻繁に書き換えるわけでもないだろうに mplabXIDEの4.15にupしたら、ファームのリカバリメニューにpickit4の選択肢があったので
もう間もなく出るんじゃないかな リリースノートの中のデバイスサポートリストにもpickit4があるが
まだββだ
pickit3よりサポート数少ないし
もしかしたらicd4と一緒で速度を上げることが主眼なのかも
まあぼちぼちだね 「MPLAB IPE」の事かな? あれは酷いコンセプトだね
対応DeviceFileを探して、
昔の "PICkit 3 Programmer App and Scripting Tool v3.10" 辺りを使った方が断然マシ。
対応済みのデバイスなら探す必要も無い 書き込みが遅いとか吠えてるのは脳内デバッグもロクにしないで「取り敢えず走らせてみよう」って輩 >>100
趣味の電子工作マイコンスレらしい書き込みwww PICkit2とPICkit3は当然見たことあるけどPICkit1ってどんなのだったんだろう
というかそもそも存在したのかな
アプリケーションノートAN589だっけ、パラレル接続ライターのこと? Pickit4出るならスマホやタブレットから書込みできるようにしてほしいな…
それとサイズ半分、値段半分にして Pickit3はUSB電源だけでPCなしで書き込みできる機能なかったっけ pickit on the go とか言うやつだな
要はメモリコピー機
>>107
BTか8266使って自作 >>112
製造工程で、ICPを担当する人に使ってもらう
たてまえ上はPICKITを製造工程ではつかわないで、ってことになってるはずだけど。
GNDがPCとは繋がっては困る機器にプログラムする。あるかな?
パソコンを近くに置けないところで。
デスクトップ機で開発している人ならあるかも。
納品ずみの一品モノをアップデートするのに、お客さんにPICKITを送ってやってもらう。 >>117
工場なんかは持ち込みが厳しいところありますねw
生産装置の1部にPIC使う事は結構あるしね 自分が使わない機能があるのは許せないって感じなのかな。
そういう機能を付けたマイクロチップに聞けばどういうことを想定して
いるか分かるんじゃない? pickit2はもうサポート外か・・・
>>120
だれがどんな状況で使ってるんだこんな機能? という素朴な疑問じゃないか?
大体想像通りだと思うが、pickitは試作用だという基本的事項が。
だけどほかに方法もないから(使えるなら)使っちゃう ということでは
まあ、勝手な想像だが9割のユーザーには不要な機能だと思う
厳密に保証された書き込みを現場でやるにはどうすんだろね >>107が答えを書けば終了なんだけどねえ
なぜか書かない ?
なんの答え?
何か見えないものを見ているのか? 日本語が読めないやつは無理して日本語掲示板に書き込まなくていいぞ $4.04エラー出すとこんなのでましたけど
ATTINY104-Xplained Nano
Coupon Code: 404Special >>122は
>>107と、>>108が関連したものだという理解なんだと思う。
(PCは持ち運びが困難だから)スマホやタブレットから書き込みたい
PC(どころかスマホやタブレットすら)なしで書き込みできる機能なかったっけ 当然だろ
>>108が>>107と無関係に書き込まれたと思うやつがいるか? >>122が>>123の質問に答えてくれればいいのだけどな。 ID:PTU6MrA7
>書き込まれたと思うやつがいるか?
日本語を読めるのであれば、いくつかの解釈ができることはわかるはずです。
そのいろいろな解釈ができる中で「俺と同じ解釈をしてほしい」という願いは、
日本語がわかるかどうかではなくて、我儘だと思います。
曖昧さや解釈の余地をできるだけ排除して議論する方が良いと思いませんか?
たとえば、>>130も>>129に対して向けたものなら、>>129にアンカーを打つべきだと思います。
で、>129に対して向けたものと仮定してですが、
>>112が「スマホやタブレットから書込みできるようにしてほしいってどんな状況?」であれば、>>107が答えるべきことです。
でも実際は「PC無しで書き込みたいって どんな状況?」ですからね…
これだと、>>108以下で議論されている機能についての漠然とした疑問だとも解釈ができます。 PICの話をしようよ。
そんな他人の言葉尻を捕まえて解釈の仕方がどうのこうのとゴネても当人は反省なんかしないよ。
書き込む側は出来るだけ誤解のないように注意して、読む側は出来るだけ書き手の状況を
好意的に理解するように努めればいい。
それでも分からないならレスしなければいい。 スタンドアロン書き込み機能、便利に使えてるよー
という実績経験ないですかね。
(納品後の現場でupdateをヒーヒー言いながらやる状況位しか思いつかない)
使ってる人いないとなれば次のバージョンからは削除されるのでは
保持メモリの分コストupだろうし
逆に売り機能だとmicrochipが思っていれば強化されるかもしれないが
でもあれは個人的には要らないか、オプションでいい機能だと思う
出先でパラメタ調整して書き込み、という状況ならノートバソ使うだろうし > (納品後の現場でupdateをヒーヒー言いながらやる状況位しか思いつかない)
まぁ、こんなところだな。 実装前なら返品して書き直してもらう(勿論費用はかかるけど)
スタンドアロン書き込み機能
IPEの謎仕様と違い、使わなければそれで済むわけだし
あ〜だ・こーだ 言うレベルではないな 使わない機能に金を払いたくない
金額の問題じゃなくて >>136
じゃあ、金払って取っ払ってもらえば良い。 >日本語が読めないアホが多いな
いや、ただの絡まりあほだと思う 「書くアホーに読むアホー、同じアホーなら書かなきゃソンソン」
はこの場合成立するのだろうか? >>82
CubeMXが強力だからHAL使え、がSTのおすすめかもね。ペリフェラルのレジスタはデータシートよりもリファレンスマニュアルが詳しい。
こういうところにも芸風の違いがでてくる。だから、PICに慣れているからPICを使う、のも合理的な理由だよ。 見た目はシールでも貼っとけばいい。
JTAG対応って事はAVRやSAMも対応する余地ありって事だね。
買わないと思うが歓迎。 PICkit4の情報出てたのか。
4線JTAG(というか普通のJTAG)、SWDサポートは将来のSAM対応でしょうね。歓迎。
PCなしでの書き込みが強化されたのかな? SDカードサポート。 MicrochipDirectの価格は3と4で同じか…
秋月価格も同額を期待 direct価格 $47.95か
ロゴにonthego用隠しスイッチがあるらしい 買うの辞めとこうと思ったがやっぱり買おう
プラモ業界でこうたやめた音頭というのがあってな、
よっしゃこれこうた!(買った)と棚から取り、
いややっぱりやめとこうと棚に戻す
この動きが
傍から見ると音頭を踊っているように見えるためにこう命名されたらしい。
踊りそうだ ごめん、この動きをくりかえす、という部分が抜けていた
ここがキモだったんだ 問題は今持ってるpickit3より作業が捗るかどうかだな
まだサポートはbetaだし、pickit3で不可能なことが出てきた時点で
更新検討するかな 8bitだと変わらない
32bitだと速い
て感じかと
PICKIT3は遅すぎる
PICKIT4で普通になる
を期待 USB3.1対応してデバッグ作業がサクサク行えるとありがたいのだが USBの制約じゃなくてHIDの制約じゃなかったっけ ICD4がでてICD3がディスコンになると嫌だから買いました。
今まで我慢してたけど、旧IDE使ってるのでXIDEのみ対応だと、必要になると困っちゃうので。 PICどっぷりな人って結構いるのね 間口広げたmicrochipの戦略勝ちだな
でも、8/16/32でぜんぜん秋てクチャ違うから
サポートするの大変だよねツールとか高くなるし分ければいいのに スタンドアローンのプログラマソフトは出るんだろうね メーカーからすれば少量多種生産なんて避けたい。
BOM代なんて数出せば叩ける。 一昔前のICE考えれば全然安いか
でもなぁトレースメモリ必要になったことないなぁ
ブレーク掛けて変数みられるだけで御の字だわ
>>166
eclipseベースのCCSはクソですなw 組み込みをやるならeclipseに慣れておいた方がいいぞ TrueSTUDIOもe2StudioもCCSもeclipse それしかなければ諦めて使うけどできれば避けたいeclipse
我慢して使ったのはxilinxのSDKだったかmicroblaze用 使いなれてないツールはクソとかいう
使いこなせない自分がクソだった pickit3ってUSB 1.1相当なんだね
クソだ >>172
High-speed 対応にしても、書き込み時間には効果ないだろ。 ワード単位で書き込む奴は、ワード単位でms単位の待ち時間が必要なので、USB1.1のバンド幅の1%も使うかどうか。 >>174
書き込み時間もそうだが、PickitからPIC への通信速度自体が。 デバッガはコード書き込み時だけ通信する訳じゃないぞ 規模の小さなコードや自動生成コードとかならそうかもしれないねえ
デバッガもいらなかったりしてwww デバッグでpickit使うことはあまり無いな…
タイミング見るときは空きピンをHLさせてオシロ観測
変数見るときはUART繋いでPCで表示 いつの時代だよ
もちろんそういうデバッグが役立つ場合も多いけど マイコンの設計も古ければ
ユーザーの考えも古い
それがPIC かといってICEまで持ち出してデバッグするのは牛刀割鶏やし やりやすいやり方でやれば良いし、それが使えないことをしたいのなら他のものを選べば良くて、
そんなことは個人的な事情にすぎないのに。
他人がしていることに煽り文句をいれて批判することなんてしなくていい。 なんか違う
このスレはPICの悪い点を指摘すると
全力で反論する信者がいるってこと
「pickit3が遅い」に対して
UARTやポートでデバッグするから遅くて良いとか
書き込む時間は変わらんとか
意味不明の反論を書く
遅いからpickit4の高速化が宣伝文句になってるってのに PICが好きなのは良いけど
悪い点はちゃんと悪い点として認識した方が良い それより秋月PICプログラマーが未だに販売されてるのが謎
値段はpickitと変わらないのにサポートは5年間放置
最新デバイスもサポートされてないし
とっくに販売終了になっていないとおかしい 悪い点
エラッタ、スペック詐欺
コア性能が悪い (8ビット)
自動コード生成のコードがクソ
(無料のだと)コンパイラの吐くコードの質が悪い
pickit3が遅い >>186
でも、同じやりとりが何度も繰り返されるのはおかしいよ。
悪い点がある、という指摘はそれでいい。たまになら。
たいてい既出、頻出なんだよな。新しいことがない。
使っている人は、そんなことは分かっていて、それでも良い点に着目して使っているんじゃないのかな。
なのに、まるで新事実を発見したかのように繰り返したりリストアップしたりしている人がいたら、
それは当然ながら、残念な人に見えちゃうと思う。 ソレノイドかなんかで電圧かけるのを
数ミリ秒以下にしないといけないのに
間違えて数秒待つ設定になってて
煙出てビックリした >>186
USB の速度より、2線から4線になったのが大きいだろ。
後、頻繁なファーム書き替え不要になるだろうし。 >>186
> 「pickit3が遅い」に対して
> 書き込む時間は変わらんとか
> 意味不明の反論を書く
この意味がわからないなら意思疎通が難しいが
書き換え速度は早くならないよ なんでICDって電話線なんだ?
ターゲット基板にモジューラージャック付けろってか
PICkitのコネクタの方を標準にしてくれよ 幸せになりたければプログラマもデバッガも自作すればいいんだよ。
なんならコンパイラも(アセンブラも)自作すればいい。
ヒマ潰し電子工作のアマチュアには時間がいっぱいあるだろ? >>197
俺は前はコンパイラもアセンブラもシミュレータもWriterも
全部Linux上で自作して快適だった。
Writerはプリンタポート使って信号上げ下げする奴
しかしチップ種別が増えて書き込みタイミングや
コンフィグビットが多様化し
pcにプリンタポートも無くなってめんどくさくなって
やめちゃった。 > pcにプリンタポートも無くなってめんどくさくなって やめちゃった。
ackの代わりにbusyを使うやつ、作ったなぁ。
M80にマクロ満載して、PICのアセンブルしてたw 昔の人は素直に動く外部バス大好きだよね……。
PC98のCバスとかも好きだって聞いた。
PCIやPCIeは安価にはそういう用途には向かないんだろうね……
遅延が怖くなければPICでもなんでも使えばいいのではと思うんだけど。
実際AVRでプリンタポート式のCNCの置き換えとかもしてるんだし(ごめんどこかで見た程度の知識しかないけど)8bitでもROMやEEPROMのサイズからデータの蓄積がネックなだけで出来ると思うけどなぁ。 >>200
PC98のCバスやAT互換機のISAバスは
アドレスデコードと単純なI/Oで外部機器と接続できた
別に好きだからという訳じゃないだろう
PCIやPCIeは複雑なプロトコルで通信してて
アマチュアが簡単に利用できるようなものではないだろ >>201
ISAもそうなのか、教えていただいてありがとう。
Cバスはソフトも書ける営業が(と言うか営業に行かない営業が)言ってたので仕事してる気にはなってたんでしょう。
PCIなんかはサウスブリッジまで経由しないといけないうえに66MHz対応の基板とか零細にはレベルが高すぎたのかなと当時は思ってました。
今になってみれば、色々と経験してきたこともわかる気がしますが、デジタル高周波とアナログデジタル混在とか色々と今から経験するべき年齢じゃねえなと思いながら格安派遣だけが売りの人生だったと振り返っている様です。
PICだっていろいろできるんだろうになぁと思う前に、日本人的にはじゃあ作れよタダでとなるんでしょうなぁ(と自分が使われる相手には言いたい、他人には別にそんな事は言わない)とか思う。
PICにはPICの仕事を、無理ならADCとかDACとか外付けして許可貰ってなんでこの値段なのってのを説明できれば零細は良いんですよ……(と企業相手に甘えられてるのも今のうちだけだと思いますけどね。) >>203
(もう壊れてるけど)これ以上壊さずに30年仕事できなきゃお国の荷物ですよw
そんな生活じゃ、あと10年もすれば非国民言われちゃうかもねw
このまま行けるかなと思ってたけど、今の職場は手取り200万切るのと、開発に関われないので甘えてないで転職資料纏めてます……。
一番最初に派遣に入った理由は色んな会社で色んなICと関わって色々覚えたいだったはずだよなぁ、と今頃ながらに思い出してたり……。
イイトコ行けたらそれから先はまた考えるようにしますよ、趣味は趣味で別に進んでますけどね。 20年やっててこの程度の知識なら、まぁ200万切ってもしょうがないだろ
もっと金欲しいとか思わずに死なない程度に食ってくくらいの気持ちでやってけば? >>201
PCIはアドレスとデータをマルチプレックスしているだけで、バス幅での1回アクセスができました。
パケットに載せるようになったのはそれより後では? >>205
その思考は甘いと思いますよ今ですら想定できる寿命が100年の時代に生きてるんですよ我々は、それでももっと過酷な国での大臣の言い訳で70歳までは働いて欲しいかなぁ……?
ってのがスウェーデンなんかの日本でもてはやされる福祉先進国ですらあるのに、我々はもっと長い寿命なわけで、ヘタすると若者がいない分75やら80やらまで働かされるわけじゃないですか。(今はそこまで出てないけど)
今は大丈夫なんて言い訳になりませんよ、我々には”退職金”なんてないんですからね。
切り詰めてないかと言われるとウソになりますが、外食と薬と、レトルトで休日1食に平日の夜食は切り詰めてますよ、今でもBMIが太り気味なので。
本当に痩せるかどうかなんてわかりませんけどね?
でも痩せるかどうかより、数百万あっても一回失業したらまた目減りするんだろうな位の冷めた目線でしか見られませんよ。
>>206
PCIも難しいんですねぇ…。 >>207
悪いな。俺も50後半で零細自営だが、不労収入含めて1千くらいはあるんだよ
1日数時間程度の設計やプログラムから、海外工場へのコンサルまでいろいろだが、
なんとかなっている。同業や同年齢の友人も同じようなもんだ
つまり、お前の能力がないだけ。こんなところで愚痴ってないで能力ない奴はベタに働け パラレルポート使ってみようとしたら最近のWindowsではまともに使えないみたいだし
シリアルポートすらなんかあんまり自由に使えなくなっちゃったっぽいのがつらい
そのせいでRCDライターがWindowsが64bitになってから使えなくなった あの頃はポートが直接叩けなくなって苦労したなぁ・・・ ポート直叩きライタは、そりゃ駄目だなぁ
ebayに1000円も出せばおつりがくるUSBで使えるPICライタがある
pic icsp usbで検索だ
ebayが駄目ならamazonでもちょっと高いが売ってるぞ うちのPICkit3が毎回のようにファーム書き換えに失敗する。今日なんて2連続で失敗した
そもそもなんで種類変えるごとにファーム書き換えなきゃいけない設計にしたんだろう PIC信者とAVR信者で言い争いがあったりするけど
相互補完するには最高の組み合わせだと思うなぁ
PICKit4で両方が使えるようになると争いに決着が付くのかな? PCからパラレルポート制御したいだけなら
USBやシリアルでPICつないでPCからコマンド送ってPICでGPIO制御する方法じゃダメなの? それともLANでRaspberry PiをつないでPCからLANでRaspberry Piにコマンドを送って
Raspberry PiでGPIOを制御した方が高速に動作するかな? こんなことが可能なんだなw
Cortex-M0 ARM(LPC1115)を使った Z80エミュレーター基板
ttp://yuki-lab.jp/hw/z80em/index.html >>217
そこに写っているZ80マイコンボード、パターンが手張りだね。
あと、追加した74LS30にパスコンが無い。というか、こまマイコンボード全体にパスコンが無い気がする。
ダイオードは、ゲルマニウムダイオードなのか、ガラス入りだし。 >>216
たしかにXパイ使えばいいな。
picだ、pcだ、通信プロトコルだ、なんてなると、
デバック大変だから、一般売りする製品作る気じゃなきゃ
nano-piでも使ったAll-in-oneが良い >>220
ラズパイをLAN経由とかUSBとかで、タイミング規定守れると思ってるんだ >>221
ラズパイ使うのなら、
LANとかUSBは、データ丸投げするために使い、
Writer作業は全部ラズパイで実現するから、
I/F経由でタイミング取ろうなんて考えないだろ。
それが分からないとは情けない。
そもそも、書き込み関するタイミングスペックはごく少数の例外を
除いて、minで規定されてるから、遅くなってもかけるよ。 >>223
ラズパイのlinuxやWinfowsIOTでのGPIOのタイミング規定わかってる?os使わずにフルスクラッチで書くの?ipやUSBの実装頑張ってね タイミングがシビアなところまでUSBやEthernetからのコマンドタイミングに依存するように設計するのはアホ >>224
嫌に絡む奴だなあ。
armはmemory mapped IOだろ?
お行儀が悪いことは承知の上だが、、
物理メモリ空間さえ見せれば、デバイスアクセスは可能。
手元にwiringPIのソースがあるから、GPIOアクセスは
これからパクればいい。
実際、wiringPIはmmapで物理空間をマップしてpinにアクセス
している。
Linuxからその程度は簡単に出来るんだよ。
必要なら、お行儀よく出刃ドラ書いたって良い。
自分が出来ない事は他人にも出来ないという
間違った思い込みはやめたら? まあ別にRaspberry PIなんざ使わなくて
もっとチープなデバイスでも十分 >自分が出来ない事は他人にも出来ないという
>間違った思い込みはやめたら?
これだよな、ホント恥ずかしいヤツ
テメェのレベルがペーペーなのを自覚しろって、大方周りが馬鹿ばっかで天狗でもになってんだろ いや、
さすがに>>221発言は恥ずかしいから
もう出てくるな Raspberry PIはOSが入っているから所詮組み込みで正確なタイミングは
無理でしょ。
全く用途が別なものを比べても意味がないと思うよ。
PICでもAVRでもそれぞれ得意とする用途が違うし
いいか悪いかを言うより何に使えるかを言えなければ
使う人の能力がないだけのことだでしょ????
批判するだけならバカでもアホでも簡単に言えることだよ
皆さんはどちらですか??????? >OSが入っているから所詮組み込みで正確なタイミングは無理
頭悪さ全開 どんな精度だと思っているんだよ
PICのライタなんか1ms前後の精度があれば十分で
そんなのはlinuxのタイマーで十分精度が出る >>233
>正確なタイミング
「正確」の概念が用途で変わるわけですよね…
min-maxがマイクロ秒オーダーで規定されていたらマイコンかもしれないけど、
minしか規定されていなければ、でかい遅延が発生するシステムでも、十分用途に必要な「正確」さを確保できます。
一方で、n秒オーダーのタイミングが必要になってくると、マイコンでは難しいことが出てきて、
高速で動作するプログラマブルロジックが必要になってきます。
>正確なタイミングは無理でしょ。
に対しては、
「いいか悪いかを言うより何に使えるかを言えなければ使う人の能力がないだけのこと」
がそのまま反論になってきます。解は一つではないでしょね。 ラズパイじゃPICライタにするにはもったいないけどな
arduino位がいいんじゃね?
つか、USBシリアル変換噛ますならPICでもいいかw
(既に書込手段持ってるならばだが) いやもー、USBパラレルのBItBangモードでやればいい
ホストPCのソフトだけでできるやん 金が無いならパチモンでも買っとけ
ebayで\1300だわな 敵はデバイスドライバの署名
なんでこんなに厳しいの…… 価格も考えて、
>>220 にnano-pi って書いたんだよ。$9.9 秋月でも1680円じゃんよ。
SDカードは必要だけど、EtherとUSBが漏れなくついてくる。
価格はLinuxでもArduinoと大差ない時代になったんだよ。 だからデバイスの書き込みのスピードで開発効率左右するとかヘンだから だらだらデバッグしてなんとなく動くものを作ってるので・・・ pickit4もicd4も高速化が大きな宣伝文句だっていうのに 結局、ハードの比較だけしてるだけで物作りをしてる人間が
発言しているとは思えないな??
(反論だけならサルでもできる)
実際何を作っているのか、何を作るのに適しているのか
いえる奴はいないのか??? >>251
>結局、ハードの比較だけしてるだけで物作りをしてる人間が
>発言しているとは思えないな??
なんで?
根拠もなく「ハードの比較だけしてるだけで物作りをしてる人間が発言していない」という仮説を持ち出してくるのはなぜなんだろう。
人がたやすく自分が何を作っているかを開陳するものだと思っているのだろうか。
自分が開陳できるのであれば、他人も開陳できると思っているのだろうか。自分でさえ開陳していない>>251が何を言ってるのだろう。
物づくりをしている人間が掲示板でハードの比較をしていてはいけないのだろうか。
サルに反論ができると思っているのだろうか。俺はあちこちの動物園に行くが、人様に反論しているサルを見たことがない。
そもそも、何を作るのに適しているのかがわかる、ということは相対的なものであり、
他のマイコンとの比較の上でしか成り立たないことぐらいは分かっているのだろうか。
ちーと触ったぐらいでそんな比較ができると思っているのだろうか。
物作りのセンスと、CPUの比較のセンスはベクトルが違っているものだとは思わないのだろうか。
一つのCPUを深く愛し、とことん付き合おうとしているファンが適不適を語れるとは限らないのである。むしろ難しいと言えるだろう。
反論するなら理由ぐらいは書けよと思う。 リセットICの時定数足りなくて、米粒PICで代替したことがあった
君んちの某アレにも入っているかもね ソフト的にもハード的にも面白みがまったく無い使い方だな
書き込みも含めて結構金がかかると思うけど
他に解はなかったの? >>255
>>254の話が
>君んちの某アレにも入っているかもね
ということで、そこそこの量産品だとして、
>書き込みも含めて結構金がかかると思うけど
1000個単位でMicrochipに依頼したらどれぐらいかかると思ってるの? で、その5000個だとしてMicrochipの書き込みサービスを使ったら? リセットICが0.31ドルの時点で高い
もちろん機能によるけど >>260
高いことは高いが、出荷時期などのバーターで吸収できる程度の価格
とくにリセットICは評価が大変。 原価厨はキモい
モノ作りの経験ない上に人の話を理解できない >>262
リセットICよりマイコンの方が評価が簡単で開発期間も短いって
いまいち理解できないんですが
うちの会社だと、ソフトリリースの手続きが非常に面倒なんで
コーディング期間をゼロとしても
その後が色々と
他だと違うのかな? >>264
評価済みリセットIC -> 評価済みマイコン+新規ソフト -> 新規リセットIC
君、ソフトしかやってないだろ。電源周りは各種熱評価から電磁波、ノイズの評価が大変。 リセットICをマイコンで実装した方が簡単
やっぱり意味がわからんね
マイコンのリセット回路を使うわけだろ?
それの評価はしなくていいのか?
実際にリセットICよりも簡単に使えるリセットICもどきがあるなら
それだけで製品になると思うんだが 新部品採用依頼の高〜いハードルを知ってる俺的には
採用済部品(マイコン)でやっつけた方が遥かに簡単と
いう意味ならすごくわかる。 たいして数も出ないくせして、やたらと煩い車屋とか
はっきり言って、出来るものなら付き合いたくない連中だな あまりに現実感のない作り話の相手はこのくらいにしておくか Microchip、Microsemiを83億ドルで買収へ
Microchip Technologyが、Microsemiを83億5000万米ドルで買収する。買収後の年間売上高は約58億米ドル規模となる見込みだ。
http://eetimes.jp/ee/articles/1803/07/news087.html 電源回路の待ち合わせとかで予定していたよりリセット長くしたいなんて話で
まあ、電源設計から見直せばいいのだけれど、もうそっちはそっちで評価しちゃってるから
すり合わせのお鉢を押し付けられて、しかも最小の部品変更でリセット時間長くしなきゃならない
で、PICでやっつけちゃったてなわけなんで
予定ロットががはけたらつぎは見直すのかもしれないが
量産部隊が悲鳴上げたって知るもんか
ババ抜きはいつも最後の工程に回っていくんだ
(ひでー) >>267
>リセットICをマイコンで実装した方が簡単
>やっぱり意味がわからんね
>マイコンのリセット回路を使うわけだろ?
>それの評価はしなくていいのか?
「簡単」を考える上で、「既成リセットIC」と「マイコンで作ったリセットIC」を比較するから
わからなくなってるのでは?
>>265を読めばわかるけれど、前提になっているのは、「評価済みマイコン」を使うこと。
それと、このケースで、「こちらの方が簡単」というのはシステムの観点だと思う。
(1) リセット時間を変えるだけでOK。ただし既成リセットICには思うようなものがない。
(2) リセット時間を変えなくてもトラブルが起きないように、各部の調整を行う。
(1)の方が簡単なケースは多々あると思う。
トラブルシューティングだから、最初の設計が不味かったんだろう、というのは無駄な議論なのでしない。 >>272
おー。MPLAB にFPGAの開発ツールも統合するつもりか!
というのは置いておいて。
貪欲だなあ。AtmelのFPGAは普及もしていなかったしな。 microsemiの石、ディスコンになったら困るなぁ 専用ICかCPUかはともかく、リセットは重要だよね。
ある研究室に納めた実験用装置が、
「1週間に1回程度誤動作する」(運用は1日に数回、電源を入れて30分ほど)
とクレームがついて、解決に時間が掛かって苦労したことがある。
持ち帰ってチェックすると何の問題も無く動作するので。
結局、原因は隣の建物の数KWのモータの電源オンによる、AC電源の一時的な電圧降下だった。
モータと装置の電源を入れるタイミングが同じだと誤動作し、
CPUのリセットに失敗して正常に起動しない。
いったん起動すると、電圧が降下してもちゃんと動作する。
CPU内部のリセット回路を諦めて、外部にリセット専用ICを入れたらOKになった。 CPUのリセットがいまいちなのにCPUをリセットICの代わりに使う不思議 主要な方針として、Microchipは今後も「MIPS」ベースと「ARM」ベースの両方の製品を提供し続けるという。
Microchipの32ビットマイコン「PIC32」ファミリーおよびAtmelのARMベースの32ビットマイコン「SAM」ファミリーへの投資も継続する。
同様に、Microchipの8ビットPICマイコン、Atmelのマイコン「AVR」ファミリーへのサポートおよび投資も続けていくとする。
また、IDE(統合開発環境)の「Atmel Studio 7」「MPLAB X」の両方を将来もサポートしていく。 いい加減コネクタにRJ11使うのは止めてくれないかな ICD4はRJ-45がささる
手に入りやすくて便利じゃん >>284
すごいね、CPUのゼネコンだな。
4ビットや1ビットも始めたりしてw スマホとか用のAシリーズのARMもやるのだろうか
それとも組み込み特化かな Atmel Studioも負けず劣らずリソース莫迦食いで激重なんだよなー NetBeansベースとVisualStudioベースだったよね コマンドラインでコンパイラ呼べ
硬派はIDE使わない そりゃ、他人様のコードを単にbuildするだけならな
そんなら、build済みのバイナリでも貰った方がもっと早い
これが硬派? 硬派と時代遅れは同義語?w
知識の肥やしとして有っても良いとは思うけど >>296
世の中のIDEは、NetBeansベースが主流になってるのにな。 俺の観測範囲では猫も杓子もEclipseなんだが…… NetBeansベースのIDEって他にどんなのがあるのだっけ。 ひどい名前だよな
もっともeclipseは日食に限らず食の意味しかないが MPLAB X以外に見たこと無いなぁ
知ったかクンか? 単純にNetBeansとEclipseを見間違えたんだと思う 8bitCPU-RAM256byteをターゲットにプログラミングするのに
IDEで1Gとかメモリ必要になる
とう考えてもクソ設計 それを富豪プログラミングという・・・
(なんか違う) それにしか使わないのなら、もっと小さいものでできることぐらいわかっているだろうに。 1GB使おうがどうでもいい
動作がとろいのはどうにかして欲しい 好きだなぁお前も
こんなにトロトロじゃねえか... java=クソ
eclipse=java
∴ eclipse=クソ 新しいICD4は高速!Pickit4は高速!
でもIDEはドンドン肥大化で低速化
F1並のエンジン搭載車新発売!!
でもタイヤは軽トラ用しかハマりません
アホが設計してる ぶつくさ言ってる暇あったら最新マシンの稟議書いとけ どとねっと、よりはマシ
Atmel-Studio7の糞っぷりは半端無い AVRやatmelネタがよく出てくるのは対抗意識か? OracleのJavaは今後、半年後とにバージョンアップして、
5年サポートのLTSを3年ごとにリリースするらしい
LTSは基本有償サポート前提になるらしいな
だからフリーのJavaを使った開発ツールはOpenJDKを使うことになるようだぞ >>306
コンパイル時に出来る処理を予めしておく事で実行速度上げるのが、今時のCPUのトレンド。 >>317
周辺機能に.NETを使ってるかもしれないけれど、現状のAtmel Studioは、C++ネイティブベースじゃなかなったっけ。
Visual C++ のランタイムが必須なはず。
というか、Java、.NETが必要だからクソだとか、メモリを大食いするからクソだとか時代錯誤も甚だしい。
年寄りがいまどきの若い者が、と愚痴っているのと同じ。
自分が若いころには当たり前だった環境やソフトは、それより前の世代の「お前」に、リソース大食いだと愚痴られていて、
その当時のお前は、前の世代の「お前」の愚痴を「年寄りはたいていこうだ」と冷めた目でみていたはず。 pic32でまともなコンパイラが使えればいいのに・・・ 〜かもしれないけど、〜じゃなかったっけ
〜はず
〜はず >>322
「まとも」って何だろな。
XC32ならコマンドラインからでも使えるはずなので、
>>322さんの価値観ではXC32は「まとも」じゃないのでしょうね。 はずの部分を否定できないから>>323のような反論しかできないわけで。ははは。 CPUが遅くてコンパイラもひどい (純正無償版)
だからアセンブラ信者が多いんだろうな >>326
多いかな?
ラウド・マイノリティなんじゃなくて? アセンブラ信者さんは、ファイルシステムとフーリエ変換と10インチの液晶パネル制御かもアセンブリ言語で1日以内に組み上げてしまうんでしょ。
レベル高すぎて、とても真似出来ないわ。 >>324
まともなコンパイラとは
質のいいコードを吐くコンパイラ
コンパイラも吐いたコードも正しく動くのは言うまでもない
コンパイラ環境への要求リソースや処理時間は
昔ほど重要じゃない アセンブラもできないヤツが
どうやってコンパイラが吐き出したコードの質を判断できるわけ?
コードが読めないんだから、そんなの出来るわけ無いだろ > 周辺機能に.NETを使ってるかもしれないけれど、現状のAtmel Studioは、C++ネイティブベースじゃなかなったっけ。
ID:FE6pvGrl <- コイツが言ってる 周辺機能とは何を指してるんだ? >>332
普通は吐いたコードの実行時間とコードサイズで評価する >>336
コンパイラの選択肢が無いならコンパイラ単体の性能評価など不要
お前は普通じゃないってことだ
30年も前の開発スタイルから抜け出せない老害℃玄人 プログラマーのウンコバクを許容するか
ガベージコレクションのメモリ大食いを許容するか
ってなって後者になっているのが現状なんだろ
昔の話を持ち出すのとはワケが違うよね メモリ大食いはIDEの話
コンパイラが大食いしてるわけじゃない >>329
>他では話題になることもない
根拠にもならんな。
ユーザー何人のうち不満を持つ人が何人いるかだろ。 >>336
フリーのコンパイラも有るし。
特に16bit以上はGCCベースだから。 >>340
アセンブラネタが出た直後にわざわざwww うわ、書き込み途中で送信した。すまん。
IDEそのものがすべての機能を単体のプログラムに実装してあることなんてないわけで、
通常は、コンパイラも外部ツールも別のプログラムやモジュールを使う。
で、そういうのが、IDEのVisual Studioベースに縛られるわけでもない。
他のツールや環境で作られていたりしてもわからんよ。 相変わらず昔の話持ち出す奴って
中身空っぽの話ばっかりだな だーかーらー
不満がある人はそういうの何とかしようとして
その解の一つがIDEを使わない、=コマンドラインコンパイル
いったんmakefileなりバッチを整備すればワンタッチだ
エディタは使い慣れた相棒
PICくらいならAPIの森もないし
ソースラインブレークできなくても何とかなる
というかそれくらいの用途にしか使ってないんだけど
あの愚鈍なIDEを使わざるを得ない人はご愁傷様 PC用プログラムも担当なんだけど、そうなるとVisual Studio がインストールされてる訳で
その上で殆ど同じAtmel Studioインストールすんのはなんかなーって思う。 Microsoftの Visual Studio も幾つかのバージョンが共存していて、
Eclipseベースの開発ツールも混在していて、
こんなものですね。 フロッピー1枚で開発してた頃が懐かしい
誰だよ開発環境を太らせた奴は 各開発環境ごとに数Gごと食うからな
メディアは安くなっても手間と時間は安くなってはいない >>352
フロッピー1枚に入るように減らせとか号令をかける奴が居なくなったことが原因だと思う。 信じられないかもしれないが
秋月でPICコンパイラがフロッピーディスクで売られていたんだぜ… 今でもフロッピーでコンパイラ売ってないか
PICじゃないかもしれないが MS-DOS の時代は OS+コンパイラでもフロッピーディスク1枚になんとか収められた。 パソコンのOSと日本語変換ソフトと辞書と、IDE付きCコンパイラと、ユーザーデータ領域を2枚のフロッピーで実現できていたわけだけが。
だけど、そんなことを懐かしんでも意味薄い。
コンパクトな開発環境を作っても、商売が成立するほどには支持されないからこその現状なんだし。 >>356
ブラゲーでもネトゲでも同じだ
40GB当たり前とかふざけてる
容量減らす工夫がゼロ過ぎて呆れる >>360
イミフ
コンパクトなら、機種ごとに専用だろうがなんだろうが支持するけど?
一生使わない機種を網羅したり、一生使わないライブラリを網羅して大容量なんて使いたくもない >>362
↓これが理解できずに「意味不明」とぬかすのなら相当なおバカさんだと思う。
>商売が成立するほどには支持されないからこその現状なんだし。
商売が成立するほどの支持者がいると思うなら、お前が作るか、お前がお金を用意して誰かに作らせてみることだな。
できたものを売れば良いではないか。
でも、お前もそれで商売が成立するほどに支持者がいるとは思っていないのだろ? >>363
有料でこんな太い開発ソフトなら
誰が買うんだね?
何が商売成立とか抜かしてんだ? 余っているディスク容量を減らすのに開発工数を使うくらいだったら
新しい機能入れるわな >>364
>有料でこんな太い開発ソフトなら
>誰が買うんだね?
お馬鹿さんだな。
誰が「太い開発ソフトを作って売れ」と言ったのかね?
誰が「太い開発ソフトを作って売れ」と言ったのかね?
馬鹿でも分かるように、二度書いたよ。
>商売が成立するほどの支持者がいると思うなら、お前が作るか、お前がお金を用意して誰かに作らせてみることだな。
「お前が良いと思うようなコンパクトな開発環境」に、商売が成立するほどの支持者がいると思うなら、
お前がその「コンパクトな開発環境」を作るか、お前がお金を用意して誰かに作らせてみることだな。
という意味だよ。 でも、実際のところは、有償開発環境の商売が成立しているところを見ると
でっかいギガバイトクラスの開発環境にお金を払う人はたくさんいる。
>>364に対して「太い開発ソフトを作って売れ」と言うつもりはない。
すでに、そういうソフトで商売は成立してるからな。 新しいアセンブラ触ってみたくてPIC32MM始めたんだけどこれ面白いね
ディレイスロットのおかげで分岐が1クロックでできるの便利そう。 能力的には
PIC24FXLP < PIC32MM < PIC32MX
なんだな
秋月にはPIC32MM0064しかないけど、これがメモリサイズ最大か
CLCとかCIPとか、周辺が充実しているけど
依存すると抜けられなくなる > 幸せになりたければプログラマもデバッガも自作すればいいんだよ。
> なんならコンパイラも(アセンブラも)自作すればいい。
> ヒマ潰し電子工作のアマチュアには時間がいっぱいあるだろ?
文句を言うだけならサルでも出来る。
プロなら色々と事情があるだろうが。 実態はゴミ屋敷状態で下手にいじったら何が起ころかわからず誰も手が付けられない状態なんだろうと思う >>370
いずれARMやx86にも手を出してみて
>>372
周辺を活用するのがマイコンの醍醐味と思う
DIPは無いけどGPMは256KBまであるよ 段々複合素子化しているな PSocみたいになっちゃいそう >>378
ARM(thumbだけど)とx86は曲がりなりにも触ったことがある
だもんでMIPS触ってみたくてね メールでICD4が$70OFFのクーポンコード案内がきた、思わずポチるトコだったが俺には使いみちがないことがわかって止めた!
でも$199になると安いよね。
秋月だと今\29800だし >>380
その辺を触った事があるなら、
MIPSは普通過ぎて特徴が無いように見えるかな
ll/sc
swl/swr/ulw/usw
この辺の命令がちょっと特殊でおもしろい
MIPS以外だと
x86のAVX512命令
ARMの条件付き実行
DSP系のアキュームレータと積和
ビッグエンディアン
16bit単位でしかアクセス出来ないピッコロ
この辺を経験するとアセンブラのスペシャリスト 負の数も1の補数とか符号ビットとかの変態アーキテクチャもある
特定の表現がトラップ値だったり
8bitPICも結構特殊
ハードウェアスタックとかアドレス間接参照の方法とか
まあ8bitはある程度特殊にならざるを得ないけど アセンブラでVLIWやるれ
パイプラインレイテンシとか
サーキュラアドレッシングとか
ビットリバースアドレッシングとか
最近Cばっかりでアセンブラやらなくなったな 過去にアセンブラで開発した経験があっても、
Cばっかりやってからちょいとアセンブラやろうとすると、
とてつもなく体が固くなっている感じがするよ。 たまにコンパイルどうなっているか気になってアセンブルリスト眺めたりする
時々あほな最適化していたりするので アセンブラで組むと「CPUの全てが思う通りにできる」とワクワクする。
Cだと「あーやっぱり楽でいいなぁ」とノンビリする。
今はMCUのせいぜい数Kバイトの制御用プログラミングが多いし、
性能を追及したいのでフルアセンブラで書いている。
趣味のプログラミングのなので、開発時間や移植性や可読性などは全く気にしていない。
早く完成すると、早く次のネタを探さないといけないしw 仕事でも組み込み系プログラムは書いてるけど、趣味のほうが移植性や可読性に気を使う。
仕事だと、嫌でもきっちりした仕様書や設計書、ドキュメントを残して、文書自体をメンテするが
趣味だと仕事ほどキッチリとドキュメント整備やらないからね。
あとからソースみてメンテしたり読み解くのが面倒くさい。
仕事でソースから意図を読めないような初心者向きに不特定多数にソース見られるということはないが、
趣味だと公開したりすることもあるしね。 この動画、結構面白いよ
新・電子立国 第2回 マイコン・マシーン〜ソフトウェアが機械を支配する〜
https://www.youtube.com/watch?v=F3oG56OqvE0 自分で書いた趣味のソースでも一か月後に読み返すと意味不明で怒りを覚える
なので出来るだけコメントに設計意図を残すようにしてる >>389
今時のは、実行順序考えないとパイプラインがストールして速度出ないから、アセンブラで書くと遅くなる事がある。 俺のところは最近はさ、PICになにか新しいデバイスをエイヤと認識させる作業ばっかりでさ
ちょっとつまんねぇんだよね。ライブラリも作りきっちゃったからLEGOでも組むように設計はできるんだが・・・
仕事そのまま外注にしちまおうかとも思ってる。 >>389
それ分かるわ。趣味の範囲だけど。
テスト用にCで書いて動作チェックした後にアセンブラで書き直してる。
アセンブラだと全てを自分の手でコントロールしてるって感じが好きで。
Cでもライブラリはすべて自作するから同じなんだけどね。 >>394
下手糞が組むとアセンブラの方が遅い
こんなことは20年前から言われてる
PIC32の小数命令とかは遅延が大きいので
良く理解してから組まないとだが
PICはそれでも簡単
スーパースケーラー & アウトオブオーダー
uOPに変換して実行
演算ポート数が多い
演算ポートを使わない命令
メモリや小数演算のレイテンシ
キャッシュ構造が複雑
分岐予測
...
こんな要素が盛りだくさんなx86だと
コンパイラを越えるのは大変 USB, Ethernet, FAT, MP3, JPEG
こんな要素が入って来てもフルアセンブラとかフルスクラッチとか言うかな?
規模が極めて小さいプログラムしか書かないって
自分で言ってるようなものだから
あまりアセンブラを連呼しないほうがいいよ > 下手糞が組むとアセンブラの方が遅い
そう言われたのが当の本人なんだろ
わかるよ、どっかで拾った単語並べてる程度のレベルだし >>403
アセンブラで組むのは速度の為だけではないのに、アセンブラ最速とか言い出すから、ややこしくなる。 自己満足でいいよ
銭のためだけに開発やってもつまらんし プログラムカウンターに対して演算しちゃうとか、別のサブルーチンに GOTO するとこれぞアンセラーの醍醐味という気分(自己満足)になれるな。 >>407
gccの拡張使うと、asmなしでそれ出来ちゃうよ。
俺も使った事ないけどね。 >>410
ヒント
gccのドキュメントから
Label as values
というキーワードを探す 30年前だか40年前だかのテクニックかもしれないが、
アセンブラで 8 bit pic やるなら、addwf pcl,f なんつうのは
今でも常套手段なんちゃう。ググると沢山ヒットする。 マシンサイクル数えてI/Oポートでタイミング生成とか
アセンブラじゃないとできないしな Cで吐き出したアセンブラコードを見てマシンサイクルを数えるツワモノも世の中にはきっと居ると思う。 >>390
私は趣味であっても仕様書や設計書や操作説明書、回路図や、
写真(完成時だけでなく製作途中のものも)などはキッチリ残しているし、
ソースプログラムにも何十行もコメントをまとめて書くときがある。
趣味には納期が無いので、このへんは時間をかけてルンルンと楽しんでやっている。
後から見直すときもこれらの資料、コメントを見れば、
アセンブラに慣れている事もあって、
特に<アセンブラだから理解しにくい、面倒だ>という事は感じない。
たとえ時間が掛かったとしても、むしろ読み解く楽しさがあるし、
たまに、「へーこんな裏技やってんだ、俺ってすごいな」とビックリするw
それに小さなMCUでレジスタやスタックを操作するような
特殊な使い方をする時は(AVRのレジスタでリングバッファを作るとか、
タイムスライスをやるとか)フルアセンブラの方が良い。
まぁ、趣味なら人それぞれの楽しみ方があるんだな、と言うことでお願いします、チャンチャン。 連投スマン
私はケースにもタカチのアルミサッシ製を使ったり、アクリルで作ったり、
操作パネルにラベル(文字)を入れたりして、時間をかけて作る事が多いです。 化石テクニックをドヤ顔で語っちゃうとか
化石テクニックで自己満足しちゃうとか
世の中平和だなあと思ってしまう 赤の他人にケチをつけるだけのような発言、
まあ、それも平和か >>416
アルミ溶接やフライスで削りだししろとは言わんが、
鉄シャーシ溶接したり、アルミ板をベンダーで曲げて作るのが普通
出来合いやアクリル使ってるのをドヤ顔でいわれてもな ぜひ、その素晴らしい仕事(趣味の)をブログでも立てて公開してください 何気に儲かってるんだねぇ
組み込み会はARMとPIC(AVR)に収斂してしまいそう
実際それだけあれば大体間に合うな ルネサスもRXともろに競合するのにSynergyというブランドでCortex-Mやってるしな http://sp.chip1stop.com/interview_renesas_platform/
> ルネサスには、「RXファミリ」や「RL78ファミリ」などの独自コアがある。
> なぜ、そうした独自コアを使わずに、ARMコアを採用したのか。
>
> 葛西?VSAの存在が大きい。確かに、日本国内であれば、RXファミリやRL78ファミリのユーザが多い。
> しかし、今後市場が拡大するIoT機器の開発が最も盛んなのはシリコンバレーだろう。
> そこで働くエンジニアの多くがARMコアに対応したソフトウエアを開発している。
> 従って、パートナー企業が開発するVSAの品ぞろえを充実させ、
> エコシステムとして拡大させるにはARMコアの採用が欠かせないと判断した。
>
>
>
> RXファミリやRL78ファミリにも、Renesas Synergyと同じ仕組みを適用する予定はあるか。
>
> 葛西?その予定はない。RXファミリとRL78ファミリは、ある意味、
> 特定の用途に特化あるいは進化してきたマイクロコントローラという位置付けだ。
> 例えば、RL78ファミリであれば、低消費電力が最大の特徴であり、
> 消費電力を極限までそぎ落とす必要がある用途に向く。
> 一方、Renesas Synergyで提供するマイクロコントローラは、汎用性が最大の特徴であり、
> 超低消費電力のみが求められる用途に最適とは言えない。 PICのXLPとどっちが電池持つか、チャレンジだ! >>423
Atmelはかなり初期の頃からARMを使ってたメーカーの一つらしいな PICのCPUコアがどうこう言う人にはAVRやARMを使ってもらえばいいだけだよな
Microchipに死角なし ARMって、フリーかつ各社汎用に使える開発環境とデバッガを構築しようとすると
けっこう苦労するイメージがあるんだが。
仕事ならKeilやIARをさっさと選択するんだが、趣味もかねてるとなかなかむつかしいのでは? >>382
フラグが無いのとディレイスロットがあるのだけで十分特徴的に感じるなあ
LL/SCはシングルコアのPICでは使い道がない…
ULW/USWってなんだろうと思ったら[S/L]W[L/R]を吐く疑似命令か
面白いとも言えるし、アラインされてなくても読めてくれよとも言える
自分が思ったのはCLZ/OとINS/EXTとMOVZ/Nあたり、特殊というか、あんまり見ないからあるの嬉しい
あと命令自体じゃないけどANDI16の即値のエンコードがめっちゃ特殊で凄まじいな >>430
Linux動くレベルのでないと、ARM使う意味が余りないと思う。 >>432
> LL/SCはシングルコアのPICでは使い道がない…
えっ???? >>434
全否定ではないけど、本当に組み込みレベルになったら周辺に互換性ないから、CPUコアを統一する意味が余りない。 >>437と同じ意見でARMを使うことを躊躇している。
年間使用数が二桁の超零細では、中期的にでも安定して入手できそうなデバイスが無い。
PICが良いとは思わないが、少なくとも供給体制に関しては古いデバイスでも入手できるのが大きい。 知らんがな
ディスコンになったときの責任まで取れるかよ
その時には客に金出させて改版
あるいはデバスを支給してもらう >>439
一番の需要は、低コストで作れるLinuxマシンだろ。 超零細の自営でかつ組み込みが前提なら、CPUコアと周辺機能がある程度統一されていること、
少なくとも中期的出来れば長期的な部品供給が期待出来ないと使いにくい。
客に金を出させるのも大変だが、同じ機能をCPU・周辺機能の変更に合わせて書き換える
手間も実質的に無駄でしかない。
もう少し有意義な使い方をしたいのが本音。 ARMといってもCortex-M系とCortex-A系は全くの別物だからな
Cortex-M系はARM命令をサポートしてなくてThumb-2のみ
メモリマップもCortex-Mは4GBのメモリ空間を8分割して
ROM用とかRAM用とか周辺用とかに区分けされてる点もCortex-Aとは全く違う Cortex-Mの中でM0、M0+もまた違う
Thumb-2の32bit長命令の多くがサポートされてなくて
サポートされてる命令のほとんどが16bit長の命令だったりする PICのスレなんだから競合となりうるMが前提だろうに
AとかLinuxとかを前提に語るアホとか
誰も聞いてないスレチな内容をドヤ顔で語るアホとか
PICスレはなかなか面白い >>447
PICの用途だと、コアの処理速度とか二の次だから。 英語版のWikipediaにCortex-Mが対応してる命令の概要が載ってる
もっと詳しく知りたければ英語になるがリファレンスマニュアルが
ARMのサイトで無料登録すればダウンロードできる
リファレンスマニュアルはCortex-M3、M4、M7はARMv7-M用
Cortex-M0、M0+はARVv6-M用になる
https://en.wikipedia.org/wiki/ARM_Cortex-M 8pinのクセにPIC12F1840の多機能なことよ
LPC810とどっちがつおいかな
ファイッ! >>435
ありゃ、なにか勘違いしてたか
あの辺の命令はマルチコアの調停に使うもので
シングルコアなら割込み禁止だけでことが足りると思ってたんだけど
あ、でも1クロックたりとも割込みを遅らせたくない時使える?
それくらいしか思いつかない… >>455
あっそう
じゃあ教える気があったら教えて >>453
今時のプロセスルールだと、8bitはスカスカ過ぎるから、周辺機能たくさん入れてもチップサイズ大きくならず、コストがあまり変わらない。 PIC24Fが人気出ればいいのにね
PIC24Fは高すぎ >>458
今時のプロセスルールだと5V仕様にできないから
180nmくらいの大きいプロセスだと思うよ。 >>458
だから16bitや32bitにシフトしてるわけで
>>459
PIC24はオワコン
PIC32に対してメリットが無くて
Microchip自体売る気が無い >>462
PIC32MMは32bitマイコンなのに安いよなぁ >>462
フラッシュメモリー部分は、信頼性考えるとセルサイズ小さく出来ないから、単純な処理ならコードサイズ小さくて済む8bit有利。 > 今時のプロセスルールだと5V仕様にできないから
そんな理由があったのか・・・・
コマケーのも良し悪し棚。 >>468
5Xで動くやつも、内部は2.5Vとか、1.8Vで動いてる。 ↑ 物もある とか言っとかないと、上げ足取られるぞw >>469
5V単一電源で内部降圧してるcpuって例えばどれ?
スレ的にはpicで、と言いたいがとりあえず何でも。 >>469じゃないけど
16bit以上はほぼそうなんでは?
今時5Vでコアを動かしてたら電力が そういやdsPICの5V版はすごく熱くなった記憶。 >>474
30Fは熱かったね、電流がよく流れてた
初めて使ったとき、これは最大クロックはダメだって思って3.3Vの33Fに乗り換えた 趣味の電子工作で 8pin 8bit PIC 用を使って
赤外線リモコンデータの受信解析ソフトをスク
ラッチからアセンブラで書いたんだ。そしたら、
なんと自分でもビックリしたことに一発完動。
今日の株価暴落はこれが原因だったようだ。 8pin 8bit PIC 秋月価格1万個分くらいのロスを出しましたので、それにてご容赦を m(_ _)m よくTVリモコンが行方不明になるので予備機をPICで自作してみたけど
電器屋で税込1000円以下のELPAリモコンの方が
軽くて操作性も良いので
結局そっちばかり使ってしまう 使うCPUのデータシート(別途インストラクションマニュアルがあればそれ) 修行?
趣味だろ
修行と思うなら手を出さない方がいい 勉強のつもりなら8ビットはやめておけ
癖が強すぎる
PICに限らず >>484
リモコン解析部はソースの行数で300行くらい。
別のリアルタイム処理と並列動作させるため状態
遷移処理で作ったので結構ムズイ作り。
ただし、コードの見やすさと実行処理ステップ数
小を優先したのでコードを減らす努力なし。
>>485
電源投入時に必ずリモコン操作が必要になる機器
2台用にPICで作った赤外線リモコン信号自動送出
器が我が家では毎日大活躍。
>>486
データシート以外は検索でサンプルを拾ってくれ
ば十分かと。ただし、おすすめの入門書おしえて
と聞く人にアセンブラは向かない気がする。 リモコンデータの受信解析ソフトって、
単なるリモコンの受信処理部分のこと?
それとも受信回路や送信機の評価用の解析? 状態遷移処理って何?
逆に状態が遷移しない処理があるのか? PLCのラダーのような
状態変移で動かすプログラミング
FAやプラントではそういう書き方しないとメンテナンスが面倒 PCの値しか状態を持たないプログラムが存在すると? 状態を示す変数を用いる処理が状態遷移処理だとしたら
ほぼ全ての処理がそうじゃないか? >>493
何のリモコンのどのボタンを押したかを解析する処理。
NEC, AEHA, SONY フォーマットMAX6バイトに対応。
受信モジュールは月並な 38kHz 3pinタイプ。
リモコンで遠隔操作ができるようになっただけでなく、
8pin PIC でも入力ボタンが一気に増えた気がする
のがうれしい。
>>495
説明が悪かったかな。状態ごとに変数値を決めて
その値に基づいて処理を行うやりかた。
ひとつのことにかかりきりでよければ、プログラム
の流れそのもので、すなわち、状態を表す変数なし
でも処理ができるので、それと区別をしたつもり。 >>502
フォーマットの識別はリーダーパルスの長さで判別? 状態遷移の状態を、状態と日本語で書くから知らないやつはわからない
stateと書けばいいんだよ パルスの受信は割り込みで
解析は割り込みの外だろ?
「状態遷移処理」とCPU占有の関係がいまいちわからん
CPUを占有してよくて
「状態遷移処理」じゃない処理にすれば
解析が簡単なのか? >>502
他のマイコンだと、状態遷移テーブルをポインタ関数テーブルに対応させてアドレスジャンプさせるんだけど
8ビットPICだとどうやるの?
アセンブラでもスマートだが、unixのcで、select文と組み合わせてスマートに実現しているのをみたときは
K&Rはこれがやりたかったのかと感動した。ネットワークと内部込みで。 質問です。
16F1705にてUSARTにて通信テストを行っているのですがうまくいきません。
何でもいいので受信すれば、1回LEDが点滅するようにしたいですがうまくいきません。
↓メイン部分でどこか間違いなどありますでしょうか?
// メインの処理
void main()
{
/** 各ピン設定 **/
ANSELA = 0b00000000 ; // AN0-AN3は使用しない全てデジタルI/Oとする
ANSELC = 0b00000000 ; // 全てデジタルI/Oとする
TRISA = 0b00000000 ; // ピン(RA)は全て出力に割当てる(RA3は入力専用)
TRISC = 0b00100000 ; // RC5(rx)だけ入力その他のピンは出力に割当てる
PORTA = 0b00000000 ; // RA出力ピンの初期化(全てLOWにする)
PORTC = 0b00000000 ; // RC出力ピンの初期化(全てLOWにする)
//UART用設定
RC4PPS = 0b10100 ; // 出力(C4へTXを割当てる)
RXPPS = 0b10101 ; // 入力(RC5を割当てる:デフォルト)
TXSTA = 0b00100100 ; // 送信情報設定:非同期モード 8ビットデータ・ノンパリティ
RCSTA = 0b10010000 ; // 受信情報設定
//UART用設定 データシートP340参照
SYNC = 0;
BRGH = 0;
BRG16 = 1;
SPBRG = 25 ; // ボーレートを9600(高速モード)に設定
RCIF = 0 ; // USART割込み受信フラグの初期化
RCIE = 1 ; // USART割込み受信を有効にする
PEIE = 1 ; // 周辺装置割込みを有効にする
GIE = 0 ; // 全割込み処理を許可しない
Flag = 0 ; // データ受信フラグのリセット
/*************** メインループ ********************/
while(1)
{
//PIC電源確認LED点灯
LATCbits.LATC0 = 1;
__delay_ms(500) ;
LATCbits.LATC0 = 0;
__delay_ms(500); // 500ms遅延する
while(1)
{
// USARTからデータが送られてきたら処理する
LATCbits.LATC0 = 1; // LED点灯
if(RCIF==1)
{
RXBUFF=RCREG; // 受信データの取り出し
LATCbits.LATC0 = 0; // LED点灯
__delay_ms(500); // 500ms遅延する
}
}
}
} >>509を見てよくわかりました
こういうプログラムが
「状態遷移処理」がないプログラムですね >>510
スマホからですみません
状態遷移処理がないとはどういう意味ですかね?
お手数をおかけしてしまって申し訳ないです >>511
あっ、いやっ...
気にしないでくださいすいません 受信データ列は正しいビットレートで正しいレベルで入力しているのは確認してあるんかいな。 >>513
受信データのビットレートは9600bps(PICは4Mhz外部クロック)で入力の電圧も問題ないと思います。
ただ、PIC(特にPPSの設定)と通信用のモジュール(※)が今回初めて使用する物なので、
基本的な記述に問題がないか確認したく書き込みました。
初心者のため意図と違う返信になっていたらごめんなさい
※通信モジュール
ttp://akizukidenshi.com/catalog/g/gK-07378/ 初期化のところは見てないのだけど(ここが問題かも)
while(1)のループが入れ子になっていて、breakもないし、外のwhile(1)は要らんよね?
どっち?
LATCbits.LATC0 = 1; // LED点灯
LATCbits.LATC0 = 0; // LED点灯
ビットレートが合っているかどうかは、初期化が終わったあとに、何か文字を送信して
オシロで見るか、PCで受信して確認すると良いと思う。 >>515
返信ありがとうございます。
》while(1)のループが入れ子になっていて、breakもないし、外のwhile(1)は要らんよね?
そのとおりです。削除します。
》どっち?
LATCbits.LATC0 = 1; // LED点灯
LATCbits.LATC0 = 0; // LED消灯
が正しいです。
》ビットレートが合っているかどうかは、初期化が終わったあとに、何か文字を送信して
》オシロで見るか、PCで受信して確認すると良いと思う。
オシロが手元にないので、PCに受信する方向で確認してみます!!
》初期化のところは見てないのだけど(ここが問題かも)
そこが問題かもしれないです・・・引き続き調査して見ます。 >>516
連投すみません
PIC側から文字を送信したところ、無事にpc側にて受信できました。
恐らく受信部分の問題だと思われます
引き続き調査してみます。 >>518
なるほど!!目からうろこでした
PICは正常に動作しました!(LEDは消灯しました)
ということはモジュールとPIC間かPCの送信の問題ですね 48MHzで動いてるPIC18から12MHzのクロックって出力されてましたっけ?
HSモードじゃだめかな
外付けセンサーで12MHzが欲しいんだけどなんかPIC用とセンサー用で12MHzを
2つ実装するのが馬鹿みたいな気がして >>519
とりあえず問題の切り分けはできましたありがとうございます
結局のところPIC側ではなくて、モジュールの問題かもしれません
送信はうまく行くのですが、受信をすると電源が落ちてリセットしてしまうことがわかりました。
理由はこれから調査しますが、不良品の可能性もあるのかな? >>521
質問する前にモジュールのデータシートは読んだ?
いや、俺は読んでないけど。 >>523
モジュールのデータシー読み込めてないです(泣)
英語ばっかで、つなぎ方などを見ただけで
一度読み込んで見ます
ありがとうございますm(_ _)m まずは
PC <===> PIC
PC <===> モジュール
で動作確認
PIC <===> モジュール
はその後で >>525
了解しました
とりあえずpcとPICの通信を完全にします
色々ありがとうございます あまりのレスの多さに感動です
>>503
随分インプリメント依存の所への質問ですね。
今回は、約 125μs ごとに赤外線パルスの有無を
チェックし、1ms以上パルスが続けばリーダーと
判断。その後、パルスが止まってから次のパルス
が始まるまでが 1ms以上なら NEC か AEHA、1ms
未満なら SONY と判定するロジックにしました。
2ms 以上パルスが来なければ終わりと判断。
>>504
とりあえず受け取った bit 数と MAX 6 バイトを
丸ごとレジスタに保存。この内容を後で適宜判断
します。
>>505
PIC には、そもそも STATUS というレジスタがあ
るのでそう書くのを躊躇いました。
>>507
以前は割り込みの無い PIC (12F510) を使ってい
たもので、そのくせというかなごりで、TMR0 の
とあるビットを監視してタイミングをとる形で、
全てポーリング処理で作りました。
> CPUを占有してよくて…解析が簡単なのか?
私はそう思っています。マルチタスクは CPU占有
ではありませんが、ひとつのことに専念している
ようにプログラムを書けるので簡単に作れる気が
するのではないでしょうか。
>>508
8 bit PIC の常套手段かと思いますが、プログラ
ムカウンターに対して状態変数を加算することで
複数のアドレスに一発で分岐できます。その分岐
先には、一般的に GOTO を並べておきます。
addwf pcl,f で検索するとワラワラ見つかります。 >>528
せっかくのキャプチャー割り込みを使わないで
ポーリングでやってるのか
メインループの他の処理によってサンプリングタイミングがずれるし
1000命令かかる処理が他に有れば完全に取りこぼすわけだ
125usと言えばPIC16ではトップレベルで応答性が要求される処理
これで割り込みを使わないで何に割り込みを使うの?
アセンブラの前にもうちょっと基本的なことを学んだ方が良い気がする 割り込み機能の全くない 12F510 が 50円だった頃
20個買ったやつがまだ結構余ってるんですよ。
今回は割り込み機能のある 12F1501 をハンダ付け
してしまってから間違いに気が付いたのですが、ま、
いいかとそのまま 12F1501 でプログラムを作成。
余ってる 12F510 にもダウングレ−ド移植をしやす
いようにとポーリングでやったんですよ。
全ての処理はイベント処理的に 125μs 以内に終わ
るようにコーディングしてます。割り込みを使えな
いわけではなくて、割り込みを使わないで作ったと
いうだけのことです。 超小規模なプログラミングでも
ホビーと業務レベルとの差は大きいな
アセンブラってところがまた泣かせる 業務用のは保守性と再利用性最重要視してるから
冗長過ぎて眠くなる
趣味のは各個人の技巧やら独自記法満載で
読んでえ辛くなる >>528
>8 bit PIC の常套手段かと思いますが、プログラ
>ムカウンターに対して状態変数を加算することで
>複数のアドレスに一発で分岐できます。その分岐
>先には、一般的に GOTO を並べておきます。
通常のCPUならそうなんですが、PICのレジスタバンクまたいでアドレスジャンプやGOTOして
かつ、ちゃんと帰ってこれるのかなと思って。 赤外線リモコン受光信号にちょくちょく
ちょっかいを出してくるヤツが居る。
何か?と思ったら、Win10 にしてあるも、
ちょっと古いノートPCが、近くに相手が
居ないか定期的に赤外線で声掛けをして
いるようなのだ。
これを使えば PC-PIC 間で赤外線通信が
できるじゃん、と思って技術資料を探そ
うとググってみても中々みつからない。
参考になりそうなサイトをご存知の方、
とりあえずヒントだけでも教えていただ
けませんでしょうか。 >>534
プログラムアドレスの下位バイトが 0xff から次の 0x00 にまたがないようにコーディングする必要があります。 早速ありがとうございます。でも IrDA のプロトコルスタックを
PIC 側に自作する根性は湧きません。PC側をもっと低水準で
Lチカしたくなります。 >>533
>>543
8bitで保守性と再利用性が最重要視?
知らない癖に語るなよ恥ずかしい >>547
え?御社には開発基準が存在せず、ドキュメント管理の効率化もやっていない、
と言っているようなものですよそれ… >>526
とりあえず通信は完了しました!
色々皆さんありがとうございました!
助かりました >>549
理由も書かずに揚げ足とって煽るやつが一番トンチンカンw >>547
横からごめん、東芝の4ビットでも保守性と再利用性は最重要視されてます。@車両関連メーカー
速度とか機能は仕様の問題だよね。そんなの仕様を満足してればまったく重要視されません。
あとはコストとのバーターだけど、コストの話になると保守と再利用できないと、いまどきのメーカとしてはダメなんだよね。
そこらは営業と調達ががんばるだけ。 仕様
信頼性
コスト
開発期間/納期
これらよりも
コードの保守性や再利用性を重視するアホなメーカーがあるのね >>553
お前ほんとにわかってないんだな。
仕様と保守を同一に語るメーカーがあると思ってるのか?
違いがわからないのかな >>554
特注の単品しかやった事が無いんだと思います。 最重要視
この言葉の意味がわからないのか自分で書いてて
他のいろんな事を犠牲にしてでも保守性や再利用性を確保する
っていう意味だぞ
なにも犠牲にせずに単に
保守性や再利用性を考えたコード
っていう感じで使ったのなら
当然だろうね
保守性や再利用性を考えないコードなどあり得ない 一部上場電機メーカーで量産品をたくさん作ってるよ
他部署や顧客に
「保守性や再利用性を最重要視して開発しました」
なんて言ったら笑われるよ普通 一人でコツコツ趣味でやっていて、この仕事できると勘違いしちゃっ子なんだろうね。
能力はありそうだけど、職場じゃいらない子ちゃんだなぁ…自営でもなさればよいかと
能力ありそうだからなんとかなるよ どれに重点置くかは業界によっても違うだろ。
統一解無いと満足しない人なの? ここでの書き込みで能力がありそうなさそうなんてわかるわけがない。
>>561
俺もそう思う。
何を重要視するかどうかは業界によっても変わるし、製品によっても変わる。
自分が思っているものと違うものを、アホだ、わかってない、あり得ないなんて言うのは
「見聞が狭い」
ということを公言しているようなものだと思う。 >>562
>自分が思っているものと違うものを、アホだ、わかってない、あり得ないなんて言う「見聞が狭い」ひと
典型的な一緒に仕事したくないタイプだな 経験則的に、人当たりの良い yes マンでプログラミングが上手い人は殆ど見かけない気がする。
まあ、細かいことはいいんだよ、っていう人は、人をまとめる仕事に回されるんだろうな。 即ち重箱の隅をつつきまくるような繊細さと
攻撃的な性格を持ち合わせたプログラマーが優秀であると どの業界でもイエスマンで仕事が出来る人なんていない プログラマ限定の話しでは無いが、
チームを組んで仕事してると、トラブルで行き詰まったときに、
思いもよらないような斬新な、目からウロコのアイデアを出してくる人がいる。
逆に、話を聴くのは時間のムダ、って人もいるが、
そういう人が受注先のエライさんだと、無視するわけにもいかず、
一通りご高説を拝聴して、実際にダメなところをやって見せないとけないのがツライ I/Oが多いの探していて、
PIC18F45K20が18のくせに安すぎる(秋月\180)のだが
何か理由があるのでしょう蟹 ●良品で普及してるから安い
●糞で売れないから安い 他の類似のPIC18に比べると周辺機能が少なくなっている。
それで構わなければお買い得。 >>508
関数ポインタは8bitでも当然使える。 相対ジャンプの距離をインデックスにしておいて飛び先で
関数アドレスロードしてそこへジャンプする
定石だね 保守性や再利用性、最悪だな
まともなコンパイラならswitch caseで自動でやるよ
テーブル、二分検索、if else 方式を臨機応変に切り替える そだねー
マイクロチップのコンパイラは頭良くないからね >>576
そういえば
1個のswitchで
連続部分はテーブルで、不連続部分は二分検索
みたいなハイブリッド処理をコンパイラがやってて
感心した覚えがある 下の方は機械に任せて、
機械が出来ない上の方を人間が考えれば良いよ
>>528みたいに基本設計がダメなものは
コンパイラが進化してもどうにもならない >>537
あなたのような方を天才ハッカーと崇拝します。
>>544
とりあえず、ここまでたどりついたけど、ここで足踏み。次の一歩へのヒントをいただけると嬉しい。
https://technet.microsoft.com/en-us/library/cc961385.aspx >>508
ステートマシンですね。
関数ポインタは、定石ですね。
代替で、switch case
を使うしかないかな?
アセンブラの展開見ると、コンパイラによってオーバヘッドが余計にでたり、
分岐ごとのオーバヘッド差が出たりして、レイテンシに問題が出る場合には注意が必要。
PICでは、cc5xを愛用していますが、
cc5xでは、skip goto という、プログラムカウンタにオフセットを増分するやり方が簡潔で、
可搬性に欠けますが、非力なマイコンなので目をつむっています。
優秀な、gccがpic用にあればいいんだけど.... >>582
自分でデバイスドライバ書く前提なら
IrDAのプロトコルをサポートしなくてもいいんじゃね >>584
自分は長いものには巻かれろ、派
スタンダードに合わせておいた方が後々何かと楽 >>583
数クロックの差で動作に影響を与えちゃうような作り自体が問題
そんな作りじゃ割り込みなんか使えない
とは思わないのかな?
PICユーザーは >>586
>PICユーザーは
一部のPICユーザーは、だね >>586
GPSDOの位相比較と制御をPICでやってるけど1クロックもずれない。
むしろPeripheral Interface Controllerとして本来の使い方かも知れない。 >>584
自作アプリで FIR Driver もしくは TrSIR.sys を
直接叩けば良さそうなんだけど、その叩きかたが
判らんとです。 >>588
内容がずれてると思うのだが
少なくとも>>586とは 数クロックの差で動作に影響を与えちゃうような
ソフトを作るべきではないという見解も、作った
ものが1クロックもずれないので、これぞ P.I.C.
と思った書き込みも、夫々理解できるのですが、
自作アプリからミニポートドライバをこうやって
叩くんだとコメントができる人は居ませんか? >>588
何Hzのクロックが何に対してずれないって? XC8のマニュアル読んでみたんだが、
ベースライン・ミッドレンジだと関数の引数がスタックじゃなく固定の場所に置かれるんだな
関数が再入不可能だし、関数が増えるほどにメモリ使用量が増える
なかなか思い切った仕様だ >>594
ミッドレンジ以下ってそもそもコールスタックしかないと思ったが。
FSRも一つしかなくてソフト的にスタックを作るのも現実的でない。 >>595
突然そういえばPICの呼び出し規約どうなってるんだろうって気になって
>>596
うん、C Compiler Optimizedじゃないことの意味をやっと理解した そもそもC言語じゃない
規格を満たしてないから
アセンブラで組む時代の時代遅れなコア CCSC買えば?
あっちもANSI準拠ではないけどっていう組み込み関数多いけど PICと掛けて小池百合子東京都知事と解く。その心は?
大年増(古いコア)の厚化粧(各種I/O) by 都知事選挙の石原慎太郎w
8ビットのコアをAVRに変更して、16ビットと32ビットにもっと注力すればいいのに・・・ 株主か大口顧客になってから言えば
ここで言っても何も変わらん 時価総額いくらか知らないけど、多分、私の小遣いで大株主になるのは無理だと思う。
小遣い以上に掛かるならカミサンの許可を貰わないと・・・。 >>599
CCSCだとベース・ミッドでも引数スタックに置かれるの?
特に今再入可能な関数をCで書きたいわけじゃないんだけど
どんな呼び出し規約してるのか知りたい >>601
余計なコストをかけずに売れ続ける商品を
経営の世界では「かねのなる木」と言う。
俺が経営者でも、コアを AVR に変更して
既存ユーザーに、今後はこちらに移行して
くださいと頼んで回るような無駄なコストか
ける判断はしないと思う。 8ビットなんて先細りなんだから
今から投資するアホはいない >>607
と、投資したことない貧乏人が言ってます 投資と聞くと株や不動産の事しか考えられない短絡脳が居るようで >>605
「大年増の厚化粧」はこれからも続くのか、やれやれ
もっとも、私は趣味の電子工作でありPICを使っていないから被害は無いけど >>611
フッフッフ、もしかしたら「イヤよイヤよも好きのうち」?
とフト思ったりしちゃったりしてw
ま、PICだろうとAVRだろうとCPU界が繁栄すればOK、という事で宜しく >>612
まあ君みたいに炊飯器や電気ポットの中身を気にしてるのは世の中のごく少数だよ >>596
デフォルトは変数のアドレスは固定で、再帰呼び出し不可。 >>616
CCSCでベースライン・ミッドレンジの話?
デフォルトはってことは変数をスタックに置くこともできるのか 8bitのPICでスタック?
ミッドレンジ以前で使えるのか XC8 global options
-> Statck options
-> Stack type:
Compiled / Reentrant / Hybrid
fsr1 を使ってるっぽいけど、それ以上は追うつもり無いんで
"どれで使えるのか / 使い物になるのか" 等に付いては、自分で確認しろや >>619
XC8でベース・ミッドで(普通の、Compiledでない)スタックが使えないのは知っている
5.8.1.3 REENTRANT AND NONREENTRANT SPECIFIERS
Functions encoded for baseline and mid-range devices always use the non-reentrant model and the compiled stack. >>617
再帰呼び出し可にすると、ソフト的にスタック作ってそこにローカル変数を入れる。 >>621
ふむ、XC8ではPIC18とEnhancedミッドレンジでしかやってないやつを
CCSではベースラインとミッドレンジでもやるってことかな CCS Cのリファレンス見たら
When compared to a more traditional C compiler, PCB, PCM, and PCH have some
limitations. As an example of the limitations, function recursion is not allowed.
って書いてあるぞ リニア・アドレスの拡張が無いヤツ、にまで無理に対応したとしても
パフォーマンスが残念な結果になるのは見えてるからな >>625
表で呼ばれる関数を実行中に割り込みでその関数が呼ばれることもある。
memcpyとかな 再入も再帰もスタック無しでできないのは変わりなくね? >>626
割り込みの中で、何十バイトものメモリー転送する事有る? 転送量の多い組み合わせだと、割り込みとDMAの組み合わせは普通にあるな
なんにしてもcの標準関数は普通使わないだろ
たまに、全部タイマー割り込みの中で書いてる奴を見かけるがw 設計思想次第
ほとんどの処理をISRでなんてこともある
dsPICなんかでは特に
初心者はISRは出来るだけ軽くと思っておいた方が良いのは確か
Cの標準関数は普通使わない?
それはどうかな
関数と意識しなくても中身が関数だったりする場合もあるし
除算とか >>631
レアケースと一般論を一緒にして比較とか書いてる時点でコミュ障 プログラムの実行時間をキチンと把握していれば、<割込み内で全て処理する>を避ける必要は無いと思う。
割込み内で処理できるのに、<フラグを立ててバックグランドでポーリングして・・・>なんてかったるい。
処理時間が厳しいプログラムなら、プログラム完成後に各処理の実行時間が設計通りになっているかどうか、
オシロなどで実測して確認すればいい。 >>633
そうなんだけど、その”プログラムの実行時間をキチンと把握”するのが、それ程簡単じゃないことが
問題なんだよね。
その裏付けを取る手間を掛けたくないから、出来るだけ<フラグを立ててバックグランドでポーリングして・・・>
になっている。
トラブルを避けるためには、ますリスクを避けることが第一になっている。
実験環境で”xx時間の検証でも問題ありません”は何の説得力もない。 裏付けも何も
割り込み周期(周期だよね?)の間に単位の処理が終わらなきゃ
ポーリングもへったくれもありませんがな
リスクとか何とかの話は意味不明だな
オシロが無ければ安いロジアナ(ebayでパチモンなら数100円で買える)でもいい
処理単位の開始でport=H,終わりでport=Lとして(トグルでもいい)
その間隔を測ることは基本
割り込み使わなければテスト的にルーチンをループさせてもいい
自分が何やってるのか意図したとおりになっているか順次把握することが大事 全ての割込みが一定周期で起きるわけじゃない。
どんな最悪条件でも”絶対に”問題ありませんと言い切るのが簡単なレベルとそうじゃいレベルの境界を
見いだせるかどうか。
少なくともその境界に対して十二分なマージンがありますというデータを示すことが
できるならいいけど、単にごく単純なケースだけを想定して話しているじゃないの。
最悪条件の見極めはそんなに単純じゃないよ。
わすか数分程度のオシロで観察しましたでは、説得力の欠片すらないレベルの話に聞こえる。 よく分からんな。万能の回答なんて無い
詳細な前提条件不明だからある程度推定して一般論的に
例えばこういうときはこうすればいいよー
としか言えない
当て推量の回答でもそこから何か汲み取れるかどうかは
質問者本人次第だな
まあ、こんな場所だから全く外していることもあるし
嘘もあるかもしれない
眉に唾して読むことw そうだね。
お互いに一般論の前提で話しているが、その前提が見事にズレているのは間違いない。
では質問を変えてみよう。
・あなたは、自身のプログラムで使用しているすべての割込み処理の最大処理時間をちゃんと計測してますか?
・それらの割込み処理が重複する可能性は全くありませんか?
・3つ以上の割込みが最悪条件で重複しても十二分な余裕のある割込み処理時間以内に収まっていますか?
せめてこのくらいの質問にすべてyesと言えるだけの裏付けは欲しい所。
あまりしつこくやっていると他の人の迷惑になるので、これで最後にします。 >>632
>>630が悪のように書いてるから反論しただけですよ
話の流れを読まないコミュ障ですか? >>639
優先度上位は当然確認するよな
割り込み禁止期間と全ての割り込みが重なってもまだ余裕があることを
下の方は余裕がありすぎるから省くことが多いだろうけど まあそもそも
このスレはまともに割り込みを使えない人も多いけど >>635
自分が作るプログラムの実行時間も知らなくて、どうやってプログラムを設計するんだろ?
実行時間を知らないからリスクになっているのに。
それに「裏付けを取る手間を掛けたくない」には少し驚いた。
信頼性アップの為に「可能な裏付けは取る」が技術者には必要だと思うけど、
ウーム、世の中には色々な人がいるもんだな。 なんか色々と現実を知らない感がただよう
実行時間を測る必要がある処理もあれば
全く測る必要の無い処理もある >>639
普通に全部Yesだろ?
お前やってないのか 割り込み処理が重複する可能性が全くありません
がYes?
普通に多重割り込み使うだろ >>648
おまえ、8BitPIC使ったことないだろ? 思った以上に反発されているので、少しだけ言葉足らずな部分の補足を。
過去に失敗したケースでは、最悪条件と思っていたケースが実は最悪ではなかったことがある。
結果として、割込み処理の時間が足りないケースで思わぬ不具合になった。
当然、すべてを簡単に管理できる単純なケースなら、割込み処理の中でデータの転送なり
何なり好きにやればいい。この点は全く同意。
ただ、そんなことをして得られるメリットは殆どない上に、管理が面倒な割込み処理側にわざわざ
処理を持ち込むことで、不測の事態に対するリスクを増やしている。
”最悪条件を確認している”と主張している人が何人かいるが、その条件が本当に最悪条件かどうか
は慎重に調べた方が良い。
いろんなケースがあるだろうから、それ以上は言えないが最悪条件の検証がそんなに簡単なら、
世の中のバグはもっと少なくなっている。 そんな考慮は最初からするの
わからないなら実測して確認するの どうせ
うまくいかん→ふってみろ
うまくいかん→叩いてみろ
うまくいかん→電源入れ治してみろ
大抵これで治って放置
そんなんで良ければどうぞ >>649
8bitで割り込みが重複の意味不明
割り込みは1個しかない
複数の要因で割り込みがかかるのはごく普通
で「割り込みが重複」の意味は? ギリギリで使うこと自体が稀
マージンがたっぷりあることが明らかなら測定などしない >>655
それはあなたの事情やポリシー、あるいは結果論では? 違います
世の中を知らないというのは恐ろしい
必要なテストは行う
不要なテストは行わない
当たり前ですね >>657の考え方なら、デバッグは要らないことになる。 >>659
必要か不要かを決めるのは何なんでしょうか。
データシートに書かれていることに従って設計していればテストは不要? まさかね。
ここで議論になってるテストは、製造段階の出荷検査ではなく、開発段階のものという前提はOK? 応答時間の保証が必要な用途がある。ならテストする。各処理の時間を測っておく。
別に時間保証なんて要らない用途もある。応答すればOK。余裕あれば範囲くらい測っとくか。
べき論に固まってるのキモい。 >>660
不要だよ
データシートと仕様書に従って設計されているかどうかを確認するのがテストだ
上流工程の経験やソフトウェア設計技法の教育まともに受けてないのバレバレだからもうやめとけ
どうせ現場叩き上げで覚えましたの20世紀の爺か低学歴の派遣だろ >>662
QCの概念が無い会社にしか入ったことないんだな。
海外メーカーだとそういうとこも有るけど。 単に自分が何やってるか判ってないんじゃないの
時々そういうの居るよ >>660
そんな単純な話ではありません
ソフトの検証技術について勉強してください ソフトの外注先なんかこんな感じだな
仕様書通り作ればそれでいい
まぁそれしかやりようが無いから それ以上どうしようもないのはわかるが
発注元としては、そもそもその仕様書に間違いが無いかどうかを確認せないかん
実物で確認は必須 >>668
仕様が間違っていたので修正して下さいと言うことなら修正しますけど
別途料金を頂きますよ >>650
その必要性がないのに、「フラグを立て、ポーリングでバックグランド処理」は
プログラムの効率を下げるだけだよ。
(サイズが大きくなって遅くなり、構造が複雑になる)
なんで「割込み処置は管理が面倒」なんだろ。
私にはそんな事を主張する君の脳味噌の管理の方が面倒に思える。
とにかくもっと経験を積み、勉強される事を希望します。 >>653
PIC16はベクタが一つしかないだけで、割り要因は多数ある。 「割り込みが重複」の定義を聞いてるんだから
素直に答えれば良いのに
複数の割り込み割り込み要因が同時に発生
であれば普通に起こりうること 複数の割り込みを扱えない初心者は初めてスレに行けば >>666
>>660はそもそもそんな単純な話じゃないでしょ?って問いかけです。
あなたは少しあわてんぼうさんですね。
CPUのエラッタが気になる人なら、いくら自分が完璧でもちゃんと動作するかどうかは
特に開発段階なら不安になって調べまくるものなんじゃないのですか? >670
他人にレスするのはいいが、自分の意見と異なるからといってすぐに”上から目線の”憎まれ口を書くのは良くないな。
あなたがどれほどの経験を持っているか知ったことではないが、割込み処理の周辺がバグの発生要因になり易い
のは少ししか経験のないものでも否定はしない。
いくら匿名掲示板とはいえ、他人を罵倒するような書き込みは褒めたものじゃない。
不愉快ならレスしなければいい。レスされた方もあなたのようなレスは望んでいないよ。 >>676
>>660
>必要か不要かを決めるのは何なんでしょうか。
>データシートに書かれていることに従って設計していればテストは不要? まさかね。
>>666
>そんな単純な話ではありません
このやりとりの>>660が質問に見えると? メモリーが1ギガくらいあるPICを100円でだしてほしい ううん とうじ たかおにできゃっきゃあそんでた きゃーきゃーか 「(NAND)Flashメモリーが1GB」なら現在の技術でも不可能でもないかも
(売れないから採算が取れず不可能とも言える) ログ溜め込むのにmicroSDやシリアルEEPROM使ってるけど
1チップなら配線も楽だし、さらにコンパクトに出来るな・・・ PIC32MX340FでPortB IOをLogicに設定にしようと
ANSELB = 0x0000;としてビルドしたのですが、
"ANSELB" undeclaredとエラーが出ます。
因みに、PIC32MX220Fのときは、このようなエラーは
出ませんでした。
原因を教えて下さい。
コンパイラはXC32 ver1.40 です >691
ここに書き込む前にデータシートを読むようにしないとダメだよ。
PIC32MX340FのADピン機能の設定はAD1PCFG。
ひょっとしたら間違ったデータシートを見ているかもしれないから、
データシートの名前はPIC32MX3XX/4XX Family Data Sheet。
PICは種類が多いから、自分が使おうとしているデバイスのデータシートは
必ずダウンロードしていつでも見られるようにしておくといいよ。 質問させてください
PICのtimer1機能を使って外部パルスの数をカウントしようとしているのですがうまくいきません。
・使用PIC:16F1705
・使用コンパイラ:XC8(V1.44)
・外部パルス:100us(high)200us(Low)の繰り返し波形
プログラムの目的としては、外部パルスを検知したらC0PINをhighへ変更
以下プログラム箇所抜粋
//各ピン設定(要調整)
ANSELA = 0b00000000 ; // AN0-AN3は使用しない全てデジタルI/Oとする
ANSELC = 0b00000000 ; // 全てデジタルI/Oとする
TRISA = 0b00001100 ; // A2ピンへ外部パルス入力(RA3は入力専用)
TRISC = 0b00000000 ; // すべてのピンは出力に割当てる
PORTA = 0b00000000 ; // RA出力ピンの初期化(全てLOWにする)
PORTC = 0b00000000 ; // RC出力ピンの初期化(全てLOWにする)
//タイマー設定
T1CKIPPS = 0b00010;
T1CON = 0b10000001 ; // 外部クロック設定
TMR1IF = 0 ; // タイマー1割込フラグを0にする
TMR1IE = 1 ; // タイマー1割り込みを許可する
PEIE = 1 ; // 周辺装置割込みを有効にする
GIE = 1 ; // 全割込み処理を許可する
//割り込み関数
void interrupt Intertime( void )
{
// タイマー1の割込み発生か?
if (TMR1IF == 1)
{
LATCbits.LATC0 = 1;
__delay_ms(500);
TMR1IF = 0 ; // タイマー1割込フラグをリセット(再カウントアップ開始)
count++; //highになった回数をカウント
}
} >>695
スマホからですみません
割り込み後にledを0.5秒光らせようと思って入れた待機用の関数です >>698
レスありがとうございます。
想定する動作としては
1.電源ON(外部パルスは常に発生)
2.A2PINに外部パルス入力
3.C0PIN(LED)がHigh
4.0.5秒待機
5.変数count(long型)に+1
※2.〜5.を繰り返し
このような動作をイメージしています。
「4.0.5秒待機」については、削除しても問題ないです。
現状としては、外部パルスをA2PINへ入力しようとしているのですが
うまく入力できてない状態です。
初心者のため、稚拙な箇所あるとおもいますが、ご指摘よろしくお願いいたします。 300us周期の外部パルスを全て取りこぼしなくカウントする必要があるか? >>703
》300us周期の外部パルスを全て取りこぼしなくカウントする必要があるか?
100usのhighの立ち上がり回数を数えたいです。
》LEDを消さなくていいの?
とりあえず割り込みの確認をしたいので、今は消さなくて大丈夫です。
》うまく入力出来てない状態の説明
オシロにて入力ピンの電圧を確認すると、想定通り(100us(high)200us(Low))が確認できますが
プログラム的には、入力として認識できていないという状態です。
》想定するLEDの状態、現状のLEDの状態
想定:LEDが点灯する
現状:LEDが点灯しない
下記の設定が初めてなので、》693の記述であっているかわかりません。
もしわかる方がいれば、教えていただけるとうれしいです。
・PPSにて「T1CKI」をA2ピンへ設定
・「T1CON」を外部クロック >>704
タイマー設定のコードはどのように作った?
Intertimeがどういう条件で呼ばれることを想定してる?
Intertimeががどういう条件で呼ばれるか知っている?
デバッガを使った事がある? タイマーの動きを理解しようか
タイマーのクロックを使ってタイマーの機能でカウントしたいのか
パルスの度に割り込みをかけてISRでカウンタをインクリメントしてカウントしたいのか
どちら? >>707
》タイマー設定のコードはどのように作った?
このサイト(ttp://www.geocities.jp/zattouka/GarageHouse/micon/MPLAB/16F1705/memo.htm)を参考につくりました。
下のような考えでつくりました。
@ T1CONレジスターの設定を行う
A TMR1カウントアップレジスターの初期化
B TMR1IFの割込みフラグを初期化
C 割込み機能を許可
void interrupt 割込み関数名( void )
{
if (TMR1IF == 1) { // タイマー1の割込み発生か?
TMR1H = ???? ; // タイマー1(TMR1)の再ど初期化
TMR1L = ???? ; // (65536までカウントアップさせるならこの2行は必要ない)
TMR1IF = 0 ; // タイマー1割込フラグをリセット(再カウントアップ開始)
}
}
》Intertimeがどういう条件で呼ばれることを想定してる?
今回の場合だと、A2ピンがHighになると呼ばれると想定してます。
》Intertimeががどういう条件で呼ばれるか知っている?
ごめんなさい、勉強不足で知らないです。
》デバッガを使った事がある?
ないです。 >>708
》タイマーの動きを理解しようか
了解しました。
》タイマーのクロックを使ってタイマーの機能でカウントしたいのか
》パルスの度に割り込みをかけてISRでカウンタをインクリメントしてカウントしたいのか
》どちら?
後者です。タイマのクロック機能は今回使う気はなく、割り込みをかけてカウンタを1づつあげたいです。 >>710
結局 パルスの立ち上がりエッヂでカウントするだけなら、タイマーを使う必要もなくて
状態変化割り込み(IOC)だけでやったほうが
簡単だね だったらPORTのIOC(Interrupt-On-Change)機能で十分だよ >>711
>>712
そうですね!!こんな機能があったとは
16F1705のデータシート内で検索してまいます
ありがとうございます!!解決しそうです!! >>714
ありがとうございます!!
↓のページ参考に書いてみたら、思ったように動きそうです!!
ttp://physics.cocolog-nifty.com/weblog/2012/06/post-cfdc.html
助かりました><感謝です >>675
「〜を希望します」なんて書き方は罵倒じゃないと思うけどな。
ただし皮肉っぽい書き方、上から目線になったのは申し訳無い。
同じ論点主張の繰り返しで先に進まないし、
プログラミング経験が足りないのかなと思って、
ついついあんな文章になってしまった。
人それぞれで考え方が異なるのは仕方が無いですね.。
直接対面して議論できないのが残念です。
ではまたそのうちに。 不自然というか、思考回路が違う気がする
いろいろ理解不能 無線リモコンの受信側で、バッテリー節約のために数秒ごとにマイコンをスリープから起こして500msぐらい待ち受け、
そしてまたスリープっていう間欠駆動させて、その都度、受信モジュールの電源はON・OFFさせてるけど、
受信モジュールの電源をON・OFF繰り返してるとが故障する確率が高くなる?
受信モジュールもスリープさせたほうが良い? >>710
>100us(high)200us(Low)の繰り返し波形
これを、タイマーを使って捕捉したいなら、
highの100us期間に必ず見に行けるような速さで、タイマー割り込みをする必要があります。
100us周期で見に行っていては遅いので、例えば60us周期で見に行けば、確実に取り込めます。
unsigned char check = off;
unsigned char LED_count = 0;
void interrupt 割込み関数名(){
if (TMR1IF == 1) { // Timer1割り込みなら
check=on; // checkの時間だぞ
LED_count++; // LED点灯時間ounter
TMR1IF = 0; // Timer割り込みflag
} else if(...){ // その他の割り込み
} else if(...){
}
}
void main(){
unsigned char count=0; // バルス数
unsigned char zenkai_check=0; // 前回の割り込み情報
check=off; // 割り込み情報なし
LED_count=0; // LED点灯時間counter
while(1){
if( (zenkai_check==off) && (check==on) ){ // Timer時間の↑なら
if(RC0==on){ // パルス入力=Highなら
count++; // パルス数
check=off; // Timer時間情報
LED=on; // LED点灯
LED_count=0; // LED点灯時間
}
}
zenkai_check=check; // Timer割り込み情報更新
if( check==on ){ // Timer1割り込みありなら
if(LED_count>500){ LED=off; } // LED時間が規定時間以上になったらoff
}
}
} ていうか、
全く何のために割り込みを使ってるのかわからないコードだな
メインループに1msの処理があったら取りこぼす 処理が逆だな
俺だったら入力波形を割り込みに入れて、
割り込みの中でタイマー値を見る 逆っていうか
何をしたいか次第だよ
単純にカウントするだけならパルスをタイマーのクロック入力にすればCPUを使わないで済む
パルス幅を計りたければキャプチャー機能
フィルター処理を加えたければポート状態変化割り込みとタイマー割り込みの併用
または変化割り込みとポーリング併用
などなど
>>722は何がしたいのかわからん
>>725もキャプチャーに対してメリットがいまいち お、今マイクロチップからPICKIT4出したから買えってメールが来たぞ
かわんがな 3のユーザー様には9ドル75セント! だったら買う。 16F18466はなかなか良さげだな…
UART直ってたら使ってみたい >>728
感想。
http://ww1.microchip.com/downloads/en/DeviceDoc/50002721A.pdf
8ピンになってる。
AVRにも対応していくのかな。
AVRに新製品。最近はAVRはご無沙汰なんだけど、MCC相当のものがあるのかな。
MEMSオシレータも手掛けてるのか。 >>732
>18446?
なぜ「?」が付くのか…。
型番間違ってるわけじゃないよな。PIC16F18446 あー。本当だ。ごめんなさい。>>731は 466 って書いてる。 後継って、どこを改善して欲しいの?あるいはなんの機能を追加して欲しいの?
まあPIC18アーキで作ったものが欲しいと思わなくはない PIC16F1454を愛用してたんだろか。
秋月で-E/Pに「D」マークが付いてるから心配だとか。 もしそんな理由なら値段差10円の16F1455-I/P使えばいいと思うけどね
もっとも、Dマークついてても在庫AAA(トリプルA)なんだししばらくは
無くならないだろうけど PIC16F1455の後継でも良いです
不満はROM/RAM
これが倍のが出てくれれば嬉しい ちゅうーかさあ
初めてACTが出てきたときに「これでUSB対応の8bitPICは全部水晶不要になるな!」とか
すごい期待したのに結局ACT搭載PICっていっちゃん最初に発表された品種のみでその後
全く採用がないとか一体なんなの?
まあ、USB対応 8bitPIC自体がここ数年新しいのが全く出てきてないけどさあ
18F14K50のACT版出して欲しいわ(18F14KK50?) 18F14K50も16F1454も買ってみたもののUSBを理解するのに気力を取られ未だ電源入れてすらいない 真面目にやったら、USBだけでも結構なボリュームあるからな
むしろ、それでも めげないヤツの方が少数
引き出しに しまったままの状態でも、別に珍しくない なんとかMLAでデバイス作ったけど、MLA部分は理解は出来てない ごめん16F1454は電源は入れてたわ
デバッグ出力用にEUSARTを使えるようにしたとこで力尽きてた PICにはarduinoとかmbed的な楽ちんライブラリってないの?
デバイスのハード層をラップしているような
Lチカ数行でできるような
シリアル出力数行でできるような
デバイス変わってもヘッダのデバイス名変えるだけのような PIC KIT Programmer3 が使えない、PICを使い始めたので、
ようやく、IPEを使い始めているんだけど、
毎回、power の設定で、「Power Target from tool」 を設定するとか、
面倒くさいんだけど、諸々の設定を保存できませんかね?
また指定した、hexファイルの履歴が残っていれば、すぐに書き込みできるとかできるんだけど... ターゲットの電源くらい入れてやったら良いと思うの。 設定出来ないとしたら糞だ
IDEも色々と糞なところがある
2重起動出来ないとか
エディタの基準線を消せないとか
起動時に前回プロジェクトを起動しない設定に出来ないとか 使いにくいと思う Windows アプリは uwsc 使えばあなたのお気に召すまま全部解決 >>750
スタンドアローンのPICkit 3 Programmerを使う コンパイラ・アセンブラ・プログラマ・デバッガを自作する >>756
基本それを使っているんだけど、それでは、Pickit2 とほぼ同じ品種までの対応で、
ここ数年リリースのPICの書き込みでは、使えないです。 デバイスによりけりだな
対応デバイスの "PK2DeviceFile.dat" を見つけられれば従来通りに使える
煩わしい、IPEともおさらばできる 18F46K22でI2Cを使うのでMCCでMSSP1を選んだが動作しない。
EUSART1、TMR0、ADCは動作しています。
SCL1とSDA1のピンはHighのままです。
I2C1.hのEMULATED_EEPROM_Write/Readをコピペしているが、
PICKit3のデバッグでPAUSEにすると
while(status == I2C1_MESSAGE_PENDING) ;から抜け出せないようです。
MSSP2にしても同じです。
EasyタブはI2C Master/Enable MSSP/Slew Standard/SDA Hold 300nS/7bitで
I2C Clockの0x03≦0xA0≦0xFFで99.379KHzと表示されてます。
RegistersタブはBCLIとSSPIのチェックとADD=0xA0/BUF=0x0/CON1=0x28/CON2=0x0/CON3=0x8/STAT=0x80
SSP1MSKが0xFFで赤くブリンクしているのが気になります。 こちらに書いていないけど、こちらに書きなさいということかな? また、お節介な荒らしがコピペしたんじゃないの?
マルチするなと荒れる原因 18F8520を使ってみたいのですが、これ用のソケットはあるのでしょうか?
そもそもテストや実装は個人で出来るのでしょうか? http://akizukidenshi.com/catalog/g/gP-07366/
これに半田付けすれば良い
電源系の配線をしてパスコンを付けて
80本ピンを立てておけば
あとはソルダレスボードでも
直接線でPICKITでも使える
ソケットもあるけど高いので考えない方が 0.5mmピッチの80pin QFPの半田付け
がんばれ >>764
ポートを入力設定にして無いとか、PowerDown設定してしまってるとか、
アナログ入力になってるとか、 0.5mmピッチは適切な道具が揃ってればあとは練習 BGAを裏返して植毛する事を思えば、全然余裕っすヨ >>767
ソケットとか変換基板買うよりもチャイナ基板屋で基板作ったほうが安いし早い。
初心者向きのフリーのCAD使えばわりと簡単。
パスコン程度は安く実装してくれるし、基板屋によってはPICなら実装もしてくれるかも知れないよ。 >>768
これはいいですね。でも半田付け殆どやったことないんですよね〜
>>770
ラインチェッカーをPICで作ってみようと思いまして80pinで一番安いこれがいいかなと
>>772
適切な道具を教えていただけるとありがたいです。
>>773
そうなんですか!?
>>774
自分でも調べて個人で頼むのは高いなと思っていたんですけど、安いところがありそうですね。
半田付け高校以来やっていないんで実装してくれるとありがたいのですが
初めは変換基板で試してからやってみます
ありがとうございました 今までXC8のFREE版を使っていたんですが、今回サブスク版を買ってみました。
んでPROレベルの最適化でコンパイルしてみたらそれまで55KBあったHEXファイルが
40KBまで縮んで「さすがPROのオプティマイズ化はすごいな」と思ったんですが、
いざこのHEXをPICに書き込んだら全く動きません
ためしに最適化レベルをFREEに設定してコンパイルしたHEXファイルを書き込んだら
やっぱり普通に動きました
PROレベルの最適化で逆に動かなくなるケースってのはどういうものがありますでしょうか? >>775
ハンダコテは何でもいい。液体フラックスと吸い取り線は必須。
ハンダはこだわりがなければ有鉛を使う。
あとはようつべで引きハンダのやり方を見てひたすら練習。
仕上がりを確認するのにルーペが必要かな。 >>776
ソースの一部分を削ってコンパイル&実行を繰り返し問題部分を特定するしか無い >>776
アセンブルリストファイルを吐き出してコンペアかけてみな。 >>776
最適化によって正しいコードが動かなくなることはある
(昔のVisual Studioではよくあった)
最適化における仮定が正しくない場合にも起こるし
単にコンパイラのバグということもある
シンプルなコードから順番にコードを足していって場所を特定してコードの記述を変えたり
ソースファイルや関数ごとに最適化を切り替えられるならそれを細かく変えることで
場所を特定して最適化設定を最適化する
また、コード側の問題としては以下が考えられる
不定値
タイミング依存
使用リソースの変化 (RAM, スタック)
処理順が変わる (volatileつけ忘れ) あとハンダは0.3φの奴を。ルーペはスタンドか頭にかけるのを。 ヤニなしで0.3mm径の半田より、
0.6mm径のものを使った方がヤニがたくさん得られて
上手に半田付けできるよね。 >ヤニなしで0.3mm径の半田より
0.3mmでヤニなしって売ってる? >>775
マイコン自体が安くても大して変わらんぞ
値段で決めない方が良い スルーホールだろうと0.5mmピッチだろうと0.6mmでやってる ハンダの径なんていろいろ選べるのだから、使い易いと思うものを使い分ければいいよね。
0.6が使い易いと思うならそれを使えばいいし。 糸ハンダの太さなんてアマチュアだから単に繰り出し易さで選んでるな。
あまり太いのも細いのもハンドリングし辛い。 細い半田だと、脂の量が少ないので、半田付けが難しいです。
0.6mmとかだと、脂が多いので使いやすいです。
あとで脂を洗浄するつもりなら、フラックスをハケ塗りすれば、0.3でも行ける 俺が0.3mmのハンダの芯のフラックスの量が少ないと感じるとき
・半田付け時の温度がうっかり高くなりすぎている。
・大きめのD、Cコテ先のまま使って、コテ先端へのハンダの広がりが大きすぎ。
ピンポイントでハンダを流し込むのに0.3mmを使っているのに、
芯のフラックスを、対象を活性化するのに使わずに、熱で飛ばしたり、
コテ先の余分なところを活性化するのに使っていては良いことないですね。 フラックスはハンダのヤニいりももちろんだが、別に筆で塗る奴用意して
基板に塗布+IC置いた後にピンごと塗布だろ。
太さは俺も0.3mm. そうなんだけど、ついつい面倒で半田盛ってしまう
で、ブリッジして慌てる
ここ一番の時にはフラックス出動するけど ブリッジしないで済むようなら極力させない。
しちゃったらなるべく一回で済むよう吸い取る。 いつかテレビで、
人工衛星搭載電子装置の基板のQFPの名人によるハンダ付け
を放送していた。
ハンダゴテを滑らせつつ連続的に糸ハンダを供給し、あっという間に終った。
出来上がり状態は全ピンがブリッジ無しの最適ハンダ量だった。
なるほど、これは名人だなと感心したけど、
私も君も数さえこなせば名人になれる、かもしれない。 0.5mmピッチなら昔だけどCx486とかIBM486BL2のTQFPを良く貼り替えたな。 PIC16で問題になるのはEUSARTくらいだからマシなほうだな ANBE PICKIT3-KIT05、 これ使ってる人がいたら確認したい
コイツに付属のZIFアダプター、PIC16F145x(USB内蔵) に対応出来てなくない?
種々試してみたんだけどダメだった
それ以外は調子良くて、コスパ自体は高いと思ってる
自分の使い方が悪いのか、そもそも対応してるのか?
説明書も回路図も無いから 判断できん ここは既に見てて知ってたけど
この回路図が合ってるなら、ダメそうだって事だな >>804
此れだけ知っていりゃ、安部ので十分だな。
一つ買っておくか。 この間からPICが必要になってラズパイで書いていたけど
安いから専用で持ってても良いよな! ZIF要るのか
凄く安いの買ったら
TEXTOOLじゃなくてTFXTDOLだった >>803
俺のメモには、PICKIT2で書き込む時にデバイスを手動設定してLVPで書き込むって書いてあるな 付属のZIF使わずに
BBに挿してジャンパー5本で直接PICKIT3に繋げば、問題なく書けるのは確認してる
該当端子を辺りを弄ればOkと言う事になるが、ZIFを外すのが大変
デバイスのDataSheet見ながらLVPならイケルかも? と考えてたんだが、 >>811 が正解か LVPなら、付属のZIFでも書ける事を確認 Verify もOK
LVP、今まで使った事が無かったから設定手順がアレだったが
知ってしまえばどうって事無い、 >>811 で正解だった
ただ、LPVだと実使用の面で何かと制約有りそう
確認も取れた事だし、
たとえ面倒でも一旦ZIF外して、基板に細工した上で付け直した方が良さそうだな。 >>810
読み書きソフトはSourceからコンパイルして作るんだけど、そんなに面倒じゃない。
オレンジパイでも書ける。 あ、
でもPICKITは遅いよね
ST-LINKとかLPC-LINKとかE1とかXDS100とか使った後だとイライラする pic18のdecf,incfでキャリーフラグ変わるってどういう事よ
pic14で実績あるコードだから何故バグるのか相当悩んだ
今さらアセンブラーでも無いんだろうけどね microchipが金払って調査会社に依頼してるんやから
当然現行大口ユーザー相手にアンケート取って1位にするやろ
日本でアンケートしたらルネ一強になるだろうし だな
"consider" なんてどうとでも操作できる incf/decfでキャリーが出てほしい場面が2バイトをdecするくらいしか思いつかない
別に出ても不思議ではないけどわざわざ変える理由が分からない
他の変更点ではアドレスがバイト単位になったのが不便だけど何かそうせざるをえない理由があったのかな
addwfとかでPCLを読むとPCLATH/Uが現在地になるやつは便利 ループの終了判定はdecfszだな
pic14はPIC12/PIC16と14bit命令が混ざったんじゃないか? >>824
PIC16は命令長が14bitだから、[バイト単位]にアクセス出来ても余り意味無い。 >>826
命令長14bitのをPIC14と呼んでる。 >>829 命令長14bitのをPIC14と呼んでる。
マイクロチップのネーミングが適当だからこんなことになる。 2バイトでアップカウントする場合、下のバイトを incfsz で skip したらi上のバイトを incf(sz) すれば良いが
ダウンカウントする場合は decfsz だけでは役不足なのが仕様としていびつと感じてはいたな。 >>828
14bitで必要無かったのは分かるがPIC18で変える必要はあったのかなと
下1bit無駄になってaddwf PCLが面倒になってまで必要だろうか
TBLRD/WTがあるけど2バイト単位でできなくもなさそうだしそこだけ1バイト単位でもいい
>>830
確かに。でも普通のN回ループはゼロだしキャリー使う場面が思いつかない
あればあったで何かしら見つかりそうな気もするけど ん?、 "addwf PCL" は従来どおりじゃないのか?
DataSheet 見てもこの部分が変わったようには見えないが >>835
命令長16bitのPICは16bitPICですか >>839
そう呼ぶこともあるけど大抵はPIC18とか24とかdsとかで事足りるから12bit、14bitほどは使わない
あくまでも私の周辺だけど >>838
アドレスが1バイト単位だから1命令先に行くには2を足さないといけないしテーブルは一度に128命令分しか飛べない
>>840
使うんだ。16bitPICって言ったら16bitCPUのPIC24/dsPICだけを指すのが普通だと思うから相当紛らわしいな PIC24C16D××、PIC16C08D××、PIC14C08D××みたいにすれば分りやすかった。
(C:コード長、D:データ長、××は種別)
でもそもそものPICスタート時からボタンの掛け違いが・・・
もう何を言っても遅い。 メーカーだけの責任じゃない
半分はユーサーの責任
>>835や>>840みたいなヤツの 何がまずいってPIC12とPIC16は命令セットでなくピン数で分かれてたのに
PIC18(とPIC17)は命令セットから違うことだな
(挙句今更になってPIC12をPIC16に統合しやがる)
PIC17と18の時16のままで頑張ればまだましだったんだよ実際18のときは初期案16だったし
17より下がるのを避けたんだろうけど、英字もう1個挟んで特別感出せばよかったんじゃないかな
PIC18F14K50みたいな感じで 型番なんかタダの記号に過ぎん。
付ける方だってそんなに考えて付けてない。
受け手が勝手に理由を捏造してるだけ。 >>849 あんたやmicrochipはそうなのかもしれないけど一般的には製品名は熟慮して決める
顧客が混乱するのは、メーカーにとって良いことではないからね。 「一般的には製品名は熟慮して決める」まるでPICの命名が熟慮されていないかのような言い方に見える。
どんなことも「熟慮」したかどうかなんて、真面目に考えれば当事者にもわからないものである。
熟慮なんて言葉は内省に使えば深くなるが、他人に対して、熟慮したかと言えば、逃げ道のない脅迫に近いものになる。
顧客が混乱してはいけない、というのは商業における価値観の一つにすぎないし、
顧客にインパクト、困惑を与えるという価値観もある。PICがそれであるとは俺は言っていない。
命名規則が変わってくるのも仕方がない。どんなに厳格に決めたところで、
企業間買収があれば、一つのメーカーに複数の命名規則の製品が混在することになる。
まとめれば従来ユーザーが混乱する、まとめなければ買収を知らない世代が統一性がないという。
命名に関しては、賢いユーザーは>>849のようなタイプだと思う。
自分の想定と違うときにパニックに陥るのはある種の発達障害だそうだ。
閾値を超えていなくても、想定と違うときにひっかかりを大きく感じてしまう人がいるらしいということは
このスレでもわかる。それを自覚することで自分と向き合えると良いのではないか。 >>852
発達障害は主文を簡潔にまとめられず
キチガイ的な長文を垂れ流すって自覚するといいよ >>853
長文といっても100行にさえ満たないものだから読めないわけでもなかろ。
おまけに>>852は複数の短い話を1レスにまとめているだけで、そのこと自体に>>853が戸惑うのであれば、
複数のレスに分ければよかったかな?
なお、この板で発言するときは、意識的に簡潔さよりも漏れの少なさを優先している。
・中身のない批判だけよりマシ。
・解釈を相手に委ねるような、よりどうとでも取れる文章は簡潔とは言わない。
・よりどうとでも取れる文章を書いた挙句に、読み手の解釈が自分の意図と異なるときに、読み手に責任を押し付けるバカよりマシ。 その通りだね。
自分の意見と異なる意見に対して、病的かと思えるほどに攻撃的な反応を示す奴が少なくとも複数はいる。
多分、お互いに尊重しあうことは出来ないんだろうな。 >>852
この長文の内容はある種の偏執狂を疑わせるな。
>PICがそれであるとは俺は言っていない。
逃げ道を用意して主張するなんて、この卑怯者めが手討ちにしてくれるわっ!w
ま、意味の無い屁理屈をどう積み重ねようと、
PICの名前には規則性が無い、は厳然たる事実だし、
これでは「名は体を表す」が成立しないではないかっ!w いつか誰かがどこかで、エラッタがあっても売れるから直さない、と書いてたな。
マイクロチップは大したもんだよ、見上げたもんだよ、屋根屋のふんどしっ!w 直したところで少量しか買わない君の手元に入って来るかどうかはわからない。 この世界ってバグ前提で動かしたりするんでしょ?
セカンドソース使ったら修正されてて動かないとかw >これでは「名は体を表す」が成立しないではないかっ!w
その仮説は証明されないから。
俺が子供だったころに、近所に「巌本徹男」(ちょっと変えてるよ) みたいな
名前の人がいた。小柄で痩せて病弱な兄ちゃんだった。 >>861
バグ前提の洗濯機とか
バグ前提の炊飯器とか
バグ前提のブレーキ制御とか
使いたくない >この世界ってバグ前提で動かしたりするんでしょ?
「この世界ってバグ前提で動かしたりすることもあるんでしょ」なら間違いではないだろね。
昔のVTRで、録画タイマーが10分ずている、とわかっていれば、ものぐさな人ならそれを前提に合わせるだろうし、
家族が気を利かせて時刻を合わせていたことに気づいていなければ、悲しい結果になるだろうし。 人命に関わる機器には使わないでね(または営業に確認してね)と
ハンコで押したようにどのデータシート/カタログに書いてある。 部品がバグ持ちなのと製品がバグ持ちなのは全然違う話
再現性があるバグならそれを避けて使えばいいだけ
さらに、動作が異なるものは普通はセカンドソースとは認識しないし
そんなものを代替品として使うアホなメーカーはない
ちょっと考えればわかりそうなものだが 俺みたいなPGの脳内にバグがあるような奴だと、
「この数式は完全に正しいはずだから問題点は他のどこかにあるに違いない!!」
とか最初に考えて、バグは永遠に治らなかったりするぞ。 >>866
>さらに、動作が異なるものは普通はセカンドソースとは認識しないし
>そんなものを代替品として使うアホなメーカーはない
バグではないけれど、「74HC4066」の違い
http://www.ti.com/lit/ds/symlink/sn74hc4066.pdf
http://www.ti.com/lit/ds/symlink/cd74hc4066.pdf
前者は 2〜6V、後者は2〜10V。 何故PICにはエラッタが多く、かつ放置するのか?
日本のある電機メーカーが自社のマンパワーが不足して、韓国のメーカーにテレビの設計を発注したそうな。
その日本側の技術者が言っていたのだが
「日本では設計完了までに詰めなければいけないところがいくつかあると判断する状態で
韓国側はOKにする。信じられん」
つまり、マイクロチップは韓国風の発想をする会社、
ということであろうと私は推測したりするのであったチャンチャン
しかもエラッタのせいでPICスレが栄える、
うーん、これは嬉しい悲鳴ではないか、マイクロチップに感謝しないとな(大笑) >>869
その結果が、現在の日韓メーカー格差だとするなら
microchipが正しいと言うのがあなたの結論か? わずかな例をもって全体の傾向と感じてしまうこと自体、感情論に支配されているように思う。
まあ、でも、組織の中で責任の押し付け合いをしたり判断を避けたり結果的に遅らせたり、
見聞きしたのに報告しなかったり(ちくらなかったり、ともいう)、
全く身に覚えがない、とは言えないな。いたた。 上位互換の新品種で修正して、不具合品は廃盤にすりゃいいと思うんだが。 >>872
趣味で使うのならそれでいいよね
100%エラッタがないと保証して、あったらすべて保証してくれる製品だけ使うといいよ 一方は完璧を期するまで煮詰めている間、
競合は多少バグあっても商機を優先してリリースし市場を制する
リスクの考え方っていうやつやな 趣味だからエラッタあってもいいよ。
俺が困らなきゃいい。 クルマだってフルモデルチェンジ後は
リコールにつながるような
不具合が潜んでると分かってても新車に飛び付く層は一定数いるからなぁ >>872
廃品種にならないのも売りの一つだから、わざわざそれを捨てる必要はないのでは
新規設計非推奨にしとけば新しい製品には使わんだろ
自分は趣味だから古いのでも新しいのでも好きなのを使うけど >>868
そういう書き方するとアスペには判らないよ PIC32MZ2048EFH064が秋月で販売開始
200MHz品なのが残念 >>870 >microchipが正しいと言うのがあなたの結論か?
マイクロチップは商売としてPICを売っている。
エラッタが多かろうが放置しようがPICは売れている。
従ってマイクロチップの商売のやり方は正しい。
勝てば官軍、ですね。 (ゴメン、1行追加)
正しいかどうかと個人的な好みはまた別ですが。 なんで秋月はPIC32のSMD品は上位品種に偏ってるんだろうか とりあえず使ってみるには全部入りが都合が良いからな
リファレンスボードも大抵そうじゃない?
もちろん量産だと極限までケチるけど
どうせなら252MHz品にしてほしかった ラジオ自作スレと同じで、此処にも偏執狂が蔓延って居るのか PIC32でI2Cを動作させているのですが
電源ON時、SCLからクロックが出ません
(SDAはデータ出力されてます。)
因みに、リセット(MCLR)をかけると
ちゃんとSCLからクロックが出ます。
電源ON時とリセットでI2Cの挙動が
異なるのですが、何が原因でしょうか? 発振前に設定してるとか
電源の安定前に設定してるとか
接続先がクロックをローに引っ張ってるとか
型番とクロックの原発は?
ドライバのコードはMCC?Harmony?独自?
MXやMZだったらエラッタの可能性も 内蔵PLLの安定前にペリフェラルの初期化しているとか
初期化ルーチンの前にウエイト入れて試してごらん >>886
レス有難うございます。
品番はPIC32MX340Fです。
PIC32MX220Fではこのような現象は
ありませんでした。
(接続先の仕様及び回路は同じ、違いは
340Fと220Fの差しかありません)
開発環境は、XC32コンパイラv1.40
IDE v2.20です >>887
ウエイトは100msecにしたり
500msecにしたりしましたが
現象は変わりせんでした。
IOの設定(TRISx及び、TMR設定)
→100msecウエイト
確認のため、LEDを点灯。(点灯してます)
→I2C初期化
(OpenI2C関数で設定)
→100msecウエイト
→I2C送信
で、電源ONの時はSCLは出力しません
(SDAはでます)
リセットのときはちゃんと出力されます 「SCLが出ない」の詳細は?
デバイスがローに引っ張って無いことは確認出来た? >>889
まいこんのほかに、何かICが関係してる?
リセットだと動くのは、電源が上がりきっているから。
電源オンの時は、マイコンも含めて電源が準備中に初期化がはじま >>890
パターンカットして、相手側と切り離しました
が、挙動は変わらず。
>>891
I2Cの初期化前に、マイコンが動作
しているか、ポートを使ってLED
を制御して確認するプログラムに
なっておりますが、LEDはONして
おります。 >>893
回路図をupできない?
そうすれば、すぐに解決すると思う。 MPLAB-Xのロジアナで見るとクロックピンはどうなってる? >>896
MPLAB X に、そんな機能があるの? >>900
ありがとう。
ちなみに、I2Cのデータシートの「通信線の最大容量」って、どの間の容量なんでしょうか?
スタンダードモードで、400pF max とあるけど、
対GND間の静電容量なのか、
SCL-SDA間の静電容量なのか。
前者ですよね? きっと。 MPLABのシミュレータは周辺機能についてはとても信用できないなあ
シミュレータで動かなくて悩んだ末に実機で試したら問題なく動いて時間を無駄にしたことが何度もある シミュレータが使えるような検証は、PCのGCCかなんかでのロジック検証ですんじゃうんだよな シミュレータは実機よりも手軽に使えるのが良い
頻繁には使わないがたまには使う PIC32MZ EFに採用されてるコアだが
MIPSはM5150と発表してるのにMicrochipはM-classとしか発表してないのはなぜ?
Microchip upgrades PIC32MZ EF family to MIPS M-class M5150 MCU
https://www.mips.com/blog/microchip-upgrades-pic32mz-ef-family-to-mips-m-class-m5150-mcu/ さぁ?
何故と聞かれても困るな。
そういう事はマイクロチップに聞いてくれ。
しかし、君はPIC32MZの普及に熱心だね。
早くその努力が報われるといいね。 MZはエラッタだらけのポンコツ
こんなん使う奴いるの?
サブマリンエラッタあるかもしれないのにね >サブマリンエラッタあるかもしれないのにね
それは何にでも。
比較する根拠があればどうぞ。 やっぱり餅は餅屋で買うのが一番
今まで8bit/16bit中心に作って来て
突然32bitに手を出しても
やっぱり無理がある
コアだけ買ってきて16bitのペリフェラルをつけただけじゃダメだよ
ARMとかMIPSとかの問題じゃなくて
Atmelを買っても全く生かされてない
長年32bit規模で作ってきたメーカーの方が
まともな設計が出来るのは当たり前
手軽にMIPSを扱えるのが今はPIC32しかないから
たまに遊ぶことはあるけど
業務で使おうとは思えんね チープなペリフェラル
チープな開発環境
チープな癖にバグが多い
8bitならそれでも良かったかも知れないけど 地雷源で芋掘りするのは個人の勝手だから別にいいけどさ
まぁ地雷源でも慣れ親しんだ土地を離れたくないという
お爺さんお婆さんの気持ちも分からないでもないけどね あちこちに地雷があると書かれてる。
それ以外でも地雷があることがある。
でもその土の癖がわかっていて、良い作物ができる。
こっちの土地においでよと言われる。
地雷があるとは書かれた看板は少ない。
でもそれ以外に地雷がないとは誰も言わない。
もちろん土地の癖は最初から研究しないといけない。
新しい土地に、地雷がないとは誰も言わない。 プロなら少しでも地雷の少ない、あるいは地雷が少ないと思われる安全サイド側へ
行こうとするのは当然だよ、
作ったものの責任を取らされるのだから。
私(ある機械メーカーの外注)は前任者が作ったバグの後始末をやらされた事がある。
対処できなかった前任者はこの件が原因で、課長とケンカして既に退職していた。
部屋を出るときに、課長にガラス製の重い灰皿を投げつけて、
こんな会社辞めてやる、と叫んだそうなw
納品先の会社に呼び出されたので、課長と私とその他の数人で行ったら、
相手も会議室に部長や課長らが5、6人待ち構えていて、
上から、精度が出ない原因と今後の対応策の説明をしろ、と言われた。
(原因が分ってりゃ修正してるっつうの)
課長が何度も頭を下げつつ、色々と言い訳してゴマカシ、
会社に戻って機械の動きを詳細に調べたら、最終的に
パルスモータを使った位置決め装置で、センサ検出を割込みでは無く
ポーリングで処理していたために、停止位置が時々、微妙にズレる。
という下らない原因だったのでガッカリしたというか、ホッとしたというか…。
アマチュアなら何をどう使おうと自由です。
掘り出した地雷を抱いて心中するのも良いかもしれません。 >>922
地雷は設計者だった、という話まで読んだ いや会社だと共通パーツライブラリに入ってるのしか使えなくてな、
新しく何か使おうとすると2時間仕事の申請書書かされるんだわ。
仕事のパーツが自由に選べるとか裏山 良し悪し 新しいものを探す旅に出なくていいという利点も大きい >922
では、あなたのお勧めするデバイスは何?
ここはPICのスレだからあまり長々とは話しできないので端的に答えてほしい。
PICにバグが多いのは確かで、他のチップに移行しようかと考えることもある。
ただ、デバイスの供給期間が長く、それなりの開発環境が安価に入手できるので使っている。
バグが多いために、特に完全な新規デバイスは避けるしかなくて、エラッタが出たころにやっと
使うかどうかを検討するしかない。
出来れば信頼のおけるメーカー製品で安価な開発環境があり、少なくとも10年以上の
供給期間を期待できるものが欲しい。 ルネといえどもエラッタ避けながら開発するのは同じなので
会社でノウハウのある石使うしかないわな…
エラッタよりもっと恐ろしいのがマイコン生産中止
30年前は設計ドキュメントなんて作る風習ないし開発環境はDOSのアセンブラだし… >>922
前任者は残念ながらスキルが低めだったのね 部屋に灰皿がある時点でダメな会社だから辞めて正解。 30年も前のデバイスを使ってて替えが無いって
どんなメーカーだ?
高くて低性能なのを買わされ続けても問題ないぬるい業界はいいねえ >プロなら少しでも地雷の少ない、あるいは地雷が少ないと思われる安全サイド側へ
>行こうとするのは当然だよ、
>作ったものの責任を取らされるのだから。
何が地雷で、どれが少ないのか客観的なデータを提示する人はいない。
根拠もなく中傷まがいの情報だけを垂れ流す人はいる。
この人に、他との客観的な比較を出すように書いても出てきたことはない。 いろいろ使ってりゃわかるだろ
バグの多さ
設計のチープさ
開発環境のしょぼさ >>927 >あなたのお勧めするデバイスは何?
推薦するCPUは特には思いつかないけど、推薦できないCPUはPICかな。
理由は君も書いている通りバグが多いしエラッタも修正しないから。
あと、8ビットPICはコアの能力が低く複雑な処理が出来ないという理由でも
採用は少し考えてしまう。
もっとも、プロなら客先からCPUを指定されることもあるし、
推薦するCPUとかしないCPUとかあまり考えないと思う。
>>928 >エラッタよりもっと恐ろしいのがマイコン生産中止
私としてはむしろ適当な時期に生産を終了して欲しいな。
CPUボードのCPUが入手出来ても、周辺の半導体やCRや機構部品などの
生産が終了すれば、結局、基板を作れなくなる。
客も適当な感覚で最新のCPUボードに更新していってくれないと、
メンテやサポート(開発環境の維持)、在庫部品の維持管理(保守部品の棚卸しなど)の
手間が掛かってしょうがないし、利益も出ない。
確かな根拠が有るわけでは無いけど、8〜10年位でどうだろうか?
>>929
実を言うと、私は前任者に少し同情しました。
全くの新卒者なのに、ハード、ソフトを教育してくれる人も居ず、
責任だけを負わされて、会社の体制にも大いに問題があったと思います。
課長もその点は反省したみたいで、次の採用者は中途採用の30代前後のベテランでした。
(>>923で嫌がられたのにまたも長文レス、申し訳無い、これで終ります) 割り込みの使い方も知らない人がソフト書いてることあるよな
PICみたいな超小規模マイコンを新人が一人で作らされたんだろうなって感じの糞コード
レビューを受けて愕然とした
一応大手のメーカーなんだけど 他との客観的な比較を出すように書いても出てきたことはない。 このスレにも割り込みの使い方を知らないヤツがドヤ顔でアセンブラで書いたって言ってたアホがいた
PICに執着してるようなヤツのレベルはこんなもん 日曜夕方の憂鬱なひととき、いかがお過ごしでしょうか メーカーもユーザーもレベルが低くて進歩がない
アセンブラで書くのが偉いと思ってるアホとか
30年も前のテクニックでドヤ顔とか
いまだに16F84を勧めるアホとか >むしろ適当な時期に生産を終了して欲しいな。
かなり前からこれを理由にPICを批判」している人がいるな。
しかもその理由が、他の部品がどうせディスコンになるから、なんて、おかしい。
この論理が通るなら、ディスコンにならない部品が非難されることになる、
通常、製品寿命が長いものについては、可能な限りすべての部品について
ディスコンにならないことを期待して部品を選択するよ。 アホの存在とチップの選択とは関係がないのでは?
まるで「Macは悪くはないけど信者が鬱陶しいから買わない」と言うのと同じぐらいに
非論理的な考え方です。 チップがダメ
開発環境もダメ
サポートもダメ
ユーザーもダメ >>939
ではスルーすれば良いのにスルーできない理由は何なのでしょう?
ここでアホとかドヤ顔と煽っても無意味じゃないでしょうか。 >934 返信に感謝。
ただ、推薦するデバイスが思いつかないのはあまり嬉しくはない。
あなたが何社のデバイスを使っているかも分からないが、その中から選択することは出来たはず。
正直、この答えでは単なるPIC批判に終わっているのが残念。
確かにPICは欠点も多いが、16ビット以上に限れば以下の点で使いやすい。
・周辺機能の多くは16ビットと32ビットで共通または類似でプログラムの使いまわしが効く。
・周辺機能の幾つかにはFIFOバッファが追加されており、複雑なプログラムを書かなくても
割込みの頻度を低く抑えられる。またはその分高速で周辺機能を動作させられる。
・同じことはDMA出もできるが、DMAの場合各デバイス毎に仕様が異なるのでプログラムの
可搬性の面からは面倒になる。
また、DMAのCH数の制約から全ての周辺機能に割り当てできないことが多い。
複数のデバイスメーカーを扱うなら、周辺機能のドライバの検証はそれなりに負担になる。
その意味では各デバイスにFIFOを追加してくれているのは非常に有難い。
この仕様が各社の標準仕様になって欲しいと思いが多分無理。 たかが電子部品のPICに、PICを使う人まで憎んだり恨んだりしているようで、
ストーカーの一種なんかね。 アンチが大量にわくのも人気のある証拠
人気のない製品は関心すら持たれない
わざわざPICのスレに来てアンチ発言してるくらいだから
PICのことが気になってしょうがないんだろうねw >>944
ある程度以上の規模なMCUなら
UARTのFIFOは大抵付いてるよ
付いてたとしても使い回しはちょっと
FIFOの有無とか関係無しに
一番違うのは割り込み関連
いずれにしろUARTドライバなんて超簡単な部類
こんなところに時間をかけたくない >>946
会社や仕事の内容を見れば技術レベルわかるじゃん。
しかもそれを得意げに書いてる時点で社会性や人間性もちょっとな 仲良くしたいんだけど
情報交換を妨げるヤツがいるから
エラッタの回避方法だって
信者のせいで語ることすら許されない 平日は客先や上司から理不尽な要求をされ、アホな部下の尻ぬぐいでストレスを
溜め、休日は5ちゃんでうさ晴らしですね >>951
>エラッタの回避方法だって
>信者のせいで語ることすら許されない
具体的なケースが出されているのに、その議論をすることが許されないほどに妨害があったっていつ? 具体的なことやソースを求めると誤魔化したり黙るのがエラッタエラッタと唱える人の特徴。 UARTは100%確実に発生るすソースもあがってる 信者に言わせると、
エラッタに引っ掛かるのはコーディング能力が足りないからだそうだ
普通に作ればエラッタの影響は受けないと
意味がわからん 夜は5ちゃんでハッスルハッスルハッスルハッスル!! 毎回毎回同じ話しかできないID:/uzfAU8KはNGにしましょう 今まで1回もまともな回避方法が出て来てないわけだが あ、
そういえば1個だけあがってたな
大分たってからだが 信者のせいでそういうのが埋もれるんだよね
実際にはいくつか方法があって
私も当選回避はしてるんだが
ほとんどの人はたまに問題が起きるのも知らずに放置してたんだよね
誰もエラッタについて知らなかったわけだから PICダメダメ信者が粘着して下らんレスするから埋もれるんじゃない? エラッタの存在の発見、エラッタの回避方法はある意味企業が
時間と労力を費やして発見したマル秘ノウハウみたいなもんだ
から、やすやすと掲示板に書着こむ人は少ないと思うんだ。
情報漏洩教育に厳しいマトモな会社の従業員ならなおさら。 マイコンはメーカーが社外秘資料を送りつけてくるので仕方なく対応してる
ディスクリート回路設計のトラブルは自社内ノウハウとして保有しているけどね 「ソフトのバグ」と主張してた信者さんは
知ってて意図的に隠蔽をしてたわけだね
そういうことにしといてあげる
まあ仕事で使うことは無いからもうどうでもいい
一通りPIC10F, PIC16F, PIC24, dsPIC, PIC32MM, PIC32MX, PIC32MK, PIC32MZと遊んできて
PICの良い点悪い点とこのスレのレベルの低さが良くわかった
たまにからかいに来るけどその時は対応よろしくね!
それからエラッタに関しては私の努力の甲斐あって、
わたし以外も書いてるようだ
私だと勘違いしないように どうでもいいと書きつつ、たまに来るとな
程度が知れますな
まあその程度の頭だから…なんでしょう >>871
あと、信者、信者と決めつけているけど、仕事の場合、プロジェクトとして
既に使う CPU が決定されていて、その条件下で技術者として製品品質
を確保しなくてはならない場合も少なくないと思うぞ。
自分は現役退いて久しいが、ルネなんかは政治的圧力で、偉い人が
勝手に決めちゃってたり。
エラッタ対策は概して出荷直前まで正攻法で動かそうと頑張ってしまう
ので、出荷直前にチップメーカーを呼びつけて血眼になって対策する
もんだ。懐かしいなぁ。 何がかんだいっても、AVRとかARMとかのスレが上がってこないのが
現実を示しているな armは、チップ買って作る人よりもボードで買う人が多いだろうから
ワンボードPCスレに、かなり話題が喰われてる気がすんな 昔、XXXXのNMOSのYYというCPUの日本代理店の営業マンが来社して、
「CMOSタイプを使ってくれ」と言われた事がある。
理由を聞いたら、「CMOSの方が新しいから」。
なんじゃそれ?と思い、NMOSタイプを買ったばかりで在庫もいっぱい有ったので、
無視して使い続けたら、納得できない不思議な動作をする。
で、CMOSタイプに変えたら問題無く設計通りに動く。
つまり、
NMOSのCPUにバグがあり、CMOSタイプで修正されたのを代理店は知っていたのに、
MOSタイプを回収したくなかったので教えてくれなかった、
という事なのね、と納得した。 訂正
MOSタイプを回収したくなかったので教えてくれなかった、
↓
NMOSタイプを回収したくなかったので教えてくれなかった、 >>977
なにをどこで何個買うかが決まらないと半導体の値段は決まらない >CMOSの方が新しいから
うむ、間違ってはない説明だったな
>なんじゃそれ?
そこで、新しいと何が違うのかを問い詰めるべきだったな >>977
5K公式価格では、
同じような機能同士の物を比べるとAVRの方が安いし
CPU性能は断然AVRの方が上
趣味ならそんな細かい理由で選ばなくて良い
一番良いヤツを買っても良いし、
わざとチープなのを買っても良い すまん。次スレは誰か立てて!
エラッタの話題を出しにくいという悲しみの投稿があったが
おれはそれを深く憂慮して同情する。
エラッタは発見も、回避もネットで公に情報交換や議論をするのにふさわしい話題だからね。
よって、PICのエラッタのためのスレを立てた。
https://rio2016.5ch.net/test/read.cgi/denki/1526300656
思う存分語ってくれると立てた甲斐がある。 >またスレ建て荒らしか
人聞きの悪いことを言うべきではない。
エラッタの話ができない、信者が邪魔をする、こんなだからレベルが低い。
前から繰り返されてきた指摘だ。
だったら、堂々とそれを話題にできるスレで議論すれば良いだろう。
スレタイになっていれば、もしエラッタに関する話題を不当に妨害する人がいても
その妨害がこそが不当だと退けることができる。
PICには考えられないぐらいの品種がある。エラッタだらけだ、という主張が確かなものであるなら、
ローカルルールで禁止されている「単発質問スレ」のレベルに収まらない話題があるだろう。 エラッタの話題はそちらに誘導してそちらでやってね
もう「PICにはエラッタが多い」ってだけの情報はここにはいらんから エラッタ情報はPICユーザーにとって必要不可欠のとても重要な情報だから、
エラッタ情報を妨害する人がいるからエラッタ関連だけを別スレにする、は本末転倒じゃ無いか?
エラッタ情報だけを分離、排除する理由が理解できない。
そんな事でスレッドを分ける位なら、8ビットPICとは縁の薄い32ビットPICを分離して欲しい。
つぅかそもそも個人が賛同を得ずに、勝手に「ここにはいらんから」とか内容を制限してよいのか? UARTは回避できない、I2Cは使えない、信者ガーって繰り返すだけの情報がいるって言ってる?
毎回下らんやりとりが繰り返されるだけなので
そんなに強調したいならテンプレにでも入れて消えてほしいんだけど いちいちムキになって相手にするからエンドレスの不毛のやり取りになるんだよ。
そだねー、とか、なぁるほどねぇ、とか、アンタが大将、とか言っておけばいいんだよ。 >>989
排除じゃないよ。
議論できないことを嘆くとき、取りうる一番シンプルで素早い解決だよ。
専用スレでも初めてスレでも同じような嘆きを書きつらねるばかりで、
エラッタの実際の検証に到れることが少なかっただろ?
それは環境のせいだったかもしれない。思う存分専用スレで語ればいい。
それに専用スレが盛り上がれば、こちらの方が傍流になるとも言える。
>そんな事でスレッドを分ける位なら、8ビットPICとは縁の薄い32ビットPICを分離して欲しい。
欲しい、ではなくて、必要だと思う人が必要に応じて立てれば良いのではないかな?
ともあれ、これからは、エラッタについては専用スレに誘導できる。
そこでは嘆く間もなく深い議論ができるだろう。いいことだ。 省略したら意味がわからなくなってる。すみません。
「PIC専用スレでも初めてのPICスレでも同じような嘆きを書きつらねるばかりで、」
「思う存分エラッタ専用スレで語ればいい。」
「それにエラッタ専用スレが盛り上がれば、こちらの方が傍流になるとも言える。」 高い
年間100個くらい工作する気じゃないと買えんな 愉快犯ってのは人通りの多いところじゃないと意味ないわけで。
キャンキャン吠えてる犬が別スレに動いてくれる筈も無く。 エラッタスレなんて、話題になったエラッタを鬼の首取ったように騒ぐだけで、
新しいエラッタや回避方法など有用な情報は何も出てこないだろう
エラッタ厨のレベル考えれば当然ここと このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 100日 12時間 57分 23秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。