 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MMBasic for Windows - betas
  Page 29 of 30   |
|||||
| Author | Message | ||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5910 |
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 Jim VK7JH MMedit MMBasic Help |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 844 |
TEST maybe in the source as a command. LIST FUNCTIONS works OK. LIST COMMANDS does not come back. Latest F4 Latest H7 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
b23 MMBasic.zip Removes the command TEST and fixes LIST COMMANDS |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
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 This program now prints nothing as if test$ is empty. OPEN "com3: 38400" AS #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 Keep safe. Live long and prosper. |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1790 |
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 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 |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
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. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1790 |
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. |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
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 Keep safe. Live long and prosper. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5910 |
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 VK7JH MMedit MMBasic Help |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5910 |
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 VK7JH MMedit MMBasic Help |
||||
Chopperp Guru Joined: 03/01/2018 Location: AustraliaPosts: 1032 |
Hi I can't get mode 16 to work. Nothing on the screen. Mode -16 & rest seem OK. Am I missing something? Brian ChopperP |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1790 |
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 |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
 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 Trying other things may well produce other results but this particular sequence will crash MMB4W every time. Bill Keep safe. Live long and prosper. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
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. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
Change test$ to (say) a$ - does it still crash? John |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1790 |
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. |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
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 Keep safe. Live long and prosper. |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
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 Keep safe. Live long and prosper. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
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 |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
It is. Bill Keep safe. Live long and prosper. |
||||
| Page 29 of 30 |
|||||
 Print this page |
