Of course in hindsight I am probably stepping on some copyright rules by having this printed, but I don't think anyone's going to complain about that... it's a developer's manual and I am using it for developing with TI parts after all.
I decided "for the hell of it" to print out the MSP430 chip family User's Guide, all 676 pages of it (slau445). Total cost was ~$70 altogether including the $10 binder from Staples. I used bestvaluecopy.com for the printing - printed in B&W, with a thicker color cover sheet, 3-hole drilled, shrink-wrapped, and put it in my own binder.
Reading the more esoteric parts of the book - like the PMM, SVS and CS systems - is actually much nicer in print I found. Just more comfortable to sit down at the table and *look* at the diagrams and text and hold my left hand under the page with the schematic/diagram while reading the details & refer back and forth. Underrated way to consume these documents IMO. I need to get some sticky notes or small sticky tabs (dunno why I didn't think to buy them when I was at Staples) to bookmark the important chapters (eUSCI peripherals, etc).
The BestValueCopy order was $37.31 for the book (676p double-sided), $19.88 for shipping, then the Staples 400-page binder was ~$12 with tax IIRC. For the smaller documents like the per-chip datasheet, I might have them do a comb-binding or similar. Only issue is that shipping cost. So I need to compare that with local services like staples or fedex kinkos..
I may have posted about this a long time ago, but I had written a library to utilize the Nokia 1202 cellphone parts LCDs - there are a couple BoosterPacks we made years ago using this and I have at least 1 working board in my bin of parts.
The library includes "msp430_spi.c", which provides an implementation of SPI for several chips including some of the FRAM chips (FR5969 and FR2433 iirc). As the Nokia 1202 LCD does not break out the D/C line, it requires 9-bit SPI, and the "spi_transfer9()" function is defined for those chips (for all the eUSCI_A0/A1/B0/etc instances). This one is tricky because it requires code written directly for your specific chip, toggling GPIOs between the USCI peripheral mode and standard GPIO mode so the 9th bit can be "simulated" using GPIO, then switched back to SPI mode and the remaining 8 bits transmitted using the traditional 8-bit spi_transfer() function.
The library includes "ste2007.c" for driving the LCD, and a basic font set (font_5x7.h) including the TI logo at character 0x81+0x82 (print those 2 side-by-side in that order).
You have to provide a function for driving the Chip Select line of the LCD, and edit ste2007.c to set your function's name for the STE2007_CHIPSELECT #define.
Under terminal/ and terminal_lite/ you'll find a few implementations of a 16x8 character display, with printf-style display supported along with a cursor - and in the terminal/ subfolder, "msp430_stdio.c" actually implements the TI cl430 compiler's STDIO interface, so you can use the TI optimizing C/C++ compiler's actual printf() and other C stdio functions against this display.
Kicking off my MSP430FR2433 hobby effort I looked into the RTC peripheral, which amounts to a really simple stupid counter, the likes of which I often used WDT for back in the day.
It just counts up to RTCMOD and then fires the ISR.
So without the fancy date tracking that RTC_B did on the Wolverine chips, I had to up the ante a bit and write myself a library to convert "epoch" seconds format (# of seconds since Jan 1 1970 midnight UTC) into a "struct tm" year/month/day/hour/minute/second/etc. structure and vice versa. I looked around for other implementations and found some inspiration from an Arduino/AVR forum, but no real code I found of use.
So I present msprtckit - https://github.com/spirilis/msprtckit
It can provide the RTC_ISR for you (for chips defining __MSP430_HAS_RTC__ like the FR4xxx/2xxx chips), or you can ignore that and implement the counter yourself, then use rtc_interpret() and rtc_epoch() to convert the timestamp into useful formats. It corrects for leap years, and only supports dates starting 1973. (made it easier to begin after the 1st leap year after the start of the epoch)
The use of unsigned long means over 4 billion seconds will elapse before rolling over, so it might have a Y2.1K problem but we'll be long gone by then...
At some point I want to implement timezone interpretation too.
If you use the RTC_ISR that comes with the library, it will manage several things for you-
1. rtcepoch (you need to initialize this yourself somewhere to match current time)
2. rtcalarm0 & rtcalarm1 - epoch timestamps for 2 supported alarms
3. rtcalarm0_incr & rtcalarm1_incr - if > 0, these will tell the ISR to auto-increment the appropriate rtcalarm0 or rtcalarm1 when it triggers so you don't have to re-set the alarms in your code
4. These variables (rtcepoch/rtcalarm*) by default live in .infoA, which is FRAM. You do need to have the DFPW write protection disabled for this to work & to allow the RTC ISR to update them:
// Disable FRAM write protection for .infoA section, but keep enabled for program memory
SYSCFG0 = FRWPPW | PFWP;
5. rtc_status is checked by your code upon wakeup to see if RTC_TICK bitfield is set, RTCALARM_0_TRIGGERED or RTCALARM_1_TRIGGERED.
6. By default the processor will not wake up every time the RTC tick occurs, but you can tell it to do so (rtc_status |= RTC_TICK_DOES_WAKEUP after rtc_init() accomplishes this)
Anyway you can probably guess this is a project I banged out in preparation for doing a clock in the future.