Reading from physical addresses..

[fernando ruiz.com]

> -----Mensaje original-----
> De: Till Straumann [mailto:strauman at slac.stanford.edu]
> Enviado el: viernes, 02 de mayo de 2003 16:57
> Para: Fernando RUIZ
> >>

> >>
> >>Hi there,
> >> I need to read from a range of physical addresses (for
> >>ex. 0x000-0x1000) from an application in RTEMS. When I say that,
these
> are
> >>the actual locations on the physical memory and not on the process
> address
> >>space.
> >>
> >>What is the best way to do it?
> >>
> >>Is it possible to do it from an application?
> >>
> >>
> >>
> >
> >Hi,
> >  My experience is that you are free to build a C pointer in order to
> read/write the I/O memory
> >mapped space.
> >
> >unsigned short char * pb = (unsigned short char *) 0x008000;
> >
> >*pb=15  by example.
> >
> NO, that's a bad idea. Doing I/O this way breaks e.g. when you switch
to
> a CPU of different endianness.
> There might be other CPU specific issues. Your approach makes porting
a
> driver difficult because it's
> hard to find the places where I/O is done. Use specific macros or
inline
> functions for IO (plus, you
> should declare the IO address a 'volatile' variable). RTEMS (at least
on
> some architectures) has
> libcpu/io.h which can/should be used.
> 
> -- Till
> 
Maybe poor but not Bad.
At the BSP specific driver code you need build a solid, optimized and
easily tested code. If your driver is in your application layer code you
don't need all of these constraints necessary at RTEMS kernel portable
layer.
What is the goal? Build a BSP driver that encapsulates all the internals
at the RTEMS kernel layer?
Can you think a very loaded real-time code driver calling all the IO
macros and IO functions in lieu of direct C pointer to obtain the same
goal?
What is the way to build a flash memory driver optimized without
pointers?

At linking file map memory you hide at RTEMS the flash memory address.
You can add a label with the memory flash address start and size.
Your driver code takes the external label and works directly with an
encapsulated memory area but addressable with 'C' pointers or better
external variables.

After in rtems application layer you have open(), read(), ioctl() and
all the standard functions.


It's very difficult for me writing a driver code twice long as necessary
and wasting the time executing a non optimized code in order to give
more portability at the driver source code level.

If I think in the driver optimized code I think directly in the
Assembler Code listing and the stupid assembler code lines added to give
portability.

You are right with 'volatile'. It's my fault, sorry.

Best Regards