Thfifo

a preson is x% more likely to vote for a candidate if they receive a leaflet, y% more likely if they shake the candidate's hand and z% more likely if the candidate kisses their baby. In other words, local campaigning matters, and doubtlessly shapes the national voteshare.

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).

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 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... @_@

While use of these functions is provided it should generally be avoided since it slows down the other CPU, and essentially wastes time while waiting.

getGlobalSWRLock
This function is caled before accessing critical data.

void getGlobalSWRLock(void);

giveGlobalSWRLock
This function is caled after accessing critical data.

void giveGlobalSWRLock(void);

Usage example:

getGlobalSWRLock();   //get exclusive access to SWR for this cpu, and/or wait until other CPU is finished with it
 myIpcData->variable=newvalue;
 myIpcData->othervar=anothervalue;
 giveGlobalSWRLock();  //allow other CPU access to SWR

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. Channel numbers are 0 thru 15.

The channels are named with strings to ease locating on the other CPU. In this way the channel number to use does not need deciding beforehand.

In addition the the ASCII name, 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. To receive data must set a handler function using fifoChanSetFunc(). Additionally fifoChanRecvChk() can be used to determine if a channel has a receive function set on the other CPU or not. In this way it may double as a mechanism to sync user's initialization functions. (need example!) If no receive function is set, data received at buffer is discarded.

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

These are all great tips! One thing I'd like to add is to make sure you elnabe video embedding. This allows viewers to share the video on their own blogs, which increases the amount of viral activity and buzz that the video generates. Very nice list!On a sidenote: what do you think of Vimeo as an up-and-coming YouTube competitor?

ToDo

While this is essentially complete and fully functional some things may be improved:

• fifo32Buf[FIFOMAXCHANS] should be moved into the fifo struct Actually putting this here because at first glance it seems this may be useful, however having it in its own array on each cpu is faster because it does not need to write/read from SWR.
• in the fifo receive function chan&0xf and chan&0xf0 are seen multiple times, would probably be best to create a local variable containing these values already masked off.
• Check if FIFO is full before transmitting data.. This Really should be implemented otherwise data may overflow and become lost. Possibly create a macro that loops while the buffer full flag is set. (added 2009/03/30) It may also be nice to add a feature to create ring buffer to queue up data in the event fifo becomes full and utilize the xmit interrupt to transparently send the queued data in the background. Integrate rng32Lib into thFifo?
• possibly provide a channelized swrLock ?