Guru
Joined: 07/08/2011
Location: AustraliaPosts: 6249
| Posted: 06:01am 22 Dec 2023 |
Every time you open a com port that has random data streaming in,
It is worth flushing the buffer.
A large buffer may take a few loops to clear it all.
do
junk$ - input$(255,#3)
loop until loc(#3) = 0
junk$ - input$(255,#3)
loop until loc(#3) = 0
Jim
Guru
Joined: 18/12/2014
Location: AustraliaPosts: 989
| Posted: 06:20am 22 Dec 2023 |
TEST maybe in the source as a command.
LIST FUNCTIONS works OK.
LIST COMMANDS does not come back.
Guru
Joined: 11/12/2012
Location: United KingdomPosts: 10169
| Posted: 08:18am 22 Dec 2023 |
b23
MMBasic.zip
Removes the command TEST and fixes LIST COMMANDS
Guru
Joined: 24/12/2017
Location: AustraliaPosts: 1638
| Posted: 03:10am 23 Dec 2023 |
Thank you Peter.
That did fix the Test problem and the LIST COMMANDS.
I still have the problems with the MM2 connected and spitting out messages 19 to the dozen presumably the coms buffer is full when I run MMB4W:
This program still crashes MMB4W.
OPEN "com3: 38400" AS #2
input #2, test$
print test$
CLOSE #2
input #2, test$
print test$
CLOSE #2
This program now prints nothing as if test$ is empty.
OPEN "com3: 38400" AS #2
test$ = INPUT$(20,#2)
PRINT test$
CLOSE #2
test$ = INPUT$(20,#2)
PRINT test$
CLOSE #2
Both programs work as expected in MMBasic DOS.
I tried a more realistic test and connected a CMM2 (changing the com port and the baud rate) and both of the above programs worked as expected when characters were printed. MMB4W did crash once while running the second program but I was unable to repeat it.
Bill
Guru
Joined: 11/02/2018
Location: AustraliaPosts: 2543
| Posted: 03:31am 23 Dec 2023 |
I gave up on INPUT$(), INPUT works ok.
Yes, it is very easy to make MMB4W crash.
'test 2.bas
clear
dim integer characters = 4, joystick 'data from controller/joystck
dim integer flag, trigger = characters - 1
dim a$
open "com7:460800" as #3 'purge buffer (thanks Jim)
pause 1
do:
a$ = input$(255,#3)
loop until loc(#3) = 0
close #3
pause 1
open "com7:460800,, buffer, trigger" as #3
pause 1
do
If flag then
if len(a$)=characters then joystick = val("&H"+a$)
? a$, bin$(joystick,characters*4)
flag = 0
endif
loop
sub buffer 'read buffer
input #3, a$
inc flag
end sub
' Program running on PicoMiteVGA
'
'dim integer m,n
'm=2^16
'do
' inc n
' n=n mod m
' pause 50
'loop
clear
dim integer characters = 4, joystick 'data from controller/joystck
dim integer flag, trigger = characters - 1
dim a$
open "com7:460800" as #3 'purge buffer (thanks Jim)
pause 1
do:
a$ = input$(255,#3)
loop until loc(#3) = 0
close #3
pause 1
open "com7:460800,, buffer, trigger" as #3
pause 1
do
If flag then
if len(a$)=characters then joystick = val("&H"+a$)
? a$, bin$(joystick,characters*4)
flag = 0
endif
loop
sub buffer 'read buffer
input #3, a$
inc flag
end sub
' Program running on PicoMiteVGA
'
'dim integer m,n
'm=2^16
'do
' inc n
' n=n mod m
' pause 50
'loop
Edit.
Data is received at 50mS intervals. Will see if it can go faster.
Edit 2. Seems ok at 5mS intervals, some errors at 1mS. (change Pause 50 in the VGA program)
Edit 3. Correction, on closer inspection there are occasional missing packets below 30mS.
Edited 2023-12-23 14:19 by phil99
Guru
Joined: 02/10/2012
Location: AustraliaPosts: 1114
| Posted: 04:30am 23 Dec 2023 |
Hi Bill,
A couple of observations:-
In your first program example I never get a failure - works every time however test$ is alway empty. This is because the time taken to create and OPEN a receive buffer and the command to read the buffer with the INPUT statement is too short for any characters to be received. If you put a PAUSE 100 between OPEN and INPUT it correctly displays characters that have had time to get into the buffer.
The same is true for your second program - no time between OPEN and INPUT$ to allow characters to arrive in the buffer. Again a PAUSE 100 between the two will show received characters.
In all my testing, I have not had any crashes of MMB4W (b23). The only issues I have had are where there are more than 256 characters in the receive buffer without any CR LF in there - this results in a 'string too long error' as expected.
Purely as an observation, if you have an unknown length of data to be received at intermittent intervals, you may choose to insert a specific header byte in the data stream. You can then read and throw away bytes 1 at a time until your wanted message block occurs. You can then read in the required number of bytes (remembering the string length limit of 255).
Regards,
Doug.
Guru
Joined: 11/02/2018
Location: AustraliaPosts: 2543
| Posted: 04:48am 23 Dec 2023 |
Instead of a pause you can trigger an interrupt on the second last character for maximum speed. By the time the Sub starts the last character has arrived.
Guru
Joined: 24/12/2017
Location: AustraliaPosts: 1638
| Posted: 06:07am 23 Dec 2023 |
Thanks Doug,
The PAUSE does work for both programs. Without it the first program DOES still crash MMB4W though and I don't think it should.
I have just tried a program with a lot of file I/O and that worked perfectly. I was worried that a PAUSE may be needed for that. But no.
While I understand your explanation and reasoning it is confusing that both programs work well in MMBasic DOS without a pause. A normal INPUT from the keyboard will wait until you type in something and hit <enter> and I realize that INPUT #nbr is normally for file I/O, it just doesn't seem to me as though it should need a PAUSE for it to work properly in this situation.
Bill
Edit: Thinking more about it, INPUT from a com port is more like a keyboard input and probably be treated the same way. My opinion for what it's worth.
Edited 2023-12-23 16:42 by Turbo46
Guru
Joined: 07/08/2011
Location: AustraliaPosts: 6249
| Posted: 07:11am 23 Dec 2023 |
I think that having characters in the rec buffer when you open it can cause grief. I would definitely flush using INPUT$(255,$n) for reliable startup.
I can't make it crash is the input chain is empty on startup.
It might depend on the make of USB TTL converter, just to make life interesting.
Another thing to remember, if you are using INPUT, it is looking for a LF not CR as the end of line.
CRs are simply dropped.
Jim
Guru
Joined: 07/08/2011
Location: AustraliaPosts: 6249
| Posted: 08:43am 23 Dec 2023 |
The strange thing I found.
At first, I could repeat Bill's error but when I went back to the original program after some experiments, nothing could make them fail...
Jim
Edited 2023-12-23 18:44 by TassyJim
Guru
Joined: 03/01/2018
Location: AustraliaPosts: 1092
| Posted: 08:46am 23 Dec 2023 |
Hi
I can't get mode 16 to work. Nothing on the screen.
Mode -16 & rest seem OK.
Am I missing something?
Brian
Guru
Joined: 11/02/2018
Location: AustraliaPosts: 2543
| Posted: 09:28am 23 Dec 2023 |
That may be the case. Sending from a MM2 via Geoff's ASCII Terminal to my program on MMB4W works perfectly but using a CH340 causes a "line too long" error.
Appending Chr$(10) or Chr$(13) to each packet doesn't help. TeraTerm has no trouble reading it properly so maybe MMB4W is a bit more fussy.
Edit.
Adding both CR and LF worked briefly then stopped and I can't get it to run again.
Puzzling.
Edit 2. Returning to Geoff's ASCII Terminal and away MMB4W goes, streaming the 16 bit packets at 30mS intervals.
Edited 2023-12-23 20:02 by phil99
Guru
Joined: 24/12/2017
Location: AustraliaPosts: 1638
| Posted: 09:53am 23 Dec 2023 |
This is what I am sending to the coms port from an MM2. There is a 10mS PAUSE between each message. It makes MMB4W crash every time when it is running this program:
OPEN "com3: 38400" AS #2
input #2, test$
print test$
CLOSE #2
input #2, test$
print test$
CLOSE #2
Trying other things may well produce other results but this particular sequence will crash MMB4W every time.
Bill
Guru
Joined: 11/12/2012
Location: United KingdomPosts: 10169
| Posted: 10:02am 23 Dec 2023 |
You are sending a continuous datastream at high speed and only doing a single read. With respect, this is a totally artificial situation which MMB4W doesn't handle - so be it.
Guru
Joined: 18/11/2011
Location: United KingdomPosts: 4022
| Posted: 10:15am 23 Dec 2023 |
Change test$ to (say) a$ - does it still crash?
John
Guru
Joined: 11/02/2018
Location: AustraliaPosts: 2543
| Posted: 10:22am 23 Dec 2023 |
Sending this from the MM2.
do:? "Hello from the MM2":pause 30:loop
to MMB4W works if via the ASCII terminal but not if sent via a CH340. In both cases TeraTerm receives the stream correctly.
Guru
Joined: 24/12/2017
Location: AustraliaPosts: 1638
| Posted: 10:29am 23 Dec 2023 |
Yes John, I tried that when the 'test' problem was found. It also works with a PAUSE 100 after the OPEN command - go figure?
It looks like this particular subject is closed now.
Thanks everyone for your interest and have a MERRY CHRISTMAS.
Bill
Guru
Joined: 24/12/2017
Location: AustraliaPosts: 1638
| Posted: 10:45am 23 Dec 2023 |
As my Irish friend would say "Well oil beef hooked".
I changed the delay from 10 to 30 and IT WORKS! At least from my MM2 with a Microbridge.
Thanks Phil.
Bill
Guru
Joined: 18/11/2011
Location: United KingdomPosts: 4022
| Posted: 12:42pm 23 Dec 2023 |
Looks like a bug, though.
I feel it should work (as in: not crash MMB4W) no matter how fast chars are sent to MMB4W and whether the receiving program can keep up or not.
John
Guru
Joined: 24/12/2017
Location: AustraliaPosts: 1638
| Posted: 11:12pm 23 Dec 2023 |
It is.
Bill