DeepBlueSky

Edit 09.12.2016: I added Arial_16x24.h and Arial_24x40 (really a 24x36, but I had to keep a multiple of 8), digits only, created with GLCD Font Creator (I had to edit the result slightly manually). See images below. So I can confirm that adding any further fonts created with GLCD Font Creator works (I run it on Linux on wine BTW) and is only limited by how much fits into the



SSD1306_OLED_5x8_11x16_16x24_24x36_fonts.zip

Edit 09.12.2016: I added Arial_16x24.h and Arial_24x40 (really a 24x36, but I had to keep a multiple of 8), digits only, created with GLCD Font Creator (I had to edit the result slightly manually). See images below. So I can confirm that adding any further fonts created with GLCD Font Creator works (I run it on Linux on wine BTW) and is only limited by how much fits into the



SSD1306_OLED_5x8_11x16_16x24_24x36_fonts.zip

Edit 09.12.2016: I added Arial_16x24.h and Arial_24x40 (really a 24x36, but I had to keep a multiple of 8), digits only, created with GLCD Font Creator (I had to edit the result slightly manually). See images below. So I can confirm that adding any further fonts created with GLCD Font Creator works (I run it on Linux on wine BTW) and is only limited by how much fits into the



SSD1306_OLED_5x8_11x16_16x24_24x36_fonts.zip

Edit 09.12.2016: I added Arial_16x24.h and Arial_24x40 (really a 24x36, but I had to keep a multiple of 8), digits only, created with GLCD Font Creator (I had to edit the result slightly manually). See images below. So I can confirm that adding any further fonts created with GLCD Font Creator works (I run it on Linux on wine BTW) and is only limited by how much fits into the



SSD1306_OLED_5x8_11x16_16x24_24x36_fonts.zip

@@DeepBlueSky - I've had success getting an MSP430F5529 to write to an SD card, but it's running on two AA's.  SD cards can take anywhere from 30 to 100mA to drive so yea - not very practical on a limited power budget.  I doubt you could even get it to operate with the internal resistance of a coin cell.
 
I'm actually using external FRAM for that reason on a project at work.  Cypress makes a range of chips from 256kb? up to 2Mbit.  It's expensive compared to SD cards or even flash, but far superior to both for power efficiency and it's also a LOT faster than flash so you can write your data and go back to sleep fast.
 
The internal 64kB of FRAM on the FR5969 can hold a fair bit of data if you're clever about packing it in efficiently, but it's possible we'll offer external flash or FRAM add-on's in the future too.  For now most of the ideas revolve around buffering a certain amount of data internally and then either passing that on over WiFi or BTLE at regular intervals.
 
Regarding the LCD - it is a Sharp LS013B7DH03 128x128 graphic "Memory LCD".  It is part of the same family as the 96x96 display TI sells as a booster pack, but that panel is being discontinued.  The 128x128 display is also MUCH better contrast and as the pixel count would imply - provides more detail.  It already has a working library we've uploaded to our Storm Ninja branch of Energia - it uses most of the guts of the previous 96x96 library, but I've rewritten it to be more power efficient and added some more capabilities like supporting images from TI's image reformer utility (part of their grlib library).
 
We chose these specific LCD's over others because they're such insanely low power.  Try any regular LCD and you'll see it draw anywhere from several hundred uA to a few mA.  We tried using e-ink at first, but compared to the Memory LCD's it's actually a moot point.  I literally cannot measure the current draw of this screen using a 6.5 digit Rigol DM3068 DMM.  It's active spec is 50uA, but when it's idle it must consume almost nothing because it doesn't even register in the nA.  That insane power performance is what we wanted for this platform - you can leave the screen on basically indefinitely and the coin cell would last years.

Nice project. I've heard a msp430g2553 has problems to get a SD card working (to e.g. log data). So this would work with your project then? Any work done for raw LCD support so it/or a certain type kind of works out of the box?

Hi guys.  It's been awhile since we've posted on this project, but progress has been steadily moving on.  We're working with the Rev 3 prototypes at this point and I think we're pretty close to a final product.  Patrick is going to be out at the Bay Area Maker Faire next week showing them off.
 
We're also trying to upload stuff as it's stable to github - a few demo projects and an Android app for bluetooth:
https://github.com/ApparentlyConnected
 
Shurikens (daughterboards) have expanded now to include a sensor board (RGB, accel & temp), a relay board, an AC rectifier board for use with a current clamp in addition to newer revisions of the LCD, Wifi, and BTLE shurikens.
 
What kind of demo projects do you guys think would be best to show off the FRAM and low power capabilities of the MSP430FR5969?  Or what demos would you just like to show how it works?
 
/Nathan

The compensation function works fine Thank you for sharing it.
407387 CPM its non compensated value triggered by several Am-241 pieces placed on SBT-11 mica window, see the photos. The software displays compensated dose rate of 8.00mSv/h with 190uS dead time and 0.0057 conversion fator.

Last updated: May 07, 2015
May 07: added SBM-20 background CPM value vs 1kg potassium salt and python code to log the data.
April 26: added deadtime image.
April 23: updated to 75

I also say one forum for all TI chips instead of "devide and conquier". As some other said, I too didn't even know of some of the other chip forums. Filtering of e.g. msp430 only content would indeed be good. Do the merge if the server can handle it, lagging is annoying for users and more tend to go away then, I hope hosting Energia doesn't slow down the server. Looking forward to Ipboard v4.0 although I personally prefer open source software/forums like phpbb, but there must be a reason why you use Ipboard.

Nice, it compiles after a few changes (<Adafruit_Sensor.h> to "Adafruit_Sensor.h") now, but unfortunately the Serial Monitor doesn't output anything at all. I tried a simple Serial. example but still no output. The MSP430G2553 is on the LaunchPad rev. v1.5 but the following code is not working. I remember the Serial Monitor working with using basically the same Serial code, weird that it is not working now.
void setup() { Serial.begin(9600); } void loop() { Serial.print("Hello"); delay(500); } It seems there are problems with Linux. I'll look at it.

don' bother float.... If the value won't overflow (less than about 650*10^6 decimal), mult by 3 than divide by 100. The mult by three can be done as `(i<<1)+i'. This will give an int value truncated.
 
 
You can avoid the div by 100 completely. After the sprintf, insert a decimal point before the last two digits. This requires that the value is >= 100 decimal, or there won't BE anything before the last two digits. This can be handled by forcing leading zeroes for 3 dig if value is <100 (using a condition and two sprintf's... one for each case)

I take it the built-in sprintf doesn't handle floats?
If want to do it without using floats - could do something like:
unsigned long long count3 = 3 * counts; sprintf(string,"%lu", (unsigned long)(count3/100) ); myScreen.text(0,1,string); add code to print the decimal point in the right position sprintf(string,"%u", (unsigned) (count3 % 100)); print this in the appropriate location That is just the skeleton - would have to fill in the printing code (and conditionals to handle 0 fractional part, etc.)

Ah right, agreed, didn't fully read the first post
 
I think %lu may work too for going up to ~4 billion with unsigned long's.

Use long int (or long unsigned) and use `ld'  (lowercase ell d )instead of `d' in the format string for sprintf. `d' is standart int. `ld' is long int.
 
 
The only info sprintf has about the type is from the format string, so if you spec standard int, whatever the param is, even if it is a long, will be interpreted as a standard int.