ESP8266 Community Forum

- Thu Aug 11, 2016 7:12 pm #52739 Using ESP Basic 3.0.Alpha 33
Program:

[poo]
if t = 0 then
t = 1
else
t = 0
end if
goto [poo]

(Note: I have a few spaces in front of each of the two " t = .." statements that do not show up on this FORUM screen.)

After Saving it, if Run it, screen goes blank. System crashes. Must RESET the chip, wait, then go back to 192.168.4.1 in a new browser window to get back working system.

If use a SERIAL TERMINAL, notice that it says: Error at line 2: Comparison between string and number! It prints once.

If go to Debug and Run the program, now the debug screen goes blank and system crashes. Must RESET to get the system back up. Again, the serial terminal displays “Error at line 2: Comparison between string and number!” once.

If add a debugon statement before [poo] then Save and Run the program, a blank screen again shows up, the debugger does not display, and the serial terminal shows, “Error at line 2: Comparison between string and number!”

- Thu Aug 11, 2016 8:26 pm #52742 Perhaps by default undefined variables are string not numeric. If so, then your first comparison would cause the error.

You could try adding t = 1 before the first line of your code to prove the supposition.

I wonder if adding a memclear and ramfree() might help shed a little light on why this causes a crash.
Or try adding a statement that creates a variable other than t, just to see if it's a comparison without any variables created that trips it.

Do you have anything in the settings page for logon to yournhome network?

Edit:
I've tried this - on my unit, running v33, it just hangs the browser display, as it's in an endless loop, with no browser output provided that t is numeric. I wonder if you have created a t variable with a string value before running the program? I'm also wondering (bit of a stretch) if the error the debug break forces may not always be null?
perhaps if you insert a break say before the label, you might see a t var exists?

- Fri Aug 12, 2016 7:08 am #52780 Oldbod,

Thanks for your post.

Yes, adding t = 0 before the first line of my code eliminates the comparison error. This may show that undefined variables are string the first time they are encountered. But strangely they apparently change type to numeric afterwards, since the comparison error occurs only once in the serial terminal in this infinite loop. (This may possibly still be a bug in error detection.)

If this error is real the documentation and language definition must be changed to note that numeric variables must be used at least once to show the parser that they are numeric, which makes BASIC a bit less “basic”.

Or a change made to be more like traditional BASIC, in which any variable ending in a $ is a string variable, else it is numeric. I would much prefer the simpler $ solution.

My settings page is at its default values. The chip acts as an access point. My network environment includes an ethernet cable to my dsl modem and a WiFi module that connects to 192.168.4.1. This gives my development environment the benefit of both Internet access as well to ESP BASIC as an access point.

But the bug remains that the debug screen goes blank. This of course should not happen.

- Sun Aug 14, 2016 3:53 am #52898 I still haven't been able to replicate your experience with the debugger, but I've now moved to v34 so that may be why. I don't at present use the codemirror files just because I have at least one android browser that doesn't work well with them.

There is definitely something in the way variables are created: I've found that if you say "n=1" as a line, that will flag a comparison error. "n =1" won't, nor will "let n=1". I suspect this may be the interpreter taking the line as an instruction to do a logical/boolean comparison rather than just "set variable to this value, creating it if not already existant" but mmiscool will know. May be I should read the documentation. I asked about your settings just because I wondered how if you were loosing the settings values hence the 192.168.4.1 or, just as you are actually are, using that intentionally...

Agree about the use of a $ for strings, but I can see there are downsides to it. Not fully tested yet, but I think an ota update of user source may be doable using "as is" code.