Hi,

i am a beginner to embedded. i have little(2 weeks) experiance in MSP.
when i goes through the system header file i saw a lot of functions.

i have some questions.

1. what is the usage of i/o function. Ex. printf
2.what is the usage of file functions.

pls. anyone answer my questions.
thanks.
by
singh

trajasinghpeter wrote:
> Hi,
> 
> i am a beginner to embedded. i have little(2 weeks) experiance in MSP.
> when i goes through the system header file i saw a lot of functions.
hi&welcome,

do you have any programming background? If not I advise to read
some beginner tutorials in c. Also the C-Faq is a good source of answers.
Google is your friend. Try writing/udnerstanding some simple C programs,
you can try this without downloading to msp. just use your favorite c
compiler on your box. Afterwards try to understand tyhe special needs
for msp, like how to control the input & output pins. There are many
examples on TI's webpage.

> i have some questions.
> 
> 1. what is the usage of i/o function. Ex. printf
prints a character string. on a unix box type: 'man printf'
(also google
brings up some man pages and every c book has a page on printf).

> 2.what is the usage of file functions.
writing and reading bytes to files. rest: (s.o.)

Greetz,

	Georg
> 
> pls. anyone answer my questions.
> thanks.
> by
> singh
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

trajasinghpeter wrote:

>Hi,
>
>i am a beginner to embedded. i have little(2 weeks) experiance in MSP.
>when i goes through the system header file i saw a lot of functions.
>
>i have some questions.
>
>1. what is the usage of i/o function. Ex. printf
>2.what is the usage of file functions.
>  
>

Well, in an embedded system there is no "natural" way to handle 
printf-style functions, as there is no console to write to and no 
harddrive to open files on.

However, when in *debug mode* most debuggers (well, ours do, at least) 
lets printf print in a dedicated "Terminal I/O" window and file 
operations can open files on the PC that the debugger runs on.

On the other hand, in *release mode* the runtime system simply assumes 
that you have provided a set of primitives that will take care of, for 
example, sending characters somewhere (serial port, LCD screen, morse 
code, smoke signals, or whatever). When it comes to file operations, the 
primitives are on the form "open a file", "read bytes" etc.
which means 
that it's up to you to implement (or license) a full file system.

Oh, by the way, it's always educating to hear stories from the real 
world -- have any one of you actually used or implemented a file system 
in this manner?

    -- Anders Lindgren, IAR Systems

-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Hi Anders,

A long time ago I wrote a C file system which used serial I/O from the 
target to a C program on a PC.
The target file commands were simply "posted" to the PC which did the
work 
and returned the results.
I think it worked well but was a bit slow. IIRC the target code was very 
small in size.

This solution was relatively easy to implement - just a series of
"wrappers" 
bolted to a basic send/receive system.

All other emebedded file system that I have seen have been very proprietary, 
with weird APIs.

regards,

Richard

----- Original Message ----- 
From: "Anders Lindgren" <Anders.lindgren@Ande...>
To: <msp430@msp4...>
Sent: Wednesday, September 07, 2005 8:00 AM
Subject: Re: [msp430] Using I/O Function(printf/File function) in MSP430f449


> trajasinghpeter wrote:
>
>>Hi,
>>
>>i am a beginner to embedded. i have little(2 weeks) experiance in MSP.
>>when i goes through the system header file i saw a lot of functions.
>>
>>i have some questions.
>>
>>1. what is the usage of i/o function. Ex. printf
>>2.what is the usage of file functions.
>>
>>
>
> Well, in an embedded system there is no "natural" way to handle
> printf-style functions, as there is no console to write to and no
> harddrive to open files on.
>
> However, when in *debug mode* most debuggers (well, ours do, at least)
> lets printf print in a dedicated "Terminal I/O" window and file
> operations can open files on the PC that the debugger runs on.
>
> On the other hand, in *release mode* the runtime system simply assumes
> that you have provided a set of primitives that will take care of, for
> example, sending characters somewhere (serial port, LCD screen, morse
> code, smoke signals, or whatever). When it comes to file operations, the
> primitives are on the form "open a file", "read bytes"
etc. which means
> that it's up to you to implement (or license) a full file system.
>
> Oh, by the way, it's always educating to hear stories from the real
> world -- have any one of you actually used or implemented a file system
> in this manner?
>
>    -- Anders Lindgren, IAR Systems
>
> -- 
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> 

Richard (UK). wrote:

>A long time ago I wrote a C file system which used
serial I/O from the 
>target to a C program on a PC.
>The target file commands were simply "posted" to the PC which did
the work 
>and returned the results.
>I think it worked well but was a bit slow. IIRC the target code was very 
>small in size.
>
>This solution was relatively easy to implement - just a series of
"wrappers" 
>bolted to a basic send/receive system.
>  
>
This is basically what our debug interface does.

>All other emebedded file system that I have seen
have been very proprietary, 
>with weird APIs.
>  
>

That doesn't sound that effective, especially since it seems like it 
would require quite a lot of work to connect such a thing to the 
interfaces assumed by normal compiler libaries. To me, the natural thing 
would be for the implementors of the file systems to provde 
compiler-specific interfaces so that the users could simply add that 
component to their application. Or even better, that we could create a 
"standard" interface that everyone could use.

    -- Anders Lindgren, IAR Systems
-- 

Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.