H8_SH__ルネサスマイコン総合スレ3__M32_R8C_Tiny

初心者ですが質問してもいいですか？
H8/300Hを使ってアセンブラの勉強してます。
なんですがプログラムカウンタの更新のところで躓きました。

PCは24bitのレジスタで、次に実行すべき命令のあるアドレスを指していると教えられました。
ここでよく、順次実行される場合は「＋１」されて次の命令を指し示すと言われるのですが、
この＋1⇔＋2Byteされたことでどうして次の命令のアドレスに行くのかがぴんときません。

メモリ構成で、偶数の上位バイトと奇数の下位バイトにバイト単位でアドレスを割り当てているということは調べました。
また、H8/300Hはメモリの最大構成16MBなので24bitでメモリのアドレス全域を指定できるというのは分かりました。
しかし命令というのは必ず2Byteで構成されているということでしょうか？この2Byteの内訳が分かりませんでした。

PCの挙動について、
命令を実行する際にアドレスの中の何を参照して次の命令の場所へと値を更新するのか教えてください。
よろしくお願いします。

>>290
命令は２バイト、または２の倍数の大きさになる。
そんなの命令表見ればわかるだろ。
こんなところで躓くなんて、
本質的に向いていないから違う進路目指したら？

やりたがってる奴の芽を摘むなよゴミクズ

アセンブラ勉強するなら最初に命令表見るのが普通だろ。

>PCは24bitのレジスタで、次に実行すべき命令のあるアドレスを指していると教えられました。
>ここでよく、順次実行される場合は「＋１」されて次の命令を指し示すと言われるのですが、

この教え方もおかしいね。H8/300Hなら10バイト命令とかもあるのに。

もしかすると教える側の教え方がヘタなせいで
学ぶ側が混乱させられているという、気の毒な例なのかもしれない。

>>291,293
偉そうに言うな!　お前も駆け出しの頃、わからなかったはずだ。
すでに知っているから、そういう言い方になるんだ。

やる気があってやってるやつを虐めるな。

どうもありがとうございます。
プログラミングマニュアルの命令セット一覧のどこを見ればよいのかわかりませんでしたが、
おそらくインストラクションフォーマットだと思いました。
ここに命令とアドレッシングモード毎に第１バイト、第２バイト〜と載っていたのでこれかと思いました。

例えば、「MOV.B #xx:8,Rd」の命令の場合、
アドレッシングモードがイミディエイトであり、インストラクションフォーマットでは第２バイト目がIMM（イミディエイト）となっています、
これは第１バイトと合わせて計２バイト使うためにこの命令は２バイトであるから、
メモリ上に偶数番地から２バイト分占有しているので、次の命令はPCに＋１されたアドレスを参照する。
と考えていいんでしょうか。

同様に「MOV.L #xx:32,ERd」の場合、IMMは第３バイトから32bit＝４バイト使い、
上位２バイト（命令そのものやどのレジスタであるかを表すビットパターン）と合わせて６バイト使うため、
この命令は６バイト命令であるので、PCの値には＋３＝されて次の命令のアドレスを示すと解釈しました。

これで合っているでしょうか。間違っていたらご指摘お願いします。

またちょっと疑問が生まれました。
例えば2バイト命令のとき、PCの値に＋１されたら次の奇数アドレスを示してしまわないんですか？
１バイト毎にアドレスが割り振られているということは、PCの値を＋２しないと常に偶数番地を示せないと思ったんですが。
もしかしたら命令のバイト数分だけPCがインクリメントされるので、PCの値は2の倍数だけ動くということでしょうか。

>>296での＋１と＋３のところはそれぞれ＋２と＋６になると考えるべきでしょうか。

>>290
H8ではワードアクセスは必ず偶数番地で行われる。
PCもビット０は常に'0'になっていると考えていい。
つまり、PCが「+1される」なんてことは絶対ありえない。



あなたの書き込みを最初に見たときからすごい違和感感じていたんだけど、
なんでそんなにPCの挙動にこだわるの？
書き並べた命令が（分岐でもしない限り）順に実行されると解釈して
なんの問題もないと思うんだけど。

とりあえずPCの挙動の細かいことは棚に上げておいて、
そんなことよりもっと重要な学ぶべきことが他にあると思う。

私が>>291で「本質的に向いていないから」と書いたのも
そのPCに異常にこだわるセンスがちょっと？？？に感じられたので。


#H8じゃなくSHならPCの挙動に敏感に反応するのもわかるんだけどね。
#「遅延スロットでPC相対アドレッシングを使ったら、
#実際にアクセスされる番地はどこか？」みたいな面倒くさい問題になるから。

>>298

学生か新入社員研修かなんかで、レポート書けとか言われてるんじゃないの？

向いていないなんて一言言うまえに、勘違いのポイントを教えてあげれば良いでしょう。
所詮、ここは２chだけどさ。

>>297

大抵のことは、マニュアルを読めば書いてあるよ。
質問されてるようなPCのことはさほど書いてないけど、
通常使う分にはそんなこと考える必要がないというのが、その理由。

>>290
あなたに「PCが+1される」と教えたその人は、
一体どのような方でしょうか？ 職場の先輩？それとも単なる友人？
H8のアセンブラを少しでもかじった人なら「PCが+1される」
なんてこと絶対ないことわかっているはずですが。


あるいはその人はH8の命令コード群をＣ言語で

short int H8_instructions[]

みたいに捉えているのかもしれません。
short int の配列ならば+1で実際にはポインタが２進むから
一見つじつまが合っているように見えますが、
アセンブラとＣ言語は別物です。Ｃ言語の変な先入観を
アセンブラの世界に持ち込むといっそう混乱します。
（Ｃ言語は「高級アセンブラ」などと呼ばれているから
勘違いする人が多いみたいですが、はっきり言って別物です）

他人の些細な疑問なんか捻り潰して、自分色に調教したいの（はーと）

速く、半導体から身を引け！

赤字を作る部門はやめろ！

PC が +1 されるとか教えてくれた人って、PIC使いじゃね？

PC が +1
が＋１アセンブラ行なら問題ないのでは？
単位が明示されていないので

自己弁護のために口数が多くなる男の人って・・・

特に誰もそんなことは教えてないんじゃないか。

>290を見ると教科書かなんかで見たCPUというものの動作の抽象的な説明を
H8に当てはめて自分でそう考えただけに見える。

なので、PC+1は単に次の命令を指すというだけの意味で、具体的に何バイトかとかは
問題にしていないんだよ、で終わりだと思う。

いや、命令とかオペランドの長さについても書いてるからPCのアドレスが
何バイト飛ぶかまで意識してるだろ。

＞自己弁護のために口数が多くなる男の人って・・・
自己弁護のために口数が多くなる女よりはマシだな

＞PCは24bitのレジスタで、次に実行すべき命令のあるアドレスを指していると教えられました。
＞ここでよく、順次実行される場合は「＋１」されて次の命令を指し示すと言われるのですが

教えてくれた人によーく聞いてみるのが一番だと思うわ

ID:woJiMDXh
何この人みっともない

爺さんだろ。
古きよき時代の俺の豊富な知識を見ろ！て感じじゃないかね。

豊富な知識というか、俺はそこまでは辿り着いたんだぞ！　お前には無理
とか言いたいのでわ。

いや、最初のレスが批判されて
さすがに自分でも悪いと思ったのか
何回もフォローするんだけど
どんどんドツボにはまっていくパターン

>あなたの書き込みを最初に見たときからすごい違和感感じていたんだけど、
>なんでそんなにPCの挙動にこだわるの？
と思うなら、PCに拘らなくても良い理由を教えてあげるといいね。
質問者本人の着目点は「PCの値」あるいは「PCの増え方」なんだから、
それを考えることを全否定されれば、困ってしまうわな。

>爺さんだろ。
いや、もっと若いような気がするな。
若いヤツは、自分の知識が高い事が前面に出てしまって、
駆け出し/初心者を小馬鹿にする傾向があると思う。
一方、年寄り/じいさんは、人間的にも落ち着いているので
「あ〜、なるほど、そういう所に目が行ってしまうんだ」と
達観すると思うなぁ。

俺を叩くのに必死な奴はいっぱいいるけど、
>>290に有意義なアドバイスをしてあげる人は誰もいないのね。

>>315
>>309

>>315
>>309に答えが出ている。

おーい！ゆのきーーーまさあきーーーーー

相変わらずIBM-PC互換機使ってるかい？

H8のPCが命令実行後に+1バイトならエミュレータ作りも楽できたのに

>>319
1byte256個の命令にレジスタからアドレスまで入れろと申すか
せめてlongword固定とか…

で、＋１(命令)だろうなあ。
ttp://cai.int-univ.com/sugsi/Lecture/CPU/4/ProgRegs.html

アドレスと即値の扱いをSHみたいにすれば何とか入らんか?

すげー効率悪くなると思うが。

現在H8/3052FでA/D・D/Aポートを用いてループ計算をさせてディジタル制御をしています．
外部電圧を取得，計算，出力（オペアンプをかませて正負）　繰り返し…

ただ，１ループで１msを切れません．できれば100usくらいまで高速化したいなと…

それで秋月のAKI-SH2/1045FのRISC（CPU周波数は低いが４倍という謳い文句に惹かれて）かSH7144F（もしくはSH7125FTiny）を使おうかと検討しています．
SH2にした理由は単にキットが見つけれなかったからです．
できればもっと高速なSH3くらいを検討したいと考えていますが，手ごろなキットはないでしょうか？

A/D・D/Aポートと開発ツールがついていることが必須事項です…

SHボードといえば、アルハープロジェクトでしょう。やっぱり。
http://www.apnet.co.jp/

>>323
ご紹介ありがとうございます．

SH-3 SH7709S StarterKitを検討します．

通常SHシリーズにはA/D・D/Aコンバータは内蔵されているのでしょうか？

>>324
>通常SHシリーズにはA/D・D/Aコンバータは内蔵されているのでしょうか？

そんなことまで人に聞くのか?　自分で調べようという気はないの?
データシートダウンロードして、見れば1発でわかるじゃん。

変換時間は気にしないのかしら？

どの程度の処理しているか分からないけど・・
H8クラスでC言語だとfloat/double型の演算を多用するとかなり遅くなるよ。
int/long型を使用した固定小数点で置き換えれば高速化できるかも。

１ループ100us程度の処理ならアセンブラで書けばいいのに

>>325
すみません，おっしゃるとおりです…
調べてみます．

>>327
一応過去にint中心になるように書き換えていますがそれでもなかなか…
6ms→4ms程度でした．

>>128
その手もありますね…

ただ，C++からの移植でして，アセンブラに直すほど余裕がないのです．
RS232Cからパラメータの送受信をPCと行う必要もありますし…
PC（Core2　2GHｚで実行して0.5us程度）で実行していた時代もありますが，
OpenGLとの連携を行うと描画にCPUパワーが取られてしまい処理が遅くなったため制御部分のみマイコン化した次第です．

>>325
H8と同じチャンネル数，分解能でありました．
申し訳ありませんでした．

>>329
富豪環境でいいのなら (大学の研究?) もう1台PC用意して
InfiBandとかMyrinet等の低レイテンシネットで接続
MPIかなんかでノード間通信すれば良かんべ

>>329
助言ありがとうございます．
はい，大学の研究です．
PCは何台も余っているのでしようと思えば可能ですし，たしかにパソコンでの実行が手軽に高速化できるのですが
OSが介入する
（例えばウインドウをドラッグするときも，その瞬間に一瞬だけCPUパワーがおち，制御が止まります…）
ことで一瞬でも処理が落ちると制御している機器が破損するという…
そういう意味でOSの介入がないマイコンへの移行した経緯があります．

>>330
IOが少なくていいんなら、SH7125お勧め。

アルファプロジェクトのSH/Tiny開発キット
ttp://www.apnet.co.jp/product/tiny/index.html

>>330

ありがとうございます．
>>322に書いたように一応候補としてあげてはいますが，
25MHｚのH8から50MHzのSH2へ移行するよりも200MHz弱のSH3の方が処理が早いかと思いまして…

内部構造の違いから大した差が出ない・200MHｚは冗長であると言う場合は考え直します．

>>334
レスアンカー(>>n)は発言相手を指すようにしてね。

一台ぽっきりの設備ならコストを気にせずCPUパワーで
逃げる手もありと思うよ。SH3でもSH4でも好きなのを選べばいいよ。

思い切ってループの中身（長いの？）をさらしてくれると盛り上がるぞ〜

C++の移植というのが足かせだけど、
問題をクリアできるなら、FPGAやCPLDでやれば、
デバイスは安いし、マイコンより高速処理。

>>335
アンカーミスしました（汗
すみません…

結局はSH7144Fにしようかという話にまとまりました…
が，25MHz→50MHｚで体感的に変わるのでしょうか．

ループ内は少々お待ちください

かなり変わるんじゃないかね
特にキャッシュがヒットしまくれば

http://kissho.xii.jp/1/src/1jyou77413.c.html

DLP：denshi

すごく汚いソースです…
マイコン初心者状態で書き上げたものなのでご了承ください…

>>338
SH7144はキャッシュはないんじゃないか？

外部アクセスしなければ、キャッシュの必要もないけど。

読む気にならなかったから、さらっと見ただけで見当違いとは思うけど、シリアル送信を割り込みにしたら？
シリアルの送信って遅いし。

>>339
float変数でもないのに、小数点計算をしているみたいですけど、
もしかしてこれは革新的技術でしょうか?

main関数のwhile(1)を見ただけだけどかなり改良の余地がありそうだね。
暗黙の型変換だらけでランタイム呼び出しが激しそう。

ルネサスのコンパイラならとりあえずdouble型をfloat型として扱うオプションを
有効にすると1/3ぐらいには改善するかも。だまって"0.49"みたいな数値定数を
書くとdouble型扱いになってしまうからね。

逆アセンブラのコードを見ながらできるだけランタイムが呼び出されないように
記述して丁寧に整数化すれば100usぐらいいくんじゃないかな？

SHでどれぐらい速くなるか知りたければシミュレータを使ってネックになりそうな
部分のステート数を調べてクロックの逆数を掛ければ大体わかるよ。
H8と比べてみるといい。

H8のばあいdoubleよりfloatのほうが早いの？と基本的なことを聞いてみる

そうです

float型は32bit長だからH8のCPUレジスタのそのまま納まってランタイム内でもシフト、
加減算などの操作が割と楽に行える。double型になるとそうもいかずオーバーヘッドが大きくなる傾向。

SHなら以下に処理時間が載っているけどH8はないねぇ。
http://documentation.renesas.com/jpn/products/tool/apn/rjj06j0023_shc_libbench_an.pdf

自分が使う用途でdoubleが必要な計算ってそう多くないし基本floatを使ったほうが良いのか
勉強になりました

ad_data=ad_data*0.49;
は
ad_data*=49;
ad_data/=100;
にするとか

100us / 24MHz = 2400state

2400もあれば、今のまま3052でも　いけそうな気がしない?

>>342-343
ありがとうございます．
ご指摘のとおり不思議な書き方をしていたようです．
ほかにもdoubleである必要がない部分などが多いようです…

コンパイラはGCCデベロッパライトです．
オプションにあるか調べてみます．

>>348
大変ありがたいです．
指摘されて気づきました…これはおかしいですね．
基本的にはやはりint化したほうが早いのでしょうか？
それともfloat程度であればあまり差はなくなるのでしょうか．


組込みはこういう部分でかなりの差が出るものだと痛感いたしました．
皆様の助言非常にありがたくいただいております．

これだからCしか出来ない奴はｗ

>>351
申し訳ありませんorz

>>348
シフト演算ができるチップなら2^nの方が早くなるんじゃないかと妄想してみる

大サービス。
たとえば(18.531*0.234+1.23)/3.14≒1.772を固定小数点で処理すると

// 変数はすべてint型
a = 18.531 * (1 << 10);
b = 0.234 * (1 << 10);
c = 1.23 * (1 << 10);
d = 3.14 * (1 << 10);
// ここから計算
y = ((long)a * (long)b) >> 10; // 乗算
y += c; // 加算
y = ((long)y << 10) / d; // 除算
// 結果 y = 1811となり1.767 * (1 << 10)の近似値が得られる

"10"はQと呼ばれる小数部のbit長で分解能を保ちながら演算結果が
オーバーフローしないように選択。上記はQ5.10形式でH8のint型だと
整数部5bit、小数部10bit及び符号に1bitの計16bitとなる。表現範囲は±32。
処理速度についてはCPUによるから何とも言えんがfloat型とは
比較にならないぐらい速いよ。ただしH8の場合は「バレルシフタ」が
ないので劇速という訳にはいかないけど。

floatの計算は、遅くなるよ。490で掛けて100で割ると、
びっくりするくらい速くなる。

だいたいイメージだけど、こんな感じ

　計算の早い順に
　　　・unsigned char
　　　・unsigned int
　　　　　　　(ていうか、そのマイコンの持っている汎用レジスタのbit幅)
　　　　　　　(H8/3052データシートの2-4ページの汎用レジスタの図が
　　　　　　　　16bitになっているので、たぶん16bitの計算が
　　　　　　　　一番得意なんだと予想される。)
　　　・unsigned long
　　　・signed int
　　　・signed long int
　　　・float
　　　・double

http://documentation.renesas.com/jpn/products/mpumcu/rjj09b0335_3052bhm.pdf
　　具体的には、上記H8/3052データシートの　巻末付録-19ページ以降に記載の
　　「命令実行ステート数」による。
　　計算するなら、Cで書いてコンパイルした結果のアセンブラ命令を、
　　この巻末資料から探しだし、命令ステート数を求め、加算したものが
　　実際に必要なclock数になる。
　　例えば、かけ算とわり算は、22clockもかかる。
　　これがfloatだと、さらにドンと時間がかかる。

　　上記の内容は、違っているかも知れないので、詳しい人フォロー願います。

signedとunsignedで明確に速度が変わる？
普段あまり意識してなかったけど今後明示しておいた方が良いか

>>354
大変勉強になります．
このあたりの知識が皆無でしたので勉強してきます．

>>355
計算結果が小数点になるとしても490かけて100で割ったほうがお得なのですね！
このあたりがGCCがどのように判断しているかがいまいちわかりません．
longで宣言した変数に代入される計算結果が少数の場合，自動的にfloatやらdoubleになってしまうのでしょうか？
それともintのまま小数点以下も2進数として格納されるのでしょうか？
無知で申し訳ありません．

今日は勉強になるな

>>356
普通は同じだろう。
ランタイム呼ぶような状況だとunsignedの方が微妙に速くなる事もあるが。

>>353
計算済みの10bit幅のテーブル参照の方が早いかも？

>>357
小数点を含む計算は、処理系依存ということになっています。
つまり「gccの言う通りに、あ・た・り・や・ん・せ・い」ということです。
でも、どのように考えたかを知る方法はあります。
簡単です、はき出されたアセンブラソースを見るのです。
「え〜、こんな長い結果なんて、わかんない」と思うでしょうが、やり方1つです。
とても短いプログラムで試してみれば、すぐわかります。
void main(){
　　unsigned int a = 123;
　　unsigned int b;

　　b = a * 0.49;　　　// 小数使用

//　　b = a * 49;　　　　// 整数で処理
//　　b = b / 100;
}
という感じです。コンパイラが0.49をどのように扱うのかがポイントですね。

b=a*0.49;
有効数字上
b=a*(1÷2 - 1÷2^7 - 1÷2^9)　（＝＞（）内は約0.49023）
ってことでいいなら
b=(a>>1)-(a>>7)-(a>>9);
っていう具合にシフトと減算だけになるから乗除算しなくて良い分
速いかな？

入力か出力のオペアンプに可変抵抗をつけてゲイン調整して
掛け算処理を減らそうぜ

数値定数に小数点をつけるとdoubleと認識されるよ。

ad_data=ad_data*0.49 だと

最初にad_dataの値がdoubleに型変換されて
その結果と0.49のdouble同士の乗算が実行されて
その結果がint型に型変換されてad_dataに代入される

合計3回のランタイム呼び出しが発生してしまうはず。
乗算はもちろん型変換もかなり時間がかかるので
組込系ではこういった記述は避けたほうがよい。
FPUとか搭載してるCPUなら問題はないけどね。

(参考)http://www.kusa.ac.jp/~kajiura/c/data/newpage1.htm

型変換が気になる場合には、明示的にキャストするとか
数値定数にサフィックスを付けるようにした方がよい

ttp://www.geocities.jp/KY_webid/c/019.html

たすけてくだしあ･･･

H8/300Hってクロック入力(EXTAL)と出力(Φ)の位相関係が規定されていませんが、
デューティ補正回路とかのせいでフラフラ変動するのでしょうか？

規定すると動作保証しなきゃいけなくなるから、規定しないはず。
同社保証するってことは検査項目が増えて結局はコストにはねかえる。
多分設計するときにも考慮にいれていないから、やれっていわれても難しいんだと思うよ。
デューティ補正回路は教えてもらったことあるけどそんなにふらふらするもんじゃ無いと思ったよ。
普通のユーザーはそんな規定いらないもん。
なんで必要なの？
Φ基準でタイミング計算すればいいんじゃない？

システムの上位からのクロックでマイコン部を動作させるのですが、位相関係が決まっていれば
システム側でH8の信号を非同期信号として扱わなくてもいいかなと期待したのです。

やはり規定されてないようなのでマイコン部の信号は非同期扱いで繋ぐことにします。
どうも有難うございました。

ルネサス？？？

逝ってよし、潰れろ！

とりあえずサムチョンが潰れてからでいいけどね

>368
非同期として取り扱った方が楽なような気が、、、

>369
ルネサスじゃないもん！
ルネサスに知っている人は多いけどね。

>>369
ルネサスが潰れたら日本の機能性LSIの技術基盤が崩壊する。
エレクトロニクス技術からすると、繰り返し回路のDRAMより、機能性LSIのほうがよほど重要

フォートランの授業みたいなテクだなぁ。

今でもFORTRANって授業で習うの?

ビットでずらして近似値にするという手法は教科書をみて思い出しました．

とりあえずところどころ訂正しました…
が，おそらく出力値が切り捨てられて0しか出力しないようになってしまいました…

型宣言などが原因のようです…

http://kissho.xii.jp/1/src/1jyou77916.c.html
DLP：denshi

>>375

> da0*=(0xFF/5)/1000;
(0xFF/5)/1000
整数で計算すれば0にしかならないよ。

デバッガとかシミュレータは使わないの？
演算の各ステップごとに値を確認してやった方がいいんじゃないか？

H8でつかえるシミュレータやデバッガでなにかいいものある？

>>375
基本はintとかlong型に統一した上で式をばらして
b = a * 49;
b = b / 100;
みたいな計算に置き換えていかないと。

変数 * 変数の場合は
c = (a * b) / 100
というスタイルになってくる。

一般に処理が重たくなる除算"/"も使いたくないから
普通はシフト演算子">>"の出番になる。
H8の場合はCPUに除算命令があってバレルシフト命令が
ないからどっちが有利か一概には言えないけど。

別にアセンブラで書く必要はなくてCでの記述がどういった
CPUの命令を引き出しているか見極めるのがポイント。
H8クラスだとこの辺の理解がないと高速化は難しいかも。

できるだけ速いSHにしたほうがいいような気もするがまあガンバッテ。

ものすごく大雑把にソース見たけど。。。
基本、除算はチョー遅いよ？
式整理して、乗算が出てくるように、もしくは除算をまとめるとかしないと。
あと、関係なさそうだけどインデントとか、大域変数が酷い。。。

>>376
そのあたりの計算は小数点の乗算にならないように>>348を参考にしましたが…
この場合，やはり型宣言をintからfloatにしないと整数化されますね…

>>377
自分も探しています．
通常はC++Builderを使用しているので変数も監視しながらステップ実行をしたりできるのですが，
GCCデベロッパではやり方がいまいち…

>>378
非常に勉強になります．
ただ，int や　long int では49をかけて100で割った場合，小数点以下が切り捨てになりませんか？

なにか大きな勘違いをしているような気がしてきました…

>>379
本当に申し訳ありません．
タブでのインデントに統一するように直しておきます．
2人でソースをいじっていたため統一されていなかったようです．
グローバル変数に関してももう少しわかりやすいように，また使いすぎないように気をつけます．

>>380
C++Builder使ってるなら、演算部分だけ抜き出して、C++Builderで確認できるんじゃないか？
整数型のデータサイズは注意しないといけないけど。

＞int や　long int では49をかけて100で割った場合，小数点以下が切り捨てになりませんか？
だったら，どうやったら整数演算で小数点以下の値が扱えるか考えてみたら？
筆算やった経験くらいあるんでしょ？

>>380
固定小数演算については正規化とかそういうので調べてみると何かヒントがあると思うよ。

例) 3.1875 -> 110011(0x33)って表現する

ようは数値の入力部分で定数倍(2^nが楽？)して、演算中はその定数倍のまま演算して
最終的な演算結果を出力するところで定数で割り算すれば良いでそ。

演算途中で定数で割り算してたら固定小数演算じゃなくて整数演算だよね。

＞演算途中で定数で割り算してたら固定小数演算じゃなくて整数演算だよね。
んなこたーない．

>>377
？
HEWにシミュレータ付いてると思うけど？
試しにルネサスCコンパイラでやってみればどうでしょうか？

>>382
四捨五入したいなら、
100で割る前に幾つか足してやればいいのかな
下２桁が
00--49までは切り捨て
50--99までなら、切り上げたい
なら、もうわかるよね。

ayを求める式を整数で演算できるように式を分解するところからやらないと

みんなで教えてるんだかイジってるんだかｗ

暇だったので。あってるかどうか知らんが・・

ay = 0.0074 * ay_2 + 59.11 * (ad_data - ad_data0) + 0.5 * ay_1
da0 = -30.192 - 0.15096 * ad_data - 0.009435 * ay

固定小数点の解説記事
http://focus.tij.co.jp/jp/dsp/docs/dspcontent.tsp?contentId=53940

どうしても高速小数点演算が必要な時はどうする？
�@FPU付CPUを使う
�AFreescaleの16bitDSP(fraction機能)を使う
�B32bit(SH等)でQ15固定で四則演算関数をアセンブラで作る
�C16bit(H8等)でスケーリング管理して整数演算
�Dその他

�@楽勝だけどコストがメチャ高になる
�ACPUが限定される
�Cコストは低いがマンドクサイし時間が経つと忘れる

というわけで�Bにすることが多い。一度関数作ってしまうと、あとはOVFだけ注意すれば
スケーリング全く気にしなくていいし。
「32bitなぞ許さん」と客に言われたらブツブツ言いながら�Cにする。
その代わり自衛手段として、スケーリング管理表を作成し、コード中にもコメントをしっかり書いておく。

みんなどうしてる？他にいい方法があればおしえて栗。

なぜDSPはFreescaleだけなんだよ？アナデバやTIの方がメジャーだろ。

TI：C2000,C5000,C6000
http://focus.tij.co.jp/jp/general/docs/gencontent.tsp?contentId=49154

アナデバ：Blackfin,SHARC
http://www.analog.com/embedded-processing-dsp/processors/jp/index.html

最近は3$以下のDSPもあるぞ。
http://focus.tij.co.jp/jp/docs/prod/folders/print/tms320f28023.html#pricingpackaging

>>391

DMULS.L R4, R5
STS MACH, R1
STS MACL, R0
RTS
XTRCT R1, R0

�Bの乗算てこんな感じ？これならよく使う。

Freescaleは「fraction機能」とやらに特徴が有りそうだね。
多分使うこと無いから調べる気がおきないけど。

このスレ的には「RX」の普及に期待するべきかな。
低コストでFPUがついてくれば応用範囲も広がるし。
ピッコロなんかに負けないでもらいたいなあ。

パソコンで演算をチェック＆最適化してから、組み込むとか？

>>393
>>�Bの乗算てこんな感じ？
そうそう、そんな感じ。実際は計算の前にもう少しやっとくことがあるけどね。
「符号1bit + 整数15bit + 小数16bit」を"fixpnt"型で定義して使ってる。

>>393
R32Cじゃ、あかんの

ルネサス系のマイコンは設計してるやつがクソ！

早く撤退しろ！携帯事業みたいに。

三菱は、白物家電で十分だ。

NECエレの方ですね、休日なのにお疲れ様です。

Nも椅子取りゲームに参加だから必死なのか。

Ｎかー。78K0だったかな、一回だけ使ったことあるな。
H8に比べるといろいろめどかったな。
安いけど。

NECお得意のエミュレーションモードつければいいじゃん
NECモード、日立モード、三菱モード、ルネサスモード

intelモード希望

クアッドコアですね、わかりま

マジな話、デュアルコアなら既にあるよ

三菱コアと日立コアのがか？ｗ

コードモーフィング技術で各プロセッサをエミュレートするんですね。

こてこてのべたべたの日本人　大和魂

　　　　　　柚木正章

終身雇用で老後も安泰。

>>407
柚木正章って誰なの？

>>408

会社に問い合わせてね。

クソ！ルネサスマイコン
特に、ゆのき
やせろよ。

質問があります。教えて頂けないでしょうか?
H8/3067をCで使っています。ビットフィールドが使いたくて、構造体を書いたのですが、
今ひとつよくわかりません。例えば、bit5〜bit0にLCDが接続してあるとします。
struct poo {
　　unsigned char dummy　:2;
　　unsigned char E　　　:1;
　　unsigned char RS　　:1;
　　unsigned char DATA　:4;
} BIT;
#define LCD (*(volatile struct poo *)0x00FFFFE)　// アドレスは適当です。
のように定義して、LCDをI/Oポート(8bit出力)につないで、
LCD.BIT.DATA = 0x0eなどとして、うまく動きました。

ところが、これを常時16bitアクセスの領域(バンク)につなぎ変えて
以下のように合計を16bitになるようにしても、まったく動きません。
struct poo {
　　unsigned char dummy　:10;
　　unsigned char E　　　:1;
　　unsigned char RS　　:1;
　　unsigned char DATA　:4;
} BIT;
さらに
struct poo {
　　union {
　　　　unsigned int WORD;
　　　　struct {
　　　　　　unsigned char dummy1　:8;
　　　　　　unsigned char dummy2　:2;
　　　　　　unsigned char E　　　:1;
　　　　　　unsigned char RS　　:1;
　　　　　　unsigned char DATA　:4;
　　　　} BIT;
　　} AAA
};
#define LCD (*(volatile struct poo *)0x00400000)　　と書いたときは、
LCD.AAA.BIT.DATA = 0x0c; だと動かないですが、
LCD.AAA.WORD = 0x000c; のように16bit代入だと動きます。
ビットフィールドでだめなのに、16bit代入だとOkなのはなぜでしょうか?

そいや、ビットフィールドでアクセスするときの上位下位って気にしたことないな。
コンパイラのバグはさすがにないか。

>>411
>16bit代入だと動きます。
ということからして、&= |= するときに、データが読み込めていない、に10bit

コンパイル結果がアセンブリ言語でどうなっているか確認してみよう
おそらく、下位8bitだけバイトアクセスしてるんじゃないか

#define LCD (*(volatile unsigned int *)0x00400000)
struct poo val16;
val16.AAA.BIT.DATA = 0xc;
LCD = val16.AAA.WORD;

のように
いったん変数val16でビット操作してから一括で書き出したらいいんじゃないか?

>>414
でもそれだと彼の目的にそぐわないんじゃないか?
もともと構造体で1bit操作をしたいんだろうから

・コンパイル結果がどう実装されるか規定されていない
・ハード的な構成によってソフト的な実装が制限される
の2つがあるなら、アセンブラレベルで最終的な実装を確認して、必要に応じて
「許される実装」にコンパイルされるようなソースに変えるか、そもそも
Cを使わないしか選択肢がないよね。

0x00400000番地がwrite-onlyになってるんじゃないの？

H8のIICなんですが、下のようにデータをライトしたあと
送信完了待ちが必要です。これはどの程度待てばよいのでしょうか？
OUTPORT(ICDRT, dt); /* データを送信する */
while(TESTBIT(ICSR, TEND) != 1) { /* 送信完了待ち */
}

また下のようにwaitをいれた場合、実際はどの程度待つことに
なるでしょうか？CLKは20MHzです。
INCとCMPとBLEの3ステップ×1/20MHz ×1000？
while(P_IIC2.ICSR.BIT.TDRE == 0){
cnt++;
if(cnt > 1000){
return 100;
}
}

下はミックス表示です。
while(P_IIC2.ICSR.BIT.RDRF == 0){
BRA @H'0FB2:8
cnt++;
INC.W #1,E0
if(cnt > 1000){
CMP.W #H'03E8,E0
BLE @H'0FB2:8
return 100;
MOV.W #H'0064,R0
BRA @H'0FF6:8
MOV.B @H'FFF74C:16,R0L
BLD.B #5,R0L
BCC @H'0FA4:8
}
}

411です。みなさん、いろいろとありがとうございました。

結論からいいますと「お陰様で出来ました!」です。原因は、私の無知でした。
原因　1.Cコンパイラの吐き出すコードが、構造体の共用体でWordで書くとバスアクセスもWordアクセスになるが、
　　　　1bitメンバーをアクセスすると、Byteアクセスになってしまう。
　　　2.同じ偶数番地指定でも、WordアクセスとByteアクセスで、データbusのLSB位置が異なるのを知らなかった私。
上記2つの同時原因により、WordとByteでデータバスの異なる線に信号が出力されるため、でした。
みなさんの指摘がズバリ的中でした。みなさんの教えにより、アセンブラコードを見ながら、
なんとか解決できました。ありがとうございました。

一つ教えてください。
なぜ、データバスの上位が偶数で、下位が奇数に決められているのでしょうか?　下の図のような感じです。

アクセス　　　　　　上８ｂｉｔ（Ｈ８のＨＷＲ＝Ｌ）　　　　　　　　　　　下８ｂｉｔ（Ｈ８のＬＷＲ＝Ｌ）
ＷＯＲＤ（偶）１５　１４　１３　１２　１１　１０　０９　０８　０７　０６　０５　０４　０３　０２　０１　００
ＢＹＴＥ（偶）　７　　６　　５　　４　　３　　２　　１　　０　−−　−−　−−　−−　−−　−−　−−　−−
ＢＹＴＥ（奇）−−　−−　−−　−−　−−　−−　−−　−−　　７　　６　　５　　４　　３　　２　　１　　０

例えば、8bitメモリを、WORDアクセスする時のメモリの取られ方は、
「奇数番地が上位、偶数番地が下位の連続2番地のセット」で1WORDを表現する、と思っていました。
そうすれば、常に偶数で扱えば良いし、LSBがいつも右端に来るし、調子が良いと思うのです。

ビッグエンディアン / リトルエンディアン でぐぐれば
少しは無知が薄まると思うよ

確かにインテルのCPUはずっとリトルエンディアンだが
それが絶対的正解というわけでもない

ビッグエンディアンの利点がよくわからない。
まさかダンプが見やすいなんて時代錯誤なことじゃないよな。
大抵の処理は下位からやるのが自然だと思うんだが。

利点/欠点ではなくて単に決めの問題。どっちが有利/不利ということはない。
たとえばTCP/IPではビッグエンディアンが標準通信プロトコル(ネットワークオーダー)

411です。みなさん、いろいろとありがとうございます。
エンディアンは知っています。卵の形状から来る話ですよね。
調べてみたら、H8はBigEndianなんですね。初めて知りました。(恥ずかし)
そのせいで、このようになってしまうのですね。納得しました。
ありがとうございました。

数値格納目的の場合は、ビッグ/リトルどちらでも良いと思いますが、
今回のように、ハード接続が絡んでくると、
LSBが常に同じ位置の方が良いのかな、と思います。

ちなみに、今回の私のようなケースでは、どのようにするのが、正しい道なのでしょうか?
A)LCDは、HWR側接続、偶数アドレスで構造体を書いて、バイトアクセスする。
B)LCDは、LWR側接続、奇数アドレスで構造体を書いて、バイトアクセスする。
C)好みの問題

411です。たびたびすみません。
考えてみると、構造体の1bitメンバの読み書きをしたときでも、
アセンブラがWORDアクセスしてくれれば、他の16bitのものと同じように
全部偶数アドレスで記述できます。

1bitメンバの読み書きでもbyteアクセスにならずにWORDアクセスにアセンブルしてくれる
そんな記述はできるものなのでしょうか?

どうして ワードサイズの一時変数を作り、bit操作をその一時変数に行ってから
ワード単位でI/Oに書くという発想は出てこないの?
マクロでラッパ書けば見た目だけはすっきりするぞ。

つーか、ハードウェア構成によってはすべてのアクセスは
必ずワード単位って指定で、バイトアクセスすると誤動作するなんてよくある。
(単なるByteEnable対応のサボリ)

>>425
ありがとうございます。

>ワード単位でI/Oに書くという発想は出てこないの?
はい、最後の手段として考えています。
が、日立のI/Oヘッダファイルでは、○○.○○.○○ = 1;とか書けばスグに値が変わるので、
僕の追加した外部バスI/Oも、そのように統一したいと思うんです。
僕の変なこだわりだけなんですが。すみません。

>マクロでラッパ書けば見た目だけはすっきりするぞ。
おっしゃる通り、ソースは見た目が半分以上重要で、視線移動の少ない方が、判読性が高いと思います。

if( a==12 ){
　　b=5;
} else {
　　b=8;
}　　　　　　　と、縦に何行にも渡って長く書くよりも、

if( a==12 ){ b=5; } else { b=8; }　

と1行で書いた方が、が判読性が良いと思います。特に同じパターンがの場合には、

　　　if( a==12 ){ b=5; } else { b=1; }
else if( a==16 ){ b=6; } else { b=0; }
else if( a==19 ){ b=8; } else { b=0; }
else if( a==25 ){ b=3; } else { b=1; }
のほうが、「a値によってb値を変えてるんだな」と、ビジュアル的で良いと思っています。

b = ( a==12 )? 5 : 1;
b = ( a==16 )? 6 : 0;
b = ( a==19 )? 8 : 0;
b = ( a==25 )? 3 : 1;　　も好きで、多用しています。


>マクロでラッパ書けば
この場合のマクロとは、defineのことでしょうか?
よろしければ、教えてください。

LCDを外部メモリ空間でアクセスするのと
内蔵ポートでアクセスするのと同じに考えていいんかいな？

LCDだったら内蔵ポートでしょう普通。
でもI/Oが不足したときには、外部busでやらないわけでもない。

E,RSはH8のどこにつながってるんだろうか？

>マクロでラッパ書けば
たとえば

#define LCD (*(volatile struct poo *)0x00FFFFE)　// アドレスは適当です。
#define set_data(val) \
do { tempword.AAA.BIT.DATA=(val);LCD.AAA.WORD=tempword.AAA.WORD;} while(0)

static struct poo tempword;

func() {
　set_data(0x0c);
}

> 僕の追加した外部バスI/Oも、そのように統一したいと思うんです。
> 僕の変なこだわりだけなんですが。すみません。
超くだらないな
こんな自己満足のためにCコンパイラにイチャモンつけるのか…

>>428
俺は基本外部バスだなあ。
制御信号をソフトで面倒見るのはめんどくせえ。

シングルチップで使わんといかん場合は仕方なくI/Oでがんばるが。

>>430
ありがとうございます。素晴らしいです。なんと言うか最高です。
そんな記述が出来たんですね。知りませんでした。

さきほど久しぶりに林晴比古さんの「プリプロセッサ・パワー」を読み直しましたが、
do{ }while(0)の書き方は載っていませんでした。スゴイです。
{}で複数行書けること、do〜while(0)でそれを実行する方法など、感激です。

すみません、一つ教えてください。
1) #define set_data(val) \
2) do { tempword.AAA.BIT.DATA=(val);LCD.AAA.WORD=tempword.AAA.WORD;} while(0)

1)の「\」は、何を意味する記号でしょうか?　定義の継続改行信号でしょうか?
1)の右に続けて2)を書いて1行にしても良いですよね?
2)の行で、do { temp...とスペースが入っていますが、ここにスペースが入っても良いのでしょうか?
今の今まで、詰めて書かないといけないと思っていました。

411です。実際にやってみました。コンパイルOK、動作OKでした。ありがとうございました。

しかし、残念なことに、
　　do {　　　　　　　　　　　　　　　　\　//
　　　　tempword.AAA.BIT.DATA=(val);　　\　// 文字データのセット
　　　　LCD.AAA.WORD=tempword.AAA.WORD;　\　// データのword書き出し
　　} while(0)
が、エラーになってしまいました。
もちろんコメントなしで、行末が\+CRLFならエラーは出ないのですが、
行末が\　<何か>　CRLFだと、エラーになってしまいます。
ぜひとも行コメントが付けたいので、現在どうするか思案中です。
しかしながら、おかげさまで、関数へのover headの無い高速動作を保ちつつ、
ソースが格段に見やすくなりました。本当にありがとうございました。

　　do {　　　　　　　　　　　　　　/* */　　\
　　　　tempword.AAA.BIT.DATA=(val);　　/* 文字データのセット */ \
　　　　LCD.AAA.WORD=tempword.AAA.WORD;　/* データのword書き出し */ \
　　} while(0)

とでもしとけばいいんじゃないの？

定義にそんなに凝ったことないから、気になってググってみた

−−−
defineディレクティブの行末のバックスラッシュは、改行文字をエスケープしてdefineディレクティブの継続を意味する。
文字列リテラルまたは文字リテラルのバックスラッシュは、次の文字をエスケープする。
−−−

…へぇボタン。

>>424
何で、誰もまじめに教えてあげないの？
オレがKYなのか。

struct poo {
　　unsigned char dummy　:10;
　　unsigned char E　　　:1;
　　unsigned char RS　　:1;
　　unsigned char DATA　:4;
} BIT;

は、

struct poo {
　　unsigned short dummy　:10;
　　unsigned short E　　　:1;
　　unsigned short RS　　:1;
　　unsigned short DATA　:4;
} BIT;

と書けばいい。

>>436
そんな「今のバージョンではたまたま偶然望んだコードが出るだけ」の記述は、やっぱりまずいだろ。
コンパイラのリビジョンが変わるたびにアセンブラレベルで検証なんて、したくないだろ？

いや、きわどいところはせざるを得ないだろう。
ファームウェアはどうしてもトリッキーな処理とか
必要だったりするし。

所詮人の作ったコンパイラ。リビジョンどころかプログラム作る度に検証しなくては製品には使えない。

ポータビリティ性が期待できないなら、あえてビットフィールド使う意味ないだろ
マクロでどうにかしたほうが現実的

全然挙動の違う仕様にバージョンアップされて、コンパイラメーカーからも説明なくて、喧嘩するんよねー…賠償問題含めて

>>436の記述で、charとshortで何が違って来るのでしょうか?
:1; とすることで、bitですよ、という意味になるんではないかと思います。

>>442
ビット操作する対象のデータ幅が変わるんでねかな。たぶんコンパイラ依存で。
ビット操作命令を発効するにしても、8bitか16bitかでアドレス指定も発行命令も違うわけだし。

てかＨ８Ｓには16bitのビット操作ないから、それっぽい結果を返す16bitアクセスなコードを吐いてくれるんでなかろか。

charとshortどころか、ビットフィールド使ってる時点で可搬性ないよ。
ビットフィールドのビット順は規定されてないからコンパイラによって違うし、
同じコンパイラでもバージョンが変わってビット順が変わった例すらある。
外部とやりとりするデータにビットフィールドを使うのは、使わなくてもよい労力を
わざわざ使うに等しいよ。

いままで秋月の3069のDRAM乗ってる奴でデバッグしてて
これからH8/3694とか使うことになったんだけどE8aって買う価値ある？

>>441
だから自動車屋は、バージョン固定してる。
特定バージョンに対して、バグ対策とか機能向上をコンパイラ屋に
やらせているんだよ。

>>437
ここが、charじゃ、Windows上でもまともに動かないんだし、
自分がコーディングするときは、ビットフィールドの使用を
回避できても、ルネのヘッダとかにもガンガン使われてるんだ
から、こういう文法機能の存在は知っていたほうが良いのでは。

SH3-7709Sを使用しています。

今度AD変換機能を使おうと思っていますが質問があります。

入力したい電圧は+-10Vです。しかし、SH3はMAX3.3+0.3Vの3.6Vまでしか入力電圧を許容しません。
よってOPアンプで1/3のゲインにして入力しようと考えています。

-0〜10Vは通常通りの反転増幅回路（100ｋΩと300ｋΩ、また、バランスをとるためにアースへは75Ω）を使用します。
しかし、+0〜10Vはどのようにすべきでしょうか？
反転増幅（1/3ゲイン）をスルーし、その後反転増幅（1/1ゲイン）にすべきなのか、トランジスタ1つにすべきなのか…
非反転増幅ですとゲインが1以上しか設定できませんし…

プログラムと違って電子回路は実践型でなかなか飲み込めません。どうかお助けください。

ちなみにアナログVccも3.3Vまでしかダメなのでしょうか？

あ、トランジスタは電流の増幅でした…





orz

opAmp使うならレベルシフトもすればいいじゃないか
倍率 -0.16倍、オフセット+1.65V にすれば
-10V〜+10V が +3.25V〜+0.05Vに変換されるぞ

opAmpがあまっててそれを使うならいいけど
わざわざこの目的のためにopAmp載せるんなら
-10Vから+10Vまで取り込める外部A/D載せた方がいいかもな

>>447
>ルネのヘッダとかにもガンガン使われてるんだから
それ、コンパイラに同梱されてる分じゃなくて独立して配布されてるもの？
独立配布でも使われてるなら安心だな。そうでなければ「ヨソでも使われてるから」
なんて気休めにもならないが。

>ここが、charじゃ、Windows上でもまともに動かないんだし
それはビットフィールドの問題か？ｗ

つMISRA-C

H8/300Htinyの3664/3694より高機能なタイプや
300L SLPシリーズを個人向けに単品で売ってるところってあります？

DigiKey.jp で普通に買えませんか?

>>450

あ、その手がありました！！

100ｋΩと16ｋΩにして356オペアンプのオフセットピン1と5の印加電圧をずらして1.65V出るようにするのですね！
これなら1つで済む！

デメリットといえば入力の分解能が荒くなる…ってことかな。
考えていたのが+側と-側で別のチャンネルを使うことだったので、予定より2倍ほど荒くなりますね。
ただ、果たしてその荒さがどう出るかは疑問なので実際に試してみます。

>>455
そろそろスレ違い過ぎかも知れないが、ものすごい誤解なので看過できずレス
356のpin1とpin5っていきなり言って通じると思うな! まぁわかったけど…
balance端子はVos調節用。そこをいじってもレベルシフトできないよ

たとえば 反転増幅回路においてIN+端子をGNDではなく
Voffボルトの定電圧源を接続すると
　Vout=Voff-(R2/R1)(Vin-Voff)
になる

>>455
こんなんでどうでしょ?
http://mcnc.hp.infoseek.co.jp/cgi-bin/img-box/img20090612132704.png

OP AMPのBAL端子は、外部信号で出力をずらす目的ではなくて、
自分自身のズレをゼロに調整するためのものなので、
そのピンを使うのはよくないと思う。

>デメリットといえば入力の分解能が荒くなる…ってことかな。
分解能が粗くなるってどういうことでしょう。
±入力のA/Dコンバータでなく、+入力ADを使う以上、offsetするだけなら、
分解能は落ちないと思う。
分解能という視点でADコンバータを選ぶと、入力振幅の広大なものはなく、
多くのADが±1V入力とかになるから、結局　抵抗分圧を使う以外に手はなかろうと思われる。
±10V→(分圧)→0と3.3V→buffer→A/Dコンバータ

>>457

有力な情報ありがとうございます！
というか手書きが素敵すぎます！
分解能は…

例えば+側で1チャンネル毎に10ビットの分解能があります．

+0〜10ＶをＡＮ0ピン入力，-10〜0Ｖを反転させ，ＡＮ1ピン入力
（もちろんそれぞれ利得を1/3に）
こうすれば合計で20ビット分の分解能が得られるかと思っていました．

オフセットすると1チャンネルで-10Ｖ〜+10Ｖ（計20Ｖ分）を10ビットで分解することになるかと…

>>458
1つの信号の上半分と下半分を別々のADに担当挿せるということですか?
それは難しいでしょう。0.0000Vのとき両者はどのような変換値になると
思いますか?　
もしアナログ技術がおありなら、上下分担方式をやってみてください。

単調性のないAD変換はダメだと思います。
1個のADで、全域をカバーさせたほうが良いと思います。
それよりは、24bitのADを外部につないで、H8からシリアルアクセスのほうが
高精度で取り込めます。

×　もしアナログ技術がおありなら、上下分担方式をやってみてください。
○　もしアナログ技術がおありなら、やってみてください。

×　それよりは、24bitのADを外部につないで、H8からシリアルアクセスのほうが
○　　　　　　　24bitのADを外部につないで、H8からシリアルアクセスのほうが

上下分担でやると
しっかり調整しないと+方向から０になった場合と
-方向から０になった場合で値が異なるという悲惨なことになるよ
実体験として

>>459

一応動いているのがH8で0〜6Vは100Ωの抵抗をかませてスルー，-6〜0Vは反転増幅（利得1/1）でスルーしています．
回路的に+10〜-10Vが出力される端子からオペアンプの-入力端子とスルーしてマイコンへ行く端子に分岐しているだけです．
おそらく+側ではオペアンプ直前の100ｋΩよりマイコンへの100Ωの方が電流が流れやすく，そちらへ．
-側が入るとマイコンからは流れずにオペアンプへと流れ反転しマイコンへ．

無知で申し訳ない；；

すみません，訂正です．
勘違いでした．

>おそらく+側ではオペアンプ直前の100ｋΩよりマイコンへの100Ωの方が電流が流れやすく，そちらへ．
>-側が入るとマイコンからは流れずにオペアンプへと流れ反転しマイコンへ．

+電源が入力されれば反転増幅回路では-電源になり，ビットが0になり，スルーした回路ではそのままの電圧を検知
逆に-電源が入力されればスルーした回路ではマイコン側で-電源となりビットが0に，反転増幅回路では+電源になりその電圧を検知．

プログラム上で反転増幅に接続されたポートのビットが0ならスルー回路の電圧を採用，逆ならしかり．
というようにしています．

>>459さんのツェナーを使う方法で試そうと思います．
変換式もデータシートで見ましたが1.24という数字がネックなのでボリュームで調整なのですね．
適正な抵抗値も…とりあえず調べてみます．

>>458
> 例えば+側で1チャンネル毎に10ビットの分解能があります．
> +0〜10ＶをＡＮ0ピン入力，-10〜0Ｖを反転させ，ＡＮ1ピン入力
> （もちろんそれぞれ利得を1/3に）
> こうすれば合計で20ビット分の分解能が得られるかと思っていました．

合計して20ビットなんてバカなことはない (笑)
そんな小細工しても得られる分解能は11ビットにすぎないぞ

>>462 >>463
スルーとか流れやすいとかビットが0とか±10Vなのか±6Vなのかイマイチ不明だが
H8の回路はかなりやばいことになっているぞ

アナログ入力端子の電圧範囲の絶対定格は -0.3V〜+AVcc+0.3V
これから外れた電圧を入れたらデバイスが壊れるとルネサスは言っている

AN1はVinと100Ω通して接続、AN2は反転増幅器出力に接続と仮定すると
Vinが+3Vの時 AN1には+3V、AN2には-3Vが印加 →AN2が絶対定格違反
Vinが-3Vの時 AN1には-3V、AN2には+3Vが印加 →AN1が絶対定格違反

おそらくアナログ入力端子の保護ダイオードにどばどば電流が流れている状態
動いているように見えても、いつ壊れてもおかしくない状態にある

柚木正章はオタク

>>462
悪いけど、あなたの説明はさっぱり理解できない。
原因は、句読点が無いのと、使用している言葉が適切ではないことです。

>一応動いているのがH8で0〜6Vは100Ωの抵抗をかませてスルー，
これは、どこで話が切れているの?
「一応動いているのが、H8で0〜6Vは100Ωの抵抗をかませてスルー」なのか
「一応動いているのがH8で、0〜6Vは100Ωの抵抗をかませてスルー」なのかさっぱりわからない。
H8以外のマイコンでも試しているけど、その中で運良く動いているのがH8ということ?

>0〜6Vは100Ωの抵抗をかませてスルー，
>-6〜0Vは反転増幅（利得1/1）でスルーしています．
スルースルーって盛んに出てくるけど、スルーって何?　どんな状態のこと?　

あと、何で6Vなの? 10Vという話じゃなかった?

こんなに長い文章なのに、句読点が無いので何が何を説明しているのか、さっぱりわからない。
　　　　　↓
>回路的に+10〜-10Vが出力される端子からオペアンプの-入力端子とスルーしてマイコンへ行く端子に分岐しているだけです．
>おそらく+側ではオペアンプ直前の100ｋΩよりマイコンへの100Ωの方が電流が流れやすく，そちらへ．
>-側が入るとマイコンからは流れずにオペアンプへと流れ反転しマイコンへ．

>無知で申し訳ない；；
そんなこと言わなくてもいいから、他人にわかるように書き直してください。
文字だけで説明するなら、こんな感じだとわかりやすいです。

・信号源→100Ω→H8のAN0
・信号源→100kΩ→OP AMP(-)→H8のAN1
・OP AMP(-)→100Ω→OP AMP出力
・OP AMP出力→H8のAN2

なんか問題解決アプローチがコピペ厨っぽいなぁ
　ソフトウェアでとにかく動いているコードを見つけ出してきてコピペ。
　コード全体を読んで動作原理を理解することなく、斜め読みして見つけた
　それっぽい値を書き換えて、自分の目的に合致させるような手法。

ソフトでもダメダメなやり方だけど、それをそのまま回路設計に持ち込んだ感じだ。
　opAmpのデータシートに載ってる反転増幅回路の例をそのままコピー。
　この抵抗とこの抵抗は増幅比を決める抵抗だから、最後に残った可変抵抗が
　出力をレベルシフトできる調整箇所だろうと根拠もなくあたりをつけて試みる。

ソフトならコンパイルエラーとかランタイムエラー出してくれるけど
ハードは黙って壊れて終わりだよ。

もうちょっと基本原理を学んでほしい。

＞もうちょっと基本原理を学んでほしい

電気・電子は理工系の落ちこぼれが選択する学科なんだからそんなこと言っても無理

習うより慣れろ
考えるな、感じろ
自分を信じて

こうですよね、よくわかります。

先日の構造体エンディアン男です。
すみません、また教えてください。
条件は先日と同じで、H8の16bitアクセスに設定したメモリ空間に、ラッチICを接続してデータを保持するような場合です。
また、Cの上で構造体により、そのラッチICの特定bit、例えばD00(LSB)をon/offするという場合です。
CPUからWORD Accessの場合は、0x0001とすれば、目的のbitをon制御でき、バスとデータがイメージ通りになります。
しかし、構造体にしてAAA.BIT.B0=1;と記述すると、コンパイラはByteアクセスの命令を吐きます。(具体的にはBSETとBCLR)
このとき、下位byteをアクセスするのかと思ったら、上位byteがアクセスされ、データバス16本のD08が1になります。
これでは私の目的のbitにはなりません。
これは、H8がBigEndienということに起因することを教わりました。
図にすると、こんな感じです。

　　　　　　　HWR　　　　　　　　　　　　　　　　LWR
15　14　13　12　11　10　09　08　-　07　06　05　04　03　02　01　00　←WORDアクセスした場合
07　06　05　04　03　02　01　00　　　　　　　　　　　　　　　　　　　←偶数番地、Byteアクセス
　　　　　　　　　　　　　　　　　　15　14　13　12　11　10　09　08　←奇数番地、Byteアクセス

そこで質問ですが、上記のような場合にデータバスのD00にアクセスしたかったら、
奇数番地に0x01としてアクセスすれば良いのでしょうか?

>>470にある現象は変だ。ありえない。

> 　　　　　　　HWR　　　　　　　　　　　　　　　　LWR
> 15　14　13　12　11　10　09　08　-　07　06　05　04　03　02　01　00　←WORDアクセスした場合
> 07　06　05　04　03　02　01　00　　　　　　　　　　　　　　　　　　　←偶数番地、Byteアクセス
> 　　　　　　　　　　　　　　　　　　15　14　13　12　11　10　09　08　←奇数番地、Byteアクセス

こうなっていると判断した材料は何か、生データを示してほしい。

ロジアナで外部バスをすべて観察したわけではなさそうだ。
すごい誤解があって、現象を誤って捕らえているとしか思えない。
ロジアナがあるならアドレスバス/データバス/制御線すべてキャプチャしてみよう。

例えば、あなたが以前書いたように

struct poo {
　　unsigned char dummy　:2;
　　unsigned char E　　　:1;
　　unsigned char RS　　:1;
　　unsigned char DATA　:4;
} BIT;

こう書いたとするとメモリはunsigned char単位でアクセスされる。
これをもし、

struct poo {
　　unsigned int dummy　:2;
　　unsigned int E　　　:1;
　　unsigned int RS　　:1;
　　unsigned int DATA　:4;
} BIT;

こう書けば、メモリはunsigned int単位でアクセスされる。

ついでにビットフィールドは、実際にメモリに割り当てられる
ビットの順序はコンパイラの好きに任されているので、必ずしも
あなたが書いた順序と一致するとは限らない。

従って、IOのレジスタなどハードの特定のビットをアクセスするために
使うのは適当ではない。

>>472
そういうことは既に指摘されている。
それにもかかわらず、いまだに同じことをやっているのは聞く耳を持たない人という事だから放っておけばいい。

そういや、統合環境（ＨＥＷとかＫＰＩＴとか）が最初に吐くＩＯ定義はビットフィールドだけど
あれは、その統合環境の中のコンパイラ狙い撃ちだから成立する、ってことでいいのかしら

>>471
ありがとうございます。
>こうなっていると判断した材料は何か、生データを示してほしい。
生データと言われても、すぐに定時できませんが、以下の通りです。
・H8のバスアクセスの図で、16bitアクセスの、
　　word access時　→　/HWR=LでD15〜D08に、　/LWR=LでD07〜D00
　　byte acces (偶数番地)　→　/HWR=LでD15〜D08に、　/LWR=HでD=H(Hiz)
　　byte acces (奇数番地)　→　/HWR=HでD=H(Hi_z)に、　/LWR=LでD07〜D00　でした。
・Cのソースでword/byte(even)/byte(odd)の1bit構造体メンバをアクセスしたときの　アセンブラ展開でも
　そのようになっていることを確認しました。
・ロジックアナライザを使って、/CS, /HWR, /LWR, D15-D00、A15-A00を観測して、
上記項目と同様なことを確認しました。
生データを示せと言われても、困ります。測定し直して波形を提示するということですか?
それはちょっとできません。すみません。

>>472
ありがとうございます。
　　(略)
> こう書いたとするとメモリはunsigned char単位でアクセスされる。
　　(略)
> struct poo {
> 　　unsigned int dummy　:2;
> 　　unsigned int E　　　:1;
> 　　unsigned int RS　　:1;
> 　　unsigned int DATA　:4;
> } BIT;
> こう書けば、メモリはunsigned int単位でアクセスされる。
はい、この書き方にはその後やっていて気づきまして、実験済みです。
ただ、私のcompilerでは、上記のようにintと書いてもbyte accsessになります。
しかし、accessされるaddressが　期待する位置のaddressにセットされることを
突き止められました。ありがとうございます。

> ついでにビットフィールドは、実際にメモリに割り当てられる
> ビットの順序はコンパイラの好きに任されているので、必ずしも
> あなたが書いた順序と一致するとは限らない。
はい、これについてはcompilerの設定で、bit filed orderを上から配置/下から配置の設定があり、
上から配置に設定してあります。(でないと日立のheader fileが使えないためです)

> 従って、IOのレジスタなどハードの特定のビットをアクセスするために
> 使うのは適当ではない。
　　重要な情報を、ありがとうございます。この件を少し教えてください。
　　適当でないということは、世の中一般的に、外部バスでI/Oをaccsessするときは、
・構造体で1bit定義でon/offをせず、必ず16bitでword accsessする
・byte accsess空間に設定して、byte accessでお使いということでしょうか?
　　　　(/CS かつ address(奇数) かつ /HWR の時にD15〜D08でやりとり)

それは繋ぐ対象と制御回路次第では。

どちらかでしかアクセス出来ない対象、あるいは制御回路ならそれでアクセスするしかない。
どちらでもアクセスできる対象かつ制御回路ならどちらでも好きなようにすればいい。
ライトオンリで読み出せない対象、あるいは制御回路ならビットフィールドは使えない。
読み出せるが、読み出すと状態が変わってしまう対象についてもビットフィールドの使用は要注意。

>>476
夜遅いのに、ありがとうございます。

>どちらでもアクセスできる対象かつ制御回路ならどちらでも好きなようにすればいい。
この「どちら」というのは「構造体でないword accsess　と　bitfield」のことでよいでしょうか。
でしたら、今回の私の回路はこれに該当します。
どちらの方法でも可能なので、どちらにしようか悩んでしまうというのが本当の所ですが、
日立のI/O header fileが、P1.DR.BIT.B0=1;とかできるものですから、
私の追加した回路も同じ指示が可能なほうが、設計思想としてよいかな?と思っています。
別の要因もあり　先日、バスの窓口としてCPLDを挿入しました。

>ライトオンリで読み出せない対象、あるいは制御回路ならビットフィールドは使えない。
>読み出せるが、読み出すと状態が変わってしまう対象についてもビットフィールドの使用は要注意。
上記2つのお話は、
bit fieldのアクセスを、&=　や　|=　を使うアセンブラコードを吐いてしまうとマズイ、ということでしょうか?
もしそうでしたら、compilerのアセンブラコードを見てみると　BSETとBCLR を使っているようで、
読んで変更して再書込ではないようでしたので大丈夫かなと思っています。
ただ、しかし自分自身でも　AAA.BIT.data &= 0x0f; などとやってしまうので、
念のため &= |= も可能なように双方向バス対応に改造し、readができるようにしてあります。

>>476さんの　>どちらでもアクセスできる対象かつ制御回路ならどちらでも好きなようにすればいい。
というお話を聞いて、私の方法でも　さほど変なやり方ではないようで、安心しました。
どうもありがとうございました。

>>この「どちら」というのは「構造体でないword accsess　と　bitfield」のことでよいでしょうか。

バイトアクセスとワードアクセスという意味です。


>>BSETとBCLR を使っているようで、読んで変更して再書込ではない

いやいやいや、H8を含めて世の中の普通のCPUはバスに繋がっているデバイスに
ビット単位でのアクセスすることなんて出来ない。

BSETやBCLRという命令自体がまさにその、1バイト読み込んで、その中の対象の1ビットだけ変更し、
1バイト書き戻す、という処理を1命令で行うものだよ。
ま、読めるならいいけど。

> 　　　　　　　HWR　　　　　　　　　　　　　　　　LWR
> 15　14　13　12　11　10　09　08　-　07　06　05　04　03　02　01　00　←WORDアクセスした場合
> 07　06　05　04　03　02　01　00　　　　　　　　　　　　　　　　　　　←偶数番地、Byteアクセス
> 　　　　　　　　　　　　　　　　　　15　14　13　12　11　10　09　08　←奇数番地、Byteアクセス

上と下 全然違うだろ?

> ・H8のバスアクセスの図で、16bitアクセスの、
> 　　word access時　→　/HWR=LでD15〜D08に、　/LWR=LでD07〜D00
> 　　byte acces (偶数番地)　→　/HWR=LでD15〜D08に、　/LWR=HでD=H(Hiz)
> 　　byte acces (奇数番地)　→　/HWR=HでD=H(Hi_z)に、　/LWR=LでD07〜D00　でした。

自分で違うこと書いているのがわかっていないのか?
もちろん下が正しい

ロジアナでHiZを動確認したのだろう?
11111111を出力しているかも知れないじゃないか(笑

それに、BSETやBCLRの動作をロジアナで確認していたら
読んでから書き戻していることがわかるはずなのだが

>>478, >>479
> BSETやBCLRという命令自体がまさにその、1バイト読み込んで、その中の対象の1ビットだけ変更し、
> 1バイト書き戻す、という処理を1命令で行うものだよ。

> それに、BSETやBCLRの動作をロジアナで確認していたら
> 読んでから書き戻していることがわかるはずなのだが

ありがとうございます。
今確認したら、仰る通り「read modify write」でした。すみません。反省です。
波形確認したら、ちゃんとRD→WR→RD→WRなどとやっています。
http://mcnc.hp.infoseek.co.jp/cgi-bin/img-box/img20090615120623.png
また、H8のマニュアルにも実行ステート=8となっていました。8ステートかかるのも頷けます。

今の今まで、BSET BCLRは
・事前readなしに一方的にそのbitだけにset resetできる
・なのでとても高速に実行できる
などと思っていました。バカでした→私。

もし1bit単位でバスの読み書きができるのならば、
・WR信号線が16bit分存在するか、または
・word書込でもbyte書込でも、何某かの方法で他のbitの情報がわかっている
でないと事前readなしで書込むなんて、できないですね。
なるほど、納得しました。教えていただき、ありがとうございました。

「BSET or BCLR≠1bit単位」となると、テンポラリの16bit変数に構造体を定義して、
それに対して1bit操作し、
バスアクセスは、常時word accessした方がすっきりしていて、よいですね。

もう少し考え直して、プログラム改造したいと思います。
指摘いただき、ありがとうございました。大変感謝いたします。
次回もぜひ叱咤をお願いいたします。

これだからCしか出来ない奴はｗ

結局のところ
いままでビット操作で誤動作していた理由は、エンディアンの問題ではなく
リード対応してないI/Oに対してビット操作していたからなのでしょうか?

417で指摘されてるね

>>482
いえ、違います。read modfy writeは始めから考えていましたので、
当初よりreadは出来ていました。
エンディアンにより番地が違っていたこと、
構造体の1bit操作でword accessするものだと勘違いしていたこと、
などが理由です。

>>484 それは変だな

バイトリードとバイト書込みに正しく対応していたら
エンディアンの問題は出ないはずだ

ビッグエンディアンの場合
> 　　word access時　→　/HWR=LでD15〜D08に、　/LWR=LでD07〜D00
> 　　byte acces (偶数番地)　→　/HWR=LでD15〜D08に、　/LWR=HでD=H(Hiz)
> 　　byte acces (奇数番地)　→　/HWR=HでD=H(Hi_z)に、　/LWR=LでD07〜D00

リトルエンディアンの場合 (もしモードがあれば)
> 　　word access時　→　/HWR=LでD15〜D08に、　/LWR=LでD07〜D00
> 　　byte acces (偶数番地)　→　/HWR=HでD=H(Hi_z)に、　/LWR=LでD07〜D00
> 　　byte acces (奇数番地)　→　/HWR=LでD15〜D08に、　/LWR=HでD=H(Hiz)
ってだけの話

ワードアクセスの時D15-D08だったものが、バイトアクセスでD07-D00に出たりはしない

>>485
こういうことです。
・H8を外部I/O機器をつないだ空間を16bitアクセス空間に設定した。
・H8がビッグエンディアンとは知らない。リトルエンディアンだと思っていた。
・というか16bit空間に設定したのだから、常時word accessされると思っていた。
　だから、下位bit(D00)に機器を接続していた。
・16bitアクセスだからword access時もbyte access時も常に偶数番地で指定しないといけない、と考え、
　bit fieldを偶数番地で定義していた。
・構造体のbit order の上から/下からは知っていて、上からに設定していた。
・構造体の1bitアクセスが、BSET/BCLRに展開されることを知らなかった。しかもそれらの命令がbyteアクセスになると知らなかった。

です。てか、なんで自分自身のまとめを書いているのか・・・・

共用体を使って
struct qoo {
　　union {
　　　　unsigned int WORD;
　　　　struct {
　　　　　　unsigned char dummy:12;
　　　　　　unsigned char B3　 :1;
　　　　　　unsigned char B2　 :1;
　　　　　　unsigned char B1　 :1;
　　　　　　unsigned char B0　 :1;
　　　　} BIT;
　　} AAA
};
#define QOO (*(volatile struct qoo *)0x00400000)

QOO.AAA.BIT.B0 = 1;

って書いたんじゃないの?

>>486
あ なんとなく 斜め上の思考が理解できた

>>470 の
> しかし、構造体にしてAAA.BIT.B0=1;と記述すると
でいう構造体が 8bitしかない構造体だったってこと??

つーか>>470読んでまさか8bitの構造体だったとは想像もつかなかった
そりゃバイト アクセスするだろ
アドレスが偶数なら上位8bitになるだろ
何の不思議もない

しかし疑問も残る。なぜ16bitのサイズの構造体にしなかったのか…

なんか、こっちが不安になってきた。

>>487 unsigned char dummy:12;

>>411 unsigned char dummy　:10;

こんな行を通すコンパイラがあるのか？

16bit/8bitの構造体の書き分け方を知らなかったんです。

　　　　struct {
　　　　　　unsigned char dummy:12;　　←これらの数字の合計が8を超えると
　　　　　　unsigned char B3　 :1;　　　　wordアクセスしてくれると思っていたんです。
　　　　　　unsigned char B2　 :1;
　　　　　　unsigned char B1　 :1;
　　　　　　unsigned char B0　 :1;
　　　　} BIT;
　　　　　　　　　　　↑
　　　　　　　　　日立のI/O header fileにcharと書いてあったので、
　　　　　　　　　charと書くものだと思っていました。
　　　　　　　　　intも書けるなどとは考えもしませんでした。
　　　　　　　　　またcharとintと書き分けると、どのようになるのか
　　　　　　　　　知らなかったんです。ていうか考えもしませんでした。
　　　　　　　　　すべては、bit数の合計でwordアクセス、byteアクセスをcompilerが
　　　　　　　　　自動的にやってくれると思っていたんです。
　　　　　　　　　　それまでも、構造体は何度も使っていましたが、
　　　　　　　　　RAM上だけの構造体だったので、上位下位とかは全然関係無かったんです。

実際、手持ちのC言語教本で、:1; と char int の2つの要素の意味や
それらの組み合わせで何が起こるか書かれたものは見つかりませんでした。

>>487
>って書いたんじゃないの?
いえ、共用体は使いませんでした。その理由は、ユニオンかける毎に変数名が長くなって見にくくなると考えたためです。
理想は、AAA.BBB = 1;程度にしたいんです。AAA.BBB.CCC.DDD=1;とかは、何がなんだか.....。

> ワード単位で0x0001と書くとOKなのに
> それをビットフィールドで AAA.BIT.B0=1; と書くとNGでした
> どうしてなんでしょう?

こんな相談で、実はビットフィールド構造体のサイズが16bitじゃなかったとは
お釈迦様でも見抜けない。

見た目をよくするためには、動作が変わっても構わないという思想が理解できない。
ソースの見栄えのよさなんて動作に影響がない範囲で努力すべきものじゃないの?
変数名を短くするために、動作が変わったら意味がない。

変数名を短くしたいなら変な小細工しないで普通にマクロを使えばよい。

＞実際、手持ちのC言語教本で、:1; と char int の2つの要素の意味や
とりあえずこのあたりとかは持っておくと良いかと
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

＞unsigned char dummy:12;
これをgccにかけるとwidth of 'dummy' exceeds its type.といって叱られる

The expression that specifies the width of a bit-field shall be an integer constant
expression with a nonnegative value that does not exceed the width of an object of the
type that would be specified were the colon and expression omitted. If the value is zero,
the declaration shall have no declarator.
とか
A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed
int, unsigned int, or some other implementation-defined type.

＞CPUからWORD Accessの場合は、0x0001とすれば、目的のbitをon制御でき、バスとデータがイメージ通りになります。
機器をD[7:0]につないだならそれでOK

＞しかし、構造体にしてAAA.BIT.B0=1;と記述すると、コンパイラはByteアクセスの命令を吐きます。(具体的にはBSETとBCLR)
これもとりあえずOK（B0ビットが正しくアクセスできれば良い）

＞このとき、下位byteをアクセスするのかと思ったら、上位byteがアクセスされ、データバス16本のD08が1になります。
ということはやっぱりB0は上位ビット側（偶数番地側）に割り付けられていて
dummyは下位ビット側（奇数番地側）に割り付けられたか、文法上おかしいって
いうんで無視されちゃった（本当なら酷い話だ・・）んじゃないの？
あるいは構造体自体が奇数番地から割り付けられているとか

>>491
>見た目をよくするためには、動作が変わっても構わないという思想が理解できない。
私、見た目という言葉を使ってしまいましたか?　だったらそれは適切では無かったです。すみません。

「わかりやすさ」というか、「パッと見て動作がわかる記述」という意味です。
それについては、>>426に書きました。
見てわかるソースが書きたいと思うんです。人様に見せるということでなく、自分で1ヶ月後、
半年後、1年後に見て動作が分かり易い、正しく思い出せる、というのが目的です。
本当は、Cの記述よりも、回路図で示すのがベストではないかと考えています。
(実際には回路図では書けませんが)　例えば、
ifやswitchなどは、回路図記号でいうところの「セレクタスイッチ」に相当すると思います。
回路図は、読むよりも先に見ることを行い「ははーん、こんなことやってんだな」と
動作がビジュアルでわかります。
詳細の動きはその後に、線のつながりを1本1本追うことで理解できます。
ところが、マイコンソースではそれを文字で表現する必要がありますから
どうしてもわかりにくいものになってしまいます。無理もありません。
でも、なんとか自分にとって分かり易い(正しく思い出せる)ソース書く要件として、
分かり易い変数名は、その重要な位置におります。短いから良いという訳でもなくて
長い方が良い場合もあります。あるいは、a, b, とか抽象度を上げることで、テンポラリ
的に意味を持たせることもできると思うのです。

>ソースの見栄えのよさなんて動作に影響がない範囲で努力すべきものじゃないの?
>変数名を短くするために、動作が変わったら意味がない。
私の言い方が見た目のみのような言い方をしてしまったようです。すみません。
もちろん、動作が1番です。で、同じ動作なら、上記のように「正しく思い出せる表記」
がしたい、ということです。すみません。

>>492
本の紹介、ありがとうございました。検討したいと思います。
＞unsigned char dummy:12;
これをgccにかけるとwidth of 'dummy' exceeds its type.といって叱られる
はい、私のcompilerでも怒られます。書き込むときには頭で思い出しながら文章を書いたので、
何も考えずに書いた=誤記だと思います。すみません。

＞このとき、下位byteをアクセスするのかと思ったら、上位byteがアクセスされ、データバス16本のD08が1になります。
(略)
あるいは構造体自体が奇数番地から割り付けられているとか
これらも何も、私の無知さに起因することでした。訳もわからず「結果オーライ」で
やってきて、基礎が不十分なものですから、ちょっと変わったことをするだけで、
ワケがわからなくて慌ててしまいました。(今までmode=7ばかりで、外部busモードは初めて使いました)

今回調べた結果で、次のようなことがわかりました。みなさんには釈迦に説法だと思いますが、
他山の石にしてもらえれば、と思い以下に記します。

共通
#define AAA (*(volatile struct poo *)0x400000)

記述A　メンバーをcharで宣言、bit数の合計を8
　struct poo{　　　　　　　　　　　　　　　　　　　　結果
　　unsigned char dum :5;　　　　　　　　　　番地→　　　　0000　　　　　　　　0001
　　unsigned char C　 :1;　　　　　　　　　　内容→　・・・・・ＣＢＡ　　・・・・・・・・
　　unsigned char B　 :1;　　　　　　　　　　番地→　　　　0002　　　　　　　　0003
　　unsigned char A　 :1;　　　　　　　　　　内容→　・・・・・・・・　　・・・・・・・・
　};

記述B　メンバーをcharで宣言、bit数の合計を16
　struct poo{　　　　　　　　　　　　　　　　　　　　結果
　　unsigned char dum :13;　　　　　　　　　　番地→　　　　0000　　　　　　　　0001
　　unsigned char C　 :1;　　　　　　　　　　内容→　・・・・・・・・　　・・・・・・・・
　　unsigned char B　 :1;　　　　　　　　　　番地→　　　　0002　　　　　　　　0003
　　unsigned char A　 :1;　　　　　　　　　　内容→　ＣＢＡ・・・・・　　・・・・・・・・
　};

記述C　メンバーをintで宣言、bit数の合計を8
　struct poo{　　　　　　　　　　　　　　　　　　　　結果
　　unsigned int dum :5;　　　　　　　　　　番地→　　　　0000　　　　　　　　0001
　　unsigned int C　 :1;　　　　　　　　　　内容→　・・・・・ＣＢＡ　　・・・・・・・・
　　unsigned int B　 :1;　　　　　　　　　　番地→　　　　0002　　　　　　　　0003
　　unsigned int A　 :1;　　　　　　　　　　内容→　・・・・・・・・　　・・・・・・・・
　};

記述D　メンバーをintで宣言、bit数の合計を16
　struct poo{　　　　　　　　　　　　　　　　　　　　結果
　　unsigned int dum :13;　　　　　　　　　　番地→　　　　0000　　　　　　　　0001
　　unsigned int C　 :1;　　　　　　　　　　内容→　・・・・・・・・　　・・・・・ＣＢＡ
　　unsigned int B　 :1;　　　　　　　　　　番地→　　　　0002　　　　　　　　0003
　　unsigned int A　 :1;　　　　　　　　　　内容→　・・・・・・・・　　・・・・・・・・
　};
記述Dの結果が出て、初めてint/charの意味、:1;の意味がわかりました。

連投すみません。これで最後です。

記述E　メンバーをintで宣言、bit数の合計を16
　struct poo{　　　　　　　　　　　　　　　　　　　　結果
　　unsigned int dum1:5;　　　　　　　　　　番地→　　　　0000　　　　　　　　0001
　　unsigned int F　 :1;　　　　　　　　　　内容→　・・・・・ＦＥＤ　　・・・・・ＣＢＡ
　　unsigned int E　 :1;　　　　　　　　　　番地→　　　　0002　　　　　　　　0003
　　unsigned int D　 :1;　　　　　　　　　　内容→　・・・・・・・・　　・・・・・・・・
　　unsigned int dum2:5;
　　unsigned int C　 :1;
　　unsigned int B　 :1;
　　unsigned int A　 :1;
　};
記述Eの結果が出て、初めてint/charの意味、:1;の意味がわかりました。

長文すみませんでした。

ところで、
＞私のcompiler
って何？

イエローのやつです。使いやすく好きです。

>>494
記述Bの
unsigned char dum :13;　
がエラーにならない？

>>498
今、もう一度やってみました。
unsigned char dum :1;　　　errorなし
unsigned char dum :8;　　　errorなし
unsigned char dum :9;　　　errorなし
unsigned char dum :16;　　　errorなし
unsigned char dum :17;　　　error　ビットフィールドの定義エラー

>>437
正解でした。

>>494
>>499
記述Bの割り当ては、コンパイラ仕様として許されてるんだろうか。
しかし、仮にバグで、通報したとしても、そのバグを利用して使って
しまっている客先があったりして、今さら修正すると、まさに >>441 の
ようなことになるから、簡単には修正されない。
そのコンパイラでビットフィールドを使うなら、コンパイラの取説を熟読
して、出力されたアセンブリコードを必ず確認し、不審な点は、イエロー
に問い合わせるしかない。

>>493
ソースコードとは第一義として機械が読むもの。
もちろん人間可読性も大事だがそれは二の次。

人間様が「パッと見て動作がわかる記述」にしたいなら
適切なコメントを入れればいいだけの話。
正しくコメントが埋め込まれたソースは見ただけで何やっているかわかるぞ。
コードだけ書き換えてコメント修正しない馬鹿がメンテしない限りはね。

適切なコメント書くのサボりたいがために、コンパイラ依存バリバリの記述を
無理矢理使ったり、勝手にunionはずしたりするのは移植性が落ちるだけ。
それは機械にとって解釈困難にする方向でソースコードの本義として間違っている。

499です

>>501
そうですね。全くもって仰る通りだと思います。激しく同意です。

私は適正なコメントを各行に入れていますし、
コメント書きをサボってもいませんので、どなたか他の人のお話ですね。
参考にしたいと思います。ありがとうございます。

499です
追記訂正です。すみません。

×　そうですね。全くもって仰る通りだと思います。激しく同意です。

○　そうですね。先頭2行と最後の1行以外は、全くもって仰る通りだと思います。激しく同意です。

>>503
あのさ
人間が読んでパッとわかる回路図(スケマ図)って機械可読じゃないでしょ?
機械が読める制約をはずすからこそわかりやすく書けるわけよ。

機械で読めるのはスケマ図をCADに入れてアートワークした結果
出てくるカーバーデータだろ?
それはもう人間には読みにくいデータとなる。せいぜいシルクで説明が入るぐらい。

アートワークレベルで、データフローに沿ってとか
機能モジュールごとにまとめようとか、邪悪な下心を持って
無理矢理パーツの配置を変えたら動くものも動かなくなる。
ソースコードにおいて人間可読性にかまけるのはそれと同じことだ。

ソースコードを書く作業は、スケマ図を書く作業ではなく、
アートワーク(ガーパを作る)作業に相当するんだよ。

ソフトウェアで人間がぱっと見てわかるようにしたければ
UML記法でドキュメント書ればよい。
もちろんそのUMLドキュメントは機械非可読だが。

CとかJavaとかにUMLに期待されるような機能を要求するのは無茶。
だって目的が違うのだから。

すげー屁理屈のような気がしないでもない。

503です。
>>504
ありがとうございました。
いただいたアドバイスを元に、これからも頑張りたいと思います。
またどうぞ宜しくお願いいたします。本当にありがとうございました。

超初心者な質問だとは思うのだが…
なんでスタックって 2つ必要なんだろう(ISP、USP)。
割り込みの時だけ ISPにしないと何か困るのかなぁ?
結局、多重割り込みした時って ISPで積んで、積んでってなるんでしょ?
USPだけじゃまずいのだろうか?

USPとISPは基本的にOSを実装するための物
ってどこかに書いてなかった？
市販OSでなくても自分用のタスクスイッチャを実装するときには役立つはず

そういう使い方をしないなら、使い分けは不要
USPを使わずに、ISPだけでｲｲ

（株）髭男爵のギャグ-「ン」設計の
柚木正章は、宮�ｱ勤みたいなオタク！まあ、大人だろう？！

M16C62p をE8aを使ってデバッグしていますが、ＬＥＤを点滅させるだけの
プログラムでＣで作ったのですが実質記述量は１０行程度。
pd0 = 0xFF;
p0 を　0xFFと0x00にループを使って時間稼ぎして点滅させるような処理
普通に動作しました。E8aの画面からダウンロードでプログラムをダウンロードさせました。
フラッシュＲＯＭには書き込まれているはずなので
E8aをはずしてフラッシュＲＯＭから起動すると正確にはＬＥＤの点滅が起きません。
点灯さえも。なので動作していないのではと思うのですが。
E8aでのエミュレータ用とフラッシュＲＯＭ用でなにかHEW3で変更させる必要な項目
ありますか？

E8aを外部電源で使用する場合
コネクタ8のVCCには5Vを入力、でよいのでしょうか？

柚木正章はまごヲタク！！

http://science6.2ch.net/test/read.cgi/denki/1243349313/
これはどの程度ヒドイのか、ぜひ聞かせて下さい。

4bitマイコン　今、予約してきました。早く来い来い。

ちなみに、○bitマイコンのbit数は、データ幅のことですよね。
アドレス幅は、どのように決まるのでしょうか?
8bitマイコンなのに、アドレスが32本あるというのは変な感じ。
アドレスの数は、何できまるのでしょう。

>>514
設計者の趣味

了解です。趣味ですか。(カラオケ、スキー、ゴルフ、盆栽、映画鑑賞　う〜ん・・・・)

H8で16MByteは要らない=デカ過ぎだと思うんですが、どうでしょう。

>>510-511にレスがついてないところをみるに、E8aの所有者いなさげ？

H8かSH2にOS載っけないで、tcp/ipスタック載っけて
ＬＡＮでpcとつなげて、ﾌﾞﾗｳｻﾞ使ってﾋﾟｺﾋﾟｺとﾏｲｺﾝを動かす（まずはLED点灯とか）をさせたいんだけど
参考になるｻｲﾄとか本ってあります？

どこを探してもみんなUDPの説明だけで終わってしまっているんです

OSのソースを読めば大抵スタックあるでしょ
ライセンスに気を付けてね

ttp://www.sics.se/~adam/uip/index.php/Main_Page

＞参考になるｻｲﾄとか本ってあります？
本はいくらでもあるだろ．
http://www.amazon.co.jp/%E3%82%BB%E3%83%B3%E3%82%B5%E3%81%A8%E3%82%
A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%8D%E3%83%83%E3%83%88%E6%8E%A5%
E7%B6%9A-%E3%83%9E%E3%82%A4%E3%82%B3%E3%83%B3%E6%B4%BB%E7%94%A8%E3%
82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E6%97%A5%E9%AB%98-%E4%BA%9C%E5%8F%
8B/dp/4789837246
とかとか（行長すぎで叱られるんで改行入れた）

>>521
Amazonはdpと後ろの数字だけでいけるんよ
http://www.amazon.co.jp/dp/4789837246

オタキング　岡田斗司夫　一番　助手

オタッキー　柚木正章　！！！

H8で教えてください。
H8のI/O出力についてです。
PICやAVRでは、I/Oピンから取り出せる電流が±20mAとかだっりします。
が、H8ではなぜ-0.5mA, +5mAとか　弱いのでしょう。
これでは押しでLEDを点けることもままなりません。
しかも吸いより押しがとても非力だと思います。
「大電流ポート」とあったので見てみると、引きだけ10mAでした。
どうしてPICやAVRのように±20mAとかではないのでしょうか?

>>524
>H8ではなぜ-0.5mA, +5mAとか　弱いのでしょう。
そういう構造だから

>これでは押しでLEDを点けることもままなりません。
バッファ使おうぜ

>どうしてPICやAVRのように±20mAとかではないのでしょうか?
そんな事しても売り上げに貢献しないからじゃね？

吸い込みが大きい方のが普通


ってのは、オヤジだけの常識なのか・・・

> 吸い込みが大きい方のが普通
俺もそう思ってる。まあ、俺もオヤジだけど。

というより、マイコンの出力で直接ドライブしない


ってのは、オヤジだけの常識なのか…。

できる能力があったとしても、できる限りトランジスタとか使うけどな。

>>527
>というより、マイコンの出力で直接ドライブしない
>ってのは、オヤジだけの常識なのか…。

今時化石みたいなジジイの常識だな。
バスでも無いのに20mAの能力を付けてるのは明らかに直接ドライブを意識して設計されてる。
ワンチップマイコンはもともとローコスト向けだし、PIC等は元もとの開発意図がそうなってる。
20mAのドライブ能力があるのに基板上のインジケータＬＥＤ如きにトランジスタつけるなて愚の骨頂だな。
まあ、素人はなにも考えずに、うまく行った事のある回路をつぎはぎするのも手だけど。

何かやらかしたときにTrが体を張ってCPUを守ってくれる。
と思って入れるようにしてる。

Trなら「あ〜やっちまったよ」で交換できるからのう。

部品点数が増えるほど消費ｗが下げれる傾向あるのかにゅ

524です。
みなさん、ありがとうございました。

>そういう構造だから
>バッファ使おうぜ
>そんな事しても売り上げに貢献しないからじゃね？
>吸い込みが大きい方のが普通
>というより、マイコンの出力で直接ドライブしない
>できる能力があったとしても、できる限りトランジスタとか使うけどな。
>バスでも無いのに20mAの能力を付けてるのは明らかに直接ドライブを意識して設計されてる。
>ワンチップマイコンはもともとローコスト向けだし、PIC等は元もとの開発意図がそうなってる。
>Trなら「あ〜やっちまったよ」で交換できるから
良くわかる回答を、ありがとうございました。
私は、試作実験でH8でLEDを駆動するときには、LEDを直接、しかも吐きで灯けていますが、
製品ではデジトラ使います。(精神的な安心感、というか仕様外の電流は....)

みなさんのご回答は、全て使うときのコツや使い方の話ですが、お聞きしたいことは、
PICなどが±20mAとかと対称出力インピーダンスかつ大電流で売っているのに、なぜH8はそうしないのか?　です。
例えば、
・設計時期が古いためで、最新機種はそうになっている、とか
・そのようにしてしまうと○○機能ができなくなる、あるいは性能が低下する、とか
・製造プロセスが....とか
・別製品にPICのような製品があるので、H8ではそうしなくても良い
・H8とPICでは、棲み分けが違う。一緒にするな。
という感じの理由が知りたいのですが、どうでしょう?

>>531
想像はいくらでもできるけど開発元じゃないと答えなんてわからないと思いますよ。

>>531
それはメーカーに聞くしかないだろう。教えてくれないだろうけど。
設計上不都合とか、コンセプトが気に入らないなら使うなということだね。
その昔、サニョのマイコンで、Write 信号が立ち上がるまで
データバスの出力が維持できないすごいマイコンがあったんだぜえ。

よく聞く例で
トランジスタの動作を水道の蛇口になぞるけれども
そんなやり取りを聞く度水流に引き寄せられるピンポン球の画がうかぶのです
でも物理的な霧吹きの実験を見たとき無い人にはこれまた説明出来ないのも事実でして
やっぱ法則に抗う何か力が働いてるのかなとは思う

524です。
みなさん、ありがとうございました。
やっぱりわからないですかね。了解です。

以前どこかで読んだ?本に、ADRやDATAバスI/F部分に大電流Bufferを入れると、
バスの速度が上がらないから非力なんだと聞いたことはあります。
でも、バス以外のピンはPICのようにしてくれればいいと思うのですが。
さらに言うと、H8/3687のような外部バスできないマイコンでも、
押しは弱く引きは少しいい程度なので、何かあるのかな?と思う訳です。
もっとも、QFPばっかりでDIPを出さないところを見ると、
PICなんざ相手にしてないんだよ、って感じもしますけど。

ありがとうございました。

所詮例え話。

>>531
大量採用決めて開発依頼した所の都合かもしれない。

用途によって見方は変わるな。

民生用超コスト重視の場合＝外付けTrすら付けたくないので全I/Oとも±20mAにしる！
計測機器や自動車用途＝ノイズ発生器になる（EMC通らなくなる）からバス駆動能力は最小限にしる！

M16Cはバスドライブ能力のHi/Lo切替えスイッチついてなかった？

そう言う意味では、FPGAはエライですよ。
電流制限が2mA, 4mA,8mA,12mAとかプログラマブルですし、
スルーレートもfast/slowありますし。

>>538
他社のだけど(TIに買収されたLuminaryMicro)、
それくらいの調節はできるっぽい。設計が新しいからだろうね。

初期のH8は設計が古いこともあるけど、
趣味人相手に結構のほほんと設計してたって聞くからなぁ。

R8Cも調べてみたけど、R8Cも一部のピンで駆動能力は変えられるみたい。
たぶん、537の言うとおりM16Cもそうなんだろうね。

>>535
質問の仕方がアホなんだよ。

ある商品の特定機能を取り上げて「この機能の開発意図は何ですか」なんて聞いても、
開発したとこにしか分かるわけないだろ。ちょっとでも常識があればそのくらいの
判断はできるはず。

>>535みたいに特定機能の欠点を挙げた上で、「この機能の利点は何ですか」と聞けば、
開発者でなくてもいろいろ挙げられるだろ。

>>542
だって欠点なら、みなさんに聞かなくたってわかりますもの。
それより、>>542は、

>>542
開発したとこでさえ分からないことも多々あるよ。

工業用だとノイズ対策に絶縁したいからあまり電流容量増えると困るし

1チップマイコンみたいにスペースやコストをギリギリまで削る用途じゃなければ
7ｾｸﾞLEDのドライブにTD62083とか追加してもバチあたらないと思うｗ

>>543
逆に聞きたい。

PICのメモリはなぜあんなに少ないのですか？　もっとたくさん積めばいいのに。

PICの命令セットはなぜあんなに貧弱で回りくどくてわかりにくい命令ばかりなのですか？
もっとスマートでわかりやすい命令セットにしてくれればいいのに。

>>546
じゃあ使うな。

>>547
それはID:2ht/c08Uに言え。

もちろん俺はPICなんか使わない。

H8の出力をPICのポートにつないで、PICのポートでLED駆動すればいいんじゃね？

542=546=548は、PICを使わない(使えない)のでございましょうか?

PICのメモリが少ないのは、大きな仕事をさせるように考えていないからです。
たかだか30程度のI/Oのマイコンに、さほど大きなRAMは必要ないでございましょ。
しかし、LEDは直接駆動できます。Sourceが-0.1mAのようにひ弱ではありません。
TD62083を使うのも結構ですが、抵抗1つでも削減したいのに、1個100円もするトランジスタアレーは
コストを押し上げますよね。ともするとマイコン本体より高くなるかも知れませんね。

命令セットがわかりにくいとのことですが、それは内部のアーキテクチャによるものです。
しかし、Cなどの言語で組んでいただく分には、そのような命令セットは関係ございませんので
どうぞ安心してお使い下さい。

QFPしかないマイコンと異なり、PICには、DIP8pin〜QFPパッケージまで、あらゆる形状がございますので、
ユニバーサル基板の上で簡単に試作ができますし、入門者にも低コストで環境が整います。
DIP品を使用することで基板実装にメタルマスク等は必要なく、低コスト生産が実現します。

AVRのが安いしわかりやすい

×さほど大きなRAMは必要ないでございましょ。
○さほど大きなRAMは必要ないでございません。

>>552
訂正した方が意味わからんぞ。ｗ

俺はピン数少なくていいから処理用のメモリがもっと欲しいと思うことが
たびたびあるがな。

PIC24とかdsPICなら内蔵ﾒﾓﾘ比較的容量あるのに
しらないのか？

PICでも多ピンのはパッケージの熱容量が決まっているだろうから
全部電流取れるわけがないと思うんだけど、ＰＩＣって全部のピンから20mAとか
電流が取れる魔法のＩＣなのか？

まさか、ピン出力とは別にI/Oグループ(？)ごとに上限が決まってますよ、だんな。モータードライバ入りのPICなんかもあるし。
と思って調べたら、我が友PIC16F59(I/O数だけが取り得の安PIC)は入出力とも1ピンにつき25mAまで、5つある各I/Oグループの最大は入出力とも100mAだったでござる。
(1グループ最大6本だから流石に全ピンがフル出力とかすると足らないな。)
で、石全体の許容出力電流ってMax. current into VDD pinsでいいのかなぁ…これだとすると全出力ポートから同時に出力可能な電流は200mAだな。

これ、流石に熱くなるんじゃねーかぁ…？

下記のコードなんですがiicSendStop関数でwhileにはまらない
ようにタイマ―割り込みによる監視をしてるんですが、getIicErrFlg
の戻り値が1にならずにはまってしまうことがあります。
個人的にはタイマー割り込みが止まってしまったときしか考えられ
ないのですが、他にまずいところありますか？
iicErrTime関数が割り込みで実行されています。

ttp://blog-imgs-24.fc2.com/s/o/u/soundreview/txt.txt

void startIicErrCnt(void)
{
iicTimeOutCnt = TIME_OUT_ERROR;
timeOutFlg = OFF;//これがいるんじゃないかいな？
}

R8C/27のハードウェアマニュアル読んでてよく分からない事があるので教えてください。
RXD1/TXD1に関してですが、設定でピンを変更できるというのは分かったのですが、
246ページのレジスタの説明みてもイマイチわかりません。
まず、送受信を別のピンで行う場合、P3_7とP4_5の組み合わせかP0_0とP4_5の組み合わせしか使えないのでしょうか？
P3-6とP4_5を使いたいのですが、その場合
・UART1SEL0、UART1SEL1
・U1PINSEL
・TXD1SEL
・TXD1EN
は、それぞれどのように設定すればいいのでしょうか？

質問なので一応あげときます

　　柚
　　木
　　正
　　章
宮　は
崎　　、
勤
み
た
い
な
オ
タ
ク
！

>>559
一番下の表に組み合わせが書いてるみたいだけど？
シリアルの送受をタイマー割り込み使ってやれば、P3-6とP4_5の組み合わせが出きるんじゃないの？

>>526 >>527

http://mofc.u.cnet-ta.ne.jp/naminohiromi/namino114.jpg

>>558
処理としては必要そうですね。
while文の中に一度も入らない場合を考えると
flgがONになってしまうので、次の呼び出しの
ときwhile文の中に入った場合いきなりstop
とreturnを実行してしまう場合もありそうです。

ただ仮にstartでtimeOutFlgを0にしなくても
while文のgetIicErrFlgにいきなり入るだけで
whileではまってしまう要因にはならないような気
がします。

iicErrTimeだけstatic宣言されてるのはなぜ？

>>565
下4つの関数は本当は別ファイルでiicErrTimeは
外部に公開しなくてもいい関数だからです。

ところで自己解決しました。whileにはまっているのではなく
タイマ―の設定ミスからカウントアップが5Sのつもりが5分
になっていました。
それと558さんのいうようにstart関数でのフラグクリアで
なおったっぽいです。

5sも時間待できるとはうらやましい

fputc( 0xFC, SCI0 );
fputc( 0x08, SCI0 );
fputc( 0x4C, SCI0 );
という3行のソースを、fprint()を使って
1行で書くには、どのようにすれば良いでしょうか?
たとえば fprintf( SCI0, " (この部分に16進3つを書く) " );　とかにしたいのです。
あるいは
unsigned char s[] = { 0xFC, 0x08, 0x4c };
fputs( s, SCI0 )
というように、配列+命令の2行になってしまうのでしょうか?

"\xfc\x08\x4c"

>>569
ありがとうございました。さっそく試したところ、ちゃんと動きました。
通信回線をプロアナで確認し、確かに送れておりました。ありがとうございました。

しかし、残念なことに、0x00が送れませんでした。0は終了なので、送れないのでしょうか。
実行結果は、こんな感じです。
fprintf( SCI0, "\xfc\x08\x01\x02" );　→　fc 08 01 02
fprintf( SCI0, "\xfc\x08\x01\x00" );　→　fc 08 01
fprintf( SCI0, "\xfc\x08\x00\x02" );　→　fc 08 02　　　　(00なので打ち切り)
もしよろしければ、何か0x00の送り方をご存じでしたら、ぜひ教えてください。

fprintfで0はダメなので、0の時だけfputcを使う

>>571
ありがとうございました。やはりprintfで0x00はダメですね。
RS232タイプのLCDを駆動しているのですが、cursorの位置を指定や
その他の設定に0を伝える必要があるため、質問していました。
どうもありがとうございました。

あと、前回の実験結果に誤りがありましたので、訂正します。
×fprintf( SCI0, "\xfc\x08\x00\x02" );　→　fc 08 02　　　　(00なので打ち切り)
○fprintf( SCI0, "\xfc\x08\x00\x02" );　→　fc 08 　　　　　(00なので打ち切り)

どうもありがとうございました。

組み込みでprintfは禁則だと思っていたんだけど、最近の若いのは使うんかねぇ・・・

>>568の知識は printf()系が重い以前の話だからな
何も考えていないに違いない

手段にすぎない目の前のソースコードの美しさにかまけて
最終目的である実行コードの汚さには気付いていないのだよ

最近の若いもんです
printfがよろしくないのは引数が不定なのスタック馬鹿食いだからかと思うんですが
整形した文字列を作りたいときってどうすればいいんですか？

ちなみに今はprintfを使ってます

ttp://www.menie.org/georges/embedded/

ありがとうございます
こういうものがあったんですね

バイナリーモードで fwrite すればいいのではないだろうか？

>>578
fwriteですか、了解です。調べてみます。
可能ならば、
fprintf ( SCI0, "\xC8\x5A\x00\x02" );　とか
fprintf ( SCI0, "\xC8\x5A%??%??", cursor_x, cursor_y );　とかのように
1文で書けないかと、思っています。
ありがとうございました。

>>574
実行コードが汚なくならないようにすることも、必要かもしれませんが、
動作に問題が無ければ、それで良いかと思います。実行コードを私たちは直接見ませんし。

それよりも私たちに重要なのは、
あとあとの修正や変更などが短時間に確実に実施できるように
見やすいソース、動作が分かり易いソースを書くことだと思います。
当然、適切なコメントは必要で、ふんだんに使っています。

ソースリスト1画面内で
1行で書けるコードが3行、4行に渡ってしまうと、得られる情報が減ってしまいます。
場面にも依りますが、多くの場合1行で書かれたものは「なるほど」となる場合がほとんどです。
ソースコードは、我々人間が修正するものですので、
1画面中に、短い行数で視界の移動を減らし、わかりやすい記述をしたいと思っています。

人間の把握可能行数は言語に寄らず一定というのが十何年も
前から知られているのでリソースが許せばそれでいいんじゃね。

でも

　行を短く簡潔に

と指定すると

　foo(qux(qix(haha() ? qaz(quz(...)) : bar(baz(hehe()),hore()),heno())

とか書いて先生短く書きました！とかやるやつがいるから行数論争は
ほどほどにな。

>実行コードを私たちは直接見ませんし。
プロじゃないならそれでいいかもしれんけどな。

>場面にも依りますが、多くの場合1行で書かれたものは「なるほど」となる場合がほとんどです。
>>580 が言うみたいに、見にくかったり、トリッキーなコードになりがちだから
いいとは思わないよ。

>それよりも私たちに重要なのは、
>あとあとの修正や変更などが短時間に確実に実施できるように
>見やすいソース、動作が分かり易いソースを書くことだと思います。
>当然、適切なコメントは必要で、ふんだんに使っています。
後半は同意だが、「私たち」ってのは誰？

君に必要なのは、スキルを上げることだね。

579です。
>行数論争はほどほどにな。
>見にくかったり、トリッキーなコードになりがちだからいいとは思わないよ。
ありがとうございます。たぶん、そういう突っ込みが入るだろうと思いました。
時と場合によりますね。

一目でわかる構文はいい。

長くて見にくい表記の例
if( A==B )
{
　　C=D;
}
else
{
　　C=E;
}

見やすい表記の例
if( A==B ){
　　C=D;
} else {
　　C=E;
}

さらに見やすい表記の例
if( A==B ){ C=D; } else { C=E; }

別表記
C=( A==B )? C=D : C=E;　　　すばらしい。

ぜんぜん素晴らしくない。
勉強し直せ

＞C=( A==B )? C=D : C=E;　　　すばらしい。

これが余計だったな
頭悪すぎ

C　=　(A==B)?　D:　E;

この書き方は？
fprintf ( SCI0, "\xC8\x5A%c%c", cursor_x, cursor_y );

元ネタでは、0が送れないのが問題なんじゃなかったか？

"\x00"がダメってことでしょ。
小出しなもんだから、何したいのかよくわからんで答えてるからね。

訂正です。
×　C=( A==B )? C=D : C=E;　　　すばらしい。
○　C　=　(A==B)? D : E;　　　　大変すばらしい。

みなさん、指摘ありがとう。

文法的には間違いではないけどね。
動くと思うけど、最適化依存だし。

でも、スペースの使い方が気持ち悪いぞ。

スペースの使い方も、難しいものがあるね
なるべく塊で意味を持って見えるように使っています例えば、
わかりにくい例
if( ( A == B ) && ( C ==D ) )｛

わかりやすい例
if( (A==B) && (C==D) )｛

わかりにくい例
if( A==B )
｛
C=D;
｝
else
if( E==F )
｛
G=H;
｝
else
if( I==J )
｛
K=L;
｝

わかりやすい例
if( A==B )｛ C=D; ｝
else if( E==F )｛ G=H; ｝
else if( I==J )｛ K=L; ｝

わかりやすい例だとブレークかけにくくない

確かにブレークはかけにくいね。
そういうときは、途中で改行してやるしかない。
デバッグが済んだら元に戻す覚悟なので、何でもありだけどね

わかりやすい例として、こういうのもあった。

A = ( B==LEFT )? C :
( B==RIGHT )? D :
( B==UP )? E :
( B==DOWN )? F ;

if() else if()と同じだけど、
パッと見で、何か選択しているな というのが わかる

>>594
お前は少しズレていると言わざるを得ない。

スレ違いじゃヴォケども
その辺の話がしたいならプログラム板で好きなだけ議論してこい

プログラム板
http://pc12.2ch.net/tech/

すこしの脱線もゆるされないのか…

H8活用に直結した話だと思いますが。
何が気に入らないのか教えてください

単発だし、ネットアサヒじゃね？
なんでこんな板に居るのかということ自体に疑問があるが。

NECとRTが合併すると残る16bitCPUは何ですか?
78K0 R8C 300Hまさか

V30

ルネはシリーズが多すぎるよな

HD64180

>>601
復活の予言？

見やすいと言ってる方が見にくくて、見にくいと言ってる方が見やすい件

元ネタに戻るけど、シーケンスフォーマットが要らないなら↓で
いいんではないのか？



buf_send ( char *send_buf , int channel , int length )
{
　　 int i;
　　 for ( i=0 ; i<length ; i++ )
　　 {
　　　　　　 fputc ( send_buf[i] , channel );
　　 }
}

fputcだから
int channel
じゃなく
FILE *fp
じゃ、なかろうか？

>>605
えーっ?　なんでたったそれだけのことに8行も割かないといけないの?

コレの方が格段にわかりやすいと思うけど。

buf_send ( char *send_buf, int channel, int length ){　　　　　　　　　　　←1space開けるのは、カンマの後だけ
　　 int i;
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←変数宣言と本体の間は1行開ける
　　 for ( i=0; i<length; i++ ){　fputc ( send_buf[i], channel );　}　　　　←たかだかこれだけの実行なら、
}　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　このようにfor(){xx}と1行にしたほうが
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　何かを繰り返しているんだなと、動作が一目でわかる。

長文だと、前者は一度で目に入る量は少ないけど、繰返し範囲間違えにくい
後者は量は多いけど、繰り返し処理を見落としやすい

どっちもどっち

>>605のほうが段違いに見やすい。

コーディングスタイルは宗教みたいなものだからな
buf_send ( char *send_buf, int channel, int length )
{
　int i;

　for ( i=0; i<length; i++ )
　 　fputc ( send_buf[i], channel );
}　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　このようにfor(){xx}と1行にしたほうが

見やすさは大事だけど、もっと大事なのは徹底すること。

コーディングスタイルでオブジェクトに差が出るならいいんだけどね。

もっと大事なのは、仕様通り動くこと

仕様の読解力が足りないとか結構ありそう...

にんげんだもの

>>610
それだと、fputcの行の次にデバッグコードを入れたらfputcとデバッグコードで
動作の差が出てくるからわかりにくい
{}で括っていますよって明示的に出しているからこそわかりやすい

・・ってまあ、宗教論争だ罠

>>616
ぼくも全く同意見。{}を書かない人がいるけど、次行だけの特典であり、間違いのもと。
ちゃんと{}を書いて欲しいと思う。
if(){}
while(1){}
for(){}

多くの場合ソースコードを一番良く読むことになるのは書いた
本人だから未来の自分がわかりやすいのが一番大事かな
１行ですむところにわざわざ無駄な{}があるのが過剰な装飾っぽくて
うっとおしく感じられたりもするけどね。
if (xxx) {
}
と書くか
if (xxx)
{
}
と書くかなどなど含めてこのあたりは本当に昔から（大学生なんかにとっては
生まれる前からだな・・）ずっと続く宗教論争だね。

自称女子高生の教えてクン登場ですぅ〜。

H8 3694Fでシリアル SCI3 にブレーク機能？があるけど、
使い方わからないですぅ〜。
頭いい人教えて欲しいですぅ〜。

エラーが発生してない時にフレーミングエラーに 0 書き込むと
CPU がストップ？するっぽいけど、あれ一体ナニ？ナニ？ナニ？？

キモッ
呆れて止まるんじゃね？

受信の時フレーミングエラーでRxDが０の時はブレーク信号がきたと判断して
RxDが１になるまで受信しちゃいけないよってことでは？

＞自称女子高生

こういう付かなくてもいい嘘を付き続けると
精神にも影響を及ぼしてくる

いい影響

>>622
真偽はともかく、質問の枕詞にこんな台詞をつけなくてはいけない位、実生活で相手にされてないって事だよ。
哀れではあるけど、

　気　持　ち　悪　い　奴

自己流ですが、仮に{}とかをつけない時は、

for() ;

と一行で収めるようにしますね。

E8aを使用するときステップ実行するとそのたびにflashメモリに書き込みを行う、というのは仕様なのでしょうか？
100回書き込みというのがメーカーが保証する値だとして実際はもっと長持ちするにしても

ちょっとした物を開発したらそれだけでメモリが使えなくなってしまいそうな気がするのですが・・・
なにか良い方法はないでしょうか？

デバッグ用と運用用とに別ける。

ステップ実行しないで机上デバッグとか？
loadするだけでflashに書き込んでるという...

>>626
ステップ実行のたびには書かないでしょ？

保証は書き込みじゃなくて書き換え

M16Cのマニュアルを読んだ感じ、イレース回数のことっぽい。書き込み自体は
カウントされない。イレース指令を出したら、該当ブロックの書き換え可能回数が
1減る、そんな感じ。実際は100回保証でも1000回ぐらいはふつーにいける、
ってのを聞いた。(100回保証品で100回を越えたら「自己責任」だろうけど)

あと、ステップ実行の度に書いてる。ブレーク命令を書き込んでおいて、
そこでブレークして、再開時に本来コードを書いて、みたいな。

よっぽど糞なデバイスじゃなければ1万回ぐらいは書けるだろ。
デバッグしてる間ぐらいなら。
保証は書き込み後10年データ保持だから、書き込みエラーが出るほど
使いつぶすのもまた容易ではないと思うぜ。

>>626
ブレークポイントをいくつも設定してるとそうなるけど、
必ず毎回毎回って事はないよ

まあ、安い装置でデバッグできてるんだからあまり文句言わない

外部バスのモードが使えて、一番ピン数の少ない300Hって、何だと思いますか?
やっばり3048oneでしょうか。

>>634
80pinのがあったような気がするが、
型番忘れた…

外部バスってアドレスとデータが出てればいいのよね？
Flashもちなら3039、外ROMなら3001とかが80pinだな
ttp://japan.renesas.com/fmwk.jsp?cnt=h8300h_series_landing.jsp&fp=/products/mpumcu/h8_family/h8300h_series/

>>635 >>636
ありがとうこざいました。

オタクの柚木正章です。よろしくな。
http://changi.2ch.net/test/read.cgi/otaku/1241858991/

まだ勤務してるかな。こてこての岡山県人。

究極の破格の安さ！
NEC VALUESTAR N VN770/TG6W PC-VN770TG6Wが新品で消費税送料込みで20,000円
新品TOSHIBA　ハイビジョンテレビ　32V型REGZA液晶テレビが消費税送料込みで30,000円
エアコンもなんでもある。
オークションよりも安く電化製品は在庫多数
詳しくはこちら
http://blog.goo.ne.jp/kotoni_001/

教えてください。

2次元配列にデータを格納する場合、

unsigned char A[2][6] = {
　{ 1, 4, 8, 12, 13, 14 },
　{ 8, 10, 8, 5, 9, 15 }
}:
とやればOKなのですが、

unsigned char A[2][6];　　といったん宣言して、
別のところで

A[0][] = { 1, 4, 8, 12, 13, 14 };
B [] = { 5, 18, 3, 9, 19, 5 };
D [] = { 4, 60, 3, 9, 0, 11 };
A[1][] = { 8, 10, 8, 5, 9, 15 };

というように他の配列と並べて、まとめて代入がしたいのですが、
どのようにスレばよいのでしょうか?

まとめて代入じゃなくて、一個ずついれる

ですよねぇ、1個ずつ。それはそれで変な感じがします。

>>640
まとめて代入できない言語を使うと、できません。
まとめて代入できる言語を使えばいいです。

ありがとうございます。
ネットで探し回りましたが、そちらでもCではダメのようでした。
ありがとうございました。
ちなみに、「まとめて代入できる言語」とは。何になるのでしょうか?

頭の悪い初心者ですが、もうひとつ教えてください。

unsigned char A[3];

for(b=0; b<3; b++){
　　A[b] = ・・・・・ 　何か計算などを実施
}
　　　　　　　　　　// その結果を、PORTに出力する。
P1DR.BYTE = A[0];　//　○○出力1
P2DR.BYTE = A[1];　//　○○出力2
P3DR.BYTE = A[2];　//　○○出力3

というのはOKです。
forの所では、繰り返しなので配列で添え字を変化させた方が、スマートに書けます。
しかし、本当はA[0]=teikou、A[0]=condenser、A[0]=coil、と内容が決まっていますので、
最後の出力の所で、
P1DR.BYTE = teikou;　　　//　抵抗値出力
P2DR.BYTE = condenser;　//　コンデンサ値出力
P3DR.BYTE = coil;　　　　//　コイル値出力
と、書きたいのです。このような場合、どのようにすればよいでしょうか?

調べたところ、共用体(共有体?)を使うとできそうなのですが、

unsigned char A[3];

union test{
　　unsigned char teikou;
　　unsigned char A[0];
};
としたら「エラーだぜ」と言われました。たしかに2箇所でA[]を宣言しているので
おかしいことがわかります。
表の顔はteikouでも、裏の顔はA[0]の配列メンバ　のような二重人格のような表記は、
できないのでしょうか?

これでいいんでないかい。
#define teikou A[0]
#define condenser A[1]
#define coil A[2]

どーしても共用体にするなら
struct foo {
　unsigned char teikou;
　unsigned char condenser;
　unsigned char coil;
};

union bar {
　unsigned char A[3];
　struct foo name;
};
とかやれば出来なくはないが。

>>644
定数ないし初期化子を並べてランタイムに一括代入できる言語となると心当たりが
ないが、Matlabあたりならできそうな気がする。Perlもできたような・・・

A = [[],[]]
A[0] = [1, 4, 8, 12, 13, 14]
B = [5, 18, 3, 9, 19, 5]
D = [4, 60, 3, 9, 0, 11]
A[1] = [8, 10, 8, 5, 9, 15]

char _A0[] = { 1, 4, 8, 12, 13, 14 };
char _B[] = { 5, 18, 3, 9, 19, 5 };
char _D[] = { 4, 60, 3, 9, 0, 11 };
char _A1[] = { 8, 10, 8, 5, 9, 15 };

void hoge0(void)
{
char *A[2];
char *B;
char *D;

A[0]=_A0;
B=_B;
D=_D;
A[1]=_A1;
}

void hoge1(void)
{
char A[2][6];
char B[6];
char D[6];

memcpy(A[0],_A0,sizeof(_A0));
memcpy(B,_B,sizeof(_B));
memcpy(D,_D,sizeof(_D));
memcpy(A[1],_A1,sizeof(_A1));
}

みなさん、ありがとうございます。645です。

いろんなやり方があるようですね。
>>646の方法は、理解できました。
>>648の方法は、A = [[],[]] の意味が理解できずに、諦めました。
その後、結局、コメントだらけですが、1つ1つ書き込んでも事なきを得ました。
例ではteikou, condenser, ciolと3個でしたが、本当は120個程度あるのでした。
>>649
勉強になります。理解する時間をください。
「*」が出てくると、とたんにわからなくなります。
ほとんどのことは配列でできてしまうので、ポインターの嬉しさが湧かないためか、
使ったことがないんです。使ったことがない=覚えようとしない、僕の悪い癖です。
すみません。

ポインタに慣れると便利すぎるぞ

柚木正章は、髭男爵のギャグー「ン」設計の
宮崎勤みたいなヲタク！！！

初心者の質問、その3って許されますか?　　　(こっそり質問しちゃおうっと)

printf()で教えてください。
printf()の書式で、
よく使う　printf( "%02x", A );　ではなく、
printf( "%02lx", B );　のように、02とxの間に小文字のl(エル)を入れる書き方があります。
このlの意味は、Longという意味だということまでは知っています。今まで、結果オーライで、だましだましに使ってきました。

このlの意味が知りたいです。
上記のprintf()には、longに関係するところが、2箇所あります。" "内の書式と、" "の後の変数、の2つです。
それで、このlは、どちらに影響するものでしょうか?

1) " "の中で表現したい書式がlongのように長い場合にlを書くのか、
　　　　例　printf( "%05lx", char変数 );　変数はcharでも書式が16進5桁なのでlを付ける。

2) あるいは、" "の後の変数がlongの場合に書くのか、ということです。
　　　　例　printf( "%02lx", long変数 );　書式の桁数に関係なく、変数がlongのときに書式にlをつける。

宜しくお願いします。

(2)だろ
16bitCPUなどで、longとintのビット幅が違う場合に効いてくる

なんで組み込みでprintf？？？

>>655は、デバッグでprintf使わないのか?

横から
俺もprintf使ったことないや

>>656
画面もないのにprintf??
fprintfにしてシリアルに流すにしたって組み込みで使うのはナンセンス

やれやれ。printfデバッグは21世紀じゃ流行らねえんだとよ。

デバッグではprintfは楽

組み込みだからこそ
シリアルに垂れ流すんじゃないのか？

>>661
fprintfとか使ってるのがって話じゃなかろうか

シミュレータ上の話は知らない

>>658
何がどうナンセンスなのか教えてくれよ。

>>660, >>661
その通りです。

>>663
めたぼ

組み込みだからシミュレーションでやれって話でないの。
シミューレタの使い方しらん。

>>663
スタックバカ食い
遅い
余計な処理をしすぎる

printf系を使うのと浮動小数点を使うのは組み込みでは禁則だった。
浮動小数点はＣＰＵがやってくれるようになったので、今は関係ないけど
H8なんかではあんまりよくない。

>>663
コンパイラによってはダメダメなコードを吐く。
昔はそういうコンパイラが多数派だったんで、その頃の経験で一律に
無用扱いする人が多い。

なるほど、
でもそれは、コンパイラがいけないんであって、printf()がいけないのとは違うよね。

E8などのエミュレータもいいんだろうけど、
printでサクッとデバッグしてる俺。

ロボットとかでセンサの値とか見なきゃいけない場合、printf系は必須なんじゃないの。

コンパイラじゃなくてライブラリじゃないか？

>>670
そうですね、ライブラリです。

いずれにしろ、それが「組み込みでprintf()を使うのがナンセンス」という>>658の根拠には
全然なり得ない。

何がどうナンセンスなのか教えてくれよ。 なあ>>658よ、教えてくれよ。

>>669
シリアルで流すにしても文字列整列は自分でライブラリを作るモノだと思うけど、
最近の若いのはprintfを簡単に使うのか。
自分のところの部下が使っていたら止めさせるな。
どういう弊害があってどんなバグが出るか解らないしな

>>645

union test{
　　unsigned char teikou;
　　unsigned char A[0];
};

重箱の隅ですまんが要素数 0 はない。

>>670
いや、printf系（というか可変引数関数）のサポートのないコンパイラでprintf系を
作ろうとすると、どうしても巨大なコードのライブラリにせざるを得ないんだよ。
フォーマット文字列に何が来るかライブラリレベルだと判断できないから、どの
フォーマット文字列が来てもいいように、サポートしているフォーマットすべてに
対応したコードを吐かざるを得ない。

もっと近代的なコンパイラだと、printf（に限らんけど）の引数の内容と数にあわせて
リンクするライブラリを調整できる。たとえばフォーマット文字列が"%d"だけの場合、
%d⇒文字列変換用のライブラリだけ使って、そのライブラリ関数を1回だけ呼び出す
形にコンパイルしてくれるから、コード効率はitoa⇒fputsとほとんど変わらない。

>>674
それならなおのこと、必要な機能の表示関数を作ればいいだろ。
別に printf じゃなくてもいいんだから。

広い意味では本来のコードと関係ない表示のための副作用を行うコードを
埋め込む手法をprintfデバッグと言うよ。
（知らなかった人、瞬間的に反発するのはご勘弁な）

>>675
表示関数を自分で作りたいなら作ればいいし、誰もそれに反対するレスはしてないって。
作るのが面倒なら、モダンなコンパイラでprintfを使えばいい。
>>674は、>>666みたいな時代錯誤に対するレスだよ。

>>676
よく分かった。おれ素直。

そうか、あなたの名前はもとなお君か。

HEWって、「60日期間限定」はダウンロードできるけど、
「ずーっと使えるMCU限定版」って、無いのでしょうか?
昔はあったような気がする。

製品版って、買うといくらぐらいですか?　30万くらい?

CPU毎にコンパイラ、アセンブラとパッケージで\198k。
ttp://crm.hitachi-ul.co.jp/system/XSOFT/xsoft_catalog071001.pdf

ありがとう

>>1-681

オタクって友達いないことなんだよ。

　　　by　柚木正章（ゆのきまさあき）

秋月のH8 3069FLANを使ってI2Cを操作してみたいのですが、
MESに搭載されているドライバはEEPROM専用ですか？
I2Cスレーブを使いたいんですが、例えばＲＴＣなどを制御したいとき、
デバイスドライバとしてopen関数で呼んで、
read, writeするだけで使えるものなのでしょうか？
それと、やっぱりメモリと同じでマウントする必要あるの？？
RTCスレーブを扱うサンプルがありましたら、お教えください。

MESのソースを読む

あの気持ち悪いMLに質問してみる

>684さん
>685さん
ありがとうございます。MESのソースを呼んでみたんですが、
I2C_startとかを直接扱う場合、デバドラ経由じゃなくて、やりたかったんですね。
ん？でもi2c.cを通常のプログラムにすればよいのかなぁ？？？
組込初めてなんで、試行錯誤しています。
あのMLには登録済みですが、使い方が...
ありがとうございました。

ポートの方向レジスタ切り替えてるところが分かれば

I2Cの前に、そもそもマイコン制御の基礎がわかっていないので、
そちらの方から攻めてみたいと思います。
C屋だとおもっていたけど、マイコンに移ってきて、
打ちのめされました...ハードをかなり意識しないと
マイコン制御ってむずかしいですねぇ...orz

ヲタキング　ルネサスマイコン
柚木正章！！！！
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

I2Cならハードウェアマニュアルとアプリケーションノートのサンプルとにらめっこしてたら
そのうちだいたいわかるよ…多分

SH2とかのI2Cサンプルってナゼかグローバルサイトにしかなくて困るが。
なんで日本語サイトにないのか

英文資料で充分，あるいは自力で何とかなるという人以外は使うなってことで

いいフィルタリングだよね > 英語読めないフヌケは排除

質問です。
H8/3694 グループのハードウェアマニュアル
ttp://w3.quake3.jp/sushi-k/pool/H8-3694.pdf
を読んでいて気になったところがあります。
21.電気的特性の　21.2.2 DC特性というところの　出力Highレベル電圧　という項目の測定条件に、

−IOH＝1.5mA

という式があります。
IOHの前に存在するハイフンは何を表しているんでしょうか？
出力とは反対方向に電流が流れるってことなんでしょうか・・・

下の方にある出力Lowレベル電圧のところにはIOL＝1.6mAと書いてあり
その意味もきちんと分かるので、出力Highレベル電圧との違いが気になってしまいます。

どなたか教えていただけないでしょうか？

出力がHのとき、出力ピンから外部に電流を吐き出すことができる。
出力がLのとき、外部から出力ピンに電流を流し込むことができる。

そういうこと。

>>694
即レスありがとうございます。
何やら難しい話みたいなので、もっと勉強することにします。
ありがとうございました。

3664のI2Cにはいろいろと不具合があるみたいだけど3694ではそのあたりどうなってるんでしょうか？

オープンコレクタとかいろいろ考えるの、めどいよね。

そういや、ポートの等価回路って見ないなあ。
ふるーいハードウェアマニュアルで見た覚えがあるんだが。

>>696
そのへん直したのが3694

>>693
どこかの誰かが、外からマイコン内に流れ込む電流方向を正方向と決めたみたい。
なので、オープンコレクタ出力の「吸う電流「を、+10mAとか表現する。
だからマイコン内から外に向かって流れ出る方向の電流をマイナス記号をつけて
表記する。
3694のデータシートに書かれている、-Ioh = 1.5mAというのは、変な書き方の代表。

一般的な表記
・吸い込み電流　IoL = 10mA
・吐き出し電流　Ioh = -1mA

なぜ吐き出しがマイナスになったか、経緯を知っている人、ぜひ教えてください。

>>699
丁寧な解説ありがとうございます。
IoLは I out Lowの略だと思っており、
当然、＋　で吐き出し電流だと思っていたことが勘違いの原因でした。
混乱した原因が分かってすっきりしました。ほんとうにありがとうございました。

経緯というより常識頼りじゃね？
ピンからの「出力」電流を、ピンから「出る」向きを基準に考えるのは自然。
むしろ、それ以外の基準が思いつくようなら聞いてみたい。

げ、ちゃんと読んでないのはオレのほうだ。
大変すまんかった。吊ってくる・・・

Transistor-Transistor-Logicの常識だとsink方向が正だろ JK

>Transistor-Transistor-Logicの常識だとsink方向が正だろ
なんで?　TTLはsinkが大電流取れる、H側電圧の方がノイズマージンが高いというだけのことで、
方向を+に定義する理由にはならないと思うけど。

>>1-704
ヲタキング　ルネサスマイコン
柚木正章！！！！
アメリカ人的考えのはずが
終身雇用！！こてこてのべたべたの日本人（大和魂）

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

インターネット接続環境だとAutoupdateをやるとHEW3などが最新版になりますが
ターゲット環境がネット接続ができないので新バージョンにならないので
なにかUSBメモリなどを経由してAutoupdateみたいに最新版にする方法ありますか？
現時点ではHEW3とE8a関係のソフトウェア、E8aのファームウェアあたりが必要です。
どなたか教えてください。
またはある時点のバージョンに戻すことができますか？

H8 の SCI を使って 38.4 Kbps で通信しようとしています。
上位側のソフト修正は NG といわれ、
下位側の H8 のみを変更して動かすよう
上から指示が出てしまいました。

H8 側は 8MHz 駆動、 35K bps が最大精度で、
H8 側で 7% 誤差が出てしまう状況です。
フレーミングエラーはなぜか出ません。（なぜ？）


クロックの IC を変えるしかないでしょうか？

ハンマーで「発注元」を殴り倒すのが正解？

あくまでソフトが悪いと主張し続ける上の指示を
撤回させる良い方法はありませんか？

上とやらが、ソフトが悪いと主張してるのに、
なんでH8変更させる指示出すの？
クロックのIC？

意味不明。
もう一回書き直せ。

つーか、そうやって意図もうまく伝えられないようだと、
無理難題押し付けて切ろうとしてるんではないかおまいの上司は。
会社大丈夫かい？

上司側の言い分も聞いてみないと判断つかんな。
実は上司にごく当然の要求をされてるだけかもしれん。

1byteずつ細切れでデータが来てても、38.4kと35kで１ビット落としそうだな。
クロックのICってシリコンオシレータのことだろうか？

上流を変えられないってのは
全体が古いシステムで、上流を置き換えるコスト考えたら、下流から乗っ取って操りたい、とかかな？

オシレータ変えるのが嫌な理由は何? コスト?

通信がうまくいかないのにどうやってチェックしたんだろうか

>>708
>>709
「通信が出来ません」の一言が抜けていましたね。
単純に切ろうとしているだけかも知れません。

>>710
ダメです。景気最悪でまだ全然回復してません。
挙句に社内では愛と勇気だけが友達、
かつデジタルを理解できる人が上以外にいません。


>>711
通信データは全て全部D7が１です。
おそらくはこのためフレーミングエラーが出ないのですが、
上に口頭で説明しても納得して頂けません。
クロックのIC==水晶振動子です。

上流変更不可の理由は、
　　・上の担当領域である事
　　・上から変更不可と指示が出ている事、
　　・社内の上位側「最新」ソースを私がリビルトして書き込んでも一部機能が動作しない
　　　　−　開発環境などの資料がない
　　　　−　社内管理のソースが最新でない可能性が高いため
　　　　　　　（他のプログラムでも最新ソースを紛失している物があったため、今回も同様の可能性が高い）

上位側に35Kpbsにしたソフトを書き込んだ所、
一部欠陥動作ながらも通信できました。
上位側デバッガの使用許可が出ないため
H8の机上デバッグ、シンクロ以外に確かめる方法がありません。


>>712
ICを変えるとなると何十個単位で8MhzのＩＣを捨てる羽目になるからです。
最悪の場合、IC変更を考えています。


>>713
ボーレートを落としてのH8<->PC間通信やH8<->上位側
通信成功を確認済みです。LEDで動作が確認できます。

なぜ、38.4 Kbpsで通信することになったの？最初から？

>>714
とりあえず、この流れで、オシレータなりクリスタルなりをＩＣって言うのはどうだろう？
集積回路じゃないしさ。

>>715
上とやらが作った仕様の段階でそーなんじゃないか？


さて
H8のSCIだと、8MHzの38400bpsは確かに穴になってるけど
n=0,N=0 って設定できなかったっけ？

何十個程度なら変えたほうがいい。高々数千円でしょ。
まともに動かないと判っているものを動かそうとするよりはいい。
あんたの日割りの賃金よりも安いんでは。

ところでソフトウェアUARTは却下？
8MHz / 4サイクル / 38400bps = 52命令/bit
こんだけ余裕があれば作れないこともないと思うが。

受信するばっかりに忙しくて、他のことが出来ないよー

サイクルじゃなくてステートか。
半二重になるけど、誤差修正するならSUARTの方がやりやすい。
>>718
スタートビットのたち下がりだけ割り込み使えばいい。

元の質問が
>あくまでソフトが悪いと主張し続ける上の指示を
>撤回させる良い方法はありませんか？
なのに、受信を実現する方法をあれこれ考えても助けにはならんよな。
「良い方法はない」と真実を告げるしかあるまい。

ソフトが悪いっていうより、今回はハードが悪いと思うよ。

>>719
>スタートビットのたち下がりだけ割り込み使えばいい。
受信開始まではそれでいいけど、受信数が連続して多いと
そればっかりにならない?

>>722
何を流すのか謎だけど、流しっぱなしってことはないだろう。
38.4kで通信するという要求は果たせるんだから問題ない。
送信した後はこれだけwait取れ、って要求ぐらいは通るでしょ。
無茶をやるんだから。

典型的なデスマーチｗｗｗ

それはいってはいけないｗ


しかし部品を捨てるのがイヤでも買うのはＯＫなんだろうか？
いや、ハードウェアシリアルドライバを付けるとか…さ。

8MHzのICを捨てるって意味がよくわからないが
たとえば クロックを8MHzから7.68MHzに変えれるのは許されないの?
ちょっと処理は遅くなるけどな

何故H8みたいな何の特徴も無いマイコンを使い続けるの？

秋月のおかげでH8なら使えると思っているヤツが多いから。
いやな仕事は、そいつらに投げておしまい。

正直H8は時代遅れだよな。
まだPICとか使ってる方がマシ。
SHも中途半端、SH使うならAVRの上位かARMを使う。

日本に金を落とせよ。

5V系で速度もメモリもそこそこ、外部バスにDMA付きで
情報も集まりやすいし入手性も良い、別に使い続けてもおかしくない。

それでもH8はないわ

何か突然アンチががが
中途半端な要件というか隙間産業的な用途はスルーされている気がするな。

Ｈ８と同じ系列なら、ＮＥＣの７８ｋあたりだと思うけど、アドレスがバンクなんだよなあ…

78kって、何でバンクなの?　バンクはPC98だけで　もう十分なのに。
その点H8は、リニアで良いと思う。

アーキテクチャの違い。

まだPC98は稼働中だから
保守するための技術が途絶えないように

>>729
H8はレジスタを32bitで使えるから意外と速いよ
8bitのPICやAVRなんかと比べちゃなんねえ
少なくとも同クロックのAVRの半分以上の速度は出るんじゃねーの
PICなんかそのまた半分以下だし
32bit演算やらしたらAVRとも逆転する

32ビットの演算は滅多にしないから、普通にプログラムするとH8は
遅い。メモリ空間が16Mバイトもあるのは、この手のCPUでは珍しく、
uClinux を動かすこともできる。

今のところルネサスは将来もH8を継続するっていっているみたいだが、
RXが出てくれば、徐々になくなっていくだろう。H8は高いので
使うのやめたっていうのを何度か聞いたが、やめたいからかもな。

個人的にはR8Cがおすすめ、簡易ICEのE8aが使えるし、E8aが
なくても、シリアルI/FだけでROMコードがデバッガを使って
デバッグできる。秋月の新しいR8CボードにRS232Cケーブルと
電源をつなぐだけで、ROMのコードをHEWを使ってデバッグできるし、
E8aのコネクタも最初からある。ただし、秋月のボードの説明書には
シリアルI/Fを使ってのデバッグについては何も書いてない。

加えて、R8Cは結構使われているし、ルネサスはローエンドCPUは
今後もR8Cで対応すると言っているので、将来性もある。

普通に考えて16bit演算ならPIC24Hの方が速いし、32bit演算ならAVR32の方が圧倒的に速いだろ。
それ以前にARMの方が速いが入手性を考えたら現実的では無いが。

Basic

10 PRINT"ゆのきまさあきは、";
20 PRINT"オタク"
30 GOTO 10

>739
そうだね悪かったね

>>738
R8Cってアドレスがスカスカなイメージしかない
それこそAVRでも使った方が良くない？
SPIも5Mbpsまでみたいだし(AVRはtiny2313でも10Mbps)
よく知らないから間違ってたらごめんよ

>R8Cってアドレスがスカスカなイメージしかない
スカスカ？　 R8C/2DでもROM 128K RAM 7.5K 結構あるぞ。
SPIの能力についてはついては知らないなー。

AVRののGCCで、ROMコードをデバッガでデバッグできるのかな？
ROM書き込みGOでUARTにログ出力だと面倒なんだよな。

ライターもたいしたことないけど面倒に感じるな。AVRのWebページって
ライターのことばっかだもんな。

>>742
外部バス付きのAVRは約64KBまでのSRAM等を追加できる
ただアドレスが64KB内で共有だから外部64KB全て使えるわけではない

R8Cはアドレス1MBある割に実際使うエリアが少ない印象＝スカスカ

SPIはR8CではSSUって名前になってるらしいけど
転送クロックレート選択がf1/4まで、つまり20MHz/4、
対してAVRはf1/2の20MHz/2まで
外部バスのない種はSPIを多用する事になるから
このクロックは実行速度にそのまま反映されやすい

最短命令はR8Cが100nsに対してAVRは50ns
AVRはレジスタメモリ間は100ns単位になる
ただR8Cは16bitだしアドレッシング種類から言えば
かなり速そうだという印象はある

AVRのデバッグにはバグ付きのエミュレータやJTAGがある
arduinoとかもあってグルーなユーザーが多い

あと16bit演算はAVRは8bit+キャリーで2クロック、
レジスタのワード転送は1クロックで済む
100ns単位なR8Cとさほど変わらないはず

おまえらさぁ。
H8以上のマイコン使うならRT｀OSも使おうぜ。実際楽だし、処理量もほとんど変わらない。
なんでRT OSの話題って出ないの？

>>743
スカスカってそういうことね。R8Cはローエンドだからな、
めいっぱいメモリ使いたければM16Cを使うべきだろうな
R8CはM16Cとコアが同じだけどバス幅半分なので速度を
考えれば使わない方がいい。

SPIは使い方次第じゃない。外部バスがないのをSPIで
カバーするんだったら、最初から外部バス付きを選ぶな
自分なら。

JTAGがあるのは知っているが、使われているのか
Web見てもJTAGでデバッグしてますっていう記述は
あまり見かけない。JTAG ICE２って純正だと結構高いんだろう。

実際のところは、Write

>>746の続き

実際のところは、Write and GOのデバッグがほとんどじゃないのか。

>>746
まあほんとに使い方によるだろうけどさ、
外部バス使うのだと大掛かりになって数百円じゃなかなか作れないし
DIPやSOP辺りのMCUになるとシリアル速度は要の1つになるわけ
SDカードみたいな遅延の多いデバイスでも10Mと5Mじゃ数割程度違ってくる
それとデバッグなんて一応JTAGもあるけどシリアルで十分だよ
AVRは特に素直だからね

だからH8なら用途はまだ見出せる気はするけど
R8Cはこのクラスの選択肢としてはどうかと思った
8bitx2hのDACは魅力的だけどね

関係ないけど上のPIC24HでもSPIは10M限界なのね
40MIPSでDMAあるから効率は違う物だろうけど

＞Web見てもJTAGでデバッグしてますっていう記述は
＞あまり見かけない。
そりゃ，Webで嬉々として書いているのは殆ど（ﾄﾞ素人　&& 貧乏人）さんですから

>>748
シリアル速度とかSPIの速度が重要ってのはよく分からないな。
狭い範囲で有効なことを一般的なことと勘違いしているように見える。
具体的な使い方を教えてほしいな。

SPIで接続するのは、EEPROM,RTC,LAN,SDカードみたいな感じじゃない、
AVRのどのあたりのCHIPをイメージしているのか分からないけど、
速度が必要なLANとSDカードとかは数KバイトのRAMのCPUには適してないような。

それに、SDカードの転送速度が数割違ってとても重要なことのように書いてあるけど、
数割の違いなんて体感ではほとんど分からない。些細なことじゃないかな。

５MってのはR8CのSSUの場合の制限だね。UARTの同期シリアルなら
もっと高速に接続できそうだけど。確認してないけどね。

AVRが素直だからうんぬんはのは同意はできんが、ROMが少ないからなんとかなるのかな。

>>748
俺もシリアルで通信速度を気にする意味が今一分からん。
どんな使い方がしたいの？

具体的な使い方教えろって、
まるっきりAVRのライタしか思いつかない連中と同じじゃないかｗ
教えてやる義理もないし、同意しないならそれでいいよ

それと同じMCUに積まれてる同期UARTが
SPIより高速になる可能性はまずありえないね
R8Cがそうだと主張するなら実験して示してほしい
まあデータシート読めばすぐに無理だと判ると思うけど

>>752
何に切れてるのか分からんが、SPIでそんなに速度が必要なデバイスは無いだろという話しな。
どうしても速度が欲しいなら具体的に言えば他に解決策があるかもと思って聞いてるんだろ？
自分だけの少ない知識が全てだと思わない方がいいよ。
どうしても速度がいるならもっと高速な通信手段は何種類かあるんだし。

752ではないけど、
個人的にはグラフィックLCDを使う時に
漢字フォントをSPIのフラッシュメモリに入れることがあるので
SPIが高速な方がうれしいことはある。そこまでクリティカルじゃないけど。

あと、ピンポイントな話題だけど
SPIバスで接続するEthernet用のコントローラにENC28J60というのがあるけど
リビジョンによってはSPIバスのスピードが遅い(8MHz以下)とうまく動かないErattaがあったはず。
で、H8とかでENC28J60を使おうとしてはまった人が結構いたっぽい。

>>753
うーん、
インターフェースを問わなければって話をするなら
始めからシリアルなんか出てくる余地はないんじゃない？
必要かどうかなんて主観的な議論はしたくないなあ

超初心者です。
割り込み禁止フラグをセットしているときに外部割り込み要求（エッジ検出等で）が発生した場合、
その割り込み要求フラグをクリアしない限り、割り込み禁止を解除した直後に
外部割り込み処理が実行されますか？

>>752
ぶっちゃけ、ピン数が少ないからってシリアルの速度が
要だなんてナンセンスだと俺は思っている。　

また、SPIの速度の違いが、重要だとも思ってない。

別に教えてほしいとも思ってないが、なんて答えるかなと思ってんだが。
残念だが、最もつまらない回答だったけど。

>答えるかなと思ってんだが
答えるかなと思ってたんだが

の間違いね。 何か面白いやりかたがあるのかなって
僅かな期待もあったんだが。

>>756
される。
割り込みはIEと要求ﾌﾗｸﾞのandで、成立すればいつでも発生する。

フラグを置いておけないと、多重割り込みでも有効にしないかぎり
割り込み実行中に、別の割り込みを取りこぼすことになるし
それでは割り込み使う意味がない。

>>758
上から目線すなあｗｗｗ

>>759
丁寧なご回答をありがとうございました。

>>760

お前ら下々に話してやってるだけでもありがたいと思えゴミ

>>754
H8にSPIってあったっけ？

ない

マスクROM仕様ってどういう事？

>>765
マスクＲＯＭが入ってる。
というか、マスクＲＯＭが何者かは解ってる？

何者なんですか？

とりあえず…少しはググろうぜ。といってみる。うぃきぺに書いてあることでいいし。

そういやF-ZTATしか触ったことないな。
ROM発注するような…FLASHじゃアテにならんような用途って何だろう？

原子炉とかコスモクリーナーDに使ってるんじゃ

>>768
・ものすげー大量に使うので少しでも安くしたい
・はがされて中身読まれたら困る
とか

俺もMASK起こしたことはないのう
マスタ出す時に胃に穴あきそうだなあ…

>>765
インフルが流行るとラインでくしゃみとかして不良率が増えるので、
作業者がマスクして作ったROMということ。
マスクして作った分だけコストが上がる。

>>770
300万パーにしたことあるよ。

>>771
うわあ。つまんね・・・

俺が疑問なのはマスクROMって書き換えできないよね？
じゃあ、出荷時にどんな内容で書き込みされているの？
好きに使えないならROM無しとどう違うの？

というあたりですがどうでしょうか？

>>774
ググろうぜ…といっても、まあＲＯＭ発注を知らんと無理か。
ルネサスにプログラムを送って、そのプログラムで動く「製品」としてのマイコンを作ってもらって、ソレを買う。
書き換えできないからバグでも出そうモノなら>>772みたいなことになる。

で、いいかな

>>775

なねほど、そうでしたか。
ありがとうございました。

解決しました。
基板作り直し＞立ち消えになりました
有難うございました。

>>715
上位側は変更しない、という指示のためです。

>>720
数日かけてビットずれの原因が分かる資料を作って提出したら
納得して貰えました。

>>721
ハードまで追ってません。

>>724
>>725
「無事」終了フラグが遂行されましたよ。

柚木正章　ゆのき！！！！！！！！！！！！

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

>>777
いちお……　おめでとう？

しかし理解の遅い上司がいると工数が無駄になって仕方ないな。

H8なんですがメモリマップで内臓RAM2kがあり、とんで
さらに下に内臓RAM2kとあり、内1kはフラッシュメモリ用書き換え用
ワークエリアで残り1kがユーザエリアとあります。
このユーザエリア1kの部分はふつうにRAMとして使っても問題
ないのでしょうか？それとも何か特別な意味のある領域なんでしょうか？

ひょんなことからE8ｴﾐｭﾚｰﾀを手に入れたのでマイコン弄りを始めてみようかと思うのですが
H8tinyの系列かR8Cの系列、どちらの方が扱いやすいでしょうか？

資料の多さだとH8のほうが良さそうですが、R8cのほうがE8でのデバッグが容易などとい言う話も聞きますし・・・
あとはルネサスマイコンの機種がどう整理されていくのかも気になるところです

糞マイコン使うな。
半導体は、やっぱり東芝。

http://it.nikkei.co.jp/business/news/index.aspx?n=AT2G02001%2003092009&landing=Next

デジタル家電向けＣＰＵ、国内勢が規格統一へ

　富士通、東芝、パナソニックなど半導体・電機大手はデジタル家電や携帯電話に搭載する
新型ＣＰＵ（中央演算処理装置）の規格を統一する。基幹技術を共有化することで、一からソフトを
開発する手間が省ける。新型の台頭を機に国内勢が結束し、ＣＰＵ市場で圧倒的なシェアをもつ
米インテルの牙城に挑む。2012年度を目標に業界標準の実現を目指す。

　ルネサステクノロジ、ＮＥＣ、日立製作所、キヤノンなども参加する。早稲田大学の笠原博徳教授が
考案した省エネ性能に優れたソフト規格に対応する新型ＣＰＵを各社が開発し、性能を検証する。


デジタル家電や携帯電話のような組み込み用っていってんのに、なんでインテルなんだよ。ARMだろ。
大体、富士通、東芝、パナって、素直にルネのCPU使ってりゃええがな。今更なにしたいの。
ルネはおつきあい程度で参画するんだろな。これまでも携帯電話用エンジンの共同開発とかルネが中核でやってきたわけだし。
これ音頭とってるの経産省とかじゃねーだろな？

>>780
H8の、何だすか。
後ろの３桁なり４桁の型番言えば、そんなｱﾄﾞﾚｽの説明しなくても、知ってる人が答えると思うが。

あと「内蔵」。

　ニュースの元ネタがわからんので何とも言えんがインテルって書いたのは
記者じゃないの？

　技術的な元ネタはこれか？
ttp://japan.renesas.com/fmwk.jsp?cnt=press_release20080204.htm&fp=/company_info/news_and_events/press_releases

こっちか。
ここのOSCAR-APIに対応するCPUみんなで作ろうぜってことかな
ttp://www.kasahara.elec.waseda.ac.jp/index.ja.html

＞これ音頭とってるの経産省とかじゃねーだろな？

文科省かもしれないが大学が保有する技術シーズを民間に移転するという名目の
補助事業でご想像通りの税金無駄遣い事業だよ。

第五世代コンピュータ思い出すな

そうか、TRONチップがとうとう実用化されるんだな。
アルファプロジェクト再来！

どこが音頭とってるのかわからんが、
携帯電話エンジンの開発のように、民間発の共同開発なら大学のセンセなんかからめない。
理学やら、工学でも理論研究ならともかく、それ以外は企業の方がはるかに上ってことを役人は理解してない。
アホの一つ覚えの産官学の三位一体とか謳い文句にするのが好きなんだよな。
センセの下にいる実働部隊ってのはこれから、ここらの会社に就職しようっていう学生だろ。
ワセダの学生に体験入社かさせるのが目的か？

シグマプロジェクトだった。アルファ〜は実在の会社だわ;;;;

ttp://pc11.2ch.net/test/read.cgi/os/1148458561/l50

>>789
それじゃ。このワセダの笠原ってのは足折って入院ってか？

H32Bロケットができたりして

ルネはH8でもSHxでもそこそこシェアとってるし、覇権をかけてRXとか開発してる最中に迷惑な話だな。
富士通や東芝はともかく、これまで国内で組み込みプロセッサの強かった三菱と日立がルネつくってこれからってときに、はなはだ迷惑。
どーせなら、富士通や東芝のプロセッサやってるとこをルネに売却するほうが話は早くないか？これからでもRX開発に参画すると。
東芝は原発に軸足うつしてるんだからついでにフラッシュもエルピに売却すりゃどーよ。

>>780
RAMはユーザーが自由に使える。
flashのあの機能はROMエリアをRAMみたいに使えるよ。
でも、RAMの一部使うからそこ使うときは気をつけてねってこと

H8ってAVRやPICより高性能なの？

>>796
それは、ビット数やクロックの条件を同じにしての比較？

いまどき、もう、H8/300とかってあんまり見ない気もするけど。

新規に使うもんじゃないけど、秋月で数百円で売ってる
AVRやPICよりかは・・・高性能だよ
AVRやPICじゃ無理でもH8だと簡単に実現できることが結構ある
用途次第だからデータシートよく見て選ぶこと
外部バスのないH8はゴミかな

柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
柚木正章
お
た
く

購入価格を同じにしての比較じゃね？

PIC だっていろいろあるからなぁ

PICも16bitの高速版とかあるしな。AVRは知らんが。

H8は32bitレジスタが使える。
68000-MMU → H8

ビット数なら、PICは40ビットAｃｃが使えるな。

SHなら64ビットMACが使えますが何か？

>>804
おまえH8とPICの機能比べて恥かきたいのか?
あくまでもPICは8bitコントローラだろが。まっとうな16bitマイコンのH8と機能比較なんか持ち出してくるなや。
PICで、
外部バスは?外にDRAMつなげたいときどーすんの?
タイマは何チャネルだっけ?
間接アドレッシングしたいときどーすんの?
ホレホレ答えてみな

>>806
頭悪すぎ、空気嫁
PICでも32ビットはあるし適材適所。
H8が32ビット扱えた所ででかいメモリ空間を自由にアクセスするには遅すぎる。
16ビットPICの40ビットAccはその筋に特化してるからH8の速度じゃ到底無理な信号処理が出来る。
必要ならSHやSHDSPを持ち出さないと無理な処理だって出来る事もある。
DRAM使うだけがマイコンの仕事じゃ無いんだよ、パソコン坊や。

しかし適材適所はいいとして
Ｈ８／ＳＨのスレで伸びる話じゃないなあ

>>807

"機能"と書いてるところに何苦し紛れの処理スピードの話もってきてんだ。
機能と速度の違いもわからんってか?そもそも8bitと16bitの設計の違いはバス幅の違いより機能の差だ。
それを比較するオマエこそおつむ悪すぎなんだよアホ。
高速処理が必要な部分にH8ってアホかオマエ。適材適所考えられないのはオマエだろうが。マヌケ

>DRAM使うだけがマイコンの仕事じゃ無いんだよ、パソコン坊や。

使いたいのに使えない、結論:それはマイコンと呼ぶにはカタワチップだから
カタワチップだからマイコンは名乗らずコントローラと名乗ることにします←マイクロチップ談

ホレホレ
・外部バスは?外にDRAMつなげたいときどーすんの?
・タイマは何チャネルだっけ?
・間接アドレッシングしたいときどーすんの?

はよこたえてみ。

40bit Acc?まともな16bit DSPなら最低MAC+加算時桁あふれ8bit確保してて当たり前。何今更の機能自慢してんの。
これも速度関係なければソフトで回避対応できる。ハードウェアの機能ができて手も足もでないのと全く違う。

結論

間接アドレッシングもできないカタワチップに用はない

>>809
>機能と速度の違いもわからんってか?

だから馬鹿だって言ってるんだよ。
速度が必要ない？ｗｗｗ
なら、バンク切り替えでもI2ｃのSRAMでも繋げてエミュすれば６８Kなんてセコイ事言わずに
８ピンPICでさえ１６G乗っけたコアiと同じ事が出来る。原理的にはね。
４０ビットのAccだって、速度を気にしなきゃi4004でさえ実現出来る。
が、まっとうなH8でリアルタイムに信号処理が出来ないのにかたわのPICが出来るのは事実。
大体、レジスタのビット数の話をしてる所に無理やり機能を持ち出したのは、知ったかパソコン坊やのほうだろ

14V池沼を相手にしてはいかん。

>>811
何を極端な例を持ち出してんだ。馬鹿者
桁あふれ処理をSWでやるなんてことは普通にやるだろうが。
MAC+桁あふれまでを含めて最小システムクロックでやりたきゃはじめからDSPを選べ。
繰り返し処理まで含めて1クロックでやりたきゃマッチドフィルタをFPGAで組めや。そんなチョイスもできないのかおまえは。
で、
おまえがまさに例として挙げた、外部メモリを使うしかない処理であっても、
16MB以内なら、H8ならそのままバスにつないで、バスアクセスタイミングでふつーに処理できるわな。
PICではそれこそSRAMエミュとI2Cでやるしかなくてリアルタイムじゃほとんど実現不能だよなぁ。ゲラゲラ
あったま悪いなオマエ、何自分で墓穴掘って、PICじゃリアルタイム処理できない実例挙げてんの。
どーせオマエがリアルタイムに処理できないってのはH8用に最適化したソフトも組まなかったんだろ?
ま、こういうオツムじゃしゃーない罠。

>まっとうなH8でリアルタイムに信号処理が出来ないのにかたわのPICが出来るのは事実。

全ての処理でいえるならともかく、オツムかたわのおまえがたまたま遭遇した一例をもとに軽々にレスすんな、
オツムかたわの >>ID:1igJe7uBがやったらたまたまH8ではリアルタイムでは動かすことができなくて
同類カタワチップのPICでは処理できました
と言い直せや馬鹿者

あとな、メモリ保護機能のないPICでバンク切り替えだけでどうやって68Kと同じことできるか説明してみろ。
MMUの意味わかってんのかお前

>>813
>全ての処理でいえるならともかく、オツムかたわのおまえがたまたま遭遇した一例をもとに軽々にレスすんな、

頭の良いお前が遭遇しなかった上に想像も出来なかったからといって、そんなに悔しがる事は無いぞｗ


>あとな、メモリ保護機能のないPICでバンク切り替えだけでどうやって68Kと同じことできるか説明してみろ。
>MMUの意味わかってんのかお前

68KにMMUが乗ってるのかよｗ
漫画ばかり読んでないで、ひよっこはまずGEBでも読んで勉強しろ。

>>812
14V厨というよりは、
どっちかっつーと「PICは暴走しない」厨に似ているような。

なんにしても。H8よりPICが高性能だと思っているなら
黙ってPIC使ってりゃいいのに、わざわざH8スレに来て
挑発的な書き込みするあたり、荒らし目的としか思えん。

こんなやつ、相手にするのも荒らし。

季節の変わり目はおかしいのが出てきやすいから仕方ないだろうね

>>814

>68KにMMUが乗ってるのかよｗ

こいつ神聖バカだな。
68kにUnixが載って、286にUnixがナンデ載せられないか、一から勉強し直せカス
話にならんなアホ過ぎて

Ｈ８はなぜ１６ビットになっても８のままだったのだろうか。
ＳＨってSuperHだのに、なぜ１から始まったのだろうか。

>>817
むか〜しXENIXてOSがあってのう…

ということで努力と根性でどうにでもなるのですよ。

68kの話は、MMUとスーパバイザモードを混同してるのかなぁ？

>>819

情報処理試験勉強をゼロから高卒と一緒にやり直せ
タスクごとのメモリの独立性はソフトウェアだけでどうにかなるとでも思ってんのか。

>XENIX

だからこそのなんちゃってUNIXだろうが。

MMUという明確なものが乗ってるのは68030からみたいだな。
って、もはや、日立関係なくなってるな。

>818
H8についてはH16というマイコンがかつて存在したため。
68000を高機能化して周辺機能集積をしたようなチップ。
CPUレジスタをリングバッファ的にたくさん切り替えて使えた。

ちなみにH32はTRONチップのことで、当時の日立はいち早く
三菱と(ついでに富士通と)提携してた。
Gmicro100がM32、Gmicro200がH32、Gmicro300がF32だた。

SHについては赤鬼さんに聞いてけろ。

>814
68000にはMMUはありません。
68010で仮想記憶がサポートされました。
68020には外付けのMMUチップMC68851があり、Macintosh-IIでは
optionだったはず。
68030でMMUが内蔵されました。めでたしめでたし。
ちなみに当時の日立は68000とCMOS版の68HC000を作ってました。

そういや東芝も68000のCMOS版を作ってなかったかな

>>823
�d〜、そしてへぇボタン連打
H16って初めて知った。ぐぐってもほとんど当たらないのが悲しいが。

>>824
あったねえ。

>>825
あれは日立とモトローラが喧嘩した結果、闇に葬られてしまいました。
そういや昔いた所にマニュアルだけおいてあったなあ…

なんで喧嘩しちゃったのですか?
モトローラの勝利でしょうか?

>825
つ　ttp://www.itofamily.com/ito/collections/16bit/h16/index.html

>>828
�d〜
そのまま育っていればＨ８と並んでおもしろそうなアイテムではあるな…

H8は秋月の据え置き価格が異常なだけで
適正に直せば500円ぐらいじゃないかと

ルネは新規にH8作ってるのかな?在庫品だけ?
新規に生産するなら、1世代遅れぐれいのプロセス使ってくれればまだまだ省電力になるのに。

>>831
今時のロジックを１世代前のプロセスで？
１世代前のロジックを今のプロセスで？

今時のタイニーを激遅クロックで使うほうが幸せじゃなかろか

>>832
H8のロジックがなんで今時なんだ。

オタクの柚木正章です。よろしくな。
http://changi.2ch.net/test/read.cgi/otaku/1241858991/

RXにVシリーズの精神も盛り込んでね

NECエレとルネサス、事業統合後の会社名を決定
〜「ルネサス エレクトロニクス」へ

http://pc.watch.impress.co.jp/docs/news/20090916_315894.html

Vシリーズの精神って何？

V25,V33,V55も含む？

Ｖ３０のとき、日の丸マイコンのロードマップあったよね。Ｖ９０ぐらいまであったかな。

すいません

gccのCで3069やろうと思うのですが、
秋月のCD-ROMのgcc(ver2.95)って古くないですか？

新しいんだと何か拙いのでしょうか、エロい人おねがいします

すみません。教えてください。
H8/3069, mode5(内蔵ROM,RAM有効モード)で、回路を作ったのですが、
動作が変なのです。ヒントをいただけないでしょうか?

1. main()と、関数だけ(タイマー割り込みなし)だと、main()動き続ける。。
2. main()と、タイマー割込を有効にすると、main()が0.1秒くらいで止まってしまいます。
　　しかしタイマー割り込みは正常にかかり続けます。

測定例
・LEDをon/offさせる関数、LED1を作ります。
・main()で、関数LED1()を呼び、LED1をon/offをさせてオシロで波形を観測
・timer1()でも、LED2を直接on/offさせてオシロで波形観測　　とした場合、

1. main()だけ(timer1()を禁止)の場合
　　ＲＥＳＥＴ　＿＿＿＿｜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
　　ＬＥＤ１　　＿＿＿＿＿｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜・・続く

2. main()+timer1()の場合
　　ＲＥＳＥＴ　＿＿＿＿｜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
　　ＬＥＤ１　　＿＿＿＿＿｜｜｜＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿　0.1secくらいでmainが止まる
　　ＬＥＤ２　　＿＿＿＿＿｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜続く・・・・

という感じです。さらに、外部バスのHWR,LWR,AS,RDは、
どれを見ても常にHのままで、まるでシングルチップモードのような感じです。
どうぞ宜しくお願いします。

とりあえず回路図とソースをうぷしろよ
笑ってやるから

Vシリーズの精神というとやっぱ8080エミュレーションモードかな

>>838
俺は最新版？にオリジナルパッチ当ててるな

>>839
Timer2の周期が早すぎるんじゃね
あと、割り込み処理が腐ってるとか

割り込みフラグを消してないに１０メセタ

839です。直りました。ありがとうございます。
>>843が「腐ってる」と言うので、リストをプリントアウトして、臭いをかいでみましたが、
特に臭いところはなかったです。
>>844
timer1はちゃんとTGFA=0にしています。その証拠に、10ms毎に正しくLEDがon/offしますので。
ところが、実はtimer2も走らせていたことを忘れていました。
timer1=10ms周期、TSTR=on、割込内でTGFA=0実施済み、割込登録済み、
timer2=100ms周期、TSTR=on、割込内でTGFA=0実施済み、割込登録「忘れ」　→　TPUは動いているのに、割り込みかからず。
で100ms後にmain()に戻れなくなってしまった。ということで、僕がアホでした。

ありがとうございました。大変助かりました。
今からプログラム再開です。

>>842
そうですか、オリジナルパッチを当てるほどスキルはないので
このままでやります

KPITってとこがHEW含めてフリーのを配布してたな
今でもやってると思うけど。

RAMが定義通りに並ばなくてくずおれた覚えがある

>>838

だ・か・ら

何でHEW使わないんだよタダだし、gccなんかより遙かにコード品質もいい,
call walkerもついてる。しかも、事実上期限制限なんてないに等しい。

>>838
そもそもHEWはVisual StudioやEclipseなどと同様に、統合開発環境(IDE)
であって言語コンパイラではない。　したがって、生成されるコードの
品質となんら関係ないし、影響も与えられない。

KPIT GNU ToolsのgccはHEW上でも走るが、gccコンパイラ自体はコマンド
プロンプトからも起動できる。 Visual C/C++についても同様。

６０日の使用期限があるので躊躇しています

これだと
http://sourceforge.jp/projects/tsuru-develop/
http://www.alpha.co.jp/biz/products/knoppix/download/pamphlet/pamphlet_edu8.pdf

3052ができるらしいので、ゴチョゴチョして3069に使えないかなあと思っています

windows用のバイナリがほしいなら、GDLでいいじゃねえの

今日も半日、入力が取り込めないバグで悩みました。
原因は、P1.PORT.BIT.B1　を、
　　　　P1.DR.BIT.B1　にしていました。
このPORT, DRをなんとかでせませんか?→日立
3069では同じDRで良いのに、なんでH8SはPORTとDRで分かれなきゃいけないの?
使いにくいな〜もぅ。イライラします。

はぁ〜。

DRがライトで、PORTがリードだっけ？
ロジック的には、いちいち１つのレジスタに書き込み読み込みを切り替えてさせるより
パラにアドレスバスに繋いでしまうほーが楽だしなあ。って、そんな設計屋の思想は知らんかしらんが。

入出力をいちいちポートで書くのはめどいから、私は大抵defineでラベル化してしまうな。
ラベルのdefine書くときに入力だけ、出力だけ、って並べておけば間違わないし。

周辺ロジックの設計思想のムラは結構前から言われてるような…

そもそも3048系(F1,3052)と3067系(3068,3069)という
似て非なる石を出す意図がわからん。
どっちかひとつでいいのに。

ROM/RAMの容量から言って、3067系があれば、3048は要らないと思うな。

>>849
何をくっだらんことにちゃちゃいれてんだ糞野郎。
gccのかわりにVisual Studio使えとか普通にいうだろうが。
わざわざgccの糞品質で、スタック容量も手計算でやるしかない言語環境で
せいぜいシングルタスクのコード書くのが関の山かいテメエはよ。

>影響も与えられない。

統合環境ならではのcall walkerを使えるかどうかで作ったコードの信頼性を向上させることができるね。
んなこともしらんとアホかお前は

ほぼ、ユーザが望む全てを無料で提供してくれてるHEWを使わずにgccやらKPITから言語環境として検討するなんざ、
本末転倒なんだよ馬鹿たれ。cpuメーカが開発環境を無料提供してくれてるのに何のためにgcc使うのか説明してみろカスの >>849

汎用性のない技術を学ぶだけの価値がルネサスのマイコンには無いってことだろ。
簡単なことじゃないか。

統合環境に使われてる人が

そういう話はこちらで

H8/SH gcc vs 純正コンパイラ
http://science6.2ch.net/test/read.cgi/denki/1183216226/l50

>>860
そのスレ、ゴミカスが建てたネタスレだから、こっちで議論したほうが有意義だよ。

>>856-857
そもそも、ルネサスの純正コンパイラやHEWって、実際のところKPITにオフ
ショア開発で丸投げしているんじゃないの？　わざと最適化レベルを変えて
純正コンパイラの価値を相対的に底上げしていると言うか、フリーのgccの
方をわざと下げていると言うべきか。

C言語なんて、詰まるところ汎用アセンブラなんだから、gccでも何でも
マルチタスクのコードなんていくらでも書けるだろ。JK

ルネサス純正コンパイラが無償提供されているというなら、使ってやらなく
もないが、所詮ルネサスのマイコンじゃあ多少最適化したところで知れてる
し、コンパイラの最適化なんかに頼るより、一度アセンブラのソースコード
吐かせて、手作業で最適化した方がマシ。

こんなことで熱くなるような変な連中がユーザなのかぁ・・ｼﾐｼﾞﾐ

>>862
こんな知ったか厨を相手にしてたらコストアップは必須だな。

>862
ルネサス純正コンパイラ　と一絡げにすることがまず間違い

最適化の話は昔から嫌というほど出てくるが、
具体的な例を見た記憶がない。

>>862

>C言語なんて、詰まるところ汎用アセンブラなんだから、gccでも何でも
>マルチタスクのコードなんていくらでも書けるだろ。JK

おまえほんとにアホの極みだな。全く理解してないし、まるでRTOSのかけらも使ったことないことがもろわかり。
アホのくせにそれを反省もせず。糞の役にも立たんレス返すだけ。恥を知れ。
gcc使ってマルチタスクのコード書いてスタックの使用量どうやって見積もるか言ってみろカス。
HEW使えばcall walker でちゃんと計算できる。それすら知らずに何をぐだぐだ戯言レス入れてんだ糞が。
gccで使えるcall walkerに匹敵するスタック量計算ツールあったら挙げてみろ馬鹿

>ルネサス純正コンパイラが無償提供されているというなら、使ってやらなく

無償提供なんだよ糞が。

>所詮ルネサスのマイコンじゃあ多少最適化したところで知れてる し、一度アセンブラのソースコード
>吐かせて、手作業で最適化した方がマシ。

やっても無いことをさも経験あるようにかたるなうじ虫
gccとルネサス純正コンパイラのコード比較もしたことないお前が笑わせんなバカ


>>866
だいたいgccの実行速度ははルネサスコード比7掛けだ。
イエローソフトもそういうベンチ結果をサイトに記載してたことすら知らねえのか。

また再インストール/VMでフル機能に戻るキチガイか。

教えてください。

マイコンにLEDがつながっています。
何かのイベント(異常とか)を検出したら、
処理をしながら、このLEDを点滅させたいです。
どのようなプログラムを書くのが定石でしょうか?
今は、

main(){　で、
　　通常処理を行う

　　もしイベント==yesなら
　　　　もしカウンター++が50000になったらLED on
　　　　そうでなくて、もしカウンターが100000になったらLED off
　　　　そうでなくて、もしカウンターが100001になったらカウンター=0
}
のようにして、ひとまず動いています。

が、通常処理の内部に待ちの部分があり、
待ち無し、0.1sec待つ、0.5sec待つなどに変化します。
その長短によって、LEDのoffの時間が変化してしまいます。

普通はどのようにプログラムするのが定石なのでしょうか?

WDTは使えないの？

ありがとうございます。WDTですか。
今使ってるH8 (3069)に内蔵されているか調べてみます。あったかなぁ...

gccの__attribute__でeightbit_data,tiny_dataとか指定できるんだけど

>>869
ITU H8 でググれ
意味が判らなかったら初心者本読んで出直せ

なんかバカとヤクザが混ざってるよな
このスレ

なんで7,8年前の２ちゃんねるみたいな人ばっかりなんだ。
脳みそが停止してんのかね？

>>869
割り込み一切抜きで、メインループにカウンターだけ置いて時間を見てるのか？
なんかPICみたいな作り方だなあ。

どっかのタイマーを１つ食ってカウンター作るほうが幸せな気がする。

そういえば…密かに(?)　>>1 に
「特に初心者の人には親切丁寧をモットーにお答えしますよ。 」
と、書いてある件。

869です。
みなさん、ありがとうございます。
タイマーがあるのは知っていますが、どのようなときに使うのかわからずにいます。
というか、タイマを使うと何が嬉しいのかわかりません。
以前一度トライしたんですが、全然動かなかったので、使わないようにして
メインで数字を++してやっています。
main外部のタイマーでやっても、そのタイマーに行ってLED onして0.5sec、offして0.5secの後
mainに戻ってくればよいのでしょうか。
その間、スイッチとかの取込ができなくなるのは同じだと思います。

>>878
タイマーの使い方はググるほうが正確に出てくるが、簡単にいうと
（他の割り込みで待たされない限り）クロックと同等の精度が出る割り込み周期が作れる、というのが一番のメリット。

そしてなんで0.5sec「待つ」ことにこだわるのか。
タイマーは毎回周期ごとに発生するんだから、割り込み発生でonだけして帰ってくる、offだけして帰ってくる、でいいじゃない？
もしくは、精度が高いわけだから、メインで読むためのカウンタをタイマー内でカウントアップさせればよいじゃない？

とりあえず「その場で待つ」という考え方は激しく排除したい。
数十ステートとかいうレベルの通信のための１ビット待ちぐらいではやるけど。

869です。
>>879
ありがとうございます。お手間をかけてすみません。
おかげ様で、プログラムがだいぶスッキリしてきました。
PICのときは、delay_ms()というのが使えて便利だったんですが、H8にはないみたいなので、毎回自分で考えています。

void timer(){　　　/*タイマーサブ　*/
　　caunt++;　　　　/*インクリしてすぐ戻る　*/
}

main(){
//　　通常処理

　　if( EM==false)begin　　　/*まだ異常が出ていたら　*/
　　　　LED(1);　　　　　　　/*LED on　*/
　　　　while(caunt<50){}　　/*10ms*50=500ms待つ　*/
　　　　caunt=0;　　　　　　　/*タイマークリア　*/
　　　　LED(0);　　　　　　　　/*LED OFF　*/
　　　　while(caunt<50){}　　/*0.5s 待つ　*/
　　　　event=0;　　　　　　　/*異常を消す　*/
　　}
}

これから出かける用事があるので、また夜か明日書き込みます。

caunt　となっｗｗｗｗ

oh,miss spell

>>880
とってもPICなコードだなあ。
まあ規模が小さいうちはその場待ちでもいいんだろうけど。

割り込みのほうのフラグクリアがないのは便宜上と解釈して…

　　if( 異常なし ){
　　　　caunt=0;
　　　　// 通常時の処理
　　}
　　else{　　　　　　　　　　　　　 //異常あり
　　　　// 異常時の処理

　　　　if (caunt<50){　　　　　　//最初 0.5sec
　　　　　　LED(1);　　　　　　　　//LED on
　　　　}
　　　　else if (caunt<100){　　　//次の 0.5sec
　　　　　　LED(0);　　　　　　　　//LED OFF
　　　　}
　　　　else{
　　　　　　event=0;　　　　　　　//異常を消す(異常が消えた時点でカウンタはクリアなので上限確認無し
　　　　}
　　}

とかじゃいかんのかしら？
これならＬＥＤ操作しながらその他の処理もできるが。

メインは
blink = (異常あり？）;
だけにして
割り込みの中で
if ((caunt++ & 0x40) && blink) {
LED(1);
} else {
LED(0);
}
とかなんとかってやっちゃうかな．50じゃなくて64カウントごとに動くけどね

>>884
> 50じゃなくて64カウントごとに動くけどね

cauntのカウント値を0から49の範囲として良ければ、点灯状態
を保持する変数を追加して

static BOOL bTurnOn;

　　if(blink)
　　{
　　　　if(++caunt>50))
　　　　{
　　　　　　caunt=0;
　　　　　　bTurnOn=TRUE-bTurnOn;
　　　　　　LED(bTurnOn ? 1:0);
　　　　}
　　}
　　else
　　{
　　　　bTurnOn=FALSE;
　　　　LED(0);
　　}

とかかな。　最後のelse〜は、メインルーチン側でblinkフラグを
書き換えるタイミングによって点灯したままになるのを防ぐ為。

汎用性を考えれば、通常はLED点灯/消灯のフラグと、LED点灯時のみ意味を
持つブリンクON/OFFフラグとを、それぞれ別に用意すると思うな。

これでどう?

LED(caunt++ < 50);
caunt = ( (blink==0) || (caunt>=99) )? 0xff : caunt;

>caunt
もう許してあげてｗｗｗｗｗｗ

>>867
KPIT gccもHEWで動くから、コンパイラや、デバッガの機能じゃなく、HEW
単体でできることなら、KPIT gccでもできるね。　call walker って、ルネ
サスのデバッガの機能だろ？　統合開発環境(IDE)、コンパイラ、リンカ、
デバッガがそれぞれ別のプログラムということすら知らないようだな。

シンボルテーブルの互換性があるかどうか知らないが、ソースデバッグは
できなくても、KPIT gccで生成したコードをルネサスのデバッガでデバッグ
(トレース実行)することは可能だろう。(逆もまた可)

イエローソフトといえば、ずいぶん昔に秋月ボードのおまけコンパイラが
使い物にならなくて、H8の開発ボード付きコンパイラを買ったけど、今でも
あんな商売が成り立っているのかなぁ？

call walkerがデバッガの一機能ってアホかお前は。使ったこともないのに何寝言ほざいてんだまったくよ。
じゃ、call walkerでgccのコード使ってスタック量見積もれるかどうかやってミロや馬鹿野郎。
手順をちゃんとここで明示しろ。話はそれからだ。

>KPIT gccで生成したコードをルネサスのデバッガでデバッグ
>(トレース実行)することは可能だろう。(逆もまた可)

言ったかぎりはその手順をここではっきり示せ。

逃　げ　る　な　よ

>>ID:9FUORgahは

gccのコードで call walker 使える方法を示してくれるそうな
実に楽しみ。ワクワク

>>888

>ソースデバッグは
>できなくても、KPIT gccで生成したコードをルネサスのデバッガでデバッグ
>(トレース実行)することは可能だろう。(逆もまた可)

C言語使っててソースレベルデバッグできずお前はいったい何をトレースするつもりだ馬鹿たれ
呆れるね。

呼び出し関係を静的トレースしてスタック使用量出すには

・コーリングコンベンションが判っているのでそれに一致するポイントを
　関数と見なして呼び出し時と関数内スタック消費を算出する
・シンボルテーブルから関数位置を得て、以下略

のどっちかになるんでないの？

H8最近また小さくなったの出なかった？

KPITか…
Aoneのデバッガでも保証無しでなんとか対応してくれたから何とか使えるが
出てくるコードがどうにも使い勝手わるくてたまらんな。

>>889-892
嬉々として、スレ上げてまで、バカ丸出しだなぁ。

Call Walkerのマニュアルを読んでみたが、大層な名前が付いているが、トレースしてスタ
ックの実際の使用量をリアルタイムにモニタできるのではなく、コンパイラが出力したスタ
ック情報ファイルを辿って足し算するだけの、予想以上にショボいオマケソフトのようだ。

ttp://documentation.renesas.com/jpn/products/tool/apn/rjj06j0073_callwlkr_ap.pdf

要は、ルネサスのコンパイラは、通常のコンパイラが生成するMAPファイルやLSTファイル
の他に、レジスタの一時退避領域や、ソース上では名前が割り当てられていない一時変数
を含めて、個々の関数内でどれだけスタックを使ったのかという情報を、スタック情報
ファイルとして出力することで、それを別のツールで表示させているに過ぎない。

C標準ライブラリについては、おそらく、あらかじめルネサスのコンパイラでライブラリの
ソースをコンパイルした際に生成されたスタック情報ファイルを参照しているのであろう。

スタック情報ファイルがない、または生成されないアセンブラや他のコンパイラで生成
されたオブジェクトやライブラリとリンクした場合、そのオブジェクトやライブラリ内の
関数でのスタック消費量は判らないが、11/16ページに掲載の『アセンブラプログラムの
スタック使用量』と同じことを、gccのコードに対して登録してやればよいだけ。

再帰呼び出しされる関数のように、ネストレベルで異なる関数のスタック消費量が正しく
算出されるのか非常に気になるが、おそらく上記のような関数の依存関係を辿って単なる
足し算しているに過ぎないであろうプログラム内部構造から、無限大となるか、単に1回の
ネストという前提で計算しているか、どちらかであろう。

ところで、処理中に多重割込が発生する状況を考えれば、仮に関数レベルでの静的なスタ
ック消費量が判ったところで、どれほどの意味があるの？

スタックサイズは、多重割込発生時でもオーバーフローしないように十分な領域を取るのが
普通だし、数バイト単位でスタック切り詰めるような綱渡りの設計はしない。

>>896
気持ちは本当によく分かるんだが、基地外を相手にしないようにしてはもらえないだろうか。
そいつは他スレでも全く同じ真似してて、相手にしてる限りいつまでも居ついて非常に
ウザいんだが、完全スルーしてれば消えるんだ。

もうすぐ日付が変わる。そこからでいいから、何とか頼むよ。

>>896

結局、あろう、だろうの連発かよ。
はよgccのコードでcall walker 走るようにしてから言えや
デバッグツールなどと勝手にほざいてアホの極みかお前は、

んで、

>ところで、処理中に多重割込が発生する状況を考えれば、仮に関数レベルでの静的なスタ
>ック消費量が判ったところで、どれほどの意味があるの？

>スタックサイズは、多重割込発生時でもオーバーフローしないように十分な領域を取るのが
>普通だし、数バイト単位でスタック切り詰めるような綱渡りの設計はしない。

多重割込みだろうが、排他割込みであろうが正確なスタック量を事前に見積もるなんて当たり前だろうが、アホ。
正確なスタック量も見積もったこともなければ、まともに組み込み用のコード書いたこともないゴミ野郎だからこそ、
言語仕様に忠実で無料であることとだけにメリットのある教育用コンパイラのgccなんぞをはずかしげもなく、
コード品質最優先の組み込みコンパイラに使うなんていう戯言ほざけるんだろうがな。

>数バイト単位でスタック切り詰めるような綱渡りの設計はしない

出た出た。こういう怠慢を指摘されたことに反省もしないアホにおきまりの台詞。
こういう奴に限って案の上マスクちょんぼで仕損出したりするのは世の常

アホさらしあげ。はよ大見得切ったんだからgcc のコードでcall walker動作するようしてみせろよ。
どーせだれも使わんけど。

call walkerって関数ポインタに対しては計算出来ないとかなかったっけ

gccでも関数毎のレジスタのpush数とかフレームサイズとかの表示はやれば出きるでしょ。
やるんだったら、asmのソースに埋め込む感じになるのかな？(armとかはやってる）

複雑怪奇な関数群の塊を使ってるとcall walkerが必要ってのもわからなくもないが...

Linuxのソースには checkstack.pl ってのがあるらしいけど
H8とかSHでは使えないのかね

フレームサイズの計算だけみたいだね。レジスタの退避数とかは誤差？

そういやカウンターのひとはどうなったのだろう

>896
>ところで、処理中に多重割込が発生する状況を考えれば、仮に関数レベルでの
>静的なスタック消費量が判ったところで、どれほどの意味があるの？

MRやHi(ITRON)のマニュアル見てみたらどうですか？
call wakerの値をベースにスタックをどれだけ設定すればよいか書かれて
いるよ。
確かに多重割り込みが起こる場合には、何重になるかまでを考慮する必要
がある。　MRのある意味隠れ機能だと思うけど、多重割り込みしない
使い方があるので、それにするとスタックを少なく設定することが可能には
なるよ。


9FUORgahさんも指摘しているけど、静的なスタックサイズをわからないまま
どうやってそれぞれのスタックサイズを決めるというのでしょうか？
まさか、スタック領域に固定コードを書いて、実行後にどこまで使われた
かを見て、そのサイズ＋αという方法ですか？

そんなに厳しい条件なら、俺はスタックチェックのコードを埋め込むこと、考えるな
使用メモリ（スタックとか）の見積りは仕様である程度は判断できると思うけど

話を切ってしまい、すみません。教えてください。

例えばH8の3069で、
数値の計算は、bit幅の長短で速度が変わるものでしょうか。

>>905
アセンブラというか、命令セットのレベルでの話よね？
とりあえず
ルネサスのサイトいって、H8ファミリーのソフトウェアマニュアルの
ところにあるドキュメントに、命令実行ステート数が書いてある。

内蔵RAM上だけの演算ならほとんど変わらないのでなかろか。

ありがとうございました。
と言うことは、ロングイントもバンバン使っても大丈夫そうですね。
僕自身がセコいためか、高速化のためにと、チャーばかり使っていました。

>907
データサイズによっては、演算に使うデータのロードやストアの速度差が多少は響くこともあるかもしれない。
命令単体じゃなく、プログラム全体では。

と、役に立たないかもしれない横槍。（もしくは混乱させるだけでまったく役に立たないゴミ情報かも？）

俺も以前は「bit数が少ないほうが高速になる」と信じていた。
だから変数は極力charで取って・・・・などね。
しかし一番早いのは、そのマイコンに合ったbit幅を使うことだとわかっいからはも
on/offフラグでもunsigned int (16bit)で、贅沢に使っている。castの手間も省けるし。
signed も素直に使う。昔はsignedも遅くなると思って、unsigned で工夫したけど、
疲れる。H8なら速いので、気にせずにバンバンやろう。

ただ注意しているのは、なるべくfloatを使わないようにするだけ。

ADDとSUBで直値だとB=1,W=2,L=3っていうステートのズレがあるが、それでも２ステートしか変わらんしねえ。
いちお、16bitコアだから、16bitで納めるってのが基本かしら。

これだからCしか出来ない奴は…

RXとかになると、たとえば足し算（ADD）
LONGしかなかったりしますね。
速度は、データ長ではなく、なにとなにの演算かに
よりますね。マニュアルにはパイプラインのDステージ以降の
マイクロオペレーション数によるものらしい。

>910
＞ADDとSUBで直値だとB=1,W=2,L=3っていうステートのズレがあるが、それでも２ステートしか変わらんしねえ。
その速度差だと、命令フェッチ時間の差が実行時間に直結してるんじゃない?

>>907
>ロングイントもバンバン使っても大丈夫そうですね。

はぁ?
あくまでも、ウェイトに無関係の内部RAMを使う場合を言うが・・・
特にサイズを意識する必要がない限り
コンピュータは語長サイズで扱うのが最も高速
つまり3069なら16bit
データバスが何ビットか考えてミロ

>>909
>だから変数は極力charで取って・・・・などね

8bitコンピュータなら正しい。

>昔はsignedも遅くなると思って、unsigned で工夫したけど、
昔の情報処理の2種。今はなんて言うか知らんが、なんのために補数を使ってるかっていう一から勉強し直せ

>なるべくfloatを使わないようにするだけ。
それはH8でデータバスが16bitだからだ。32ビットデータバスなら32ビットfloatを使うことは少しもおかしくない。
ただし数値演算ユニット)搭載のプロセッサで64ビット演算にしか対応してなくてdouble よりも、
floatを明示すると速度低下するプロセッサもある。

>>914
>　32ビットデータバスなら32ビットfloatを使うことは少しもおかしくない。

バスが32ビットだからといって32ビットfloatがハードで扱えるとは限らないから整数演算で済ます事は良くある。
そもそも、バスが32ビットだからといって最適な語長が32ビットとも限らない。

>>915
>バスが32ビットだからといって32ビットfloatがハードで扱えるとは限らないから整数演算で済ます事は良くある。

お前はアホか。
整数で済むダイナミックレンジの計算になんでfloat使うんだ。
>>909が心底バカでも無い限り、なるべくfloatを使わないのはdoubleに対してだろうが。
常識持てや。お前が何の修飾詞も書かず"バス"と書いてるところをこちらが"データバス"と察してやってるのと同じようによ。

>バスが32ビットだからといって最適な語長が32ビットとも限らない。

ハーバードアーキの場合かよ。しょーもない揚げ足取りしてんなカス
設計デフォルトのデータサイズにあわせてレジスタサイズ、バスサイズを決めてハードウェア設計しないことには
CPUの設計ができないんだよマヌケ。
語長==ワードサイズというのはそのCPUが最も効率よく扱える情報量の長さだ。
バスが32bitで32bitが最も効率よくないCPUなんてのは欠陥設計だ。
もっと言えば、こんなものを32bitコンピュータとして販売してるなら誇大広告だ。

>>916
>　整数で済むダイナミックレンジの計算になんでfloat使うんだ。
> >>909が心底バカでも無い限り、なるべくfloatを使わないのはdoubleに対してだろうが。

ハードで32ビットfloatを計算出来ない場合、32ビットや64ビットの整数の方が圧倒的に早い場合が多いから
整数の方がダイナミックレンジが狭いとは言えない。目的次第だ。

>ハーバードアーキの場合かよ。しょーもない揚げ足取りしてんなカス
それしか思いつかないのかよｗ

>バスが32bitで32bitが最も効率よくないCPUなんてのは欠陥設計だ。
>もっと言えば、こんなものを32bitコンピュータとして販売してるなら誇大広告だ。

お前の頭の中ではなｗ
バス幅と語長を合わせなきゃいかんなんて制限はお前の頭の中だけだ。
語長より大きいバスや小さいバスを持つCPUは幾らでもあるし
お前の頭より欠陥は少ないと思うぞｗ

お前ら朝から元気ですね

>>917

>整数の方がダイナミックレンジが狭いとは言えない。目的次第だ。

お前ホントばかか。高校の普通科の情報処理とやらからやり直せ。
32bit int の数値精度を犠牲にして、指数部を設けてダイナミックレンジを大きくしてるのがfloatなんだよマヌケ。
笑わせんなアホが。朝から寝ぼけてんのか。

>バス幅と語長を合わせなきゃいかんなんて制限はお前の頭の中だけだ。

これをいうならデータバス幅とレジスタ長さだろうが。
語長というのはCPUがもっとも効率的に扱えるデータ長のことだ。
一番都合がいいとメーカが主張してるんだからそのデータサイズでアクセスする場合最も速度が速い
上でも言ったが、アドレスバスなのかデータバスなのかちゃんと書けよ。アホ学生

>語長より大きいバスや小さいバスを持つCPUは幾らでもあるし

メーカ xx bit プロセッサと命名してる場合、標準レジスタサイズ、データバス幅、語長はxx bit。
語長より大きいデータサイズアクセスは、所用クロックにおいてペナルティがあるのが一般的だ。
いくらでもあるというならx86のように拡張につぐ拡張を重ねたcpuや、ハーバード以外の、組み込み限定で上げてミロや

>>ID:1LKlHEn3 コイツってスタックサイズも見積もらずにKPITだのgccつかうだの戯言ほざいてたシングルタスク限定コードした書いたことのない >>ID:9FUORgahじゃねーのか?
gccでもcall walker早く動かせよ。それともトンズらのチキン野郎か？よかったねぇネットじゃ誰か特定されなくて、なぁチキン野郎

基地外に水をやらんでくれよ・・・せっかく静かになってたのに

なんで逐一、バカだカスだと宣言するのだろうか。定型文かマクロなのだろうか。

さておき、符号付きの場合、符号ビットを抜いて符号付き31bitデータとかいうのかしら？

浮動小数点演算を使うと、高速なFPUを内蔵するチップでない限り、整数演算より大幅に遅くなるだろ。
floatを使わないってのは、そういう意味だと思うんだ。

doubleよりfloatが遅くなる場合が云々、って意味じゃないと思う。

>915
即値を扱う場合、レジスタ長なみのデータサイズを扱えば命令長が長くなるか命令数を増やすしかないから、最低でも1ステップは遅くなるな。
SHのごとく、即値を扱えないようにして必ずレジスタ間接を強要するアーキテクチャなら無関係だが。
即値以外の、レジスタ直接なら916の言うとおりだろうが...

32ビット固定長命令のMIPSやPowerあたりだと、32ビット即値を一命令では扱えないから
命令を分割して2命令にする分だけ遅くなる、とかな。

>917
ダイナミックレンジと演算速度を混同してない? 全然違う意味でしょ。

＞バス幅と語長を

32ビットアーキテクチャながら16ビット固定長命令のCPUだってあるし、
32ビットアーキテクチャでデータバスが64ビット幅ってCPUは数多くあるからねえ。
それどころか、16ビットアーキテクチャで最小命令長16ビット、データバス16ビットでレジスタだけ32ビットってのもあったしなあ。

>>919
>語長というのはCPUがもっとも効率的に扱えるデータ長のことだ。
>一番都合がいいとメーカが主張してるんだからそのデータサイズでアクセスする場合最も速度が速い

単なるフラグに1ワード割り当てて数値で比較するのと、1ワードにパックして複数同時に条件比較するのでどっちが早いんだ？
たとえ１ビットでも、わざわざ数値で比較するのとビットのONOFFで条件分岐するのでどっちが早いんだ？
語長が32ビットのCPUで8ビットに充分収まる数値しか使わない場合、毎回無意味な0が上位の数値をロードするより
命令に埋め込まれた即値をロードする方が圧倒的に早いだろ。
XXビットCPUだから毎回XXビットの演算をさせる方が早いとはいえない。
そんなのはアプリとプログラマの質で大幅に変わる物だ。
これだからＣしか出来ない奴はｗ

>>923
>即値以外の、レジスタ直接なら916の言うとおりだろうが...

>>916はかなり間違ってる事を書いてるので反論したまで。まあ、全てが間違いという訳では無いから言うとおりの部分もあるだろうけど
「即値以外なら」とくくれるほどは正しく無いしそもそもなぜ即値を外す？
一般的なプログラムではフラグ（1ビット即値）による分岐はかなりウエイトが大きいと思うぞ。

>>ID:XoVDvW2H

何あったま悪い比較持ち出してるんだお前。

>単なるフラグに1ワード割り当てて数値で比較するのと、1ワードにパックして複数同時に条件比較するのでどっちが早いんだ？

完全糞だな
1語長 x n回アクセスと 1語長アクセスを比較して何をしたいんだバカ
だいたいデータバスすなわちメモリとのアクセス効率の話をしてるのに、
何を、パイプラインの乱れに直結する条件判断の話にすり替えてんだこのバカ
しかも、うすっぺらい知識をもとに恥ずかしげもなく何をつらつらかき込んでるんだこの糞が。
しかもコイツこんな比較を持ち出すこと自体パイプライン、バレルシフタの有無によって全く条件が変わることも皆目知らんアホ学生そのものと見た。うすっぺらぺら過ぎんだよ馬鹿たれ。
糞知識しかないアホがマヌケなレス書き込むなこのうじ虫。
Cしかしらねぇのはテメエだろうが。
数値ダイナミックレンジの意味すら理解できない一知半解のおまえのようなゴミ見てると反吐が出んだよ。
学問板のここから出て行け。
gcc 対応 call walker はどうしたシングルタスク知障

結局H8/3069では、
イントが一番速いと言うことで 良いでしょうか？

結局H8/3069のソフト開発は、
インドが一番速いと言うことで 良いでしょうか？

なんとなく…
イントって、コンパイラの設定とＣＰＵコアで扱い変わるよね？
ショートのほうだっけ？
というか
半角英字でしか打たないものをカタカナで書くとすげえ違和感。俺だけかしら。

さておき。
何も考えなくていいとか、変なライブラリ呼ばないとか、そういう意味で整数演算しか使わないなあ。
で。
charでもintでも命令長かわらなければ同じ速度じゃないか？
longと即値は命令次第っぽいけど。

インドって日本のＣＰＵでの開発ってやってるのかしら？

>>925
悔しそうだねｗｗｗ

ありがとうございます。
Cの記述が長いと実行速度も遅いような気がして。

CPUのワードアクセスとビットアクセスどっちが速いとか言われても、アクセスするアドレスがどこかでも変わってくるよね。
8ビットバスのところと16ビットバス、32ビットバスのところとで。
CPU内蔵I/Oとか20ステートくらいウェイトが入る鈍足メモリだったり。実際のI./Oが32ビットごとに1ビット分しかない場合とかさ。

いやまあ、さすがに1000ステートくらいウェイトが入るのはハードウェア設計ミスだと思うけど・・・そういうものも過去にはありました。

オレも行番号が小さい方が早いような気がしてた。
BASICだったけどな。

さて、カネベーベーでも買うか

マイコン使用のハードウェアを設計して20年、
マイコンソフトをCで書き始めて、 8年くらいになります。
最近、ソフトを完成させるまでに時間がかかるようになってきました。
自分自身を見直してみると、迷うことが増えたように感じます。
その迷うというのは、

小数点の入る計算をfloatのまま計算するような記述を書き、いったんはそれで動くのですが、
「いや待てよ、もしかすると1000倍して整数で計算した方がいい(速さ、設計思想)かもしれないな」とか、
if()で書いてるところは、switch()のほうがいいかも。変更だ。　とか
for()で回すのもいいけど、この場合は、10行そのまま記述したほうが、設計的に一貫性がとれてるな、とか
AD変換器の関数では、AD_conv( ch )とチャンネルセレクトを付けたんだから、D/Aも( ch )をつけた関数にしないと、おかしいよな、(今回はDAは1ch使用なのに)とか
このLCD表示器の関数は、他にも転用できるようにReadもできるようにしておこう、(今回はWriteだけなのに)とか
です。

上記のように、一度考え出すと、あれも修正して、これも修正して、となってしまい、
そんなことしてる時間は無いことがわかっているのに、途中で、もう一度書き直したりしてしまいます。

数年前は　こんなに迷うこともなく、ササッと書き上げていたのですが。
こんな私は、変でしょうか?　

あるいは、みなさんは、こんな事はないですか?

なんか、ソフトが嫌いになりそうです。

時間内に終えているんならいいんじゃね。

>>934
時々、他の人にソースコード読んで貰うと良いんじゃないかな？
8年も一人で書いてると、いろいろおかしくなってるのに気づかないもんです。

ソフト歴25年だけどいまだに動けばいいやです。

動く手前で止まってる人が多いから

お、CMMIレベル１達成ですな

ラジオデパート１Fにあった
「エイティラボラトリ」って何処に行ったかしりませんか？
R8Cボードを買おうと思ったけど、webでチェックしたら消えちゃってるみたいで。

>>934
心療内科に行ってカウンセリングを受けたほうがいい

>>941
そうだよね。

仕事なんだからやっつけでやらないと間に合わないぞ。
とりあえず動けばいいんだ。
極めるのは趣味でやれ。

>>942
ソフトでもハードでも、動作が仕様通りでバグがなければ、それ以上は無駄なコスト。

技術者の良心というものはあるが、それが評価される環境などない。
民生品でも他でも最近は品質が低いと思うが、それが今求められている品質とも言える。
今はデジタル化のおかげで誰が設計しても問題は出にくいのだけど、これでいいのかね…

>>943
>これでいいのかね…
ですよね?　そう思いますよね。
そう考えると、例え俺一人でもやらねば　と思うんです。
高い設計思想が、良い商品を育てると思う。
動けばよい、結果オーライで良い、などは寂しく思います。

昔のは寿命が長かった
今のは保証期間中だけ持てば良いっていう設計していると思う

>>942
>とりあえず動けばいいんだ。
>>943
>ソフトでもハードでも、動作が仕様通りでバグがなければ、それ以上は無駄なコスト。


やっつけ仕事ばかり、考えずにてきとうな仕事ばかりだと、自分の実力の足しにならない。
ちょっと考えてソフト組めば次に流用出来てどんどん仕事が楽になるのに。
やっつけだから完成度が低い＞部品流用出来ないから時間が無くて次の仕事もとりあえずのやっつけ＞以下ループ
ってのがそういう奴らの実態だな。

でも嫌いになったら意味ないでしょ

っていうかそういうのは学者さんがすればいいんだよ
現場ではそういう学者さんの成果を使わせてもらうとして。
逆に好きなら現場じゃなく学者さんになればいい。

>>947
嫌いなら別の仕事すりゃ良いだけ。幾らでも仕事はあると思うよ。
無理して合ってない仕事する事は無い。鬱病になるよ。

？

>>944

あなたの>>934の書きこみは、もっともな点もあるけど、

> if()で書いてるところは、switch()のほうがいいかも。変更だ。　とか
> for()で回すのもいいけど、この場合は、10行そのまま記述したほうが、設計的に一貫性がとれてるな、とか

は性能向上に貢献するとは思えない。

> AD変換器の関数では、AD_conv( ch )とチャンネルセレクトを付けたんだから、D/Aも( ch )をつけた関数にしないと> 、おかしいよな、(今回はDAは1ch使用なのに)とか
> このLCD表示器の関数は、他にも転用できるようにReadもできるようにしておこう、(今回はWriteだけなのに)とか

にいたっては、今回は使わないことがわかっているのだから無駄。むしろ性能改悪。

とりあえずいまやっているプロジェクトは納期に間に合うよう納品して、
自分の至らない点に気づいたらそれをメモっておいて、
次のプロジェクトで初期設計段階から生かすようにするしかないんじゃないかな。

やってもやんなくてもいいライブラリの整備とか、
どうでもいいこだわりで工数膨らましてるだけじゃん？
余裕がある時とか、再利用性があるものになるんならやってもいいと思うけど。

集中力が持続できなくなっていて、
自覚のないままにやるべきことからやや目をそらして逃避してるように見える。

>>951
if (foo == 1)
　hoge();
else if (foo == 3)
　fuga();
　：
てなコードをswitchにするとコンパイラが頑張ってジャンプテーブル作ってくれるかもしれない。
そんなアホな書き方するんじゃねえとは思うが。

forループの展開は、キャッシュのないCPUで極限まで速度を追求すると手を出すことになります。
んで、Cのマクロに繰り返し展開がないことを恨む。

まあどうでもいいことだな。

>>934は自分の設計思想が高度と思ってるようですが、小手先って感じですね。
てか1000倍して云々で底の浅さが見える。1024ちゃうんかと。

現場を知らん学者が考えるとどんなのができるんだろうか

>>953
switchとifって、いわゆる論理演算を含んだI/Oの話でしょう。
Cはcase文に式を入れられないので、swtichを使うべき構造でも書けない場合が多い。
それで、if文で書くことになるけど、ハードウエアについては動かしてみてわかることがあるから、
下位3ビットしか見なくてよかったので、swtich文で上手くかけた、とかそういうことでしょ。
普通の整数値でswitchとifで悩むようならド素人すぎるよ。

ただ、どういう環境で仕事してるのかしらんけど、今時そんな余裕があるなんてうらやましいね。
そんなことやってる下っ端技術者だと、グループのリーダから文句が出るだけだろうし、
自営とかで一人でやってるなら、少ない費用しかもらってないだろうから、そんな気にもならないだろうし。

>>954
Cで書く人は気にしないでしょ。

>>953
ループ展開はたいていのコンパイラにあるでしょう。
組み込み系のコンパイラには普通はあるよ。例えばRenesas製でも。

ifとswitchだけど、Renesas製がどうかは知らないけど、今時のコンパイラは、
ソースの構造を分析するし、その程度だと同じになるから、同じ出力を出す可能性があるよ。
そう思っていたら、古典的なポインタとインデックスは、やっぱりポインタの方がいいとか、いろいろあるけどな。
でも、そんなことを気にせずに記述できる程度の仕事でなければ、採算ラインには乗らんというのは、
大企業でも中小企業でも自営でもいっしょ。

ただ、メモリのアクセス方法とかワード幅とかはちゃんと考えないと駄目だし、
アルゴリズムがまずいのは論外だよ。
Call Walkerがないとスタックサイズがわからないとか、RTOSが難しいとかは、
組み込み経験が少しでもあると思えないが…

>>955
EJBのようなものができる

>>957
今時アセンブラで書いてるの？
逆に聞きたいけど、何のメリットがあるの？

Cで書いたって、これは気にするでしょう。
C++で書きたがる人が気にしないってのなら同意するけど。

>ソフトでもハードでも、動作が仕様通りでバグがなければ、それ以上は無駄なコスト。

その通り…なのだが、まず仕様をきちんと作ろうぜ。

>>960
えーと、LSBが1/1024か1/1000かの話よね？
とくに制限や思想のないコーディングなら、どっちでもいいような気がする。
四則演算に頭使わなくていいのが言語のメリットだし。

と書いてて思い出したが、もとは思想というかコダワリの話か。
うん、２の乗数のほうが幸せかも。

>>961
痛い。耳が痛い。　動作仕様書から一気にコード書いちゃう私には…。
途方もないほどファジーな動作仕様書だけ来て、さあ作れと言われることが多いからねえ…。

>>962
>途方もないほどファジーな動作仕様書だけ来て、さあ作れと言われることが多いからねえ…。
へー、すごいね、って言われたいのかもしれないけど、悪いけど全然そう思わない。
ファジーな動作仕様書で作れと言われることと、仕様を書かないのとは何も関係ないじゃん。
仕様を書かずにできるソフトって、100〜200行程度のものだと思う。

そんなに自慢しなくてもいいよ、全然すごくないから。
大人しくちゃんと仕様書を書こうよ。

ファジーな動作仕様書が来たら、ファジーな動作をするコードを提出しないといけないのでは？

>>964
人工知能で

ファジーな動作をする高度なコードかぁ...

ボケ老人シミュレーターで

>>963
Ｃ言語で行数ってソース規模の指標になるの？

なるでしょ

逆に>>968がどんな指標を使っているのか気になる

ちなみに30年前にIBMが作った
メインフレームOSが100万行ぐらい
その時1人月で1000行

これだけ知っておくと、現場で
工数の妥当性を考える時参考になる

まあ
if(hoge==poge){
を
if
(
hoge
==
pege
)
{
と書けば7倍の行数になって、生産性大幅アップだな。
でも、開発規模に応じたテスト件数をこなさないといけないルールだと、こんなので7倍のデバッグケース考えるのは厳しいような。

>>970
そういうのはツールつかって定型書式に変換してから、行数カウントするんだよ。無能ちゃん。

1行にまとめるんですね

一行じゃ無理でしょ。せめて7行位無いと。
http://pc12.2ch.net/test/read.cgi/tech/1215352849/

１行に書けるものをわざわざ７行にとか、もう公務員的な発想としか思えない
エディターのメモリーが不足して１行にどれだけ詰め込むかみたいな時代もあったのに。
ゆとりとは恐ろしいものだ

>エディターのメモリーが不足して
ないない

>>974
老害乙

雑誌で「一行ベーシックコンテスト」みたいなん、あった。
お題がでて、いかに詰め込むかって。

>>975
あるって。おまいが知らないだけ。

昔uCOM-87なんてCP/Mが開発環境で
WordMasterのメモリ不足でソースを分割するまでもないプログラムなんぞ
行詰めして無理やりコンパイラを通したもんさ。

1行って、何を持って1行とするの?
エディター上での「改行」をしたら1行、とかだと、エディタの1行文字数の制限が無限なら
どんな長いプログラムでも書けるんではないですか?
Cなら;で、BASICなら:でつなぎまくる。

64KB の壁とかあったんだよ、昔は。

>>979
まあふつーは１行１命令じゃなかろか。
くそ長い演算とか、くそ長い if 文とかはどーするのか知らないが。

>>980
定番だねえ。
Z80系で64KBを簡単に超えられるシステムもってる機種って結構少なかった気が。

ところで、そろそろ次スレ？

>>980
この前、vb6でぬるく開発していたら、64kの壁があって笑った

新スレが立てられません。規制中みたい。


良かったら使ってください。
↓

H8_SH__ルネサスマイコン総合スレ4__M32_R8C_Tiny


　　PICもAVRもいいけど、やっぱりMade in Japan ルネサスマイコンは最高っす。
　　
　　H8やSHだけの限定ではありません。ルネサスマイコンについてなんでもどうぞ。
　　トラ技のTinyやR8Cから入った入門者の人も、M32/16ファンのあなたも、
　　ルネサス製マイコンや開発環境に関する、レポート、質問、購入方法など、なんでもドゾー。
　　
　　特に初心者の人には親切丁寧をモットーにお答えしますよ。

　　過去スレ1　http://science3.2ch.net/test/read.cgi/denki/1106160714/
　　過去スレ2　http://science6.2ch.net/test/read.cgi/denki/1159675598/
　　過去スレ3　http://science6.2ch.net/test/read.cgi/denki/1228014309/

　　関連スレ　H8/SH gcc vs 純正コンパイラ
　　　　　　　http://science6.2ch.net/test/read.cgi/denki/1183216226/l50
　　　　　　　トラ技４月号に付録のH8マイコンで実験しよう Part5
　　　　　　　http://science6.2ch.net/test/read.cgi/denki/1102215461/l50
　　　　　　　【浦島】H8は日立製だと言い張るスレ【太郎】
　　　　　　　http://science6.2ch.net/test/read.cgi/denki/1072445656/l50
　　　　　　　Ｈ８ファミリ、スーパーＨ　限定スレ
　　　　　　　http://science6.2ch.net/test/read.cgi/denki/1189508057/l50
　　　　　　　●●●くみこの組み込み相談室1.0●●●
　　　　　　　http://pc11.2ch.net/test/read.cgi/tech/1191397574/l50　
　　　　　　　ルネサスホームページ　
　　　　　　　http://japan.renesas.com/fmwk.jsp?cnt=mpumcu_category_landing.jsp&fp=/products/mpumcu/
　　
　　割込処理後のフラグクリアを忘れずに、
　　SCI設定後は、1bit時間以上待って、
　　モジュールストップに注意して、　　　　さぁ　レッツ ルネサスぅ〜〜〜

たてまつた

H8_SH__ルネサスマイコン総合スレ4__M32_R8C_Tiny
ttp://science6.2ch.net/test/read.cgi/denki/1254737313/l50

void main(void)
for(;;)
{
}
}

error: expected declaration specifiers before ‘for’

void main(void) {
for(;;)
{
}
}

>979-980
1行は255バイトまでじゃなかったっけ?
Cはともかく、むかしのBASICでは。

ラインエディタでも1行255バイトまでとか、そこそこあったんじゃない?

1行の最大文字数が何文字までだったかは忘れたけど、2DDフロッピーディ
スク搭載のCP/M-80のシステムで開発していた当時、別にZ80のメモリ空間が
64KB固定でも、当時のWord Master等のテキストエディタは、64KBを超える
テキストファイルもちゃんと扱えましたよ。

通常は規模が大きくなると分割アセンブルするので気にしたことはない
けど、M80(MicrosoftのZ80アセンブラ)も、入力するソースファイルの
サイズに64KBという制限はなかった気がする。　

CTRL-C/CTRL-Rで画面を前後にページ送りすっと、ディスクI/Oの速度が
遅くて、キャラクタディスプレイにも関わらず、グリーンモニタの画面
を書き換えていくのが目で追えた。

そりゃワープロで64KB制限があったら使いものにならんわな。
それでは本1冊どころか下手すると1章も入りきらん。

>>990
ソースの制限はわからなかったけど、出力ファイルサイズが64KからOSのサイズを引いた大きさ（40Kバイト位）しかアセンブル出来なかった気がする。
しかたなく98のクロス環境に移行した覚えが。

>>991
ポメラは、8000文字までだぞ

メモ帳は書くとこ少ないんだぞ

と主張されてもな・・・

週刊アスキーの「無料ソフトの殿堂」にPICのライティングソフトが
のってやがる。編集部にPIC厨でもいるのか？

気に入らなければ厨ですか

そういや、Windowsのコモンコントロールの1つ、エディットコントロールが
32bitなのに16bitWindowsの仕様を引きずっていて、編集できるテキストが
最大32KBまでだったような。　んで、エディットコントロールを貼り付けた
だけのメモ帳も同じ制限が...。

>>997
それWindows 95系の制限・・・
Windows NT系のメモ帳は最初から32KBの制限ないよ。

ＶＢとかから制御できるテキストボックスは有無を言わせず制限あった気が

1000get

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。