 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 : MMbasic 5.3 Requests.
  Page 9 of 11   |
|||||
| Author | Message | ||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Robert;Please don't forget: i = ftan2(j,k) Very important!!!! redrok |
||||
| Bizzie Senior Member Joined: 06/07/2014 Location: AustraliaPosts: 192 |
I have been thinking about writing a GUI Control editor so you could interactively move, size and set other properties of a control. To do this you would need access to the above properties, as far as I can tell this is not possible now. Calling any GUI xxxxx #ref,...... will generate an error. I realize that I am asking for a complete redesign of how controls are written but I will throw this into the discussion for 5.3. Another thought was to use something like AutoTrax DEX to draw the controls and then generate code from the drawings but this seems too much work to me. If anyone has some ideas along these lines please contact me or start a new thread. Rob White |
||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
there may be another way... one could code the 4 basic fuctions directly, perhaps even uplifting the source code from the double maths library. for the transcendental functions (trig, logs, etc) it would be possible to use the corresponding 32-bit functions (already present) to obtain a first approximation, followed by a few loops of iterative refinement to extend out to the 64-bits. the end result may well be relatively compact. the question is: is there any real interest in doing this, not just as an academic exercise, but in terms of folks having actual applications that require 64-bit maths? cheers, rob :-) |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| LouisG Senior Member Joined: 19/03/2016 Location: AustraliaPosts: 129 |
Here is my request for MMBasic 5.3. Would it be possible to add an additional parameter to the LINE command which, when asserted, would cause the displayed line to turn into a series of flowing dashes. It would be used in creating dynamic mimic diagrams (e.g. liquid flowing in a pipe) and would be a welcome complement to the fine array of screen controls Geoff has already produced. The flowing line should catch the eye and indicate a direction of flow of the dashes. To keep things simple, spaces between dashes of any line colour could be grey (except for grey lines of course). Synchronising dashes as they go round corners could be dispensed with. The above animation is relatively slow speed and may be possible to do using present V5.2 commands. If so could anyone provide a hint as to how? I have already mastered graphs and bargraphs but baulk at animating specific lines on a screen. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2932 |
One trick I use to use for 'animation' was to colour swap - but unfortunately this is not an MMBasic feature yet. I will try to explain. In some BASICs, you could change the colour of a colour  . So for example you would have a black background, and then set all 'unused' colours to display as black as well. Then you would draw a frame of dashes (in your case) in one of the unused colours, then the next frame in the next unused colour, etc, etc. End result here is a black background with black dashes on it (i.e. a black screen!)Then to animate the dashes you would simple cycle through the unused colours and turn each one on one at a time to grey for example, then back to black. End result is a nice smooth animation. Does that make sense? (even though not possible on the MM  ) |
||||
| LouisG Senior Member Joined: 19/03/2016 Location: AustraliaPosts: 129 |
Thanks WW. I am now thinking out a possible subroutine which would take take the coordinates of the line ends and calculate and generate LINE commands for individual dashes and spaces, each say 15 pixels long. This would then be recalculated say every quarter second and shifted along the line by 5 pixels. Will experiment with it over the holidays. Still, it would be nice to invoke the flowing dashes using a LINE command parameter. . . Louis |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 767 |
It would be awesome if somehow we could create GUI controls to include whatever kind of graphic object needed and attach it to the "action" code... Maybe with the new "MZ" target we will get the needed extra space inside for such things... I love all the teem work going on by Geoff, Matherp and Kiiiid getting MMBasic to the next level..!! Awesome work Gents..!!  |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Here's a very rough bit of MMBasic code to do this using things as they are currently. It needs a lot of polishing but shows the idea. If an extra LINE parameter were used it would probably also need to handle forward/reverse/static flow. Greg Edit: I think 250 msec 'ticks' are faster than necessary; 500 works fine too and leaves more leeway for the main program and more 'pipes'. This is running fine on an MX170 chip. 'PIPE FLOW ILLUSION - MMBasic V5.2 for ILI9341 LCD Display - Greg Yaxley (paceman) '----------------------------------------------------------------------------------- cls LINE 20, 40, 220, 40 ,4,&HFF0000 'testing fixed lines - a few options LINE 20, 60, 220, 60 ,4,&H00FF00 LINE 20, 80, 220, 80 ,4,&H0000FF LINE 20, 100, 220, 100 ,4,&HDCDCDC LINE 20, 101, 120, 101 ,2,&H0000FF '-------------------------------------------- 'This is just a rough test routine - apologies for not dimensioning variables properly. 'It only works for horizontal lines and forward flow. The flow 'illusion comes from the half segment added 'alternately at the start of the pipe. 'Other parameters could add direction (forward/reverse/static) i.e. the 'inc' variable, also colour, pipe diam. etc. 'Segment length is fixed here at 10 pixels and for a pipe from starting at x(20) & finishing at x(220) gives '10 flow-segment pairs. If the number of pairs is odd the colour is out of sequence. The 'end of the pipe' needs 'tidying up with half segments when necessary. The segment loop-control is also a bit off but I'll leave that for 'others too. 'Using the PAUSE for animation is not on in real life - counters &/or SETTICK need to be used instead. '---------------------------------------------- flow.pipe(20,20,220,20) 'display the pipe (start x, start y, finish x, finish y). do flow.segments(20,21,220,21) 'display flow segments starting one line below 'start y' to leave pipe outline loop sub flow.pipe(stx,sty,finx,finy) LINE stx, sty, finx, finy ,5 'default (white) pipe outline (if wanted); 5 lines wide end sub sub flow.segments(stx,sty,finx,finy) 'the flow segments are displayed 3 pixels wide to leave pipe outline 'Flow segments fixed at length of 10 pixels temp = stx inc = 5 'half a segment length for illusion of flow do while stx < finx 'Fill the Pipe, start with blue, alternate with white (default) segments LINE stx, sty, stx+10, finy,3,&H0000FF : LINE stx+11, sty, stx+21, finy,3 stx = stx + 20 loop stx = temp 'reset pipe start-position variable Pause 250 line stx, sty, stx+inc, finy,3 'display the 'half' segment in alternate colour at start of line do while stx < finx 'display the rest of the 'shifted' segments in correct colour sequence LINE stx+6, sty, stx+16, finy,3,&H0000FF : LINE stx+17, sty, stx+27, finy,3 stx = stx + 20 loop stx = temp pause 250 do while stx < finx 'Fill the Pipe again - this time start with the alternate colour LINE stx, sty, stx+10, finy,3 : LINE stx+11, sty, stx+21, finy,3,&H0000FF stx = stx + 20 loop stx = temp pause 250 line stx, sty, stx+inc, finy,3,&H0000FF 'display the half-segment again, alternate colour to previous do while stx < finx 'the shifted segments again in correct colour sequence LINE stx+6, sty, stx+16, finy,3 : LINE stx+17, sty, stx+27, finy,3,&H0000FF stx = stx + 20 loop pause 250 end sub '------------------------------------------- |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
I like the idea of doing it in Basic code. That way you don't have the central (Geoff) code suddenly busy for a long time (every screen update) - which would really foul up programs needing to be hard real time. (i.e. this avoids ruining the latency) John |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6268 |
If you are using a few fixed angles (horisontal and vertical are easiest) for the lines, a user defined font is worth looking at. With the correct size font, lines of different thickness and the gaps in different places along the line is easy to produce. Making it move involves writing a different character for each stage of the animation. Jim VK7JH MMedit |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Hadn't thought of that John but good point. I'm not sure how many 'flow-lines' might be in a diagram at one time but my code definitely needs a proper programmer to optimise it - I'm a metallurgist.  It's probably of less relevance with most MX170 applications, but is relevant as LouisG suggests, for MM+ applications (and MZ's) - maybe as another 'CONTROL' type. That's a very different approach Jim. I think the need for this would be process control board applications and I can't remember seeing any of those with other than 90 degree bends so your first point shouldn't be an issue, horizontal and vertical lines would do it. Someone would have to set up the fonts though and there's extra work and memory overhead in that. It's interesting that the animation I did (after a lot of fiddling) only actually involves four different loops, two if you simply swapped the colours for the first and third loops - I'm not sure if that gains much speed or not. Joining pipes at a bend complicates things because it has to know which colour is 'going around' the bend as the second 'pipe' is entered and that will change with odd/even numbers of segments. I guess you could be a bit untidy and ignore untidy 'flow' segments at the bends but if the lines were short that wouldn't look very good. Greg |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
exactly! I have been watching this thread for some time and it occurs to me that there are a lot of requests for really niche/specific stuff. If we applied the same logic to other areas, there'd be a lot of house-shaped bricks. A programming language should provide a rich set of "primitives" - maths, string-handling, memory/data structures, input/output, flow control etc. - the building blocks and avoid anything that is only useful to 10% of the audience. Then we concentrate on building a fantastic _open_ libraries to house specifics for everyone to use and you just include and modify the bits you need in your project. Think about talking to the ESP8266 (which is a cheap, common, mega-useful device) - that is highly desirable. It's a great device and we should all be building IP aware projects. BUT, do we need built in support for it? Is it worth sacrificing precious space for something that may not be used in most projects? It is very easy to get the 8266 working with the existing COM ports and I developed my own library (in MMBasic) to provide a web API in an evening using nothing more exotic than INPUT$/PRINT# and some string slicing and flow control. Besides saving a lot of space in the core, libraries also avoid having to do something in a specific way. I don't always use the LCD commands built in to MMBasic (they don't provide flexibility for a multiplexed/shared data bus - or 8 bit). I wrote my own LCD library - in MMBasic - and it is plenty fast enough, also I am not bound to one way of doing things and I can make it jump through any hoops I like, even tweaking it from project to project. One warning here though - without the specialisms, it risks isolating any who's programming skills might be more "junior" ... but that's what forums are for - to learn from and help others. Good library, active forum... problem solved? INCOMING!!!! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2932 |
Good points well made Captain! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
perfectly put! with the MX470/mmbasic feature set leaving the MX170 behind, i'd very much like to see much of the basic functionality that is diffeent between MX170 and MX470 shifted into custom functions. this would mean that if one wanted to, an MX170 could be configured to run any MX470 basic code (hardware and flash limitations aside). ie, you could load up the MX170 library with the full compliment of GUI functionality, with the tradeoff that you would then be limited to just small 'user' programs. if a stripped-back MX170 mmbasic does eventuate (and i really do hope it does), this would be the starting point. some of our cfunction-savy members could then perhaps take the MX470 gui source code and convert it to cfunctions for use with the MX170. though i do still have a few favourites i'd personally like to see hard-wired in - BMPx80 (air pressure sensor) support being the main one! cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
There you go, the BMPx80 uses an I2C interface. So write your own driver for it in BASIC. I think that a lot of people ask for their favourite device to be supported because asking is easier to do than pulling out the data sheets and figuring out the details. The devices that are supported were selected based on what I thought at the time would be the most popular. I don't have plans to add any more special devices. I keep saying this but, as far as features go, the MX170 Micromite has matured and most changes will be trivial or bug fixes. There is scope for more features in the MX470 and MZ versions but they have to be worthwhile, not just designed to fix one person's particular problem. Geoff Geoff Graham - http://geoffg.net |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
In my experience teaching others how to use a microcontroller (using the micromite) it became very obvious right from the start that the built in support is what gets them interested. Beginners have no clue how to read datasheets, make I2C/SPI subroutines to get it to work, etc. The brilliance of the micromite is that a beginner can get it to work very quickly and gets hooked. After that the willingness to go hunt for information is a lot bigger and not an obstacle anymore. Getting things to work that are not supported gives a big confidence boost. I would say that doing to much in firmware will be detrimental to the advancement of the beginning developer. If everything is easy then not much will be learned. Only candidates for firmware i would think is if speed is critical or anything that can not be done using MMBASIC or Cfunctions. My personal wish is for a redim statement and ubound/lbound statements. This would make manipulating arrays much easier as currently arrays have to be dimensioned larger then needed as there dimensions can set only once. Also with the current trend to connect to the internet a Hashtable would be invaluable as most services return key/value pairs of data which currently is very hard to do from basic. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
I thought ERASE would let you get rid of an array. You can then DIM it the new size. John |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
... and ... Evening chaps. JohnS: yes you are correct but it needs a bit more clarification on the specific application. ERASE is destructive - it dumps any data in the array. REDIM is also destructive but (dare to dream) REDIM APPEND preserves the data in the array... pruning or padding elements as required but I suspect it is quite a bit of development which is unlikely on such a mature product.MicroBlocks: If kludging REDIM with an ERASE/DIM combo, you need to trap potential errors... e.g. ON ERROR SKIP ERASE A$ DIM A$(x) otherwise it will fail first time round (when A$ doesn't exist). Small point. LBOUND returns the same as OPTION BASE (so you can set a CONST to keep track of it). UBOUND is trickier to do (It is the number of the top element in the array). With MMBasic your prog needs to have some scheme to keep track of it. So although ... FOR n=1 TO UBound(A$) ... makes it easy(er) for code to self adapt, you can always keep track of whatever you used to DIM the array in the first place. Together they are nice and tidy but their absence isn't a show stopper (for me at least). I have written quite a few function/subs to provide the functionality of the "missing" VB6 functions - perhaps that would be a good thread to start - VB work-a-likes  |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
I agree with MicroBlocks (Jean) about the in-built device functionality, especially with the MX170 MM2. It makes it reasonably easy (or just possible) for beginners and enthusiastic hobbyists to get something really useful going. That's a big plus and as he said, encourages further leaps into the great software unknown. I can also see Rob's (and other's) point about a 'stripped-down' version for the MX170 for the more professional product-developer users, but that creates a lot of extra work for Geoff to create and maintain. For "a mature product" (his words) that's hard to justify and the time and effort taken for that would necessarily come out of further development of the MM+ etc. The worst thing that could happen for us all is for Geoff to get burnout - not that I think that's happening any time soon. Greg |
||||
| Page 9 of 11 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
