Thfifo

From ProjectWiki
(Difference between revisions)
Jump to: navigation, search
(FIFO)
Line 2: Line 2:
 
A novel approach to inter-processor communications and related resource management for the Nintendo DS. Based on the concepts of simplicity, ease of use, modularity, and run-time resource allocation.  
 
A novel approach to inter-processor communications and related resource management for the Nintendo DS. Based on the concepts of simplicity, ease of use, modularity, and run-time resource allocation.  
  
In addition to the usual FIFO functionality, functions for managing the 4K shared memory space (swrmalloc/swrfree) are also provided.  
+
In addition to the usual FIFO functionality, functions for managing the 4K shared memory space (swrmalloc/swrfree), and rudimentary inter-processor mutual exclusion functions are also provided.  
  
 
==Shared Work Ram Management==
 
==Shared Work Ram Management==
Line 34: Line 34:
 
bool swrfree(void *loc);
 
bool swrfree(void *loc);
 
</source>
 
</source>
 +
 +
 +
==Inter-processor Mutual Exclusion==
 +
Two functions, void getGlobalSWRLock(void) and void giveGlobalSWRLock(void) are available to restrict access during critical read/writes to swr. For this the well documented Peterson algorithm is used.
 +
 +
These functions were originally conceived to prevent corruption during swrmalloc but may be useful to developers as well. Still debating if the FIFO section itself shouldnt provide per channel locks... @_@
  
 
==FIFO==
 
==FIFO==

Revision as of 23:22, 11 August 2008

Contents

What is this?

A novel approach to inter-processor communications and related resource management for the Nintendo DS. Based on the concepts of simplicity, ease of use, modularity, and run-time resource allocation.

In addition to the usual FIFO functionality, functions for managing the 4K shared memory space (swrmalloc/swrfree), and rudimentary inter-processor mutual exclusion functions are also provided.

Shared Work Ram Management

Functions detailed here are for managing the 4K shared work ram (swr) segment. This segment is uncached on the arm9 side and therefore slower so should only be used for variables and structures that routinely need to be immediately available to both CPUs.

Traditionally this area was managed at compile time using complex #define statements requiring careful planning to prevent two libraries reusing the same region twice. To avoid these potential pitfalls a simple dynamic runtime allocation system is provided so that libraries may request swr space with minimal concern.

These functions may be called from either CPU, and you should be able to malloc on one side and free on the other! (however this is discouraged).

ToDo:

  • the malloc/free functions should be recoded so that they use less space and store the malloc structures directly in swr. The functions are currently just modified version of vram malloc... >_>

SWR Functions

swrInit Initialize the swr functionality, called on both CPUs before using. Calling this function is unnecessary if using the FIFO because its called already in fifoInit().

void swrInit(void);

swrmalloc Allocate a region of swr. Only argument is the size requested. Returns a pointer to the newly allocated region or null if fail.

void *swrmalloc(int size);

swrfree Frees up a previously allocated region of swr. Only argument is the previously allocated swr pointer. returns true if successful.

Do not see this being used very often if at all, but it is provided for completeness.

bool swrfree(void *loc);


Inter-processor Mutual Exclusion

Two functions, void getGlobalSWRLock(void) and void giveGlobalSWRLock(void) are available to restrict access during critical read/writes to swr. For this the well documented Peterson algorithm is used.

These functions were originally conceived to prevent corruption during swrmalloc but may be useful to developers as well. Still debating if the FIFO section itself shouldnt provide per channel locks... @_@

FIFO

The design philosophy here is based on simplicity and modularity. It is essentially a channelized version of the hardware rather than an attempt to provide facilities for every possible need.

Each channel is assigned an ASCII name so that it may be easily identified by the other CPU, and an optional pointer to user data to be shared between CPUs (most likely allocated with swrmalloc :P). Each CPU expecting to receiving data is required to assign a handler function.

Up to 24 bits of data may be transfered at a time, the format of this data is left up to the developer.

FIFO Functions

fifoInit

void fifoInit(void);

fifoChanCreate

thfifo_t fifoChanCreate(const char *name, void *udata);

fifoChanSetFunc

bool fifoChanSetFunc(thfifo_t chan, _pHFifoFunc func);
typedef void(*_pHFifoFunc)(s8 chan, u32 data, void *udata);	//callback

fifoSendChan24

void fifoSendChan24(thfifo_t chan, u32 data);

fifoFindChan

thfifo_t fifoFindChan(const char *name);

fifoChanRecvChk

bool fifoChanRecvChk(thfifo_t chan);

fifoGetUData

void *fifoGetUData(thfifo_t chan);
Personal tools
irssi scripts
eggdrop scripts