 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 7 of 11   |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Not ideal i think as that requires people to use CFuntions. And what about the MX150? I still have lots of those available and for most tasks they are sufficient. Writing code for different MCU's without reverting to CFunctions to identify which opins can be used is still nice to have. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4034 |
Then try PEEK. I think the MX150 may be one of those where space is already in short supply so MMBasic using more may be unattractive. John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Will PEEK work with different MCU? I think only within the same family. What about ported versions, like the one for the ARM or any other future MCU that will be used. Microblocks. Build with logic. |
||||
| Nathan Regular Member  Joined: 10/01/2016 Location: GermanyPosts: 49 |
Hi Geoff, do you mean something like the following? cfunction.h -------------------------------------------------------------------------------- #define Vector_userFunc_1 (*(unsigned int*)( Vector_CFuncRam +63*(sizeof(int)))) #define Vector_userFunc_2 (*(unsigned int*)( Vector_CFuncRam +62*(sizeof(int)))) #define Vector_userFunc_3 (*(unsigned int*)( Vector_CFuncRam +61*(sizeof(int)))) #define Vector_userFunc_4 (*(unsigned int*)( Vector_CFuncRam +60*(sizeof(int)))) #define Vector_userFunc_5 (*(unsigned int*)( Vector_CFuncRam +59*(sizeof(int)))) #define Vector_userFunc_6 (*(unsigned int*)( Vector_CFuncRam +58*(sizeof(int)))) driver part -------------------------------------------------------------------------------- long long addItA( long long x, long long y) { return x + y ; } long long subItA( long long x, long long y) { return x - y ; } ... main ... register ... volatile unsigned int libOffs ; getFPC(NULL,&&getFPCLab,&libOffs) ; // warning can be ignored, stupid editor getFPCLab: { } Vector_userFunc_1 = (unsigned int)&addItA + libOffs; Vector_userFunc_2 = (unsigned int)&subItA + libOffs; ... use the new system functions by a cfunction sys call --------------------------------------------------------------------------------- #define addIt(a,b) ((long long (*)(long long ,long long)) (Vector_userFunc_1)) (a,b) #define subIt(a,b) ((long long (*)(long long ,long long)) (Vector_userFunc_2)) (a,b) long long polyA (long long *a , long long *b) { return (long long)addIt(*a,*b) ; } long long polyB (long long *a , long long *b) { return (long long)subIt(*a,*b) ; }  not feeling well with it Nathan |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10198 |
 |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Nathian/Peter, It might not look clean but it will compile to the same as your original suggestion. I just don't think that it is right to embed a rarely used feature in MMBasic (and use flash) when there is some other way to do the job. On another subject... John, you can use PEEK() to get the device ID as follows: DEVID% = PEEK(WORD &HBF80F220) AND &HFFFFFFF If you wanted it to work on all Micromites including the MX150 (ie, before 64-bit integers) you would have to use: DEVID_LOBITS = Peek(&HBF80, &HF220) + Peek(&HBF80, &HF221) * 256 DEVID_HIBITS = (Peek(&HBF80, &HF222) + Peek(&HBF80, &HF223) * 256) And &HFFF Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
A general comment on this thread... I love these sorts of discussions because every so often up pops an idea that would really add value to MMBasic. However, it needs to add genuine value and these are some of the criteria that I use when deciding on that: - Will many (ie, 20% or more) users find it useful and, more importantly, actually use it? - Does the syntax follow the "style" of the BASIC language? - Can the same outcome be achieved using ordinary BASIC code? - Will it use up much flash? - Will it be easy or hard to implement? - Will it impact the performance of the Micromite for the "ordinary" user? A lot of ideas are created by people to fix a specific problem in one or two projects and I am very wary of these. It is extremely hard to remove a feature once it has been added to a computer language - this is because there might always be someone out there that has a program using that feature. Unless great care is taken, MMBasic could easily be cluttered with badly thought out "features" that cannot be removed. Just look at the Windows API for a good example. So, thanks for the suggestions but please do not be disappointed if yours does not make it into MMBasic. It is a difficult balancing act producing a clean and productive computer environment and not every good idea can make it in there (a lot of mine have not made it). Geoff Geoff Graham - http://geoffg.net |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Bravo Geoff! I've got a lot of ideas for additions that I absolutely know should not be included. Paul in NY |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 871 |
Apologies if this is not the right thread (I'll happily start a new one) but I have the following suggestions: - I've been experimenting with both SuperClock and BoatComputer and notice that each has their own ...Font.BAS files loaded to Library. Whilst the same font number is used in the programs they are not interchangeable (this requires deleting the old and saving a new library - not too hard). Is their any sense in "harmonising" the font numbers (eg by reserving the first x fonts for Geoffg etc) or is this just something to be aware of? - In MMEdit is it possible to show a "Ruler" (or an extra field on the top-right of the menu bar) to show which character on a line the cursor is at (this would help setting out "Text" or "Print" fields? (I've tried using column marker but that is not quite right). I continue to be in awe - thanks, Andrew |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
geoff: in the world of high-end programmable calculators, it is quite common for some functions to be written in a higher-level language to reduce code size (at the expense of reduced speed of the function). for instance, consider the DS18B20() function in mmbasic. if it were replaced with a short segment of basic code held in a 'fixed' library, would that basic code occupy less flash than the current C implementation? this is, of course, only practical with functions that are not time-critical, and may indeed not produce any significant gains in the case of mmbasic. just an idea. cheers, rob :-) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6268 |
MMEdit is written in an interpreted language and speed is a problem. Having a line character counter would slow things down too much - I tried. The column marker was the best I could come up with for now. Jim VK7JH MMedit |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 871 |
Thanks Jim. Andrew (I'll just mark out a straight-edge and hold it up to the screen. I'll be trying your FontTweak next . . . Cheers.) |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
Hi Andrew_G decades ago we used to use a chinagraph pencil(grease pencil?) to mark places on the screen for character positioning so text looked nice and eberything lined up. That was on a glass CRT and it used to wipe off clean, dunno how you might get on with a modern plastic-fronted screen. might give you some ideas |
||||
palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1982 |
Don't really know what you are trying to do but after CaptainBoing's suggestion what about printing a grid on clear film and taping it to the screen. Paul. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
here is an idea that has been suggested before, but worth bringing up again as i see it has caught out yet another beginner: allow OPTION LCDPANEL ... and OPTION TOUCH ... to be placed in the first lines of a program. if the configuration matches what has already been set, the line should be skipped by mmbasic. if it does not match, then the configuration should be adjusted to match and mmbasic seamlessly rebooted and the program restarted. this simple change would remove a step that many folks seem to get caught up on. in the case of neither device being configured, 2 reboots would occur before the program finally ran past the first two lines. once the devices were configured, the first two lines would do nothing. and to allow for those embarrassing times when one manages to get to an unstable configuration, introduce a variation on the factory reset sequence, perhaps using a string of 20 '#' characters, that causes all OPTION settings (including LCD, TOUCH, and AUTORUN)to be ignored on startup, but the basic program area to remain intact. obviously, OPTION PIN ... should not be ignored. cheers, rob :-) |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1427 |
Second vote for that. I have gotten into the habit of putting all of that at the beginning of the program, but as a remark/comment, just to keep track. Micromites and Maximites! - Beginning Maximite |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
It is not quite as easy as that Rob, it is that way for a good reason. Configuration settings such as OPTION LCDPANEL need a reboot so that the pins could be reserved at startup, before anything else could get to them. When I was developing the code I got into terrible tangles trying to trap scenarios such as duplicated assignments because, if they were not trapped, they would often cause an exception (which is very bad). In the end I realised that configuring LCD panels etc is a hardware thing because they do not change when different programs were run - therefore the config commands do not belong in a program. Just think it through, if you embedded the settings in a program that program would then be non portable because one person's settings could easily be different from another's. Even the current system had problems with duplicate assignments causing exceptions during startup. These led to continuous reboots but I mostly fixed that in 5.2 which now monitors the startup sequence and erases any OPTION commands that caused an exception. Still not perfect but much better than the chaos that would ensure if the commands were embedded in every program. Sorry for the long winded answer but this question keeps coming up so I thought it best to give a full explanation. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
yep, i see the problem, hence the requirement that the lines be at the start of the program. things could even work thus: when the interpreter sees a line with OPTION LCD ... or OPTION TOUCH ... it does the following: 1. compare the configuration in the line to the current configuration. if it matches, skip the line (ie, do nothing). 2. if the configuration doesn't match then: 2.1 shut down the whole I/O system (deconfigure all pins and onchip peripherals) 2.2 carry out the configuration specified in the line 2.3 set AUTORUN on for the next reboot only 2.4 reboot micromite this would prevent any conflicts created at the OPTION line from causing an exception. i do realize that these configurations are a 'hardware' thing rather than a 'software' thing, but explaining that to the average user is not always so easy. also, it is worth remembering that LCD configurations can change if someone is using a micromite as an experimental setup on a breadboard. in that case, they are likely to want to have the ability to have their code reflect how they have just plugged things together. just my opinion, mind you. i don't use any of the colour LCD ot touchscreen stuff myself. cheers, rob :-) |
||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Geoff; I think I found an error in the PORT()= Command. The command states that any number of pins can be used.I just built up a 44 pin on a breadboard. I connected 33 test LEDs to all the available pins. I set all pins to DOUT. I wanted to make sure I had no shorts so I wrote this code snippet: ' uMITE 5.2 ver 5.02 40MHz The first version, with 33 outputs, sets both pins 43 and 44 when shifting 32 positions, only pin 43 should be set.DO INPUT "Test shifting bits";E FOR T = 1 TO E IF T = 1 THEN Out% = 1 ' Output to 33 Pins Each set to DOUT ' This doesn't work correctly for the top bits PORT(1,5,8,8,19,9,30,3,35,4,41,4)=Out% PRINT 5+8+9+3+4+4;" ";STR$(T,2,0);" ";HEX$(Out%,9) ' Output to 32 Pins Each set to DOUT ' This works correctly 'PORT(2,4,8,8,19,9,30,3,35,4,41,4)=Out% 'PRINT 4+8+9+3+4+4;" ";STR$(T,2,0);" ";HEX$(Out%,9) Out% = Out% << 1 PAUSE 20 NEXT T LOOP When shifting 33 positions neither pins 43 and 44 are set, pin 44 should be set. The second version, with 32 outputs, works correctly. (I suspect the OPEN() function has a similar problem but I haven't tested that.) redrok |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6268 |
I think the number is a signed 32 bit integer internally. That should explain the odd behavior of the top two pins. Jim VK7JH MMedit |
||||
| Page 7 of 11 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
