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.


Jim

TEST maybe in the source as a command.
LIST FUNCTIONS works OK.
LIST COMMANDS does not come back.

b23


MMBasic.zip


Removes the command TEST and fixes LIST COMMANDS

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.


This program now prints nothing as if test$ is empty.


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

I gave up on INPUT$(), INPUT works ok.
Yes, it is very easy to make MMB4W crash.

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

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.

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.

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

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

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

Hi

I can't get mode 16 to work. Nothing on the screen.
Mode -16 & rest seem OK.
Am I missing something?

Brian

  TassyJim said  

It might depend on the make of USB TTL converter, just to make life interesting.

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

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:



Trying other things may well produce other results but this particular sequence will crash MMB4W every time.

Bill

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.

  Turbo46 said  

It makes MMB4W crash every time when it is running this program:

OPEN "com3: 38400" AS #2
input #2, test$
print test$
CLOSE #2

Change test$ to (say) a$ - does it still crash?

John

Sending this from the MM2.

to MMB4W works  if via the ASCII terminal but not if sent via a CH340. In both cases TeraTerm receives the stream correctly.

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

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

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

  Quote  

Looks like a bug, though.

It is.

Bill