|
Post by johnnyd on Jun 12, 2019 4:27:25 GMT -5
Hi good people of LB land,
This code is used to look for a serial device being connected (it's a USB device) and loops round until it detects a string that it spits out.
The code sits in the loop waiting for the device to be connected.
When I run it, it will increase memory usage (4k per increase) and after a short while will crash out with stack overflow.
If I step through it in debug, there is no memory increase. Not sure if it still crashes as I'm not patient enough o keep clicking!
find$=chr$(255)+chr$(255)
[comloop] for a=1 to 16 scan oncomerror[comerr] open "com"+str$(a)+":,9600,N,8,1,cs0,ds0,rs" for input as #coms comopen=1 calldll #kernel32,"Sleep",200 as ulong,r as void a$=input$(#coms,lof(#coms)) if a$="" then[nextcom] pa=instr(a$,find$) pb=instr(a$,find$,pa+1) if (pb-pa=11) or (pb-pa=22) then com$=str$(a) exit for end if
[comerr] oncomerror
[nextcom] if comopen=1 then close #coms comopen=0 end if calldll #kernel32,"Sleep",100 as ulong,r as void next a if com$<>"" then[csok] goto[comloop]
[csok] wait
John.
|
|
|
Post by Rod on Jun 12, 2019 7:43:41 GMT -5
I don't like the scan statement in there and I am not sure if oncomerror "" is getting called every time through the loop. You might be building up a stack of oncomerror events.
Untested code but it does away with the scan and should consistently reset the oncomerror event.
[comloop] find$=chr$(255)+chr$(255) a=1 com$=""
while com$="" oncomerror[comerr] open "com"+str$(a)+":,9600,N,8,1,cs0,ds0,rs" for input as #coms
comopen=1 calldll #kernel32,"Sleep",200 as ulong,r as void a$=input$(#coms,lof(#coms)) pa=instr(a$,find$) pb=instr(a$,find$,pa+1) if (pb-pa=11) or (pb-pa=22) then com$=str$(a) else com$="" end if
[comerr] oncomerror
if comopen=1 then close #coms calldll #kernel32,"Sleep",100 as ulong,r as void a=a+1 mod 16 wend
wait
|
|
|
Post by johnnyd on Jun 12, 2019 9:31:44 GMT -5
Hi Rod, Thanks for the reply, but it still crashes out with stack overflow. Slightly modded your code: [comloop] find$=chr$(255)+chr$(255) a=1 com$=""
while com$="" oncomerror[comerr] open "com"+str$(a)+":,9600,N,8,1,cs0,ds0,rs" for input as #coms comopen=1 calldll #kernel32,"Sleep",200 as ulong,r as void a$=input$(#coms,lof(#coms)) pa=instr(a$,find$) pb=instr(a$,find$,pa+1) if (pb-pa=11) or (pb-pa=22) then com$=str$(a) else com$="" end if
[comerr] oncomerror if comopen=1 then close #coms comopen=0 end if calldll #kernel32,"Sleep",100 as ulong,r as void a=(a and 15)+1 wend
wait
If you run it in debug and have task manager open, you will see the memory increment.
If you single step through it, the increment doesn't seem to happen, but I got bored clicking.
I've altered the way I determine the string to look for but it doesn't affect the way the port is determined.
The scan was there because I have a window open with some dialogue and a cancel button, so the button needs to be detected.
John.
|
|
|
Post by Rod on Jun 12, 2019 12:57:57 GMT -5
Perhaps slow down the looping so that it builds less of a stack?
The scan has the danger that it will deflect your code away to some other point mid process. Choose where you place the scan carefully. Best at the end of the process so that you know the com port is closed. If you have a mouse move event the scan could be jumping out of your com loop hundreds of times a second.
|
|
|
Post by johnnyd on Jun 13, 2019 3:39:20 GMT -5
Hi Rod,
It still doesn't want to play.
I reinstated the for-next loop so I could place the scan outside so it won't check while in the loop.
It now closes the port after a successful open & read of the port, so doesn't need to check at the end.
I tried increasing the sleep at the end to a second, but memory usage still suffers, albeit more slowly.
I even took the oncomerror out but the memory still crept up.
It looks like LB isn't performing housekeeping with this? Time to point this at Carl.
find$=chr$(255)+chr$(255) com$=""
[comloop] scan for a=1 to 16 oncomerror[comerr] open "com"+str$(a)+":,9600,N,8,1,cs0,ds0,rs" for input as #coms' calldll #kernel32,"Sleep",200 as ulong,r as void a$=input$(#coms,lof(#coms)) close #coms if a$="" then[comerr] pa=instr(a$,find$) if mid$(a$,pa,2)=find$ and mid$(a$,pa+11,2)=find$ then com$=str$(a) exit for end if
[comerr] oncomerror calldll #kernel32,"Sleep",100 as ulong,r as void next a if com$<>"" then[csok] goto[comloop]
[csok] wait
John
|
|
|
Post by Rod on Jun 13, 2019 4:04:32 GMT -5
There is API code posted that opens the serial port. I think there is a demo on the LBPE. Perhaps that closes down the resource mor efficiently. Away from home and out of time right now. You would only use the API code to establish which port then revert back to native code.
|
|
|
Post by johnnyd on Jun 13, 2019 5:11:01 GMT -5
Hi Rod,
OK, I'll search it out. Meanwhile, I've posted it under bugs.
John.
|
|
|
Post by Rod on Jun 14, 2019 5:49:58 GMT -5
The LBPE API code does not seem to have the stack overflow error.
find$=chr$(255)+chr$(255) com$="" while com$="" for a= 1 to 16 if CheckCom(a) then open "com"+str$(a)+":,9600,N,8,1,cs0,ds0,rs" for input as #coms calldll #kernel32,"Sleep",400 as ulong,r as void a$=input$(#coms,lof(#coms)) close #coms scan pa=instr(a$,find$) if mid$(a$,pa,2)=find$ and mid$(a$,pa+11,2)=find$ then com$=str$(a) : exit for end if next wend wait
Function CheckCom(cp) 'Checks for COM port available. Thanks LB group members! lpFileName$ = "COM"; cp 'Returns true if port can be opened dwCreationDistribution = _OPEN_EXISTING hTemplateFile = _NULL CallDll #kernel32, "CreateFileA", _ 'This won't halt the program if the port doesn't exist. lpFileName$ as ptr, _ dwDesiredAccess as ulong, _ dwShareMode as ulong, _ lpSecurityAttributes as ulong, _ dwCreationDistribution as ulong, _ dwFlagsAndAttributes as ulong, _ hTemplateFile as ulong, _ hFileHandle as ulong
CallDll #kernel32,"CloseHandle",_ 'Close the port, so we don't get an error later hFileHandle as ulong,_ ret as long If hFileHandle = _INVALID_HANDLE_VALUE Then CheckCom = 0 Else CheckCom = 1 End If End Function
|
|
|
Post by johnnyd on Jun 14, 2019 7:19:01 GMT -5
Hi Rod,
You star! This has sorted it.
Thanks for helping.
John.
|
|
|
Post by Brandon Parker on Jul 10, 2019 22:41:58 GMT -5
Hey John, I replied to other, duplicate thread as well since I was unaware that Rod had answered the question here. Stack overflow issue{:0) Brandon Parker
|
|