Proton BASIC Community

Some years ago I built a tube tester, the thought of wiring 9 rotary switches was not very appealing to me so the path of least resistance was chosen and pots were used to emulate rotary switches, I was most unimpressed with the feel of the working product so a speaker was installed and the code written such that every time the "switch" changed state the speaker made a click it seemed much better, the human mind or maybe my mind is a strange thing.

https://sites.google.com/view/kenstubetester

This is a quote from the web page.
I decided to use pots for the manual mode pin select as one can see the selection by looking at the chicken head knob position, the code has been written such that a click occurs when the pot is moved to another position. A small cheap ebay purchased 16 to one MUX board was mounted on the front panel so all 15 pots could be connected to the custom designed micro  PCB using a single 10 wire ribbon cable, leaving some spare wires for expansion. The dsPic board I designed can also be seen in this image.

ken k

Quote from: trastikata on Jun 03, 2023, 03:55 PMIt looks like a problem with the parser because even with colon ":" after "Then", which is supposed to indicate a new line, doesn't generate the correct assembler code:

Code Select Expand

Code Select Expand

ElseIf sw1<130 Then : t=6

I am not sure that is the case, you can either write If, Then Else/ElseIf on the same line or on separate lines, I suspect the compiler is probably looking for two different things to differentiate which method the user has used and thus how to process the code correctly, i.e.
If it sees code to execute after the Then statement is process the the If Then Else as being written on one line, whereas if it sees no code after the Then statement is processes the If Then Else is is written using the multi-line format and so processes it expecting the code to execute as a result of the Then statement to be on the next line.

Therefore in writing...
[b]If x = y then[/b]
[i]Do this[/i]
[b]Elseif x = z then[/b] [i]Do that[/i]
[b]Elseif a = b then[/b] [i]do something else[/i]
[i]Do another thing[/i]
[b]End If[/b]

By writing Elseif x = z Then Do that on the same line you are effectively mixing the two different ways of writing the If Then statement which is probably why it does not work, after all it is unreasonable to expect the compiler to consider every possible way in which someone could structure their code.
Thus the first line in the example above may be telling the compiler to process it as a multiline If Then because there is no following code on the same line, thus for the following ElseIf/Else statements it is logical that the compiler would therefore expect and so look for the Then code to execute to also be on the next line of code, rather than the same line of code so it ignores anything after the Then, hence no code is produced for the thing to do.

I am now in the process of altering the compiler's syntax checking for the If-Then directives, so they detect the syntax issues shown here. The compiler's If-Then directives have had the same syntax checking for about 18 years now, and it has taken that long for them to be spotted as incorrect in checking some texts placed where they should not be. Not bad at all in my book. LOL.

That is one of the problems when writing complex code on your own. A subconscious bias sets in, so the, "not so obvious", are not always detected, and the bias stops a person creating code that "should not work, so why write it" :-) That is where a "third person" comes in, so they can perfrom tasks that never crossed the mind of the code's creator.

Les, could you take a look in this topic, messages #15 ... #19?
I'm curious what about your opinion is about the line separator ':'.

Bringing it up, Les could you please advise regarding our discussion in posts 15 to 19?

Re  #15..#19
The manual states a colon can be used to separate instructions on the same line. An if..then : statement is an incomplete statement, it cannot finish on a : so the compiler should pick this up as a syntax error. I think it is wrong to describe the : as a new line.

Quote from: JohnB on Jun 09, 2023, 04:41 PMRe  #15..#19
An if..then : statement is an incomplete statement, it cannot finish on a : so the compiler should pick this up as a syntax error.

John, if you take a look at post 17 where I included a screenshot of the manual, you will see an example with "For .. Next" loop. I see no difference between the "For .. Next" structure there and the "If ... Then" in question.

P.s. It is not only instruction but labels as well that can be separated by a colon as per the same screenshot. But I hope Les will clarify it soon.

The colon : is open to abuse, I have seen a full lines of unreadable code using colons, not on this site.
Personally I think it should be reserved for Labels or used once per line, max.

As for the If ElseIf Else statement, I remember Les saying he was changing the compiler and EndIf was always required, this was related to the colon.
Maybe Les changed it and didn't update the manual.

Dave

Hi All,
I don't know if this is related to my abuse of using the colon but in the same code as my original post about using pots as rotary switches, I had a line of code as follows-

If INTCON.1=1 Then count=count+1 : INTCON.1=0

Now when I'm checking a flag I like to clear it as fast as possible and clear it on the same line so I don't inadvertently write other lines of code between. 
At the last minute I changed the line of code to-

If INTCON.1=1 Then Inc count : INTCON.1=0

It seemed such a trivial change I didn't bother checking but the count function no longer worked until I restored the original code.
I don't think I have used the Inc and Dec commands before but didn't expect this.  Can anyone confirm if this may be a colon issue again?  If the code after the colon was not recognised then I guess my count stops at 1 as the flag will never be cleared.

Cheers,
David

Hi David

This is not a single line if
If INTCON.1=1 Then count=count+1 : INTCON.1=0

It should be written
Which is more readable and better practice
If INTCON.1 = 1 Then
    count = count + 1
    INTCON.1 = 0
EndIf

Even if I'm only writing one instruction, I will always use this format, it's easier to read and you may need to add more instructions, no problem with this format.
The Basic Language relies on line breaks other languages have other methods.

Ban the Colon no crap
Sorry couldn't resist

Dave

@david If I put multiple statements after the if..then I always put the : endif at the end.
I've actually never found a problem with my method.

Johan

Edit: Sometimes I have an if ... then which very obviously changes a counter and flag and then I don't want to use 4-5 lines in my source.

OK - fair enough about my poor formatting but why did one work and the other didn't?  I was expecting that n=n+1 could be replaced with Inc n but it doesn't seem that way with my dodgy formatting.
My apologies if I've muddied the waters regarding the original post.

Best regards,
David

I agree with DaveS, but in a simple test the two statements in post 28 produce the same asm code

F1_000007 equ $ ; in [TEST_18F.BAS] if INTCON.1=1 Then count=count+1 : INTCON.1=0
    movlb 0x00
    btfss INTCON,1,0
    bra _lbl__3
    incf count,F,0
    bcf INTCON,1,0
_lbl__3

F1_000008 equ $ ; in [TEST_18F.BAS] if INTCON.1=1 Then Inc count : INTCON.1=0
    movlb 0x00
    btfss INTCON,1,0
    bra _lbl__3
    incf count,F,0
    bcf INTCON,1,0
_lbl__3

The exact code would depend on the device and variable assignments, so that might come into play. The above was for an 18F25K22 with no other variables.

Yes I'm seeing the same assembler code for the 16F684 I'm using but just can't get it to work with Inc count.
I shall try to be more careful with my formatting in future.
Back to the original thread.

Cheers,
David