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:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています