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 : New Version: Micromite MMBasic Ver 5.05.02
Page 1 of 2 | |||||
Author | Message | ||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I have a new version of MMBasic for the Micromite and Micromite Plus. It is Ver 5.05.02 and you can download it from here: http://geoffg.net/micromite.html This version incorporates all the changes/fixes in the previous series of beta releases (the Change Log runs to 2 pages). New features include an optimised storage of the program in flash so that larger programs can be loaded, the ability to remove comments and unnecessary text when the program is loaded, a new GUI control for the Micromite Plus and general small improvements. Also, all known bugs have been fixed. Check the Change Log for the details. Geoff Geoff Graham - http://geoffg.net |
||||
Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Got it! Thanks Geoff! You managed to squeeze the DOS executable down by 11KB while adding quite a bunch of goodies and without deprecating very many older "features". My initial tests indicate that it is about 7% faster. Paul in NY |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
Geoff, The version on your web site appears to be the same as the version posted on 18 July, ie. version 5.05.02 Beta 6. Is the new version you refer to above beta 7 and if so, are you planning on updating your web site? Thanks again for the terrific work on producing MMBasic. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Panky, I think that you need to clear your browser cache as my website now lists V5.05.02 (not a beta version). This version is essentially the same as the last beta version (beta 6) with a few additional tweaks and a lot of testing. Geoff Geoff Graham - http://geoffg.net |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
Cheers Geoff, Sorry for wasting your time panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
PicFan Senior Member Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hello Geoff! Thank you for your effort. The Micromite is for me as a hobbyist, the best you can wish for. A minor typo is on page 66, which is missing "O" for Option Explicit. Thanks again and best regards! Wolfgang |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Thanks Wolfgang. I will update it. Geoff Graham - http://geoffg.net |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3496 |
Dear Geoff, In my effort to port my software from the MX170 to an ARMmiteF4 (MM+ based) I stumbled upon a language difference between MM2 and MM+ that I feel would not be needed. Why do we use Setpin no, INTL, MyInt in MM2, and GUI Interrupt in MM+. That is only confusing. Maybe that is a language difference that can be omitted in a new release. I understand the MM2 version is universal (for any interrupt) but it must have do something special to prevent double asignment (option and basic program). The MM+ has (in stead of the special exclusion) a specific command for this one special interrupt. Both cases do something special, maybe one of them could be the standard. Regards, Volhout Edited 2019-10-03 04:58 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Yes Volhout, a good point. In the interpreter they work completely differently but the programming interface should be the same. I will look into it in a future release. Geoff Geoff Graham - http://geoffg.net |
||||
piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Greetings Geoff ! Just a couple of points with 5.05.02, so far: - In Version.h, line 120, it should read: #include "MMBasic/MMBasic_Includes.h" instead of: #include "MMBasic\MMBasic_Includes.h" Else, it fails to compile under anything but Windoze... :-P - When I loaded the project, MPLAB X IDE (v4.15) complained that the said project was created with a newer IDE and warned that importing it could result in failures (the only failure I noticed was a bogus "???" name for the project in the v4.15 IDE "Projects" tab). However, the README.txt file still mentions MPLAB X IDE v3.65 as your build system... Perhaps should you quote your actual current IDE version. Note that last time I tried to use a v5 IDE (a few months ago), I had to revert to v4.15 since v5 did not work at all under Linux (or at least under my Linux distro: PCLinuxOS); I might have another try at v5, time permitting (but since v4.15 works beautifully, I really don't feel compelled to try and update). |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
Hi geoffg I have a small problem I use an gps chip and I write prog to use this gps on mx170 (or mx470) with v5.05.2 my problem is that some cases, prog spend time is too long (where??) normal main prog is executed in 150 to 200ms, but some times it is executed in 600ms see capture screen Run 19:44:58 -> 0.120 19:44:59 -> 0.172 19:45:00 -> 0.172 19:45:01 -> 0.172 19:45:02 -> 0.616 19:45:03 -> 0.616 19:45:04 -> 0.616 19:45:05 -> 0.616 19:45:06 -> 0.616 19:45:07 -> 0.571 19:45:08 -> 0.173 19:45:09 -> 0.173 19:45:10 -> 0.173 19:45:11 -> 0.174 19:45:12 -> 0.173 19:45:13 -> 0.173 19:45:14 -> 0.173 19:45:15 -> 0.650 19:45:16 -> 0.173 19:45:17 -> 0.582 19:45:18 -> 0.173 19:45:19 -> 0.173 19:45:20 -> 0.605 19:45:21 -> 0.649 19:45:22 -> 0.173 > do you know what?? my prog rec_gps_ref.zip Edited 2019-10-07 03:54 by goc30 |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
The first question is... does the timing change between V5.05.01 and V5.05.02 ? It should not because there are no timing differences between the two versions. Secondly, looking through your program... you have two interrupts running simultaneously. One is getting characters from the GPS and is controlled by the baud rate. The other is the one second timer that you use for decoding the GPS data - this will take a lot of time to execute depending on the GPS data accumulated. You are timing the loop which waits for first interrupt and its elapsed time will depend on exactly when the one second timer fired. If it fired while your program was waiting in the first loop you can expect that loop to take extra time. This is all normal and a consequence of how your program is structured. If I were you I would scrap the one second timer and decode the GPS data immediately a full record was accumulated. Geoff Geoff Graham - http://geoffg.net |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
no there is no change. In fact, it is an old problem . the problem is the same with or without the second interrupt "top1sec". In fact I do not understand why most of the time the execution is done quickly and why sometimes and in a random way, the time becomes too long. as I had a doubt about the sending of the GPS frames, I made a small prog on a second mx170, simulating the GPS. In this case, the simulator always sends the same frames and with the same timing. But I still have my problem of random execution time simul_gps.zip |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
this is what I begin to do, and it is worst!! in this program, I spend minimum time to receive and only store in round stack after, in main module, i verify crc and store in dedicaced table. If I read time in main module without decoding frame, it is small beter, but I have always random timing timing In addition, given the operating mode of the basic (interpreted), each line (even comments) lengthens the execution time. That's why the program under port interuption must be the smallest possible and the shortest in execution time with this prog ,minimal versus with only 1 interrupt, you can see that the problem persists test_gps_rec5.zip 'with real gps module Run 'execution time in main (if >50ms) 09:58:00 -> 0.122 09:58:01 -> 0.601 <--- 09:58:02 -> 0.124 09:58:03 -> 0.124 09:58:04 -> 0.124 09:58:05 -> 0.124 09:58:06 -> 0.125 09:58:07 -> 0.601 <--- 09:58:08 -> 0.124 09:58:09 -> 0.124 09:58:10 -> 0.562 <--- 09:58:11 -> 0.124 09:58:12 -> 0.593 <--- 09:58:13 -> 0.124 09:58:14 -> 0.125 09:58:15 -> 0.124 09:58:16 -> 0.592 <--- 09:58:17 -> 0.123 09:58:18 -> 0.123 09:58:19 -> 0.124 09:58:20 -> 0.558 <--- 09:58:21 -> 0.596 <--- 09:58:22 -> 0.125 09:58:23 -> 0.565 <--- 09:58:24 -> 0.125 > |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I'm sorry goc30 but I just don't have the time to debug and rewrite user's programs online. Also, this thread is about MMBasic V5.05.02. You should start a new thread. Geoff Graham - http://geoffg.net |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
I'm just a little disappointed by your answer, which implicates the programmer, while obviously the problem is mostly structural in using MMBasic 1 - my program is correct and contains no bug. In addition it has been over a week that I am on this problem with several versions of my program to understand where the delay comes. 2 - I'm not even sure you have to watch my latest program 3 - I am in computers (hard ans soft) for more than 40 years and specialized in real time industrial computing. As such I have already installed, for example, master and slave Modbus protocols on different platforms and in several languages In addition GPS management is also one of my specialties, especially in car racing, where the milliseconde is important. so I know very well how to program a software exchange in interrupt mode 4 - rather than immediately questioning the programmer, I would have preferred you to explain why the basic interpreter loses so much time managing an interruption. I say that in 9600bds, each character is received approximately every millisecond, and a millisecond with a mx170 is 40 000 machine instructions. I understand that the basic interpreted is slower than a basic compiled, but in the case of MMbasic, it seems that it is much much slower to the point of making some tasks impossible, or certain functions such as "goto" whose Execution time is dependent on the number of lines (including comments) between the goto and the destination line. so dorenavent, when I need consistency and reliability, I would take another system, faster (even on an arduino 16 Mhz) and more precise, and I use Mbasic only for smalls no importants software. Edited 2019-10-08 04:22 by goc30 |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3649 |
That may mean it's one of: 1. a bug in goc30's program or understanding of it / its output 2. a bug in MMBasic 3. both The usual practice (virtually a rule) is that the programmer (here, goc30) provides a small test program to demonstrate that it is item 2 above. This has been done numerous times with other problems. Whether the posted BAS files qualify is up to each person I suppose but for me they're too big and complex plus require hardware etc that many won't have. Anyone want to duplicate the problem / explain it / provide a simpler test program... John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
This is NOT a bug in MMBasic. It is a natural consequence of how the BASIC program was written. Start a new thread, don't hijack this one. Geoff Geoff Graham - http://geoffg.net |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
my prog minimal for testing you can see that I use only 1 main loop and 1 subroutine in interrupt mode, nothing else! Option EXPLICIT 'option autorun on Const cnbbuf = 10 Dim i As integer dim j as integer dim txt as string dim v1 as float Dim ptime1 As float Dim ptime2 As float Dim tmbuf(cnbbuf) As string dim flgtmbuf(cnbbuf) as integer Dim ptWrite As integer Dim ptRead As integer Dim txbufgps As string dim flgf as integer dim nbcar as integer txbufgps="" flgf=0 Open "COM1:9600,255,spcomrec4" As #2 ptWrite=0 ptRead=0 for i=1 to cnbbuf tmbuf(i)="" flgtmbuf(i)=0 next i '***************************** do ptime1=timer for i=1 to 20 for j=1 to 10 txt="bonjour" v1=(3.14159/5.2)*3.7 txt="" next j next i ptime2=timer if ptime2-ptime1>50 then print "time";str$((ptime2-ptime1)/1000,4,3);" nb char=";str$(nbcar) nbcar=0 end if pause(100) loop '***************************** sub spcomrec4 Local tx$ As string 'length 3 Local i1 As integer Local i2 As integer Local a$ As string length 1 local vai as integer i1=Loc(#2) if i1=0 then exit sub else tx$=Input$(i1,#2) nbcar=nbcar+i1 print i1 'i1=number of char in receive buffer '----------- mark1 loop storing data For i2=1 To i1 a$=Mid$(tx$,i2,1) vai=asc(a$) if a$="$" then ptWrite=ptWrite+1 if ptWrite>cnbbuf then ptWrite=1 tmbuf(ptWrite)="" flgtmbuf(ptWrite)=1 end if if vai=10 then flgtmbuf(ptWrite)=2 else if vai>31 then tmbuf(ptWrite)=tmbuf(ptWrite)+a$ end if next i2 '---------- mark2 end loop end if end sub in this program, I print number of char receive in each interrupt, and execut time of main loop with number of total chars receives result give that (extract) 4 3 4 4 4 4 4 time 0.568 nb char=485 time 0.059 nb char=0 time 0.059 nb char=0 you can see that each interrupt receives 4 characters at once, which means that it executes in 4ms. if I erase code between 2 marks (loop storing data) result is best 1 2 1 1 1 1 time 0.581 nb char=500 time 0.059 nb char=0 each interrupt receive only 1 char. it read but not store. It mean that loop storing data work during 3 ms (this code is very simply and normaly can't use this time). This is THE problem, it is too long I leave you to imagine the time that would take an interruption if I had followed the advice of geoffg who asked to emerge a maximum of treatment in the interruption for info, in ASM or in "C" this loop on pic32mx take some micro-seconds not 3 ms Edited 2019-10-08 09:13 by goc30 |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
This is an problem in MMBasic and MMBasic Plus v5.5.02 and I am in good thread who speak about MMbasic v5.5.02 problems p.s. I never say that it is a bug. I just say that it is a problem, and I would like understand why it spend too many time to execute an simply small interrupt uart subroutine Edited 2019-10-08 09:23 by goc30 |
||||
Page 1 of 2 |
Print this page |