No.... Nothing changed.
Added this:
[code:1:65a675e8d2]echo off
Config input1 = CRLF , Echo = CRLF[/code:1:65a675e8d2]
EXCEPT for first line, Still getting this string 1234567890 all the time:
[code:1:65a675e8d2]1234567890#
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890[/code:1:65a675e8d2]
[code:1:65a675e8d2]10
49
50
51
52
53
54
55
56
57
48
[/code:1:65a675e8d2]
No there is something more wrong here, since this code SHOULD work >
I decide to not to use CRLF or CR..... I modify sending process to:
[code:1:65a675e8d2] ADCHEX = "1234567890#"
print ADCHEX;
[/code:1:65a675e8d2]
and now catching # character
[code:1:65a675e8d2]Config Serialin1 = Buffered , Size = 32 , Bytematch = 35 [/code:1:65a675e8d2]
So interrupt routine look the same:
[code:1:65a675e8d2]
Inputbin #2 , ADCHEX
print #2 , ADCHEX[/code:1:65a675e8d2]
This is results:
[code:1:65a675e8d2]12#12345678
90#12345678
90#12345678
90#12345678
90#12345678
90#12345678[/code:1:65a675e8d2]
BUT, seveal reset atempts later, I got working code.... But only once. This is totally unreliable.... :(
I figure out this. If first read is in the part of receiving string, first part is missing due the processor is just wake from reset, all other read are wrong. Results above show that I got all characters, but in wrong place....
So what I mean is that input routine still waits for "missing" bytes in way that receive expected number of bytes from two interrupts, and then assemble whole string...
I change interrupt routine to this:
[code:1:65a675e8d2]temp = 0
do
temp1 = Waitkey(#2)
incr temp
mid(ADCHEX , temp , 1) = chr(temp1)
temp1 = ISCHARWAITING(#2)
loop until temp1 = 0
'Input #2 , ADCHEX
print #2 , ADCHEX[/code:1:65a675e8d2]
And got this results every time
[code:1:65a675e8d2]12#
1234567890#
1234567890#
1234567890#
1234567890#[/code:1:65a675e8d2]
This is much better, but it is not what I wanted.....
↧