amstan

When I counted there were 81. I guess you have 80 now. heh.
 
How do you limit current on them? Aren't you worried that you get uneven brightness if you just use the pin current limit? At least the anodes should have a resistor for current limit(ideally a transistor as well, if you want higher currents).
 
Also.. a battery like the CR2032 can only give like 5mA, anything more and the voltage should drop.
If the voltage drops too low you might have glitches in the mcu and have problems with the program execution. You could solve that with a big cap.
 
I included the leftover parts for my binary clock. You might be missing a bunch of things(like the smpsu chip). But you should be able to get most of it operational with the bare minimum of parts.
 
You don't really need the smpsu if you don't run on battery and you already have 5V available. You can also bypass that mosfet on the 5V rail; it's completely useless, doesn't do what i wanted.
 
I haven't checked if i gave you a light sensor as well, for that you need a heat gun. Take note of the changes you need to make of the pcb, i had some pins swapped.
 
I also included 20 ws2812 leds for you to populate that board.
 
I also included a bunch of hitachi based lcd modules that I had laying around(i had a box with at least 50).

Would this be of interest?
 
I have a bag of them (80, all pictured). In various stages of pin bending(i don't think any are broken though).
I didn't really have any plan for them, totally forgot I had them for a while there.
 
I'm open to donating them for this group buy. At least part of them(I don't think there's a need for 80, heh). The catch is that they're 3 digits, this board calls for 4 digit displays.

Would this be of interest?
 
I have a bag of them (80, all pictured). In various stages of pin bending(i don't think any are broken though).
I didn't really have any plan for them, totally forgot I had them for a while there.
 
I'm open to donating them for this group buy. At least part of them(I don't think there's a need for 80, heh). The catch is that they're 3 digits, this board calls for 4 digit displays.

@@simpleavr
 
Why don't you jump on IRC to discuss donating arrangements?
 
#43oh on irc.freenode.net

Would this be of interest?
 
I have a bag of them (80, all pictured). In various stages of pin bending(i don't think any are broken though).
I didn't really have any plan for them, totally forgot I had them for a while there.
 
I'm open to donating them for this group buy. At least part of them(I don't think there's a need for 80, heh). The catch is that they're 3 digits, this board calls for 4 digit displays.

Would this be of interest?
 
I have a bag of them (80, all pictured). In various stages of pin bending(i don't think any are broken though).
I didn't really have any plan for them, totally forgot I had them for a while there.
 
I'm open to donating them for this group buy. At least part of them(I don't think there's a need for 80, heh). The catch is that they're 3 digits, this board calls for 4 digit displays.

Yeah, same.
 
I have too many things i don't have a purpose for.

Just got an email about this- http://news.vfd-itron.com/wp-content/plugins/mailpress/mp-includes/action.php?action=view&id=1064&key=79a0418a7e547d1aa215ec106bc40ecf
 
Noritake 12-key captouch pad with soda-lime glass, uses Atmel QTouch technology. I think I'm going to pass on it as I have no need (their VFDs are mainly what I'm interested in).
 
Sent from my Galaxy Note II with Tapatalk 4
 
 

You need to install http://processors.wiki.ti.com/index.php/MSPDS_Open_Source_Package aka tilib. It replaces the uif method in mspdebug. Energia comes with a binary of it.
 
If you don't want to go the energia route, and you have archlinux you can install https://aur.archlinux.org/packages/mspds/. If you're on another distro you could look inside here and run the compiling commands manually.

ld.exe: CC3000FirwareUpdate.cpp.elf section `.rodata' will not fit in region `rom' ld.exe: section .vectors loaded at [0000ff80,0000ffff] overlaps section .rodata loaded at [0000e6b0,00011a29] ld.exe: region `rom' overflowed by 6840 bytes Seems to me that something won't fit. The CC3000 firmware might be too big to be used with the fr board(which only has 16k of code space). I might be wrong though.

This project is an update to the binary clock that I used on my desk. The new version has a lot of new features including RGB leds(WS2812), a bigger microcontroller(The Olimexino-5510 board), capacitive touch and light sensor.
My first idea was to have something based on the MSP430G2553, a couple of WS2812 leds and capacitive touch. But after comparing the work i would have to do, and very few rewards to the Olimexino-5510 functionality I quickly reconsidered. The Olimexino-5510 provides quite a few things I wanted:
MSP430F5510 Battery Charger USB capabilities Arduino Form Factor So all I had to do was make a nice board that went on top with the stuff I wanted for the clock functionality.

WS2812 RGB LEDs
The main feature of the Clock is the 6x3 WS2812 RGB led matrix. These leds contain a little controller that accept a serial protocol for the color data and they handle the PWM. They're also chainable meaning that only one pin(D11, LED-DATA) is required to quite all of them. In my using @@oPossum's library

Power Supply
The Olimexino-5510 has a connector for a battery. But it just connects the battery to the 5V rail, the battery could go as low as 3V. The WS2812 aren't meant to run that low, specifically the Blue led get a lot dimmer. In order to fix this I incorporated a SMPSU that can get 5V from the battery voltage. It could in theory handle as much as 2A. The design was done with TI Webench, all parts are the same as the suggested ones. I had to modify the Olimexino a little to actually give me the raw battery voltage on the shield connector, on battery there's no voltage on the 5V pin, i assumed there was. It all works quite well now except it's kinda whiny.

The WS2812 leds are very bright, so in the darkness this might be a problem. One could dim them by sending them a darker color but this reduces resolution. Q2's purpose is to PWM is the 5V that the LEDs in order to dim them externally. This essentially gives another scaling factor for the brightness. It's a similar principle to how dynamic contrast works in TVs. Unfortunatelly this did not work as I wanted, the mosfet was too slow to PWM the leds fast enough without aliasing. My next design will probably contain a mosfet driver.

Capacitive Touch Pads
I have 4 pads acting as buttons. I originally connected them directly to some pins assuming I had PinOsc hardware like on the value line. Unfortunately I discovered this was not the case too late. I fixed it by adding 2 resistors between each of the pairs. This allows me to do a pretty crappy RC measure. It still works quite good though, i can get about 200 discrete values of the reading. As suggested by TI I had a non solid ground plane of the backside to reduce the intrinsic capacitance.

Light Sensor
The shield also has a light sensor, meant to measure ambient brightness. One can use this to make the display's brightness match the room. The sensor is connected via I2C, since neither the Arduino nor the Olimexino-5510 have I2C exposed on the pins I will have to do a software solution for this. The TCS34725FN sensor is also capable of measuring RGB color; I'm sure something fun can be accomplished using that. Of course I managed to do the footprint wrong for this, so it required some cutting traces to swap some pins; after that it worked just fine.

Eagle Files
I also have the schematics in PDF format.

Code
The current code is mostly made to prove the hardware. It could use a lot more work for the UI.
Features
Clock Functionality with fading SMPSU Off demo Capacitive Touch Demo Light Sensor Demo USB CDC ported from Energia that i used for debugging so far Everything was compiled with msp430-gcc. I uploaded the firmware using the new f5529 launchpad board due to the fact that mspdebug does not support the olimexino usb bootloader.

Parts
Most parts I got from digikey, except the Olimexino-5510, the beefy 6600mAh battery and the WS2812 leds. I got a pretty good price for the LEDs from Alibaba at only 13 cents each.
I ordered the board through Elecrow, I really needed it to be black.

Meta
My old clock was this boring thing with an attiny44, using a matrix of green leds.

I originally started this version(v2.0) as a school project, but I wanted to share it.
Due to the many issues I had I'll probably make a version 2.1(if i fix the shield) or a v3 if I make a standalone board. I'm open to ideas.
I still have quite a few board leftover(about 7), i'm open to sending them to people if postage is cheap/free/easy.
Imgur album for non-users.

You know the drill. Same kind of promotion as http://forum.43oh.com/topic/4358-noritake-graphic-vfd-128x32-free-sample/.
 
Link: http://www.noritake-elec.com/evalkit-sample.php?id=sample
Expires 31 Jan 2014 at 7:00 PM CST.
 
Description from the site:
 

Got mine as well.... was buried in the spam folder
 
Sent from my HTC Aria
 
 

The user manual on the Fuel Tank tool folder has the sensor hub as the datasheet:
http://www.ti.com/tool/BOOSTXL-BATTPACK?DCMP=tivac-battery&HQS=tivac-battery-b
 
Get the usermanual from E-14:
http://www.element14.com/community/docs/DOC-65076?ICID=knode-TIlaunchpad-space

I could, but there are a few problems i though of:
The design I have right now can be battery powered. None of the launchpads have that unless you use the new fuel tank booster pack. Maybe that's an option. I could also integrate the battery charger on my board(same chip from the olimexino). I need 5V for the RGB leds, the original 20-pin launchpad only have low current(less than 100mA) at 3.3V. Even though the original launchpad could probably drive the display just fine, it will have to be a 40 pin booster pack. Perhaps i could add a 5V pin for external powering(maybe from the fuel tank booster pack, if used with the original launchpad). Stuff like this makes me lean more on a standalone board maybe.
 
So far I designed this with not a lot of input from others. It would be nice if I had some feedback:
Do you guys like the smpsu? If removed one could still kinda drive the leds(blue still lights up at 3.3V), but some kind of software would have to compensate for the color(and full white will not be possible anymore). The PWM for the dimmer. I still think this is required, dimming all leds in order to achieve a higher brightness resolution at lower intensities. I order for this to work properly it should be capable of PWMing the 5V rail at at least 100kHz(to avoid aliasing with the built in ws2812 leds). The 5V rail uses 500mA when all leds/channels are on. Is this a worthwhile thing to include, given that i already failed implementing it in v2.0 As i mentioned earlier, one of the reasons I did this project was for a class in school. I attached the report I submitted for that in case anyone wants even more details about it.
PS: Yay, i'm on the frontpage.
tr1-report-withdiagrams.pdf

You know the drill. Same kind of promotion as http://forum.43oh.com/topic/4358-noritake-graphic-vfd-128x32-free-sample/.
 
Link: http://www.noritake-elec.com/evalkit-sample.php?id=sample
Expires 31 Jan 2014 at 7:00 PM CST.
 
Description from the site:
 

Inspiration:
So I'm looking at making a small msp430fr5739 based board. I was thinking that I would be able to use the msp430 launchpad to program them. However, I hit a snag in that they don't seem to recognize the msp430fr5739 as a valid device. I can use my FRAM boards to program them but not the $10 launchpad. Then there was all the hubbub about the new msp430g2955 chips and it got me thinking. Why should I let Texas Instruments determine how I program my chips?

Investigation:
I got to looking at BSL and then got discouraged trying to find a client that works on windows, linux and OSX. It mostly seemed like it was going to be a hassle. Then I got to thinking about just using GDB and its Remote Serial Protocol. If you use msp430-gdb and mspdebug, you use this interface over a local server socket. However, an often unnoticed feature of this protocol is that it can also be used with a regular serial port.

Solution:
I decided to implement a gdb stub server that you load once on your msp430 chip. You can think of it as a bootloader that happpens to use the Remote Serial Protocol. This allows you to load new programs on that chip without the need for a launchpad or an FET. All you need is a usb->serial port dongle. You can find these on ebay from $2-$10. They all go faster than the 9600 baud the virtual serial port the msp430 launchpad provides. It is likely you probably have one of these already. This scheme doesn't allow you to debug using msp430-gdb, but it does provide a way to load new code without having to deal with BSL or having to write any host side code.

How it works:
This version targets the msp430g2553 so that people can easily try it out. I'm guessing that most people don't have an msp430fr5739.  Load the attached code below to an msp430g2553 using your launchpad one time. At this point, you could remove that chip from your launchpad and throw it on a breadboard. You just need power, the caps and a pull up resistor. Then connect TX and RX to a serial to USB converter (ftdi, cp102, pl2303hx, etc..). For simplicity, we can just test with the launchpad itself and ignore the fact that there is an FET on the board and just use /dev/ttyACM0 or COM1: on windows.

At reset time, the code looks at the state of the P1.3 button on the msp430g2553. If you are holding it down, the code starts a gdb bootload/server running on the msp430g2553. On your linux box, just start up msp430-gdb to connect to the chip over a serial port. You can't debug, but what you can do is erase your flash and load a new program. The gdb server code sits at memory 0xfa00 -> 0xfdff so you do lose some of your flash. *I've done some optimization see later posts in this thread *


Loadable hex file:
The gdb_bootloader.hex file from the zip file must be loaded on an msp430g2553. I'll post code and support for other chips at a later date. I'm excited about this concept and wanted to let people try it out.

To load the gdb_stub firmware ( do this one time )
$ mspdebug rf2500 "prog gdb_bootloader.hex" MSPDebug version 0.21 - debugging tool for MSP430 MCUs Copyright (C) 2009-2012 Daniel Beer <dlbeer@gmail.com> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Trying to open interface 1 on 057 rf2500: warning: can't detach kernel driver: No data available Initializing FET... FET protocol version is 30066536 Set Vcc: 3000 mV Configured for Spy-Bi-Wire fet: FET returned error code 4 (Could not find device or device not supported) fet: command C_IDENT1 failed fet: identify failed Trying again... Initializing FET... FET protocol version is 30066536 Set Vcc: 3000 mV Configured for Spy-Bi-Wire Sending reset... Device ID: 0x2553 Code start address: 0xc000 Code size : 16384 byte = 16 kb RAM start address: 0x200 RAM end address: 0x3ff RAM size : 512 byte = 0 kb Device: MSP430G2553/G2403 Number of breakpoints: 2 fet: FET returned NAK warning: device does not support power profiling Chip ID data: 25 53 Erasing... Programming... Writing 970 bytes at fa00... Writing 32 bytes at ffe0... Done, 1002 bytes total OK. Once you have that installed, you no longer need to use your launchpad to load new code. To load programs on your chip now, just connect a usb->serial dongle up to the msp430g2553 directly and connect to that via msp430-gdb. Here are the steps to load a blink program using msp430-gdb via the serial port:
$ msp430-gdb blink.elf GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=msp430". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home2/kimballr/github/msp430_code/fabooh/examples/basic/blink/blink.elf...done. (gdb) set remotebaud 9600 (gdb) target remote /dev/ttyACM0 Remote debugging using /dev/ttyACM0 _reset_vector__ () at ../../../gcc/gcc/config/msp430/crt0.S:103 103 ../../../gcc/gcc/config/msp430/crt0.S: No such file or directory. in ../../../gcc/gcc/config/msp430/crt0.S (gdb) erase Erasing all flash memory complete (gdb) load Loading section .text, size 0x96 lma 0xc000 Loading section .vectors, size 0x20 lma 0xffe0 Start address 0xc000, load size 182 Transfer rate: 264 bytes/sec, 16 bytes/write. (gdb) quit A debugging session is active. Inferior 1 [Remote target] will be killed. Quit anyway? (y or n) y OK, now there are two things on your msp430g2553 chip. At 0xfa00 there is the boot loader, it is run first before your blink.elf code. It checks the button to see if you are holding it down. If not, then it runs the blink.elf code. If you are holding it down, it runs the gdb server instead and allows you to reload code. So just press reset to start the blink. Press and hold the P1.3 switch down and press reset to start the gdb stub server.

Pretty simple huh? I think so.

-rick

The files in the attached zip only work with the msp430g2553 at this time:

[Edit: Updated version 04-07-2013 3:43 PM]


Source Code:
... fast track to how to get started ...

http://forum.43oh.com/topic/3661-1k-serial-gdb-bootloader/?p=33112

I'm actively optimizing this code. I only started on this project on Thursday and posted what I had late Friday. It was 1950 bytes the first pass. But I was so excited about this concept, I just had to share. Saturday, I spent the day on it and got the code size down to less than 1k.

The code is written in C++ using my fabooh framework. I've been trying to find a good app to use as the fabooh debut project. I think this will be it. This type of code needs to be small but needs the flexibility to use various UART implementations. This code personifies what fabooh does well. So expect to see it real soon now, in the fabooh source tree.

You can get yourself in a good position to use this code if you grab fabooh from github.com and take a look at it. https://github.com/RickKimball/msp430_code

@@amstan I should have read more. Anyway.. can you make this for the Launchpad too? I'm not sure if the Olimex-5510 follows the Boosterpack specs. I can help you sell these through the Store.

I guess most of you are the proud owners of Dave's uCurrent [1].
 
I also have one of them and I happily use it. but most of the times I forget to turn it off. needless to say that next day the enclosed CR2032 is flat.
a new revision of that device is soon to be released, however due to physical constraints it will still lack an auto-off feature [2].
 
early this morning I decided to make a small circuit [3] that will be housed in the uCurrent box and that will provide power to it for a given interval. I put together a schematic [4] and a pcb [5] for this.
 
the idea is that the user can leave the uCurrent in the ON position and it will automatically power off either if the output voltage is below a given level for an interval or simply timeout after an interval - this can be reset/tweaked by a button press.
 
my biggest worry is that the analog inputs (P6.0, P6.1 tied to uCurrent's VGND, Vout+) of the msp430f5510 will somehow skew the otherwire precise instrument. Dave's schematic is here [6].
what are your thoughts on this?
 
I am very tempted to simply send the gerbers to manufacture and find out the hard way one month later, but I thought I ask first
 
[1] http://www.eevblog.com/projects/ucurrent/
[2] http://www.eevblog.com/forum/crowd-funded-projects/current-gold-on-kickstarter/msg354450/#msg354450
[3] https://github.com/rodan/ucurrent_ctrl
[4] https://raw.github.com/rodan/ucurrent_ctrl/master/hardware/schematic.png
[5] https://raw.github.com/rodan/ucurrent_ctrl/master/hardware/board.png
[6] http://www.eevblog.com/files/uCurrentRev5schematic.pdf

This project is an update to the binary clock that I used on my desk. The new version has a lot of new features including RGB leds(WS2812), a bigger microcontroller(The Olimexino-5510 board), capacitive touch and light sensor.
My first idea was to have something based on the MSP430G2553, a couple of WS2812 leds and capacitive touch. But after comparing the work i would have to do, and very few rewards to the Olimexino-5510 functionality I quickly reconsidered. The Olimexino-5510 provides quite a few things I wanted:
MSP430F5510 Battery Charger USB capabilities Arduino Form Factor So all I had to do was make a nice board that went on top with the stuff I wanted for the clock functionality.

WS2812 RGB LEDs
The main feature of the Clock is the 6x3 WS2812 RGB led matrix. These leds contain a little controller that accept a serial protocol for the color data and they handle the PWM. They're also chainable meaning that only one pin(D11, LED-DATA) is required to quite all of them. In my using @@oPossum's library

Power Supply
The Olimexino-5510 has a connector for a battery. But it just connects the battery to the 5V rail, the battery could go as low as 3V. The WS2812 aren't meant to run that low, specifically the Blue led get a lot dimmer. In order to fix this I incorporated a SMPSU that can get 5V from the battery voltage. It could in theory handle as much as 2A. The design was done with TI Webench, all parts are the same as the suggested ones. I had to modify the Olimexino a little to actually give me the raw battery voltage on the shield connector, on battery there's no voltage on the 5V pin, i assumed there was. It all works quite well now except it's kinda whiny.

The WS2812 leds are very bright, so in the darkness this might be a problem. One could dim them by sending them a darker color but this reduces resolution. Q2's purpose is to PWM is the 5V that the LEDs in order to dim them externally. This essentially gives another scaling factor for the brightness. It's a similar principle to how dynamic contrast works in TVs. Unfortunatelly this did not work as I wanted, the mosfet was too slow to PWM the leds fast enough without aliasing. My next design will probably contain a mosfet driver.

Capacitive Touch Pads
I have 4 pads acting as buttons. I originally connected them directly to some pins assuming I had PinOsc hardware like on the value line. Unfortunately I discovered this was not the case too late. I fixed it by adding 2 resistors between each of the pairs. This allows me to do a pretty crappy RC measure. It still works quite good though, i can get about 200 discrete values of the reading. As suggested by TI I had a non solid ground plane of the backside to reduce the intrinsic capacitance.

Light Sensor
The shield also has a light sensor, meant to measure ambient brightness. One can use this to make the display's brightness match the room. The sensor is connected via I2C, since neither the Arduino nor the Olimexino-5510 have I2C exposed on the pins I will have to do a software solution for this. The TCS34725FN sensor is also capable of measuring RGB color; I'm sure something fun can be accomplished using that. Of course I managed to do the footprint wrong for this, so it required some cutting traces to swap some pins; after that it worked just fine.

Eagle Files
I also have the schematics in PDF format.

Code
The current code is mostly made to prove the hardware. It could use a lot more work for the UI.
Features
Clock Functionality with fading SMPSU Off demo Capacitive Touch Demo Light Sensor Demo USB CDC ported from Energia that i used for debugging so far Everything was compiled with msp430-gcc. I uploaded the firmware using the new f5529 launchpad board due to the fact that mspdebug does not support the olimexino usb bootloader.

Parts
Most parts I got from digikey, except the Olimexino-5510, the beefy 6600mAh battery and the WS2812 leds. I got a pretty good price for the LEDs from Alibaba at only 13 cents each.
I ordered the board through Elecrow, I really needed it to be black.

Meta
My old clock was this boring thing with an attiny44, using a matrix of green leds.

I originally started this version(v2.0) as a school project, but I wanted to share it.
Due to the many issues I had I'll probably make a version 2.1(if i fix the shield) or a v3 if I make a standalone board. I'm open to ideas.
I still have quite a few board leftover(about 7), i'm open to sending them to people if postage is cheap/free/easy.
Imgur album for non-users.

I added a ton of good pictures.

This project is an update to the binary clock that I used on my desk. The new version has a lot of new features including RGB leds(WS2812), a bigger microcontroller(The Olimexino-5510 board), capacitive touch and light sensor.
My first idea was to have something based on the MSP430G2553, a couple of WS2812 leds and capacitive touch. But after comparing the work i would have to do, and very few rewards to the Olimexino-5510 functionality I quickly reconsidered. The Olimexino-5510 provides quite a few things I wanted:
MSP430F5510 Battery Charger USB capabilities Arduino Form Factor So all I had to do was make a nice board that went on top with the stuff I wanted for the clock functionality.

WS2812 RGB LEDs
The main feature of the Clock is the 6x3 WS2812 RGB led matrix. These leds contain a little controller that accept a serial protocol for the color data and they handle the PWM. They're also chainable meaning that only one pin(D11, LED-DATA) is required to quite all of them. In my using @@oPossum's library

Power Supply
The Olimexino-5510 has a connector for a battery. But it just connects the battery to the 5V rail, the battery could go as low as 3V. The WS2812 aren't meant to run that low, specifically the Blue led get a lot dimmer. In order to fix this I incorporated a SMPSU that can get 5V from the battery voltage. It could in theory handle as much as 2A. The design was done with TI Webench, all parts are the same as the suggested ones. I had to modify the Olimexino a little to actually give me the raw battery voltage on the shield connector, on battery there's no voltage on the 5V pin, i assumed there was. It all works quite well now except it's kinda whiny.

The WS2812 leds are very bright, so in the darkness this might be a problem. One could dim them by sending them a darker color but this reduces resolution. Q2's purpose is to PWM is the 5V that the LEDs in order to dim them externally. This essentially gives another scaling factor for the brightness. It's a similar principle to how dynamic contrast works in TVs. Unfortunatelly this did not work as I wanted, the mosfet was too slow to PWM the leds fast enough without aliasing. My next design will probably contain a mosfet driver.

Capacitive Touch Pads
I have 4 pads acting as buttons. I originally connected them directly to some pins assuming I had PinOsc hardware like on the value line. Unfortunately I discovered this was not the case too late. I fixed it by adding 2 resistors between each of the pairs. This allows me to do a pretty crappy RC measure. It still works quite good though, i can get about 200 discrete values of the reading. As suggested by TI I had a non solid ground plane of the backside to reduce the intrinsic capacitance.

Light Sensor
The shield also has a light sensor, meant to measure ambient brightness. One can use this to make the display's brightness match the room. The sensor is connected via I2C, since neither the Arduino nor the Olimexino-5510 have I2C exposed on the pins I will have to do a software solution for this. The TCS34725FN sensor is also capable of measuring RGB color; I'm sure something fun can be accomplished using that. Of course I managed to do the footprint wrong for this, so it required some cutting traces to swap some pins; after that it worked just fine.

Eagle Files
I also have the schematics in PDF format.

Code
The current code is mostly made to prove the hardware. It could use a lot more work for the UI.
Features
Clock Functionality with fading SMPSU Off demo Capacitive Touch Demo Light Sensor Demo USB CDC ported from Energia that i used for debugging so far Everything was compiled with msp430-gcc. I uploaded the firmware using the new f5529 launchpad board due to the fact that mspdebug does not support the olimexino usb bootloader.

Parts
Most parts I got from digikey, except the Olimexino-5510, the beefy 6600mAh battery and the WS2812 leds. I got a pretty good price for the LEDs from Alibaba at only 13 cents each.
I ordered the board through Elecrow, I really needed it to be black.

Meta
My old clock was this boring thing with an attiny44, using a matrix of green leds.

I originally started this version(v2.0) as a school project, but I wanted to share it.
Due to the many issues I had I'll probably make a version 2.1(if i fix the shield) or a v3 if I make a standalone board. I'm open to ideas.
I still have quite a few board leftover(about 7), i'm open to sending them to people if postage is cheap/free/easy.
Imgur album for non-users.

Totally what it was!
I am very grateful!
 
All my pins work properly now!

Hi @@amstan,
 
I think I know what might be your problem.
 
In the FR5969 user's guide section 8.3.1 on p. 310, it mentions that on this device, all port pins are not only Hi-Z at startup, but that the pin initialization that you do does not take effect until you clear the LOCKLPM5 bit in the PM5CTL register. This is different than most other MSP430s, so it's an easy step to miss.
 
If you check the latest TI code examples for this device, this line has been added after GPIO initialization:
  PM5CTL0 &= ~LOCKLPM5;           // Disable the GPIO power-on default high-impedance mode                                   // to activate previously configured port settings Regards,
Katie

There's ubuntu packages available. You might still have to compile some things from source(ex: the mspdebug from there can't do fr boards yet).