I have always done my select/case like this so never had that problem
I find it easier to read
Regards Paul



[code:1:49293badd5]
Select Case P
Case 1
Print "All is ok"
Case 2
Print "Some error occurred"
Goto Brake_here
Case Else
Print "Unknown error"
Goto Brake_here
End Select

[/code:1:49293badd5]

Hallo, Its Work, Thank you well, Is a new time for me to Prog with LCD´s, so i have a Problem with the fonts. I use a LCD Display with 0,92" and a resulution of 128x32 (other infos from web says 128x64.
After Prog a Programm with

Lcdat 2,10, "1995-2015"
Lcdat 3,5, "MSC Electronic" ,1

the fonts not readebel
see the Pictures...
can you help by the next Steps??
Thanks a lot BoA

Hi,
I came accros this odd behavior with select-case statement used together with Goto.
Two statements separated by a ":" on the Case Else line will throw an error if last statement is a Goto.
If the second statement are moved one line down, the code will compile and work as expected.
Its no big deal doing this as an workaround, but I'm curious why.

Compiler version :2.0.8.1
Compiler build :2.0.8.1.000
IDE version :2.0.8.1.001
Windows OS :Windows 10 Pro

[code:1:e2d55d65d6]$regfile = "m328pdef.dat"
$crystal = 16000000
$hwstack = 100
$swstack = 100
$framesize = 100
$baud = 38400

$sim



Dim P As Byte

' THIS GIVES > Error : 323 Line : 19 Label Too Long [ "UNKNOWN ERROR" : Goto Brake_here]
P = 1
Select Case P
Case 1 : Print "All is ok"
Case 2 : Print "Some error occurred" : Goto Brake_here
Case Else : Print "Unknown error" : Goto Brake_here
End Select



' THIS WILL COMPILE AND WORK AS EXPECTED
P = 2
Select Case P
Case 1 : Print "All is ok"
Case 2 : Print "Some error occurred" : Goto Brake_here
Case Else : Print "Unknown error"
Goto Brake_here ' THE GOTO FOR CASE ELSE MOVED TO NEXT LINE
End Select

Brake_here:
Print "P= " ; P
End[/code:1:e2d55d65d6]

[b:e2d55d65d6][color=red:e2d55d65d6](BASCOM-AVR version : 2.0.8.1 )[/b:e2d55d65d6][/color:e2d55d65d6]

Above is whole code which works well (tested) with all charcters (0 or not) which have carriage return/linefeed, or with received bytes (not chr) with (at least of one) value >0. But when UART received only 0 bytes, not characters, then Ischarwaiting() don't return 1, it don't see 0 like received byte.

[quote:5aae93e45e="Flash"]This is not a code,[/quote:5aae93e45e]
Yes, you're right, these are only unrelated lines, but no code which would allow o tackle the issue.
[quote:5aae93e45e]I don't need to use inkey, waitkey, inputbin etc. only confirmation of receipt.[/quote:5aae93e45e]
Without use of any of these, or similar commands the input buffer won't be emptied.
Makes no sense.
If you expect help, post a compilable example which shows the problem.

[quote:93e6a2625b="MWS"][quote:93e6a2625b="Flash"]because Ischarwaiting=0 if all bytes are zero(0)[/quote:93e6a2625b]
Your statement is wrong.

Ischarwaiting() returns an 1 for a byte received, doesn't matter of the byte's value.
Your code - which you do not show - is flawed.[/quote:93e6a2625b]

This is not a code, I know that Ischarwaiting() returns an 1, here is question why it don't return 1 when I received e.g. three bytes in a row and all of this three have value 0x00, shouldn't Ischarwaiting() recognize this bytes with value=0?
This is the simple code (AT90CAN):
[code:1:93e6a2625b]
Config Com2 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
Open "COM2:" For Binary As #2
Config Serialin1 = Buffered , Size = 100

'Slave send some bytes (3 or more) with 0x00 values (I can see them on logic analyzer) on COM2 UART - Ischarwaiting(#2) = 0

If Ischarwaiting(#2) = 1 Then 'loop through data
'do something
Else
'do something
End if
[/code:1:93e6a2625b]
When is one of the received byte with value >0 (e.g. 0x01) then is all ok -Ischarwaiting(#2) = 1. I dont need to use inkey, waitkey, inputbin etc. only confirmation of receipt.

see the help about null character
I suppose you know but ...
null ascii 0 is different of "0" chr ( 48 )

Help said
"you can send and receive both with While the Inkey() will get the character from the HW UART when there is a character in the buffer, it will return a zero when the character is zero. This makes it unusable to work with binary data that might contain the value 0."

Ischarwaiting()

"While the Inkey() will get the character from the HW UART when there is a character in the buffer, it will return a zero when the character is zero. This makes it unusable to work with binary data that might contain the value 0.
With IsCharWaiting() you can first check for the presence of a character and when the function returns 1, you can retrieve the character with Inkey or Waitkey."

so ischarwaiting return 1 when you send it a null but inkey see nothing.

so please send us a your code
JP
:wink:

[quote:241d6cbbf2="Flash"]because Ischarwaiting=0 if all bytes are zero(0)[/quote:241d6cbbf2]
Your statement is wrong.

Ischarwaiting() returns an 1, doesn't matter of the received value.
Your code - which you do not show - is flawed.

Hi,

Maybe a Do Loop while ISCHARWAITING. Something like:-

[code:1:cfbcb9bfc4]
While Ischarwaiting(#2) = 1 'loop through data
Rfid_char = Inkey(#2) 'Get 1 byte
If Rfid_char = 2 Then 'Chr 2 - Start of MSG
Rfid_ptr = 0 'Reset pointer
Else
Incr Rfid_ptr 'Move to next byte
Rfid_array_local(rfid_ptr) = Rfid_char 'Save char to array
End If
If Rfid_ptr >= 12 Then ' correct length
Rfid_have_buffer = 1 'tell user space
Rfid_ptr = 0 'Reset buffer pointer
Exit While 'Move on
End If
Wend
[/code:1:cfbcb9bfc4]

In this example CHR(2) is the start of a message the message is always 12 bytes long and the data lands in a Byte array (Rfid_array_local). Note I'm using buffered serial i/o so this routine doesn't need to be called that often.


Regards
Ian Dobson

Is there some way for UART receiving zero bytes (e.g. 0,0,0,0), because Ischarwaiting=0 if all bytes are zero(0), only if one is >0 (0,0,0,1) then it worrks fine. Problem is because slave send some empty bytes data which can't be changed.
Thanks

[b:8b8d1f822d][color=red:8b8d1f822d](BASCOM-AVR version : 2.0.8.1 )[/b:8b8d1f822d][/color:8b8d1f822d]