Honored Contributor
Honored ContributorMy personal view is that for an embedded system there is little point abstacting access to hardware through either stdio or posix files (ie starting with fopen() or open()). All that does is add extra layers and slow things down.
Much better is to just define a set of API calls directly into the 'driver' itself that are optimised for the task in hand. In some cases the operations might be defined as inline functions of# defines for performance reasons. At the lowest level you will need to use uncached bus cycles that access the actual hardware. These can be requested with the IOWR (etc) defines, but it is much more common (look at any unix device driver) to define a structure to map device registers than to use constants for the offsets. The guys who did the gcc port for nios2 should have seriously considered adding an 'attribute' to memory items that would have caused ldio/stio instructions be generated for them. From the fixes I did to the gcc port I don't think it would have been difficult.
