[En-Nut-Discussion] stdio + nutrom

[Pavel Chromy]

NGB wrote:

>>IMHO, this is one of *the* strong points of Nut/OS. It enables you to create
>>device
>>drivers that you can access using standard functions like fprintf,fgets,
>>etc.
>>In most compiler/developer distributions you can only use stdio functions on
>>files.
>>If you want to use the supplied functions to control your devices you run
>>into all
>>sorts of problems, which, in Nut/OS, you don't have.

> That kind of makes sense for 'f' functions but it doesn't make sense for 's' 
> functions that print to a buffer.

Well, look at the sources, the formatting itself is done by (generic) _putf(),
both fprintf() and sprintf() being just nice lids on top of it 
(through vsprintf() and vfprintf()). 
It is true that without sprintf there would be probably no need of such architecture
and fprintf might be faster.
On the other hand this way support for program space strings (also as objects of formating)
is provided.


>>fopen(UROM:NameOfFile, "r");
> 
> I understand that, what I don;t get is how I can get my pointer to the data ?

Well, you don't. Remember that the rom file resides in program space, whoch means
that even if you got the "pointer" to the data, it actually would not be a pointer since
it would not be possible to dereference it the usual way (GCC does not support this AFAIK),
but rather just an address pointing to program space.

> if I have to use fread this is going to be very slow

See above, you have to use LPM instruction (or memcpy_P()) to get the data anyway,
and fread does exactly the same. If you don't read it byte by byte but by blocks,
the overhead is not that bad. I'm using my own device driver to acces I2C EEPROM as a file
(with the advantage that I don't care whether the data is in EEPROM or program space).


-- 
#define QUESTION ((bb)||!(bb))

Mgr. Pavel Chromy
ASIX s.r.o.
Staropramenna 4
150 00 Praha 5