Problem ?? calling a Function by label with no PARENS (), I thought was illegal
OR is it because I am not passing a value to it, just getting the RETURN value???
'
BT/compiler will call this function:
/////
function event_current_status()
dim current_status
current_status = AD(2) >>6
return current_status
end function
/////
with this result:
Executing...
starting Main:
1 to display time-- 2 to set time
3 live AD value -- 4 set threshold
5 reset data, 6 review data, 7 prnt data
8 battery voltage, 9 event logger - GO
choice was 2
* * RTC updated during 'EVENT logger
set time accordingly
D ? enter value
H ? enter value
M ? enter value
S ? enter value
time is set
30th 21:18:45
1 to display time-- 2 to set time
3 live AD value -- 4 set threshold
5 reset data, 6 review data, 7 prnt data
8 battery voltage, 9 event logger - GO
choice was 9
start status 420....................NO PARENS, to get this value
30th 21:19:OO
30th 21:19:O3
382........................I changed the AD potentiometer input - so the 'while loop would exit"
no parens !!
30th 21:19:O4
373
no parens !!
30th 21:19:O5
396
no parens !!
30th 21:19:O6
404
no parens !!
*******************************CODE SEGMENT that caused the above print out -- notice the parens () are missing !!!
Status:
event_start_status = event_current_status .......................NO PARENS
print "start status ",event_start_status
'
Monitor_loop:
'
if threshold >= 0
while event_start_status < (event_current_status() + hysteresis) AND event_start_status > (event_current_status() -hysteresis)
call RTC_update_time
loop 'checks event monitor input pin every second
else
'REM routine for digital change in value
endif
gosub RTC_read_time
'
print event_current_status.......................NO PARENS
print "no parens !!"
event_start_status = event_current_status()
'log info
'check for an end of job event/button
goto Monitor_loop
BT - Function calling
Re: BT - Function calling
FUNCTION or SUB without parameters can be called with or without (). Nothing is being passed so it doesn't much matter.
So I'm not sure what the issue is here.
GOSUB or CALL keywords are optional for FUNCTION or SUB, they are for backwards compatibility with some BASICs that required them. I tend not to use them myself.
So I'm not sure what the issue is here.
GOSUB or CALL keywords are optional for FUNCTION or SUB, they are for backwards compatibility with some BASICs that required them. I tend not to use them myself.
Re: BT - Function calling
no program issue, I thought the compiler was overlooking something., ws all
I first noticed it when doing the mbed, went back and verified it on the BChip.
**
I am confused when you say the GOSUB and CALL keywords are optional --
I took the CALL out of my loop and now I get errors from the compiler -:::
RTC_update_time
-ERROR C:/Coridium/Basic.mbd2/Examples/1768_event_logger01.bas: 302: Expected lvalue: variable, pointer, or register, found end of line
so then I added the empty Parens and still got an error:::
RTC_update_time()
-ERROR C:/Coridium/Basic.mbd2/Examples/1768_event_logger01.bas: 302: Expected lvalue: variable, pointer, or register, found ()
**
it also screws up the else/endif according the the rest of the error messages - which is expected ; just FYI
*******
RTC_update_time is a labeled routine, grouped up in the Function/gosub area [ie. prior to Main: ]
it ends with a Return, but doesn't return a value - just updates some strings for time display & WAIT(998) for my timer.
I first noticed it when doing the mbed, went back and verified it on the BChip.
**
I am confused when you say the GOSUB and CALL keywords are optional --
I took the CALL out of my loop and now I get errors from the compiler -:::
RTC_update_time
-ERROR C:/Coridium/Basic.mbd2/Examples/1768_event_logger01.bas: 302: Expected lvalue: variable, pointer, or register, found end of line
so then I added the empty Parens and still got an error:::
RTC_update_time()
-ERROR C:/Coridium/Basic.mbd2/Examples/1768_event_logger01.bas: 302: Expected lvalue: variable, pointer, or register, found ()
**
it also screws up the else/endif according the the rest of the error messages - which is expected ; just FYI
*******
RTC_update_time is a labeled routine, grouped up in the Function/gosub area [ie. prior to Main: ]
it ends with a Return, but doesn't return a value - just updates some strings for time display & WAIT(998) for my timer.
Re: BT - Function calling
Code: Select all
SUBusingLABEL:
print "do something"
RETURN
SUB SUBwithNOparams
print "do something else"
END SUB
main:
CALL SUBusingLABEL ' CALL or GOSUB is required here for any subroutine using labels: ... return
SUBwithNOparams ' simplest way to call it
SUBwithNOparams() ' also legal as of some version of the compiler in the last year
CALL SUBwithNOparams ' is also legal, though I think a bit wordy
CALLing an #included FUNCtion
Hello Basicchip,
I ran into problems when I moved my FUNCTIONS to a file that I "#include(d)" -->> see attached picture
This seems counter to your last reply/ code example in this link:
viewtopic.php?f=9&t=867&p=2757&hilit=CA ... 35ee#p2757
'
Your example appears to have the Function/Sub in the same file as "Main:"
'Using "ARMbasic[9.60c] on the PC Copyright 2021, Coridium Corp." BasicTools 6.40 on a ProStart
on Windows with Notepad++ editor
'
Any thoughts ??
Gary Olzeke51
I ran into problems when I moved my FUNCTIONS to a file that I "#include(d)" -->> see attached picture
This seems counter to your last reply/ code example in this link:
viewtopic.php?f=9&t=867&p=2757&hilit=CA ... 35ee#p2757
'
Your example appears to have the Function/Sub in the same file as "Main:"
'Using "ARMbasic[9.60c] on the PC Copyright 2021, Coridium Corp." BasicTools 6.40 on a ProStart
on Windows with Notepad++ editor
'
Any thoughts ??
Gary Olzeke51
- Attachments
-
- CALL_to_include_files.jpg (144.75 KiB) Viewed 1160 times
Re: CALLing an #included FUNCtion
Moved them Back into the file with 'Main:'
No more issues
Olzeke51
[edited] the 'translate' SUB - GOSUBed another SUB to print an error message ????
actually both of those did the GOSUB Errors(n) to print messages...
?? have to set a 'global variable' for the Error #, then
. do the GOSUB Errors(n) from the "Main:" ??
No more issues
Olzeke51
[edited] the 'translate' SUB - GOSUBed another SUB to print an error message ????
actually both of those did the GOSUB Errors(n) to print messages...
?? have to set a 'global variable' for the Error #, then
. do the GOSUB Errors(n) from the "Main:" ??
Re: CALLing an #included FUNCtion
Would really need more context to answer this.
The example you site compiles and runs correctly.
There is a difference between a subroutine defined by LABEL1: ... RETURN and one defined by SUB LABEL2 ... ENDSUB
The LABEL1: ... RETURN can never have parameters, so CALL LABEL1 () would be illegal
And in this case you must use CALL or GOSUB
In the LABEL2 case, the compiler knows it is a SUBroutine and not just a label, so the following are all legal
LABEL2 subroutines must always be declared before their first use. That restriction does not apply to LABEL1 type subroutines. That is what I would guess your error is about.
Why so many syntaxes? Well in the original BASIC it was always something like GOSUB 120. Doing without line numbers means you need labels. And SUB --- ENDSUB comes along with other later BASICs. CALL, GOSUB or implied are available in many different modern BASICs.
The example you site compiles and runs correctly.
There is a difference between a subroutine defined by LABEL1: ... RETURN and one defined by SUB LABEL2 ... ENDSUB
The LABEL1: ... RETURN can never have parameters, so CALL LABEL1 () would be illegal
And in this case you must use CALL or GOSUB
In the LABEL2 case, the compiler knows it is a SUBroutine and not just a label, so the following are all legal
Code: Select all
LABEL2
GOSUB LABEL2
CALL LABEL2
Why so many syntaxes? Well in the original BASIC it was always something like GOSUB 120. Doing without line numbers means you need labels. And SUB --- ENDSUB comes along with other later BASICs. CALL, GOSUB or implied are available in many different modern BASICs.
Re: BT - Function calling
RESOLVED ---
NOW I know what those 'guards' DO
'
turns out BOTH of my support #includes had the same 'guard'
SO the second file got ignored for the final compile !!!! [and any of its SUBs]
'
must be a pre-processor function - there is no mention in the help file for 'guard'
'
THANK YOU, Basicchip for testing on your end
It only took about 3 hours, and 12 screen-capture of errors , and 6 extra 'testing' files [including your Blinky.bas}
'
Gary Olzeke51
NOW I know what those 'guards' DO
Code: Select all
#ifndef IRremoteint_h
#define IRremoteint_h
turns out BOTH of my support #includes had the same 'guard'
SO the second file got ignored for the final compile !!!! [and any of its SUBs]
'
must be a pre-processor function - there is no mention in the help file for 'guard'
'
THANK YOU, Basicchip for testing on your end
It only took about 3 hours, and 12 screen-capture of errors , and 6 extra 'testing' files [including your Blinky.bas}
'
Gary Olzeke51