 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 V5.3 Beta 3
  Page 2 of 3   |
|||||
| Author | Message | ||||
| WhiteWizzard Guru  Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Geoff, Suggestion for MM+. IF you don't set OPTION SDCARD, but type FILES, then you get the message: 'Error: Cannot access the SD card' Can this please be changed to something like: 'Error: SD card not configured' This will massively help when configuring E100s, and also bring it in line with the other Error messages such as LCDPANEL and TOUCH. WW |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Good point. OK, will do. Geoff Graham - http://geoffg.net |
||||
| ajkw Senior Member  Joined: 29/06/2011 Location: AustraliaPosts: 290 |
In regards Clocktrim. Perhaps show the Clocktrim value in Option List Might be useful when trying to trim over a long period and remembering the value previously set. I am about to test but does anyone know a value to correct for a gain of a minute per day? Anthony. Edit, I presumed this was a Console Option, it seems it needs to be set in a program. Question stands, does anyone know a value to correct for a gain of a minute per day? |
||||
redrok Senior Member Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi ajkw;I don't think you will get that amount of precision. Since there are 1440 minutes / day. +-12.5% is about +- 180 minutes. With a resolution of +- 31 steps this would be about +- 6 minutes per step. This is clearly good enough for normal functions including baudrate. Just not so good for precision time clocks. If you need a good time clock add one of the i2c clock chips. I use the 8563 with 32k crystal and 20pF variable cap. I can trim it to about 1 second per day. BTW, this trimming is not easily done without a good frequency counter. I calibrate my counter watching the 1 pulse per second on a GPS receiver. redrok |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Thanks redrok, I was mulling over the numbers whilst getting on with other things last night and they were going the way you outlined. Am familiar with RTC's. I was one of the first to put a DS1302 in a Maximite back in 2011. Details are in these forums. anyway getting off topic now.. Cheers, Anthony. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
found an interesting 'bug' in integer support this afternoon, that was messing up some GPS result by just a fraction (about 20 metres). try out the following code: a$ = "4342.4026,etc" ' the original sentence b$ = "4342" ' integer part c$ = "4026,junk" ' fractional part + rest of sentence d$ = "4026,S,17239.0" ' fractional part + rest including a "." Print (Val(b$)*10000)+Val(c$),(Val(b$)*10000)+Val(d$) i%=(Val(b$)*10000)+Val(c$) j%=(Val(b$)*10000)+Val(d$) Print i%, j% > run 43424026 4.34240e+07 43424026 43424024 > notice the small difference (2) between the values on the 2nd line of output? the intention of the code was to use a 64-bit integer to store latitude/longitude in units of 1/10000th of a degree. the problem is that while VAL() evaluates up to the first non-numeral character, it bases the type returned upon the presence of a decimal point, even if this decimal point is outside of the numeric characters being converted. i believe this is an error, as non-evaluated characters are having an effect on the type of result returned (but not upon the value. note that i am very happy that VAL() does evaluate up to non-numeral without error - this is extremely useful behaviour, particularly in splitting up comma delimited NMEA sentences coming from a GPS receiver. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
rob, Does Print val(d$) show 4024? It looks like a bug (either way) and I expect Geoff will fix it if he knows about it. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
no, it prints "4026". the numeric results for each individual part are correct, the error is in they type of the result - something like "4026,." returns a result of type float, whereas it should (i believe) return a result of type int64 as evaluation never proceeds past the comma. the problem can be resolved by using INT(VAL("4026,.")), which appears to force the type to int64. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
hmm.... Traditionally the type of VAL is floating point (of whatever kind). Might need a VAL% function... (Otherwise the person using MMBasic may need to go back to thinking about the way fl pt behaves!) John |
||||
| redrok Senior Member Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi robert & John; I agree with John that traditionally VAL evaluates to a float. Even when forced to be an integer it still retains the 24bit fractional resolution, albeit with extra junk characters beyond the 24bits. Part of the problem robert is having is due to the Multiply in the math. The multiply forces the answer to be related to a float. I have been working on some high precision fixed point math routines all done using only hexadecimal add, subtract, and shifts. I am implementing both multiply and divide but there are no multiply nor divides being done. Anytime a float type math operation is done you can't expect there to be 64bit answers, only 24bit type answers. I would like to see johns VAL%() function as this would be quite useful for 64bit integer calculations. Since I have been working with fixed point there is a need to have a second VAL function that works with the fractional part. Possibly: VALFRAC%() I have no idea if this is generally useful though. BTW, one of the best calculators on the net I have found is: Big Number Calculator. This works much better than the Microsoft calculator as it uses and displays HEX bignums including the fractional part. redrok |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Rob, From your code above that produces the four numbers, are you saying that the bottom right number should be 43424026, and not 43424024; and hence the 20metres inaccuracy? I have just run the code on a MicroMite Extreme and the bottom right number is indeed 43424026  I know Peter has been working on increasing accuracy, and hence my question above! WW |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
I think it is all to do with VAL() being floating point and not the stray decimals in the string. VAL(c$) and VAL(d$) are equal. Jim VK7JH MMedit |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Jim, I think that's right and it's not a bug but rather a behaviour that happens to be revealed by the code fragments. I suppose it can be avoided by using integer variables and doing the addition with two of them, along the lines of: i%=VAL(b$)*10000 i2%=VAL(c$) i%=i%+i2% j%=VAL(b$)*10000 j2%=VAL(d$) j%=j%+j2% (i.e. as you also said) It's not very intuitive, though. John |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 767 |
Micromite User Manual Ver 5.3 beta 3 (Page 5)... I was reading this summery and got the impression that you could use a 44 pin part with the USB option and use it as a console port... Isn't USB only supported on the 470 class MM's..? If so, then, maybe take this out, as it could give newbie's the wrong idea when ordering parts... Of course, I could be totally wrong also..!!  |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Hi Zonker Something like this may be better  : |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
OK, I will update the wording. Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
would have to disagree. here is a simpler example: c$ = "4026,junk" d$ = "4026,more.junk" Print Val(c$)*10000, Val(d$)*10000 > run 40260000 4.02600e+07 > the two results should be of identical format. one may argue as to weather both should be int64 (left) or scientific/float (right), but it still remains that the output sent to the console should be the same. various other punctuation characters beyong the comma seem to also affect the result type of VAL(). if the result type of VAL() is fixed as always being float, then an argument could be made for adding a new function VAL%() that always produces int64 results. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
If its type varies then that's not good and the VAL% I suggested looks to be needed - with VAL to be changed so as NOT to vary in return type. Yeah... I reckon it's in effect a bug. This sort of problem would not normally affect any BASIC as they don't have an integer type that can represent more integers than the floating point (aka real/double) type. (Usually the floating point type can represent - exactly - more integers than the integer type, where the BASIC has an integer type. I know, a bit odd.) John |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Further investigation does show the problem. If there is a decimal anywhere in the string, the number is treated as a float. It is seen better with numbers with a lot of digits: The solution is to trim the string before evaluating. Jim edit: MMBasic looks for a decimal or an 'E' to determine if the number is a float so the above example doesn't need the decimal. the 'e' in 'more' is enough to result in a float. VK7JH MMedit |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
I will have to think about this one. VAL() does search for a '.' or 'E' and uses that to tell if it needs to convert the number as a float. The solution will be to first determine the end of the number before doing the search. This adds some complexity but might be simpler than creating a new function such as VAL%(). Geoff Geoff Graham - http://geoffg.net |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
