Using Strings - pitfalls and traps for long term 24/7/365 project

Hi. I'm wondering if anyone can advise please.

I normally avoid using strings but now it/they would make life a lot easier in a new project.
The device must stay running indefinitely as a data logger, no on off switch, no reset button. It is to collect data from a BLE module, store it in some I2C eeproms then when able send if via a WiFi module to a server on the internet.
I've settled on the Teensy-LC for now - power consumption is critical, but may have to upgrade to the Teensy-3.2 if code size becomes an issue etc.
The WiFi module is the ESP12S. It seems "reasonably reliable" (not had a problem with simple connect/disconnect over a few days but always paranoid about reliability) so far and I'm happy to reset it if there is an issue. It does not have to send data in real time. Since the logger is person carried, it won't be in WiFi range very often anyway and it is guaranteed to fail when signal strength is marginal etc. It will only bring up the module occasionally anyway (they sure are power hungry).
The BLE Module us the USR-IOT BLE-100.

My question is, is using Strings and supporting functions a "good idea" for a long term operation project. I've read how garbage collection and such can cause problems. Admittedly that was some time ago and with the conventional old ATMega based Arduinos. Some people seem to hate strings.
Using strings would make reading and deciding messages a lot easier but if there is a reliability issue, I'll ditch them and work it myself. It's just that I'd like to make that decision now instead of later down the track and ideally use other peoples experience as a guideline.

Thanks for any ideas or feedback - Richard

Avoiding Strings is generally better AFAIK - especially for long term running. They should work as expected and be reliable on Teensy.

With an ESP- that could handle lots of data as well. Is that being set up for Arduino programming?

Thanks for the feedback. Feeling I get from you is that in Teensy with bigger memory they should work ok. Maybe declaring static and not creating/destroying all the time would be a help too.

No - using the ESP via the AT command set. Do not want to use that for processing the data as it consumes a lot of power. Teensy-LC is far better AFAIK.

Yes, staying in the Arduino environment. I've had the framework for the project running for a few months without fault in the Teensy-LC. It has been remarkably reliable. It must accept a BLE string, strip it apart, store into I2C, read a real time clock, store that into I2C, do some pretty simple timing. No big deal. Works extremely well.

Ta - Richard

Indeed the ESP for WiFi is power hungry. Never used it with AT commands - I had mine under powered during setup and went from AT to NODE to Arduino attempts until I fixed breadboard power - then it worked and it was nice that it was common IDE to Teensy. But it has the onboard SPIFFS area if a 4 MB unit - you might have 3 MB of storage area.

The T_LC is much better power wise - for lowest power look into Snooze Library if constant activity isn't needed and a low power mode can be used.

Teensy should be reliable. And Strings on Teensy have been made and seen to work well from what I saw posted - just need to not confound it with fragments. Perhaps pre-allocating large enough fixed lengths and then safely re-using them in place if the size and number of needed strings is known in advance it should be no problem.

vk3txd said:

My question is, is using Strings and supporting functions a "good idea" for a long term operation project. I've read how garbage collection and such can cause problems. Admittedly that was some time ago and with the conventional old ATMega based Arduinos. Some people seem to hate strings.
Using strings would make reading and deciding messages a lot easier but if there is a reliability issue, I'll ditch them and work it myself.

Click to expand...

If strings would make your life easier, then by all means use them.

If you want something that runs reliably for a long time, just don't do any dynamic memory allocation, either implicit or explicit aside from what's absolutely needed.

Explicit is malloc/calloc/etc., and they should be relatively easy to avoid. Implicit can be a stack frame (very hard to avoid) and probably some allocated by certain string functions. The functions may be easy to use and nice to have, but there is usually a way around them.

I finished a sizable project a little while ago -- quite a few strings, though mostly for efficiency reasons, I don't think I've used any string function not written by me.

Strings will make swiss holes in your heap, and are generally frowned upon. They will work better on teensy than other arduinos due to ram size yes, however, eventually youll reach that fragment point and kapow! character arrays are your friend, and their functions, even though some can take more ram than necessary, dont end up slowly dragging your project to a crippled state, depending on how you use them and how you handle your NULL point. Some of the ESP functions return Strings, but I havnt stumbled upon their functions building one. They usually cast the return as a String and it destructs on function scope exit. This I dont think is bad, you basically create a non fragmented String buffer and discards it instead of allocating space for additional characters you add to it when building.

Thanks tonton81, floating and defragster. I wasn't going to use malloc/etc so that's fine. The problem I anticipated tonton81 pointed out was 'swiss holes' possibly as a result of temporary strings created by string functions (rough guess). floating your point about avoiding and writing own is well taken. Could not have said it better, 'character arrays are my friend' so I think I'll build tools around those.
Thanks.