ABB semaphore protection overhaul The ABB semaphone protection logic that came with TCS211 from TI was broken in several ways: * Some semaphore-protected functions were called from Application_Initialize() context. NU_Obtain_Semaphore() called with NU_SUSPEND fails with NU_INVALID_SUSPEND in this context, but the return value wasn't checked, and NU_Release_Semaphore() would be called unconditionally at the end. The latter call would increment the semaphore count past 1, making the semaphore no longer binary and thus no longer effective for resource protection. The fix is to check the return value from NU_Obtain_Semaphore() and skip the NU_Release_Semaphore() call if the semaphore wasn't properly obtained. * Some SPI hardware manipulation was being done before entering the semaphore- protected critical section. The fix is to reorder the code: first obtain the semaphore, then do everything else. * In the corner case of L1/DSP recovery, l1_abb_power_on() would call some non-semaphore-protected ABB & SPI init functions. The fix is to skip those calls in the case of recovery. * A few additional corner cases existed, all of which are fixed by making ABB semaphore protection 100% consistent for all ABB functions and code paths. There is still one remaining problem of priority inversion: suppose a low- priority task calls an ABB function, and some medium-priority task just happens to preempt right in the middle of that semaphore-protected ABB operation. Then the high-priority SPI task is locked out for a non-deterministic time until that medium-priority task finishes its work and goes back to sleep. This priority inversion problem remains outstanding for now.

FreeCalypso Luna phone handset UI development platform consists of these 3
components:

* A Caramel-type Calypso motherboard, either iWOW DSK or FC Caramel2
* An LCD carrier board, currently using HaoRan HT020K1QC36S LCD module
* A 5x5 keyswitch matrix board for the keypad function

This Luna is our primary official platform for FreeCalypso phone handset UI
development.  The UI code we got from TI comes in two interesting versions:

* Big color version: 176x220 pixels, 16-bit color
* Small B&W version: originally 84x48 pixels, we are extending it to 96x64 pix

(Originally there was also a third version, large 176x220 pix B&W, but we find
 it uninteresting and we've removed it from our supported set.  It was really
 nothing more than a hack to display a minimal-effort derivative of the original
 small B&W UI on the large D-Sample LCD, so we are not removing anything of any
 real substance here.)

FC Luna hardware is required for anyone who wishes to work on the phone handset
UI project in FC Tourmaline: it is the only target platform that can display
both versions of our work-in-progress UI firmware.  Mot C1xx and other similar
phones have small LCDs that can only display the small B&W version of our
TI-based UI, and in the Mother's opinion working solely on the smallbw version
to the exclusion of the bigcolor version is not acceptable.