Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 02:28 20 Apr 2024 Privacy Policy
Jump to

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: Australia
Posts: 3165
Posted: 09:40am 01 Oct 2019
Copy link to clipboard 
Print this post

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 States
Posts: 769
Posted: 02:51pm 01 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 1094
Posted: 11:58pm 01 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 01:53am 02 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 1094
Posted: 02:00am 02 Oct 2019
Copy link to clipboard 
Print this post

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: Austria
Posts: 133
Posted: 10:03am 02 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 01:14pm 02 Oct 2019
Copy link to clipboard 
Print this post

  PicFan said  A minor typo is on page 66, which is missing "O" for Option Explicit.

Thanks Wolfgang.  I will update it.
Geoff Graham - http://geoffg.net
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3496
Posted: 06:54pm 02 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 12:01am 03 Oct 2019
Copy link to clipboard 
Print this post

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: France
Posts: 134
Posted: 12:45pm 06 Oct 2019
Copy link to clipboard 
Print this post

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: France
Posts: 425
Posted: 05:50pm 06 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 09:59pm 06 Oct 2019
Copy link to clipboard 
Print this post

  goc30 said  I have a small problem


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: France
Posts: 425
Posted: 02:39am 07 Oct 2019
Copy link to clipboard 
Print this post

  Geoffg said  

The first question is... does the timing change between V5.05.01 and V5.05.02 ?
Geoff

no there is no change. In fact, it is an old problem
.
  Geoffg said  
Secondly, looking through your program... you have two interrupts running simultaneously.  

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: France
Posts: 425
Posted: 08:05am 07 Oct 2019
Copy link to clipboard 
Print this post

  Geoffg said  

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

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: Australia
Posts: 3165
Posted: 11:19am 07 Oct 2019
Copy link to clipboard 
Print this post

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: France
Posts: 425
Posted: 06:14pm 07 Oct 2019
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 3649
Posted: 08:37pm 07 Oct 2019
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 10:11pm 07 Oct 2019
Copy link to clipboard 
Print this post

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: France
Posts: 425
Posted: 11:10pm 07 Oct 2019
Copy link to clipboard 
Print this post

  JohnS said  That may mean it's one of:

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.


John


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

  Geoffg said  
If I were you I would scrap the one second timer and decode the GPS data immediately a full record was accumulated.


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: France
Posts: 425
Posted: 11:15pm 07 Oct 2019
Copy link to clipboard 
Print this post

  Geoffg said  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


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
© JAQ Software 2024