Maximum number (i.e. quantity/limit) of variables

Dear all,
please apologise for my, probably trivial, question below:
is there any limit on the number (quantity) of varables for an app ?
In my app (apk size approx. 5.5 Mb) I have slightly more than 200 global variables, spread in 50% numeric, 25% boolean, 25% string. One of these strings is actually a buffer for data writing, for debug purposes, into a txt file. The file can reach up to 40/50 Kbytes at the end but it is written incrementally (approx. a few Kb at a time).
The question arises since for a "mysterious" reason the app shows apparently erratical behaviours since a few days ago when I have added some features and consequently I have added also some variables. Obviously I don't use the added features, to avoid that the strange behaviour can be triggered by these functions, but the variables are still there (declared).
A back up version, unfortunately old enough to be useless to make a step-by-step investigation, works.
In a nutshell: (the final question is) is there a limit number of variables that MIT AI2 can handle ?
(I don't think I've reached the "end of memory" of my tablet LENOVO Android 9).

Thanks a lot !

PS sorry to have bothered you but, I remember when I was young :grimacing:, an unpredictable behaviour sometimes was caused by an "overlap" of RAM variables (in embedded systems featuring a very little amount of RAM memory) ... :upside_down_face:

Shouldn't be an issue, sounds more like how these variables (or other activities) are handled in the app somewhere.

Thanks @TIMAI2 ,
probably you're right, but since It's more or less a couple of days that I'm getting crazy about this issue, I was just wondering whether there could be a limit on the number of variables.
I've also tried to comment out the last added variables declaration (i.e. by disabling their global declaration) and I was expecting that the error of "missing variable" was rised up, but I've seen that no errors are declared. Just to see if the variables are used somewhere else in the code (unwanted).

Anyway, if you say that there is no limit on the variables number, I will continue my search in other directions: riding for nowhere, looking for the unfindable :rofl: :rofl: :rofl:

Cheers, Ugo.

I didn't say there is no limit, (some say there is an edge to the universe...), just that for the numbers you indicated there should not be an issue.

1 Like

:innocent: :innocent: :innocent: sure... the Earth is flat, like a pizza :rofl: :rofl: :rofl:

Could the new variables have stumbled into a forbidden name space, like Java keywords?

1 Like

Dear @ABG, (and @TIMAI2),
thanks a lot for your suggestions. This is a good idea, and I didn't think on it, before. I will take a look on that also.
As a matter of fact I'm still continuing the investigation (the problem is still present) and I was thinking about a "timing" problem.

Just a few words to explain a bit more what is the "strange behaviour" that I'm facing with.

My app is intended to manage the endurance races (i.e. rallies) done with an ancient car (Lancia Fulvia 1.3 HF dated 1967) owned by a friend of mine.
We have put two Hall sensors of the rear wheels of the car and with a couple of Arduino boards, a Nano to interface the Hall sensors, in order to be capable to get the Hall inputs in real time, without nothing else to do, and an ESP32 to send the pulses via BT to the app running on a Lenovo pad (8" display/Android 9).
We have used two Arduino boards because the Hall sensors are analogue ones, so the Nano (like a Schmitt trigger) acquires the voltages generated by the Halls, then squares them to generate a true pulse, The Nano is linked to the ESP32 by two wires, in order to rise two interrupts to the ESP32 on the falling edge of the pulses. The ESP32 counts the pulses (interrupts) and sends the counts to the app via BT every 500 ms (together with some status bits; in total, less than 20 bytes).

In parallel we have also enabled the GPS of the Lenovo pad so to have two different sources for both speed and distance. My app is then capable to work with each source singularly or both, depending on the settings that we write into a configuration file.
This has worked fine for many months, but recently (the Android updates are locked, in order to avoid any surprise) the behaviour has changed: while using only the GPS source, the algorithm works fine, but when I use only the Hall sensors, the same algorithms fails : the sequence (flow) of the overall app seems unpredictable.

The main difference between the two situations is that when I use only the GPS input, the 10 ms clock for polling the BT input is not enabled. In other words: when the Hall source is enabled, every 10 ms the clock fires and looks for incoming data from the BT (if no data is available the clock exits immediately).
Another difference is that when I use only the GPS, the data (position and speed) updating rate is slower: i.e. 1000 ms (1 s) and is generated by a different Clock block that is the "timer tick" of the app, always running.
What is troubling me is that everything has worked fine for months, but now not!!!

Obviously I don't believe in ghosts, so most probably there is something that I've done in some recent modifications that is generating the mess, but though I try to make a step by step investigation, I'm not reaching a stable result, yet.
For example: thinking about a "timing shift", I've removed a SOUND block, that I used to give an audible feedback to a pushbutton (supposing that the SOUND block is keeping for itself the CPU 'till the sound has finished to play), and the Hall algorithm happily started to work fine again as in the past :+1:. Then, for a counter-proof, I put again the SOUND and it failed again. So I thought: "I got it !!!", but by removing again the SOUND block, it continued to fail :upside_down_face: so it seems that the SOUND block is not the true root cause.

In my offsetminded experience of old embedded software engineer, the unpredctable behavious were caused typically by memory or timing overlaps, stack overflows, interrupts' addresses not mapped...other nightmares...
So, to try to detect the cause, I'm writing on a file some flags (like buoys: "passed from here") and I see that, when I use the Hall inputs, the flow of flags is different with respect to the one of the GPS. So my thoughts are: either there is a decision variable that is overlapped (or wrongly set) or there is a timing which is not respected...or...

The challenge continues...(and the headache too :disappointed:)
Obviously any hint is much appreciated, .
Tschuess, Ugo.

10 ms is fast for AI2.
Do you really need to poll that often?

If that's you transmission period, you need poll only every 250 ms.

You don't need multiple Clock Timers.
Just use your fastest (smallest ms) Clock and check deadline variables to decide whether or not to poll for inputs.

Things that can change by themselves over time to slow things down:

  • Batteries degrade, lowering their voltage
  • Lowered voltages result in processor slowdowns
  • External RF interference can appear to slow down BlueTooth traffic
  • Dust can accumulate, increasing heat, resulting in processor slowdown

I once encountered a side effect of the SOUND component where it blocked interrupts.

1 Like

Dear @ABG, Abraham,
again thanks a lot for your time in reading me, and for your hints.
Honestly I know that a sampling rate @ the double of the fastest input should be enough, so the polling period should be 250 ms, but in order to be on the "safe side" I always use a much faster clock (and I never had problems with AI2 as well: for example, in my CAN EOBD interface app that I posted a couple of years ago). Nevertheless, I agree with you that probably I'm too fast (my wife says the same :upside_down_face:).
I agree also that I can have a unique fast clock and set some "demux" variables to timely perform slower tasks, as in a scheduler, but I rather prefer to have different clocks so to separate phyically and visually the tasks (like every man I have only one neuron -my wife says- so just one task at a time :slight_smile: ) As an exercise, some months ago I've written a trial app that behaves exactly in that way (effectively I've called it "Scheduler" ) but I've seen with an oscilloscope that there were no significant improvement in the time slots precision.

I guess that the main problem now is the fact that this app is born without a clear specification from the beginning and now, by adding and removing features (and related variables) the code seems more or less a Pisa Tower (bending :frowning_face:), therefore I'm now crawling against the river current to find the bug :face_with_head_bandage: :face_with_head_bandage: :face_with_head_bandage:. I will keep you informed on any (hopefully) progress....

Vielen Dank fuer Ihre Hilfe.
Mit freundlichen Gruessen,

Dear @ABG, dear @TIMAI2 ,
at the end I found the root cause: an "open input" to the ESP32 board !!! :angry: :rage: :angry:
The solderless breadboard where the ESP32 and the Nano are fitted in, had an analogue input wire that was open (let's say "a poor contact"), so suddenly it was reading variable voltages that were interpreted wrongly (obviously) and the status bits sent together with the counter of Hall pulses were wrong and misinterpreted by the app which foolished the correct flow.
By re-connecting the wire everything works fine again !!!
At the end it was a HW problem.... :tired_face: :tired_face: :tired_face:
This is the revenge of my software engineer soul... :innocent: :innocent: :innocent:
Again thanks a lot to all.

(@ABG you were right when you said that a different voltage can cause different behaviours: yesterday when for a while it was working fine, I was running on batteries, so the overall voltage was probably lower and the analoge input did not suffer of the power supply ripple, but when I powered again the HW with the AC/DC power supply, the stuff failed again...).
Lesson learned !!!

Cheers, Ugo.

PS here below the breadboard I mentioned:



This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.