H8でfopen()/fgets()/fputs()

H8でfopen()/fgets()/fputs()/fread()/fwrite()その他FILE系関数を

2003/JUL/27

トラ技/秋月/HEW/HEW2あたりのCコンパイラにFILE系関数を導入してみます。と言ってもファイルシステムを載せているわけではなく、デバイス対象と思ってください。またモニタ配下などシングルタスク環境ではfgets()など入力系はめちゃくちゃ扱いにくいです。

UNIX標準関数とH8上のプログラミングについてある程度ご存知の方を対象に書いてます。
無保証です。各自の責任においてお願いします。

参考資料

モニタソースパッケージにあるlower.c
コンパイラマニュアル…手元のADJ-702-303では

9.2.2節…プログラミング＞初期設定プログラムの作成＞実行環境の設定＞低水準インターフェースルーチン
10.3.1節…C/C++言語仕様＞C/C++ライブラリ＞標準Cライブラリ

コンパイラ添付stdio.h

とりあえず

ターゲットプログラムにfopen("dev","r");fgetc(fp); みたいのを書き足して、トラ技Cなり秋月Cなりで普通にコンパイル、リンクしてみてください。いくつか関数が見つからない、と言われるはずです。そういう関数を手書きして追加リンクすることでFILE系関数が利用できるようになります。

でおいらは何書きゃいいのさ？

int open(char *fileName, int openMode, int openFlag)…fopen()の下請けで呼ばれ、文字列fileNameを解釈して fd(UNIXでいうファイルデスクリプタ)を返してやります。以後fdによる参照になります。またたとえばリードオープンのfprとライトオープンのfpwが同一のfdを参照しても構いません。デバイスの初期化をここでやりたくなりますが、無理にここでする必要はありません。
int read(int fd, char *buf, unsigned int count)…open()で返したfdからcount(注：符号無16ビット) バイトを読み出しbufに送り、実際に読めたバイト数を返します。1バイトで返してもかまいません。 -1で返すとEOFが立ちます。戻り値が符号付16ビットですね。最大32767バイトかも知れません。 0で返してもEOFになるようで、リトライの類は(やるなら) read()でする必要があります
int write(int fd, char *buf, unsigned int count)…open()で返したfdにbufから count(注：符号無16ビット)バイトを書き出し、実際に書けたバイト数を返します。1バイトで返してもかまいません。 -1で返すとEOFが立ちます。0で返してもEOFになるようで、リトライの類は(やるなら) write()でする必要があります
int close(int fd)…fclose()の下請けで呼ばれます。複数のfpが同一のfdを参照するのを許すのであれば、全fpのfclose()までclose()してはいけないことになります。デバイスの初期化をopen()以外でするのなら、close()では何もせず単に0を返しておけば良いでしょう。
char *sbrk(size_t size)…常に-1を返しておけばよいでしょう。 (sbrk()が呼ばれたことがわかるようにしておくとベターかも)
fopen()で返されたfpはまだバッファが(場所もサイズも)設定されていません。そのままfputs(,fp)とか呼び出すと、あわててmalloc()を呼び、さらにその下請けとして sbrk()が呼ばれるようです。が、それなりにsbrk()を実装してもmalloc()の動きが変で期待した動作になりませんでした。
int lseek(int fileno, long offset, int base)…アプリケーションからfseek()やlseek()をよばない限り実装自体不要です。

デバッグ時にはopen()の中でprintf("open() が呼ばれました。引数は%s %d %dです\n",,); とかやりたくなりますが、マニュアル(10.3.3節)にはFILE系関数は全然リエントラントじゃないぞとあります。fpかfdが異なれば平気な気がしますが、独自の出力ルーチンを用意したほうが無難です。当サイト内にあるOUT_STRING()なんかいかが？

添付lower.cについて

モニタソースパッケージについて来るlower.cですが、少々いじる必要があります。

int read(int fileno,char *buf,unsigned int cnt) /* Lower of scanf */
がありますが、 fileno==0の場合の入力ですからむしろreadSTDIN()とリネームして、別に用意する独自read()から
```
int
read(int fd,char *buf,unsigned int cnt)
{
	switch(fd) {
	case           0 : return( readSTDIN(fileno,buf,cnt));
	case: USBPIPE0FD : return( readUSB  (fileno,buf,cnt));
	case: LANPIPE0FD : return( readLAN  (fileno,buf,cnt));
	}
	return(-1)
}
```
で振り出すと良いでしょう。さらにreadSTDIN()の後ろのほうでエコーバックに
write( fileno, buf, cnt ); /* Echo Back */
としてますが
write( 1, buf, cnt ); /* Echo Back */
です。
int write(int fileno,char *buf,unsigned int cnt) /* Lower of printf */
も同様にwriteSTDOUT()です。
cmd24.srcで強制的に_iob[0],_iob[1]を設定してますが、sml_buf[] の使い方が正しくなく、fd==3あたりのデバイスと競合します。freopen()で正しく設定しなおすのがいいのかなぁ。

RAMもなんか必要なん？

FILE _iob[]…lower.cの中で確保してますが、同時に使用するファイルポインタの数だけ確保してください。 fopen()が呼ばれるたびに未使用_iob[i]を若い方から検索し使用されるようです。 4個確保してfopen()5連発すると、たぶん想像通りのことがおきます(^^;)。
こんな感じで立ち上げ時に0で埋めておきます。
```
_start()
{
	for(i=0;i<10;i++) clearFP(&_iob[i]); /*_iob[0]と_iob[1]は微妙です*/
}
clearFP(FILE *fp)
{
	char *cp;
	cp=(char *)fp;
	for(i=0;i<20;i++) *cp++=0 ; /*FILE構造体は19(パディングで20)バイトです*/ 
}
```
unsigned char sml_buf[]…lower.cで確保してます。fdに対しノンバッファリングを指定すると入出力にsml_buf[fd]が用いられるようです。つまりfd==8のデバイスがノンバッファリングであれば sml_buf[8]が確保されている(9個ですね)必要があります。

じゃいよいよfopen()

fopen(char *fileName,char *mode)ですが、fileNameはそのままopen()に渡されるだけですから、好き勝手に作って構いません。「いやファイルシステムを載せたい」という方は"/dev/tty"とか"tty:"とかデバイスファイルであることがわかるようにしておくといいかも。

modeは最大三文字の文字列で

一文字目…'r','w','a'のどれか

二文字目…なしか'+'

三文字目…なしか'b'

でUNIX準拠と思われます。このmodeに応じてO_RDONLYとかO_CREATとかがopen()に渡されます。(がデバイスによってほぼ固定でしょうから open()側で無視してもいいのではないかと…)

DOS系C処理系で'b'なしだとCR/LF変換したりCNTL-ZでEOFが立ったりしますが H8では'b'があってもなくても同じみたいです。

setvbuf()って何者？

fopen()の後には必ずsetvbuf(FILE *fp, char *buf, int type, size_t size)を呼ぶ必要があります (呼ばないとmalloc()が呼ばれてしまう)。以後はUNIXとほぼ同じ動作をするようです。

bufは(たとえば).bssに確保してください。advancedではsize_tはlongです。

typeは３種類あって

type fputs()時動作 fflush()/fclose()時動作

_IOFBF bufがsizeを超える時に限りwrite()がsizeで呼ばれます残ったサイズ(size以下。半端です)でwrite()が呼ばれます

_IOLBF bufにLFを書き込んだとき(注) 、bufがsizeを超える時write()が呼ばれます残ったサイズ(size以下。半端です)でwrite()が呼ばれます

_IONBF write()が1バイトで繰り返し呼ばれます write()は呼ばれません
注：常にLFをひとつバッファに抱こうとするようで、直感とは異なります。
　fputs("aaa\n",fp);⇒何もおきません
　fputs("bbb\n",fp);⇒"aaa\n"でwrite()が呼ばれます
　fputs("ccc\n",fp);⇒"bbb\n"でwrite()が呼ばれます
　fflush(fp)       ;⇒"ccc\n"でwrite()が呼ばれます
　fputs("aaa\nbbb\nccc\nddd",fp);⇒wirte()が２回("aaa\n"と"bbb\n")呼ばれ"ccc\nddd"がバッファに残ります

じゃどんなデバイスがむいてるのかな？

SCI…まずはシリアルですね。添付lower.cではSCI1固定にしてますが、 fp=fopen("/dev/tty0","w"); fputs(string,fp);みたいにしてSCI0も使えます。バックスペースに対応する(UNIXでいう-cooked)にはオリジナルの様にread()内で独自にバッファリングする必要があります。
USB…パイプを用いたバイトストリームなんで比較的相性はいいです。_IOFBFでどうぞ。
ネットワーク…まったく知らないのですが、UNIXのsocketやpipe風であれば相性はいいでしょう
EEPROM…ページサイズ(24C1024で256バイト)での_IOFBFはいい感じ？lseek()を載せる必要があります(グローバル変数に置いとく位でいいでしょう)
rawRAM…メッセージやAD変換の結果を232Cに流すと間に合わない、なんてときにRAMに fprintf(ramFP,,)しておいて、後でゆっくりfsacnf(ramFP,,);fprintf(sciFP,,");とか
NULL…何もせず捨てるデバイス。デバッグメッセージのON/OFFがお手軽にできます

なかなか便利そうじゃん？

ストリーム型のデバイスからの入力は扱いにくいです。UNIXであればなんとかデーモンをすきなだけfork()してfgets()でサスペンドさせとけばいいのですけど、シングルタスク環境では fgets(,,sciFP)でブロックされたら身動きが取れなくなってしまいます。

一方で出力系や、EEPROMなど「必ず読める」デバイスの入力には便利かもしれないですね。

無保証です。各自の責任においてお願いします。
解析その他で大先生にご協力いただいています。ありがとうございます。(ぺこり)
将来、大先生自ら情報公開される可能性もあるとのこと、楽しみにしましょう

感想などは

またはこちらの

からどうぞ。
つっこみもやんわりとなら歓迎します。

トップページ

へもどる

type	fputs()時動作	fflush()/fclose()時動作
_IOFBF	bufがsizeを超える時に限りwrite()がsizeで呼ばれます	残ったサイズ(size以下。半端です)でwrite()が呼ばれます
_IOLBF	bufにLFを書き込んだとき(注) 、bufがsizeを超える時write()が呼ばれます	残ったサイズ(size以下。半端です)でwrite()が呼ばれます
_IONBF	write()が1バイトで繰り返し呼ばれます	write()は呼ばれません