![]() |
Forum Index : Microcontroller and PC projects : Micromite MkII beta testers needed
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
Oldbitcollector![]() Senior Member ![]() Joined: 16/05/2014 Location: United StatesPosts: 172 |
Wow Geoff, this is faster... I've been working on a little program to read around 20 keypresses with IF/THEN statements this afternoon. As I was wrapping up the program, I figured it was time to load the new .hex file and give it a whirl. NOTICEABLE DIFFERENCE IMMEDIATELY. Thank you. My Propeller/Micromite mini-computer project. |
||||
micronut Newbie ![]() Joined: 03/09/2014 Location: United StatesPosts: 37 |
I just want to thank everyone that is working on the MkII. Geoff your hard work in adding new features and improving MMBasic is greatly appreciated! Peter you did an awesome job with helpful tools and tutorials for MkII. I have a couple of years of experience with C but it has been awhile since I use it but I certainly will now. Also I'm looking forward to what my fellow beta testers come up with ![]() |
||||
centrex![]() Guru ![]() Joined: 13/11/2011 Location: AustraliaPosts: 320 |
Hi All I am trying to get Peters(G8JCF) lcd code to work with the new ver 4.6 with no success. No problems with Ver 4.5D. Any ideas Cliff Cliff |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Cliff This is a known issue. The problem is that in 4.6 B16 the DIM statement creates both Global and Local variables. The LCDI2C_INIT call creates 8 GLOBAL vars using DIM, but in 4.6, those DIM statements only create LOCAL vars which disappear when the SUB ends. BTW this same problem will exist in all my libraries. I have discussed this issue with Geoff, and I understand that a future (next ?) 4.6 Beta will restore the 4.5 DIM/LOCAL var scoping . In the meantime, if you need to make the LCD library work, do the following At the start of your Program place DIM LCDI2C_LCDBackLight, LCDI2C_I2CAddr, LCDI2C_RSDataMask,
DIM LCDI2C_EMask, LCDI2C_BackLight, LCDI2C_NibPos, LCDI2C_BLOn, LCDI2C_BLOff Then in SUB LCDI2C_Init, comment out ALL of the DIM statements. LOCAL statements are fine. OK ? Peter The only Konstant is Change |
||||
centrex![]() Guru ![]() Joined: 13/11/2011 Location: AustraliaPosts: 320 |
Hi Peter Thanks for that, it also explains why I am getting other DIM statement errors which I fixed by moving the DIM to the start. Regards Cliff Just tried it, shifted all my dim statements to the the start of the program now everything works as per 4.5D. Many thanks Cliff |
||||
plasma Guru ![]() Joined: 08/04/2012 Location: GermanyPosts: 437 |
Pullup and pulldown on setpin. Has anyone testet this? Because the Microchip Errata Document say this will not work?!! |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Why don't you try it out for yourself? Geoff Graham - http://geoffg.net |
||||
plasma Guru ![]() Joined: 08/04/2012 Location: GermanyPosts: 437 |
Iam stuck @ work :( |
||||
WhiteWizzard Guru ![]() Joined: 05/04/2013 Location: United KingdomPosts: 2932 |
I can confirm PULLUP works (used with a push button to Ground). WW |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
The value of TIMER is updated but not TIME$ and DATE$ (99% of applications that need TIME$ and DATE$ will use a RTC). Note that the sleep period is approximate and can vary by +/-20%. I agree and an excellent solution, thanks. This is amazing, previously I got a lot of stick because this was allowed! It was a bad practice and I believe that the critics had a good point. Also the change was necessary to allow variables to optionally not use a type suffix. It will break a few programs (it broke one of mine) but the change was necessary. And before anyone asks, I don't want to make it yet another option - there are too many already. Sorry but I have to disagree with you on this one. Using type suffixes is an archaic part of BASIC and there had to be a better way defining the type of a variable - Visual Basic does it the same way. You can continue to use a $ suffix for strings if you wish but everyone else should not be required to do the same. BTW, I hope that you are happy with SELECT...CASE. Geoff Geoff Graham - http://geoffg.net |
||||
plasma Guru ![]() Joined: 08/04/2012 Location: GermanyPosts: 437 |
I try it out this night ! Btw: Geoff have you found a Spell to work the errata "bug" out ? |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
About DIM and LOCAL i have an opinion. :) Scope is one of those things that can confuse anyone. If you look at most other computer languages everything that gets defined stays within that scope. It is a good practice. This prevents subroutines and functions to use each others variables. A mistake is easily made, especially in basic where variables can be made on the fly. A = 1 creates a new variable. This should be equivalent to DIM A and then A = 1. The DIM will then determine the scope and create that variable in that scope. In my opinion you should be unable to create global variables from inside a function or subroutine. If someone writes a library function, scope gets difficult. If it consists of more then one function a way must be found to keep those variables accessible. Preferably within that library only. One way of doing that within the limits of the newest basic is to have a subroutine that has 'sub functions'. Like this still untested Song playing library routine: [code] SUB SONG(Mode, param1, param2, param3$) 'Define variables here DIM Song$, Note$, Location, Speed, Repeat, Playing DIM START_TIMER = -100, STOP_TIMER = -200 SELECT CASE Mode CASE START_TIMER 'Only used internally 'Start the timer tick 'Use speed to calculate period SETTICK Speed * 1000, SONG, SONG_TIMER Playing = true CASE STOP_TIMER 'Only used internally 'Stop the timer tick 'Use speed to calculate period SETTICK 0, 0, SONG_TIMER 'STOP PWM Use SONG_PWM to determine which channel PLaying = false CASE SONG_LOAD Song$ = param3$ Speed = val(param1$) Repeat = val(param2$) Location = 1 CASE SONG_PLAY ' Play sound subfunction IF NOT Playing THEN SONG START_TIMER ENDIF CASE SONG_PAUSE ' Pause sound subfunction IF Playing THEN SONG STOP_TIMER ENDIF CASE SONG_STOP ' Stop sound subfunction IF Playing THEN SONG STOP_TIMER Location = 1 ENDIF CASE SONG_LOCATION Location = val(Param1$) CASE ELSE 'Arrived here because of timer tick 'Get note at "Location" to play Note$ = MID$(Song$, Location, 1) 'Calculate frequency for use with PWM 'Set PWM Use SONG_PWM to determine which channel IF Location < LEN(Song$) THEN Location = Location + 1 ELSE Location = 0 IF Repeat = false THEN SONG STOP_TIMER ENDIF END SELECT END SUB [/code] Only a few CONST are needed in the global scope. Greatly reducing interference with other library functions. [code] CONST SONG_LOAD = 1, SONG_PLAY = 2, SONG_PAUSE = 3 CONST SONG_STOP = 4, SONG_LOCATION = 5 CONST SONG_TIMER = 4 ' TIMER = 1 to 4 CONST SONG_PWM = 1 ' PWM is 1 to 5 (1A, 1B, 1C, 2A, 2B) [/code] You can then use this library function with: [code] SONG SONG_LOAD, 1, false, "cdeccdecefgefg" SONG SONG_PLAY [/code] Microblocks. Build with logic. |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@TZ When SUB SONG ends/exits all the DIMed vars will disappear (in current 4.6) so there can be no continuity of variables from one call to SUB SONG to the next call to SUB SONG. So in the case of CASE SONG_LOAD
Song$ = param3$ Speed = val(param1$) Repeat = val(param2$) Location = 1 several locally DIMed variables get set and then SUB SONG exists, and with the exit those locally DIMed variables also disappear thus losing the values to which they were just set. So what was the purpose of CASE SONG_LOAD ? I'm clearly not understanding the mechanics of your method, sorry :( If DIM inside a subroutine meant STATIC (as in VB), then I can see how SUB SONG would work, but STATIC is not what DIM means, and I'm certainly asking for STATIC. If MMBasic had classes and/or modules thus enabling a variable(s) scope to be expanded from only inside SUB/FUNCTION to MODULE/CLASS level, then there would be no problem (I dislike Global Vars, but one does need vars which are shared across 2 or more subs/functions). Peter The only Konstant is Change |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
just having TIMER updated is enough to keep me happy :-) i have a specific application in mind. can you possibly expand a little on the +/-20%? is the wide tolerance for short intervals only? is it because of 'rounding to the nearest second' at the start and end of the interval? what about sleeping for several hours - will sleeping repeatedly for 5 hours produce intervals that each vary randomly between 4 to 6 hours? or will the intervals all have the same length? i'm hoping it is actually more like (+/-1sec) + (+/-0.5%) i am surprisingly archaic in my ways, some would say a bit of a Luddite in many regards. often i hark after the days of valved B&W television, where there was an elegance to design and a place for the generalist engineer. again, extremely pleased, it is a useful addition. what would be a nice compliment to SELECT...CASE would be an MM.INTPIN variable that held the number of the pin that caused the last interrupt. i recall this from many moons ago. btw, i have made use of READ/RESTORE/DATA recently. i notice that some basic implementations allow an argument to RESTORE for selecting the DATA statement that the pointer is to be set to. this may well be a useful enhancement: RESTORE [ line# | label ]
cheers, rob :-) |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Geoff I agree with your thinking re A,A$,A%. A,A$,A% all being distinct is a recipe for hours of head-scratching. Add in Option Default, and Dim VAR as TYPE, and another few hours will result ! The suffices, $, % and nothing, denote the type of A. A is the name of the variable itself. In languages which have more than just a few types, eg C,C#,VB,Delphi etc type identifiers would quickly get out of hand. I have, like I'm sure lots of other people, done things like A$="1234", A=Val(A$) when I've been lazy ! Really bad practice IMHO. Peter The only Konstant is Change |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Geoff I meant to write "I am NOT asking for STATIC" in my post above re DIM/LOCAL Peter The only Konstant is Change |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Peter. You are right. That can only be done when they are static. :( Microblocks. Build with logic. |
||||
cosmic frog Guru ![]() Joined: 09/02/2012 Location: United KingdomPosts: 302 |
I like the sound of Peters RESTORE[label/linenumber]. Could be very handy. Dave. |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Dave That's Robert's idea to give him the credit ! Personally I haven't used the DATA statement/construct in a BASIC program since 1976 when BASIC still had line numbers, single letter variable names, tty I/O etc. On 'big' machines, eg PCs, one just reads in data items from files, and on small/micro machines, eg uMite, one just DIMs arrays, and sets each element to the data item required. Peter The only Konstant is Change |
||||
Grogster![]() Admin Group ![]() Joined: 31/12/2012 Location: New ZealandPosts: 9586 |
Can someone please clarify the new variable arrangement for me. Not requiring $ for a string variable anymore, does this mean that you can have: A=1234 for a numeric variable A="1234" for a string variable, dropping the $ A=1234 for number and A$="1234" for a string are much easier for ME to follow, as I am sure, many other old-school programmers. ![]() ![]() Smoke makes things work. When the smoke gets out, it stops! |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |