Home  |  Contents 

Microcontroller and PC projects
  Forum Index : Microcontroller and PC projects         Section
Subject Topic: Micromite MMBasic Ver 5.04.10 Beta 1 Post ReplyPost New Topic
Page of 2 Next >>
Author
Message << Prev Topic | Next Topic >>
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2349
Posted: 05 July 2018 at 3:34pm | IP Logged Quote Geoffg

As promised, I have a new beta version of the Micromite firmware which fixes some of the things that did not make it into V5.04.09. You can download it from: http://geoffg.net/micromite.html

The idea of the beta versions is to test new features and bug fixes that have the potential break something else within the interpreter. I will keep updating the beta version until it is stable and then make it into a final release. If you find any issues or bugs in this beta please report them in this thread and I will try to fix them ASAP.

New in this version (compared to V5.04.09) is:
- Further optimised the internal memory management. This improves the speed of string operations by up to 10% over and above the considerable speed improvement already in V5.04.09.

- When pressing the enter key (Ent) on a GUI NUMBERBOX the resultant number displayed will be automatically formatted with the same number of digits after the decimal point as the number entered using the keypad.

- Fixed a number of bugs which caused the CtrlVal() function to return an incorrect value for a NUMBERBOX or TEXTBOX when called from within the MM.KEYPRESS subroutine. I must have had a very "bad hair day" when I originally coded this function.

- As part of the above fix CtrlVal() will always return a floating point value for NUMBERBOX - even within the MM.KEYPRESS subroutine (previously it was documented as returning a string inside this sub).

I have tried to reproduce the bug reported by Mike (KeepIS) where a GUI NUMBERBOX would crash MMBasic when a SETTICK timer was also running. It seems to work fine for me so if you see this Mike I would be grateful if you could test this beta version - maybe I accidentally fixed the issue while working on the MM.KEYPRESS issues.

Next on the list is to revise the TEXTBOX keyboard layout for Grogster.

Geoff




Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
panky
Guru
Guru
Avatar

Joined: 02 October 2012
Location: Australia
Online Status: Offline
Posts: 510
Posted: 06 July 2018 at 1:14pm | IP Logged Quote panky

Geoff,

The CtrlVal issue in NUMBERBOX that I highlighted has been fixed - thanks. Not sure about KeepIs's problem with timer interaction as I am unable to test that.

Cheers,
Doug.


__________________
DonTSM1,Duinomite,CGCMM1,CGCMM2,2xDimitech,3xWWuMites,MicksMuP,Grogster1A,4xPeterMuM+,Zonker DIP-600,3xCGuKits,CGuBoard2,SnadPic100,SCBP64 & Exp100,PMMZ144,PMMZ100 .. and loving it![:D
Back to Top View panky's Profile Search for other posts by panky
 
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 547
Posted: 06 July 2018 at 7:57pm | IP Logged Quote CaptainBoing

Hi Geoff.

could I ask you to consider an enhancement for the RTC command to harmonise the operation of the two counterpart RTC commands in that they both work with the date/time system values?

when setting the time, could it be that if you don't specify the argument string, SETTIME takes the current DATE$ and TIME$ values?

when setting the RTC under software it is a chunk of code to split out the values so currently, we have to:

RTC SETTIME VAL(RIGHT(DATE$,4)), VAL(MID$(DATE$,4,2)), VAL(LEFT$(DATE$,2)), VAL(LEFT$(TIME$,2)), VAL(MID$(TIME$,4,2)), VAL(RIGHT$(TIME$,2))

what I am proposing is that the above is still supported (for legacy code on new firmware) but in the event of a zero argument count, RTC SETTIME uses DATE$ and TIME$ so the command would also support

RTC SETTIME

... which is neater and establishes a common mode of operation between the two commands. I don't know what is involved - nothing is ever impossible for the man that doesn't have to do the work



Edited by CaptainBoing on 06 July 2018 at 8:25pm
Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
matherp
Guru
Guru


Joined: 11 December 2012
Location: United Kingdom
Online Status: Offline
Posts: 2164
Posted: 06 July 2018 at 9:06pm | IP Logged Quote matherp

How about what I have implemented on the STM32H7 port?

If you set time$ and the RTC is enabled then it automatically updates the RTC. Likewise date$. Then you can get rid of the command RTC SETTIME altogether.

I've also implemented reading the RTC as part of the "NEW" command so the use of RTC GETTIME becomes much less important.

Finally, I've implemented a "DAY$" function that returns the day of the week automatically calculated from the date.

Code freely available of course. This made particular sense on the STM32H7 as it has a built in RTC with external battery backup that keeps running even when the chip isn't powered.

Edited by matherp on 06 July 2018 at 9:16pm
Back to Top View matherp's Profile Search for other posts by matherp
 
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 547
Posted: 06 July 2018 at 10:11pm | IP Logged Quote CaptainBoing

that sounds quite nice - I didn't specify above but I was referring specifically to the Mk2 (170 chip) - how would you determine the "RTC enabled"? You could probe the I2C bus at wake up but then MMBasic doesn't know what is attached to the pins - you might be using them for something else and could potentially cause a problem... suppose there is a mains relay connected - eek!

I think in an arena where the hardware is more controlled/more pins (like STM and MMX), it is great to have that level of support but the flexibility of the 170 (not just but is the only one I use without going to a MMX) means you can't make any assumptions about what is connected to pins. The 170 can be short on pins and I have two specific examples where I use the I2C pins purely as 5V tolerant I/O. I wouldn't want anything playing with the pins without my express say-so.



Edited by CaptainBoing on 06 July 2018 at 10:13pm
Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2349
Posted: 07 July 2018 at 12:13am | IP Logged Quote Geoffg

CaptainBoing wrote:
when setting the time, could it be that if you don't specify the argument string, SETTIME takes the current DATE$ and TIME$ values?

That could be done and I will have a look at it.

One thing that worries me is that it has a certain circular illogicality about it. I mean, GETTIME sets the Micromite time from the RTC (which is supposed to be always correct). Then, SETTIME does the opposite and uses the Micromite time to set the RTC - now the Micromite is assumed to be the one that is correct.

This sort of illogicality is not good in a programming language.

There is also the question of how did DATE$ and TIME$ get to be set correctly in the first place? If the settings were entered by the user then why cannot this data be used to set the RTC (which can then be used to set the Micromite's clock).

Geoff
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 547
Posted: 07 July 2018 at 12:46am | IP Logged Quote CaptainBoing

it's down to the vigilance of the programmer

There is something "complete" and pleasant where functions have a part-counterpart relationship, like VAL/STR$, Unixtime/HumanTime etc... GETTIME writes Date$/Time$ so could SETTIME read them? I think that focusing such actions all through system values feels like object orientated - I know DATE$/TIME$ are not real objects in the true sense of programming but they can be made to feel like it with a more symmetrical approach (I would love a single DATETIME$ "object" if you are feeling bold wow! inbuilt NOW$ function)

The validity of the time origin is a moot point really as it is only down to the application - all my MMs run UTC wherever they are so in the UK their clocks are only "right" 50% of the time. I have one in Hyderabad, India which is 5.5 hours slow from local perspective. I try to keep things at UTC +/- 2 secs everywhere and DS3231 can do that reliably for several months. As part of my "patrols" I always check the time with time.is and tweak as necessary. There are plenty of ways to make this more elegant I suppose but that isn't my point here.

So long as not-too-much time is allowed to elapse between setting them and stashing in the RTC, the set values are trustworthy.

The problem with all of this, of course, is the MM (170) is fairly stuffed so change for change-sake is difficult to justify.

it's an idea that's all

Edited by CaptainBoing on 07 July 2018 at 12:59am
Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
TassyJim
Guru
Guru


Joined: 07 August 2011
Location: Australia
Online Status: Offline
Posts: 2544
Posted: 07 July 2018 at 1:22pm | IP Logged Quote TassyJim

On the MX170 where the system time is controlled by a free running oscillator, not a crystal, it is handy to keep RTC and system times separate.

Having RTC SETTIME default to system time if no arguments are included would be good but that is as far as I would go.
When I want to control the system oscillator with CLOCKTRIM, I like to read system time followed by RTC GETTIME then compare the before and after times and use the difference to adjust CLOCKTRIM.

If I regularly talk to the mites from a PC, I use the PC time to update the mite and don't use a RTC. I can still do the trimming with CLOCKTRIM if desired.

Jim


__________________
It all started with the ZX81....
VK7JH
http://www.c-com.com.au/MMedit.htm
Back to Top View TassyJim's Profile Search for other posts by TassyJim Visit TassyJim's Homepage
 
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 547
Posted: 07 July 2018 at 3:48pm | IP Logged Quote CaptainBoing

agree with that. best not to get too ambitious on a system with a small amount of firmware space... and it is "only" a micro-controller. easy to forget that when you have the luxury of MMBasic in that arena.


... as an aside on obtaining time rather that having an RTC:
I have a controller in my garage that does lights, door, alarm, pipe warmer etc. It is controlled from an android app on my family members' phones to a Bluetooth module (HC-05? can't remember now). CLOCKTRIM means I get a drift of just a few minutes a week so the outside lights still reliably track enough of the daytime to come on around dusk and go off at dawn. It doesn't have an RTC but rather picks unixtime from transmitted commands and sets its date/time, "just in time".


...
               If Len(b$)>=16 Then ' commands look like $D1505054337041!
                    if Left$(b$,1)<>"$" Or Mid$(b$,16,1)<>"!" Then FlushIO:Goto BadFrame
                    dt$=HumanTime(Val(Mid$(b$,3,10)))
                    On Error Skip 1: Date$=Left$(dt$,10) ' set the clock (UTC)
                    On Error Skip 1: Time$=Right$(dt$,8)
                    ' parse the command
                    Select Case Mid$(b$,2,1)
...


Very similar method to what you describe above; I also have a snooker/pool hall table-timing product in a few clubs around UK. Each installation has anything from 9 to 22 slaves (using HC-12s) and the master is the only thing with a reliable clock (PC). Every poll/discovery cycle starts with a broadcast of the time from the master. I don't even bother with CLOCKTRIM on the slaves as they have their times set every 5 minutes or so.

...
ELSEIF dst=999 THEN ' broadcast only
                    SELECT CASE cmd$
                         CASE "TIME"
                              IF LEN(pl$)=19 THEN
                                   IF MID$(pl$,9,1)="," THEN
                                        ON ERROR SKIP 1:TIME$=LEFT$(pl$,8)
                                        ON ERROR SKIP 1:DATE$=RIGHT$(pl$,10)
                                   END IF
                              END IF
...



Edited by CaptainBoing on 07 July 2018 at 3:59pm
Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
Andrew_G
Senior Member
Senior Member


Joined: 18 October 2016
Location: Australia
Online Status: Offline
Posts: 218
Posted: 08 July 2018 at 11:03am | IP Logged Quote Andrew_G

Hi,
I'm hesitant to leap into a discussion amongst MM giants but in contributing to answers to Geoff's rhetorical question of "where do Date$ and Time$ come from" I have a base station with a GPS module purely for date and time (RTC sentence) - every two hours it broadcasts (via HC-12s) the current GPS value (corrected for UTC offset and DST) so that everyone is on the same page. The slight lag between GPS and remote device is not critical in my case and with two COM ports (GPS and HC-12) my base's MM170 is OK.

Andrew
I have dispensed with my RTC (the batteries do die and even after trying I couldn't control the drift as effectively/easily as the above method).
Back to Top View Andrew_G's Profile Search for other posts by Andrew_G
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2349
Posted: 08 July 2018 at 12:35pm | IP Logged Quote Geoffg

Another day, another beta (V5.04.10 Beta 2). You can download it from: http://geoffg.net/micromite.html

This version has a revised keyboard layout for the GUI TEXTBOX as per Grogster's suggestion. I have added an extra three keys down the right hand side and that allows for the addition of a number of permanent keys that are available on every layout of the keyboard. These are the delete/backspace key, the cancel key, and period (".").

To squeeze in the extra keys I made each key slightly narrower and reduced the space between keys. The result still looks OK (to my eyes at least). While doing this I realised why the original keyboard was 10 keys wide. With an 800 pixel wide screen each key was 80 pixels however with 11 keys wide each key now occupies 72.727 pixels and that fraction of a pixel was a real pain to deal with.

I would be grateful if people could play with this as I am anxious to find out if the new layout has broken anyone's program.

Geoff




Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
robert.rozee
Guru
Guru


Joined: 31 December 2012
Location: New Zealand
Online Status: Offline
Posts: 1273
Posted: 08 July 2018 at 3:23pm | IP Logged Quote robert.rozee

hi geoff,
is there any chance of slipping mouse-control (using the X-11 extenstions) into the editor? as a first step, just have clicking on a given location cause the cursor to go to that location.

i've tried adding this support within gfxterm, but the timing is just too tight to get it working reliably. i do have mouse-wheel up/down map to the up/down keyboard arrows.


cheers,
rob :-)
Back to Top View robert.rozee's Profile Search for other posts by robert.rozee
 


Page of 2 Next >>
In the news...
 
Post ReplyPost New Topic
Printable version Printable version
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.8
Copyright ©2001-2004 Web Wiz Guide

This page was generated in 0.1719 seconds.
Privacy Policy     Process times : 0.02, 0, 0, 0.16