mk wrote:
> Can any one tell me how to (test)load the
> memory with test.264 bitstream.
> Regards mk

How you load the code depends entirely on the target hardware you are
using (ARM is just a CPU core; it is used in a number of processors, all
with different architectures surrounding the core), and how you are
connecting to it (serial port, JTAG debugger etc.).

If you are using a commercial development board the board manufacturer's
web site is probably a good place to start for suitable tools and
documentation for programming the processor. Failing that the chip
vendors site may have tools for the specific chip.

Clifford

mk wrote:
> Hi Clifford,
>  The c code contains fprintf which reads the test bitstream.After
> crosscompiling does the arm assembly code can read the file from the
> disk or do i need to load the file contents to memory.
> Regards
> mk

I think I misunderstood. I thought you were asking how to load the
compiled program code to your target.

To be honest I now have no idea exactly what you are asking!

Clifford

If your system does not have a filesystem, then no.

It would not bee too difficult presumably to modify the code to read the
data at run-time over a serial port for example?

Clifford

mk wrote:
> Hi Clifford,
> I have to test the compiled code.The test data is contained in a *.264
> file.The original c code uses fscanf to read the values.i want to know
> whether the cross compiled code can read the test file or do i need to
> load the test inputs to memory.
> Regards
> mk

You can use the file functions when you run the program in the simulator
(GDB/arm-elf-run).

Example:
http://www.mikrocontroller.net/attachment.php/372521/main.c
http://www.mikrocontroller.net/attachment.php/372522/newlib-syscalls.c

arm-elf-gcc -o test.elf -Os -g -mcpu=arm7tdmi main.c newlib-syscalls.c
arm-elf-run test.elf

mk wrote:
> Andreas S. wrote:
>> mk wrote:
>>> Hi Andreas,
>
>  I tried the file functions you specified.But whie linking iam getting
> errors undefined refernce to _open,_close.

Which toolchain are you using?

mk wrote:
>  I tried the file functions you specified.But whie linking iam getting
> errors undefined refernce to _open,_close.
>
These functions are among the Newlib syscalls (see section 12 of
http://sources.redhat.com/newlib/libc.html). These are specific you your
target hardware and you are expected to implement them yourself.
Typically a minimal implementation will simply support the stdio streams
(stdout, stdin, and stderr), however you can use them to add support for
a filesystem or even emulate a filesystem over a serial or JTAG
connection for example - but you do need a good understanding of
iostreams and filesystems to make it work correctly. However, file I/O
will not 'magically' work, you have to provide the drivers (not to
mention having some sort of 'media'!).

If you have a COTS development board that is one of the ones for which
the WinARM distributuion has direct support, then it may already have a
minimal syscalls package that you can start with.

If you have no syscalls implementation, other parts of the standard
library will also fail. For example you will not have support for
dynamic memory allocation.

The simple answer is that file I/O is a DIY job for embedded systems,
because no system is the same - most do not even have filesystems. You
have been less than clear what your system has and how you expect this
date to be stored and delivered.

If you are expecting a host computer to serve the file data, then IMO it
would be much simpler in the short term for you to roll your own client
server architecture and deliver the data over serial or USB (serial
being by far the simpler, but much slower). A server application running
on the PC would accept data requests from a client running on the
target, and respond by sending the requested data. You'd need to define
your own protocol, it could be as simple or as complex as you need. Here
is where implementing the syscalls may be useful, for both stdio access
to the serial port and more importantly dynamic memory allocation, which
may be important if you need to allocate buffers for this data

Clifford

Clifford Slocombe wrote:
> mk wrote:
>>  I tried the file functions you specified.But whie linking iam getting
>> errors undefined refernce to _open,_close.
>>
> These functions are among the Newlib syscalls (see section 12 of
> http://sources.redhat.com/newlib/libc.html). These are specific you your
> target hardware and you are expected to implement them yourself.

Newlib comes with default implementations that work with the simulator
exactly as I described above. But I recall now that Martin told me he
has compiled the Newlib for WinARM without the default syscalls because
his build would break otherwise.

Andreas S. wrote:
> Newlib comes with default implementations that work with the simulator
> exactly as I described above. But I recall now that Martin told me he
> has compiled the Newlib for WinARM without the default syscalls because
> his build would break otherwise.

Perhaps it is just me and everyone else knows what the following are;

jm10.1
arm7.i
test.264 bitstream
arm sdt

so that the responses from mk make more sense? I must admit that I am
not entirely clear what he is asking, and perhaps he has assumed that
the terms he is using are common place. As I said, perhaps they are, and
it is just me.

Clifford