 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 : Micromite MMBasic Ver 5.05.02 Beta
  Page 3 of 4   |
|||||
| Author | Message | ||||
Turbo46 Guru  Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
I like lizby's proposal. Some versions of BASIC had the command: RUN [line #] Which could be useful to use after a RUNTO command if you want to just continue running your program. A subsequent RUNTO line# command could continue running from where the program stopped until it hits the next target line. Bill PS Geoff, You really should add a 'Donate' button onto your web page. It may allow you to buy more equipment or go on more holidays! Keep safe. Live long and prosper. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
simple enough; (?) report the line number when the user presses CTRL-C... something like "Break in 180" I have posted links on how to set up a paypal "tip jar". If just on your main page, it would take about 5 minutes to do (assuming you already have a paypal account - if not add another 5 minutes). You must be the busiest man on the red continent  |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3534 |
In that case the line number should mean something. A bit hard with a program that does not have line numbers. On the other hand, if you could (after CTRL-C) jump to the line (show program listing in LIST mode on the monitor, 10 lines before until 10 lines after the point where the BREAK happens...). My personal suggestion for added debug features (correct me if they are already existing, and I simply don't know). I would like to have a BREAK-INSPECT-CONTINUE possibility. In some systems that is done by placing a break point in the source code, and having a continue button in the IDE. While in BREAK mode you can check variables. Often combined with single step mode, so you can single step through the code. Single step allows for STEP-IN(also step into sub's) and STEP-OVER(execute the sub as a single step. This is a major change, and will definitely be too much for MMBasic (effort, but also code size). In my TinyBasic port I did for Arduino, I added (for debugging) following commands - HELP (list all the commands the interpreter understands, something like a mini MAN page in linux) - VARS (dumps all the variables and their current value...yes that can be a lot, so you need your scroll buffer on the terminal). - MILLIS x (fills variable x with the difference in time since the last MILLIS x. this can be used to check how long certain code takes to execute). - Control-C shows the line number where the break happens. Please note that Tinybasic only has 26 variables A-Z (16bit), line numbers, no editor..so retyping the line is the way of edit(*), no strings, no floating point. So what is practical there may not be in MMBasic. (*) actually you edit in notepad or similar and send the code through the serial port, in a similar way de MMBasic IDE works on the PC. This in no way helps defining new commands, but it may give idea's Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8584 |
I think the only things needed are a specific "BREAK" command and a single step mode (implied BREAK after every command). Both would be the equivalent of ctrl-C but in the program. AND, of course, CONTINUE needs to be fixed so it works properly under all circumstances. At the command line you can then inspect any variables using PRINT and issue the CONTINUE to move on (Function key short cut needed for continue) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3015 |
I would add very little to this. I would like to see "CONTINUE [FROM line#]" so that you can optionally restart from a different point. I have found this helpful when debugging VBA basic programs--but if it would add too much complexity, it could be omitted. And for BREAK, "BREAK line#1[,line#2[,line#3 ...]] [DISPLAY] [DELAY=milliseconds] where DISPLAY means show the reconstructed lines as they are executed, and DELAY specifies a delay between lines of some number of milliseconds. These could help a lot with the debugging of complex programs. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
GOTO target ? Micromites and Maximites! - Beginning Maximite |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Well bump it up! It is absolutely unfair that you should not be compensated for all of the brilliant work you have done with MMBasic! Huh .... you're already driving on the wrong side of the road, we're driving on the right side. Paul in NY |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
I think you would need to modify the RUN command by adding three parameters. RUN (delay nnn, [start at nnn, [run for nnn] ] ). RUN without parameters would function as it does now. RUN(100) would continue at the next line without clearing variables with a delay of 100 ms between lines. RUN(0) would continue at the next line with no delay. RUN(0,0,10) would continue at the next line with no delay for 10 lines. RUN(0,55) would continue at line 55. The third parameter would require counting lines from the restart point. Lexically it could completely replace both RUN and CONTINUE. Paul in NY |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
No. As it does today would be fine. The physical line number of the line in the program file. No need to (re)introduce numbers as labels. This is what error reporting does, so we already have the line number - just report it when the program is halted. |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
One change that I would like to see in MMBasic is to make OPTION EXPLICIT more explicit. By that I mean that the following: OPTION EXPLICIT DIM A, B, C Would be illegal. Currently the variables default to float but that may not be what the programmer intends. I have seen several instances of where a program starts that way but the program carries on to treat the variables as integers. I recall reading somewhere that Geoff said that using integers is about 25% faster than using floats and that may be significant. Consider loops that repeat many times. I believe that the type of variable should be declared when dimensioned: DIM INTEGER A, B, C or DIM FLOAT A, B, C Bill Keep safe. Live long and prosper. |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 844 |
OPTION DEFAULT NONE will achieve that. Compatibility with previous versions is probably why it not how you suggest. From the manual: If OPTION DEFAULT NONE is used then all variables must have their type explicitly defined.When a program is run the default is set to FLOAT for compatibility with previous versions of MMBasic. Latest F4 Latest H7 |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
Thanks disco4now, Yes, you are right of course, I guess I need to re-read the manual. Having said that, maybe I'm a little pedantic but I would still like to see OPTION EXPLICIT work that way. It just seems a bit wrong to me to have to declare a variable without having to declare it's type. Bill Keep safe. Live long and prosper. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
the trick would be to have an option more extreme than just 'explicit': OPTION VERY EXPLICIT just to be on the safe side, when invoked this option should generate a warning message to the user. cheers, rob :-) |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
Perhaps the warning could be avoided by the user having to explicitly specify the level of expicitness: OPTION EXPLICIT (arg) where arg could be A, R or X. Where X is the most extreme. That was meant to be a serious suggestion Rob. Bill Keep safe. Live long and prosper. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
you make a good point Bill, an even higher level of explicitness may also be warranted: OPTION EXTREMELY EXPLICIT this would require all variable declarations be confined to a seperate section at the beginning of the program. and lower-case letters being prohibited. cheers, rob ;-) |
||||
KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1363 |
I'm not sure if this is the right place for this but here goes: The description of Ghost text is different from what I'm seeing, I just wanted to confirm which is correct as I'm running this on a ARMmite H7 and the MM.basic version is 5.0503. I don't have an MM+ to test this on but from memory it was the same the last time I tried it. From the MMBasic Ver 5.05 Manual: [quote] The value of the control can be set to a string starting with two hash characters (##) and in that case the string (without the leading two hash characters) will be displayed in the box with reduced brightness. This can be used to give the user a hint as to what should be entered (called "ghost text"). Reading the value of the control displaying ghost text will return an empty string. When a key is pressed the ghost text will vanish and be replaced with the entered text. [/quote] Reading the control displaying ghost text "##Enter Text" returns "##Enter Text" Pressing Can returns Ent to MM.KEYPRESS and the on-entry control value is returned, which all seems fine to me. I though I'd bring this up incase the manual needs to be changed? OR the behaviour I'm seeing is incorrect and is confined to the A-H7. BTW It has no impact on the program itself, just a discrepancy between code and user manual. Mike. It's all too hard. Mike. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
That is not right. It should read as an empty string - I will check on an MM+ to verify that. EDIT: A thought has just occurred to me. Is that inside a MM.KEYPRESS sub? If so, see my answer below. That is working correctly. I have been struggling with a number of issues with MM.KEYPRESS and have come to the conclusion that I will have to remove this feature in future versions. The original idea of MM.KEYPRESS was that you could use it for inputting formatted data like date/time and GPS coordinates but a specialised input box just for these types of input would be much easier to use and render MM.KEYPRESS redundant. Geoff Geoff Graham - http://geoffg.net |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1363 |
Thanks Geoff, yes inside MM.KEYPRESS. I've had many issues with MM.KEYPRESS over the years but they have been mostly resolved with the last MM.BASIC updates, at the moment it's working fine, however a dedicated control as you mentioned may be the way to go, the biggest trap is the difference in control returned values between inside and outside of MM.KEYPRESS, and some control close timing issues, both obviously when in edit mode. The ARM-H7 has enough room for me to make a multiline edit textbox which is what I really need anyway for some CNC type projects. Mike. It's all too hard. Mike. |
||||
| PicFan Senior Member  Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hello Geoff! I have a small problem with the version V5.0502 and MKII, or am i doing something wrong ? But an example says more than many words. OPTION DEFAULT INTEGER PRINT MM.VER PRINT MM.DEVICE$ DO DO WHILE(fTest()=0) PRINT "X" PAUSE 500 LOOP PRINT "A" PAUSE 500 LOOP FUNCTION fTest() TIMER = 0 PRINT "F1" 'DO WHILE(TIMER < 5):LOOP fTest = 0 '************** PRINT "FT="fTest END FUNCTION RUN 5.0502 Micromite MkII F1 '1 function call - OK, then print "X" ! FT= 0 X F1 FT= 0 X . . . . All OK, but now we change fTest = 1 '************** RUN 5.0502 Micromite MkII F1 FT= 1 F1 'WHY 2 FUNCTION CALLS before "print "A"? FT= 1 A F1 FT= 1 F1 FT= 1 A We change fTest = 0 '************** and uncomment DO WHILE in the function. RUN 5.0502 Micromite MkII F1 FT= 0 X [10] Loop Error: LOOP without a matching DO We change fTest = 1 '************** and uncomment DO WHILE in the function. RUN 5.0502 Micromite MkII F1 [20] fTest = 1 Error: A sub/fun has the same name: FTEST Please help, thank you and best regards ! Wolfgang P.S.: Same result with V5.0501 and V5.0408. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8584 |
I can confirm the findings on MMX. Certainly looks like one or more bugs in the handling of "DO WHILE" "LOOP". I'll email Geoff to make sure he sees the thread |
||||
| Page 3 of 4 |
|||||
 Print this page |
