PIC専用のスレ Part53 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
＿＿＿＿＿＿
／Microchip .／|
／ ( ﾟ∀ﾟ) ／ | アセンブラのアの字もわからない
|~￣￣￣￣￣| ／. 超初心者からHEXが読めてしまう
|/Ｚ./Ｚ./Ｚ./Ｚ_|／ || 鬼ﾌﾟﾛﾌｪｯｼｮﾅﾙの為のｽｯﾄﾞﾚ（#ﾟДﾟ）だ!ﾓﾞﾙｧ
||. ||. ||. ||
大人気のPICマイコンのスレ
なんといっても情報が豊富だし、開発環境も多いし、パッケージも豊富
使いやすくて、しかも安い。やっぱりPICだよね
例の如く基本リンクだ
http://www.microchip.com/ マイクロチップ本社(Microchip Technology Inc. )
http://www.microchip.co.jp/ マイクロチップ テクノロジー ジャパン 株式会社
http://www.microchip.com/maps/microcontroller.aspx Microchip Advanced Part Selector (Maps)
またーりやっておくんなまし
種類が多くてワカランって奴は上記パーツセレクタで、機能から最適製品を絞り込め！
教えて君はとりあえずGoogle( http://www.google.co.jp/ ) くらい使おう
テンプレ内の秋月小売価格も在庫が捌ければ、次の仕入れからは昨今の為替相場変動にならって
適宜価格改定されてます。ここの表記価格とは違うかもしれないのでそのつもりで
前スレ：
PIC専用のスレ Part52
http://wc2014.2ch.net/test/read.cgi/denki/1453468748/ 以下、C言語専門スレとなります。
アセンブラは別スレへ誘導されます。 実際 (C ： アセンブラ) の比率って、どのくらいなんだろう？
僕の周りでは、100：0 なんだけど。 アセンブラで全部作る人も居ない事はないだろうけど
Cのソース中にASMがちょろっと混じるぐらい普通じゃね？ 昔から安定して使われている仕掛けのメンテ、ぐらいしか利用状況ないんじゃね？
新規の仕掛けでASMで起こすって、あんまり考えられない。
新規だったら容量の問題とか、別な上位チップに置き換えて、とかやるし。
例えばPICの範疇でぎりぎりだ、という話なら別な手段を使うっしょ。
アセンブラソースをCに置き換えるってのはよくやる。
こないだ話題になったバンク切り替えとか、始めなんでこんなことやってんのか悩んだ。
Cから入ったもんで MPLAB-X v2.20でPICに書き込まれるIDを編集する方法をおしえてください。 タイミングの不要なLEDの点滅とかならCで十分。
もしくはモッサリプログラムで良いとか。 逆に私は一度だけでいいから簡単なプログラム(LED点滅等)をアセンブラでやっておく方がいいと思う。
一度でもやっておけば何が出来て何が出来ないのかの判断が多少なりともできるかと。
例えば 「初めてのPIC 0x07」スレの >915,921が作成可能かどうかとか
>使用しているPICは12F683です。
>回路ですがGP0からGP2までの3本にそれぞれセンサー部からの信号が入っています。
>どの信号も通常はGND電位でセンサーが感知したときの状態によって10または30uSのVDD電位のパルスを出します。
>タイミングは不定期ですが概ね15分に一度有るかどうか程度ですのでPICはほぼループ的に監視状態です。
>パルスを感知して10または30uSを判断したら10uSの場合はGP4を30uSならGP5を出力オンにするだけです。
>3本のどの入力の場合でも出力の処理は同じです。
>またGP3が出力のリセット用のスイッチにしていて通常はVDD電位でスイッチオンでGND電位になります。
センサの同時入力の有無で難易度が大きく変わりますが。 大文字SはSiemensやね
秒は小文字のsじゃないの？ 趣味も仕事もアセンブラだな。
なにか誤動作したときに言語のせいにしても始まらないからな。
たかが数キロのプログラムでCを使う必要が無い。 仕事は効率で判断しなきゃならないけど、趣味は使いたい方を選べる。 効率で言えばCだと思うけど、
>>22は、どちらもアセンブラなんだね。 俺も8ビットPICは仕事も趣味もアセンブラ。
RISCであるPICのアセンブラはあまりにも効率が悪いので、かなりマクロ化
して使ってる。
見た目はPICのアセンブラに見えないかも知れない。 >>24
最終的な品質まで考えると、アセンブラの方が圧倒的に良い。
やっつけ仕事ならCかな。 一方が頑なになると、融和的だった方も頑なになり、両極対決みたいになって最後は罵りあいになるんだ。
互いに他派のメリットを論じれば、理解せずに否定してるわけではないことの証になるのにな。 自営業とかで、他人がソースコードを触る可能性が無いなら
好きにすれば良いと思うけど、会社の場合は他人でも
メンテナンスできるようにCで書くのが基本だな。
高速化とか効率化のためにアセンブラ化を考える場合でも、
Cの関数単位でアセンブラ化して、アセンブラ化する前の
Cのコードはコメントとして残しておくよ。 https://pbs.twimg.com/media/CVX2OPvUYAEOESx.jpg
なんで C言語を 相手に 戦争を おっぱじめ たんだ!?
いまごろ アセンブラかよと いわれても 手おくれだ
いいか、 これは、 この世界で いちばん いい言語だ!
いちばん すぐれた 言語なんだ!!
おれには、 これしか ないんだ!
だから、 これが いちばん いいんだ!!
こんな感じかと まぁでもマジな話、アセンブラメインの人が書くビット操作関連のプログラムは芸術品だと思う。
短くて、早い、これはやっぱり美しいよ。コードとして。
Cから入った、初めに算術演算式ありきで覚えた俺には出来ない。
Cもむかーしからやってる人なんかはさらっと逆ポーランドで書いたりするけど、あれも美しい。 >>32
芸術品と言うか「そこでそんなやり方？！」って驚かされることが多かったなぁ。
FCのゲームとか改造してる時は特に多かった。
>>20
アセンブラだとループ構造とかも全てを自分で仕上げていくしかないから時間がかかる。
趣味だと時間を気にせずにプログラムを整えてプログラムを小さくしたり遊べる。
仕事(自分はやった事はないけど)だとやっぱり納期とか時間が限られてたりで
余計な所に手間をかけてる余裕はないだろうし、
アセンブラを扱える人が他にいないとそのプログラムのデバッグが出来ない。
とこんな感じかな。 >>27 >>30
Cしか出来ない奴（インライン展開しか弄れないレベルの奴含む）って、アルゴリズムを考える能力が低い。
だから品質の悪いコードを平気で書くし、それに気づいてない。
とくに、Cの縛りで変なコードを書いてしまったり、そもそも簡単に変な事を出来てしまうから
考えようとしなくなって、アルゴリズムを考える能力が低いままの奴が多い。
そして、そういう奴等が書いたコードが世に出回ってリコール騒ぎになるんだよ。
以前、某大企業で、電話のボタン入力部分にバグがあって、チャッタ除去出来てなかった為に
3億円分位リコールで対応したと聞いたことがあるw
最初からアセンブラで掛ける奴がちゃんと組んでれば問題ないのに、アルゴリズムを考える能力が低い奴が
書いたために、結果的に効率wが悪くなるんだな。Cしか出来ない奴の言う効率って
自分がいかに手抜きするかって事しか頭に無いから、トータルで見ると学生のお遊びレベル。 定番のC vs ASMで盛り上がってるところ失礼します。
HarmonyのUSBでdescriptorのHarmony configuratorで設定できる所以外を
ちまちまと弄りたい場合、方法はありますか？ なんにしても「○○しかできない」は幅が狭くなるような気がする。
高級言語ゆえに、練度の低い技術者でもプログラムを組めることはあるだろうけれど、
上の例で出てるようなチャタリング除去あたりは、練度の低いアセンブリプログラマでも
やらかしてしまいそう。
そんなことより特に8ビットPIC(とりわけ16以下)だと、C言語で組む場合でも、
他の素直なマイコンに比べて意識するべき癖が強いよね。
そういう地雷を避ける意味では、8ビットPICについては、アセンブリでの経験がある方が良いと思う。 >>35の言うチャタリングの話は、Cとアセンブラ、関係ないでしょ。
単に、ハードウェアの理屈を知らないだけだと思う。
なので、見当違いだと思う、 >>35は釣りなんだよな？
アルゴリズムの教科書でアセンブラを推奨しているやつなぞひとつも見たことない。
否定しているのは履いて捨てるほどある。
PICなどではなく高級なアーキテクチャのCPUのプログラミングマニュアルでも非推奨。
アセンブラしか選択肢がなかった50年前ならともかく、最近の教科書であったらぜひ教えていただきたい
というかどんなにハードリソースが厳しくてもアセンブラ使用不可の企業やコミュニュティばかりなわけだが、
現在のソフトウェア開発状況を全否定するところがすごいね。 >>19
私もアセンブラ派だけど
趣味でCPUやっている人がCを使うってどうなんだろ？
趣味ならプログラムの開発効率なんかよりも
使いこなす楽しさ（たとえば小さなCPUをマルチタスクで動かすとか）の方が
優先すると思うけどな
たとえていえば
「峠道を走るのが趣味です、ドリフト使って所要時間を少なくしたいです」
という人がオートマ車を選択するようなものでは？
・・・まぁでも、「峠道を走るのが趣味です、運転よりも景色を楽しみたいです」
という人がいても不思議じゃ無いかｗ
プロの選択基準はまた別の話だ >>40
峠道でドリフトするようなやつが迷惑なんだと認識してください。
ドリフトできるにこしたことはありませんが、普通の人は峠ではしません。
サーキットでもドリフトなんかするとタイムでないのでしません。最近はラリーでもしません。
どうしてもドリフトしたほうが良い場合だけこっそりやります。
ドリフトなんて好きな人が見栄でやるだけ。
それはドリフトしたいだけであって速く安全に走るのとは別。ドリフトが趣味ならいいですけど。
アセンブラも同様。趣味でやりたい人が使ってください。ドリフトしろと語るのは迷惑です。 どうしてアセンブラがいいって人はどうしようもなく喩え話が下手くそなんだろうな。
俺は確かに、コードは美しく、早い（本当は速いのまちがい）、と書いたけど、
汎用性がある、とか、メンテが容易、とか
第三者でも改変、改良がしやすい、なんてことはヒトッコトも書いてない。
アセンブラの弱点、というか宿命だよね。機種依存性が高過ぎるのも難点。
アセンブラの解析しなくてはいけないことがあるので、
かなりしっかりPICのアセンブラは使えるようになるまで勉強はしたけどね ここまでの流れは>>3がすべての元凶
出てきて謝罪するべき こちらにマックユーザがいるかどうか分かりませんが、もしOSXユーザの方が
いましたら教えてください
mal(microchip application lib)にはMacintosh用のHIB-Bootloaderツールも
一緒に入っていますが、実際にこのツールをOSX上で動かしてPIC18のファームを
流し込んだ事がある方はいますでしょうか？
El capitanでこのツールが正常に動くのか知りたいです ＞峠道でドリフトするようなやつが迷惑なんだと認識してください。
もちろん私自身はドリフトなんかやった事がありませんよ、誓います
一度、筑波であおられたことはあります、すぐに譲りました
＞どうしてアセンブラがいいって人はどうしようもなく喩え話が下手くそなんだろうな。
うーん、そうかぁ、残念です。じゃぁ、カレーを作るときに
A)市販のルーを利用する（C）
B)スパイスを買ってきて自分で調合する（ASM）
はどうですか？合格ラインでしょうか？ぜひ上手な見本を見せてください アセンブラ派の俺は、当然ホールのスパイスを買ってきてカレーを作るぞ。
市販のルーなんてカレーじゃ無いだろ。全然別物。 >>47
俺に手本を聞いてどうすんだよ
>>31で書いただろうが で、そろそろ 実行サイクル数計算するぜ自慢 の時間ですか？ >趣味ならプログラムの開発効率なんかよりも
>使いこなす楽しさ（たとえば小さなCPUをマルチタスクで動かすとか）の方が
>優先すると思うけどな
PICマイコンを使うことそのものが趣味なのか、趣味で何かをしていてその実現の手段としてのマイコンなのかでずいぶん変わります。
MTのクルマの運転そのものを楽しみたい人はMT車を選ぶでしょうけど、
趣味で旅行、趣味で釣り、趣味でバーベキューにでかける、など、趣味のためにクルマを使う用途はいろいろありますね。
カレーでも同じです。
プロがカレーを作るとき、拘りのある専門店は極めるような作り方をするかもしれませんし、
カレーに拘りのない定食屋さんや喫茶店ならレトルトを使うこともあります。
今の話題は、プロ以外がカレーを作る場合ですね。
カレーそのものが趣味の人なら、いろいろ拘りがあるかと思いますが、オフのときに何かの趣味に没頭していて
お腹が減ったなあ、そうだボンカレーを食べよう、ってのはごく自然なことです。
俺自身は、趣味の作品であっても、何を使って作ったかは、あまり関心がなくて、すげえモノであることの方に惹かれます。
このことはアセンブリあるいはCのどちらかを貶める意図はありません。すげえモノが作れるならどっちでも良い話です。 >>53を書いていて思ったのですけど、手段としてPICマイコンを使う人のことを不快に感じる人がいるのでしょうね。
ファン気質ってのはそういう傾向はありますが、内面だけにとどめておいて排他的にならないでほしいな。 >>53
同意
俺は同じ機能をARM,AVR,PIC,PSoC,Z80,6805,
8085で作るのが趣味です マシン語＝HEXファイル直書きこそ正義って方はいらっしいませんか？ >>55
6805？
ほんとに？6800とか6502との間違いじゃなくって？ >>55
ROM/RAM(2708-2764とか6264)入手出来るの？
周辺のＳＩＯ，CTC,PIO・8251・8253，8259なんかも。 >>32
同僚で、プログラム書けないのに逆ボーランド法でえっへん<(｀^´)>してる奴がいたなぁ
関数電卓も大学生協のポケコンも使えないのに、あれは何だったんだろう
最高速度30km/hの道路でドリフトするようなものか >>40
19だけど、例えば何かの実験をする時にシビアなタイミングを必要としないのなら
Cを使ったりはするかな。ループ処理の記述とか楽だしね。
>>58
64Kbit〜4MbitまでのROMなら揃えてあるな。RAMは6264と62256。
あと8255も何個か持ってる。
>>56
6502ならそんな感じだった。頭の中でニーモニックが浮かんでも実際にメモ書きする時は16進。 趣味で使う人でも、コード書くのが趣味の人と
マイコンを使って形にするのが趣味の人がいる・・・・
車で例えれば、車自体をいじるのが好きな人と
車は移動手段で目的地に行くのが好きな人がいる
それを一緒にしてはどうかと思うがな〜〜〜〜〜 >>57
6502のウチマチガイでした
ファミコンばらすと出てくる >>58
2764〜27256,周辺ICは昔買ったのが沢山ある、ROMライターはPC98 シビアなタイミングが必要なときは、CPLDを使うのは、反則ですか？
だって、アセンブラよりVerilogのほうが
簡単なんだもの。 >>65
他にも12F1と16F1の取り扱いが増えてるね。ええこっちゃ〜
16F1455の@260って価格がちょっと微妙な気がするのは内緒だけど、USBでhoge
したいなら16F1454@230円も扱ってるのがありがたい
12F1840@150円も扱いが始まってるから12F1822でメモリ足りない用途にちょうど良い
例によって秋月の商品ページの記述は間違ってるみたいだけど
（12F1822=2kword、12F1840=2kword） 16F88ですが、データシートを見るとRAポートはRA5以外は内部にダイオードクランプが有るようですが、
デジタル入力で使用する際に電源電圧を越えるような例えば電源5Vで使用時に10Vのパルスを入力しても
ダイオードクランプによって耐えれる物でしょうか？
ご存じの方、アドバイスをお願いします。 ダイオードでクランプされてるんだから１０Vの電圧掛けちゃまずいに決まってる。 抵抗入れたら抵抗で電圧降下してピンには１０Vかから無い >>73
>>70はそういうことも含めて質問してるんじゃないかと思う。 PIC16F145Xついに入ったか!
18F14K50に続いて積むぞー! 欲を言えば面実装版も入れて欲しかった
16F1454/1455は14pinしかないから1.27mmピッチのSOPでもかなり小さくて
取りまわし楽なんだよなぁ 70です。
レスありがとうごさいます。
元々、こちらのHPを見ていて
http://blog.livedoor.jp/kegakudan/archives/1021682193.html
ここではATtiny2313ですが、25Vを直接入力していました、これ。
自分はPICの環境しか持っていないのでPICではどうだろうか？とデータシート見たところATtiny2313と同じようにダイオードクランプがあったものの、積極的にそれを利用する使い方はした経験が無いので質問しました。 >>72
直列に抵抗を入れると、PICの内部抵抗とで分圧すると言う理解で良いでしょうか？ >>78
>>72じゃないけど
Input clamp current, IIK (VI < 0 or VI > VDD).... ±20 mA
ということなので1.5kΩが直列に入っているならVcc=5Vとして
1.5k x 20 mA + Vcc = 35VまでOKです。 【Enhanced Mid-Range】8bitﾏｲｺﾝ 新ｼﾘｰｽﾞのPIC12F/16F1xxx,旧ｼﾘｰｽﾞ(Mid-Range)より機能UPで値段も安い新規設計ならこちら
MIPS値はｸﾛｯｸの1/4 ('16/05版 USB対応チップ等追加)
◆[40pin] F1937の大幅値上げでF1939一択
-◎16F1939 \240 16Kw 1024 I/O36 Adc14 Cs16 Cmp2 Tm4/1 Ms1 Ec2/1 CCP2 SR LCD24
-×16F1937 \250 08Kw 0512 I/O36 Adc14 Cs16 Cmp2 Tm4/1 Ms1 Ec2/1 CCP2 SR LCD24
◆[28pin] F193xは値段差がつまりF1938で,1783&1716のｱﾅﾛｸﾞ強化&OPｱﾝﾌﾟ有りは用途に応じて
v◎16F1938 \210 16Kw 1024 I/O25 Adc11 Cs8 Cmp2 Tm4/1 Ms1 Ec1/2 CCP2 SR LCD16
-×16F1936 \210 08Kw 0512 I/O25 Adc11 Cs8 Cmp2 Tm4/1 Ms1 Ec1/2 CCP2 SR LCD16
^△16F1933 \200 04Kw 0256 I/O25 Adc11 Cs8 Cmp2 Tm4/1 Ms1 Ec1/2 CCP2 SR LCD16
v◎16F1783 \200 04kw 0256 I/O25 12adc11 Cmp3 OA2 8DAC1 Tm2/1 Ms1 CCP2 PSMC(仕様2+16MHz↑の動作に2.7V要)
*◎16F1716 \180 08kw 1024 HEF128 I/O25 Adc17 Cmp2 OA2 8DAC1 Tm4/1 MsP1 CCP2 PWM2 COG1 CLC4 PPS ZCD(仕様2)
◆[20pin] ｱﾅﾛｸﾞ強化&OPｱﾝﾌﾟ有りの1709とUSB機能の1459(48MHz=12MIPSも魅力)
-○16F1829 \190 08Kw 1024 I/O18 Adc12 Cs12 Cmp2 Tm4/1 Ms2 Ec1/1 CCP2 SR
-○16F1828 \160 04Kw 0256 I/O18 Adc12 Cs12 Cmp2 Tm4/1 Ms1 Ec1/1 CCP2 SR
*◎16F1709 \180 08kw 1024 HEF128 I/O18 Adc12 Cmp2 OA2 8DAC1 Tm4/1 MsP1 CCP2 PWM2 COG1 CLC3 PPS ZCD(仕様2)
-○16F1508 \150 04Kw 0256 HEF128 I/O18 Adc12 Cmp2 Tm2/1 PWM4 Ms1 CWG CLC4 NCO(仕様3)
*◎16F1459 \230 08Kw 1024 HEF128 I/O17 Adc9 Cmp2 Tm2/1 Ms1 PWM2 CWG ●USB(仕様4)
◆[18pin] 18ﾋﾟﾝの割に多機能
v◎16F1827 \150 04Kw 0384 I/O16 Adc12 Cs12 Cmp2 Tm4/1 Ms2 Ec1/1 CCP2 SR
◆[14pin] OPｱﾝﾌﾟ&多機能の1705,安価な1503,USBで1454/4
-◎16F1705 \110 08Kw 1024 HEF128 I/O12 Adc8 Cmp2 OA2 8DAC1 Tm4/1 MsP1 CCP2 PWM2 COG1 CLC3 PPS ZCD(仕様2)
*×16F1825 \165 08Kw 1024 I/O12 Adc8 Cs8 Cmp2 Tm4/1 Ms1 Ec1/1 CCP2 SR
-△16F1823 \100 02Kw 0128 I/O12 Adc8 Cs8 Cmp2 Tm2/1 Ms1 Ec1/0 CCP- SR
-◎16F1503 \080 02Kw 0128 HEF128 I/O12 Adc8 Cmp2 Tm2/1 PWM4 EUSART無 Ms1 CWG CLC2 NCO(仕様3)
*◎16F1455E \260 08Kw 1024 HEF128 I/O11 Adc5 Cmp2 Tm2/1 Ms1 PWM2 CWG ●USB(仕様4)
*○16F1454E \230 08Kw 1024 HEF128 I/O11 Adc&Cmp&DAC無 Tm2/1 Ms1 PWM2 CWG ●USB(仕様4)
◆[8pin] 容量、値段、機能の有無が大きいので用途に応じて
*○12F1840E \150 04Kw 0256 I/O6 Adc4 Cs4 Cmp1 Tm2/1 Ms1 Ec0/1 CCP- SR(仕様2)
-○12F1822 \100 02Kw 0128 I/O6 Adc4 Cs4 Cmp1 Tm2/1 Ms1 Ec0/1 CCP- SR ★LF&E/P仕様も\150で取扱
*○12F1612 \100 02Kw 0256 HEF128 I/O6 Adc4 Cmp1 Tm4/1 CCP2 EUSART無 Ms無 CWG SMT2 ZCD(仕様2)
-○12F1501 \070 01Kw 0064 HEF128 I/O6 Adc4 Cmp1 Tm2/1 PWM4 EUSART無 Ms無 CWG CLC2 NCO(仕様3)
◆表記 Tn/m=Timer[8bit]/[16bit],Ecn/m=ECCP[Full]/[Half],Cs=CapSense,Ms=MSSP,SR=SRLatch,OA=OpAmp,8DAC=8bitDAC
12Adc=12bitADC,HEFxxx=EEPRM無し代替に長寿命FLASHメモリ
共通 EEPROM256byte,EUSART,10bitADC,5bitDAC,1.024V基準電圧,温度計
型番にE付き→通常のI/P仕様(max85℃)ではなくE/P仕様(max125℃)のみ取扱
◆標準仕様 VDD1.8V(max16MHz)〜2.5V(max32MHz)〜5,5V,4xPLL有,内蔵OSCでも32MHz可
(仕様2) VDD2.3V(max16MHz)〜2.5V(max32MHz)〜5,5V,4xPLL有,内蔵OSCでも32MHz可
(仕様3) VDD2.3V(max16MHz)〜2.5V(max20MHz)〜5,5V,PLL無,内蔵OSCで16MHzまで
(仕様4) VDD2.3V(max20MHz)〜2.7V(max48MHz)〜5,5V,3x&4xPLL有,内蔵OSCでも48MHz可
◆ﾌﾟﾛｸﾞﾗﾑ面で新命令追加,bankは32ﾏﾃﾞ拡張,ｽﾀｯｸ16ﾚﾍﾞﾙ,LATが追加,割込時のﾚｼﾞｽﾀ自動保存
16bit幅で2本になったFSRﾃﾞ別ｱﾄﾞﾚｽに連続配置RAM(0x2000〜)やﾌﾟﾛｸﾞﾗﾑ領域(0x8000〜)ｱｸｾｽ可能
◆追加命令群
ADDWFC,SUBWFB : ｷｬﾘｰ,ﾎﾞﾛｰを含んだ加減算
ASRF,LSLF,LSRF : ｼﾌﾄ命令
BRA : PCLATHやﾍﾟｰｼﾞ境界に関係なく相対ｼﾞｬﾝﾌﾟ [9bit幅] PC+255〜PC-256へ
BRW : PCLATHやﾍﾟｰｼﾞ境界に関係なく前方へのみ相対ｼﾞｬﾝﾌﾟ PC+W(0〜255) ADDWF PCL,f ﾖﾘ便利
CALLW : 上位はPCLATH,下位はWのｱﾄﾞﾚｽにｻﾌﾞﾙｰﾁﾝｺｰﾙ
MOVLB,MOVLP :ﾊﾞﾝｸｾﾚｸﾄ,PCLATHに直接定数入れる
TRIS,OPTION :TRIS(A〜C),OPTION_REGにWの値入れる(非推奨だったが以前から有り)
RESET : ｿﾌﾄｳｪｱﾘｾﾄ
ADDFSR : FSRに定数(-32〜+31)加減算
MOVIW,MOVWI : INDFｶﾞﾂｶｲﾔｽｸ FSRに対して[PRE/POST][+1/-1]や定数(-32〜+31)offset可能 F1454/5 なんか割高と思ったら、なにげにEP？ IPでいいのに・・・ >>66
6805だったか6808を昔使ったんだけど、あれこそアセンブラで書かないとどうしようもない。
4Bitマイコンとかとほとんど変わらない。
あんなの趣味で使うとか面白いけど入手とかどうするのかなと思って。ワンタイムだしICEむっちゃ高いし。 16F1455と1454って何が違うのかと思ったら1454には
ADCコンバーター付いてないのね >>82
仕事で使ったよ
量産するのになんか6809より安いって話だった
Cコンパイラとアセンブラの併用だったけど
レジスタがちょっと少なくて苦戦したけど
それでも命令直交性の良さでカバー出来るものだった
入手性とか価格とかはハードの人達でないとわからん
TP組んで、結果から続き作っただけだし >>84
6809と6808(6805)はチップ構成やらアーキテクチャからして異なる。
8085が8086と値段が違うといってるようなものだな。
6809はマルチチップのほぼ16bitに近いレジスタ構成。6805は6800ベースのワンチップ構成。
でも使いやすかった。
スレ違い申し訳ない >>ID:Ss0D/KjY
スレ違いだという自覚はあるが書かずにいられない
あやまれば何でも許されると思っている >>74
勝手に解釈すんなよ。質問する側にちゃんと質問する癖をつけさせろ。
なんで質問する側が手抜きして情報後出しなんだよ。 >>88
いいじゃねぇか。嘘や間違いを教えられて痛い目にあうのも勉強ってもんだろ。 >>88
僕も、>>74と同じように感じたけどね。 >80
なんか知らないうちに色々機能追加されたチップが追加されてるんだな。
USBみたいにわかりやすいのの他にZCD (ZERO-CROSS DETECTION)や
SMT (SIGNAL MEASUREMENT TIMER)とか
12F1612のデーターシートみるとPORT関連の各ビット単位設定も追加されてる
PORTx ,TRISx ,ANSELx .WPUx ,LATx は知ってるけど
INLVLx (入力電圧レベル設定 ST/TTL)
ODCONx (オープンドレイン出力設定)
SLRCONx (スルーレート上限設定)
必要か・・？とも思うけど、あればあれで便利な場面もあるか つか5Vトレラント位、全ピンでやってくれよと思う。 >93
それって5Vで動かせばいいだけじゃないの？
VDDの上限が5Vないチップに関してはしょうがないけど そろそろ電源＆書込関係だけ縛りのピン配置自由なPICがほしいな
搭載モジュール別にしてほしいよ >95
全部の周辺モジュールは無理だろうけどPPS機能のついてる16bitPICや8bitPICの一部は可能かと
>*◎16F1709 \180 08kw 1024 HEF128 I/O18 Adc12 Cmp2 OA2 8DAC1 Tm4/1 MsP1 CCP2 PWM2 COG1 CLC3 PPS ZCD(仕様2)
>-◎16F1705 \110 08Kw 1024 HEF128 I/O12 Adc8 Cmp2 OA2 8DAC1 Tm4/1 MsP1 CCP2 PWM2 COG1 CLC3 PPS ZCD(仕様2) >>93
全く完全に同感
Cypressのマイコンは全ピン5Vトレラントでこの点だけは使いやすかった
PICにも5VトレラントなIOピンを持つ品種もすこしあるけどピンが限定的すぎ 5Vトレラントって、どんなときに必要ですか? あんまり必要性を感じないけど。
5V信号---->入力(3.3V電源PIC) のトレラントですよね? 抵抗1本ではダメなのでしょうか?
出力も0-5Vが欲しいとか? クランプダイオードに期待しすぎでしょ。
それに、+3.3Vが落ちている時に5Vがかかると、3.3V系のデバイスに
5Vがかかることになるけど？ >99
>それに、+3.3Vが落ちている時に5Vがかかると、3.3V系のデバイスに
>5Vがかかることになるけど？
こう書かれると、VDDへの+3.3Vが落ちている時に入力ピンに3.3Vなら掛けても
いいように聞こえるけど、それって絶対最大定格を逸脱してないかい？ >>100
ダイオードを通してVDDに行くので、Vf以内だから、いいんじゃないか？ 最近になって秋月で取り扱いが始まった12F1840ですが、12F1822用のHEXファイルを
そのまま適用出来ますでしょうか？ >>94
5Vで動かせるもので、5Vトレラント謳ってるものってあるの？ >103
ああ、PIC32限定の話だったのね。レスアンカーついてないけど>80,92の後に"つか"とかで
続けたからてっきり>80の一覧の事だと勘違いしてた。16bitならPIC24FVやdsPIC33EVあるし >101
絶対最大定格は大抵こんな表記だぞ
Voltage on all other pins with respect to VSS -0.3V to (VDD + 0.3V)
VDDに電圧かかってない状態なら0.3Vまでしか許容しない。 それじゃA/D入力も切断しないといけないっつぅことになるなね。 >>105
厳格にそれを解釈すると、クランプダイオードのVfが0.6Vであるなら、クランプダイオードでは
絶対最大定格を逸脱することになるのだけど、実際は、クランプダイオードに電流が流れるような
VDD+0.7V、GND-0.7Vは許容しています。低インピーダンスの信号源をつないでクランプダイオードに
じゃんじゃん流れるのは禁忌で、入力許容電流という形で表現されています。 >>99
クランプダイオードを通じて電源電圧が供給されてしまうのは、割とよくあるトラブルで、
外部コネクタを接続したら、リセットがうまくかからないとかありますよね？ ない？ >>98
>5Vトレラントって、どんなときに必要ですか? あんまり必要性を感じないけど。
抵抗で済む場合もあるけれど、5V側の消費電流を増やしたくないときとか。
抵抗値を上げて対応できるときはそれで済ますことはあります。 ということは、そのような場合で抵抗で対処できない場合のみに
5Vトレーラントが必要と言うことですね。
だったら、さほど必要ではないということですね。
すると>>93,>>97の意見は、どうなるのかな。 疲れるから馬鹿を相手にする気は無い、とだけ書いておくよ >>110
>ということは、そのような場合で抵抗で対処できない場合のみに
待って。俺の使い方が世の中のすべてじゃないから。
自分の望む結論を導くことを急がないで。 >>111
>疲れるから馬鹿を相手にする気は無い、とだけ書いておくよ
それはそれで失礼な話です。 >>110
こういうケースはどうでしょうか。
クランプダイオードに流す場合は電源にその電流が流れ込むわけですし、もともと
3.3V系の消費電流が小さいと吸収しきれなくなりますね。
5Vトレラントであればそういう心配はいらないことになります。 1つ分からないんだが、Vdd+0.3Vを超えてもクランプ電流の制限±20mAを超えなければいいんだったら、
Vdd+0.3Vの制限は何のためにあるんだ?
±20mAの制限だけじゃ駄目なの? >>115
高電圧でもストレスを与えるからじゃないかな…？
高電流よりはかなり緩いんだが、寿命が一気に縮まる上になかなか特定できないんだよね、思い込みで作ってたりすると。
と聞いた気がする。 >107
確かに実際は大きめの電流制限抵抗(数十kΩ)を入れれば大丈夫だけど
その場合なら>99のいう電源OFF時に5V入れても許容できるわけで
>99の3.3VはOKで5VはNGみたいな表現はやっぱりおかしい。
電源オフ時に入力ピンに直結で3.3Vいれたら>108で指摘されてるように誤動作するし
>106
外部電源で電流がじゃんじゃん流れてくるようなら切断するなり電流制限抵抗入れなきゃ当然ダメでしょ。 >>117
なんだか「5Vトレラントなんて要らなくて抵抗で済む話じゃないか」って方向に話を進めようとしているように見えます。
そんなことはないですか？
5Vトレラントが使えることがセールスポイントになっているデバイスは少なくありません。
ってことは、それを必要としている人がいるってことです。
5Vトレラントに限らず、「俺から見てあまり役立ちそうにないように思える機能」が入っているデバイスってたくさん
あるかと思いますが、「そんなものを必要とするなんておかしい」と考えるよりは「役立つのはどんな場面なんだろう」と
考えを巡らせる方がずっと楽しくて有益だと思います。 >118
5Vトレラント使うくらいなら5V電源で動かせばいいじゃんとは思ってます。
PIC16F1や、PIC24FVなんかはレギュレーターを内蔵して内部動作電圧のみ
低電圧化させて、入出力で5Vが可能です。5Vトレラント入力よりずっと使いやすいかと。
Microchipもそう判断しているからPIC16F1やPIC24FVのレギュレーター内蔵品を
製品化したのではないでしょうか？ >>117
A/D入力で電流がじゃんじゃん流れるわけないだろ、無知すぎる。 A/D入力ピンは通常高い入力抵抗だがサンプル&ホールドが開始されると
低くなる・・・・（とはいってもじゃんじゃん流れはしない）
しかし、保護ダイオードが入っているので電源電圧よりはるかに
高い電圧がかかればじゃんじゃん流れ込み、結果としてマイコンの
電源に高い電圧がかかることになります。
これは、とても危険なことです・・・・ >>108
半端に動いてしまって変な現象が出るとかね。
>>117
＞>99の3.3VはOKで5VはNGみたいな表現はやっぱりおかしい。
ちゃんと意味が理解できてないでしょ？
抵抗入れればいいっていうのは、クランプダイオードの電流制限を
かけようっていうだけだからね。
>>119
＞5Vトレラント使うくらいなら5V電源で動かせばいいじゃんとは思ってます。
必ずしも、所望のものが5Vに対応できているってわけでもないしね。
3.3V向けに作ったコアを5V向けにリファインしなおすくらいなら3.3Vの
ままI/Oだけを5Vトレラントにする方がいい。+5V入力が必要なお客の
ニーズも取り込める。
「オトナの事情」の一種かもしれませんな。 >123
すいません、私には>99の説明が VDD上限3.6V品のマイコンにVDD=0V(電源OFF)状態でも
入出力端子に3.3Ｖなら掛けて良いと読めましたけど違うのでしょうか？
5V入れたら耐圧的にもNGですが、3.3Vも絶対定格的にNGですからどちらもダメなはずですが >>120
>>121の話は理解できましたか？
じゃんじゃん流れないのは、抵抗も含めてそういう回路にするからですね。 >>119
世の中、何かの方式に収束すれば済むことなんてなくて、いろいろなアプローチが
できるようになってる方が、良いと思うのですが。
5Vで使えば良いというのは一つの解決方法ですが、ほかに3.3Vでないと動かない
デバイスもあれば必ずしもそうはいきません。
5Vトレラントも含めて複数の電圧を扱えるマイコンが求められる場面もあるものです。 >>124
>>99が3.3V、5Vの2電源混在のシステムを想定していて、必ずしもそのふたつの電源が
同時にON/OFFしないのであれば、そもそも3.3V系が落ちているときに、3.3Vがかからない
という考え方かもしれません。
こういう条件も考えられます。
・3.3V系の消費電流が5μA程度である。
・外部の5V系デバイスとは直列抵抗を介して接続している。
・クランプダイオードのVfが0.6Vとする。
・3.3V電源は吸い込みのないレギュレータで構成されている。
・3.3V電源は落ちている。
・5V系の電源は生きている。
この場合、5V系の回路が5Vを出力したとき、直列抵抗の抵抗値が100kΩ程度だと3.3V系の
電源電圧は3.6Vを超えますね。 >>113
最初から結論ありきで話してて人の意見をまともに聞かない馬鹿は失礼にあたらないの？ >>115
> Vdd+0.3Vを超えてもクランプ電流の制限±20mAを超えなければいいんだったら、
> Vdd+0.3Vの制限は何のためにあるんだ?
0.3Vプラスまでなら、100A配電盤からの直結でも問題ないです、ってことでは？ >>125
＞電源電圧よりはるかに高い電圧
これがどの程度のことを言ってるのか分からないがA/D入力の規定範囲内ならそれが電源掛かっても壊れるほど流れないでしょうよ。 >>130
5Vトレラントの話の中でのことなので、「(マイコンの)電源電圧よりはるかに高い」
は少なくとも5Vは想定して良いと思います。
電源電圧が3.3Vであるとき、5VあたりがA/D入力の規定範囲内に収まるようなPICマイコンって
具体的にどんなものがあるのでしょうか。 > Vdd+0.3Vを超えてもクランプ電流の制限±20mAを超えなければいいんだったら、
> Vdd+0.3Vの制限は何のためにあるんだ?
IC内部の入力ピンのパッドがVddに対して0.3V以上高くなったら、
たとえクランプダイオードに流れる電流が少なくても、他の部分
にダメージを受けるかもしれないから、製品として無事である
保障はしないよってこと。
Vfの値は温度によっても変わるしね。 >>132
と言うことは>>77のリンクのATtiny2313の使い方も間違ってるよね。 メーカーによって5ｖトレラントを実現する方法は複数あるのが
実態のようです。
あるメーカーは、電源側の保護ダイオードをはずして入力のFETの
ゲート電圧耐圧を上げる方法とってるらしいです
あるメーカーはバッフア回路を入れてるらしい。 Vdd+0.3Vを超えたら±20mAを超えなくても駄目なんだったら
±20mAの存在意義が無いからそれは無いと思うんだけど、
Vdd+0.3Vを超えずに入力ピンに20mA以上って流せないと思うんだけど 思うのは個人の自由。何回思っても良いぞwww 憲法でも保証されてるw
だが、データシートは絶対。 どうせダメって言っても納得しないんでしょ？
自分に都合の良い回答しか受け付けなさそう >120
人に無知とか言う前に話の流れをよく読もうよ。>99 >100 >101 >105 >106 >117後半
AD入力側のマイコン側の電源が落ちている状態(VDD=0V)の話だぞ
マイコン側の電源が落ちているのにAD出力側の電源が入っていて
マイコンの入力ピン(電源落ちているからAD入力や出力とも区別無いが)に
電圧かけたらマイコン内部のクランプダイオードを通じでマイコンのVDD端子に
流れる、マイコン側のVDD=0V状態なんだから 外部電源のAD出力を
ダイオード介してGNDに直結するようなもんだからじゃんじゃん流れるだろ。
マイコン側(VDDを共有するマイコン以外も含む)の回路規模が小さければ
ADの電圧によっちゃマイコン側が動作するかもしれない >>139
まずは「電圧と電流の両方の規定があることが妥当であるという前提」で考えてみてはどうですか。
そうすれば>>129さんのような視点も出てきます。
あなたの場合、
「俺、すげえ合理的。両方の規定があるのはムダ。データシートに両方書くメーカーってバカだねー」
みたいな思い込みが先に立ってます。
あと、
>Vdd+0.3Vを超えたら…駄目
という読み方をすると、データシートを読むのは難しくなります。
確かに、「絶対最大定格は一瞬たりとも超えてはいけないもの」のような定義をされていますが、
この文言(一瞬たりとも)に拘って先に進まない人はつらいな。 >>142
自分が求める答えが得られるまで、いろいろな人に尋ねる人がいますね。 >>145
>この文言(一瞬たりとも)に拘って先に進まない人はつらいな。
拘れよ。一番重要な事だろ。そんな決まり事を自分の解釈でねじ曲げるから
℃素人って言われるんだよ。そもそも先に進まないのは馬鹿だからだし
自己解釈でねじ曲げて進んだ所でそんなのは進んだとは言わない。馬鹿にも劣る。 ＞Vdd+0.3Vを超えたら±20mAを超えなくても駄目なんだったら
＞±20mAの存在意義が無いからそれは無いと思うんだけど、
思うのは自由だけど、意義はある。
＞Vdd+0.3Vを超えずに入力ピンに20mA以上って流せないと思うんだけど
思うのは自由だけど、流れてしまうこともある このくらい優しく書いてもらわないと駄目なのかな？
ttp://www.analog.com/media/jp/technical-documentation/raq/RAQ50_J.pdf ROHMでは0.3Vを超えても良いと言ってるけど。
＞VEE-0.3V よりも低い電圧もしくはVCC+0.3V よりも高い電圧を入力した際に入力端子に
＞電流の流れ込みもしくは流れ出しが発生し、特性の劣化や破壊につながると説明いたしました。
＞これを防ぐ方法として、入力端子にクランプ用の順方向電圧の小さいダイオードを設ける、
＞もしくは抵抗を挿入して入力端子に流れる電流を制限する方法があります。
＞前者はIC に入力される電圧を制限する方法であり、後者は電流を制限する方
＞法となります。入力電流は10mA 以下となるように抵抗を設定して下さい。
＞図2.4.1 のVF はダイオードの順方向電圧でおおむね0.6V 程度として下さい。
http://rohmfs.rohm.com/jp/products/databook/applinote/ic/amp_linear/common/opamp_comparator_tutorial_appli-j.pdf PICkit2 Programmerに関して質問なのですが、
プログラムを作り、書き込んで修正して、再度書き込んでとしている時に、
開発環境が出力するHEXは更新されているにもかかわらず、
実際のPICの動作が変更されていない事がありました。
当初、PICが壊れたのかと思い別のPICを使っても同じでした。
何処で問題が有るのかと注意深く見ていたところ、
PICkit2 ProgrammerでHEXを読み込んだ際に画面上部にあるChecksumが
変わっていないのに気が付きました。
しかし、画面下部のProgramMemoryの各アドレスの値は変更されています。
PICkit2 Programmerでこのようなバグなどあるのでしょうか？
ご存知の方、情報をお願いいたします。
開発環境はMikroCを使用しています。PICは16F88を使用しています。 >>148
>拘れよ。一番重要な事だろ。そんな決まり事を自分の解釈でねじ曲げるから
それはデータシートの見方がわかっていないと思います。
もしも「何を!」と思うなら、下記に示すデータシートの電流ついての注釈について、解釈を捻じ曲げない立場で
説明をしてみてください。さて、できるかな、わくわく。
>>150のリンク先にも一瞬たりとも超えてはならぬ、とあるわけですから、それだけを
拠り所にしてしまうと、もうそれを信じるしかなくなるのは分からないでもありません。
もしかしたら、怖い先輩や先生にそういうふうにキツク言われたのかもしれませんね。
>>150が聖典をあがめる信者のように例にしたアナログデバイセズ。そこのオペアンプのデータシートです。
ttp://www.analog.com/media/jp/technical-documentation/data-sheets/AD8622_AD8624_jp.pdf
絶対最大定格の電圧は、±電源電圧です。(なんと+0.3Vみたいな話もなく、±15Vで使えば、±15Vが制限です)
電流については10mA。その電流の注にこうあります。
>入力ピンには、電源ピンへのクランプ・ダイオードが付いています。入力信
>号が電源レールを0.5 V 超えるときは、入力電流を10 mA 以下に制限する必
>要があります。
ね、電源電圧より上回ることを許容しているでしょう? ここPICのスレなんだけど・・・
この子はスレタイが理解出来ない子なのかな？（；´Д｀） >>154
注に書いてあるということはそれも含めての絶対最大定格だよっていう
ことも理解できない方ですか？
それとも注意書きは最大定格とは別物なのだと思っている？ >>148
サージとか静電気とか、ごく短時間は絶対最大定格に含まれないと思うけど
あくまで絶対なんですかねぇ
今飲み屋で、王様の言うことは絶対！って言ったら女の子に笑われるぞ >>155
すみませんね。アナデバの資料を根拠にした話だったので、アナデバの資料を提示した次第です。
>>156
その注釈がなくても電圧は超えても大丈夫なのですよ。
クランプダイオードの存在とその電流をちゃんと解釈できる場合、という条件が付きますが。
この例のデータシートの場合は絶対最大定格の表の注釈にそれが書かれていて、
よく読めない人にとってもわかりやすくなっていますが、本文の中に紛れているケース、
当たり前だから書かれていないケースなどいろいろです。
教える側にとっては、こういう人は難しいだろな。電圧を超えても大丈夫だと教えたら
今度は四角四面に「絶対最大定格の電圧は超えても良いと教わった」って考えてしまいそうです。
それぐらいなら「絶対超えちゃだめだ」と教えておく方がリスクが低いかもしれません。 上にも書いたけれど、絶対最大定格の電圧については>>129さんがわかりやすい解釈をしてくれているのにね。 無能なヤツほどだらだらと冗長な文を書き連ねる
ってことがよくわかるね ごめん、馬鹿を相手にするの疲れたからこの話はやめる >>158
>すみませんね。アナデバの資料を根拠にした話だったので、アナデバの資料を提示した次第です。
なんでマイクロチップのICの話してるのに違うメーカーの全く違うデバイスの話をしてるんだ？
頭おかしいんじゃねw
プロセスも回路も違うアナログICと比較しても正しい保証は無いんだが
理解できないほど頭が悪いのかw PICのEUSARTの送信割り込みって送信バッファが「あり→空」に変化した時だけ
割り込みかかってくれればいいのに・・・
空だと常に割り込みが発生し続けるって気づくまで挙動不審に難儀したわ >>167
それそれ。僕も填った。しょうがないので、自分で変数持って、微分した。
あと、
1) 書き込みレジスタが空になったぞ(=書けるぞ) 割込
2) 送信シフトレジスタが空になったぞ 割込
などあって、理解するまでに時間がかかる。
RS485の送受信切替を1)でやって、エライ目にあった あれ、割り込みで送信する場合でもTRMTとTXIFを両方チェックしないとダメなんだっけ？
片方しかチェックしてなかった・・・ >>165
そらーZ80とか難しくて断念した人達が楽なPICでやっと手にいれた、自分デモできるマイコン工作の趣味を長年やってて
頑固になった
柔軟性がなくなった爺が多いからしょうがない >>170
Z8は楽勝だろ、一部レジスタがひっくり返るのとスタックのOVF気にすれば大抵のことは楽勝だったぞ。
東芝のTMPZ84で2000年ぐらいまで使ってたわ。
8255とか大量に繋いで制御も簡単だったからな。
あれが出来ないとかありえないだろ。 >>167,168
16550っぽく思って、使ったら同じ目にあった。ｗ >>167
「とりあえず空なら割込みが入る」っていうのは便利なこともあるけどね。 >>175
リングバッファにセットして割込有効にした途端に送信開始するよねｗ >>176
そうね。X-ON/OFF制御の時とかね >>171
まあ、PIC 普及前のアマテュアの製る Z80 システムってば
32pin や 40pin DIP のばかでかい IC が 4〜6 ヶ、
標準ロジック IC が 10 ヶほど並んでおり、
ワイヤラッピングでなければジャンパー線が
夏の蔓草のようにからみあい、もりあがっていたでは
ありませんか ﾐ'д ` ﾐ >>172
ん？みんなZ8って行ってたんだよ当時は。
>>178
それが嫌でTMPZ84C011とかに乗り換えたんだよ。
AKI-80とかベースにすると便利だった。 Z80とは全く別アーキテクチャの
Z8というプロセッサが存在する。
https://ja.wikipedia.org/wiki/Z8_(%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9)
http://www.st.rim.or.jp/~nkomatsu/zilog/Z8MCU.html 当時はSIOを内蔵したTMPZ84C015をよく使ったわ 末期には、KL5C8400とか出てたなー
鉄屋までぜっぱち。 >>185
なにやらパチンコの基板のあたり判定とかする部分は、認定の関係で未だにZ80系らしい。
しかもメインのプログラムが3Kとか最大のサイズも決まってるとか…。だからZ80系の需要は未だにある。
最も、液晶に絵を出したり、派手な演出とかは全部が子基板で親子の関係がひどいｗ PICで処理しきれないから外側にFPGA付けるようなもんですね >>179
音でいうぜっぱち
何故にあんなにヒットしたのだろう うはリロードしたら181、183両氏が書いてた
はずかちー >>187
>認定の関係で未だにZ80系らしい。
なんで、いつまでもZ80に拘るのでしょうか?
認定の関係と言っても、認定担当者も世代交代しているだろうに。
Z80しかわかんない年寄りが、しかも実際のアセンブラソース見て認定してるとか? ぶっちゃけマイクロソフトのBASICが8080系列で書かれていて、
Z-80マシンへの移植、展開が楽だったからではないでしょうか。
ハードウェアの爆発的な普及でソフト市場が安定したような。
6809とか6502なんかに比べるとプログラム書きやすかったですし。
あの頃だと速度の問題はあったけど実数が気軽に扱えるMicrosoftのBASICは便利でした。 >>187,193
2764だったかな8KB-ROM。今はCPU内にROMを内蔵したパチ専用のカスタムチップ。
だからその都合だと思う。
むかーし、メーカーの仕込みで
どの流れでもプログラムの実行速度が変わらないように命令のサイクルをすべて合わせて
大当たりカウンターに偏りを持たせて天国モードと地獄モードを作っていた機種まである。
その事に気が付かなければ検査してもプログラム上には何の仕込が無いように見えるから。 4004,8008から
♪思えば遠ォくへ来たもんだァ〜♪
プログラム不要の人工電子頭脳までもう少しだから
ジーチャン達は長生きしてメイドの土産に見届けるんだぞ。
・・・
ア、間違った、冥土だった、
まさかプレゼント持ってメイドカフェに通っているジーチャンはいないだろうな。
いたら俺にも紹介してくれ（笑） ザイログ製（だったと思う）Z80のセラミックパッケージをアキバで見つけたとき衝動買いしそうになったなぁ。
68000のあのでかいパッケージも意味もなく欲しいと思った。 ArduinoUnoを用いて液晶パネルに画像を表示させようと考えています
こちらのサイト(http://plaza.rakuten.co.jp/aisuke37/diary/201502150000/)を参考に
AdaFruit ILI9340ライブラリのスケッチ例(graphictest)を用いて2.2インチ液晶(http://www.aitendo.com/product/7277)にArudinoを接続したのですが
コンパイルとボードへの書き込み自体は成功しているようなのですが、LEDバックライトが光るだけで文字が出力出来ません.....
配線はgraphictest内のUNOに対する指示に従って接続しているはずなのですが何故動かないのでしょう.....
最悪別のライブラリを使用してもいいのでどうにかこの液晶パネルを使用することは出来ないでしょうか? >>198
スレチ致しました、すみませんお流しください...... >>196
今時の年寄りは>196より長生きするかもなぁ。 秋月でPIC16F1705買ってきた。
8音ピコピコMIDI音源作るぞ。 何もかも初心者なのですが、助けてください
MPLAB X IDE v3.30でpwm.hなどがインクルードできません
コンパイラはxc8です（v1.37)
〜/Microchip/xc8/v1.37以下を検索してもpwm.hなるファイルもありません
pwm.hをインクルードする前の状態ではビルドできて一応実機で動いてますが
#include 〈xc.h〉
#include 〈p18f4553.h〉
のあとに
#include 〈pwm.h〉
を追加すると赤い下線がついて
Can't find include file
といわれます
ファイルはどこかから別途ダウンロードがひつようですか？ >>203
includeのなかのplibにありませんか？？
そのため
#include <./plib/pwm.h>
と記述する必要があるのでは？？？ >>203
最近のバージョンはライブラリが別になってる。
マイクロチップとしては、コードコンフィグレーター押し xc8 v1.34までなら可能のようです。
それ以降には入っていません・・ >>202
サイン波1音までは出来た。
FM音源もdspicも今の自分には難しい。 >>209
サイン波1音なんてCしか出来ない奴でも出来る。
アセンブラでチマチマネチネチ弄ると10音ポリでも余裕で出せるからガンバレ。 ちなみに、下手な音源作るよりFM音源の方が圧倒的にやさしい。
足し算と掛け算だから、原理を知ってればアセンブラで書くのは容易いし
Cだと10分の１以下しか速度が出ないから、DSPICの勉強にうってつけだと思う。 〜は易しい、〜は簡単
という奴に限って自分では何も作ってない法則 悔しそうだなwww
Cしか出来ないからLEDの点滅位が関の山なのかwww >>210
サイン波2音までできた。
DAC1個で1音、アナログにしてから、オペアンプのミキサーで混ぜてる。
これでも今までは矩形波しか作ったことないから感動した。
FM音源だと、1チップで10ポリができるのかい？すごいな。 C言語でもクロック上げれば出来るよ
そんなにどうこう言うべきことではないと思う
結果として出来ればどんな方法でも問題はないし
趣味でやっているのだからどうでもいいのでは？？？ >>216
せっかくのDSPICなんだから、プログラムで足し算して結果をDACに送ればいいだけ。
FM音源はアルゴリズムが簡単＆DSPICにマッチするから、少ないステップで発声出来る。
サイン波が出来たらその読み出し周期に別のサイン波なりエンペローブなりを入れてやれば良い。
その部分は単純な足し算と掛け算なので、FIRフィルタが実行出来るDSPICにしたらたいした処理じゃ無い。 Cでもできるのか。
以前はアセンブラで書いてたけど、
Cで書き始めてからはCでしか書く気がしない。
今なんて、MCCじゃないと面倒で、部品箱はMCC未対応の石が減らない。
趣味としては今の環境が楽しいな。 >>217
クロック上げるって、オーバークロックするって事？
プログラムがタコな上に定格で動かないなんてゴミだな
そんなのは出来るとは言わないw C言語だけでWAV再生とかやってる人居るね、それ考えたら何でもアリじゃね？ 倍音のサイン波も出してレスリースピーカーにつないでほしい ID:/cry5Qxv
ID:/cry5Qxv
ID:/cry5Qxv 俺レベルになると 00 FF FE とか直接打ち込んでるから 俺レベルになると音響カプラから直接音声で入力できる そういや、10音ポリフォニックピアノがPSoCのサンプルでもあったなぁ。
結構ピアノっぽい良い音していた。あのCPUって4MIPS程度なんだよね。 俺レベルになるとディスクを見るだけでコンテンツが頭の中に浮かんで来るから
CDは簡単だったけど、H.264を脳内デコード出来るようになるまで半年掛かった FM音源の難しい所ってチップをコントロールする事よりも音色を作る事だと思う。
あとチップ自体の動作が遅い。 >>222
WAV再生なんてなんも考えることなく垂れ流すだけだろ。Cでもとりあえず動かすなら動くんじゃね。
CがダメなのはDSPをまともにサポート出来ないって事。ライブラリに計算させる位が関の山。
なので、DSP部分を使いこなすならアセンブラ一択しか無い。DSPを使いこなせないなら
わざわざDSPIC使う必要が無い。クロックの高いPICとしてしか使いこなす能力が無いって事だからな。
Cしか出来ない奴はそんな当たり前の事が理解できないんだよ。
今までの悔しそうな書き込みがそれを物語ってるwww >>230
そう、なんも考えること無く垂れ流すだけで微妙な音色や音声も再生できるからね アセンブラで、DSPにあたえる基データのスカラベクトル行列演算って何ステップくらいで書けるの？
16ビットの4×4くらいでいいから教えてよ 良しわかった！
単音PIC音源として
MIDIインターフェースで制御PICからコントロール
出力をミキサーで混ぜちゃえｗｗｗ ＞CがダメなのはDSPをまともにサポート出来ないって事。
別にできないってことはないだろうけどね。
スパコンでもFORTRAN使ってたりだし。 >>236
出来ないよ。DSPの真価はリアルタイムに計算出来るって事だから
DSPの機構を使わずにCで書いてたら全然間に合わない。
バッチ処理ならFORTRANでもCでも良いけど、リアルタイムに音声合成みたいな
事をやるようには出来てない。せいぜい音声再生がいいとこ。 >>237
お前がDSPやらFPUやらGPUを使ったことがないことはわかった。
一生アセンブラでソフトウェア書いてていいよ。 オブジェクト志向プログラミング
には対応できないとダメだろうなあ。 PICの電子工作の話にFPUだのGPUだの持ち出さないと会話についていけないって
よっぽど足らないんだろうな。そんな奴がDSPだのFPUだのGPUだの言っても説得力が全くないw
そもそもDSPICを使った事のある奴の言葉には全然見えないw >>237
コンパイラというものについて、そこまで無知だとは
思わなかったなあ。
そりゃ、アセンブラにしがみつきたくなるよね〜。 ID:/cry5Qxv ＝ ID:Yp4y7Z5X コテも付けず℃素人とか貧弱な語彙でしか自己主張できないチキンw
かわいそうに普段誰にも相手にされないんだろうなぁ >>244
コンパイラ以前に、DSPICを使ったこと無いだろw
せいぜいメーカーのライブラリを使って想定されたサンプルプログラムを動かして喜んでるレベル。 >>238
なぜに人差し指に指輪なんだ
結婚後に太ったのか 自分で納得してアセンブラ選択してんならそれ自身もって使えよ、人に噛み付いてんじゃねえよ。 だからはやくDSPICの乗算器使ってFFTでフィルタ作る場合の窓関数通す展開式のアセンブラのソースコード出せって。
URLでいいから。 いっとくが、乗算器使うだけのコードじゃなくて、その前段階と後工程の処理コードだからな。
おれはCとアセンブラ使い分けてるが、アセンブラだけでフルスクラッチで書いたコードってのが見たいんだよ。
速いだろうとは思うが、人間業じゃないと思うんで、はやく頼むわ >>255
英語でSO、中国語で所以、サントリーの飲み物でもある
質問にお答えしました。 >237
自作のサンプルソースを出すわけでも無く、>232の質問にさえ答えられない
技術的な話は全く無く、ただの空論だけ。虚しくならない？ Lチカくらいで終わった人達と、はるか上を目指した人達の同族嫌悪では？ どうせ 仕事だから出せない とか言うに決まってる。
弱い犬ほど良く吠えるな。 所詮口先だけ、アホには何も出来やしないよ。
できると言うならソースコード出せばいいだけだ・・ >>260
俺はLチカ位をアセンブラで書いてるよ・・・。 もうすぐ8ビット品がAVRに一本化されたら
「PICで絵色千佳＾＾」とか言えなくなっちゃうぞ
16bitPICにふさわしいアプリケーションを追求すべき ID:bMywPqgs
なんだ、買収されたショックからまだ立ち直れないのかｗ >>266
でも慣れたPICのIOや安定したハードウェア互換に、AVRのコア載せて、GCCでPicKitとデバッガ使えたら、
ちょっとそそられたりする。 >>269
ワザワザPICのIOなんか使わなくても
マイクロチップ社の高度なアナログIP群とAVRコアを組み合わせれば
競合の8bitマイコンはすべて薙ぎ倒せる気がする AVRコアに魅力を感じないんだが
市場でも評判が良くなかったから買収されるハメになったんだろうし >>272
実は8bit品のシェアはPICを上回ってたらしいな
Arduino絡みじゃない？ すみません、以前同じ質問をさせて頂きましたがその時は回答が無かったので
改めて質問させてください
MALに入ってるBootloader用のUtilなんですが、Mac用を実際に使ってる方は
いませんか？Windows用のver2.9jはWin7(64bit)で問題なく使用出来ていますが
Mac用がOSX（EL Capitan等）でちゃんと動くのか、実際使ってる方がいるのか
知りたいです
本当はコマンドラインで動くmphidflashに期待したかったんですが、これは
MacどころかWindowsですらまともに動かなくて・・・ windows買っちまえばいいのに。なんで出来ない奴って変なとこに拘るんだろう >>273
安売りしてたからシェアが高かったとか
いずれにせよオワコン >>238
え？ジョークで書いたらマジだったの？
てかその基板デザインユニークで(・∀・)ｲｲ!!
昔持ってたMonoPoly(KORG)を思い出す発想 >>259
PIC使いはアマチュアが多いからじゃないか？
私のオフ会での経験によると、
他人が作ったプログラムにバグを発見したとき、
「バグがあります、Aという症状で、Bが原因で、対策はCです」
と報告すると、プロからは感謝されるが、アマチュアはまるで人格を否定されたかのように怒る。
過去に二度ほどイヤな思いをしたので、
二度あることは三度ある、今はアマチュアの作ったソフトは、
すごいですねぇ、素晴らしいですねぇ、と褒めまくることにしている。
もちろんバグを見つけても黙っている。
PICファンがAVRを褒め讃える、Cファンがアセンブラを褒め讃える、
そうすればレスの下らない言い争いは無くなってメデタシ、メデタシ。 >>278
内容に関係無い話で悪いけど、この基板良いよね。
評価用に買った2枚が無くなったので、追加で何枚か買ってきた。
＋ 電源ラインの配線をしなくて済む。
＋ パーツのすぐ近くで電源と接続できる。
− ハンダブリッジに気を遣う。 >>279
俺の代わりにバグ見つけてくれるとありがたいと思うけどなあ
なんでﾌｧﾋﾞｮるのか理解出来ん >>281
バグがあるかもと思ってる人と、バグなんてないと思ってる人の違いじゃね？
プロは機能がＦＩＸできてからが仕事の始まり、アマチュアは機能がＦＩＸできたら終了
新卒やアマチュアに状態遷移図書けというと、異常ルートのまったくないヤツを平気で書いてくる >>280
リード部品だけならいい基板だよね
チップ部品が混ざってくるとヒヤヒヤする ちょっとスンマセン
MPLAB X IDEのエディターの事で聞きたいのですけど
http://free.5pb.org/i/s/yccp160606212210.jpg
↑この赤い線は何ですか？
できれば コメントアウトの列を揃えるのに使いたいので
赤線を左右に移動させたいです。
たぶんToolsのOptionsのどこかで設定できそうですが わかりません >>284
丁度良い？
ワンサイズ上が丁度良い
秋月のリード売りのやつかな あ゛、プルアップとかノイズ取りコンデンサとして電源やGNDと接続する時ね。
2.54ピッチの時は大きくないと繋がらない。 >>285
たぶん、印刷時の用紙の大きさ(というか印刷領域)のことじゃないかな。
用紙サイズを変えてみて下さい。 >>289
あのさぁ・・・・
知らないなら一々口挟まずに黙ってれば？馬鹿なの？
>>285
その赤い線は単に「ここまでが80文字なので見やすいソースコードになるように
1行の長さを大体このくらいに抑えましょうね」って言う目安の印だよ >>285
うっとうしいので俺はtext limit lineの色を変えて見えなくしてる。 >>290
ただ>>285へのレスだけを淡々と書く。
というわけにはいかないんだな、人格的に未熟だから。 >>289
レスどもです
>>290
ああ、そういう事ですか
サンクスです
>>291
なるほどtext limit linetっていうのですか
サンクスです いろいろやってたら Tools → Options → Editor → Formattingで
Languageの項目をいろいろ変えてみてたらRight Marginを変更出来る奴があったので
そこで変えることが出来ました
http://free.5pb.org/i/s/yccp160607213917.jpg >>297
すばらしい
コイツはグレイトですよ。実にすばらしい。ブラボー ファミコン世代か
いい年して選曲がキモイ
アニヲタ、フィギアヲタと同類のキモさ >>296
了解しました。
用紙の、右側の余白(マージン）の設定ですね。
たぶん用紙サイズを変えると、線の位置も変化するとおもいます。 >>297
うわー、凄い
結構いい音色ですね
軽く感動
そして基板は例の電源が飛ばせる基板 ハンダ不良でショートして電源がバチっと飛びやすい基板なんじゃね？ｗ
これかな、高いけどＤＩＰで小さく作るには良さそうだね
http://akizukidenshi.com/catalog/g/gP-07214/ >>305
無線給電。その発想はなかった
>>306
それそれハンダブリッジで手軽に電源が取れるらしい
試しに買ってみたけど使わないまま放置されてる
別スレでも製作写真あったけど皆配置が綺麗で羨ましい プチプチ音はMIDIのメッセージ受信が波形生成に干渉してるんだと思い、割り込みをいじってみたが、音のオンオフに連動して発生してるようだ。
出力にLPF付けたがダメだった。
DACのVref、DAC出力バッファ回り、ミキサー、電源波形、ミキサー出力のDCオフセットの影響あたりを見てみようと思う。
この基板、部品配置優先でピンを決めたから、ICSP不可能。特にVppピン周りの回路
は気を使わないといけないな。 >>305
MIDIはbluetoothシリアルで受けてるから、PCとの接続って点では無線。
電源が無線というのはパワーグリッド基板のことを言ってるんでしょ。チップパスコンは使いづらいけど、配線は楽だよ。 DCオフセットで思いついた。
プチプチ音の原因は、無信号時のDAC入力値が0だからかも。127とすべきか。 プチプチがぜんぜん聞き取れんのだけど・・・・
> 127とすべきか。
プラス電圧域だけで出力してるなら、無音は中点電圧にしないとね。 >>311
>プチプチがぜんぜん聞き取れんのだけど・・・・
そうとうお歳をお召しな様でW
>プラス電圧域だけで出力してるなら、無音は中点電圧にしないとね。
そうとは限らない。 中点にすればいいとは限らないとは？
結果的に無信号時電圧を中点にしたらプチプチは消えた。
http://i.imgur.com/g5yyL0H.jpg 「そうとは限らない」とぼかすのは
・よく分からないか、
・自信がないか、
・いつでも逃げられるようにするため
なんだってさ。 >>313
音源次第だから限らないと書いた。バッテリー駆動の物で無音を０Vに設定するものもある。
その場合はプチプチ音を消す方法は２つある。
>>313は中点にするべき音源、回路構成なのに中点にしてなかったって事だろ。
>>314
悔しそうだなｗｗｗ
頭の悪い奴ってだいたいそうだけどなｗ プチプチが聞き取れないとは書いてあるけど、
プチプチを含めて「音色」だと思っている場合もある。
「限らない」なら、どういう場合かその時に書けばいいのに。
自分の落ち度を無視して相手の落ち度だけ指摘するのもどうかと。 https://youtu.be/dslnwhfvw00
プチプチ消えたらこんな。
無音時0Vでプチプチを消す方法が気になるな。
バッテリ駆動ってことは、バッテリ節約するためでしょ？
DACの基準電圧に負電源？アンプに工夫？ >>319
>プチプチを含めて「音色」だと思っている場合もある。
お前、自分の言ってることが分かってるかw
韓国人じゃあるまいし、見苦しいよwww >>319
>「限らない」なら、どういう場合かその時に書けばいいのに。
自分で書けよ。なんで俺が書かなきゃいかんのだ？
図々しいにも程が有る
教えてほしいなら 「教えてくださいご主人様！」と叫んで3回まわってワンと吠えろw >>323
「教えてくださいご主人様！」
くるくるくる
「ワン!」 DAC後段のミキサーの入力に、無音時のみDCオフセットを加算すれば、無音時のDAC出力は0でもプチプチしないんじゃないか。
メリットあるのかな。 >>320
8音シンセサイザーになった！＞前の４音でしたよね？
エンベローブが良い感じにふわっふわで楽しい
手作りでこれが出来るって羨ましい >>325
> 無音時のみDCオフセットを加算すれば
その加算したところで音が出るよ。 32MX250f128B で
i2SのPCMショート・フレーム・モードのマスターモードは再現できるんだけど
i2SのPCMショート・フレーム・モードのスレーブモードが再現できない・・・
SPIRBF: SPI 受信バッファフル ステータスビットが立たないんだけどなんでなん？
i2SのPCMショート・フレーム・モードのスレーブモードってバグとかあるん？
なんか知ってる人いませんか？ ちなみに普通のSPIスレーブモードはちゃんと駆動するし
SPIRBF: SPI 受信バッファフル ステータスビットもちゃんと立つ >>322
言葉通りの意味なんだがな。
>>323
こっちも言葉通り。 >>328
エラッタには載っていないので、新しいバグか？？？ >>323
自分で書けよ。なんで俺が書かなきゃいかんのだ？
図々しいにも程が有る
教えたいなら 「教えさせてくださいご主人様！」と叫んで3回まわってワンと吠えろw 原因判明 SS1の設定を入力にかえてなかっただけだったｗ
出力時は RPB15R = 3; // SS1
で入力時は SS1R = 3; //SS1
って書かないといけないんやねｗ
てっきりSS1としてポート使うんなら同じ設定でいいっておもって
間違ってたｗ >>324
よろしい。
バッテリ駆動の量産向けICは大抵、無音時は0Vにしてある。メッセージカードとかに使われる簡易的な物がそう。
数的にはON・OFFの圧電サウンダの次に多いと思われる。
スピーカーを直接駆動するものもあるし、トランジスタ１石のエミッタ接地アンプの場合もあるが
何れにせよ発音終了後に出力電圧を０Vにする事でアンプの電源も落とせる。
このタイプはバイアスの掛け方に２種類あって、発音スタート時にハード的にランプ波形を
生成しバイアスを掛ける物と、音データ（大抵はPCMか同等の物）自体に
スタート、終了後のランプ波形を持たせる物がある。後者はメーカーのツール自体に
ランプ波形を追加する機能がある。後者は音声メモリを食うので時間が短くなるデメリットがある。
以前、昔、TIの小ピンDSPを使ってパーコールとかやった時は、ソフトでランプ波形を出力してた。
PIC+抵抗+トランジスタ+スピーカー+電池で出来るので、暇人はやってみるといい。 >>337
おつ。
俺、>>324なんだけど、正直言って、もったいぶらずに最初からそれぐらい書けば良いのではないかと思う。
教育のために自分で調べろっていうのは、自分が所属する組織の中でなら良いのだけど、
あるカテゴリに秀でた人だって、別のカテゴリでは素人同然ってことは、この世界ならよくあることだし、
皆がみなすべてのカテゴリに秀でた人になる必要もない。
自分が持っている知識なり長所なりを提供しあっていければ、匿名掲示板に集う意味も大きくなる。
くるくるくる、わんわんわん！ 俺はしばらくの間のクイズだと思えて楽しめたよ。
答え合わせが1ヶ月後とかだったらモヤモヤが溜まるけど。 ＞自分が持っている知識なり長所なりを提供しあっていければ
提供しあうんじゃなくて、一方的に頂きたいってだけだべ？ >>341
性悪説に基づくなら来なくていいと思うのです。
本件については俺は傍観者だったけれど、知ってることは提供しているよ。
あと、あらゆるカテゴリで素人の人が結果的に一方的にいただく立場になったとしてもOKだと思うのだけど。
こういうのは「現在の俺の収支」だけで考えてると無理があるんじゃないかな。
もし、現在の俺の収支だけで考えるなら、現在において求めない人だと教えてもらうことがない(情報の収入がない)から、
その人は何を提供しても収支は合わないことになるね。
でも駆け出しのころは多くの人がいろいろな人に指南してもらう立場だったよね。
それ以前に、音源のムービーの人は、もうそれだけで凄い刺激を公共のものにしてくれているわけだし、そういうのも含めて
提供しあっているって考えて良いのではないかな。 技術は「持つ者」と「持たざる者」の２種類しか居ない訳で
会社じゃ有るまいし、「技術を持たない者」に対して
懇切丁寧に教えてやる義務なんてない
あくまで技術を持つ人が好意で公開してくれているに過ぎない 施しを受けるのが常識だと考えるお客様体質な奴がいるから空気悪くなるんだよ
2chはお客様サービスセンターじゃねーってのに
作品公開は自己満オナニーの垂れ流しなだけだし
それ自体は悪い事じゃないけど、
それをしてくれてるからってことで手助けをする義務は無いよね？
手助けもまた自己満オナニーだからやりたい奴がやれば良いだけだろ >>339
>もったいぶらずに最初からそれぐらい書けば良いのではないかと思う。
もったいぶってる訳じゃないし断る。
そもそも考え方が間違ってるよ。自分の組織とやらなら自分にメリットがある事もあるだろうが
2chで直接的な回答を書くのは世のためにならない。
素人だから無知なのは当然として、努力しない素人を導こうなんて大層な思想なんて持ち合わせて無いから
必要なら学校の先生にでも聞いてくれ。学校なら努力しない奴でも教えてくれる。
だいたい俺が書くのは「知ったかすんなよ℃素人」ってのが定番だが
℃素人が知ったかしてする書き込みは害悪なので牽制してる。
℃素人呼ばわりされた奴は自分じゃ知ってるつもりで書いてるから反発して
酔態晒すのを見るのは楽しいが、所詮、しったか。素人にとっては害でしかない。 >>342
>でも駆け出しのころは多くの人がいろいろな人に指南してもらう立場だったよね。
自分がそうだからと言って、他人もそうだとは限らない。
そもそも、俺の年代だと、データシートを読んで自分でなんとかするのは当たり前だったしな。
殆ど独学だよ。 >>346
はったりかまして引っ込みがつかなくなって2日間考えてやっとこじつけた
のが音楽の発音には役に立たないランプ波形か。
℃玄人が具体的なことを書くのは得意分野だけにしておけよ。 >>337,>>343
「知ってるけど教えない」って態度は
「本当に知ってるけど教えない」「知らないけど知ってるふりをする」「知っているけど理解できていない」どれとも捉えられる。
掲示板の場合後者2つだと思われる可能性が高い事は忘れない方が良いかもな。
書く気が無いのなら初めから口出すなよ、と思われる可能性もかなり高い。 どっちにせよ
情報を出さない奴はスルーでいいんじゃない？
相手するほうがどうかしてると思うぞ >>355
質問スレだと自称プロな人の長文トークコーナーになっちゃうのよ >>354
興味が無い、既に知ってる人なら、「あっそ、ふーん」だけど、
書き込み主の素振りに疑問を抱く奴も居るって事だ。 疑問を抱くのは自由だけどファビョり感が半端無いな。 あ、客観的に見てそう思うだけだから勘違いするなよ。 ２チャンネルなんて昔から清濁あいまみれる場で、何が本当なのか
何が嘘なのかなんて分からないですよ。
書かれた内容なんてまともに受けないで、本当にそうなのかと一回自分で
ちゃんと調べたり、考えて情報を咀嚼しないと。
大食い選手権みたいにロクに噛みもしないで丸呑みばかりしていると
消化不良になったりするし、脳の発達にも良くないのと同じように
身につかないし、ご自身の技量も上がらないでしょうね。 知ったかすんなよ℃素人ってコメは考え直す切っ掛けにはなる。 俺が「中点電圧にしなくちゃだめだよね」って書いたせいでこんなに荒れてしまいました。
申し訳ござらん。 PIC使いは、相も変わらず罵倒しあっててアホかと馬鹿かと
平常運転 >>366
それより、コメ って書いたのは君かい? 米米倶楽部ってやたらメンバー多かったよな
カールスモーキーがおそらく食えない奴らに給料やるためにメンバーにしてやったんだろうな
男気のある奴だぜ 豆知識
℃素人連呼するヤツに「良くわかってないから罵倒しかできないんだな」
と言うと何の脈略もなく「悔しいんだな」と返ってきます。
実は悔しがってるのは℃人本人で、自分の感情を相手に映し出しているのです。
これを心理学用語で「投影」と言います。
本当にわかってなくて罵倒しかできないのですから、あまり追い詰めず
可愛そうな者を見る目で生暖かく無視してあげましょう。 俺は人のためじゃなく自分の利益のために回答してる。
人にものを教えると分かりやすく説明する文章力がつくし、自分の理解が深まる。
ついでに解決して礼言われると気持ちいい。 教えてくださいご主人様！って言われると気持ちが良いよな。 >>374
豆知識とか言って無理やり食いつくのが
どうみても悔しそうwww
よっぽど悔しい思いをしてきて積年の恨みが有るんだろうと思うよ。哀れ杉www arduinoでこの世界に入ってきたものです
arduinoはある程度触れたのですが、歴史の長い分野を開拓したいと思い、PICに手をつけ始めようと思います
早速pickit3あたり購入し手をつけてますが、arduinoしか知らない身として気をつけることはなんでしょうか？
オススメのPICとかあればご教授ください >>369
それは存じ上げませぬ。
ところで、無音時は0Vというアルゴリズムは開陳されたのでしょうか。
怒涛のレスの波を掻き分ける気力はござらぬ故。 とりあえず16F84A, 16F887, 16F877A, MX250F128Bあたりを購入していろいろいじってみる予定
オススメサイトとかありますか？ >>380
MCC対応デバイスだと楽だよ。
PIC18F26K22とか。 >>380
今更84なんて使うより1823とか1827あたりにしておけば？ >>380
古い石は作例は多いけどあまり参考にならないかも。
16F84は内蔵オシレータもないから不便だし、今から使うなら16F1827とか16F1938あたり、
または8pinの16F1822とかが分かりやすいのでオススメ。
ArduinoからということはC言語を使うのだと思うけど、
あっちのようにすぐ使えるようなデバイスモジュールやそのライブラリは揃ってないから、
自分でデバイスを繋いでドライバー部分も書くことが多くなるので、覚悟してくだされ。 >>386
あれはPIC内蔵モジュールの設定用ですよね
外付けしたデバイスにも対応してくれるようになったの？ >>387
内蔵ADCとか
16F84のメリットは、最小限の機能の日本語データシートの存在では。一度日本語のデータシートを頭に入れれば、他の機種の英文データシートも読める。 >>387
アルデーノは、AVRも含めた基板回路全体が規格化されているので、
周辺ICのライブラリも たくさんあるでしょう。
PICの場合は、周辺ICまでのライブラリはないから不便だよね。
またcinfigも面倒だよね(1回やれば慣れるけどね)
でも
マイコンの周辺ICには自分の思い通りのICが選べて、
自分の思い通りの基板サイズにできて、
自分の思い通りの回路設計ができて、
自分の思い通りのライブラリが作れて、
コードも簡潔に無駄なく書ける、
それだけだよね。 arduinoって、外付けデバイスのドライバも書かなくていいのか！
PICで加速度センサからの読込で苦戦したけど、
そういうのないってことなのか。いいな。
俺の無知な発言は忘れてくれ。 べつに作らなくてもいいからH8のデータブック端から端まで読んでみるのはどうだろう >>378
俺もAruduinoからPICに入ったけど
PIC16F1827でMPLAB X ,xc8使ったよ
本買ったけどxc8の使ったのが無くてGoogle先生に大変お世話になったよ
一通りPICで遊んだ後は
PSoC1で遊んでる
IDEの出来はMPLABよりも使いやすい どこもマイコンを使うときでも、出来るだけ
基本機能のみを搭載している簡単なものから入ったほうが
実際に使わない機能の初期設定で困ることが少ないと思うよ
単純なものから初めて、徐々に高機能のものを使うほうが
わかりやすいと思う。
F1タイプはお勧めしません〜〜〜〜 >>394
どうせ最初は人様のコードを拝借するんだからF1で問題無い。
そこを基点にいろいろ変更する過程でコンフィギュレーションの魔境に踏み込めばいい。
ちなみに84Aは300円、1827は明らかに高機能ながら半額の150円。 マイクロチップ社のYouTubeに出演してるメリケン娘が気になっている
英語があれだから何言ってるかわからんけど
名前知ってる？
いつかあの娘で抜いてみようと思うんだ 最初にはPIC10F200がお勧め。
・クロック源の選択肢が内蔵のみなので何を間違ってもとりあえずは動く。
・アナログ機能無しなので出力をするまでの罠が少ない。
・安いので壊したか心配になった時のためにたくさん買っておける。
なおLチカとスイッチ入力くらい試したらまともな石に移る前提で。 PICはArduinoにはなれなかったから
ガキみたいなジジイがいろんなとこで粘着してんだよな いろいろ参考になるわ
ところで、ど の変換を℃にしてる人は
やっぱそっち方面のヲタなのかな？ >>393
PSoCの場合にはI/O操作は基本的にAPI呼ぶだけだもんね。
レジスタの直たたきなんて殆どやることないし。
タイマだのシリアルポートだのの構成も自由に組替えられるのもありがたや。 PSoCはつぶしが利かないからPICとFPGAの方が色々便利。
量産用途に嵌れば便利だけど、性能追求する感じじゃ無いし
スピード遅いしプログラミングとしては詰まらないけどな。 入門にはPIC10F200がおすすすめ・・・
に大賛成、その後PIC10F222でどこまで出来るか試してみるのも
面白いと思うよ。
巷にあるちょっとしたものなら222で作成可能なものが沢山あります
（PICの機能はよく考えられてると思う・・価格対機能の点で）
自分も50種類くらい10F222で組んでますが非常にバランスがよく
必要最低限の機能だけでも結構出来ます。
（NI-H充電器、赤外線リモコン解析機、6LEDフラッシャー（4階調制御）
赤外線エリアセンサー、ソーラー誘導灯、太陽追尾装置など） I/Oとメモリが足りない場合もあるけどね……。
一番は足が足りない場合が……。
16セグメント用に英語と数字、全部記述したらどれくらいのROM必要になるんだろ…。
入力側はUARTかI2Cでもいいけど、出力が足りるか不安だわ……こういう計算ってどうするの？コンパイラにもよるから組んでみるしかない？ 入門に6ピンを薦めるとは℃素人猛々しいｗ
少なくとも14ピンで、書き込み用のピンは書き込み専用に使い
実機に手を触れずに何度も書き換え出来るほうが、短時間で書き換え出来るし
無駄に時間を浪費しないから効率的。 I/Oが足りなければ16F57と言う選択もある
ROMも2KWあるしね〜〜
8X8ドットマトリックスで漢字表示なんかも出来ます。 >>409
初心者はPIN数よりどれだけサンプルプログラムがあるかの方が
助かります。
どのPICを使えばより沢山の情報が得られるのでしょうか？？
データシート見てプログラムなんて組めませんし
PICの書籍も古いものが多く参考になるものも少ない >>411
データシートを読む気が無いなら、
Arduinoでも使っていた方が幸せになれる。 >>411
12F1822でググるとかなりの数の日本語の作例がヒットする。
8pinの中では割と容量多いけど初期化設定等は少ないのでオススメだと思う。
10Fシリーズだと容量もpin数も機能も少なすぎるので…
慣れたら次は18pinとか28pinので。
さらに容量や速度が不満になってきたら24Fシリーズでどうですか。
(個人の感想です) picってネットに無線で繋いだりできるの？
esp8266ならちゃらっとできるんだけど
そもそもpicにそんなことできるわけないかw
Arduinoになれなかったんだしな >>414
PICでもwifiモジュールがあればできる
Arduinoも同じだろ
そもそもESPシリーズはArduinoIDEが使えるというだけの話でArduinoとハード的には無関係だろ
Arduino信者ってキモいな 日本人は仏壇や神棚があり初詣にも行くくせに無宗教だと思い込み、すぐ信者という言葉を使って他を排斥する基地外民族 >>418
韓国人を差別するな！
どう考えても韓国人は被害者だろう
お前ら日本人は反省しろ
そして韓国人に感謝しなさい
日本が存在するのも韓国のおかげなのは歴史が証明しているんだから >>410
16F57は好きだけど初心者には勧めづらいなあ。
・内蔵クロックが無いのでクロック源を外付けする必要あり。
・2kWあるが、ベースラインなので定数テーブルに使えるのはその半分。
・プルアップ機能がないのでスイッチ入力のためには外付け抵抗が必要。 >>414
コピペしてネットに繋げるのが精一杯な感じの奴の書き込みだなｗ >>416
そんな調子だから、無知無教養って言われるんだよ。 作るモノも決まってないのに使うICだけ決まっている本末転倒 >>423
面白そうなデバイスを見つけたら、とりあえず調べたり使ってみる人って強いよ。
作るモノが決まったときの豊かな抽斗になるし、抽斗が多ければ作るものの発想が広がるもの。 >>424
そういう発想は無いみたいよ。
なんでもググって、それでも分からなければ２ちゃんに頼るという
情けない方々だから。 Arduinoは既存のシールドを接続して他人が作成したスケッチを少しイジるだけの
簡単なお子ちゃま仕様のオモチャだからつまらんのよ MCCが機能拡張して、arduino用の外付デバイスを制御できるようになればいいのに、とmicrochip信者が発言してみる。 >>427
前者はともかく後者は自分から始めてみては？
コンパイラの主流も大体決まりつつあるし、その書式でジャンジャン公開していけばいいと思う。 >>426
激しく同意。
シールド
スケッチ もう、この言葉だけで、イヤになっちゃう。
スケッチって言わなくてプログラムとかソースでいいじゃん。 Arduinoって開発環境が特に優れているって訳じゃないよな
シールドを付け替えて色々な機能を簡単に追加出来るのが受けているんだよな
マイコンチップとして自分で半田付けして機器を作るような人にはあまり関係ないよな >>432
このモジュール使いたいけど俺のスキルじゃ無理、ってのが結構あって、arduinoはドライバが転がってて羨ましいと思うことはあるよ。 作られたモノ自体はArduinoでも、そうでなくても要は作られたものに何らかの価値があれば良いんだし、
特にプロトタイピングって位置づけなら、何で作られているかは二の次だと思う。
Arduinoや出来合いのシールドのおかげなのか
「マイコンどころか半田付けも苦手、でもアイデアはあるよ」
みたいな人の作品がいろいろ出てきているのは良いことだと思うよ。
こういう流れはみんな恩恵を受けてきている。
技術的ハードルがアイデアの実現の壁になっているなら、そんな壁なんかどんどんなくなれば良い。 ここでArduinoの話ばかりするのはどうなんだろうね >>435
自分たちが獲得した技術や知識の習得をすっ飛ばしてモノを作るなんて、って感じなのかなあ。
そんなのつまらない考え方だよな。
Arduinoの悪口なんて言わなくてもいいのにね。PICで負けないぐらいに愉快なものを作れば良いんだし。
でもPICにもArduinoみたいな環境が普及すればいいのにな、とも思う。
好きでない人は使わなければすむだけだし。 >>436
PICが残念なのは書き込みに高電圧を必要とするところ
このせいで初心者が手を出しにくい
AVRは（というかarduinoは）この欠点がなかったからこんだけ普及した AVRとArduinoの区別もつかないのが信者。
AVRとPICの区別はつく？
買収された方と買収した方だよｗ >>436
アルディーノみたいな標準品がないからなぁ……。
まあそれでも世界的に見れば廃品種作らなくていい位売れてるから問題ないんだけど
個人的には早く5桁シリーズの普及が欲しい マイコンチップであるPICと応用製品であるArduinoを比べようとする時点でクソキモい。 >>436
AruduinoもPICもAVRもPSoCも使うけど
まったく同意 ID:PJjXV6+Vが何と戦っているのか分からない。
俺の場合は、ArduinoもPICもESP8266も使い、
Arduinoで出来てPICで出来ないという経験が無いからだろう。
ESP8266はちょっと毛色が違うけどね。 PICはArduinoにはなれなかったから
ガキみたいなジジイがいろんなとこで粘着してんだよな >436
標準環境なんか作ったらそこで製品の改良が終わっちゃわないか？
AVRなんかarduinoのせいとはいわんが、MEGAシリーズはろくに機能追加されず、挙句
マイコン自体にはたいして依存してなかったからarduinoに捨てられて終了みたいなもんだし。
逆にPICはもう終わりだろって思ってた8bitPICがエンハンスドミッドレンジを出して、さらに多種の
周辺機能を追加した新製品が続々と出ている、USB OPA CWG CLC NCO PPS SMT ZCD CRC 等
I/Oピン毎の入力レベル、OD出力、スルーレート制限 なんてのも追加されてのもある。
これら周辺機能有無とピン数別で多数展開してる品のそれぞれの特性を活かせる、共通の
ハード(マイコン＋基板）が作れない。 >>437
LVPがあるけどね
PIN一個損するから使ったこと無いけど >>437
高電圧要らないのも有る。PIC24系とか。 PICなんかよりZ80とか6809の方がいいだろ？ スレチ承知で書き込むけどさ
あれだけArduino、主にUNOが普及しちゃうと、
その次のモデルってのはすごく難しいよね、戦略的にも性能的にも。
そうすっと今のUNOの微妙なバージョンアップ品みたいなのが延々と続いて、
ある日そのアーキテクチャが物凄く時代遅れになっている、となる可能性は極めて高い。
モノ、というものの構成要素に、依存性の高い要素を組み込むことは、
安定化には繋がるが、将来的に閉じる事が同時に約束されちゃう。
そこらへんをエンドユーザはどう感じてどうやっていくのか、ってのはすごく大事なことだと俺は思う >>449
UNOが今でも強い存在感を持ってるのは、そこそこの実用性を持ってるからだと思う。
「それで十分」みたいなものなんだけど、この感覚はある意味危険で「それで十分」だと
思ってるつもりが実はその環境でできることしか発想できなくなっている場合もある。
「家から出してもらえないとき、家の外に出たい猫はストレスを感じるが、
家の外に関心のない猫は、それで充足する」と、ペット屋のおっちゃんが言ってた。
定番環境でマイコンに触れてから、もっと深く学ぶなり技術の部分を他人にゆだねるなりするようになるのか
その定番環境でできることだけに面白さを感じるようになるのかは人それぞれだね。
そういえばPICも、ずいぶん長いあいだ PIC16F84 が定番だった。これをしゃぶりつくした人や
これ以上のものの必要性を感じないと言ってた人もたくさんいるのではない？ >>450
ひさしぶりにこのスレでいいこと聞いた気がする Arduino使ってた人も中途半端なことに気がつき
ラズパイに走ってる人がかなりいることも事実です 高性能なものが作りたい、
簡単に作りたい、
って気持ちと、
全てのビットの振る舞いを理解して制御する達成感はどっちもアリで、トレードオフな部分があると思う。 全部 斜め読みしつつ、デフォルトで良いところはほっとく、だな。 中華のコピーでいいから、ラズパイ０ほしいなぁ。
安くてちっこい部品として。 >>450
どうせ、他人が作った物を丸写しするだけ
だからメジャーどころでいいのさ。 >>456
さすがに中華でも５ドルはつらいんちゃう？
本家はコピーのスイスに身売りしちゃったし 本家は財団で、買収されたのは製造しているファーネルじゃなかったっけ。
ファーネルっていえば日本国内では部品通販のレオコムが代理店なんだけど、
あらためて調べてみたらEagle CADもファーネルの一部なんだね。 LEDマトリックスでも光らせてみては？
足と性能が足りるか分からんけど、aitendoのフルカラーマトリックスとか Arduinoが無ければ8ビットマイコンはPICが制圧してたな
先行組がMega8あたりでAVRに流れ、Arduinoで一気にひっくり返された感じだ >>463
制圧していたかもしれないのは、ホビー市場ですかね？
半導体産業のマーケットとしては小規模な話だと思いますが。 PIC16F57でも漢字表示くらいは十分出来るよ。 PICでHVPとLVPってあると思うけど、HVPを使う利点って何なの？
もはやLVPだけでいい気がするんだけど >>467
そのLVPって実際には誰も使ってないじゃん
それだけLVPの方がデメリット大きいって事だよ LVP敢えて使う必要がない。
つかMCLR/VPPは専用ピンだろ事実上。 よく知らんが
高電圧を掛けて書き換える信頼性の高いEEPROMか
低電圧で書き換えられるが信頼性の低いフラッシュメモリが使われている
とかの違いがある製品あるのかもしかして 高電圧はプログラミングモードに入るためだけじゃないのかな。
プログラミングに必要な電圧は内部でチャージポンプで作ってるんだと思うな。 今時、書き込みに高電圧が必要とか時代遅れすぎじゃね？
とか思ったんですが、皆さんどう思います？
>>468
安全性とは具体的になんですか？
電圧的な観点ではないと思うがどういうことですかね
>>469
>>473的な話ですか？
>>470
具体的にどういうデメリットがあるのか自分も知りたい ライタの自作が複雑になるから高電圧は嫌われてたんじゃないかな
最近ではPickit買われるようになったから関係ないとは思うけど 他社の書き込み機を見ると半額とはわないまでも3000円切ればいいなぁとは思うけど、その分マイコンが豊富でいいかとも思う。 個人的には高電圧でなければならない、とは思わないけれど、
あえて「安全性とは何か」という理由を探すなら、
「通常使用で何かの拍子に書き換わったりしない(という確率が高い)」
ってことではないですかね。
ICSPのための接続のまわりで高電圧対策が必要な場合もあります。
世間が「低電圧書き込みが常識」と思うようになれば(すでになってるか)
高電圧書き込みは次第に廃れていくように思います。 高電圧って言うほど高くないだろ。+10Vかそこらだろ LVPがあるのに、HVPにしてわざわざ別電源を用意するだけのメリットが本当にあるのか？実は誰も答えられない現実 >485
LVPだと*MCLRを無効にして入力ピンとして使えなくないか？ いまだにライターを自作したりして楽しんでいらっしゃる気丈なお年寄りには敬服します。
私は、始めてPICを使ったときからすでにPICkit3で書き込んでる苦労知らずの若造です。
追加投資100円のR8Cで作ったライターで書き込むときに、
LVP必須だったので面白がって１度だけやってみたことがあるだけです。
面倒なので、以後PICkit3以外は使わず、HVPもLVPも一切意識すらしたこと無いです。 MCLRをIOに割かなきゃならんような状態なら素直にパッケージか品種の変更考えるよ >>489
PICkit2くらいなら簡単に自作できるよ！！
（ただし書き込みに最低限必要な機能のみ）
現在もそれを使用しています
PICkit3は待たされることが多いのであまり使っていません >>485
高い電圧加わらないかぎり、書き込みモードに入ることはない。 LVPだと書き込み速度が遅かったりしなかったっけ？
エラー率も高かったような？ LVPだとプログラム書き込み時以外、
PGM端子は”L”にしておく必要があります
そのためI/Oが一本使用できなくなります 結局、LPVは何が嬉しいのでしょうか?
・高電圧回路を用意しなくても良い
・あとは、あとは、あとは・・・・ 高電圧回路の用意って何よ？
6.3vのコンデンサ使わない事か？w VPP端子に接続するほかの回路に高電圧が回り込まないようにするための回路のことじゃないですかね。
VPP=9Vのデバイスに、VPP=9V未対応のライターが使われても大丈夫なようにするための
電圧リミッタは、自分で使う限りは必要にはならないだろうし。 そろそろ前向きな話しよう
IDE Xpress使ったことある人いる？
いいかげんXC8評価版のアホさにへきへきしてるんだけど、サーバ上でPRO版のコンパイルできるのかな
クラウド上のプロジェクトがIDE X用としてDLできるらしいから、最適化されたバイナリだけ欲しい >>500
残念ですがFree版です＞Xpress >最適化されたバイナリだけ欲しい
とか、全然前向きじゃ無い雰囲気ｗ 最適化されたバイナリだけ欲しい
欲しい
バイナリだけ
バイナリだけ欲しい
最適化
最適化されたバイナリ >>500
XpressがCharge Freeなのは分かるとして
クラウド上で動いてるXC8のバージョンもEvalutionなの？ ？
バイナリを得るためにみんなプロジェクト書くんだろ
まさか書くだけ書いてコンパイルしないで放置プレーみたいなどMなのか
>>501 ←リンク間違い
XpressがCharge Freeなのは分かるとして
クラウド上で動いてるXC8のバージョンもEvalutionなの？ 無料で試せるのに自分で試さない馬鹿はなんなの？
頭おかしいの？ ttp://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB%20Xpress%20Press%20Presentation%20final%20-%20for%20web.pdf#page=8
に書いてあった
MPLAB XC PRO available via monthly subscription
月額料金を払えばPROが利用可能 この無能め 無能はお前だカス
さらに言えば質問しておきながら回答者を無能呼ばわりとか常識も礼儀もないガキ
さっさと消えろ どなたか助けて下さい。
12F1288で状態変化割り込みをしようと思っています。
入力はRA3に2Hz程度の矩形波、チャタリングはありません（オシロで常時確認）
ANSELA = 0b00000000;
TRISA = 0b00001010;
IOCANbits.IOCAN = 0b001000;
IOCAPbits.IOCAP = 0b000000;
INTCONbits.IOCIE = 1;
INTCONbits.PEIE = 1;
INTCONbits.GIE = 1;
の設定で、RA3に立ち下がりで割り込みがかかるようにしたつもりです。
割り込みルーチン無は以下のとおりです。
// RA3
if (IOCIF == 1)
{
IOCAF = 0;
PORTAbits.RA2 = 1;
__delay_ms(10);
PORTAbits.RA2 = 0;
}
IOCAFを0にすればIOCIFは自動的に0になると書いてあるので、そうしてます。
ところが、何故か入力の立ち下がりだけではなく立ち上がりでも呼ばれてきてしまいます。
一体何が足りないのでしょうか？ 510です・・
原因はチャタリングでした・・
http://i.imgur.com/ajwj10M.jpg
大変申し訳ないです。 510です。
・・・と思ったのですが、チャタリングをRCのローパスで強力にカットしても
やはり立ち上がりでも呼び出しが来てしまうようです。
何故でしょうか・・・。 510です。記述間違いでした。
IOCANbits.IOCAN = 0b001000;
IOCAPbits.IOCAP = 0b000000;
↓
IOCAN = 0b000000;
IOCAP = 0b001000;
度々どうも失礼しました。 510です。
やっぱり何をやっても立ち上がり・立ち下がり両方IOCIF割り込みが来てしまいます。。
うまくいかないので、もう少し落ち着いて考えてみたいと思います・・。 >>509
＞この無能め
はMicrochipXpressへの言葉で、このスレの住民の方々に宛てたものではございません >>515
2Hzなら、もしタイマが余ってるならポーリングで検出するのは？
それか、チャタリングをシュミットトリガで取ってみる。 >>511
チャタリングが原因ではなかったので消しました、すみません。。
>>518
どうしても状態割込が必要です。
7414で作った矩形波にローパスかけて、オシロで拡大しチャタリングないことを確認しました。
IOCAP・IOCANどちらか一方をたてても立ち上がりたち下がり両方割り込みが来ます。石を変えてもダメでした。
RA3は入力専用だったり、Vppで高電圧がかかったりするので、まだ忘れている設定があるのでしょうか、困った・・ ちなみにLVPもMCLREもoffです。
同時にタイマー1割り込みとusart割り込みとeeprom割り込みを使ってますが全てうまく行ってます。
（今回のバグ追求のために全て無効にしています）
一番容易と考えていた状態変化割り込みでつまづきましたわToT >>513
8ビット分書いてみてもダメかな？
左詰めで認識されてるとか。
割り込みが必要なら、とりあえずの対処としては、割込後の状態がHなら立ち上がりと判断してスルーするとか。
パルスじゃなく幅のある矩形波ならokでは？ >>519
ピンの状態が変化したときにかかる割り込みだから、仕様。
片側だけとりたいなら、INT使え。 >7414で作った矩形波にローパスかけて、オシロで拡大しチャタリングないことを確認しました。
爺にありがちな愚かさ。 >>521
ありがとうございます。
帰宅したら8bitでかいてみます。入力はもともと矩形波です。
最悪立ち上がり時はキャンセルで対応したいと思います。
>>522
IOCAPとIOCANの立場は・・
>>523
？ ？？ >>524
X IDE v3.30のsimulatorでは、片側しか割り込まないけどなあ mclr は？
リセットかかっても今の状況にはならん気がするが ra2のビット操作をportじゃなくてlatに出してみれば？ >>524
やり方が間違ってなければ最初に疑ったように波形に問題がある可能性が
高いね。
PICの空きピン(なければ別のPIC)から2Hzの信号を作ってRA3に入れてみる
・正常に割り込めば波形に問題あり
・両エッジで割り込めば設定に問題あり
これではっきりすると思う。 >>529
ありがとうございます、今からやってみます。
>>521
8ビット書きはやっぱりダメでした。 皆様の温かいご協力感謝しております。
PICのRA0で出力した矩形波をRB2にダイレクトに入力したところ、
正しく立ち下がりのみ来るようになりました！！
結局は7414で生成しローパスを入れた波形の立ち上がり時間（0.5ミリ秒）が原因のようです。
ローパスを通した波形をもう一度シュミットトリガーに通して整形して、入力したところ
やはり正しく立ち下がりのみ割り込みされました。
キリっと立ち上がり下がりしないとダメなんですね・・・意外でした。
繰り返し皆様には感謝しております。ありがとうございました。 最後に・・
PICが生成した矩形波にローパスを付けて、状態割込みRA2に入力したところ
やはり動きが不安定になりました。
状態割込み入力は立ち上がり立ち下がりの速さが要求される、で確定のようです。
もともとスイッチなどを想定している割にはちょっと不思議だと思います。 データシートも読まずに「不思議だと思います」って、馬鹿じゃねーの？
闇雲にコンデンサ入れまくるのは万年℃素人爺の常套手段。 コンデンサをおまじないと思ってる俺、スンマセンした！ 場合によってはコンデンサのおまじないの効果は
絶大な場合もあるよ。
信じるものは救われる・・・・・ア〜〜メン シュミットトリガ入れてみたら？って書いたの俺だけど
1822のRA2はST入力ってデータシートに書いてあった。
だからローパス付けてダメってのは不思議。
・MCCの吐いたコードでもダメ？
・IOCAPとIOCANの設定後の値はデバッグのWatchで見た？
・割込直後にいじるLATにより電源電圧が揺らいでない？
・割込じゃなきゃダメな理由は何だろう？ RA3はTTL入力だし、RA2シュミット入力ならノーマルTTLの7414のハイレベル
じゃ足りないでしょ
＞RA2 ST CMOS General purpose I/O
＞RA3 TTL ? General purpose input >>537
確かにシュミットなら、あんな風にはならないよね。
あのどうさは、非シュミットの動きだよね。
ふしぎだ。
どんな波形でもいいから、Vthを、一気に駆け抜けて行って欲しい。 俺もイった余韻を楽しむために脳内コンデンサを入れることに決めた！ >>537
すみません。書き間違いで、
状態変化割り込み入力ピンはRA3です。
こちらはシュミットではないようですので、
ゆっくりではダメということでは無いでしょうか（？） 入力をRA2に変えてやってみたところ、コンデンサでローパスした
ゆっくり変化する波形でも正しく立ち下がりだけ割り込みが来ることが確認できました。
よほど歪みのない矩形波でなければ、
RA3で状態変化割り込み入力をするのは難しいということのようです。
これで結論だと思います、色々お世話になりました。 >>543
違うって。
非シュミットピンだから、コンデンサ付けて鈍らせ過ぎると、2度感じるんだよ。
Vth近辺の電圧がダラーっとしてない？
コンデンサのおかげで、Vthを、サッと通過してないでしょ？ 質問に対して答えが貰えて、その答えをしっかり実験して、その結果と謝辞を書く。
当たり前の流れのようで掲示板ではかなり希少なケースだと思ったり。 Harmony1.07でUSB HIDデバイス作ってる人いる？
一見動いてるように見えるけどホストからreset pipeとかclear featureが延々投げられていて気味わるい。
一応デバイスはpic32mx270f256 XC8のstrlenってconst char*でプログラムメモリ上の文字列を正しくカウントできないのですが、仕様でしょうか？
デバッガで追うと\0の部分をすり抜けます。
プログラムメモリは8バイトじゃないから？ MCC18の場合はそれを使うようです。
しかしXC8ではstrlenでよいようなことを見かけます。
シミュレータデバッガでプログラムエリアをみると、終端文字が3400でした。
他のリテラル文字にも34がついてます。
xc8のstrlenにバグがあるような話は見かけないので
自分が何か勘違いしてるようなきがしないでもないです・・ 最近秋月で16F1455か16F1454を買った人がいたら教えて
リビジョンIDいくつだった？ >>547
プログラムメモリ8バイトってどう言う意味ですか? 1454はA5だったけど1455はA4だった記憶があるが・・・・ 14ピンで内臓クロックでUSBなんてすごい。
秋月の18F14K50のボードでMLAのサンプル使ってUSB経由でMIDI受信しようとしてるんだけど、MCC使えないし、そっちの石の方がいいのかな。 >>552
ありがとう
エラッタみる限りA2、A5、A6の3バージョンしかなさそうなんで1455はもしかすると
A2の可能性があるのかな？（A2はバグ持ち）
とりあえずADCは使わないんで明日にでも1454買ってくる
>>553
小さい物を作るには超絶便利だけど所詮はエンハンスドミッドレンジ。
割り込みが2レベル使えるとか細かいところで18F14K50のほうが使いやすいと思うよ
16F145xにはEEPROMが無い（もっとも代わりにHEFがあるけど）
あと超大事な事
16F145xにはUSB HID Bootloaderが無い（MALには入ってるんだけどまともに動いた
ためしが無い）一応フリーのDFU Bootloaderはあるんだけど。。。 >>551
文脈から言えば、 「プログラムメモリは8ビットじゃないから」の書き損じでしょうね。 秋月のPICは大量買付けのものが多いせいかリビジョン
古いものが結構存在してるね〜〜〜
10F222、12F629,615,683など買ったら2007〜8年製造のものだった お前が沢山買ってやらないからだろ。
頑張って買ってやれよ。
俺はdspicが殆どだからいいや。 すげえ、というか、お大事に。
そばで携帯使わないように気をつけるね。 生命維持装置のせいで死にそうとか意味無いじゃんwww 出力20Wのプルトニウム電池で駆動されるので飛行機乗れない 20Wもあればモーターが動くだろ。
ペースメーカーならリチウム電池で十分なんでは? (本人はアレで面白いと思ってるのでそっとしておいてあげて、) 16F1827のSleep機能について
OSCCON=0x00; としてLFINTOSC31kを選択すると
Sleepしても即Wakeしてしまうのは仕様なのかな？
MFINTOSCの31.25kHzを選択すれば寝るのだが…
LFINTOSC供給ペリフェラルWDT,FSCM,PWRTを
無効設定にしてるので大人しく寝てくれても良いのに… >>554
そのスペックでも1454そそるなあ。
USBでMIDIを受けて、EUSARTかI2Cに変換させたいだけだから。
夕方、秋月突撃してみる。
1454をMCC使ってUSBのCDCやMIDI送受信したいときは、MLAみたいなサンプルコード吐いてくれるの？ >>569
SLEEPはクロックを停止することで消費電力を下げるけど
LFINTOSCはSLEEPしても停止しないので動作し続けるのでは？？？？ 今さらだがmtouch使ってみた。
お手軽でいいね
感度をできるだけ高くしたいんだけど、発振周波末や比較する電圧、充放電電流の設定と感度の関係についての死霊とか情報ないかな？
パッドをでかくする以外にもこの辺の設定も関係有るのではと思ったんだけど、
マイクロチップのドキュメントにはそこまでつっこんだ記述がなくて 資料はいくらでもあるけど死霊は検出出来ないだろうな。 資料なんて大量にある。まず読んだドキュメントをかけや
感度いくら高くしても誤動作多くなるだけだぞ、ほんとに作ったのか？ これみんな戦争で戦前の日本が行った残虐行為
若い人たちは知らないだろうけど
俺たち のご先祖様はこんなことやってきたんだ。。。
我々日本人は反省しなければならない
そして戦争のない時代を築いていこう
今回の選挙は、戦争反対の「民進党」に投票しよう！！！
共産党でもいいよ！
http://www2.biglobe.ne.jp/~remnant/tumeeri2.jpg
http://www2.biglobe.ne.jp/~remnant/bayonet.jpg http://www2.biglobe.ne.jp/~remnant/buriedalive.jpg http://www2.biglobe.ne.jp/~remnant/bodiesriver.jpg
http://www2.biglobe.ne.jp/~remnant/Lots_of_heads.jpg http://www2.biglobe.ne.jp/~remnant/infantsdead.jpg
http://www2.biglobe.ne.jp/~remnant/chinahead.jpg
http://www2.biglobe.ne.jp/~remnant/nankinginfant2.jpg
http://www2.biglobe.ne.jp/~remnant/publicexecution.jpg
http://www2.biglobe.ne.jp/~remnant/Killednanjing.jpg
http://www2.biglobe.ne.jp/~remnant/behead_china.jpg
http://www2.biglobe.ne.jp/~remnant/shanghaibaby.jpg >>574
>>575
遅レスと文盲 申し訳ない
呼んだドキュメントは↓の2つくらい
AN1334 堅牢なタッチセンシングの設計手法
DS41328A mTouch ユーザーズガイド
ハード的な注意事項とデジタルフィルタの特性、ライブラリの使い方は載ってるんだけど、
入手しやすい小ピンで使えるCSM形式については電圧検出式(CTMU, CVD)の方が優れるくらいしか書いてなくて、
周波数検出式(CSM)については詳しく触れてないんだ。
その類いのドキュメントを知ってるか試して特性が解った人がいれば聞きたい >>554
一昨日に八潮で買った16F1454は最新のA6だった うちWindows7なんですが、
みなさん、もうWindows10にアップデートしました？
する予定？
それともしない？
このスレ的にどっちがいいのか、ご意見をよろしくです。 7から10にしたけど、MPLABXとPickit3は使えてる。
ただし重いよ。 >>582
エンジニアたるもの新しい物を拒まず挑戦していけ >>583
誰が多数決すると言ったんだ？
>>584
ありがとう、参考になる。
>>585
エンジニアがどれだけの者か知らんが、
開発環境は安定第一という考えもある。 特に不満がない限り積極的にツールを新しくする事は無いし、リリースノートを
必ずチェックして変更点が直近で必要ないものばかりならやっぱり更新しない OSが上がったからってコンパイラがつくるコードが変わる筈も無い。 ツールを最新にするかどうかは、正解はないでしょうね。
どちらでも恩恵もリスクもあるだろうし。もう本人の自己責任としか言いようがない。
(細かいバグフィックスは、リリースノートに載ることは期待できないし)
OSについては、俺はメインの環境は7から10にして、動作が軽くなったと感じています。
でも古い周辺機器のサポートがどうなるかわからないから7のパソコンも残しているよ。
「安定第一」と「新しい物に挑戦」は方向性が違う概念だと思います。
安定させるためには、新しいものへのアップデートも必要なことがありますね。
リリースノートにすべてのバグフィックスがリストされることなんて期待できませんし。 開発ツール類なんて複数バージョン併用しやすいように作ってあるのが殆どなんだから
上手く使って自身の問題解決に役立てればいいんで無い？ PIC16F1455によるUSB-MIDI I/F
http://wp.me/p17P2N-cm 仮想環境でそれぞれの開発環境作ればOSは何でもかまわないよ
仮想環境内でネット使わなければセキュリティー問題もないし
HOST環境でネット使用して共有フォルダー経由でデータの受け渡しすれば
それほど面倒ではないし >>594
仮想環境で、PicKitのドライバとか、自分の作ったPIC用のUSBドライバって、簡単に動く？
厳密なタイミングとかの確認ってどうやるの？
さらにHOST(例えばLinux)で対応しておらず認識しないハードウェアを仮想側(例えばWindows）にドライバいれて
ちゃんと動きますか？ Pickit3は仮想マシンでも問題なく動作してるよ。 USBなんて元々仮想環境みたいなもんだから全く問題ない。
厳密なタイミングなんてUSBじゃ元々無理なんだから気にするな。
ま、℃素人だから余計な所が気になるんだろうけど。 usbaspは仮想彼女でも問題あって、認識もしないね PICはArduinoにはなれなかったから
ガキみたいなジジイがいろんなとこで粘着してんだよな >>606
おじいちゃん、その話はもう何度もしたでしょ>>399>>443 探す？おぢぃちゃんはログを見直してるって思っているんですねぇ。 >>608
なに、簡単なことです。
スレを「全部」表示にして長尺印刷します。
広縁にたぁっと伸ばし、十寸勾配程度で睨みつつすり足で移動すれば、
四半刻もかかりません。 >>591を見て、やる気が湧いた。
10bitPWMのDDS×5ch×4チップのMIDI音源。
秋葉のガチャでFM音源チップ買ったけど、難しそうだよな。
http://i.imgur.com/jb2DX1X.jpg
http://i.imgur.com/uQNuz3H.jpg これみんな戦争で戦前の日本が行った残虐行為
若い人たちは知らないだろうけど
俺たちのご先祖様はこんなことやってきたんだ。。。
これじゃイスラム教徒の自爆テロを非難できない
俺らのおじいちゃん達は大量殺戮の 前例を作ってきた張本人だったんだ。。。。
我々日本人は反省しなければならない
そして戦争のない時代を築いていこう
改憲勢力が2/3を超えたらしいが、民進党と共産党の暴力革命でなんとかなるだろう！
改憲阻止！！！
http://www2.biglobe.ne.jp/~remnant/tumeeri2.jpg
http://www2.biglobe.ne.jp/~remnant/bayonet.jpg http://www2.biglobe.ne.jp/~remnant/buriedalive.jpg http://www2.biglobe.ne.jp/~remnant/bodiesriver.jpg
http://www2.biglobe.ne.jp/~remnant/Lots_of_heads.jpg http://www2.biglobe.ne.jp/~remnant/infantsdead.jpg
http://www2.biglobe.ne.jp/~remnant/chinahead.jpg
http://www2.biglobe.ne.jp/~remnant/nankinginfant2.jpg
http://www2.biglobe.ne.jp/~remnant/publicexecution.jpg
http://www2.biglobe.ne.jp/~remnant/Killednanjing.jpg
http://www2.biglobe.ne.jp/~remnant/behead_china.jpg
http://www2.biglobe.ne.jp/~remnant/shanghaibaby.jpg ・8ピン
・VREF内蔵
となると、12F1822くらいですか。 >>616
>・VREF内蔵となると、12F1822くらいですか。
12F1822って、VREF内蔵してるか? 何VのVrefですか? >616
全て確認したわけじゃないけど1000番台以降ならFVRもってそう。
12F1840 , 12F1612 , 12F1501 は持ってる
>617
1.024V とその x2 , x4。FIXED VOLTAGE REFERENCE(FVR)で探して 横からだけど
ＦＶＲ持ってるのと持ってないのとの区別って
いちいちデータシート開かないとわからない？ >>618
ありがとう。確かにVref持っているね、12F1822。
調べたら、
Accuracy
・12F1822 -8%〜8%
・TL431 0.5〜2% typ
TCR
・12F1822 -114ppm/K
・TL431 +92ppm/K
温度係数は、TL431並なので、初期精度のズレをなんとかすれば、
結構使えるね。
ありがとう。 >>621
そのURLの表って、どうやって見るんでしょう?
FVRの数が、どこに現れているのでしょう。
左右方向スクロールバーを移動すると、最上段のタイトルはそのままで、
下の表だけが左右に移動します。しかも右端まで移動しても、
まだ先の項目があるように見えます。
もちろく、FVRの数のタイトルは出てきません。 どうもありがとうございました。
1XXXシリーズだと脈ありってことですね
とりあえず秋月で1822買ってきます。
>>620
TL431は1mA近く流してやらないと安定しないですよね？
ちょっと勿体ないと思い >>625
後出しで「もったいない」とか言われても・・・
LM385なら10uA〜だけど、それでもだめかな >626
おいおい後出しって・・・ひどい言いがかりだな
そもそも >616で内蔵のVref持っているPICを聞いてるだけで、外部にVref持つのと
どっちがいいとか聞いたわけでもないのに。 聞いた616の時点で消費電流の話なんて出てないから後出しだろが >>627
> そもそも >616で内蔵のVref持っているPICを聞いてるだけで、外部にVref持つのと
> どっちがいいとか聞いたわけでもないのに。
それを後出しと言うのだが くだくだ書けば3行にまとめろなんて罵声が飛ぶ掲示板で、想定する条件を最初から全部書けなんて求めるのは酷です。
郵便で文通してるわけじゃないのだし、やりとりの中でまとめて行って良いのではない?
ある程度の後出しぐらい良いじゃないか。
あと、コトバの行き違いやニュアンスで技術の話から外れて喧嘩になるのは勿体ないです。 こんなんだからPIC使いが変人よばわりされるんだよ
聞かれもしないのに勝手に外付けを持ち出してきて
ヤンワリ断られたからと言って後出しだとか
内蔵品を探してる時点で
・部品点数を増やしたくない
・消費電力を増やしたくない
・外付け品と比べて精度が落ちるのは許容する
このくらい、普通に推測できるだろ、普通は 「後出し」は黄門様の印籠か？
後出しが目に入らぬか？といえば、みんながへへーと這いつくばるのか？
後出しとか前出しとか細かい事にいちいちグズグズ言うな。
ちなみに言って置くが俺は中出し派だ。 でもたかがマイコンの内蔵モジュールに何過大な期待してんだ、
と思わなくもない 期待はしてないが、内蔵温度センサで補正かけたら
何処まで温特を向上出来るかやってみるのも面白いかもしれないな。
暇なしだからやらないだろうけど。 >>627
>外部にVref持つのとどっちがいいとか聞いたわけでもないのに。
PIC内蔵のVerfが、本格的な外部設置のVref ICと大差なくて、いいね。
ということを言いたかったんじゃないの?
最初に431の話を出したときに消費電流のことなんか、少しも言ってないし。
そこに、消費電流の話を持ち出して、否定するようなことを言うから
いけないんだと思う。 >635
部品の性能に文句を言うのと、人に対して文句を言うのを一緒にするなよ 鳥越みたいな後出しはイヤだな。
小池みたいな前出しもどうかと思うが。 まぁだけど、8ピンでVREF内蔵なチップが選び放題ってのは
AVRに対して凄いアドバンテージだな 条件の後出しは仕方がありません。
そんなに条件に拘るなら元レスの「8ピン、VREF内蔵」も尊重すればいいのに。でもそんなにガチガチに考えずに、
「内蔵に拘らずに、目先を変えて外付けって手もあるんじゃないですか？」っていう提案は良いと思うし、
それがそれまで開示されていない理由で否定されるのも、視野が広がって良いことです。
相手を非難する必要はありません。
ところで「8ピン」という条件だと、VREFを外付けすると貴重なピンを1個使っちゃうよね… 18ピンだとしても「貴重なピンを1個使う」事には変わりない。
その上で8ピンに収まるならなんの問題も無い。 mla(2016-4-27)を使って、PIC18F14K50でUSBキーボードを作ろうとしています
サンプルの HID_KEYBOARD に対して、唯一コンフィギュレーションデスクリプタに「_RWU」だけを
追加して、それ以外は一切無変更でビルドしたHEXファイルを用意しました
このHEXファイルを書いたPIC18F14K50をWindows10につなぐと、Windows10がスリープした直後に
即座にスリープが解除されてしまいます。PICを外すとこのような現象は起きないのでこのPICが
原因であることは間違いなさそうです
Windows7ではこのような現象は起きていません
Windowsの電源管理の設定で「このデバイスでコンピュータのスタンバイ状態を解除できるようにする」の
チェックを外せばとりあえず回避できるのですが、そうするとキーボードからスリープ解除が出来なくなります
Windows10でUSB周りの仕様が大きく変わったせいだとおもうのですが、この現象に対する対応等の
情報はありませんでしょうか？ snoopy(って、もう古いか)でusbパケットの流れを見てみてはどうでしょう？
直接解決策じゃなくても自分ならそうします。 PIC16F1455によるUSB-MIDI I/Fの作り方編
http://wp.me/p17P2N-ek >>645
USBでもランニングステータスはあるのかー
勉強になる。 >>646
それって外部MIDI IN/OUTの話じゃ？
USB-MIDIってイベントパケットにランニングステータスはないよ >>647
こういう状態でPCからのMIDIデータをPICで読む場合、ランニングステータスは無くて、常に3バイトデータ(ノートオン、ノートオフを含んだデータ)で転送されるということ？
それだと楽なんだけど。
http://i.imgur.com/G18JTbX.jpg そんなもんソフト次第。曲データ自体がランニングステータスしてるのに
再生ソフトが省くかよ。 >>648
midi10.pdfを見る限り、4バイト単位のパケットで送られているからランニングステータスは無いと思うよ。
元々ランニングステータスは遅いシリアルでも遅延を少なくデータを送るための策だから速度の速いUSBには無用だと思われ。
USBだと常に4バイト単位で送られるからMIDIメッセージの解析がかなり楽になってデバイスは作りやすいはず。 >>649
シリアルのMIDIで送るにしても一旦はランニングステータスを展開していると思うけど。そのまま垂れ流しだと途中で止めたり再開したりすると問題が出るから、そんな再生ソフトは問題だな。 MIDI受信データをPICのPWMでピコピコ鳴らしてるんだけど、止まってるはずの音が鳴り続ける事象がときどき起きていて
現状の受信処理はランニングステータス未実装なので、ランニングステータスでノートオフされると、鳴りっぱなしになるわけで
そこでランニングステータスを疑ったわけです。
MLAが中途半端だからこうなる。 >>652
それってもしかしたらUSBの64バイトパケットを4バイトずつにばらしていないからかもしれないよ。
MLAは64バイト受け取る処理しか書いてないから、64バイトの中身を最大16個の4バイトパケットにばらさないと抜けちゃうかもしれない。
受信したバイト数を調べて何個の4バイトパケットが送られてきたかチェックする必要があるよ。 >>652
MCCに、USB のライブラリも取り込まれた様なんだが、こっちはどうなんだろ？ >>653
今の処理は、ReceivedDataBufferの4バイト目までを読んで、残りは無視してる。5バイト目以降もデータが存在する可能性があるのか。
見てみる。
>>654
期待したけど無いみたい。 >>651
仕様を満たさないゴミソフトしか書けない癖になんで他人のプログラムに文句付けるんだか。
>>652
>MLAが中途半端だからこうなる。
なんでそうなるｗｗｗ
お前がちゃんとランニングステータス実装すれば良いだけじゃ無いかよ。
自分の技量不足なだけだろうに。 >>656
何も考えずにMIDIファイルのままMIDIケーブルに乗せろというのか？
それは無責任だろ？そんな無責任な仕様でいいのか？その方がよっぽどゴミだと思うが。
ランニングステータスを考慮して実装して何が悪い？ちゃんとやってるのに文句を言われる筋合いはない。
ってゆうか、この「仕様を満たさない」の仕様って何？意味がわからん。 PICが受信するMIDIデータを、そっくりそのままEUSARTに
吐いて、いろんな曲を鳴らしながら、Teratermを眺めてみた。
ReceivedDataBufferの5バイト目以降は、
曲の再生開始時以外は値は変化しないように見える。
ノートオンとノートオフだけど取り出して
ピコピコ鳴らすだけなら無視して良さそうだ。
ランニングステータスの有無は、よくわからない。
ランニングステータス対応によるデメリットは無いから、
とりあえず実装して変化をみてみようと思う。
http://i.imgur.com/cDlkb3X.jpg
http://i.imgur.com/8OkiUDU.jpg >>657
ランニングステータスはMIDIの仕様だろ。
それをめんどくさいから実装してないって話じゃ無いのか？ >>660
>ランニングステータス対応によるデメリットは無いから、
対応してなきゃMIDI仕様を満たしてないから動作しないゴミ
対応して当たり前なんだから「デメリットは無いから」って、考えが間違えてる。 >>660
midi10.pdfによるとUSB転送でのランニングステータスはないみたいだよ。
ただ、パケットの5バイト目以降はこちらの実験ではデータが存在したことがあったから実装できるならしておいた方がいいかも。
とくにエクスクルーシブはほぼ確実に5バイト目以降にもデータが存在してた。
ランニングステータスの意義はMIDIのシリアル転送が遅い事に対する策なんだからUSBに存在しないのは理解できるし、めんどうくさいから実装するしないの話ではない。
音楽をやってると音が遅延して出られるとリズムがずれるから演奏もしにくいしね。実際にステージとかで経験しないとわかりにくいのかな？ >>661
>>662
未実装はめんどくさいだけです。すいません。
>>663
俺もmidi10.pdf見てみたけど、
ランニングステータスの記述は見つからない。
MIDIデータサイズも4バイト目までしか記述がない。
しかし、さっきのTeratermでも演奏開始時の5バイト目以降の
データの存在は観測したし、「ききょうや」さんもランニングステータス対応で作ってるし、面倒くさがりは良くないことがわかった。 ランニングステータス判定を実装した。
いろんな曲を聞いてみたけど、検出できず。
たまたま手持ちの曲が使ってないだけかも知れないけど。
今発生してるノートオフ取りこぼしの原因が
ランニングステータス以外にあることはわかった。
http://i.imgur.com/juCNaUG.jpg
http://i.imgur.com/pcCYD0U.jpg そもそも、不具合が発生してるのに原因を特定する事が出来ないとか… >>666
ノートオフの取りこぼしはベロシティ０のノートオンもノートオフとして代替するのを実装していないという例もあるよ。 >>672
それは大丈夫。
設計能力が無いのは確かにそうなんだけど、設計してから作るべきものなんだろうか。
最後の最後になって、もっとピン数多いの使えば良かったとか、はじめから仕様を固めとけば手直しが要らなかった、と思うことはたまにはあるけど。
俺は仕様も回路図も書かずに思い付きで走り始める傾向があるとは思う。仕事か趣味かでも違うと思うけど、皆さんどうですか？ >>674
仕様が決まっていたり、性能が見積れるものなら、最初からできるだけ詰めておきますが、
趣味でも仕事でも「仕様も決まっていないしパフォーマンスが出るかどうかもわからない」なんていう場合は
出来るところから始めてそのまま形にしてしまうこともあります。 ワシ自身はHIDしか作った事ないが、
MLAなり、Harmonyなんて、完結を求めるようなもんじゃなくね？
巨人の肩に乗ってるとは思うけど。 >完結を求めるようなもんじゃなくね？
これってどういう意味?
・完結を求めるようなもの ではないよね?
・完結を求めるようなもの ではないことはないよね?
「なくなくない?」女子高生みたいで、わかりにくいよ 音源の件、いくつかのバグは潰したけど、潰しきれず、
「あるチャンネルのノートナンバーとベロシティが一定時間変化しなければ
そのチャンネルは強制ノートオフ」という暴挙で解決した。 PICのIOポートはドライブ能力が高すぎてリンギングを起こす、等ということは
ありうるのでしょうか？
AVR用のサンプルをPICに移植していたのですが、どうにもPICだと期待した通りに
動かなくて、ロジアナで確認してみたら出力のIOポートのH⇔Lを切り替えた際に
リンギングが起きているようなのです
試しにこの出力ピンとGNDの間に470pFのコンデンサをかました所誤動作しなくなりました
AVR用の回路では当然コンデンサはついていません（ただしAVR用回路の場合は出力ピンは
内部プルアップ抵抗で、PICに移植するに当たっては外付け10kでプルアップしているという
違いはあります）
このような現象は初めてです >681
「ドライブ能力を上げるとリンギングを起こすような回路と基板」は作ろうと思えば作れると思う。
その手の原因がそんなに分かりやすい(教条的にコレと決めつけていい)なんてことは絶対に無いし、
今回のでドライブ能力まわりを疑うのはハズレだと思うけども。
基板も回路も違うんだから、どこで何がおきてるかなんてそれだけでは分からん。
今日はPICのほうの基板で起きたのかもしれないが、
明日はAVRのほうでトラブるかもしれない。そんだけ。 ロジアナでわかるリンギングってどんなのだ？
ドライブ能力じゃなくて負荷とか引き回しの問題じゃないのかね？ オレの知識と経験じゃ、リンギングと断定するにはオシロが必須なんだよね
ロジアナでリンギング判定って
「今日晴れたのは、俺が前日てるてる坊主吊ったお蔭なんだぜ」
みたいなノリに思える 接続したプローブが原因でリンギングが発生する事もあるよね まあリンギングだったらオシロを使うよね．
周波数も関係あるけどパターンや配線が違えば寄生容量とかあるわけで一概にそれをPICのドライブ能力が・・・とかいうのは違うのでは？ リンギングの原因は
1. インダクタンス
配線長によるインダクタンスを取れば消えます。
2. 出力が過激に高速
信号発生ICの、出力電圧の変化が急激過ぎるとリンギング出ます。
PICとAVRの出力電圧の変化の速さ、あるいは、出力電流の大きさを
比べてみます。
出力ビンの直後に10〜33Ωの抵抗を、直列に入れると消えます。
いずれにしろオシロがあると、一発なんだけどね。
なんでもかんでもコンデンサを入れるのは、良くありません。 ロジアナで見えたならリンギングでなくてグリッチじゃないの？ ポート出力でグリッチが発生するかな?って気がしますが。
LになっているポートのビットをHにするプログラムにおいて、
AVRからPICに単純移植したら…L-H-L-H…なんて動きになることってあるのかな。
それはともかく、ロジアナのサンプリングレートとか、ケーブル長とか、受けるデバイスの種類とかもわかった方がいいかも。
それもリンギングなのか別の原因なのかを切り分ける材料になります。
>>689さんが書かれている通り、「とりあえずコンデンサ」は良い解決方法ではありません。
リンギングであれ、グリッチを削除するためのLPFであれ、ドライブするラインの抵抗成分とあいまって効果を発揮している
わけですが、コンデンサを大きくすることで、ラインに流れる電流も大きくなります。
直列の抵抗で抑えることも検討してください。 実はLAT使ってなかったので出力がばたついてました、というオチだったりして プログラムの書き方でありうるか…。
>>681
問題が発生している部分のポート操作のプログラムは開示できますか。
(前後数行ぐらい含めて) >>693
こんな感じです
#define CLK TRISBbits.RB3
LATB = 0b00000000;
TRISB = 0b01111111;
CLK = 0;
_wait_30ms();
CLK = 1;
_wait_30ms();
CLK = 0;
_wait_30ms();
：
>>962
LATではなくTRISでH/Lを切り替えています >>692
LATではなくTRISでH/Lを切り替えています >>695
これで何か問題が出るかな、って感じです。
マイコン側はオープンドレインとして使って、
受け側で10kΩでプルアップ、
この状態で切り替わりのタイミングでばたつきがある
受け側を470pFでGNDに落としたら解決した。
ってことですよね。
配線長はどれぐらいで、受け側のデバイスは何なんでしょうか。 ＞＞６９５
なんかＰＩＣの使い方が根本的に分かってないんじゃないの？
トリスは出力の状態を変えるためのものじゃなくてポートを入力で使うか出力で
使うかを設定するためのもので使い方が根本的に間違ってます
トリスではなくラットで出力ピンの状態を切り替えてください
しかしその前にまずはＰＩＣの教科書か参考書でＰＩＣの基本的な使い方の
勉強をする事をお奨めします。残念ですけど、アナタ、根本的に分かってない。
まったく理解出来ていないように見受けられます >>699
LAT = 0、TRIS = 1、I/Oポート = Hi-Z、回路外の抵抗に H にしてもらって、
LAT = 0、TRIS = 0、I/Oポート = GND、私が L にする。
は、オープンドレイン出力を実現するための手法として、よくやると思うけど。 ＞＞７００
お前の中ではそうなんだろうな、お前の中（ｒｙ
お前がそんなイレギュラーな使い方を良くやるからといってそれが一般的だなんて
思うのは勘違いも甚だしい。そんな使い方は誰もしてない。
そもそもＰＩＣにはオープンドイレンポートは標準でついてくるのでそんな変態な
使い方しなくてもちゃんとオープンドイレンポートがついてくる訳で。 >>699
>なんかＰＩＣの使い方が根本的に分かってないんじゃないの？
>トリスは出力の状態を変えるためのものじゃなくてポートを入力で使うか出力で
えええー。ポートをオープンドレインで使うときはよくやる手法ですよ。
ポート自体は0出力にしておいて、TRIS＝0でL、TRIS＝1でHiZですね。
他のマイコンだとDIRみたいな名前のものもあるのですが、PICはTRISって名前になってます。
この名前になっているのに「出力の状態を変えるためのものじゃなくてポートを入力で使うか出力」って
固定観念になってしまう方がびっくりです。
他のマイコンでDIRって名前であっても、やってることは同じなんでオープンドレインを作るときには使いますが。 >>701
マイコンによってはオープンドレインを標ぼうしているポートが特別に高い電圧に耐えるようになっているものもあります。
もちろん、TRISやDIRによるオープンドレインは通常のポートと同じ耐圧、引き込み電流しか期待できません。
ですが、同じ電圧のほかのデバイスとインターフェースするのであれば、オープンドレインを使う場合には
TRISやDIRは便利ですよ。
いや実に掲示板っていいですね。
普通のポートをオープンドレインにできないものだと思っていた人に新しい抽斗が付け加わりました。 >>701
標準のオープンドレインポートって16FのRA4のことか？
それとも24のODCレジスタのこと？ 後だし情報が凄まじいな。
I2Cをソフト制御でやるときに良く使う手だけど、自分はそれで出力にリンギングやグリッジが発生したことはない。
出力はどんな線をどれくらい引き回してるんだ？
プルアップ抵抗はいくつ？ 誰も使わないって書かれたから釣られてしまうけど、
トランシーバのマイクで、PTT制御と、矩形波の出力を両立させる
時に使ったよ。 >>701
みんな使ってるみたいですが、その点に付いては どう考えていますか? また始まった。小学生のケンカで
「ぜってーだな！ぜってーだな！ 100億賭けるか？」
てのと同じにしか読めんよ。
デジタル扱ってるからって思考もデジタルになってはいかんよ。 >>701
PICをオープンドレインとして使うときの標準的なやり方だよ。
MSSPを持っていない品種をI2Cマスターで使うときには必須。
AN578 - Use of the SSP Module in the IIC Multi-Master Environment
http://ww1.microchip.com/downloads/en/appnotes/00578b.pdf >>711
だな。同じにおひがする。大した技量ないのにいろいろケチつけたがる。
きっとどこかのwebで聞きかじったことを信じてケチつけてるんだろうな。
本質を知らないからあちこちでトラブるんだな。残念な・・・ >>698ですが…
>>695
ずいぶん脱線しましたが、プルアップがある限りTRISでポートの上げ下げをされていること自体は問題はありません。
配線長や受け側デバイスの情報もよろしく。
H→Lと、L→Hの両方でトラブルが発生するでしょうか、それともどちらか一方でしょうか。 文字で説明されるより、回路図を見せてくれたら、一発なんだけど >>715
実装は回路図に載らないだろ。
俺はPICからズルズルと数十センチ以上、線を延ばして受け側デバイスにつないでると思うが。
その程度のオツムでないと信号線にコンデンサ直結なんてしないだろ。 >>716
>実装は回路図に載らないだろ。
その回路自身がどうなっているのか定かではないのに、
実装なんてその先の話だよ。 >>712
> 大した技量ないのにいろいろケチつけたがる。
技量というか、初心者レベルの基礎知識も欠けてる。
LEDのVFが0.6V、とかだもの。 >>718
どっかのサイトで生半可に聞きかじったから、きっとダイオードと名がつけばなんでもVFが0.6Vだと思い込んでたのかもね。残念な・・・
もしかしたら、ゲルマニウムも知らないのかな？若いのかもｗ だけどデータシートの読み方って難しいよね。
VFも電流次第だし。
白色LEDのデータシートのVF欄で3.2Vって書いてあったら、3Vの電池では光らないって考えちゃう人もいるよねきっと。
俺も0.6Vぐらいの電位差を作りたくてダイオード入れて、0.1Vも差を作れなかったような失敗もしたことがあるよ。
下図のような設計を見たことがある。
抵抗の左は5V単電源で駆動されているオペアンプの出力。
3.3Vで動作しているA/Dコンバータに不用意な電圧がかからないように、という気持ちはわかるんだけどな。
>>721
ツェナーといいつつショットキーの記号になってるところでしょ >>721
3.3Vのツェナーがどんな特性を持ってるか
データシート見ればわかるぞ。 >>722
クイズダービーとハウマッチは見てたなぁ
巨泉、たけし、石坂のやりとりは最高に良かった 3.3V動作のA/Dが3.4Vで壊れるわけでもあるまいし いやいや、大電流のときは3.4Vどころか4V以上行ってしまう。
でも、OP AMPの出力インピーダンスが高いので底までいかないと思うけどね。
>>724の真意がわかんない。 >OP AMPの出力インピーダンスが高い
高いじゃなくて低いの間違いじゃないの？
たぶん 724 は、3.3Vのツェナーは3.3Vジャストから通電するんじゃなくて
3.1〜3.2Vでも僅かに通電状態になると言いたいんだろ
(換算抵抗値が∞じゃなくなる)
その結果、A/Dの入力はツェナーの換算抵抗値と1kΩとの分圧になるから
マイナス側に誤差るって話じゃろう PICでサーボモーターの制御の勉強を始めたのですが、
16F84Aで1つのタイマーで6個のサーボモーターを制御出来るか考えております。
良い作例などのURLをご存知の方が居られましたら教えていただけないでしょうか？
過去に調べたときにタイマーのクロックをずらしながらそれぞれのサーボモーターに
パルスを送る作例を紹介しているページを見たのですが今検索しても
ページが無くなったのか探せませんでしたので質問させていただきました。
よろしくお願いします。 制御先はRCサーボでいいんだよな？
古いしマイコンも違うし、指示されている中では外付けICもちょっと洗礼されてない(外付け二つじゃなくてソフト書き替えたら一つでも可能らしいけど試したことない)、
足が足りるかとかは確認してないけど、参考にどうぞ。
Little Burning Core
ttp://www.geocities.jp/mimiin/tips/lbc/index.html ええー?
>>724さん以外、本当に3.3Vのツェナーの電圧電流特性をご覧になってますの?
>>720はやってはいけないA/Dの保護の代表だと思います。
切れ味が悪いとか、3.1〜3.2Vどころじゃありません。
ttp://www.nxp.com/documents/data_sheet/BZX84_SER.pdf
10ページのFig5です。(NXPの製品ですが、どこのものも、低電圧のツェナーは似たり寄ったりです。
2Vで80μAぐらい、流れています。つまり、>>720の回路で入力が2.08Vで出力が2.0V。
2.5Vだと500μAなので、1kΩで500mVダウン。入力3Vが出力で出力が2.5Vですね。
しかもツェナー電圧は温度で変動しますから、テーブルで校正するわけにもいきません。
とてもとても16bitのA/Dに相応しい精度にはなりませんね。 ツェナーダイオードの特性よりもA/Dコンバータの電源が0Vのときのことが
考慮されてない気がする >>734
A/Dコンバータにも依存しますが、そこは>>720でもOKなケースがありますよ。
オペアンプが5Vで駆動する。不幸なことにA/Dの電源が立ち上がっていない。
そんな場合でも、入力保護クランプダイオードに電流を流すことを許容している
1kΩが直列に入っていれば、入力電流は5mA以下で、入力電流を許容している
ADCならたいていは大丈夫ですね。
またまた「それだと入力の絶対最大定格電圧を超える」っていう人が出てくる
かもしれませんが。 >そんな場合でも、入力保護クランプダイオードに電流を流すことを許容している
>1kΩが直列に入っていれば、入力電流は5mA以下で、入力電流を許容している
>ADCならたいていは大丈夫ですね。
むちゃむちゃ…
そんな場合でも、入力保護クランプダイオードに電流を流すことを許容しているADCなら、
1kΩが直列に入っていれば、入力電流は5mA以下なのでたいていは大丈夫ですね。 >>732
返信ありがとうございます。
外付け無しでは不可能でしょうか？ >>714
ありがとうございます
あれから色々と弄くれってた結果、どうやらオープンドレイン出力にしてるのが
誤動作の原因になってるのでは？というところまで分かりました。
試しにTRISでのH/L制御を止めて普通にLATでH/Lを制御するようにしたら誤動作
しなくなりました。（出力ポートについてるプルアップ抵抗10kΩは取り外せない
のでそのままです）
ただ、TRISでの制御（オープンドレイン出力）だと誤動作してLATでの制御だと
正常に動く理由は良く分かりません。オープンドレイン出力は変化が遅いと
言うのをどこかで見ましたが、パルス幅120μsくらいにしても誤動作しました
パルス幅云々は関係なくて立ち上がり／座り下がりの変化がゆっくりだとダメ
なのかもしれませんが良く分かりません >>738
>オープンドレイン出力は変化が遅いと
>言うのをどこかで見ましたが、パルス幅120μsくらいにしても誤動作しました
>パルス幅云々は関係なくて立ち上がり／座り下がりの変化がゆっくりだとダメ
>なのかもしれませんが良く分かりません
「立ち上がり」に対しては「立ち下り」が普通に使われます。
「座り下がり」の方が本来は合ってそうな気もしますね。でも滅多に見ないです。
オープンドレインが遅いことで今回のようなグリッチ?が発生するとしたら、
立ち上がりが遅いことでLHの閾値をまたぐあたりで受け側デバイスのL/H判定が
ばたつくことが原因になることが多いと思います。
でもコンデンサを付けたら改善したのですよね? 立ち上がりはもっと遅く緩やかに
なっているはずなので、別の原因もあるのでしょう。
「立つ」には起き上がる意味合いが強いが、
なんらかの現象が起きるという意味もあるからな >>738
オープンドレインが遅いのではなく、立ち上がりのときにきちんとインピーダンスが低くなっていれば問題なく引っこ抜ける。
だから負荷の問題が大きくて、負荷の状態をきちんと書け、とみんなが言ってるのに書かないのは
突っ込まれるような設計と実装しているからじゃないのか？ >>739
1) TRISではなくLATで制御する
→ 閾値を跨ぐ辺りで旗付かないように素早く変化させる
2) 信号線にコンデンサを取り付ける
→ そもそも信号に雑音が乗らないようにして、ゆっくり変化させても閾値で
誤動作しないようにする >>738
オープンドレインでも立ち下がりは早いです。
AVRのサンプルはオープンドレインでも動いてるのですよね。
そもそもオープンドレインで制御してる理由は何ですか？ >>742
なるほど！そういうことだったんですね！！
(1)と(2)のどっちでも誤動作は無くなったんですが、この場合(1)と(2)のどちらの
対策がよりベターなんでしょうか？(2)のほうが根本対応という感じがしていいのかなぁ
という気もしています
>>743
特に理由はありません
あえて言うなら、人生で初めてPICを触った時に参考にした教科書がそのような（TRISの
操作でL/Hを変えるような）サンプルだったので以降ずっと同じようにしてきました >>744
オープンドレインにする理由が無いなら(1)の一択だと思うけど。
原因も特定できないのにコンデンサで誤魔化すのは邪道だね。 >>744
そういう時は(1)と(2)の対策を両方盛り込むのが常套手段
冗談に聞こえるかもしれないけどプロの現場じゃこれホント
そうする事で実は片方の対策だけじゃ不十分だっって場合でも問題を回避出来る
「こっちのビームが駄目ならガンダムのビームライフル、そしてビームサーベルだ。
いわば三重の武器がある」
これくらい周到な対策を行うべき コンデンサを直接入れると充放電で絶対最大定格以上の電流が流れて故障率が
上がるよ。
根本的に筋が悪い対策。 ドリブン側にコンデンサ入れるのなら、せめてダンピング抵抗をドライブ側にいれてくれ 前スレでPIC16F1454 PIC16F1455の話題出したの私で
私の手柄で秋月で扱い始まったといっても過言ではないのにw
電子工作意欲の谷間に入ってて完全に乗り遅れた…悔しい。
しかしPICのUSB機能の実装は模範的だよね
サンプルコードも模範的で
USB2.0仕様書との対応性が良いから分かりやすい
V-USBとは大違いだよ！ >>752
つられて1454買ったんだけど、MLAのサンプルコードって1459用だよね。
どこを変えれば1454で使える？ >>753
MLAは無駄に複雑だから触りたくなく、
genericにしか興味がなく、
PICのUSB機能は16Fと18Fとで変わらないので、MCHPFSUSBとかいう
PIC18F4550を使った何かのデモボード用の「generic」のサンプルプログラムを
内容理解しながらPIC16f1455用に記述修正してコンパイル通るところまで確認した
だけで終わっているからMLAの1459用のやつとかは良く知らないです。 >>752
>私の手柄で秋月で扱い始まったといっても過言ではないのにw
馬鹿か？自意識過剰すぎ
16F1455なんかMicrochipがACT付PICを発表した直後くらいから18F25K50とともに
リクエスト出し続けてるわ >>754
すげえ。心が折れそうだ。
MCCでポチるだけでコード吐いてくれないと俺には厳しい。 RSだってchip1だってある時代にこの爺さんは何時代を生きてるんだろ>手柄 >>752
いかにも、秋月に並ぶまで指をくわえて待ってるような奴、らしい釣りですね。 ユーモア交えてレスしたつもりだったのに高専のクソガキみたいな奴らに絡まれちゃったよw
定期の途中下車で秋葉原利用できる電子工作者はカツカツしてないのよ >>756
最新のMCCは、USB のライブラリも搭載してるらしい。 >>761
MCC3なんだが、USBの使い方がわからん。
MCCでUSB使えるのは大ニュースだと思うけど、使えてる人いるのかな？ >>759
自分だけが面白いつもりってのはユーモアじゃねえよ。 >>759
＞ユーモア交えて
何が足りないかわかるかい？
それが無いものを「ユーモア」とは呼ばないんだぜ 本人はユーモアのつもり
だが全く伝わらないから他人はユーモアでは無いと
結局、自分の中だけのユーモア PICの入力ピンのインピーダンスはMAXということらしいのですが、
図のような繋ぎ方をしても特に問題は無いということでしょうか？
>>766
それだと全部並列につながるから3.3kΩ1本でプルアップするのと変わらないんだけど >>766
ダメです
矢印（やじるし）の先には何か別の回路の入力が繋がるんだと思いますが、
その回路だと出力ピンの出力が入力ピンに吸われて別の回路の入力ピンに
正しく伝わりません。
PICの出力ピン1つから複数の入力ピンに繫ぐことはご法度（ごはっと）です >>768
御心配には及ばない。
それにしても、白痴並みのレスだな。
何のひねりも無いじゃないかｗ >>766
「MAX」の意味するところが常識的なものだとして、
問題ないが意味もない。>>769のとおり。 >>770
＞矢印（やじるし）
＞ご法度（ごはっと）
このかっこの中って何のつもり？
あと、
繫(きしゅいぞんもじ)
なｗ >766
矢印の先が他のチップの入力なら問題は無いけど(出力ならダメ)、あまり意味もないかと
PIC内で出力ピンのPORTなりLATを読めばわざわざ入力ピンを用意しなくても済むはずだし。
もしかしてPIC内の周辺機能で外部ピンからしか制御できない機能を使いたいということなのだろうか？
それなら、どういうふうに使いたいかを書いたほうがよりよいアイデアのレスがつくかもしれないよ 出力ピンを入力ピンでモニタしている(しかも2本)目的はわからないのだけど、その矢印の先が適切なデバイスであれば問題はありません。
図ではひとつのPICになっているけれど、図に書かれたPICの2つの入力が「ほかの2つのPICの入力」でも同じです。
>>770さんが書かれているような「ひとつの出力から複数の入力を駆動してはいけない」はとても不正確です。
より正確かつ厳密な表現はあるかと思いますが「出力で駆動可能な範囲を超えてほかの入力を駆動できない」です。
電流にしても電圧にしてもスピードにしても、非常に駆動能力が低い出力デバイスだと、相手デバイスによっては1個でさえ駆動できないことがありますし、
その逆にいくつものデバイスを駆動していることもあります。
というか、「アドレスバス」「データバス」「SPI」「I2C]などおなじみの接続は、ひとつの出力デバイスに複数の入力デバイスが繋がっていますね。
>>770さんの真意が知りたいです。
「すげえ決めつけ」と言われて、反論に対しその言葉をそのまま使ってますが、それって言葉に窮した子供が議論をはぐらかすときに使う手段です。
>>771さんに対して思うところがあるのなら、技術的な反論を要求するべきだと思います。
と、ここまで書いて、>>766のような接続の回路を作ったことがあることを思い出しました。有りえますね。 >770
なにも理解できていないところが、>699,701 と同じだな ２ちゃんねるも本格的に終わってるな 次スレ要らないな >>777
上手く説明できるか分かりませんが、こんな感じで考えています
PICのIO端子にコネクタを付けて外部回路の挿し変えが出来る様にしたいんですが
その時に端子の状態からどのパターンの回路が繋がったのかを自動で判別したいんです
例えばOut端子をLにしてIO1-3の状態を読んだ時に、
・IO3がLなら回路Aが繋がっている
・IO2がLなら回路Bが繋がっている
・IO1とIO3がLなら（以下略
という感じです
ただこれをやるにあたってPICのIO端子同士をつないでしまっても大丈夫なのか
自身がなかったので質問させて頂きました
>>780
できれば判定用ポート(端子)とデータI/O用ポート(端子)は分けた方が、あなたの場合はいいと思うよ。 >>781
判定用ポート(端子)とデータI/O用ポート(端子)を分けるというのは、判定用ポートと
データIO用ポートを分けて使って判定用ポートはI/O用には使わない（前述の図で言うと
IO1-3は判定専用に使う）という事でしょうか？
判定用には3本使おうと思っているのですがその3本を判定専用にしてしまうと
データ用のIOが足らなくなってしまうので・・・ >>782
検出用ポートをADCにして、電圧で識別するのは？
写真の回路は、後付けでスイッチを付けたかったけど、
ポートの余りが無かった(配線が面倒だった)ので、そうした。
http://i.imgur.com/4f5aDTJ.jpg 抵抗値の上限はADCの特性上数kΩだったような。
ADCの出力値は計算通りにならないので、
switchじゃなくifで分岐させて検出するといいと思います。
http://i.imgur.com/Ogs5uW5.jpg >>783
ありがとうござます
面白いアイデアではあるのですが今回はそこまで逼迫してる訳でもないので。
IOピンが1本しか使えないような状況だとその方法がいいですね
昔、ビデオデッキにワイヤレスリモコンなんていうものが無くて有線リモコンで
操作してた時のリモコン端子はステレオミニプラグでしたが、あれってリモコンの
ボタンごとに微妙に抵抗値が変えてあったんですね ＞矢印（やじるし）
＞ご法度（ごはっと）
＞ポート(端子)
端子(たんし)、じゃねえんだ！
面白いね、この人ｗ >>784
その数kΩは、A/Dコンバータのホールドコンデンサに一定時間内にチャージするための抵抗値だったはず。
A/Dコンバータ入力の静的な漏れ電流は比較的小さいので、変換周期が遅くて良い場合は、A/D入力端子に
コンデンサをぶら下げれば実質的に抵抗値は高くても良くなります。 >>785
抵抗値の上限の根拠はそれです。
基板の識別なら高速応答は要らないから、
消費電流を減らしたいなら、その方がいいですね。 っていうか、>>780って出力と短絡させる必要ある？
判定用のピンはGNDに落とせばいいように見えるけど
出力とつなぐメリットが見いだせない 緑茶茶かな。
手持ちの抵抗から、出力値がなるべく等差に近付くように選定した気がする。
全部1kΩとかでも大丈夫だと思うよ。
http://i.imgur.com/QJnOMg8.jpg >>790
>>780の説明では「アウトをLにしたときに」という例で説明されているけれど、
実際には、なんらかのパターンでチェックするんじゃないだろうか。
でないと、ほかの入力が外部要因でLになっていた場合に誤認識するよね。
ほかの入力がたまたま「なんらかのパターン」に合致することはない、という前提だけど。 >>790
俺もそう思う。
検出用ポートの弱プルアップをオンオフすれば、出力ポートは不要では。
近距離なら抵抗すら不要では。 >>795
PIC内蔵の弱プルアップを使えば外付抵抗削れる。
長距離引き回すんじゃなければ。 内蔵使うか否かは、配線の長短で判断するものではないでしょ。 内蔵でダメな場合って、ほとんど配線の長短じゃないかな >>797
どんな場合に内蔵を使うかを書かれると有益なんですが。
俺の意見(プルアップが必要な場合に…)
・リセット時に決まってる必要がある場合は外部プルアップ
・プルアップ抵抗が高抵抗かつ誤差大でもいい場合は内部プルアップ
・なんせ部品点数を減らしたいときは使えそうなら内部プルアップ
・あたりまえだけど内部プルアップがないポートなら外部プルアップ。
>>797さん的に加えた方がいいもの、それは違うだろ、が有ったら付け加えて。
長距離を引き回す場合は、外来ノイズを受けやすいことから>>796の考えに至ったのだと思います。
その考え方は有りかと。 > 外来ノイズを受けやすいことから
どんだけ長距離か知らんけど、そんな酷い環境なら、何があるかワカランから
シリーズに入れるなり絶縁なりするんじゃない？
そうじゃなきゃ、内蔵で十分。 >>800
「そんな酷い」もいろいろありますから、環境を2種類で考える必要はないと思います。
本件の場合は仮にノイズでレベルがひっくり返るような環境でも、複数回のサンプリングで対応できると思いますが。
ばらつきも問題にならないし、マイコンが起動してから確定すればいいわけで、俺なら内蔵で対処するかな。 ADC方式は、こっちの方が良かったな。
コネクタ無接続時の電圧が定まるし、部品も少ない。
http://i.imgur.com/4TsyO1W.jpg >>799
>・リセット時に決まってる必要がある場合は外部プルアップ
それは内蔵/外部の話じゃ無くて、プルアップの要不要の話。
>・プルアップ抵抗が高抵抗かつ誤差大でもいい場合は内部プルアップ
「いい場合」とは、どんな判断基準によるか書かなきゃダメだよ。
>・なんせ部品点数を減らしたいときは使えそうなら内部プルアップ
「使えそうなら」とは、どんな判断基準によるか書かなきゃダメだよ。
>・あたりまえだけど内部プルアップがないポートなら外部プルアップ。
それは内蔵/外部の話じゃ無くて、プルアップの要不要の話。
・高抵抗で良くて、
・抵抗の温特が悪くても良くて、
・抵抗値のバラツキが大きくても良くても良い
そんなときに「しか」使えないよね、内蔵プルアップ。
しかも、プルダウンすることも多いのに。
結論
・外部のプルアップを使うと幸せになれる。 リセット中にDI/OがHiZの入力になるCPUを出力で使うときは
＜外部プルアップ＋負論理回路＞が多かった。
そうそう、昔、知り合いが設計した制御装置は、CPUの5V電源が落ちると、
フォトカプラ絶縁の24V系外部出力が全てオンするという素晴らしいものでｗ
「5V電源と24V電源は同時に落ちるから問題無い」という言い訳には笑ってしまった。 数秒ずれると思うんだけど、上司はそれで納得するよ （あるある） 絶縁された24V系統つうと産業機械の制御盤の中身かな > そんなときに「しか」使えないよね、内蔵プルアップ。
そんな「しか」が多いから、内蔵されたんだろうに。
> しかも、プルダウンすることも多いのに。
多いかどうかは設計思想の違い。
> 結論
> ・外部のプルアップを使うと幸せになれる。
論拠がことごとく破れてるよ。 目の前の狭い範囲しか見えてない可哀想な人なんだよ、たぶん。 >>804
プルアップを何のためにするのか、というのはシーンによって一定しません。
「いっときも入力がHiZになっちゃダメだ」という思想と
「リセットのときぐらいはHiZでもいいよな」という思想とではよりどころも違います。
少なくとも、外部ではなく内蔵プルアップを使うケースの多くは、後者に寄りかかったものです。
ですので、この議論をするときは、いったん両方を肯定しないと当然のように外部プルアップしか
容認できないことになります。
当然ですが、俺も両方の考え方を肯定して書いています。
> >・リセット時に決まってる必要がある場合は外部プルアップ
> それは内蔵/外部の話じゃ無くて、プルアップの要不要の話。
ここで議論しているのは、その用途で内蔵でいいか、外部でなければならないか、ですから
やはり内蔵/外部の話なのです。
> >・プルアップ抵抗が高抵抗かつ誤差大でもいい場合は内部プルアップ
>「いい場合」とは、どんな判断基準によるか書かなきゃダメだよ。
判断基準はケースバイケースだと思います。
例えばHiZになってから、Hレベルに落ち着くまでの時間に制約があるなら、外部プルアップで
それを保証する必要がありますね。
> >・なんせ部品点数を減らしたいときは使えそうなら内部プルアップ
> 「使えそうなら」とは、どんな判断基準によるか書かなきゃダメだよ。
高抵抗かつ誤差大でも良くて、リセット時にイネーブルになっていなくていい場合です。
> >・あたりまえだけど内部プルアップがないポートなら外部プルアップ。
> それは内蔵/外部の話じゃ無くて、プルアップの要不要の話。
あたりまえですね。
>・高抵抗で良くて、
>・抵抗の温特が悪くても良くて、
>・抵抗値のバラツキが大きくても良くても良い
>そんなときに「しか」使えないよね、内蔵プルアップ。
「しか」というよりも、俺、結構そういうシーンは多いと思うんだけど。
>プルダウンすることも多いのに。
その多いシーンだと、プルアップで事足りることが多いです。
プルアップでもプルダウンでも良いけどCPUにプルアップしかないからプルアップでいいか、というケースもあれば、
習慣的に負論理で何かがおきるような設計をされているデバイスが多いからですかね。
もっとも、FPGAだとダウンも選択できることが多いと思います。
>結論
>・外部のプルアップを使うと幸せになれる。
不用意に部品点数が多くなることが不幸でないのなら、それで幸せになれると思います。
ケースバイケースで判断したいところです。 最終的に、PICの先につながる基板を選択して、何が出来上がるんだっけ？ Directで注文しようと思って最後の画面で9日に発送とか出てくるから2週間も
先かよーしゃねーなーとか思いつつ、よく見たらAugじゃなくてSepだった・・・
9/9かよ・・・さすがに遅すぎる
Microchip Directに注文して発送が1ヶ月時以上も先とか、注文受けてから
作るのか？ >>812
在庫がなければそういうこともあるんじゃないでしょうか。
個々の超小ロットユーザーの注文を受けてから製造ってことは多分なくて、
次にいつ、その部品を作るのかが決まっていて、それによる出荷がその時期なんだと思います。 48MHz駆動の8bitPIC（PIC18F4553）でパルス幅1μsの信号をXC8で処理記述出来るかな？
1本の信号線で4us周期のパルスが
＿｜￣￣￣ Low 1us - Hi 3us → bit 0
＿＿＿｜￣ Low 3us - Hi 1us → bit 1
と言うのを受信処理したいんだけど。1回の受信は5byteとか8byteと言う感じで
ある程度決まってる
48MHz駆動でも1TCYが83nsかかるんでasmなら楽勝(?)でもCだと厳しそうな気も 48MHzの8bitPICって
Z80A-4MHzのPC8801の10倍位の性能があるのか
良く考えたらこりゃ凄い >>815
プロセッサの種類が違うとクロックと性能比が全く変わる
最近は特にアーキテクチャの進歩が激しいからクロックなんて性能とは関係無いぐらいに思っておいた方がいいかもな PICに外部メモリー、各種I/O、コントローラのせて当時のPC互換に仕立てたモノを想像してみるに、とても性能が上回るとは思えないな。 CPUがせっかく速くなっても、Cで鈍臭いプログラムｗ >>814
>1回の受信は5byteとか8byte
ということは、受信を休んでいる期間があるわけですね。
休んでいる期間はどうなっているのでしょうか。H？
純粋にソフトだけで実装するならアセンブリ言語かなって気がします。 >>817
なんだかんだで、１マシンサイクルの周波数は、ほぼクロックに比例しているような気がするけどね。
マイコンの場合。 ×１マシンサイクルの周波数
○１マシンサイクルの処理性能 >>814
素人の素朴な疑問だけど、
スタートビットとストップビットはあるの？
同じ値が続くと1も0も同じに見えそう。 >>814
もしかしてbit1がクロックでbit0がデータの同期通信？
いずれにしても受信中の処理量、受信完了後の処理量などで必要な時間が変わるから
もう少し情報が無いと何とも言えないな。 >>825
何言ってンのか分からん
単に信号線1本で0/1を送るってだけの話だろ。クロックとか同期とか関係ない
1u/3uの信号は良く知らんが、昔あったAppleのADBポートは似たような信号だった。
（35us/65usでbit0、65us/35usでbit1、これを16回繰り返して2byte通信） >>824
STARTとかSTOPとかは必要ない
こういう1bit転送の場合はIDLE中はHiとかが普通
たとえば「00011」なら
￣(IDLE)￣￣￣￣|＿＿＿|￣|＿＿＿|￣|＿＿＿|￣|＿|￣￣￣|＿|￣￣￣(IDLE)￣￣
こんな感じになってて、HIが一定期間以上続けはIDLEと分かる >>827
アイドル後の一発目の立ち下がりさえ逃がさなければ、111も000も区別できるって事？ >>814
1u/3uくらいならCでも記述出来ると思うけど、その8byteなり5byteの受信を
行ってる間は割り込みも禁止して信号線の監視に専念しないと無理
とりあえずLow/Hiの時間を配列にでもだらだら書き溜めておく
んで受信が一段落ついたところでLow/Hiの時間をチェックして0/1の判定を行う感じ
1usのパルス幅チェックもギリいけると思う >>828
それ取り逃すようじゃそもそも話にならんでしょ
>>814の例だとIDELの後に来るのがbit1なら1usだけLowになるのでこれを
取りこぼすことなく処理を開始するのはそれなりに工夫が必要
INT割り込みとか状態変化割り込みじゃ取りこぼす気がする >>830
INT0割り込みでもアイドル後のLOWを取りこぼす事はないと思うけど、Cだと
割り込み処理に入ってPORTをチェックした時点で既にHIになってそうな予感
レジスタ退避とかその他諸々入れるとそのくらい遅れるのかね MPLAB Xのエディタだけど 改行コードとかタブコードは表示できないの？ >>286
オー、スマンスマン、とんでもない勘違いをしちまった。
入力が2本あるのかと思ったら、値0/1のデューティ比の図だったのか。 クロックストレッチ対応のソフトウェア式I2CスレーブのCプログラムを
AVRマイコン(20MHz) 8bitPICマイコン(20MHz) Z80CPU+Z80PIO(AKI80 12MHz)
の各マイコンに移植してマスター側から供給できるI2Cクロックの上限を調べると
AVRマイコン:約500kHz 8bitPICマイコン:約50kHz Z80CPU+Z80PIO:約2kHz
という結果になる
AVRマイコンと比較するとアレだけどZ80と比較すればPICマイコンはすごく速い >835
10倍も変わるわけないだろ。4クロックじゃなかった？ だから4倍だな。 >836
アセンブラで書いてみればわかるけど8bitPICの命令系はほんとにしょぼい、AVRが１命令でできることを
8bitPICだと2命令以上無いとできないことがおおいし、何より8bitPICの命令体系がC言語に向いてない。
C言語での比較なら1/10も妥当な数字だと思うよ、まあアセンブラ同士で比較しても1/10より多少マシな程度かと
8bitPICは４０年も前の設計でAVRそれから２０年も後発のCPUだからその点は致し方ないかと。
16bitPICなら逆転できるし >>838
AVRのアーキテクチャはたしかにいいけれど、アセンブラで書くとAVRのほうがしょぼいだろ。
ステップとしてはAVRのほうが増える。
逆に言えばAVRがそれだけCに特化されているRISCだということ。 > アセンブラで書いてみればわかるけど8bitPICの命令系はほんとにしょぼい、AVRが１命令でできることを
> 8bitPICだと2命令以上無いとできないことがおおい
> アセンブラで書くとAVRのほうがしょぼいだろ。
> ステップとしてはAVRのほうが増える。
どっちなんだよｗ >>827みたいな波形なら、74CH123をひとつ外付けするだけでEUSARTを使って同期シリアルとして受信できそうな気がする。
それだったら250kbpsの同期シリアルの受信だし、ソフトの負担はかなり減りそう。 わずかなスピードの違いで AVRとPICのファンが争っていても仕方がないと思う。
おまけにソースコードもなしにしょぼいとかしょぼくないとか主観の話になってるし。
どちらも、小規模でスピードに厳しくない用途で使うものになりつつあるんじゃないでしょうか。
スピードが必要なら世間はARMに行っちゃってますよね。 何千品種もあるPICひとくくり
と
何百種もあるAVRをひとくくり 意味ある比較かね？ 比較用
8bit÷8bit 符号無し 例外処理は面倒なので0は無し(なにか他に良いお題はないですかね？)
割る数と割られる数ともメモリかレジスタ上にすでに有るとする
[AVR];レジスタ dividend=被除数&商,remainder=余り,divisor=除数,count=カウンタ
CLR remainder
LDI count,8
LP:LSL dividend
ROL remainder
CP remainder,divisor
BRCS SKP
INC dividend
SUB remainder,divisor
SKP:DEC count
BRNE LP
RET
[MidrangePIC];メモリ dividend=被除数&商,remainder=余り,divisor=除数,count=カウンタ
CLRF remainder
MOVLW 8
MOVWF count
LP BCF STATUS,C
RLF dividend,f
RLF remainder,f
MOVF divisor,w
SUBWF remainder,w
BTFSS STATUS,C
GOTO SKP
INCF dividend,f
MOVF divisor,w
SUBWF remainder,f ;PICは引けるか確認して引くより、引いて負だったら足して元に戻す方がいいかも
SKP DECFSZ count,f
GOTO LP
RETURN >>844
DsPIC対AVRの乗算器で。
PICもAVRも好きなんだよ。
PICのハードの使いやすさや丈夫さ、開発環境の安さと
AVRのアーキテクチャがMIXされると最高なんだけど。 演算ではないけど・・・
少なくともDI/Oの操作に関してはAVRの方が早いと思う。
昔のPICスレで、ある入力のループ処理をPICとAVRのアセンブラで書いて、
総クロック数を計算して比較していたが、結果はPIC:1.5uS、AVR:0.2uSだった。
ただ得意な分野はCPUによって異なるだろうから、
この結果比較で「AVRの方が優れている」と判定する事は出来ないと思う。 >845
16bitPIC(dsPIC,PIC24)はAVR(Tiny,Mega)よりずっと高性能だからわざわざ比較する意味がないよ。
もともと>838で "８ｂｉｔＰＩＣ"って限定して始めた話題だし 18FやEnhancedMidrangeで改善されたけど、Midrangeだとキャリー付き演算が無かったから
多バイトの加減算とかすごくだるかったな。32bit同士の加算だと
[AVR] レジスタ R19:R18:R17:R16 + R23:R22:R21:R20 → R19:R18:R17:R16
ADD R16,R20
ADC R17,R21
ADC R18,R22
ADC R19,R23
[MidrangePIC] メモリ A3:A2:A1:A0 + B3:B2:B1:B0 →A3:A2:A1:A0
MOVF B0,w
ADDWF A0,f
MOVLW 1
BTFSC STATUS,C
ADDWF A1,f
BTFSC STATUS,C
ADDWF A2,f
BTFSC STATUS,C
ADDWF A3,f
MOVF B1,w
ADDWF A1,f
MOVLW 1
BTFSC STATUS,C
ADDWF A2,f
BTFSC STATUS,C
ADDWF A3,f
MOVF B2,w
ADDWF A2,f
BTFSC STATUS,C
INCF A3,f
MOVF B3,w
ADDWF A3,f マクロ使うから全然問題ないな。秋月でdspicの売れ行きが悪いのは
そんな性能はパンピーにとって殆ど不要って事なんだろうな。
俺はdspicをよく使うし、周辺機能も使い倒してるからAVRなんかじゃ全然足らない。
1000倍早けりゃ周辺の貧弱なAVRでも良いかもしれないが、USBをソフトで実装出来ても
信頼性低いしネタにしかならない。 >>849
お前以外の賢い人間はdsPIC使うくらいなら最初から32MX使うから
あえてdsPICを選ぶ必要性がないだけ >>849
ちなみに、FPGAと比べるとどうですか? >>850
使ったこと無いのバレバレだから無理しなくて良いよｗｗｗ
秋月のラインナップにはDSP内蔵無いからdspicに対してアドバンテージ無いんだわ。 使ってないのバレバレなのはむしろ >853 なんだなぁ
この子必死すぎｗ >>852
FPGAも便利だけど、コンパイルに時間が掛かるからdspicで済ますことが多いな。
後、FPGAだけって事は殆ど無くて、dspicも一緒に使う事が多い。
電源投入時に回路情報をdspicから転送する様にしてあるから、専用ROMを在庫する必要が無くなって便利。 >>854
秋月のラインナップにDSP内蔵の物があるのかいｗ 32ビットだから16ビットよりも速いとか思ってんのかなｗ
℃素人まるだしｗｗｗ >845
ところでさ、話そらしてるようだけど >839で言った >ステップとしてはAVRのほうが増える。
の例って出ないの？ >>851
俺情報ｗ
秋月のdspicは新しい品種が増えない上に古いのも減る一方。
ま、デジキーの送料無料つじつま合わせに買ってるから秋月に無くても大して困らないけど
秋月にあれば急に必要になった時安心なんだが、どんどん新しいのが出てくるから
在庫が大変だろうし、多分売れないだろうから秋月にも要望出してない。 秋月スレならともかく、デバイスの話をするときに、秋月で何が売れているかってどれだけの意味があるんだろう。
「秋月で買い物をする客層」という母集団での話にしかならないじゃないか。 そんなこんなで、>>814の元の話題がそっちのけになってるし。 >>860
BGAは滅多に使わないからな。QFPデバイスなら結構いける。
>>861
スレ間違えたｗ
ま、以前、代理店から買ってた時、「秋月が安いですよ。仕入れ数が桁違いだから、あそこまで安く出来ない」
と言われた事もあるから、物によっては秋月使うのも悪くない。
パンピーの動向も知れるしなｗ >>862
もう終わった話だろ。もっと具体的な質問ならば色々レスもつくかも試練が
具体的に書けない理由でもあるんだろう。 >>814にとって終わった話だったとしても、1本線でデータを送る場合に、パルス幅で0/1判定するメリットって何なんだろうな。
・調歩同期より高速化しやすい?
・ビットスタッフ付きNRZIよりシンプル? いや、普通にあるだろ＞１WIREデバイス。
１WIREデバイスがまだ無い時代に、ｚ８０のデバッグ用に使ってたし。
PC９８のプリンタポートでデバッグ情報読んで表示してた。
ｚ８０側はラッチを適当なアドレスに割り当てるだけで済んでかなり便利だったな。 メリットは、1ビット毎に同期が掛かるからマージンを大きく取れるし、プログラムが簡単。 >865
最近だと数珠つなぎできるフルカラーLEDモジュール WS2812がそうだね。
https://cdn-shop.adafruit.com/datasheets/WS2812.pdf
1bit当たり１．２５usだから>814より３倍くらい速いな
数珠つなぎで大量に使うLEDモジュールに採用するくらいだから
転送レート的にもコスト的にも優秀なんじゃないのかな 互いに専用に作られたもの同士の通信ならメリットはわかるんだけど、
マイコンで送受信しようかって話になると、とたんに面倒になるね。 面倒とか言ってると、なんも出来ずに年を取って呆ける一方だから
頭の体操と思ってマクロにしておくといい。
特に、送信側はNOP一つ入れるか入れないかでビットを表現するようにしておくと
占有時間も短いし便利。
例えば、LEDなんてよくインジケータとして付けるが、同じポートにLEDの点灯中か
点滅にあわせてデータを出力しても、人間の目にはデータが乗ってる事を認識出来ないが
フォトダイオードを近づけるとデバッグデータやら内部データを確認出来る。 >>868
これ、0 codeが0.8u/0.35uで1 codeが0.7u/0.6uって超きつくね？
めちゃ厳密にデューティー比チェックしないと簡単に誤判定しそう >>864
具体例が挙がったところでどうせ君には何も答えられないだろうから黙ってればいいよ
と言うか「もっと具体的な例がないと答えられない」とかテンプレ回答するやつは
総じてどんな情報があがってきても回答出来ないやつばかりｗ
周期4usでディーティー比1:3の1-wireプロトコルでデータの塊が8byteとか5byte。
どう考えても任天のN64とかGameCubeのコントローラです本当にあ（ｒｙ では >>814 への回答は、AVRのアセンブラで書けば無問題、という事でw
思い出したけど、リモコンの信号も0/1でパルス幅を変えてるね。
>>870 のアイデアは面白い、いつか試してみようっと。 頭弱い馬鹿は黙ってなよ
そうすれば馬鹿だってばれずにすむよ マクロでって、マイコンさんはその間何してるんだろうって話なんだけどな。 ま、もう惚けが始まってるなら致し方が無い。
無理言って済まんなｗｗｗ >839
8bitPICをアセンブラで書いたこと有るの？
有るなら>848の[MidrangePIC]の所を書き換えてくれないだろうか
さすがにあんなに長くならないよね、もっと短くなるんだよね？ ＞パンピーという略し方は1970年代のツッパリブーム時、
＞ヤンキーや暴走族など不良の間で普及。
＞不良が不良以外を呼ぶ際に使われた。
ID:97mx9dVf
ID:fLoj+bp2
は、ジイで不良、予想通りｗ >>880
逆に、AVRはメモリ⇔レジスタ間の転送が抜けてる。
32ビットの変数をずっとレジスタに入れて置けるなら良いが
プログラム次第だな Timer1を別用途で使ってる場合のサーボモーターの制御ってどうすればよいでしょうか？ >882
ということは、[MidrangePIC]だと >848が最短なの？ >>848
AVR はレジスタ間演算は速いけどメモリ上のデータを扱うとロード２回とストア一回が演算毎に加わってコード肥大化が半端じゃない
演算とメモリへの書き戻しが１命令でできるPICは優れもの AVRは使ったことないからワカランけど、
PICは、メモリ≒レジスタ、な考え方だからね。
演算に使えるレジスタは１個しか持ってないし。 AVRマイコンはシリアル式のISPでトラブると簡単に「fuseリセッタの刑」を食らう
fuseリセッタはパラレル方式だからICソケット＋DIPタイプの縛りから逃れられない
その点はクソ速さだけが取り柄 PIC最高！ アセンブラでAVRのプログラムを書くとき、設計段階での重要な検討事項はレジスタの割り当て。
これがマズイと実行速度が遅くなったり、プログラムサイズが大きくなったりする。
とくにマルチタスクではディスパッチャのレジスタ保存も関係してくるので問題になる。
理由は
・汎用レジスタ方式だから。このへんが8bitPICとは根本的に設計思想が異なる。
なにしろレジスタで受信リングバッファが作れるｗ
・AVRのコアを設計した学生がコード2バイトなのに命令の種類を欲張るもんだからｗ
使用できるレジスタに制限のある変則的な命令が多い。
（例.LDI Rd,K （d=16〜31))
余談になるが、結局、AVRはXmegaで失敗したと思う。
データは8ビットでいいからコードだけ3バイトに拡張し、
レジスタを32個×8組に増やしてレジスタバンク方式を採用すれば、
Cコンパイラを作る人もマルチタスクを作る人も、そしてエンドユーザーも喜んだと思う。
tinyやmegaとソフトコンパチにすれば下位の資産もムダにはならない。
もう今となっては手遅れだけどね。AVRはフェイドアウトしていくんだろうな。 コアを設計する前に、どれだけコアに触れたか
経験は数も大事だし、深さも大事 中途半端で素人考えの浅はかな直行性を持たせると使い物にならないと言う事だな。
z80 vs 6809 しかり、 8086 vs 68000 しかり。
一見、ソフトを組み易いように見えて、そんな細かい事よりももっと重要な事に考えが向いてない。 アセンブラを低級言語、Ｃ等を高級言語と区別するのは、人目線に於いての事。
対してニーモニックベースの話はチップ・デバイス目線。
双方が成り立ちから別なのに言い合っても交差する点はないと思うよ？
AVRの豊富なレジスタ、アドレッシングは高級言語向きだし、
PICの命令セットはアセンブラで技工を培った結果だろうし、
良い所を双方使えばいいのでは？ >AVRの豊富なレジスタ、アドレッシングは高級言語向きだし、
素人の受け売りでしか無いな。
自分でコンパイラ書いてみればわかるよ。32ビット変数をレジスタに置いておかないと
極端にスピードが落ちる様なゴミプロセッサで、どうやってメモリを扱うんだい？
大量のメモリを自在にアサイン出来て初めてコンパイラが生きてくる。
限られたレジスタしか使い物にならないなら、アセンブラでキッチリ書くのが一番。
つまりＡＶＲはアセンブラ向け。と言うより、高級言語には向いてない。 じゃあなんでavrにはgccがあってpicには無いんですかねえ
（・∀・）ﾆﾔﾆﾔ 他にコンパイラを作ってくれる所が無かったからgccを使ったに過ぎない
gccでAVRの能力を発揮出来るわけじゃない。個々のプロセッサの作法を考えてコンパイル出来る訳じゃ無いからな。
Cしか出来ない奴はそのドン臭さに気がつかないだけだよｗ >891
XMEGAは時代的に16bitPICの対抗馬になると思ってたのに、蓋を開けてみればMEGA+α程度
そのくせ8/16-bit AVR microcontrollerとか表記してたり。XMEGAのどの辺に16bit要素があるんだよとｗ
AVRは初期の90S2313の時から完成されたアーキテクチャだったからその後の改良は難しいんかな。
まあ8bitPICも言えた義理じゃないが。Baselinは初代PIC1650の時代を考えればしょうがないとしても
Midrangeはもうちょっとマシに出来なかったのかと・・・16F84Aで32bitの加減算のコード(>848と同じ)
考えた時はめまいがしたよｗ アンカ打たれもしないのに、夜中に朝からと独り言を書き込み続けてんのがいるな。ホントに寂しいんだな。 >895
>自分でコンパイラ書いてみればわかるよ。32ビット変数をレジスタに置いておかないと
>極端にスピードが落ちる様なゴミプロセッサで、どうやってメモリを扱うんだい？
今時のプロセッサってレジスタに置いとかないと演算出来ないかと・・・ >>901
レジスタは普通テンポラリな物だが、AVRはメモリを変数にすると遅くなるので
レジスタを変数に割り当てないと速度が遅くなるって事なんだが？
演算はPICはリテラル相手でもメモリ相手でも出来る。 >16F84Aで32bitの加減算のコード(>848と同じ)考えた時はめまいがしたよｗ
向き不向きがあるからな。向いてないから他の趣味を探せば？
普通は一回作ったら使いまわして改善していくから、それほど問題ないレベル。
それが出来ないのは向いてないとしか言いようが無い。
アーキテクチャの修正は後々まで尾を引くから乗るか反るかの大博打みたいなもん
32ビット演算なんて頻度の低い物の為にコードマップを汚されなくて良かったと思うよ＞Midrange
時代に合わせて過去の資産を生かせる様に建て増しするのが、プロセッサの寿命にとって良いのはx86が証明してる。 >902
そのメモリ相手の演算が8,16bitPICの低速の原因だと思うんだけど。
AVRやPIC32(MIPS)やARM等はメモリ相手の演算は出来ず、レジスタ間の演算しかできないど１サイクルで１命令
8,16bitPICはメモリ相手の演算ができるけど、8bitPICは４サイクルで１命令、16bitPICは２サイクルで１命令
毎回 レジスタに較べて低速なメモリに書き出すより演算に必要な分だけレジスタ郡に読み込んでレジスタ間で
演算を完了させて、必要な結果だけメモリに書き出せばいいわけで。そのために多数のレジスタを用意するというのが
現在のRISCプロセッサの主流かと。
全部で１０００個の変数があっても局所的に見れば必要な変数は極僅かな事が多く、必要な変数を動的にレジスタに
読み出し、変数(メモリ)に書き戻す。動的なレジスタに割り当てなんてアセンブラで自前で管理なんて無理だけど
コンパイラが管理してくれるし >903
>32ビット演算なんて頻度の低い物の為にコードマップを汚されなくて良かったと思うよ＞Midrange
あのさー、PIC18やEnhancedMidrangeで対応されてるんだけどなぁ・・・ 「コードを考えて眩暈がした」ということと「再利用して普段使いする」というのは全く別のものなんだけど、
それを対立概念と考えるのはなぜなんだろう。
眩暈がした、というのはエンジニアリングに対する感受性だし、何の感動もなしにコードを考える人よりは
探求心に期待できると思う。そういうのって改良へのエンジンだもの。
それに、ブラックボックスに押し込んで、眩暈がするような思いをクリアするようなら、中身の動作への関心も
忘れてしまって、「マクロ化すれば面倒さはない」って言っている人みたいなことになるんじゃないだろうか。
まあ、なんであれ、向き不向きをそんなわずかな情報で判断するのっておかしい。 >903
ついでに聞いておきたいんだけど、>848のコードをEnhancedMidrangeで書いたらどうなるかわかる？ >>905
>>903はちょっとわかりにくいけれど、あなたが言っているようなことは、
>時代に合わせて過去の資産を生かせる様に建て増しするのが、プロセッサの寿命にとって良いのはx86が証明してる。
ということで、>903と一致していると思うんだ。
>32ビット演算なんて頻度の低い物の為にコードマップを汚されなくて良かったと思うよ＞Midrange
これは、もともと>>898へのコメントなんだし。
>Baselinは初代PIC1650の時代を考えればしょうがないとしてもMidrangeはもうちょっとマシに出来なかったのかと
この時代について言ったことなのだと思ったよ。当時の時代を考えれば、Baseline→Midrangeの拡張は、
妥当なものであると>903は考えたんだろう。俺もそう思う。
>898は、その時点でもっと大きい拡張があってもよかったと考えたのかもしれない。正解はないだろけどね。 悔しがってると本気で思ってるかそう思いたい願望が強いのか
あるいは両方か
何れにしても℃玄人の思考が人間的に残念であることは自明である >>904
前にも書いたが、レジスタだけで済むなら早いが、現実的にはメモリが必要だから
メモリを積んでるわけで、あとは転送したほうが良いのかメモリとレジスタ間で演算出来た方が良いかは
アプリケーションによって変わる。結果として、市場で負け組みのAVRの
性能が低かったと言う事でしょ。
Cしか出来ない奴は「最近のコンパイラは性能が良い」とか「Cの吐き出すコードはアセンブラより最適化されてる」
だの、夢物語りを語るんだが、GCCを8ビットマイコンに使ってる時点でボロボロだと気付けよｗ
>>906
>眩暈がした、というのはエンジニアリングに対する感受性だし、何の感動もなしにコードを考える人よりは
敏感なんだねｗ
でも、眩暈はただ事じゃ無いかもしれないから医者に見てもらった方が良いかもよ。
>中身の動作への関心も忘れてしまって、「マクロ化すれば面倒さはない」って言っている人みたいなことになるんじゃないだろうか。
マクロ化と中身の関心は別物。マクロ化は如何に自分の手間を省くかって事。
手間を省いた分、ほかの事を考える時間が作れる。
眩暈を起こしてる段じゃ無いよｗｗｗ >908
キャリー/ボロー付きの演算くらいMidrangeで追加しても良かったんではと思うんだけど。
実際PIC18やEnhancedMidrangeで追加されてるから必要なのはMicrochipも認めてるはず。
Midrangeがいつ出来たかは詳しくは知らないけど
http://www.cqpub.co.jp/hanbai/books/37/37291/37291-intro.pdf
この年表をみると1986年PIC16C54(Baseline)、1991年PIC16C84(Midrange)なら
少なくとも1986年以降かと。インテルから32bitCPUの80386が出る時代ですよ。
初代PIC1650(1976年)の同世代の8080,MC6800,Z80もキャリー/ボロー付きの演算命令持ってるし
PICと同じ1チップ系の8048,8051ですら持ってる、そこから10年経ってるMidrangeのPICが持ってないのは
時代に即してるとは思えないんだけど。 >>910
>眩暈はただ事じゃ無いかもしれないから医者に見てもらった方が良いかもよ。
「鼻が曲がる」「ほっぺたが落ちる」「目から鱗」とか理解できる人が
要らないことで煽るのは良くない癖です。
そういうことをしなければもっと愛される人だろうに。 >>911
当時の他のマイコンとの比較は大きい意味を持たないと思います。
Z80などとは狙っている用途が違いましたし。 >>912
℃玄人の致命的に頭が悪いところは自分の立ち振る舞いの悪さにより
損をしていることに気づいていないところだな >913
その次の行も読んでください
>PICと同じ1チップ系の8048,8051ですら持ってる、そこから10年経ってるMidrangeのPICが持ってないのは >>911
>少なくとも1986年以降かと。インテルから32bitCPUの80386が出る時代ですよ。
パソコンのCPUと組み込み8ビットを比較してもなんの意味も無い。
8ビットのしかもワンチップなんて、4ビットに毛が生えたみたいな物だから
プログラムカウンタさえケチってリニアじゃ無い物が在った位、コストの要求が第一だった。
俺は16C54、16C55、16C56から使ってるので、84が出たときもそれなりに恩恵は受けた
386だってアセンブラでFPUぶん回してプログラム組んでた。
アプリ使うしか脳の無いコアi世代のニワカが
>キャリー/ボロー付きの演算くらいMidrangeで追加しても良かったんではと思うんだけど。
とか天然全開でほざいて見た所で歴史は変わらないし、
マイクロチップのこれからの動向に微塵も影響は無いだろうな。
>>912
>要らないことで煽るのは良くない癖です。
これを取ったら俺が俺じゃ無くなる >916,917
ちゃんと>911を読んでほしいな。
ところで、>907はわかりませんか？ >>918
ちゃんと>>916、>>917を読んでほしいな。
ところで、>>907は自分で考えてみれば良いのでは？ >>914
損得勘定でしか話せない奴ほど情けない者は無いなｗ
いつも群れてないと不安なんだろｗｗｗ >>920
孤高な俺かっこいいとでも思ってるんだろうな
社会に属しているからこそ自分の知識や技能に価値が見出されることを知れば
もう少し謙虚になれるだろう ま、でも実社会でもそうだよな
知識や技能の無い奴ほど周りの目を気にして
こそこそ立ち振る舞ってるｗ ℃玄人のような人材は自分の手の及ぶ範囲でことが済む仕事においては
問題なく遂行することができるが、他人の協力を得なければできない仕事
となると途端にパフォーマンスが落ちる さすが、他人のふんどしでしか食っていけない奴の言い訳は哀れだわｗ >>915
その次の行も読んでください
>PICと同じ1チップ系の8048,8051ですら持ってる、そこから10年経ってるMidrangeのPICが持ってないのは
>>913において、Z80という言葉を出さない方がよかったですね。
俺が、8048や51を意識してなかったように見えてしまったかもしれません。
>当時の他のマイコンとの比較は大きい意味を持たないと思います。
>それらとは狙っている用途が違いましたし。
と、読んでもらえば良いかと思います。
というか、マイクロコントローラとしての最低限の実用性を確保した上でどこまで命令数を絞れるか、
みたいなところに設計者は美学を感じてしまっていたのかもしれません。(想像ですよ!) >知識や技能の無い奴に言われましてもｗ
アウトプットのないマクロやサブルーチンって外面的には無能ですね。
具体的に書かない人の能力評価は低いですよ。 >>929
ID:0JN+WqWR のどの辺が具体的？ｗｗｗ
>アウトプットのないマクロやサブルーチンって外面的には無能ですね。
NOPの重要性を考えたことがあるかい？ >>930
アウトプットとは、データを書き換えたり、ポートを変更したりすることだけではありません。
適切な時間を経過さぜることもアウトプットですよ。
重要なことですが、NOPは他の命令やデータを罵倒しないのです。 >>930
俺が思うに、0JN+WqWRはあなたの影のようなものです。
俺もまたそんなふうになっても仕方がないので、あなたの発言に含まれる良いところは
できるだけピックアップしたいな、って思います。 >>重要なことですが、NOPは他の命令やデータを罵倒しないのです。
知ったか℃素人を罵倒するのはOUTPUTだろｗｗｗ >>927
自分の能力を日々高める努力をすることは必要なことであり、
自分でできる範囲を広げることは非常に重要ですし、
あなたはそれを非常に大切にしていると思います
一方で、その考えを強めすぎて、全て自分でできるんだ、
他人の協力など不要だと思い込みは実社会で仕事をする上では
捨てた方がいいです
真に仕事ができる人は個人的な能力が高く、かつ謙虚で
他人を敬い動かすことも得意な人です >>934
>全て自分でできる
なんて言ってるのはID:0JN+WqWR でしょう。だからこそ間違いを指摘されると
意固地になって一連のID:0JN+WqWRの様な書き込みをする様になる。
俺は「他人を敬い動かす」なんて事をネットであろうが実社会だろうがするつもりは無いね。
他人をおだててなんとかしようなんて気持ち悪い。
自分がされて嫌なことは他人にもしない。
℃素人は人にあらず。素人に嘘を吹き込んで偉そうにしてるから叩かれて当然。 なかなか万能な人はいないから。
居丈高にふるまっている人でも、2chに書かれたことを見て、あっそうかなるほどな、と思って
仕事に趣味に使っていることもありますよね。絶対それはないwww って必ず言いますが。
ベテランを自任している人が、「LEDに電圧をかけると0.6Vで電流が流れ始め」って言ってるのも最近見ました。
自任ってその程度のものです。 >928
１チップのマイクロコントローラとしては8bitPICと8048と8051は競合すると私は思いますけどね。
1976年当時8048が実装できて、その１０年以上後のMidrangePICで実装せず、じゃあ不要かと思えば
2001年に登場したPIC18では実装される(まあPIC18は１命令長が16bit化されて余裕があるからというのも理由でしょうが)
さらに遅れて2009年に登場したEnhancedMidrangeは１命令長が14bitとMidrangeと変わらず既存命令はそのままに
新規命令として追加されました。
>903 32ビット演算なんて頻度の低い物の為にコードマップを汚されなくて良かったと思うよ＞Midrange
この方に取ってはEnhancedMidrangeはコードマップが汚れたPIC扱いなのか、どうりで>907に答えてもらえない訳だ。
最後まで不要として貫くならわかりますが、後になって実装したんじゃとても美学とは思えませんね。 >>938
>１チップのマイクロコントローラとしては8bitPICと8048と8051は競合すると私は思いますけどね。
競合して勝ったのがPICって事でしょ。
勝つ理由は色々あるだろうけど、値段≒チップ面積や、プログラムのしやすさ、客先で書き込める等
色々なパラメータのバランス。
しょっちゅうフラグの扱いが変わるのも勘弁して欲しいかなｗ >>937
すみません。アンカー打つときは不等号マークを2つ打っていただけるとすごく助かります。
同一レス内にで同じレスに対して複数のアンカーを打つ場合は、あとは >937 でも差支えないかと思います。
と言ってますが、>>928の引用符が変でした。すみません。
>最後まで不要として貫くならわかりますが、後になって実装したんじゃとても美学とは思えませんね。
「美学」は俺が想像で切り出した話なんで、あまり判断に使わないでください。
それに、美学って要するに「こうしたらきれーだなー」って感覚なので、そのときどきで変わって良いと思います。
貫かねばならぬ、って言われると窮屈ですよ。
製品作りでも「こうした方が良い」って主張はあっていいのですが、話し合いを重ねる中で、「相手の意見にも
いいところがあるなあ」と思い始めるようなこともあるかと思います。
そんなときに、相手の中に「け、偉そうに言うなら貫けよwwww」なんて言う人がいたら嫌ですよね。
まあ、BaselineからMidrangeへのアップグレードはもう過去の話なので、今更論じても仕方がないし、今のチップが
使えるものならそれでいいじゃないかって気がします。
俺の用途だと最近はPICが合わないことが多いのですが、それは俺の問題です。 わざと特徴付けして、誤魔化せてるつもりｗ＞アンカー PIC最大の汚点はポートに対するリードモデファイライトのソースをレジスタにせず
ポートにしてしまったことかな。
後になってLATなどという取って付けたようなものを追加するはめになった。
ポートを直接ビット制御してるような怪しげな製品が一杯存在するんだろうな。 それはそれで便利だったよ。外からドライブしても電流が流れすぎないように出来た品
PICだけじゃなく、他にも同様の物はあった。
速度が上がってLATが必須になったが、昔のデバイスでは問題無かった。 >>895
パソコン速くなって、コンパイルあっという間になったからな。
直交化とかどうでもよくなった。 PIC32に移行したんで8ビット野郎が論争始めてもスルー 収まってから「スルー」とか上げるのは、構ってほしいから？ 最終コードの品質にも影響するから実行速度が変わるだろうけど
コンパイラの出来にスポイルされて、結局どうでもよくなる
どうでもいい奴って、CPUがチューリングマシンに置き換わってても気が付かないんじゃねｗ >>948
それで目的の機能が得られれば、問題ないんじゃないの？
ていうかそっちのほうがいいだろ普通。 >>949
パソコン坊やの発想だな。
ハード絡みで周辺回路が関わってくるのに、CPUが変わって全く同じになるとは思えない。
「どうでもいい奴」と書いたのは、そういう細部まで気を配れない奴の事。
ま、テラHz位のクロックで動くチューリングマシンがあればなんとかなるかも知れんが
最初からチューリングマシンを想定してプログラムを書いたほうが圧倒的に効率が良いだろ。 >>950
電源やら周辺機能、コスト、付加価値含め、要求仕様が満足できればCPUとか言語なんてなんだっていいよ。
使用言語なんてユーザに渡ってからバグが少なく、簡単で単純でメンテが楽なほうがいい。
市場要件や量産規模が大きければ大きいほどそうなる。
CPUとか言語とかこだわるのは遊びで作ってるヲタクだけ。 俺の趣味はプログラミングで、つまりプログラミングは遊びだから
「世界の誰よりも早く誰よりも小さく」を目標にプログラムを作っている。
人間なら当然だろ？ 極限にチャレンジしなければ人間じゃないだろ？
もしも自分がプロだったら「誰よりも効率よく儲ける」になってたと思うけど(笑) >>953
きっと早いとか小さいとかにコンプレックスあるんだね、風俗で言われたりしたのかな？
趣味でもプログラム書くけど、自分は速く小さくより安定動作とメンテナンスを優先するけどね。
個人でいろいろ違うと思うけど、プロは儲けるのが目的でもないよ。お金が儲かるのは結果にすぎない。
ま、社会に出たことない人にはわかんないと思うけどね。 趣味なんだから目的の機能果たせばok、大抵一個作って終わりなんだから、
効率悪かろうが、100円高かろうが問題ない。 >>954
・風俗には生まれてから一度も行った事が無い。一度行ってみたいナ。
セＸＸスした女性は４人しかいないけど小さい、早いと言われた事は無い。
もっとも二人は全くの初心者で判定基準が無かっただろうし、
残りの二人は遠慮したのかもしれない、う〜ん、少し不安だｗ
・安定動作は当然気にするよ、不安定なプログラムじゃ作る意味が無い。
・メンテナンスは気にしない、私のプログラミングはヒマ潰しなので時間はタップリある。
むしろ面倒で手間が掛かりそうだな、となると少し嬉しい
・金が目的ではないのに結果として金が入ってくる、というのは素直に羨ましい。
私もそういう仕事で稼ぎたいｗ
最後に、私は水商売（郷土料理屋）をやっていたので、社会には出ずっぱりです。
どういう理由で社会には出たことの無い人って判断したの？ >>956
僕は趣味のプログラミングでも、作りたいものがあってのプログラムなので、
PICだろうがARMだろうがPCだろうが、CだろうがASMだろうが、遅かろうが速かろうが目的が果たせられれば
何でもオッケーなんですよ。
高速化しないと目的が達成できなければガリガリにアセンブラで書いて高速化もしますが、それが目的では
ありません。
それよりも、使ってる最中や、同好の人ににリリースしたあとにに、バグや想定範囲外の動きで、急遽メンテナンス
しなくてはいけないほうがうんと嫌です。
充分考慮しても想定外のバグは必ず出るし、そういうところのほうが修正が厳しくコストもかかります。
これは仕事でも同じで、コストは、下流工程での修正になればなるほど大変で、
ちゃんとお金をもらってそれなりの仕事をしているプログラマや回路設計者であれば、身にしみているはず。
社会経験の浅い技術者や技術のない営業であればあるほど、基本仕様設計やメンテナンス設計をおろそかにして、
高速化やどうでもいい機能追加などの自分のオナニー的行為に走りがちだと思います。
プログラマーや回路設計でお金をもらって仕事をした人は、機能に影響しない高速化なんかより、リリース後の
問題対処のほうがどれだけ大変か身にしみているはず。
なので、プロ技術者として社会で飯を食ったことがないと判断しました。
プロ技術者と、単なる経営者や営業とは、同じお金をもらうことが結果でも、目的が異なることもわかっていると
思いますので、そこの区別がついていない内容も同様です。 とりあえすPICに関係のない話で煽るのやめようよ。
テツガクは専用の板があるから「ニンゲンなら」なんて話はそっちでやって。 >>956
おっとついでにもう一つ。
マイコンプログラムと回路設計できれば、海外に技術派遣かなにかで行けば、風俗どころか接待でセックルしほうだい。
あっというまに経験人数2桁は超える。
おもいきり低レベルなプログラムか、ネットワーク上位だとすごく重宝される。
日本では使い捨て奴隷だが、海外と日本では技術者の地位がまったく違うことに驚きます。 >>951
要求仕様を満たして且つ安定動作するのは当たり前だな。出来て当たり前。
その上でシンプルで美しいのが良い。
ゴテゴテしてるとか効率悪いってのはバグの入り込む可能性が高くなるからな。
ま、℃素人なら「デバッグを楽しむ」とかほざいてる奴も居るし良いかもしれないがｗ NGID:DJzj/i+d
NGID:LoMtzwa/ >>950
上から目線で説教垂れるくらい立派な大人なんだからスレくらい立てられるだろ？ 要求仕様無く思い付きでソースを書き始めてデバッグが一番楽しい℃素人趣味人です。
しっかり設計してから始めた方が早かったな、と後で思うことはあるけど、しっかり設計するうちに熱が冷めることもあるわけで。
趣味だから許される事だとは思うけど、高いレベルで趣味を楽しむためには設計や、記録を残すことに時間を割くべきかとも思う。 >>957
これ以上他の人たちに迷惑をかけられないので一行だけで終わりにします。
あなたはプログラミングを趣味としているアマと、プログラミングで生計を立てているプロの違いの本質を理解していません。 >>966
本質も何も自分が代表みたいな顔するなよ。趣味アマもプロもいろいろあっていいんだよ。
「人間なら当然だろ？」なんて ↓こっちへいってぶってこい。
http://mint.2ch.net/philo/ >>815
Z80Aと同等の事をやらせるとなるとレジスタの少なさがかなりひびいてくる予感。 次ぎスレ
ttp://rio2016.2ch.net/test/read.cgi/denki/1470076841/ >>968
10倍の速度があればエミュレートしてトントンか速い位かも。 >>950
おまえがスレひとつ立てられないから、>969が立ててくれたぞ。礼のひとつくらい、言っとけよ。 なに寝言言ってんだ？
950=969=俺 だよｗｗｗ PIC32MXで作るMZ-80エミュレータの製作
でやってる人いるよ・・・ アホが住み着いていて罵詈雑言で仕切ろうとするから、
そのうちにみんイヤになって出て行く。 最近は2chの情報の量や質を個人サイトが上回るようになった
2chは気晴らしに、適当にちゃちゃ入れて楽しむところ >>981
お前ほど無能ではないから
気晴らしに、適当にちゃちゃ入れるのに、そう時間はかからんのだよ
それ以外の大部分の時間は有意義に使ってるからご心配なく 構ってもらえないのか…
底辺の集まる(笑)
2chでしか憂さを晴らせないないんて可哀想に
普通の人は、友人と気晴らしに出かけるのにね 最近時間ができて、マイコン工作をまたはじめようと思います
PIC16C84のころで知識が止まっているので、正直ウラシマ状態です
早速ですが、PIC16F1705やPIC16F1827の４ｘPLLについて教えてください
これって入力されたクロック（水晶発振or内蔵オシレーター）をほんとうに４倍にしている
(たとえば８MHz→３２MHｚ）のでしょうか？
４クロックかけて実行しているのを1クロックにして、見かけ上４倍にしている、ということでしょうか？
というのは、外部から入力できるクロックが２０MHｚまでとなっているため、
ほんとうに４倍の３２MHzで動作できるのなら、３２MHzまで入力できるのでは？と思い
疑問に思いました。 発振回路は20MHzまでの制限がある
PLL使う32MHz動作は内蔵発振8MHzを使うときに限る そんなに信用ないなら、ピンに出力できる品種で試したら？ >>985
そういう話をしてるんじゃないと思うが
PLL4で32MHzで動くならPLLを華麗にスルーして直接32MHzを突っ込んで動かす
モードがあっても良いんじゃねーの？なんで無いの？って疑問だろ >>987
発振回路部分の最高動作周波数が、20MHzって事だろ。
外からこの回路に入力しても、当然、20MHzまでしか保証されない。 それは水晶を付けた場合の話でしょ
オシレータなら発振回路とか関係ないし
実際PLL専用ICでも水晶ならxxxまで、オシレータならxxxまでみたいな条件も多い
んでもまあ8MHz付ければx4PLLで32MHzを保証するつーてんのに32MHzのオシレータに
対応するとか何のメリットもないけどな。たぶん対応して無いのはコスト的な理由だよ >>984 >>984
18F26K22なんかは4xPLLで内蔵16MHz*4=64MHz動作で、ECモードの外部供給でも
64MHz入力が可能だから実際に4倍してると思う。 pickit3が見つからん、とほざくから本体見たら、STATUSが赤い・・・・入院が必要なのか？
つい２時間前には書き込めたのに。 >>984
1. 水晶発振回路に使うインバータは周波数に応じた適切なスピードが必要
2. そのインバータの入力が外部クロックの入力にアサインされている
3. 高速の外部クロックに対応するためには、そのインバータのスピードの可変範囲を広くする必要がある
という面倒さから、対応していないものもあるのではないかと思う。
今のは高い周波数の外部クロックに対応しているものもあるよね。 >>993
＞水晶発振回路に使うインバータは周波数に応じた適切なスピードが必要
そこはインバータというのには違和感があるな。
インバータには間違いないんだけど、発振回路なんだから、帰還反転アンプと書いて欲しい。 サイクル数を厳密に調整したい場合に数数えながらＮＯＰ（ノップ）を並べたり
してるんですが、１個１サイクルしか稼げないので場合によってはすごく大量の
ノップを並べなければならないことがあります
ノップみたいな感じでレジスタに一切影響を与えることなく２サイクル以上を
稼げるアセンブラ命令はないんでしょうか？ NOPを使うアルゴリズム自体に無駄があるということに気づくべき >>995
大量にNOP並べても精度でないだろ。
PICのクロックの誤差なんて下手すると％いくのに。 今や旧型のpic16f887でさえ外部から48MHz供給して正常に動くし40MHzのセラミック発振子
外付けでも正常に動作する。
やる気の問題 >995
GOTO $+1
で２サイクル命令になるよ
>996,997
どの分岐ルート通っても同じサイクル数にする際によく使う手だよ
タイマーとか使う余裕すら無い短時間の調整ね。 次スレ
PIC専用のスレ Part54
ttp://rio2016.2ch.net/test/read.cgi/denki/1470978281/ このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 81日 18時間 17分 19秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/
http://pink-chan-store.myshopify.com/
レス数が1000を超えています。これ以上書き込みはできません。
