 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.4 Requests
  Page 2 of 2 |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I still have a HP deskjet 500 and use Parker ink to refill the cartridges. Now i thnik of it that thing is already more then 25 years old. Still works. :) Back to topic. I think MMBasic is pretty good and has lots of features. If something is missing then it often can be made to work with just a few lines of basic. I would vote for the 1-wire search function as that is a tough one in basic and it is very useful. Microblocks. Build with logic. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
I have thought long and hard about this. With the existing GUI controls I tried to pick the common requirements (eg, GUI LED) or the impossible to implement in BASIC requirements (eg, GUI TEXTBOX). The problem is that there is an almost unlimited list of additional controls (with a myriad of configurations) that could be implemented - and it is futile trying to cover this need by adding more controls. Previously it was difficult to mix ordinary graphics (LINE, BOX, etc) with GUI controls because a pop up keypad would mess up the screen. But with V5.4 (due soon) the touch down interrupt will occur before the keypad is displayed. This gives the programmer the opportunity to redraw their graphics to suit (eg, display in a dull colour). This change removes the last impediment to mixing basic graphics with GUI controls. As a result, I do not have have plans for any more built-in GUI controls that could be implemented using ordinary graphics. Geoff Geoff Graham - http://geoffg.net |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
As I've mentioned elsewhere, I've had fairly good success under 5.2 & 5.3 with regards to using TEXT on pages with limited GUI elements. No elements that popped up number or keypads; Some checking was required when pages changed to ensure clean redraws. The one thing I did find to cause an issue under 5.3, When I decided to try out the GUI LED blink option. On implementing this, I began to get screen corruption. The GUI LED was always set before the TEXT writes to the pages. When the blink timeout is reached I assume what could be happening is that the "Cursor" location is left at the LED position. If the LED was to turn off mid way thru a TEXT string write the corruption would occur; always around the location of the LED. So I suppose the real question is, using this rough example, [Code] GUI LED.... to be on for 200ms, bottom centre of screen PAUSE 195 .... guessing write times TEXT "The Quick Brown Fox".... written say top left, [/code] I'd be expecting what is happening is that if the TEXT command had got as far as writing "The Quick Brown" when the LED was switched off, then the " Fox" would be written somewhere related to the GUI LED's co-ordinate location. Incentive to use the TEXT command:- 19 Data fields & descriptions on a particular E100 screen. Very easily laid out & readable. Would require 38 GUI objects on top of the 19 Variables. And while good in some places, the borders on objects can be cluttering in some layouts. It would be great if they could be supressed. (Width 0?). Cheers Phil. the happens |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Good thought Grog, A Function could help, PinType(Pin, Type), eg PinType(17,"DOUT") could update the 17th element of an integer array. A 28 element integer array wouldn't waste too much RAM even if it was mostly empty. Phil. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Phil, I think that your issue is caused by MMBasic updating the "next position to write text to". I will have a look a it but expect more questions if I cannot figure out exactly what the issue is, Geoff Geoff Graham - http://geoffg.net |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Thanks Geoff, Will add, The LED on state is triggered by coms reception interrupt, hence there is a random nature of the timing. It is not possible for it to turn on mid Text write, but the turn off of blink could time mid write. Initially the display will be clean, takes time for the random "miss placed" writes to occur. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Thanks Phil, it is a bug. When the LED is turned off it also rewrites its caption which is what screwed up your TEXT command. This will be fixed in the next version. Geoff Geoff Graham - http://geoffg.net |
||||
| sawasdee01 Newbie  Joined: 23/12/2016 Location: United KingdomPosts: 33 |
Hi Geoff, I realise that this is 'rather late', but having watched the development of the Micromite Extreme and the PI version, I am starting to wonder whether there isn't a future for the Micromite standard and Micromite Plus as a first class wearable / mini sensor / other battery powered platform. With this in mind, it would be great to 'build out' the power saving measures. Number one for me, would be the enhancement of the CPU SLEEP command to allow sleeps with a granularity of either a tenth of a second, or (ideally) a hundredth of a second. The current sleep granularity of one second does not work well in a semi-real time inner loop - eg see 'bodge' below:- DIM DATA% DIM LASTDATA% DO WHILE(1) DATA% = READ_SENSOR%() IF DATA% <> LASTDATA% THEN SEND_VIA_REST(DATA%) UPDATE_LCD_DISPLAY(DATA%) LASTDATA% = DATA% ENDIF UPDATE_LCD_TIME() SLEEP(1) LOOP Because the granularity of sleep is limited to 1 second, the code shown above suffers from a number of shortcomings, namely:- - the maximum rate at which the sensor can be read is only 1 time per second - the maximum rate that the LCD can be updated is slightly more than once per second. If the LCD displays HH:MM:SS, the seconds will appear to 'jump' periodically. - No allowance for long running routines can easily be made (eg SEND_VIA REST()) Maybe, almost exactly the same battery savings could be achieved with the routine below, if a sleep could be made to be scalable in tenths of a second. DIM DATA% DIM LASTDATA% DO WHILE(1) DATA% = READ_SENSOR%() IF DATA% <> LASTDATA% THEN SEND_VIA_REST(DATA%) ' This routine takes approx a tenth of a sec UPDATE_LCD_DISPLAY(DATA%) LASTDATA% = DATA% ELSE SLEEP_TENTH_SEC(1) ' When sensor data has not changed, sleep 0.1 sec ENDIF UPDATE_LCD_TIME() ' LCD time updated 10 times a sec - ie no jumping LOOP Apologies, if the code isn't exactly right - it is supposed to convey a concept, only. Other super useful power saving features might be 'wake from watchdog', wake from low power CPU timer, etc. Anyhow, Micromite is a fantastic product and it is great to see the forum alive and well. Best wishes. Sawasdee |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Unfortunately sleep increments of one second is the minimum that can be achieved without any external circuitry. Basically there are two ways that the PIC32 can be woken up from sleep. One is an interrupt which is how the basic SLEEP command works - it sets up an interrupt on the change of pin state and it is this interrupt that wakes the processor. This would be the best way for you to achieve short sleeps - build a simple low power oscillator which generates a pulse on the wakeup line every millisecond (or whatever interval that you need). The other way the PIC32 can be woken is when the watchdog timer goes off and that is how the timed sleep (SLEEP seconds) works. The watchdog timer is set to one second, when it goes off the processor is woken up, it checks if enough seconds has passed and if not goes straight back to sleep. The issue is that the minimum watchdog time is one second. The PIC32 used for the Micromite is not really designed for ultra low power operation. Microchip have recently introduced a new ultra low power PIC32 family but they do not have the memory capacity to run the BASIC interpreter. Geoff Geoff Graham - http://geoffg.net |
||||
| Page 2 of 2 |
|||||
 Print this page |
