17/07/17 12:00:46.26 tLOGVm3a.net
PIC24の命令セット詳細(英語)
16-bit MCU and DSC Programmer’s Reference Manual
URLﾘﾝｸ(ww1.microchip.com)
852:774ワット発電中さん
17/07/17 12:48:23.43 vO10BZFX.net
アセンブラバカが出ると炎上する
32bitバカが出てくると過疎る
853:774ワット発電中さん
17/07/17 12:57:01.03 ziTgEkgi.net
PIC32使ったこともあるが、趣味の制御対象なら大体PIC18ぐらいで十分なことに気づく
内蔵ペリフェラルやdipのピン数、パスコンなど外付けパーツの数はPIC18が有利。
大容量でかつ緻密な制御ならともかく、大したことしないのに32ビットにこだわるほうが滑稽
854:774ワット発電中さん
17/07/17 13:27:42.57 Hk/QuPnX.net
そういう100羽一絡げの議論よくない。
855:774ワット発電中さん
17/07/17 14:43:39.32 eG+Ddob0.net
能力の無い人間ほど、あーだこーだと言い訳が上手だなｗ
856:774ワット発電中さん
17/07/17 14:44:16.54 UTYyTvq2.net
>>835
Lチカ程度の事しかしないならPIC18どころかPIC12でも十分だよ
お前にPIC18は不要。というか実に滑稽
今日また一つ賢くなれてよかったね
857:774ワット発電中さん
17/07/17 15:02:21.11 KqHKqRBn.net
PIC32はMIPS32だからもはやPICなのかと言われると微妙
858:774ワット発電中さん
17/07/17 17:13:03.52 SChFaRbK.net
>>831
PDP-11の命令セットを眺めるとなるほどねと思うかも。
859:774ワット発電中さん
17/07/17 18:00:29.27 DcPS9JUl.net
>>839
意味不明
860:774ワット発電中さん
17/07/17 18:15:08.59 tLOGVm3a.net
>>840
これですか？
PDP-11/40 processor handbook
URLﾘﾝｸ(pdos.csail.mit.edu)
861:774ワット発電中さん
17/07/17 18:24:00.51 tLOGVm3a.net
PDP-11なんてDECのベストセラーの16bitミニコンで
Version 7までのUNIXがアメリカの大学でよく使われてたことしか知らない
DECに関してはこんな記事があるよ
業界に痕跡を残して消えたメーカー CPU設計に大きな影響を与えたDEC
URLﾘﾝｸ(ascii.jp)
862:774ワット発電中さん
17/07/17 18:59:35.38 KqHKqRBn.net
>>841
要は巷で流行ってるARMコア搭載のマイコンと構図は変わらんってこと
863:774ワット発電中さん
17/07/17 19:04:40.65 UTYyTvq2.net
DECは消えたけどDECの技術はSamsungに受け継がれたし、DEC魂はSamsungの
中に息づいてるよ
864:774ワット発電中さん
17/07/17 19:13:49.94 DcPS9JUl.net
>>844
構図とPICかどうかと
どういう関係？
865:774ワット発電中さん
17/07/17 19:18:22.07 DcPS9JUl.net
意味不明な屁理屈で32bitをこのスレから追い出そうと？
866:774ワット発電中さん
17/07/17 19:24:30.65 KqHKqRBn.net
>>846
>>847
わるいわるい、そんなつもりで書いたわけじゃないよ
そんなムキにならないでよ～
867:774ワット発電中さん
17/07/17 19:47:50.14 tLOGVm3a.net
>>845
URLﾘﾝｸ(pc.watch.impress.co.jp)
> さらに、旧DECのAlphaプロセッサ開発チームから
> 多数のアーキテクトとエンジニアを迎えることで開発力を強化した。
> K7を担当したDirk Meyer氏は元Alpha 21064/21264のアーキテクト、
> K8を担当するFred Weber(フレッド・ウェバー)副社長
> (Vice President、
868:Computation Producuts Group)は元NexGenのアーキテクトだった。 > その当時は、旧DECのJim Keller氏(Atiq Raza氏の退社後に退社)がK8を担当し、すでに開発を始めていると言われていた。 IntelはDECの半導体部門を買収してるし AMDはDEC Alphaの開発者を引き抜いてる Jim Keller氏はAMDのZENの開発責任者
869:774ワット発電中さん
17/07/17 19:49:24.47 wk/Iu1Nb.net
PICも8ビットと32ビットとでは同じ会社の組み込み用マイコンてだけで
応用用途も作る作法も大分異なるのだしスレ分けたほうが有意義と思うなあ。
同じ会社の製品て括りではもはやAVRもPICと同一スレにすべきという議論も
可能とは思うがそれはない方向なんだろ？
870:774ワット発電中さん
17/07/17 20:07:00.82 tLOGVm3a.net
>>850
スレわけるとARMやルネサスの信者さんが喜ぶよ
871:774ワット発電中さん
17/07/17 20:16:56.55 wk/Iu1Nb.net
>>851
誰かが喜ぶのだからそうするべきという賛成意見？
誰かが悲しむというなら反対意見だけどそうじゃないんだよね？
872:774ワット発電中さん
17/07/17 20:33:56.04 rSrwPqCy.net
趣味性が強くて感情的になりやすいってのはあるかなあ。
PICだけがスレがたくさんあるのも、なんだかんだ言っても感情的なものが原因だし。
873:774ワット発電中さん
17/07/17 20:41:09.68 tLOGVm3a.net
>>852
ルネサスのスレでここ一週間くらいのレスみてくるといい
874:774ワット発電中さん
17/07/17 21:16:29.88 wk/Iu1Nb.net
マイコンなんて必要に応じてPICでもARMでも適当なのを選べば
良いと思うけども、Microchipの社員でもないユーザーの立場で
PICに拘ってそれ以外のユーザーを敵視するって馬鹿とかしか思えん。
875:774ワット発電中さん
17/07/17 21:19:04.70 rSrwPqCy.net
>ARMやルネサスの信者さんが喜ぶよ
その人たちが喜んだとして、PICユーザーに何か不都合でもありますの？
876:774ワット発電中さん
17/07/17 22:50:44.60 DcPS9JUl.net
>>769
877:774ワット発電中さん
17/07/17 22:56:44.99 UTYyTvq2.net
別に分ける必要なし
878:774ワット発電中さん
17/07/17 22:59:58.18 rSrwPqCy.net
>>857
言われないと前に進まない人なのかな？
過疎るとどんな不都合がありますの？
879:774ワット発電中さん
17/07/17 23:02:43.26 DcPS9JUl.net
>>859
分けたいならそのメリットをまず上げるべきかと
880:774ワット発電中さん
17/07/17 23:06:54.73 DcPS9JUl.net
C言語で組んでいれば命令の差など些細な差
それよりもペリフェラルの差の方がソフト設計やハード設計をする上で重要
PICはどれもペリフェラルの作りは近い
特に16bitと32bitは非常に近く、
ピンコンパチであったりもする
881:774ワット発電中さん
17/07/17 23:09:21.56 DcPS9JUl.net
分けるなら分けるで、16bitをどうするかでまた揉めるぞ
882:774ワット発電中さん
17/07/17 23:19:21.35 DcPS9JUl.net
ビット数で分けたら、次はC言語とアセンブラを分けるとか言い出しそうだな
883:774ワット発電中さん
17/07/17 23:21:56.56 rSrwPqCy.net
>>860
まず基本的に分けないという姿勢でこれまでやってきたか、ってことがあります。
PICスレは名目上、分かれていますが、中身は混濁しています。
中国系禁止みたいに公序良俗に反するわけでもない、合理的なことが書かれた>>1とは
関係なしに喧嘩が発生します。そんなことならスレを再統合すれば良いのではないかと
俺は思うのですが、そうはなっていません。
これは「スレは統合が望ましいものである」という共通認識がないことの証明です。
分けるメリットは上にも書かれてますので俺が繰り返す必要もありません。
互いに感情を傷つけあうレスを慎まないなら分けた方が良いでしょう。
他の例でいえば、テスターのフルーク禁止スレは、たまに揉めますが、おおむね有効に
働いています。(その>1を読めば、公序良俗に反するものでもないことがわかります)
>>862
>分けるなら分けるで、16bitをどうするかでまた揉めるぞ
揉めたら分ければいいんじゃないですか？
884:774ワット発電中さん
17/07/17 23:25:30.11 rSrwPqCy.net
>>864を書いていて再認識したわけですが、
>互いに感情を傷つけあうレスを慎まないなら分けた方が良いでしょう。
おそらく、これが楽しいと感じる人が何人かいることが根源的な問題なんですよ。
885:774ワット発電中さん
17/07/17 23:27:08.49 DcPS9JUl.net
分けたら揉めない
という根拠は？
886:774ワット発電中さん
17/07/17 23:28:30.03 DcPS9JUl.net
PIC共通の話題はどこてする？
887:774ワット発電中さん
17/07/17 23:29:30.96 DcPS9JUl.net
既に2個もスレがあるが、
初めてスレだけ分けたいの？
888:774ワット発電中さん
17/07/17 23:33:50.37 rSrwPqCy.net
>>866
おっと。俺がそんなことを書いているとしたらミスです。どこかな。
揉めないではなくて、揉める頻度が減る、ですね。
根拠はひとつは、テスターのフルーク禁止スレです。たまにそのことで揉めますが、
分ける以前の揉め方とは段違いの平穏さです。ってこれ、>>864でも触れてるじゃあありませんか。
889:774ワット発電中さん
17/07/17 23:33:54.86 DcPS9JUl.net
テスタースレの分割が有効に働いてる？
またまたご冗談を
890:774ワット発電中さん
17/07/17 23:35:22.04 DcPS9JUl.net
揉める頻度が減る根拠は？
分けた場合のデメリットはちゃんと把握してる？
分け方は？
891:774ワット発電中さん
17/07/17 23:36:37.90 DcPS9JUl.net
>>861に対する意見は？
892:774ワット発電中さん
17/07/17 23:37:13.41 rSrwPqCy.net
>PIC共通の話題はどこてする？
PIC総合スレを作ればいいじゃあありませんか。
でもね、分ける以前に
> >互いに感情を傷つけあうレスを慎まないなら分けた方が良いでしょう。
> おそらく、これが楽しいと感じる人が何人かいることが根源的な問題なんですよ。
本当はこっちをなんとかした方が良いわけですが。
たぶんね、8ビットPICスレで「PIC32 ビットを使わない爺はボケだ」なんて言う人が出てきたら、
「スレチだ総合スレでやれ」って話になります。
893:774ワット発電中さん
17/07/17 23:38:37.69 rSrwPqCy.net
>>872
これも>>873で。
894:774ワット発電中さん
17/07/17 23:39:49.02 DcPS9JUl.net
スレの乱立は賛成しない
895:774ワット発電中さん
17/07/17 23:40:38.84 DcPS9JUl.net
揉めるのがイヤなら揉めない工夫を
スレを分けても解決しない
896:774ワット発電中さん
17/07/17 23:41:06.35 rSrwPqCy.net
>テスタースレの分割が有効に働いてる？
>またまたご冗談を
あー。
これからフルーク禁止スレで、フルークの話題を連投する人が出てきてもカウントしません。
有効に働いていないことにしたい人がきっといます。
897:774ワット発電中さん
17/07/17 23:42:52.31 rSrwPqCy.net
>揉めるのがイヤなら揉めない工夫を
たいしてデメリットのないスレ分けも工夫のひとつじゃありませんか。
で、それ以外に、何かありますの?
既に無視し続けるには不快すぎるからこういう話題になるのですよね?
898:774ワット発電中さん
17/07/17 23:45:40.47 rSrwPqCy.net
>スレの乱立は賛成しない
だったら有効にスレ分けが働いていないPICスレも統合する方向に。
899:774ワット発電中さん
17/07/17 23:46:00.11 DcPS9JUl.net
君自信、電気電子とは関係ない話題を延々してスレを汚してる自覚はある？
無いなら君も彼らと同じ
悪気が無いだけたちが悪い
900:774ワット発電中さん
17/07/17 23:46:31.96 DcPS9JUl.net
>>879
よろしく！
901:774ワット発電中さん
17/07/17 23:47:03.29 DcPS9JUl.net
あとは任せた
902:774ワット発電中さん
17/07/17 23:47:08.50 UTYyTvq2.net
分けたきゃ勝手に分ければいいよ
ただし後から俺ルール出してきておきながらそれを他人に強要しないのなら。
分かれた後も8bitも32bitもこれまでどおりこのスレで会話するけどその時に
「32bitは向こうのスレでやれ」とか一々強要してこないのなら勝手にどうぞ
903:774ワット発電中さん
17/07/18 05:44:00.91 7eWwVQ9B.net
まあ分けても過疎るだけだろうな
32bitバカってID:E7pLNk3Uみたいに薦めるだけで大したこと書てないから
904:774ワット発電中さん
17/07/18 06:31:46.08 6CAge1nZ.net
>>767が32bitバカか
32bitの話題が上がるだけで拒絶反応なんだね
病気か？
905:774ワット発電中さん
17/07/18 06:39:32.44 qfL0/tqD.net
分けたって出張合戦になるだけだから無用。
906:774ワット発電中さん
17/07/18 06:56:44.22 6CAge1nZ.net
まずは、初めてスレとして整備すれば？
テンプレとか
高くて性能の低い古いPICも普通に売ってて選ぶのに困るから >>6 にまとめたり、
PICの特徴をわかった上で使ってほしくて >>5 にまとめたり
そういうの、おれが来るまで誰もやってなかったよな
おれが勝手にまとめたテンプレに対して意見すら何も出ない
あとあれば良いと思うのは、PIC関連の情報へのリンク集
907:774ワット発電中さん
17/07/18 07:05:26.76 6CAge1nZ.net
開発環境の説明もほしい
PICKIT3
MPLAB X
MLA
MCC
Harmony
908:774ワット発電中さん
17/07/18 07:43:35.52 P/ytct1a.net
スレ分けるより、MicroChipに、AVRコア＋PICモジュールのPICAVシリーズを出してもらうように運動しよう！
みんなが幸せになれる
909:774ワット発電中さん
17/07/18 07:52:47.58 f/XGLWLm.net
しょせん人間の醜悪さを競うような罵詈雑言のゴミ溜めスレだぞ
細かく分けても悪臭プンプンの分別ゴミ箱が増えるだけｗ
910:774ワット発電中さん
17/07/18 08:04:19.62 6CAge1nZ.net
>>889
PICコアのどの辺が不満？
911:774ワット発電中さん
17/07/18 08:13:34.49 qfL0/tqD.net
AVR8bitとか32の周辺ってそんなに腐ってた？
912:774ワット発電中さん
17/07/18 08:57:11.20 P/ytct1a.net
>>891
8bitのバンク切替なところ
913:774ワット発電中さん
17/07/18 08:57:33.59 P/ytct1a.net
>>892
PICに比べるとノイズ耐性が低い
914:774ワット発電中さん
17/07/18 10:37:18.96 DeG44/DB.net
C言語そのものというより、ライブラリや変数の型でコード効率や、スピードで問題出てくるからね。
PICの場合、不用意に浮動小数点をつかったり、8bit変数 ですむところに 16bit変数を使うとか、
printf等のライブラリを使うとかで、余計プログラムサイズが増える。
トレードオフの問題だけど、
関数呼び出しの、オーバーヘッドを意識して、あえて、変数をグローバルエリアに確保するとか。
915:774ワット発電中さん
17/07/18 11:04:43.13 P/ytct1a.net
>>895
8bitのPICの場合、実コード上では、グローバルとローカルでそんなに大きく意味があるとは思えない。
916:774ワット発電中さん
17/07/18 11:55:14.42 WBT7nM9D.net
>>893
32bit使えば解決
917:774ワット発電中さん
17/07/18 11:57:28.06 WBT7nM9D.net
>>895
不用意に浮動小数点を使うライブラリってどれ？
918:774ワット発電中さん
17/07/18 12:03:36.30 P/ytct1a.net
>>897
32bitの5Vのラインナップってたくさんある？
919:774ワット発電中さん
17/07/18 12:10:40.41 gbOT6R2z.net
5Vに拘るのはアセンブラバカ。
Arduinoでレベル変換たくさん使うバカと同類。
920:774ワット発電中さん
17/07/18 12:15:59.95 qfL0/tqD.net
そんなにレギュレータ載せたくないの？
921:774ワット発電中さん
17/07/18 12:55:54.86 nVjybN+z.net
そんなところで、RaspberryPi ZeroWが1300円なりか・・・
922:774ワット発電中さん
17/07/18 13:03:57.92 WBT7nM9D.net
5V馬鹿
アセンブラ馬鹿
8bit馬鹿
16bit馬鹿
32bit馬鹿
PIC馬鹿
>>890が正しいかも
923:774ワット発電中さん
17/07/18 13:29:16.31 WBT7nM9D.net
AVR馬鹿、RaspberryPi馬鹿、Arduino馬鹿はスレチ
924:774ワット発電中さん
17/07/18 14:47:09.14 WBT7nM9D.net
>>889
みんなって？
お前だけだろ
925:774ワット発電中さん
17/07/18 15:30:09.36 P/ytct1a.net
電源は3.3でもいいんだけど、FETをドライブするのにポート出力が5V欲しいんだよ
3.3で直でドライブできるFETはかなり減る。
プルアップしても良いんだが、5Vトレラントでもあまりやりたくない
直接Lチカするだけでも3.3だと抵抗値が5Vより面倒くさい。
926:774ワット発電中さん
17/07/18 15:54:23.60 DeG44/DB.net
>>898
たとえば簡単な温度計測表示等で、整数値演算でこなせるものを、float使ったりすることですよ。
もちろん、使い分けですけど。
927:774ワット発電中さん
17/07/18 18:07:55.69 WBT7nM9D.net
>>907
で、どうしたいの？
>>906
無いものねだりしてもしょうがない
時代的にはマイコンの電圧は下がる方向だから、
3.3Vでなんとかする方法を考えるか
先が無いのを承知で5Vを選ぶか
しかない
バンク切り替えの何が問題？
928:774ワット発電中さん
17/07/18 18:09:20
929:.84 ID:WBT7nM9D.net
930:774ワット発電中さん
17/07/18 18:32:00.85 J/AKPH0N.net
>>908
分かっているくせにわざわざ聞く嫌な野郎だな
本当に分からないのなら適正ないから事務屋でもやってろ
931:774ワット発電中さん
17/07/18 20:37:41.68 6CAge1nZ.net
言わなきゃわからん
932:774ワット発電中さん
17/07/18 21:35:36.70 /uarHnXn.net
5Vトレラントのオープンドレイン+外付けプルアップで強引に……
933:774ワット発電中さん
17/07/18 21:39:20.07 zKAMRjWg.net
バススイッチでいいんじゃない？
Cypressのマイコンは何故か5Vトレントが充実してるけどMicrocipのマイコン
（あと旧atmelのやつも）は5Vトレントじゃないか、トレントだとしても限られた
わずかなピンだけなんで基本的には5Vトレントなバススイッチを併用してるな
934:774ワット発電中さん
17/07/18 21:43:20.04 W2aAVRli.net
トレラントね
935:774ワット発電中さん
17/07/18 22:04:46.11 P/ytct1a.net
>>908
AVRコアにPICモジュールがなぜ欲しいかと聞かれたから
リニアアドレスで5Vそのままつなげられる頑強なIOとモジュールでDIPってのが便利だと答えたまで。
AVRはいい線っていると思うが、メーカーの対応としてはMicroChipのスタンスが好きなので。
それをないものねだりとか言われても困る。別にねだっているわけではない。
バンク切替の問題がわからない人に答えても無駄でしたね。
>>910さんの回答がナイスでした。
936:774ワット発電中さん
17/07/18 23:16:02.46 6CAge1nZ.net
>>889が無い物ねだりじゃないって？
運動しようとか言ってるわりに、
全く賛同を得ようという気が無い
変な人
みんなが幸せ？
お前が幸せになりたいだけだ
937:774ワット発電中さん
17/07/19 06:56:46.86 Y0WeyBA5.net
MicroChipって書き方が変です。
938:774ワット発電中さん
17/07/19 08:31:05.89 MCBRWJYc.net
>>916
PIC関係ないところで個人攻撃がお好きなお方ですね
939:774ワット発電中さん
17/07/19 10:12:21.19 NL5AYZ9m.net
AVRはスレチ
940:774ワット発電中さん
17/07/19 12:21:43.63 ctD0e0YN.net
1社がIDEを２つ持ってるのは不自然な感じがする。長期的にでもまとめて頂きたい。
941:774ワット発電中さん
17/07/19 21:13:09.87 gnJ4d3Ut.net
ここに書いても無意味
942:774ワット発電中さん
17/07/20 06:23:01.79 deVyL6yO.net
相手の発想を「馬鹿」と言う馬鹿
943:774ワット発電中さん
17/07/20 07:51:33.67 uSN7MDdK.net
PICって何がいいの？
944:774ワット発電中さん
17/07/20 09:28:26.77 lgLp4sGo.net
8pinが豊富なところが良い
945:774ワット発電中さん
17/07/20 10:05:08.02 z4oui2Fk.net
>>923
コピペ元がたくさんあること。
単純で制約が大きいので、やれOSだの、マルチタスクだのとややこしいところに
手を伸ばさなくても済むこと。
Atmel（AVR)などの敵対勢力はMicrochipが買収してくれるので、安泰に思えること。
などなど
946:774ワット発電中さん
17/07/20 10:06:18.91 0zN0toQM.net
ライターが安い
947:774ワット発電中さん
17/07/20 11:29:24.29 uSN7MDdK.net
>>924
8pinの作例を教えて下さい
>>925
コピペ元のリンク集をいただけると
>>926
最近はどこも安い気がする
ST-LINK/V2とかLPC-Link2とか
948:774ワット発電中さん
17/07/20 11:32:49.26 uSN7MDdK.net
マイコン自体の売りはありますか？
949:774ワット発電中さん
17/07/20 12:21:34.28 0zN0toQM.net
夏休みだね…
950:774ワット発電中さん
17/07/20 13:13:36.57 AvSuDKE+.net
ID:uSN7MDdK って質問者を装って、>>927のように周りの用事を増やしたり逆らうが目的。
相手にしなくていいでしょう。
951:774ワット発電中さん
17/07/20 13:21:36.67 siGPhp4j.net
わざわざ隠す内容か？
952:774ワット発電中さん
17/07/20 13:29:04.17 AvSuDKE+.net
煽り目的の人のために、わざわざ書いてやる必要もない。
953:774ワット発電中さん
17/07/20 13:31:22.72 AvSuDKE+.net
あ、>>931が書くことにケチをつけるつもりはございません。どんどん書いてあげてくださいな。
954:462
17/07/20 23:12:31.84 KhXkfk6b.net
久しぶりにここに来ましたが・・・
すみません 私がアスペでした
955:774ワット発電中さん
17/07/21 00:02:26.38 Zy3u7jSR.net
>>927
GDBとJTAGが使えるのはそこそこ安いけど、8bitクラスの書き込み器とデバッガは
PICが安いと思うな。ルネもだいぶ安くなったけどな。
AVRではDRAGON使ってるが、チップを選ぶのがいまいちだ。
956:774ワット発電中さん
17/07/21 06:22:10.01 Id4VyTdC.net
PICKIT3でのデバッグは精々8bitまでだな
16bitや32bitだとデータ転送が遅すぎて非常にストレス
32bitだとICD3が必須と言っても良いくらい
ただ書くだけならどっちでもいいけど
最近はROMブートローダーが内蔵していて、
ライターを使わずとも
いろいろなペリフェラルから書けるのが主流だけど
PICはそうなってないよね
ルネサスはE1が便利
RL78からRXまで使えてPICKITみたいに遅くない
957:774ワット発電中さん
17/07/21 07:07:33.49 zbVt1CU2.net
当てずっぽうでコード修正->デバイスで実行 を繰り返す人には致命的かもな。
958:774ワット発電中さん
17/07/21 07:15:23.90 XXWA6Tt7.net
ほいで
959:774ワット発電中さん
17/07/21 07:47:23.33 30IozQ75.net
8ピンだとデバッガは難しいな。
960:774ワット発電中さん
17/07/22 01:18:08.33 TfC4hBxV.net
XC8について質問さしてください
EEPROMの0x80～0xBFの間に
A1, B1, A2, B2, ・・・ , A16, B16
という順番で値が書かれています
これを uint8_t buff[16][2] の配列に入れたいだけなんですが、どういうコードを
書くのが一番よいのでしょうか？
多分やり方はいくらでもあって例えば
for (i=0 ; i<16 ; i++) {
buff[i][0] = read_eeprom(0x80 + i*2);
buff[i][1] = read_eeprom(0x81 + i*2);
}
でも
uint8_t j=0;
for (i=0x80 ; i<0xBF ; i+=2) {
buff[j][0] = read_eeprom(i);
buff[j][1] = read_eeprom(i+1);
j++;
}
でも何の問題もないと思うんですが、XC8においてもっとも最適な記述がしりたいです
961:774ワット発電中さん
17/07/22 01:27:36.98 lvDqxJsX.net
コンパイラにアセンブルコード吐かせて研究する
962:774ワット発電中さん
17/07/22 02:26:27.39 lvDqxJsX.net
簡易的な方法として、コンパイル後のサイズが小さい方を良いと判断する
963:774ワット発電中さん
17/07/22 05:54:20.04 4G2p61XR.net
ポインタ使わないなら
// uint8_t j=0;
padr=0x80;
for (i=0 ; i<16 ; i++) {
buff[i][0] = read_eeprom(padr++);
buff[i][1] = read_eeprom(padr++);
}
964:774ワット発電中さん
17/07/22 06:55:57.72 jlfjZwz9.net
>>939
同じタイプの多ピンで開発して、8pinに移植
965:774ワット発電中さん
17/07/22 07:11:06.74 jlfjZwz9.net
>>940
コンパイラの最適化が頼りない時は
自力で最適化を行う
uint8_t *buf = &buff[0][0];
uint8_t i = 0x80;
do {
buf[0] = read_eeprom(i);
buf[1] = read_eeprom(i+1);
buf[2] = read_eeprom(i+2);
buf[3] = read_eeprom(i+3);
buf += 4;
i += 4;
} while (i =! 0xC0);
スピード優先だとこんな感じかな？
サイズ優先だとループ展開せずに以下の一行に
*buf++ = read_eeprom(i++);
スピード優先も、もしかしたらこれを複数行並べる方が速いかも
966:774ワット発電中さん
17/07/22 07:24:00.73 jlfjZwz9.net
ガチガチに最適化するなら、
コンパイラが吐く結果や時間測定結果を参考に
>>945 のループの展開(ループアンロール)は、
高速化のテクニックの基本
コードサイズとスピードどちらを優先するかで
どの程度展開するかを決める
コードキャッシュが小さい場合など、
展開し過ぎると逆に遅くなる場合があるので注意
967:774ワット発電中さん
17/07/22 07:28:39.32 jlfjZwz9.net
do while はループ先頭で条件判断を行わないので
for より速くてコンパクトになる可能性がある
ループの最後で条件分岐するのが最適で、
この形になるように導く
for だと、
最悪ループの先頭で条件分岐し、
ループの最後で先頭にジャンプ
になるので、ジャンプが増える
968:774ワット発電中さん
17/07/22 07:32:05.80 jlfjZwz9.net
>>940 の前半は
コンパイラが糞だと非常に効率が悪いコードに
read_eepromのパラメータも、
乗算と加算を馬鹿正直にやるかもしれない
buffのアドレス計算も同じ
まともなコンパイラだと、
全くそんな事は気にしなくて良いのだけど
969:774ワット発電中さん
17/07/22 07:39:03.04 jlfjZwz9.net
いろいろ書いたけど、
大したループサイズじゃないし
コードサイズも余裕があるなら
吐かれるバイナリの質よりも
見やすくて変更もしやすいコードを心がけた方が
良い場合が多い
970:774ワット発電中さん
17/07/22 08:31:34.42 jlfjZwz9.net
コンパイラの最適化の設定も忘れずに
無料版でも1段階は設定可能
971:774ワット発電中さん
17/07/22 09:49:18.31 Sb5uusv4.net
>>945
検証できないから聞きますが、buffの配列に取得した期待値がそれで代入されます？ 特定の言語処理系だからじゃなくて
スピード優先ならリテラルは敵なのでは？
スピード重視ならi＋リテラルも遅くするのでは？
forよりwhileでスピードを求めてるのに実行遅くするような演算が全部の行に入ってるのはどうなんだろ
972:774ワット発電中さん
17/07/22 09:57:48.56 lkt4oF/S.net
昔のスパコンだと極力ループさせないようにしてチューニングしてたな。
4回回す場合は、同じのを4回書く。
容易に結果が分かる数値は、直接書く。
みたいな感じ。
973:774ワット発電中さん
17/07/22 10:33:25.91 T+b5JIhr.net
>>952
それ、ループアンローリングっていうコンパイラの最適化手法の１つ。
974:774ワット発電中さん
17/07/22 10:36:28.34 qk8L++04.net
>>951
前半
多重配列のデータのならび順はC準拠であれば決まっている
後半
(さらにループを展開しない限り)演算数は最小になっている
buf, i は、提示した2通りをそれぞれ試して
速い方を選べば良い
これよりさらに最適化するなら、
吐かれるアセンブラをみたり、
速度をはかりながらやる
975:774ワット発電中さん
17/07/22 10:37:44.00 qk8L++04.net
>>952 >>953
>>946 にそのまま書いたのに無視かよ
976:774ワット発電中さん
17/07/22 10:42:20.50 qk8L++04.net
>>951
出来れば君の案を書いていただけると
部分的でも
977:774ワット発電中さん
17/07/22 11:19:20.24 H4wXH4dr.net
>>940
0x80..0xBFだと64byte。32byteのbuffに読み込んだらまずいでしょ。
978:774ワット発電中さん
17/07/22 11:21:51.99 qk8L++04.net
あ、騙された
>>945も【i != 0xA0】にしないと
979:774ワット発電中さん
17/07/22 12:32:04.12 g+wBlK1Z.net
>>957
64バイトエリアに8ビットのデータが32バイトあるつーだけ
980:774ワット発電中さん
17/07/22 12:34:47.86 g+wBlK1Z.net
>>959
と、思ったけど1ワードのデータが32個かもわからんな
981:774ワット発電中さん
17/07/22 13:03:55.42 hv1lv5ch.net
>>960
uint8_t buff[16][2]
982:774ワット発電中さん
17/07/22 14:53:17.15 H4wXH4dr.net
>>959
よく見ろ。>>940の後半のコードはまずい。
983:774ワット発電中さん
17/07/22 15:42:26.22 Jdv45tdf.net
>>940
> EEPROMの0x80～0xBFの間に
>
> A1, B1, A2, B2, ・・・ , A16, B16
>
> という順番で値が書かれています
> これを uint8_t buff[16][2] の配列に入れたいだけなんですが、
要素数が 16x2 = 32個 ということなら EEPROM のアドレス範囲が違うのでは。
> どういうコードを
> 書くのが一番よいのでしょうか？
> XC8においてもっとも最適な記述がしりたいです
・コードサイズを最小にしたい
・実行時間を最短にしたい
以上の条件が両立するとも限らないので「一番よい」「最適な記述」は一概には言えない。
単に速くしたいのなら
buff[0][0] = read_eeprom(0x80);
buff[0][1] = read_eeprom(0x81);
buff[1][0] = read_eeprom(0x82);
buff[1][1] = read_eeprom(0x83);
buff[2][0] = read_eeprom(0x84);
～略～
buff[15][1] = read_eeprom(0x9f);
こんな感じで展開すれば良いし、短くしたいのなら
uint8_t i = 31;
do {
((uint8_t*)buff)[i] = read_eeprom(0x80 + i);
} while (i--);
と書くのが良いと思う。コード生成の結果はコンパイルオプション `-S' を使用して確認するべき。
何れにしろ XC8 のコード生成効率は PRO エディションでもお世辞にも良いとは言えないのでこんなことに頭を悩ますくらいならアセンブラで書くか他のマイコンを選んだほうが精神衛生上良いだろう。
984:774ワット発電中さん
17/07/22 16:42:24.28 Jdv45tdf.net
>>963訂正:
配列アクセスよりポインタを使って
uint8_t i = 0x80;
uint8_t* pBuff = (uint8_t*)buff;
do {
*pBuff++ = read_eeprom(i);
} while (++i < 0xc0);
とした方がコードは短くなる。但し RAM の消費は増える。
985:774ワット発電中さん
17/07/22 17:18:58.45 AIsBIsxf.net
コードが短くなるって言ってる人はCのソース上での話？
>940 の質問者の意図考えたらCのソースが短くなることには何の意味もないような・・・
986:774ワット発電中さん
17/07/22 17:37:11.26 Vzk5udcC.net
eeprom使ってる時点で速度目的なら最適化とか意味なし
987:774ワット発電中さん
17/07/22 17:53:15.62 Jdv45tdf.net
>>965
XC8 前提の話だしコンパイラの出力に決まってるだろ。「XC8 のコード生成効率は～」とか書いてるの読めんの?
988:774ワット発電中さん
17/07/22 18:13:16.73 D5rDcn9S.net
xc8標準のEEPROM読書は関数ではなくマクロ展開だから
大量に命令並べるとあっという間にプログラムメモリ喰い尽くす
989:774ワット発電中さん
17/07/22 18:14:05.65 Jdv45tdf.net
>>964訂正:
uint8_t i = 31;
do {
buff[0][i] = read_eeprom(0x80 + i);
} while (i--);
とすると XC8 PRO エディションで最適化をすべて有効にした条件で2命令短くなる。
990:774ワット発電中さん
17/07/22 18:18:41.83 qk8L++04.net
30年前に戻った感じがいいね
991:774ワット発電中さん
17/07/22 18:21:15.86 Jdv45tdf.net
>>968
> xc8標準のEEPROM読書は関数ではなくマクロ展開だから
XC8 標準で read_eeprom() なんてマクロは提供されていない。
992:774ワット発電中さん
17/07/22 18:30:59.46 JhS6GSkE.net
EEPROMで便乗です。
memory.cで以下のソース
void DATAEE_WriteByte(uint16_t bAdd, uint8_t bData)
{
uint8_t GIEBitValue = INTCONbits.GIE;
EEADRH = ((bAdd >> 8) & 0x03);
EEADR = (bAdd & 0xFF);
EEDATA = bData;
EECON1bits.EEPGD = 0;
EECON1bits.CFGS = 0;
EECON1bits.WREN = 1;
INTCONbits.GIE = 0; // Disable interrupts
EECON2 = 0x55;
EECON2 = 0xAA;
EECON1bits.WR = 1;
// Wait for write to complete
while (EECON1bits.WR)
{
}
EECON1bits.WREN = 0;
INTCONbits.GIE = GIEBitValue; // restore interrupt enable
}
これを
static int use_eeprom = 0;
void DATAEE_WriteByte(uint16_t bAdd, uint8_t bData)
{
if (use_eeprom) {
use_eeprom = 0
while (EECON1bits.WR)
{
}
EECON1bits.WREN = 0;
}
EECON1bits.WREN = 0;
}
EEADRH = ((bAdd >> 8) & 0x03);
EEADR = (bAdd & 0xFF);
EEDATA = bData;
EECON1bits.EEPGD = 0;
EECON1bits.CFGS = 0;
EECON1bits.WREN = 1;
EECON2 = 0x55;
EECON2 = 0xAA;
EECON1bits.WR = 1;
use_eeprom = 1;
}
でダメ？
993:774ワット発電中さん
17/07/23 20:19:13.55 +KT2MRq9.net
>>940
こんだけレス付いてんのに返事も無しかよｗ
994:774ワット発電中さん
17/07/23 22:54:20.63 31e83Ea6.net
ネタフリzzz
995:774ワット発電中さん
17/07/24 00:51:32.16 eY/Gb/+c.net
次はあっちのスレとくっつけちゃっていいよね
996:774ワット発電中さん
17/07/24 06:01:29.60 vqg3oSsM.net
くっつけるって、どういうこと?
本スレと初心者スレでは、働きが全く違うよ。
別にするのが良いと思います。
997:774ワット発電中さん
17/07/24 06:56:44.01 suKZRfDi.net
>>975
なんで?
998:774ワット発電中さん
17/07/24 07:25:48.86 IT6WpZKq.net
ここ実は初心者に極論を投げつけてしたり顔する人達の隔離スレだから一緒にしちゃだめ
999:774ワット発電中さん
17/07/24 08:19:02.95 IgNzFJmE.net
今更PICを始めることに意味はないので自称初心者が近づいて来たら
追い払ってやるのが親切というものだろう。
1000:774ワット発電中さん
17/07/24 08:35:25.36 7Pe5TL8A.net
>>979
単機能で使う分には便利だけどね。
ラズパイとかと組み合わせて使ってる。
1001:774ワット発電中さん
17/07/24 09:38:24.90 eY/Gb/+c.net
>>979
それだ！
それが親切
1002:774ワット発電中さん
17/07/24 17:36:29.54 wwUrCVcP.net
>>979
DIPで1個当たりの価格も安いし、趣味では魅力的だと思う。
1003:774ワット発電中さん
17/07/24 22:45:55.21 QqVv7Vyk.net
>>979や>>981は、人が嫌がることがわかっていてこういうことを書く人です。
相手にしなくて良いと思います。
1004:774ワット発電中さん
17/07/25 00:15:58.93 tKUwUzEI.net
初心者がいまからPICを始めるメリットを自分の言葉で語れないから
「人が嫌がること」なんて筋違いの反応してんだなｗ
1005:774ワット発電中さん
17/07/25 05:18:06.52 sf5U2+Gj.net
自分の能力が低くて使いこなせないからといって
初心者が使いこなせないって事にはならないけどなｗｗｗ
1006:774ワット発電中さん
17/07/25 07:06:28.16 jJpgLchu.net
村上春樹を読むことにメリットはない。
村上春樹を読むことのメリットを自分の言葉で語れないだろう。
↑こういうことを書く人は、ほぼアンチ村上春樹。
こういう人と、村上春樹を読むことのメリットについて議論することは無駄。
1007:774ワット発電中さん
17/07/25 09:15:07.26 lKUXiUEH.net
今更[any words]を始めることに意味はないので自称初心者が近づいて来たら
追い払ってやるのが親切というものだろう。
1008:774ワット発電中さん
17/07/25 12:42:57.10 YQHqs/qs.net
では、PICに代わるものとは？
ブートローダー書き込み済AVR?
1009:774ワット発電中さん
17/07/25 12:51:41.66 tK/J44ou.net
変らせんな
NICと一緒に出て行くわ
1010:774ワット発電中さん
17/07/25 15:41:01.69 ob2Wxawt.net
>>970
そうだね。30年前からやってることはほとんど同じことの繰り返し。
まるでトラ技の特集のようだ。
1011:774ワット発電中さん
17/07/25 16:40:02.60 0khn/41t.net
>>989
もうネットワークつながる環境に戻ってこなくて良いよ
1012:774ワット発電中さん
17/07/25 16:50:21.48 HOMN9NtT.net
>>986
ハルキストにとって村上春樹の作品を読むことは目的だが、PICはどう言ったところで道具であり手段でしかないので目的にはならんよ。
1013:774ワット発電中さん
17/07/25 17:27:53.33 xsE2zAfR.net
学んでく過程で手段目的化はある話だと思うが、いつまでも続いてるんだよな、皆さん。
1014:774ワット発電中さん
17/07/25 17:40:18.43 tK/J44ou.net
>>991
PIC NICが一緒に行くのは
1015:774ワット発電中さん
17/07/25 21:09:54.95 jJpgLchu.net
>PICはどう言ったところで道具であり手段でしかないので目的にはならんよ。
ひとそれぞれ。
それが理解できないのは狭い。
1016:774ワット発電中さん
17/07/25 21:20:32.17 Kh17S0Eq.net
> ひとそれぞれ。
> それが理解できないのは狭い。
初心者を含む他人に勧める理屈がないのは分かったｗ
1017:774ワット発電中さん
17/07/25 21:22:59.25 jJpgLchu.net
>>996
どうせお前には最初からその結論だ。そして何を聞いてもその結論だ。
1018:774ワット発電中さん
17/07/25 21:39:15.58 GMKXcSc1.net
説明責任が果たせなくなると非難をはじめる
まるでどこやらの総理みたいだな
1019:774ワット発電中さん
17/07/25 21:49:07.08 jJpgLchu.net
あなたに説明責任を問う資格があるわけでもないし、
俺は総理でもなくて説明責任を負うわけでもないよ。
1020:774ワット発電中さん
17/07/25 21:49:43.66 jJpgLchu.net
ばかばかしい。
1021:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 78日 3時間 27分 43秒
1022:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています