H8_SH__ルネサスマイコン総合スレ3__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/
　　
　　関連スレ　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/
　　

2ゲット

EDN12月号の表紙のRENESASの広告の女の子で抜いた
のうし先輩は最近の広告でオススメありますか？

SH4をつかいたいんだが、開発環境が高いなー。せめて３万円くらいにしろよ。
１０万じゃ高すぎ。
　E8Aはすごくいい。しかし今使ってるCPUの中ではM16しかデバッグできない。
M16は好きじゃないんだよな。
TIのMSPを見習えよな。安くて機能がすごくいい。

そんなに いいですか？
例えばどこらへん？

H8/3048か3052で、プログラム側からマイコンを
ソフトウェアリセットする方法を教えてください。

ウオッチドッグでイってしまえ

リセットベクタ読み込んでそこにジャンプ

それでリセットになるんか？

リセット後の初期化がしっかりしてれば、大丈夫じゃないの？

割り込み禁止にしてとんだ方が安全かも？

>>9
そらハードウェアリセットのようなわけにはいかんだろうさ。

ならハードもリセットされるウオッチドッグのタイムアウトの方がよかんべ。

時間がかかってもいいなら、ウオッチドッグの方がいいと思う。

M16Cの62PにSRAM付けて遊んでるんですが、
sscanfの出力先をSRAMのバッファにすると動かないんですが、何か方法はないんでしょうか？

sram_ram.cに
sWkBuf[256];

test.cで
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
　・
　・
　・
iRet = sscanf(bTempBuf, "GET %s", sWkBuf);
みたいな事をやると、iRetは正の整数が帰ってくるのですが、sWkBufの中身は何も書き込まれません。
iRet = sscanf(bTempBuf, "GET %s", sWkBuf_local);
みたいな感じだとうまく行きます。

sWkBufにはR/W出来るの？

>>15
調べてないんではずしているかもしれんが、現象から考えると格納する
sscanf の結果を格納する変数の宣言がnear になっているような。

near は、64Kアドレス以内の変数の宣言。far は制限なし。
ただし、near は2バイト、far は4バイトのポインタ変数になる。

外付けRAMはおそらくfar なのでそれでだめなのではないかな。もしそうだと
すると、sscanf の出力変数に外付けRAMの変数(sWkBuf)を指定することはできない。

とりあえずsscanf の宣言を確認してみたらどう。

H8マイコンを選ぶ理由を教えてください。

トラ技2004年4月号に付録で付いてたから。

char_farってのがあるんだ。

>>16
R/Wはできます。strcpyができました。

>>17
extern _far char sWkBuf[256];　としてます。
sscanfっていうか、ルネサスのコンパイラは関数全てがfarポインタになっています。
extern _far char sWkBuf[256]; としても、sWkBufって形でポインタで扱うとnearになっちゃうんですかね？

教えてください。2つあります。

H8/3069に、外部バスでSRAMを接続する回路を考えています。

1. WR, RD, CS関係はわかったのですが、AS(アドレスストローブ)の使い方が
　　わかりません。
ASは「アドレスバスの信号が全部確定しましたよ」という信号だと思っています。
メモリへは、data, address, CS, WR/RDをつなげば、動作すると思うので
このASはどうすべきかと悩んでいます。
予想するに、H8のCSを使わずに、H8外部で74HC138などでアドレスをデコードするときや
1つのCSバンク内で複数のデバイスを使用するためにアドレスを分割したいとき、
CSのハザードが出ないように138のGにASをつなぐ、そんな時に使うのではないでしょうか。
だとすると、
バンク内に1つのSRAMという構成の場合は、AS出力は開放のままで良くて、
WR, RD, CSのみでOKではないかと考えています。

2. 上位アドレス線の扱い
　SRAMとして1Mbitの物をCS2に割り当てようとしていますが、
　1Mbitなので、アドレス本数は、16本(A0〜A15)までしか必要有りません。
　なので、A16〜A19の4本は、使わなくても良いと考えています。
　そこで、わからないのは、
　1バンク2Mbyteの空間用のCS出力があるにもかかわらず、
　アドレス線がA19まである理由がわからないのです。
　　もしかすると、「オレはCSなんて使わないんだよ。外部でFPGAで
　アドレスをデコードするからね」という人用に、全本数のアドレス線が　
　出ているのでしょうか?

上記の考えは正しいでしょうか?

どうぞ宜しくお願いします。

タイミングさえ満たせるなら使おうが使うまいが好きにすればいいよ。
/ASは、/CSやストローブに対してアドレスのセットアップやホールドを要求する
デバイスの一部で便利なこともあるが、SRAMは使わなくても繋げられる。

2はただの勘違いでしょ。
2Mbyteの空間内の任意の場所を指定するには21ビットのアドレス、つまりA0〜A20が必要。

>>23
ありがとうございます。
/ASの件は、了解です。概ね合っていて、安心できました。

アドレスの件は、ご指摘の通り間違えています。すみません。
1MbitのSRAM(64k×16bit)でした。なので65536アドレスとなり、16bitアドレス。
全然違うこと言ってました。すみません。恥ずかし。

で、/CSがありながら、アドレスが全線出ている理由は、あの内容で
正しいでしょうか?

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

>2はただの勘違いでしょ。

>24
まず、/CSが2MB単位って言ってるけど、3069の場合、レジスタの設定で
そうじゃない動作も出来るでしょ。そのとき一番広いエリアは8MBあるよ。

それはおいておくとしても、例えばVRAMを2MB以上もつ液晶コントローラを
繋げたい場合なんか上位のアドレスが必要になるけど、複数の/CSから
上位アドレスを作るのは面倒だし速度的にも不利だよ。

あるいは2MB以下の範囲でも、2つのエリアをまたいでデコードしたい場合も
2本の/CSと下位アドレスでデコードするより上位アドレスがあった方が
便利かもしれない。大して変わらんと言われれば仕方ないが。

要は、無くて困ることはあっても、有って困ることはないから用意してあるんじゃないか。
その信号が要らないなら使わなきゃいいだけ。

>>26
ありがとうございました。具体的な説明でよくわかりました。
つまり「どちらでもできるように出してあるので、ユーザーが考えて使い分けなさいよ」
という認識ですね。ありがとうございました。

>複数の/CSから上位アドレスを作るのは面倒だし速度的にも不利だよ。
　　この場合、2つの/CSを、Low NORするという手法を考えてしまいますが
　　正しいでしょうか。たしかに速度的にそんな感じがしますが、
　　上位アドレス多bitを、切り出してアドレスデコードすると、ゲートをたくさんくぐるので
　　CSのLow NORでも、結構やれるんではないでしょうか?

>あるいは2MB以下の範囲でも、2つのエリアをまたいでデコードしたい場合
　　これは、CSより下のアドレスを切り出す必要があるので、
　　CSでやるより、CPLDなどにデコードしてもらった方が良いですね。

教えてください。

H8/3068は、H8/3069とROM容量以外に　何が違うのでしょうか?
ルネサスの総合カタログを見ましたが、特に何も謳っていないみたいです。
3069と置き換えができるとか....I/Oヘッダファイルとかも同じならさらに嬉しいんですが。
秋月に1250円で売っているので、いいなとぁ思いました。

動作モード6が使えないが、基本的には同じ。
もしかしたら一部機能に拡張があるかもしれないが、レジスタ設定で
ソレを有効にしない限り従来品と同じ動作をするようになっている。

あ、ピン配も互換だから基板にはそのまま載せ換え可。

>>29,30
ありがとうございます。いいこと聞きました。

では、
・通常使用　→　秋月で3068を
・メモリたくさん欲しい　→　同じく秋月で3069を
・3.3V駆動したいなら
　　3069(5V)　→　3029(3.3V、入手先不明)
　　3068(5V)　→　3028(3.3V、入手先不明)
ということですね。
モードは、7と5が使えれば、全然問題なしです。(殆どはモード7で使用です)

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

キーボードのキーを自動的に入力する為に何かいい方法を探していて
マイコンならプログラムみたいに自由に組む事が出来るのでいいのではと思い
H8/3664を秋月電子から購入し
LEDをちかちか点滅させるまでどうにかいけたのですが

キー入力はショートさせるだけでいいのでリレーのような機能がマイコンで表現できないのかなと思っています
リレー回路のように1のとき導通させたり　０の時は切り離したりという事は出来るのでしょうか？

つ　4066

H8/3069に8ビットSRAMを接続したんですが、特定のデータビットだけ
うまくいかない。
具体的には(D14、D15)で、なぜかD14は読み込むと1がたったままで
D15は何も反応せず、0x80を買いても読み込むと0x40になってしまう。
下位のD8〜D13は問題ない。データバスは30Ωのダンピング抵抗を通して接続
している。不思議なのはD14のダンピング抵抗をはずすと、つながっていないはずなのに
0x00〜0x7Fまでなぜか読み書きできるようになる。
接続はデータバスに関してはピン番号も規則的で間違っていないと思う。
アドバイスお願いします。

>>34

　　MOV.L　#メモリの番地,ER1
　　MOV.B　#H'00,R0L
　　MOV.B　#H'FF,R0H
LOOP:
　　MOV.B　R0L,@ER1
　　MOV.B　R0H,@ER1
　　BRA　　LOOP


みたいなプログラムを走らせてオシロで各端子の波形を観測する。

>34
配線ミスか半田不良だろ。

何より一番いけないのはこれだ。
「接続はデータバスに関してはピン番号も規則的で間違っていないと思う。」

そんなこと思わなくていいからまず確認する。
自分のしたことを真っ先に疑う、これがデバッグの鉄則だ。

　　謹　賀　新　年

　　　　今　年　も　ど　う　ぞ　宜　し　く　お　願　い　し　ま　す。

何か最近H8関連のスレが伸びないけど、もう人気無くなったのかな。
みなさん別のマイコンに移って行ったとか?
あるいはFPGAに移動とか?

ちょっと寂しいなぁ

仕事では相変わらず使っとる

最近やり始めたなら、はじめてのマイコンがH8(の3069F-LAN)だった
という人はきっと多いはず。他のは導入にライタが必要だったり
躊躇する要素があるからだ。
速度はともかく2MB、RS232C、有線LAN付きのオールインワン的な
マイコンボードが完成品で、しかも安く入手できる。
これが無かったらどうなっていただろう。

2chで人がいないのは、単純にH8専用スレ？が無意味な1行レスで
荒らされてるのが原因じゃまいかと。

だよね
すごいね、いいね、のオンバレードじゃ
嗚呼ここには馬鹿しかいないのかと思う他ない
やってる人は黙々を手を動かしてる
そんな当たり前の状況だろうな

教えてください。

H8にFPGAをつないで、
・H8が指示する値をFPGAのレジスタに書くと、そのレジスタ値をFPGAが読んで実行する。
・逆に、FPGAが制御中のレジスタの数値を、H8が読む事ができる。
というようにしたいです。
H8からメモリのように読み書きすれば、それがFPGAのレジスタに読み書きされるように
したいのです。

そこで、H8は外部バスモードで駆動して、H8とFPGAを以下のようにつなごうと考えています。
・H8 A15〜A00、D15〜D00　→　FPGAへ
・H8 /HWR、/LWR、/RD、/CS4　→　FPGAへ
上記の接続で良いでしょうか?　他に接続すべき線はないでしょうか?
気になっている線には、　/AS、/BREQ、/WAIT、/IRQ、/RESET　などがあります。

H8の内臓ROMを2分割してプログラムA(仮に0x000000番地からとする)
プログラムB(仮に0x300000番地からとする)
を格納したいのですが、可能でしょうか？
具体的にはプログラムAがBIOSみたいなもので、ある条件
をみたしたらプログラムBに分岐するみたいな。
開発環境はHEWなんですが、プログラムAは普通にHEWの骨組み
を利用すればいいですが、プログラムBの割り込みやセクション
設定がいまいちわかりません。プログラムBのP領域他を0x300000
からとすればよさそうですが、割り込み処理はベクタエリアが共通
なのでAとBで違う処理をする場合、アドレスがかぶるのでどうすれ
ばよいのかよくわかりません。
参考になるHPや書籍があったら教えてください。

>>43
ABどっちが走ってるかフラグで分ければいいんじゃね？
ABを完全に別にしたけりゃ、両方０番地から書いてバンクにするとか。

ああ、内蔵ROMか
バンクの話は無しだな

>>42
接続すべきでない線があるような？

>>43
H8SXならベクタテーブルを変えられる。
トリッキーだけど、H8/3069でベクタテーブルをRAM化したことがある。

>>46
>接続すべきでない線があるような？
えっ、そうなんですか?　ぜひ教えてください。

もしかして、A00でしょうか?　16bit幅だから偶数番地しかアクセスしないから
要らないだろう、ってことでしょうか。
仮に接続してしまっても、FPGA内で使わなければ良いのかな、とも思います。

>>42
気が変わったら8ビットバスモードにも変更できるしA00つないでおいても特に問題ない。
というか、/CS使うんだしアドレスを16本もつながなくてもいいんじゃないの？そんなに大量にレジスタ作るの？と思わなくもない。
ピンに余裕があるなら使いたい分だけつないで好きなようにデコードすればOKです。

＞/AS、/BREQ、/WAIT、/IRQ、/RESET　
どれも別に必須ではない。回路側で色々やりたいなら用途がでてくるかもしれない。
でも/ASなんて全く必要にならないだろう。リセットは欲しいかな。
別にあっても悪さをするわけではないので、つなぎたければ全部つなげばいい。

>>49
ありがとうございます。全て了解です。安心しました。

>/CS使うんだしアドレスを16本もつながなくてもいいんじゃないの？そんなに大量にレジスタ作るの？
>>42ではレジスタと言いましたが、ビデオメモリという感じで使いたいんです。
H8で書いたイメージを、FPGAで表示処理してもらう、という感じです。
要は、FPGA内部のブロックRAMをデュアルポートRAM的に使いたいのです。
ただ、絵の領域はそんなに広くないので、A15までは要らないと思います。

>でも/ASなんて全く必要にならないだろう。リセットは欲しいかな。
リセットはつないだ方が良いですね。私のミスでした。
マイコンがFPGAをリセットするというのもありなので、
H8と同じ/RESETを持って行かなくてもよいと思いますが。
ありがとうございました。

FPGA内部のブロックRAMを、デュアルポートRAM的に使う方法として、
CoreGenのデュアルポートメモリのIPを使おうとしていますが、
一般的に、その場合　何か特別な配線が必要なものでしょうか?
　　　　　　　　バス衝突が起きたときに、H8の/WAITを引くとか....

WAITを使うとか、BREQ使うとか、そもそも衝突がおきないようにしとくとか

>>51
ご回答、ありがとうございました。

H8のRAMアクセスについて教えてください。

http://science6.2ch.net/test/read.cgi/denki/1231337201/51-52
のやりとりで、
H8とRAMの配線で、LSBを配線しない理由は、
　　偶数始まりでアドレスを指定するからであり、
　　なぜ、偶数始まりで指定するかというと、
　　メモリをちゃんと無駄なく0番地から使うために、0と1、2と3・・・となる。
と予想しています。
それはそれでOKなんですが、
もしアドレスを　0番地を使わずに、1と2、3と4・・・という使い方をするならば
H8とRAM間の配線でLSBの配線も必要になる、という考えは正しいでしょうか?
あるいは、16bitアクセスする事自体ができないようになっているのでしょうか?

H8って奇数番地からの16bitアクセスって出来たっけ？

エラーは出ないが、偶数番地からワードアクセスしたのと同じ結果になる。
（300Hの場合）他は知らん。

で、
>>53
＞もしアドレスを　0番地を使わずに、1と2、3と4・・・という使い方をするならば
＞H8とRAM間の配線でLSBの配線も必要になる、という考えは正しいでしょうか?

間違い。
バスコントローラが、16ビット空間として設定したアドレスに対して
/LWR,、/HWRを使い分けてくる　=　A0がデコードされているのと同じ。
なのでRAMにA0を接続する必要はない。

/RDはCPUから見たら読むデータを選ぶだけ=区別する必要がないので常に1本。

>>54
V850 は(無駄に)できたりする。

>>57
intel系の流れを受けてるからでしょ。
V850って命令セットがおもしろいなと思った。

>>55, >>56
ありがとうございます。
ということは、次のようで良いでしょうか。

ＲＯＭ番地　Ａ２　Ａ１　Ａ０　／ＨＷＲ　／ＬＷＲ　
　　０　　　　０　　０　　０　　１　　　　　０
　　１　　　　０　　０　　０　　０　　　　　１
　　２　　　　０　　１　　０　　１　　　　　０
　　３　　　　０　　１　　０　　０　　　　　１
　　４　　　　１　　０　　０　　１　　　　　０
　　５　　　　１　　０　　０　　０　　　　　１

あれっ?　わからなくなってきた。　ヘルプ〜〜!!

使ってるマイコンのハードウェアマニュアルをよく読みませう。

H8/3048でのSCI割り込み動作中にIRQでの割り込みに移るって事できる？

割り込みレベルを変えればできるように思うけど。

>>61
SCIの割り込み処理の中でSCIの対応した割り込みを周辺機能で禁止して、
CPUの割り込み禁止を解除すれば、多重で割り込み処理が出来る。
SCIの割り込み抜けるときは、逆の事やるのをお忘れなく。

こんにちは
お聞きしたいことがあります
HtermはVistaで正常に動作しますか?
開くことは開いたのですがマイコンが手元にないので細かい確認ができません

あけましておめでとう。　H8　万　歳　!!

はい、おめでとう。　今年もH8を　宜しくね。

はじめてマイコン挑戦です。
マイコンはH8/3694Fです
データシート見てて思ったのですが
ポートBにPCRがないのはなぜですか？

>>67
自己解決しました。すれ汚しすいませんでした

ちょいと教えてください
前から気になってるんですが、HEWでコーディングを行っているとき
構造体のメンバへアクセスするような記述をするとエディタの反応が
少し鈍くなるのですが、なにか特別な処理をしてるのでしょうか？

たとえば、
struct ABC {
　int X;
　int Y;
}
があるとして、

main()
{
　struct ABC a;
　a.X=128;
}

と書きたいとすると、「Ａ．」と打ち込んだところで少しレスポンスが遅くなります
何でしょうか？

HEWでコーディングをしない

Aから始まる構造体がすでに定義されているかHEWが調べているから

aのメンバを探して表示しようとしてるからじゃなくて？

自分も今SH2のHEWお試し使ってるんだけど
math.h include してatan2関数呼ぶと
リンクエラーが出る。
mathlibにatan2がないのか、mathlibがインクルード
されてないのか・・・
どーすればいいんだ。

解決。
ビルドの項目にライブラリ指定するとこありましたね。

>>71
>>72
VisualStudioみたいにインテリジェンスしてくれるならまだしも
なにもしてくれないみたいで、いったい何の処理やってるんだろうと
ずっと気になってる
関数呼び出しはプロトタイプを表示するみたいですね

H8/3694F用いています。
開発環境はHEW4です。
HEWでのスタートアップルーチンというのはどこに記述するのでしょうか？
またアセンブラのスタートアップルーチンは使えるのでしょうか？
参考書や、検索かけたのですがいまいち理解できませんでした。

新しくプロジェクト作ったら hwsetup.c とか、その他いろいろおせっかいなファイルができない？
hwsetup.c は main 関数の前に走るはずだから、ハードウェアの設定なんかはそこに書けば
いいんでないの？どうしてもアセンブラ見たいなら、探せばあるだろうけど。

スタートアップルーチンはresetprg.cに雛形ができる。
ttp://www.infohobby.jp/products/P05010/P05010-S2.htm

Flash.exe Ver.5.0って、ダウンロード出来る？
たどり着けないんだけどorz

自己解決しました。

ルネサスなど軒並み赤字転落へ　半導体業界も人員削減の嵐
http://www.business-i.jp/news/ind-page/news/200901170039a.nwc
　ルネサスは主力のシステムＬＳＩの販売が急激に落ち込み、０９年３月期は最終損益が２０００億円規模の赤字（同９５億円の黒字）に転じる見込み。

ＨＥＷの製品版っていくらするの？試用期間すぎちゃった

10万くらい

正確に言うとHEWは無償だし、試用期間もないんだけど、
HEWと一緒に使ってるであろうSHCが有償で、試用期間が設定されている

１０万！？みなさんどうしてるの？
なにか裏技がある？？

制限ったって、SH で 256KB も作れるんだぞ。足りんのか？

まあ強いて言えば、いきなりそんなでかいプログラムになることはないので、
枯れたルーチンはアドレスの上位に固めて、別々にビルド、んでリンク。




…てのが NEC の環境ではできた。

H8/TINY使ってるのですが、RAMがたりません
増設はできるのですか？

ピンコンパチでRAMの大きいのに載せかえる（あれば）。

なければ何か工夫して外部に置く。
バスがないのでめんどい。

>>86
Roger that.
ご助言ありがとうです。

このスレで言うのもなんだけど、H8/tiny使うぐらいなら
容量大きめのPICやAVRのがいい気がします。
その辺どういう基準で選んでますか？

>>8
さすがにPICとならH8の方がいいと思うけど、H8の中でも好き嫌いはある。
H8/Tinyは使わないようにしている。Port3が4bit毎にパッケージの対角線に
配置してあったり、割り込みベクターが無くて、PICみたいに判定してから飛ぶとか
使いにくいと思った。なので、今はH8/3069ばっかりでやってる。
ROM/RAMいっぱいで使いたい放題。機能も潤沢。

×　>>8

○　>>88

■韓国 重工業　売上高　2007年

斗山重工業　連結198億ドル　（2兆3364億円）
現代重工業 15兆 5330億ウォン（1兆7552億円）　　　　　2008年は19兆9571億ウォン
三星重工業 08兆5191億ウォン（約9670億円）


■日本 重工業　売上高　2007年

三菱重工業 連結3兆2,030億円
川崎重工業 連結1兆4,386億円（二輪車事業含む）
石川島播磨重工業 連結1兆2,210億円

ttp://japan.cnet.com/blog/onuka/2009/02/02/entry_27019971/
＞日立と三菱のマイコンが統合してルネサンス
＞著者： おおぬか
さすがに頭悪すぎるぞ、おまぬか〜。

HEWで開発してるんですけど、外付けのRAMをつけて、
内臓RAM使用領域をオーバーした場合、外付けのRAM
領域の番地に変数を自動的に配置するようにできますか？
それともやっぱり外付けRAMにB〜とセクション名をつけて
変数を確保するときは
#pragma section 〜
変数
としなきゃ駄目でしょうか。

外付けのRAMをケツの方に割り付けると悩まなくてすむかも？

あんまり具体的な話じゃないのですが教えてください。
M16Cのボードで以下の機能のうちのいくつかが付いている(チップとコネクタが載っている)ボードを知りませんか？
・RTC
・UART
・外部フラッシュ
・Etherコントロール

できればM16C/6xシリーズだと助かります。

>>93
>内臓RAM使用領域をオーバーした場合、外付けのRAM 
>領域の番地に変数を自動的に配置するようにできますか？ 

HEWで動的に配置条件変えるってこと?
なんでそんなことが必要なんだ。
そもそも内蔵RAM使用領域をオーバするかどうかをソフト書いてる人間が把握できなくてどうする。
callwalker使って使用スタックエリアを全て正確に把握するなんてのはソフト書いてる人間が
当然やらなきゃいけない作業だ。

全部外付けでよくね？

たしか、外部メモリは内部より遅かったよな

内部クロックと外部クロックが違ってたらノーウェイトでも違ってくるね

外部アクセスは1ステート追加される？

93ですがH8のメーリングリストに同じような質問がありました。
MMUがなければどうもできないようですね。
ttp://www.exp.org/h8/ml/archive/cgi/view.cgi?message=6111

ttp://www008.upp.so-net.ne.jp/funfly/h8_11.html
こちらのHPで紹介されてるように外付RAM容量>内臓RAMの場合、
RAMセクションを外付けRAMの番地に変更して内臓RAMは切り捨てるって
方法は割りと一般的なんですかね？
なんか数十キロバイトでももったいないなぁと思ったんですが。

>>99
ノーウェイト、クロック同じでも。ステート数が違ったんじゃないかな？
3067だけど違ったような記憶があるんだけど。


>>101

>MMUがなければどうもできないようですね。

そんな問題か？
コンパイル時にはみ出した領域を外部メモリに自動配置するんだろ？
MMU云々は実行時の話じゃん。

日立のHEWについて教えてください。

HEWは、フリーでダウンロードできると思いますが、
フリー版には、扱えるチップの限定があるのでしょうか?
あるいは、H8/3694〜SHまで　全〜部コンパイルできるのでしょうか?

HEWは無償で機能制限があるのはSHCだと言ってるだろうが
このバカチンがっ！

実行コードの容量制限があるだけでチップの制限はない
SHの場合は256kBまでいける

開発環境　HEW　H8/3694F

I2Cにメモリ増設して読み書きしたいのですが参考になるサイトなどありませんでしょうか？

>>101
#pragma abs16
__near16
とか、使えば内蔵RAM使うように出来るしょ。

>>105
ルネサスのサイトにApノートがあるよ
HewについてくるDocumentUpdaterで簡単に検索できるよ

>>107
ありがとうございます。ちょっと見てみます。

私以外にも無償評価版止められて困っている人がいるのですね(^^
いまさら止めなくても・・と愚痴ってもしょうがないので製品版で持っているHEWの1.2を
引っぱり出してきてコンパイルしたら組み込み関数nop()が使えないじゃないですか・・
インラインアセンブラで書くしか方法がないのでしょうか？
やったことがないので書き方の例とか教えていただければ助かります。

>>109
>無償評価版止められて困っている

え！？

そう、オンラインアップデートによって止まったんだと思うんですけどね。

>>109

#define すれば良いのでは？

>>109

使用期限終わった後のプログラムサイズの話?それならVMWare

>112 #define すれば良いのでは？

なんらかの、これはアセンブリ言語ですというのをコンパイラに知らせる
キーワードが必要ないのですか？

コンパイラに知らせるより、
レジストリにHEWのインストール情報をきれいさっぱり忘れさせる方がいいだろが。

いっそ、HEWやめて、GCCにするとか

>115
どこ消せばいいか分かるの？

>>117

>きれいさっぱり
↑↑↑
いいかげん気付よ

新しいPC買ってきてそれにインスコすれば全て丸く収まる

だ・か・ら
VMWareがあるんじゃねーかよ。
あんまり書くとチョサッケン侵害幇助とかいわれちゃかなわんからな。

3694Fに増設できるメモリってEEPROMより高速なものでありますか？

ポートが余ってるなら、パラレルタイプのもの使う？

秋月電子製AKI-H8/3052FのLCDに文字を印字したいのですが、うまくいきません。
サンプルソフトでは表示できるので、ハード面に問題はないと思います。
どこに問題があるのでしょう？
unsigned char *lcd=(unsigned char *)0xffffc6, *tcr0=(unsigned char *)0xffff64, *tstr=(unsigned char *)0xffff60, *tsr0=(unsigned char *)0xffff67;

void time(int);
void printlcd(char*);
void lcdinput(char,int,int);
void lcdsetup(void);
void main(void);

void main(void)
{
lcdsetup();
printlcd("hell world");
}

void printlcd(char* word)
{
int count=0, flag=0, count2=1;

while((*word)!='\0')
{
count++;
word++;
}

word-=count;

if(count>=17)
{

while(count2<=16)
{
lcdinput(*word,1,0);

count--;
word++;
count2++;
}

lcdinput(0xc0,0,0);

}

while(count>=1&&count<=16)
{
lcdinput(*word,1,0);

count--;
word++;
}

}

void lcdinput(char character, int rs, int setup)
{
char sub=character;
unsigned char control;

sub=character>>4;

if(rs==1)
{
control=0x30;
*lcd=0x10;
*lcd=0x30;
}
else
{
control=0x20;
*lcd=0x20;
}

if(setup==1)
{
goto SETUP2;
}

*lcd=(sub|control);
time(4);
*lcd=((sub|control)&0xdf);
time(4);

*lcd=(sub|control);

SETUP2:;

*lcd=((character&0x0f)|control);
time(4);
*lcd=(((character&0x0f)|control)&0xdf);
time(4);
}

void lcdsetup(void)
{
time(15);
lcdinput(0x23,0,1);
time(4);
lcdinput(0x23,0,1);
time(4);
lcdinput(0x23,0,1);
time(4);
lcdinput(0x22,0,1);
time(4);

lcdinput(0x28,0,0);
time(4);
lcdinput(0x0e,0,0);
time(4);
lcdinput(0x06,0,0);
time(4);

lcdinput(0x01,0,0);
time(4);
}

void time(int value)
{
int count=0;

*tcr0=(unsigned char)0x00;
*tstr=(unsigned char)0x01;

while(value>count)
{
if(*tsr0==(unsigned char)0x04)
{
*tsr0=(unsigned char)0x00;
count+=2;
}
}
*tstr=(unsigned char)0x00;
}

こんなに長いのを読めってか?

それなら読みやすいように、
{ の位置を()の後ろにして、1文を短くしてください。
　　例)　if(・・・・・){
　　　　　} else {
　　　　　}

インデントを付けてください。2chではタブが使えませんので、
タブは全角スペース2文字に置き換えると、
　　if(rs==1){
　　　　control=0x30;
　　　　*lcd=0x10;
　　　　*lcd=0x30;
　　} else {
　　　　control=0x20;
　　　　*lcd=0x20;
　　}

という感じにインデントが付けられます。

　　unsigned char *lcd=(unsigned char *)0xffffc6,
　　　　　　　　　*tcr0=(unsigned char *)0xffff64,
　　　　　　　　　*tstr=(unsigned char *)0xffff60,
　　　　　　　　　*tsr0=(unsigned char *)0xffff67;

　　void time(int);
　　void printlcd(char*);
　　void lcdinput(char,int,int);
　　void lcdsetup(void);
　　void main(void);

　　void main(void){
　　　　lcdsetup();
　　　　printlcd("hell world");
　　}

　　void printlcd(char* word){
　　　　int count=0,
　　　　　　flag=0,
　　　　　　count2=1;

　　　　while((*word)!='\0'){　count++;　word++;　}
　　　　word -= count;

　　　　if(count>=17){
　　　　　　while(count2<=16){　lcdinput(*word,1,0);　count--;　word++;　count2++;　}
　　　　　　lcdinput(0xc0,0,0);
　　　　}
　　　　while(count>=1&&count<=16){　lcdinput(*word,1,0);　count--;　word++;　}
　　}


　　void lcdinput(char character, int rs, int setup){
　　　　char sub=character;
　　　　unsigned char control;

　　　　sub=character>>4;
　　　　if(rs==1){　control=0x30;　*lcd=0x10;　*lcd=0x30;　}
　　　　　　　else{　control=0x20;　*lcd=0x20;　　　　　　　}
　　　　if(setup==1){　goto SETUP2;　}
　　　　*lcd=(sub|control　　　　);　time(4);
　　　　*lcd=((sub|control)&0xdf);　time(4);
　　　　*lcd=(sub|control　　　　);
　　　　SETUP2:;
　　　　*lcd=((character&0x0f)|control);　　　　　time(4);
　　　　*lcd=(((character&0x0f)|control)&0xdf);　time(4);
　　}

　　void lcdsetup(void){　
　　　　time(15);
　　　　lcdinput(0x23,0,1);　time(4);
　　　　lcdinput(0x23,0,1);　time(4);
　　　　lcdinput(0x23,0,1);　time(4);
　　　　lcdinput(0x22,0,1);　time(4);
　　　　lcdinput(0x28,0,0);　time(4);
　　　　lcdinput(0x0e,0,0);　time(4);
　　　　lcdinput(0x06,0,0);　time(4);
　　　　lcdinput(0x01,0,0);　time(4);
　　}

　　void time(int value){
　　　　int count=0;
　　　　*tcr0=(unsigned char)0x00;
　　　　*tstr=(unsigned char)0x01;

　　　　while(value>count){
　　　　　　if(*tsr0==(unsigned char)0x04){　*tsr0=(unsigned char)0x00;　count+=2;　}
　　　　}
　　　　*tstr=(unsigned char)0x00;
　　}

読む気もないんだけど、スタートアップルーチンに間違いはないの？

いいね

すげえええええええええええええええええ

だよね

>>126
なるほど。ご指摘ありがとうございます。
>>127&128
わざわざ、書き換えていただきありがとうございました。
>>129
スタートアップルーチンはサンプルをそのまま流用していますし、念のためLED点灯プログラムをそのスタートアップルーチンでリンクし実行してみましたが問題なく実行できました。

*lcdに書き込んだ後のウェイトがないところがあるね。

　質問です。
　H8もR8Cも開発環境はHEWでできるのでしょうか？
　HEWの言語はCであるというのはわかりますが、ポートの操作とかがまったく
わからない状態です。　プログラムの書き方がある、初心者サイトみたいな
ところがあればリンクいただけないですか？

データシートがあるだろ。

ttp://monoist.atmarkit.co.jp/fembedded/index/h8.html

>>135
サイトを良く見てみ。サンプルプログラムがゴロゴロしてる。

>>138
いやだね

>>135
本屋行って良く見てみ。関連本がゴロゴロしてる。

>>140
いやだね

M16CとH8のどちらを使おうか迷った場合ってどのように判断するのでしょうか？
また、それぞれの利点って何になりますか？

>>142
使いたい機能・性能を満たしていて安い方を選べば。

137,138,140さん　回答ありがとうございました。
調べてみます。

M16C/62Pを今仕事で使ってるんだけど、アーキテクチャが古いと思う
汎用レジスタが16bit×6本で少ない、アセンブラで書くわけじゃないんだけど、
C言語でもいまどきポインタのデフォルトサイズが16bitになってる

M16Cのメリットは…ノイズに強いらしいという都市伝説がある。
あと、R8C/Tinyは手っ取り早く使うにはPICより楽

個人レベルで使うならH8の方が書籍が多いし秋月で買えるから良いと思う。
迷ってるならH8の方が無難。
周辺機能もあまり変わらないし。

個人レベルなら M16Cの方を自分はおすすめするな。
アーキテクチャについては、 >>145 のいうとおりなんだが、
H8の方が遅くてメモリ効率が悪い。

オークス電子のoaks-mini がおすすめ。完成品じゃないけど、
組み立てさえすれば、後は、RS232Cケーブルさえ用意すればOK。
結構まともなデバッガも使える。

H8は動かすまでが大変で、まともなデバッガのない環境も多い。

R8Cの方が書籍が多いから、手に入るんならR8Cの方が
いいと思うが、キットで入手しやすいのがあったかな。

久々にH8に戻ってきたんだけど、いまHEWって

- kpitgnutoolsのHEWv4
- ルネ純正HEWv6評価版（制限付き）

の２つがあるよね。みんなどっち使ってるの？それとも
エディタ＋gccでやっててHEWなんて使ってねーよって感じ？

KPITのHewじゃねーだろが。
Hewはあくまでもルネサスツール
Hewの設定環境を引き継ぐだけだろ。
コンパイラはあくまでもgcc
そしてgccは糞ってことは既出

>>145
>M16Cのメリットは…ノイズに強いらしいという都市伝説がある。

都市伝説じゃないよ。旧日立（小平）の人が認めてたから。

小平？
武蔵じゃなくて？

>>150
小平と武蔵は同義だろ

gcc使って、動かせる人って少ないからだろ？

>>148
私も最初は驚きましたが、KPITからダウンロードしてインストールするとHEWがインストールされて、ツールチェーンに
gccが登録されています。

>>145
ポインタが16bitだとなにが不便なの？

M16CはR8Cとバイナリ互換だし、R8Cはロードマップ上に
残っているので、R8 > M16C > H8 だと思うけど

H8は32bitレジスタ、アドレス空間も(アドバンスモードで)16MBで、
昔の68000みたいに実質32bitCPUっぽく使えることを言ってるのでは。
gccでもそういう風に使うだろうし、MESみたいなOSを載せる余裕もある。

>>154
16bitだと64kBしか使えないでしょ。当り前だけど

組み込みで 64KB も使えて何が不満なんだ。

OS乗せてSDカード対応させてとかやりたいときもあるんだ

>>158
SHでも使ってろ

m16Cのアドレス空間は１Mバイト。 16ビットのアドレッシングしか
できないわけじゃない。 64kバイト境界で near と far に分けてる。
m16Cの中には、内部ROMを512Kもつモデルだってある。


C言語でプログラムする場合、あまり意識する必要はないんだけど、
ROMデータを扱うとき、たとえば定義してある文字列を扱うとのに
はまりやすい、と思う。

ＨＥＷでＨ８-３６６４使っとります。
別のファイルにある関数呼ぶときに、引数がうまく渡せなかったんだけど
リストファイル見たら、飛び先の関数で使わないＥ０に引数の値が入ってた＼(^o^)／

メインと同じファイルに入れたらＲ１Ｌに入れてくれるようになったんだけど、
これってバグっすか？

>>161
おまいのコードがな。

呼ぶ方にプロトタイプ宣言入れれ。
入ってないとintと仮定されるので、charで受け取れねえ。

>>162
さすがだね。
なるほど　勉強になりましたよん。

>>162

なるほど。

呼ぶ方に
extern void hoge();
入れてもダメで

extern void hoge(int*);
って感じで型を入れててやらないとうまくいかなかったっす。

この場合、
hoge("abcde");
って感じで呼び出すと
C1016 (W) Argument mismatch
って出るんですが一回、定数に置き換えてそのポインタを渡さないとダメなんでしょうか？

>>164
はじめてのCでも読み直して来い

>>164
自分の無知を棚に上げて、鬼の首を取ったかのように
いかにもアドバイスが悪くて苦労しました、みたいなレスすんなボケ。

何を偉そうに

>>164
・extern要らない
・別ファイルの関数の実体の引数と比べて見て違わない？
・文字列入れるなら"int *"じゃなくて"char *"にするべきでは？

>>164
だからこのスレで一般的なＣのこと聞くのヤメレ。

すいませんねえ
糞どもが調子に乗ってしまって

>>156
使いたければ　far 　を使えばいいだけの話。
far と書くと移植性などで使いたくないとかいう理由？

そういや石田晴久先生が亡くなったそうだな。
K&R読んだ奴は祈っとけﾅﾑﾅﾑ

>>172
K&R原文で読んだ人には関係ない話

ttp://japan.renesas.com/fmwk.jsp?cnt=rx_family_landing.jsp&fp=/products/mpumcu/rx_family
とりあえずマニュアルでも読んでみますかねえ。

日立　万歳!

一通り眺めた。
CPUはR32をH風にした感じか？
周辺は完全にH8Sだな。

HなCPUをC言語で使ってる人はそんなに苦労しなくても移行できそう。

このスレの新参者でございます。
Ｈ８／３０５２　と　ＨＥＷ　で天体望遠鏡の方向制御をしたいと思っています。

質問があります。
・浮動小数点演算は出来ますか？（処理時間が大きくてもＯＫです。）
・ｓｉｎθ、ｃｏｓθ、ｔａｎθ の演算は出来ますか？

以上、よろしく御願いいたします。

http://www.binzume.net/library/aki-h8_05.html

>>178
あ、やっぱりHEWで浮動小数点はサポート外ですか？

質問です　リチウム電池を0.5Ｖ以下まで早くするにわ、どのようにするのが良いのでしょうか？
良い方法が、あれば教えて下さい、お願いします。

>>180
ついでに回答します。

リチウム電池で0.5Vは過放電です。
過放電したリチウム電池を充電すると熱暴走（発煙、発火）の危険性があります。
リチウム電池は3.0V以上で放電終止するのが一般的です。

以上、スレ違いのような気がしますが。

もう一度質問させて下さい。

HEWを使うという前提で
浮動小数点演算、ｓｉｎθ、ｃｏｓθ、ｔａｎθ の演算が可能なSuperHは
どのSH？？からでしょうか？

よろしく御回答をお願い致します。

>>179
ライブラリはあるから>>178が紹介しているようなことをしなくてもできるよ
まー、速度は遅くなるし、コードはでかくなるしで場合によっては使えないかもしれないけどね

>>183
H8用の浮動小数点ライブラリがあるですか！
一度トライしてみます。

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

H8(HEW)のfloat演算はリアルタイム制御では使いもんにならんが、遅くていいのならフツーに使える。
<mathf.h>をインクルードすれば三角関数ライブラリもおｋ。

わーい♪　うれしいな♪

俺なら 78K か V850 を使う。

いくら何でもこれから製品化するのに90nプロセスはひどすぎるだろ
せめてリーク電流対策した65nで低消費電流路線狙うべき

内蔵flashが作れないとか。

結局H8はディスコンにするのか？
RX上でH8バイナリが動くとかはないよな？

SH7144のマニュアルで調歩同期式の最高値がPφ=24MHzのとき
750000bpsなのですが、
実際には57600bpsぐらいまでしか使えません。
言語はC言語で書いていて処理に時間がかかってしまい、
仕方がないことなのでしょうか？それとも別に原因があるの
でしょうか？

受信エラーが出てるのでは？

>>191
割込みと受信バッファ使えばC言語でも115200bpsも楽勝
ポーリングで受信のたんびにデータ処理をしているとそんなものかも知れない。

>>191
受信ルーチン全部アセンブラで書け。
無駄なレジスタ保存はするな。
パイプラインストールしないように考えてコード書け。

SH7144ならソフトだけでコンポジットビデオ信号作れるほどのパワーがある。
SCI使ってるなら57600Bps程度の通信などCPU能力の1%も消費しないはず。

7144はそうでも吉田基板は16x2のLCD制御するのがやっと

>>191
シリアルラインに遅いトランシーバやフォトカプラ使ってない？

>>191
楽勝ということはやっぱプログラムが悪そうな予感ですかね。
受信割り込み処理はリングバッファに格納してるだけです。
以下ソース
やっぱ遅いでしょうか？
char dt;
struct IORegs *r;
struct RingBuffer *rx_p;

r = ®[ch]; /* レジスタアクセス用ポインタ設定 */
rx_p = &rx[ch];

dt = INPORTB( r->rdr ); /* データの読込 */
RESBITB(r->ssr, 0x78); /* RDRFクリア */
if ( rx_p->count >= COM_BUF_SIZE ) /* オーバーランエラー */
return;
rx_p->buffer[rx_p->save++] = dt; /* バッファ格納 */
if ( rx_p->save >= COM_BUF_SIZE ) /* リングバッファ構築 */
rx_p->save = 0;
getCount( rx_p ); /* データ数算出 */

>>196
トランシーバはADM3202です。100Kぐらいなら余裕のはず。

1回の割込発生につき1バイトしか読みださないの?

>>197
getCount 関数は何をやってる(遅い処理やってないか)？
ぐらいかな、このリストで思うのは。count とかがどこで更新されるのか
わからんので、ほかはなんとも。

>>198
読み出す前に次のデータがきてしまうとオーバーランエラーじゃない？
>>197 のソフト的なやつじゃなくて、受信ハードの方の。

>>197
ソースを見た限りでは余裕だと思う
受信後のフラグのリセットなどが影響しているのかも知れませんね
オシロがあってボードにON-OFF出来るピンがあれば割り込み処理の間だけ
ピンをONしてオシロで観測すると良いですよ。

ちなみに下はSH7144ボードで使っていた割込受信ルーチン
#define rssts() (SSR_1 & SSR_RDRF)
#define reset_rs() (SSR_1=(SSR_1 & ~(SSR_RDRF | SSR_ORER | SSR_FER | SSR_PER)))
#define rsdata() RDR_1
void int_rxi(void)
{
if(rssts()){
if(rx_ct < RXD_BUFFSIZE){
rxbuf[rx_wp] = rsdata();
rx_wp = (rx_wp+1) & (RXD_BUFFSIZE-1);
rx_ct++;
}
}
reset_rs();
}

>>198
1回の割り込み処理で1バイト読み出しです。

>>199
getcountの中身はリングバッファに溜まったデータ数を
更新しているだけで、countの更新はこの関数で行われています。

static void getCount( volatile struct RingBuffer *b )
{
if ( b->save >= b->load )
b->count = b->save - b->load;
else
b->count = b->save + COM_BUF_SIZE - b->load;
}
なので大した処理ではありません。

リングバッファに使ってる領域はキャッシュ有効or無効?

>>200
受信割り込みの入り口と出口に仕込んでオシロで見てみました。
正常に通信できる57600とダメな115200ともに2us程度でした。

>>202
特に意識してRAMを使っていないのですが、どうやって確認すればい
いでしょうか？

誤差がでかすぎるのでは？

>>204
ttp://documentation.renesas.com/jpn/products/mpumcu/rjj09b0026_sh7144.pdf
391ページの計算式でPφ24Mで115200のときN=6で誤差が1%程度です。

ちょっとソースさらします。
ttp://blog-imgs-24.fc2.com/s/o/u/soundreview/sci.txt
115200にするとrsPutchで1バイトづつ送信してもPCには正しく
表示されませんでした。

>>203
115200bpsでデータ受信間隔はおよそ80uSだから
処理速度の点に関してはOKですね。

>>205
相手がパソコンなら、パソコンの設定が正しくないのかも？。
一度、ループバックで確認してみたら。
オシロがあるんなら、信号見れば正しいボーレートかどうかわかるはず。

>>205
誤差は7%じゃない？
だとするとちょっと厳しそうな気がする。

>>205
パソコンの方も疑ってみようと思います。
明日確認してみます。

>>208
約7%ですね計算間違ってました。
誤差ってのがいまいちピンときませんが、7%っていうのは相当なんで
しょうか？

>>209
調歩同期で7％誤差では、まず通信できない。
フレーミングエラーとか出てるはず。

>>210
どうやらそのようですね。
確かにPC側のソフトにもフレーミングエラーと出ていました。
ググったら下記でてきました。
ttp://misumi.sakura.ne.jp/blog/archives/2007/05/115200bps.html
まさに同じふろくボードを使っています。
できないことがはっきりわかってすごくすっきりしました。
皆様ありがとうございました。

7.3728MHz×4

内部オシレータでシリアル通信するのは避けた方が賢明？
データシートの発振周波数幅がめちゃくちゃ大きいけど、
実力値的にはどうでしょうか。

なぜ計算してみようとしないのだろう・・・・

>>213
データシート上は使えないことになるから、
よほど確かな根拠がない限り普通は使わないな。

>>214
実力値は計算じゃわからんだろ。

SH7144だと動作周波数は4MHzから50MHzと書いてある。

は？

H8 3664のI2Cって不具合あるみたいですけど、
開始条件発行後にIRICが一向に立たないことと関係あるんでしょうか？

>>218
まだ日立時代にその件でクレーム付けた。
メール返信で不具合を認めた上で「3694のご採用を強くご推奨します」だとよ。
I2C使うんだったら3664は止めとけ。

僕、柚木正章です。

>>219
どうもです。
EEPROM書き込むだけなんで、3664でやっていこうかと思います。

教えてください。

>>222
何を?

>>222は　さだまさし。
「海は死にますか　山は死にますか」

俺は、オタッキーデブヲタ！柚木正章です。

IBM-PC互換機は重いらしい。

こんにちわ！

デブヲタの柚木正章です。

IBM-PC互換機を持ってます。

重いで

こんばんわ

包茎ちんぽの柚木正章です。

皮が剥けない、どうすればいいの？

はあ？

ttp://headlines.yahoo.co.jp/hl?a=20090416-00000029-jij-bus_all

MIPS/ARM/SHが同じメーカーから出てくるのか…
ややこしいのう。

>半導体国内2位のルネサステクノロジ（東京）と同3位のNECエレクトロニクスが、
>来年4月をめどに経営統合する方向で最終調整に入ったことが16日、明らかになった。

>ルネサステクノロジとNECエレクトロニクスが経営統合する方向で最終交渉に入ったという一部報道に対し、
>NECエレクトロニクスは4月16日、「報道されたような事業再編について当社として決定した事実はない」
>というコメントを発表した。

どっちやねん。

>>230
恐らく上だろな

会社統合後はCPUラインナップ統廃合するんだろな

頼むから MINICUBE2 対応は継続してくれよ。

>>230
「最終調整に入ったけど、何も決定していない。」と言うだけのこと。

と言うか、この手の話の広報のコメントは大抵これと同じだろ。

>>231
V850Tinyとか。
減ることはないだろうな。

日立と三菱のとき、開発環境やツールの統合であれほど大変だったのに
さらにNECも統一するわけ？

前回に懲りて、今回は無理してツールの統合はやらないんじゃないかと。

>>235
それじゃ合併した意味がないからツール統合するだろう

それより問題はNEC本体に残ってる半導体畑の人間を
道連れにするかどうかだな

>>236
NECのシリーズは次シリーズからHEWが使えるようにする・・のかなぁ・・？
統合の実績からいって、NECのほうに統合するのはあり得ないと思う

別々のままでいいんじゃないかねえ。
それぞれのユーザーも慣れてるだろうし、デメリットしかないように思うけど。
無償版の利用制限はルネに合わせて欲しい。ｗ

>>238
三菱日立がやっと統合できたんだから、１０年かかってもおかしくないよね。
というか、RXはこのままで、次シリーズで統合ということかもしれないけど。

ルネサス（日立三菱＋NEC)とエルピーダ（NEC三菱+日立）も一緒になりそうだけど。

ＣＰＵ・半導体メーカーの合従連衡の工程表

2010年　ルネサスとNECエレクトロニクスが合併
2020年　富士通マイクロエレクトロニクスと合併
2030年　テキサス・インスツルメンツ （米）と合併
2040年　東芝セミコンダクターと合併
2050年　フリースケール・セミコンダクタ（米）と合併
2060年　ARM Ltd（英）と合併
2070年　サン・マイクロシステムズ（米）と合併
2080年　インフィニオン（独）と合併
2090年　ＡＭＤ（米）と合併

2100年　インテル（米）と合併
この年、ＨＥＷはバージョン100となり、プログラム規模は１テラ・バイトを超えた。

>>240
マジレスすると現在の組み込み系での平均メモリ搭載量が64KB Flash/2KB SRAMと
控え目に見たとしても、2100年ならムーアの法則により35184372088832倍になる。
よって、Flashなら68TB搭載が標準になる。普通搭載Flashの1/64以下しか使わない
なんてヘボな設計・チップ選択はしないので、2100年には50TBを超えるあたりを
うかがってるはず。

ちなみにWindows2100はその頃には最低動作環境2EB RAMになってるはず。

あ、間違えた。 2^((2100 - 2009) / 3) = 1073741824倍ね。
そこから先の数字は正しい計算の方の数使ってるからそのまま。

いや、多少の間違いはどうでもいいレベルだろ

　　　　　　　　　　　　／）
　　　　　　　　　　　／／／）
　　　　　　　　　 ／,.=ﾞ''"／
　　　／　　　　 i f　,.r='"-‐'つ＿＿＿_　　　こまけぇこたぁいいんだよ！！
　　/　　　　　 /　　　_,.-‐'~／⌒　　⌒＼
　　　　／　 　,i　　　,二ﾆ⊃（ ●）.　（●）＼
　　　/　 　　ﾉ　　　 ilﾞフ::::::⌒（__人__）⌒::::: ＼
　　　　　　,ｲ｢ﾄ､　　,!,!|　　　　　|r┬-|　　　　　|
　　　　　/　iﾄヾヽ_/ｨ"＼ 　　 　 `ー'´ 　 　 ／

動作速度はどうなるの？

>>241
マヂレスすると、メモリやCPUのロジック素子を構成する原子の大きさや
半導体中での電子の移動速度は決まっているし、ピン数や歩留まりなど
から、実用的なダイやパッケージのサイズも決まっているので、過去の
ムーアの法則が、将来も従来どおり適用できるわけがない。

現に、CPUの動作クロックの上限はここ数年で既に頭打ち、メモリやペリフェ
ラルを接続する外部バスに至ってはもう10年近く進歩がない。

大量のメモリを積んだとしても、メモリ有効に利用するため、例えば8GBの
メモリ全てにHDD等の外部記憶からデータやプログラムをロードするのに、
どれくらいの時間がかかるか単純計算してみるといい。

あるいは、ライトバックキャッシュが有効な場合、電源断が起こる危険性や
シャットダウンにかかる時間を想像してみるといい。

この人んｈｋで見たことある

試用版HEWを新しいのにインストールしなおしたら同じソースコードでも微妙に動作が変わって
驚きだ・・
SH7045F使っていてMTUのコンペアマッチで割り込みを起こすようにしているのだけど
以前はMTUの値を読んで0になっているときには割り込みが必ず終了していたのに
今のだと割り込み関数の実行前の場合がある。
まー、もっと腕があれば詳しく調べられるだろうが不思議な現象だ。

　　　　　　　　　　　　／）
　　　　　　　　　　　／／／）
　　　　　　　　　 ／,.=ﾞ''"／
　　　／　　　　 i f　,.r='"-‐'つ＿＿＿_　　　こまけぇこたぁいいんだよ！！
　　/　　　　　 /　　　_,.-‐'~／⌒　　⌒＼
　　　　／　 　,i　　　,二ﾆ⊃（ ●）.　（●）＼
　　　/　 　　ﾉ　　　 ilﾞフ::::::⌒（__人__）⌒::::: ＼
　　　　　　,ｲ｢ﾄ､　　,!,!|　　　　　|r┬-|　　　　　|
　　　　　/　iﾄヾヽ_/ｨ"＼ 　　 　 `ー'´ 　 　 ／

この人、顔はおもいっきりテキトーなくせに手は妙にリアルで気持ち悪い

いやいや コイツ 人じゃないから

きっと中の人などいる

>>246
技術者「今度ばかりは理論的限界です。無理っす！」
経営者「私の在任中は、ムーアの法則を維持します」　　このせめぎ合い。

ぶっちゃけ、物理的に無理とされた処理能力でも、ＩＢＭの1000コア！ＣＰＵで無理が通ってしまった。
今後はＣＰＵの内部処理で、大量のコアを統合するソフト面で競争にならんかな。

ところで、手（ポート）だけリアルで顔（ＣＰＵ）がゆるい・・・・Ｈ8そのものでは？

>>246
コア数競争が一段落したら、次はロード速度を向上するために
バス幅競争になって4096bitバスとかになる。そしたらもうチップ内でも
パラレルではやってられんてことになって、高速シリアルバスが登場して
そしたら・・・

無線とか光コネクトのチップとかでてこないかな。ルネとかNEC（もう同じ会社か）が
無線デバッグデモってたけど、もはや半田付けとかの概念が消滅して、電源だけ
配線したらモジュール間がハイパーキューブ接続されるの。

>>254
> バス幅競争になって4096bitバスとかになる。

今やCPUより集積度の高いGPUでも内部256bitとかだろ。バス幅を広げると
ビット間の遅延時間差のばらつきが大きくなるし、チップ上で配線領域が
占める面積も増える。配線間のクロストークや電源ノイズも増えるだろう。

> パラレルではやってられんてことになって、高速シリアルバスが登場

パラレルをスループット維持したまま、シリアルに変換するとなると、例え
ば32bit幅をシリアルで送るには、クロックレートが32倍以上でなければなら
んわけだが？

> 半田付けとかの概念が消滅して、電源だけ 配線したらモジュール間が
> ハイパーキューブ接続されるの。

野良チップが流行するわけでつね。

GPUって何だよ>>255
恥ずかしい間違いだなｗｗ

CPU（中央演算装置）だぞ
情報処理2種を持ってる俺が言うんだから間違いない。

>>256
もちつけ。
ttp://www.google.co.jp/search?hl=ja&q=GPU%E3%81%A8%E3%81%AF&lr=
これ読んで冷や汗たらせ。ｗ

ちょっと待て
　その書き込みは
　　アサヒかも

　　　　　　　　　　　　／）
　　　　　　　　　　　／／／）
　　　　　　　　　 ／,.=ﾞ''"／
　　　／　　　　 i f　,.r='"-‐'つ＿＿＿_　　　こまけぇこたぁいいんだよ！！
　　/　　　　　 /　　　_,.-‐'~／⌒　　⌒＼
　　　　／　 　,i　　　,二ﾆ⊃（ ●）.　（●）＼
　　　/　 　　ﾉ　　　 ilﾞフ::::::⌒（__人__）⌒::::: ＼
　　　　　　,ｲ｢ﾄ､　　,!,!|　　　　　|r┬-|　　　　　|
　　　　　/　iﾄヾヽ_/ｨ"＼ 　　 　 `ー'´ 　 　 ／

オタクは、柚木正章だ

おチンチンが剥けない

オタッキー柚木正章です。

アメリカ人的考え

「新人類」！！

「ラムちゃんだ！」

一人で日本橋行くのってオタク！！

以上、柚木正章でした。

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

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

　　　　　　　　　　　 _,ノ‐''''''^¨¨¨⌒￣⌒^^''¬-､,_　　　　　　　　　　
　　　　　　　　._v-''¨｀.,,vｰ─-､　　　 .,,vｰ─-､　 .¨'ｰu_　　　　　　　
　　　　　　_ノ'″　　./′　　　 ¨┐ .／　　　　 ﾞ'┐　　 .ﾞ'┐　　　　　　
　　　　 ,／′　　　./　　　　　　 .ﾐ .i′　　　　　 .）　　　　 ﾞ＼　　　　
　　　 ,/′　　　　　|　　　　　●　| ｝ _●,　　　　 |　　　　　　＼　　　
　　 ./′　　　 ._,,､-ﾐ.　　　　.　　/¨ﾚ　　　 　　 .人,_　　　　　　ミ　　
　 .,ﾉ′　　._ノ'″　　＼_　　 ._,rlﾄ冖へy　　　_／　 ¨'‐u　　　　 .ﾞlr　　
　.,i′　　／ｰ-v､.,,_　　 ¨^^¨´〔　　　 〕.¨^^¨′　　__.,､ ﾞ＼.　　　 ｛　
　〕　　 ./′　　　　.⌒'''''　　　 ＼,,,,,,ノ′　 v-ｰ'''¨′　　　ﾞ┐　　 ｝　　　　＿＿＿＿＿＿＿＿＿＿＿
　|　　 ﾉ　 .────ｰ　　　　　　｝　　　　　 __,,.,､v--ｰ''　　｛　　 .］　　／
　|　　:|　　　　　　　 .__,..　　　　　 .!　　　　　 ｀　　　　　　　　.｝　　.｝　<　　　僕　オタッキー柚木正章です
　｝　 .|　　 .--:;:冖^￣　　　　　　 .|　　　　　 ¨¨¨¨¨¨ﾞﾌ¨¨′ .｝　　｝　　＼
　.|　 .｝　　　　.＼_　　　　　　　　 .｝　　　　　　　　._／　　　　｝　 .:|　　　　￣￣￣￣￣￣￣￣￣￣
　 ).　.〕　　　　　 .ﾞﾐzu,_　　　　　　｝　　　　　 _,ノ┘　　　　　 ｝　 /　　
　 .｛　 ).　　　 .,/'″　 ¨ﾞ(ｧv､,_　　.!　 ._,,,,v‐'^′　　　　　　 ,ﾉ　 ﾉ　　
　　 ﾐ.　7,　　 .iﾞ　　　　　 〔　　｀¨¨^^⌒　　　　　　　　　　 ,ﾉ′,/　　　
　　　ﾞ).　ﾞli.　_ﾉi.　　　　　ﾉ　　　　　　　　　　　　　　　　 .,r′.,ﾉ　　　
　　　　＼ ﾞ>'′^ｰ､､､v‐′　　　　　　　　　　　　　　　.,r′ ／　　　　
　　　　 .|／　　　　　　｝　　　　　　　　　　　　　　　　./′,／　　　　　
　　　　./′　　　　　 ,i¨¨¨¨¨¨ﾞソ冖干ｱ^^^^^^^^^^^|　r'′　　　　　　
　　　 .,i′　　　　　 ./¬冖'''''7′　　　∨¬ｰｰz─-「　＼　　　　　　
　　　 .｝　　　　　　_ﾉ　　　　　厂¨丁¨¨ﾌ　　　　.ﾐ､　　　　ﾞ＼　　　　
　　　 .〔　　　　　./′　　　　　ﾞ'-､..!,,ノ'′　　　　 ﾞ).　　　　　ﾞ).　　　　
　　　　｛.　　　　.ﾉ　　　 ､､､､､､､､､､､､､､,,,,,,,,,,､.,　　〕　 .､　　　｛　　　
　　　　 .〕　　　 .］　　　 .|　　　　　　　　　　　 .〕　　|　　ﾞl!　.,／⌒┐　
　　　　　｛　　　 .|　　　　|_　　　　　　　　　　 ,ﾉ　　,｝　　 ﾚ''′　　 .｝　
　　　　　 〕　　　 ).　　　 .ﾞ＼_　　　　　　　,,r''′　丿　　 八,　　　_,ﾉ　
　　　　　 .〕　　　 .＼_　　　　^''ｰ-vvv-ｰ'″　　,,ﾉ　　　 ］　¨'ｰ'''″　
　　　　　 .:|　　　　　 ^'ｰv.,_　　　　　　　　 _,ノ'″　　　　｝　　　　　　
　　　　　 .｝　　　　　　　　 ¨ﾞ''¬ｰ----ｰ''″　　　　　　 ］　　　　　　
　　　　　 .｝　　　　　　　　　　　　」　　　　　　　　　　　　.|　　　　　　　
　　　　　,r冖¬¬¬¬〜----ｰ《､､､､､､､､､､､､､､,,,,,､.....|　　　　　　　
　　　　 r′　　　　　　　　　　　　|　　　　　　　　　　　　 .ﾘ.　　　　　　
　　　　 .＼,,_　　　　　　　　 ._,,,vrh､､,_　　　　　　　　　　 ._）　　　　　
　　　　　　　¨^^'''''''^¨^^''''''¨′　　　 ⌒^^^'''''''''''^¨¨¨⌒″

ぼく柚木正章です。

「ぼくドラえもんです。」は大山のぶ代が作り出した糞キャラだぞ。
本来は君だれと聞かれて「ドラえもん。」これだよ。

（株）髭男爵のギャグ -　「ン」設計の

超ヲタクの　柚木正章です。

NECｴﾚになるんだっけ

RENECAS

>>269
ルネカス、ﾜﾛﾀ！

NECESASというのはどう?
ルネカスはいい感じだけど、ち○カスの仲間になりそう。

はやく、潰れることを祈ってる。

3664Fを使ってるのですが
動作中にフラッシュROMへ設定値等を保存することは可能でしょうか？

それとも設定値保存用にEEPROMを別途用意しないといけないのでしょうか？

実装面積とかコストとかの問題がないなら、
EEPROM 付けとく方がいいと思う。

H8-3694くらいの石を使うのですがC++でコードかくのは無謀ですか？

納期の問題がなさそうで、コードが収まって実行スピードが十分なら、
別にいいんじゃないかと思う。
C++ は、後々資産になるクラスを残していかないとメリット薄いと思うけどね。

実行速度はそこまで問われないから、コードサイズとかRAM容量がネックになるかなぁ
単にC++を長く使ってたせいかCとの境界線が曖昧になっててやりにくいってだけなんですが

>>273
書き込み中はフラッシュROMが見えなくなるとかの制限があったような？

>>273
>>278も言っているように、フラッシュ書き込み中はフラッシュは読めない。
フラッシュをアクセスするコードはすべて内蔵RAMに置かなければいけない。
オールC言語でもできなくはないけれど、アセンブラの知識は必須。

それを簡単にこなせるような人は、そもそもここでそんな質問する必要もなく
着々と実行に移しているはず。

プログラムも乗っているフラッシュに、書き込み中に強烈なノイズが乗って
CPUにリセットがかかったような場合など、極めて例外的なケースに対しても
完璧な対処ができる自信がないなら、>>274が言うように
外付けEEPROM付けるのが吉。

>>279
＞書き込み中に強烈なノイズが乗って
＞CPUにリセットがかかったような場合など、極めて例外的なケースに対しても

あー、あるある・・・orz
うちの設計さんがEEPROMケチりたかったのかしらないが、それでトラブル出して大問題になってたなぁ

内蔵フラッシュって書換保障回数が極端に少ないのはどうしてなんだよ

すべてをフラッシュメモリとして作られるデバイスとでは
製造プロセスが違うから。

…と言う話だ。

おーい、柚木正章！！！！！！

終身雇用しとるやろ！

コテコテのベタベタの日本人の考えや。

【露天】▲川温泉その３【混浴】
http://love6.2ch.net/test/read.cgi/onsen/1172292931/

277 ：名無しさん＠いい湯だな：2009/05/10(日) 19:50:36 ID:regnN8oD
いきなり女の子たちが大量に入って来たから驚いた。
彼女たちは近所の中学のテニス部で、毎週土曜日は練習後に入浴してるそうだ。

おまけに５分くらいしたところで、顧問の♀先生・・・25歳独身(推定)・・・が
「遅れてごめーん」と入ってきた。

で、風呂に浸かっている俺に気がつくと、にっこり笑って「旅行ですか、どちらから？」
と話しかけて（ｒ

>>277
C++の使い方にもよるけど、クラスやテンプレート使っても
コードサイズなんて大して増えないでしょ？数キロバイトが
問題になるような環境じゃなければ。

トラ技の付録にビンヘッドをハンダ付けしてもう2年

あっ。3694ってROM 32K、RAM 2Kとかのやつか。それは苦しいね。

赤字の半導体部門、やめろよな。

まずは赤字をやめよう。

初心者ですが質問してもいいですか？
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とかもあってグルーなユーザーが多い