DeepBlueSky
-
Content Count
26 -
Joined
-
Last visited
-
Days Won
2
Posts posted by DeepBlueSky
-
-
Hi,
Yes I tried this particular one (it is for SPI and I do not know how to change it to work with I2C) and many other ones, including the Adafruit, U8g2, etc.
Check this out
http://forum.43oh.com/topic/10061-msp430g2553-ssd1306-oled-i2c-11x16-font/ -
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
- rainbowtable, Fmilburn, Rei Vilo and 1 other
-
4
-
Thanks for suggesting an SD alternative. If the alternative has a much lower power consumption (or should I say the SD has too much) and doesn't have the same problems SDs have, and offers other superiorities, then I'm ok with a higher price.
Something external to which the chip writes/logs data to, which later can be transferred to PC, would be very nice (logging data so something which can be later put on PC for further processing is kind of essential).
The reason I thought about raw LCDs first is that they can have big digits, are relatively power efficient and have relatively good contrast. But if you say that the contrast of the Memory LCDs is comparable (or better?), and of course the impressive low power consumption you mentioned (I would have guessed 10x that much consumption), then a bigger version of the Memory LCD would be an alternative. The higher resolution not to forget.
When will this be available
-
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?
-
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.
Thanks
I'm not sure but I think compensating 407387 CPM with 190
-
Hello,
I bought a Sparkfun ML8511 UV sensor breakout and set it up according to this.
It kind of works / I have a weird problem: No matter the voltage (3V or 3.3V), the sensor output values change periodically very strongly:
- Closer to UV-AB source: ~1.5 to ~10.5 to ~1.5 and so on (with more steps in between) (distance of course doesn't change).
- More away from the UV source: ~0.2 to ~1.5 to ~0.2 and so on.
When I attach a 1.5V battery constant voltage source as a test, the displayed value is indeed rather constant ranging from 4.39 to 4.59, so it must be the sensor's problem?
Google-ing this problem didn't reveal any results.
I tried using A0 and (A1-A5) because of possible noise? but this unfortunately didn't help.
I'm using a MSP430G2553 and its ADC10, on a breadboard. Is this a known problem of such a setup?
-
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.
-
Thanks, I'll try it out. At the moment it didn't work maybe because I did already so many things from tutorials (of which nothing worked) and I was planing to do a fresh OS install anyway (Ubuntu 14.10 64bit), then I'll try again. If it won't work, that's not so bad in my case because I want a portable Lux meter anyway and will use a Nokia 5110 LCD.
*edit*
After a fresh OS install and unpacking the original archive energia-0101E0014, it unfortunately doesn't work (weird, I remember it working without doing anything). Anyway I'll connect the Nokia LCD and try reading the sensor now.
*edit*
Got it working with the LCD I was able to measure up to a constant value of ~120000 Lux (although it goes "up to 88,000 Lux") using a Cree XM-L LED in a C8 Flashlight case, but if it got even brighter (doesn't make sense anyway because in nature 100k Lux are about the highest), the value decreased. So I guess reliable are "up to 88,000 Lux" or 120k Lux if this value is correct, which is very nice because such Lux meter can cost quite something and are not even open source.Can't attach the sources, it says " You can upload up to 197.98MB of files (Max. single file size: 175bytes)". I'll try again later.
*edit*
Now attaching is working again.
-
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.
-
Hello,
I bought an Adafruit TSL2591* shield but unfortunately it looks like there's no lib for MSP430s. There's code for Arduino and some posts about the TSL2561. Unfortunately I don't have any experience with I2C and hope/wonder if someone is interested to get it running on the MSP430s? That's a really nice sensor.
* :
High Dynamic Range Digital Light SensorWhen the future is dazzlingly-bright, this ultra-high-range luminosity sensor will help you measure it. The TSL2591 luminosity sensor is an advanced digital light sensor, ideal for use in a wide range of light situations. Compared to low cost CdS cells, this sensor is more precise, allowing for exact lux calculations and can be configured for different gain/timing ranges to detect light ranges from 188 uLux up to 88,000 Lux on the fly.
The best part of this sensor is that it contains both infrared and full spectrum diodes! That means you can separately measure infrared, full-spectrum or human-visible light. Most sensors can only detect one or the other, which does not accurately represent what human eyes see (since we cannot perceive the IR light that is detected by most photo diodes) This sensor is much like the TSL2561 but with a wider range (and the interface code is different). This sensor has a massive 600,000,000:1 dynamic range! Unlike the TSL2561 you cannot change the I2C address, so keep that in mind.
The built in ADC means you can use this with any microcontroller, even if it doesn't have analog inputs. The current draw is extremely low, so its great for low power data-logging systems. about 0.4mA when actively sensing, and less than 5 uA when in power-down mode. -
Nagios is indeed a good suggestion. "out of memory" could mean a memory leak (as also suggested by roadrunner84), make sure you have at least the latest supported version of each software. I'm not sure if it's normal to buy more memory just because you get this error once a week or so, because it looks more like a bug/memleak. A forum/DB may run slower with less memory but a they shouldn't stop running altogether.
-
Had another look, and I'm almost certain that the serial debug code in the library is the source of your frustrations. You are using P1_2 for your sensor, which is the TX pin for the 2452's timerserial library. I'd say that what's happening is the serial code in the debug is sending data on P1_2, which is messing up the DHT22. The reason you need the 1 second delay in LPM3, is to give the timerserial library time to clear the serial queue.
I'm not sure / I don't think so: Before I decided to ask I already commented out the debug code because it gave me a compile error right away "multiple definition of `__isr_9'". Using different ports also works (DHTPIN P1_3, LED P1_2) when millis() (see below) is commented out.
grahamf72, you indeed solved it for yourself
As already said your code doesn't work for me. However, when I comment outif (millis() < _lastMillis) { return _lastResult; // return last correct measurement } _lastMillis = millis() + 1;in DHT22_430.cpp it seems to work
It looks like the millis() can't run in LPM2 / LMP3.I also commented out "delay(250);" and changed "delay(20);" to "delay(10);" to reduce unnecessary power consuming cycles.
And what also works now is the code pattern suggested by roadrunner84.
I think the problem is hereby solved
First post edited.Can this be moved back to projects?
-
I tried your code and also switched to your ports but it's the same without adding delay: LED does not blink if I breathe at the sensor. ("#define DEBUG" is commented out too).
The sensor gets its data when restarting the chip but doesn't get its data when it's running/waking up when in LPM3 and without delay(1000). Maybe you should test again.
What seems to work is when I comment out
if (millis() < _lastMillis) { return _lastResult; // return last correct measurement } _lastMillis = millis() + 1;Because in my case I do a "millis()"/waiting by entering the interrupt routine every 10s.
-
Touching the sensor it seems rather cold, no warming.
The thing is it needs this delay(1000) only in LPM3, not LPM1. Maybe clock related? In LPM3 SMCLK is, as roadrunner84 also mentioned, turned off, but I don't know. It's strange. LPM2 BTW is same as LPM3.
From msp430g2452.pdf:
-
I edited the cpp file and commented out the #if defined(DEBUG)...#endif, as I was indeed having problems compiling the code, which I should have mentioned, sorry.
-
I tried your version again and it compiles with __bic_status_register_on_exit, but has the same problem as mentioned earlier.
Yes, it does work in LPM1, no delay(1000) needed (it's the version in my first post). But when using LPM3 it only works with delay(1000) (as in my post #5). Without the delay in LPM3 I can wait as long as I want, the sensor still doesn't return any valid value.
-
Yes, that's why it is set to every 3 seconds. The delay(100)s come after this time has passed. But there's a problem which I tracked down:
Using e.g. TACCR0 = 12000 and the if(wakeupCounter % frequency == 0) and setting any frequency doesn't work at all, even 10s.
What also doesn't work at all is setting TACCR0 = 60000 and removing the if(...), so it only checks every 5s (which should be more than enough). By "at all" I mean that the sensor just doesn't return a valid value.
It seems that the sensor needs a busy wait of approx 1 second (it's like only this delay(1000) starts the time of the sensor, which is, as already mentioned, "every second or two", which is no problem for me, I don't need a super fast sensor) which of course defies the purpose of sleep.
So although this works, it is not a solution (edited my prior reply code too so it is more correct):
void loop() { _BIS_SR(LPM3_bits); } ... delay(1000); flag = mySensor.get(); h = mySensor.humidityX10(); //t = mySensor.temperatureX10(); if (flag) {Any suggestions?
-
Your code gave this error:
error: '__bic_status_register_in_exit' was not declared in this scopeIn the msp430g2452.h header file I found
... #define LPM3 _BIS_SR(LPM3_bits) /* Enter Low Power Mode 3 */ #define LPM3_EXIT _BIC_SR_IRQ(LPM3_bits) /* Exit Low Power Mode 3 */ ...
and replaced the line with LPM3_EXIT. Is this the same as your line?
It compiles but unfortunately does not improve power consumption (700
-
I decided to build an air humidity alarm so I know when to air (you can also attach a piezo buzzer, which is more recognizable in some situations). I found/use this lib.
Chip: MSP430G2452 (this I had left, I think it's overkill for this task)
--
Problem solved.
Thanks to all who helped.
To solve the problem I decided to comment out
if (millis() < _lastMillis) { return _lastResult; // return last correct measurement } _lastMillis = millis() + 1;in DHT22_430.cpp because I think the millis() doesn't run below LPM1. I also don't need the millis() because I already wait in interrupts (3-10 seconds, enough for this sensor which needs at least 1-2 seconds time).
I also commented out "delay(250);" and changed "delay(20);" to "delay(10);" to reduce unnecessary power consuming cycles. Tested and works.
BTW: don't forget to comment out "#define DEBUG" in DHT22_430.h (but it will give you a compile error anyway when using timer ("multiple definition of `__isr_9'")).
That's it, no further changes (if I would have made many small changes to the lib, I'd have attached the two lib files in an archive file).
--
Power consumption:
- In LPM3: 10
- In LPM3: 10
-
Updated first post with proper function now and added images, enjoy
-
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.
Thanks, you are right, it goes up to 2^32 ? 1, whereas ld doesn't.
void loop() { counts=4294967296-1; sprintf(string,"%ld",counts); myScreen.text(0,0,string); sprintf(string,"%lu",counts); myScreen.text(0,1,string); delay(100000); } -
Isn't there a "%u" option to tell sprintf/printf/etc. to interpret it as unsigned?
If I try %u it only goes up to 2^16, if I use %ld it goes up to 10 digits or so, so much better.
-
Thanks, this helped to solve first of the two problems
-
Changing to "unsigned int counts;" doesn't help.
MSP430G2553 + SSD1306 OLED (I2C) + 5x8, 11x16, 16x24 and 24x36 fonts
in Projects
Posted
I didn't try attaching any further I2C devices. I suggest you open a new topic for your problem. The solution will surely be helpful to others too.
Yes, you can delete the unneeded entries from the smaller fonts (the bigger fonts only have number already because they won't fit into this IC), but see the code for the bigger fonts and adjust it (basically change to s.charAt(j)-'0').