Flash too limited to allow OLED & SDCard about cosmicwatch-desktop-muon-detector-v2 HOT 18 OPEN

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.

I currently trying to get the program to work with a smaller library for the oled displays. The library can be found here: https://github.com/greiman/SSD1306Ascii
The compiled sketch with the sd library and this library uses around 57% of the global RAM and 93% of the program memory. This is with the default arduino nano bootloader.
As for RAM, I have heard that using char arrays instead of the String library makes ram usage more predictable and stable as ram is not dynamically allocated.
My attempts can be found here: https://github.com/jgOhYeah/NonOfficial-StuffForCosmicWatchMuonDetectors

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.

I just checked one of the files logged to the sd card and the dead time is around 43% of the total time after 25 hours running. Might have to speed it up slightly somehow. I am investigating other libraries which may be a compromise between the two.
I have measured the standard oled version of the software to have a dead time of around 4% and the sd card only version with an sd card inserted to be around 0.3%
This might be one of the reasons why the detector I built does not always seem to be behaving properly :)

from cosmicwatch-desktop-muon-detector-v2.

Considering you can pack all the code into a single sketch, you could take some unused I/O pins and a switch and let the operator decide what he wants to run in software; Serial / OLED & Serial / SD & Serial / OLED & SD & Serial. This way you don't need to upload three different sets of code and the user can determine what kind of performance vs features he wants.

from cosmicwatch-desktop-muon-detector-v2.

I have swapped to the u8x8 library for driving the display, which is a part of the u8g2 library and is text only. It seems to be fairly fast and not use that much memory. For those interested I have attached a spreadsheet of tests I have done comparing a few libraries. The results seem to match up with Michael's measurements for dead time differences between the libraries.
SSD1306Libraries.xlsx
Dead time seams to be around 5% of the total time now with both the screen on, logging to serial and the sd card.
Here it is: https://github.com/jgOhYeah/NonOfficial-StuffForCosmicWatchMuonDetectors

By the way, the reason why I measured 40% dead time for the SSD1306ascii library was probably because I put a bracket in the wrong place and it was probably trying to do adc readings on the wrong pin. :)

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.

I just wanted to provide an update. I managed to get both OLED and SDcard functions working within the same software set. I had to swap out the adafruit library for the SSD1306Ascii library, make a few modifications to the display calls and cludge-in the existing SD card functions. My code is not pretty, but works as a proof of concept.

It uses 97% of the program memory and 65% of the dynamic memory. Not much more could be squeezed out. Feel free to use my proof of concept code however you would like. I'm just happy helping out the project.

Cosmic_Watch_V2_Comb_Simp_Disp.zip

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.

Sounds good. I should mention upon the first upload you may have some garbage displayed on the OLED that will persist until all power is removed. It has something to do with the OLED not liking seeing the libraries swapped out.

from cosmicwatch-desktop-muon-detector-v2.

Hello, Good job on modifying the code and getting it to work.
I eventually gave up on the library for this job myself because I thought it was just too slow, but obviously not :).

I also wrote a version that has been running on my physics teacher's detectors for a few months, but I forgot to upload the latest version until now. Sorry for the slight delay.
It should be here https://github.com/jgOhYeah/NonOfficial-StuffForCosmicWatchMuonDetectors.

I used the u8x8 library, which is much more limited in terms of fonts and font sizes, but is fast and does not use much memory, as well as being versatile enough to make something readable. If it is possibly to use a slightly nicer looking, low memory, high speed library, that is good to know :).

Last time I checked, the dead time for this code with display and sd card was about 8%. I am not sure if this good enough, but it seems to work. This code uses 91% of the program memory and 65% of the ram, so it seems that no matter the libraries or code used, it is always going to be tight squeezing in and sd card and display.

There was somehow enough room left that I managed to put in a module that can burn the detector's name and a few other settings into the EEPROM without having to upload a different piece of code to it.

I have read that with the ram in arduinos, it is often better to use char arrays instead of the String class as the String class can waste memory, eventually running out and causing the arduino to crash. I found an interesting article on it here. Maybe with stuff like this in mind it would be possible to successfully go above the 70% dynamic memory suggested limit if needed?

from cosmicwatch-desktop-muon-detector-v2.

Hello jgOhYeah,

Your code is so pretty, polished, and well commented. Mine was just a kludge to see if the concept would work. I'm pretty sure I broke all of the external tools as my print statements / orders differ from what the external tool expects, but nothing that couldn't be fixed.

SSD1306Ascii library is pretty good as it's written to be very low memory and they have a number of fonts to choose from. The arial14 font I chose is pretty nice looking and has the same character sizing as the adafruit library.

With regards to string and ram, I saw a similar article that discussed how the arduino compiler will allocate ram for any strings because it operated under the notion that they may be dynamically manipulated elsewhere in the code. This can be very wasteful if your using a bunch of static strings, like we do here. I like how you used char arrays to keep the ram usage down, but there's actually a built in function in the arduino IDE that can help with a little less effort. It's a function call F(). By defining your string inside this wrapper function, the string will get statically allocated in program memory and not ram. That's how I kept my ram usage down. You can even use it with normal string operations for example Serial.println( F("Your string here") + F("Your other string") + somenumber );

It would be interesting to see if how the char array method and the F() compare against each other with regards to ram and cpu usage.

from cosmicwatch-desktop-muon-detector-v2.

Semi-organised code and extra features are mainly a result of trying to avoid homework :) Although it often starts out with comments and nicely layed out, it often ends up very messy with very out of date comments making little sense :) The notes are also because I have been known to leave projects for a few years or so and completely forget what I was doing when I came back to them and have to start from scratch.

I have not done any tests speed wise, but I would have it a guess that the F() macro is doing something similar to the strcpy_P in the background in that it copies strings saved into flash into char arrays, but does it automatically. Probably the fastest is the Serial.println("text") without anything to save memory as the string is already in ram.

In another project I have been using the F() macro and it makes it much easier to follow, however in this code I wanted to write identical strings to up to 3 separate things (serial, display and sd card) using the least amount of memory possible.

I ran a small test comparing memory usage of different ways of saving and then printing a string out twice and found that the F() macro saves the string into flash memory twice, even if both strings are identical. This surprises me, because I would have thought the compiler would optimise this, but evidently not.

By using strcpy_P, the string can be saved into flash and then only copied into a char array only when required, allowing a string to be used multiple times if required, although it is very manual to set up. It does also allow char arrays to be manually manipulated and reused, as well as a scratchpad for processing hopefully without having to allocate more memory.

Once I started with this system, I decided to keep going with it as to have all UI text on the one file, even if strings are only used once for consistency. Not sure if this is the best way to do it, but that's what I did.

StringMemTest.zip.

As for the compatibility with the existing python scripts programs, that only happened much later in the version I did and as of now I still have not got round to implementing the reading and deleting files from the sd card bit. A work in progress :)

from cosmicwatch-desktop-muon-detector-v2.

A slight update to my version of the code:

I only recently noticed that in February 2019 there was an update (v2.25.10) to the U8x8 library that claims it should be around 4% faster (see near the bottom here). I have not tested this in this application, however I was playing around with drawing images on the screens and ended up with a graphical bar graph and scale instead of the hyphen one. It ranges from 0 to 180mV and each division should be around 20mV (off by a bit due to rounding to fit inside 120px wide).

Interestingly, early testing suggested that loading the top image background from flash into ram, overlaying the bar on top of it at the right length and then displaying it somehow takes around 1/3 the time it does for my adaptation of the hyphenated version. Not really sure why as I thought that the hyphenated version would have been more efficient, might be something to do with how the library handles characters in the background?

On the other hand all of these do not seem to have major effects (fractions of a % only) with dead times of:

• 4.6% old (v2.2) for 24 hours in slave mode with a rate of 0.121c/s (not 100% sure which version of U8x8, probably pre v2.25.10)
• 4.1% new (v2.3.2) for around 17.5 hours in slave mode with a rate of 0.138c/s (U8x8 v2.26.14)

I have updated the non-official repository with the latest version.
Good luck with your muon detecting :)

from cosmicwatch-desktop-muon-detector-v2.

from cosmicwatch-desktop-muon-detector-v2.