 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 : MM/MMX: Parser issue with variable names
| Author | Message | ||||
| BrantB Newbie  Joined: 27/10/2017 Location: CanadaPosts: 40 |
As I have said before, I really am not looking for problems. But I can't help it when I trip over something.  It seems that variable names which begin with the term TIMER may actually be interpreted as the TIMER itself. For instance, the variable called TIMER_INTERVAL seems to cause an issue. Below is some simple code to demonstrate. OPTION EXPLICIT ' Declare the variable to hold the desired TIMER trigger value DIM TIMER_INTERVAL AS INTEGER ' Reset the variable to 0 (zero) TIMER_INTERVAL = 0 ' Reset the TIMER to 0 (zero), and pause for a bit to guarantee ' that it will be >0 when the main loop starts TIMER = 0 PAUSE 1 DO ' If the TIMER trips past the pre-set trigger value, print the ' current TIMER and variable values to the Console, and advance ' the trigger value to the next interval (i.e., plus 5 seconds) IF TIMER > TIMER_INTERVAL THEN TIMER_INTERVAL = TIMER + 5000 PRINT " TIMER: "; TIMER PRINT "Variable: "; TIMER_INTERVAL END IF ' Do this nonsense for 30 seconds (30,000ms) LOOP UNTIL TIMER > 30000 END What should happen, is that the current values (of TIMER and the corresponding trigger variable) should print to the Console every 5 seconds (roughly). Instead, it seems the actual TIMER is erroneously being advanced by 5000, and the variable is not getting touched at all ... causing the loop to whiz to completion without any delays. If I change all of the variable references from TIMER_INTERVAL to any of the following variants (or, I suspect, anything else which does not begin with the character sequence "TIMER"), the problem goes away: T1 T_1 _TIMER_INTERVAL (the initial underscore makes the difference) On the other hand, if I just change it to TIMER1 (or, indeed, several other variations I tried which all began with "TIMER"), the issue still occurs. I can tell you that this is the case for MM v5.0409 (beta 12) on a PIC32MX170F256B, and for MMX v5.0414 on a PIC32MZ2048EFH100. However, the same code does run just fine in MM v5.0405 (on the MX170). So, it looks to me like something unintentional happened to the parser, sometime between v5.04.05 and a newer subversion (I don't know precisely which subversion was the actual birthplace of the gremlin  ).I think this one may be an investigation for @Geoff, with @matherp to play catch-up incorporating it into the next aligned release of MMX. (At least, that's what I suspect, if I am correctly grasping the way development is carried out.) Cheers, Brant |
||||
| WhiteWizzard Guru  Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Hi Brant, It is not wise to use variable names that begin with a 'Keyword' (i.e. a command or function, or a label-name). Just looked for this 'warning' in the MM User Manual but cannot see it straight away. IF you want to use a similar name to aide with reading your code then use a lower case prefix. I often use 'ww' so hence your above example for me would be written as wwTIMER_INTERVAL The above technique then does not confuse the parser (and I believe you were lucky it ran on one version of MMBASIC) |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@WhiteWizzard, Okie doke - noted. Your approach is interesting; thanks for the tip. I guess I was a victim of circumstance. I started off (several months ago) experimenting with Micromite on an MX170 (DIP-28), and at that time, I didn't run into any issues with the TIMER_INTERVAL variable name. More recently, I managed to get an MMX rig (100pin MZ) up and running ... and then ended up spending some time chasing down some strange behaviour in a couple of my programs. Of course, given that I am still coming up to speed on MM/MMX, I naturally figured it was something I had done wrong. I narrowed it down to what I described above ... but, didn't feel comfortable just taking the easy road and posting a "problem" right away. So, I dusted off some other firmware to at least confirm that it had not previously been an issue. Given that I was so lucky in the first place, I wish I had bought a lottery ticket back then, too!  Cheers |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
While I do use some programming languages that do not allow user variables to begin with a keyword, MMBasic is (or was) not one of them. That pain is usually reserved for languages that don't recognise spaces. I have tried with a few other keywords without any problems. I tried CPU_INTERVAL PRINT_INTERVAL PIN_INTERVAL The only one that shows a problem is TIMER_INTERVAL I do think that you have found a bug. Jim VK7JH MMedit |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Yes, it is a bug and I can see what is causing it. Give me a day and I will put the fix into the 5.04.09 beta and report back. Thanks for the report. Geoff Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
That explains why I couldn't see it in the manual!  Even though it has been confirmed by Geoff and Jim that it is ok to use command/function names at the start of variable names; I personally will still use a prefix to make it 'stand out' clearly. Note that Label names did cause an issue at the start of variable names but I believe Geoff has looked into better parsing since it was last discussed on this forum. So not sure if Label-names are still not allowed at start - something to test later today . . . |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
I have fixed this bug and you can download the latest beta version with the fix from: http://geoffg.net/Downloads/Micromite/Micromite_V5.04.09_Beta.zip Thanks Brant for finding it and please keep looking for any more (even if you are not!). Any bug reports are gratefully received. Peter: in the function tokenise() in the file MMBasic.c look for the line: if(*tp == 0 && (!isnamechar(*tp2) || (commandtbl.type & T_FUN))) { and add this line immediately following: if(*(tp - 1) != '(' && isnamechar(*tp2)) continue; // skip if not the function Geoff Geoff Graham - http://geoffg.net |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
Tested ... and working just fine (at least on the 28 pin MX170). Thanks for the quick fix. And, yes, I will continue to report things if/as I come across them.  As I become more and more confident in my understanding of, and abilities with, the MM family, I look forward to being able to contribute by helping others and answering questions (based on experience). In the meantime, I will make my contribution by shining a light on previously undiscovered "features". Cheers! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
As per post on other thread - YES, this really helps. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
