 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 4 of 11   |
|||||
| Author | Message | ||||
kiiid Guru  Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Geoff, may I request some currently missing functionality, please? I am sure it shouldn't be too hard to implement and so far I have not been able to find a workaround for its lack. I am looking for a way to force the touchscreen keyboard on screen and start using it as console input until the "Cancel" button is pressed. Ideally there should be a "Ctrl" button as well, so one can do Ctrl-C and other similar combinations. http://rittle.org -------------- |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Yes, I have thought of this one but there are a few issues. Firstly, how is this keyboard activated? If is done by touching a control what happens to that control when the keyboard appears? Another question - is this really useful? All you could do is type some commands at the command line. The small window would be useless for the editor, especially if the function keys are non existent or difficult to get to. The biggest problem is getting the SSD1963 controller to scroll just part of the screen while leaving the keyboard in place. The way that the current driver is written that is not possible and from my reading of the data sheets I don't think that the SSD1963 could ever be made to do it. There are some things that are not practical or possible - and I think that this one falls into that category. Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Actually I didn't look at it in such complicated way. Rather by having some option, so if the screen is touched where there are no controls, the keyboard appears so it can replace a physical one to enter something just like it is coming from the console. So all functions such as inkey$, input, etc can take their input from there. There is no need to care about scrolling half panel and so on. This can make a number of projects which are currently impossible or very difficult, much easier to do so I think it is worth it. Note that in this case I am looking from point of view of an embedded device, not a computing system http://rittle.org -------------- |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Maybe use a small always on top 'button'/'image' in a corner of the screen and once pressed it will pop up a keyboard which input goes to the console/inkey/input. Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
How could we replace scrolling? This is an integral part of the console. The only thing I can think of is to blank the entry area and return the cursor to home every time ENTER is used. Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
How about not printing anything on the screen but calling a feedback function instead on every pressed key? Thus the user can organise their own screen output which is a quite simple task http://rittle.org -------------- |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2932 |
Having a 'console touchscreen keyboard' would be extremely useful as kiid suggests. HOWEVER, Geoff is concerned about all the console features that require screen scrolling. This primarily includes commands such as 'LIST', 'FILES', and most importantly the whole functionality of the EDITOR. It must be remembered that every time a command is entered at the Command Prompt, then the screen potentially scrolls up to show the 'new' Command prompt on a new line (and possibly to also show the result of the command typed). All this 'scrolling' is what concerns Geoff as the onscreen keyboard needs to be 'static' in position - something the SSD is not good for as I understand). The only thing I can think of as a solution is to 'split' the display into two 'virtual screens' and have the keyboard on one of the 'virtual screens' (and static), and then the reduced size console displayed on the second 'virtual screen'. This may need a to be under software control if the SSD is 'limited'. If matherp hasn't already done so, this is one for him to chime in on as he is very much the 'display expert' and will know whether there is a potential solution. . . . I hope it is possible to solve the above as it would make a MM tablet a reality  WW |
||||
| Nathan Regular Member  Joined: 10/01/2016 Location: GermanyPosts: 49 |
Hi Geoff, What about a reduced scrolling area? Something, which can be defined by command 33h? (Most displays support a reduced scrolling area) Nathan |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Interesting, I will dig out the data sheet again. Geoff Graham - http://geoffg.net |
||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Geoff; Since these micros are CMOS inputs have quite high input impedance. Also, I understand upon reset these micros initialize all pins as inputs until told to be otherwise. Good engineering practice teaches us to not leave unused inputs floating. If floating near the threshold the chip will cause a small increase in VCC current. This happens even though the inputs employ Schmitt triggers. When I write programs I first initialize all the unused pins with pulldowns to prevent them from floating. My suggestion for ver5.3 would be to set all pins to SETPIN DIN,PULLDOWN when powering up or after a reset. This would save some memory because I wouldn't have to do this initialization in the uMITE program. What do you think? Are there other problems, possibly when coming out of sleep mode? redrok |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
changing the mode of pins, unfortunately, may break existing code and/or designs. how about having a persistent option for the default state, something like: OPTION PINMODE PULLUP | PULLDOWN | FLOATING that defines the 'unassigned' state of all unused pins. ie, when a pin's mode is changed the unassigned state is overriden, while when a pin is deassigned (for whatever reason) the state is set back to PINMODE. the factory default would be: OPTION PINMODE FLOATING hence preserving backward compatibility. because the option is persistent (like autorun), it would be applied even before the user code starts running (at least after the very first run of the program). cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
My answer to this is just test it as I did. There is no extra current. Geoff Graham - http://geoffg.net |
||||
| Nathan Regular Member Joined: 10/01/2016 Location: GermanyPosts: 49 |
Hi redrok, please take a look onto the following side, too. dafaultPin You can use the C-function for seting all unsed pins to a specified state. No idea if it is used by someone else as me. Nathan |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
I got a simple one... when pressing CTRL-C, could we have the line number where the break was detected? MMBasic already keeps track of the line number for error reporting so I am hoping it's fairly straight forward to output it on a break (?) Would help a lot in debug... something like: <ctrl-C> Break in 177 > |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
It would be great to have a few permanent options at user's disposal. Something like OPTION USER1 "something" On the surface this looks like something that can be covered by the VAR SAVE/RESTORE pair, but it isn't. The reason for these would be to configure some options specific to the user's particular board. People who understand C could consider these as some distant equivalent to the #define in the preprocessor http://rittle.org -------------- |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2932 |
@Geoffg Can the FONT command be 'tweaked' from a single scaling parameter, to two scaling parameters; with the two parameters relating to width scale (x), and height scale (y) ?? This would then allow for example: Double width with: FONT [#]font-number, 2 [,1] Double height with: FONT [#]font-number, 1, 2 Thanks for any thoughts/feedback WW |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
@WW I looked at that some time ago (when you asked last). I cannot remember exactly why but it was not possible with the way that fonts are handled. I will re look at it because it would be a handy feature. @kiiid I must be dense but exactly why can't you use a saved variable? It seems like the solution. Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
The saved variables are killed by NEW command. I am talking about more permanent options which can be set by the user to accommodate some specific needs for board configuration http://rittle.org -------------- |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
can the library area not be used for holding such configuration? cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
i've a few of suggestions for the 5.3 version, with my particular interest in 28-pin micromites. i am sure some of these have been suggested before, my appologies for any repetition: 1. built in support for BMP180/280 pressure sensors. these can return both the current air pressure as well as the temperature. while these are I2C devices, the calculations required to return temperature and pressure are quite complicated and far safer if not left to the novice programmer. this would complement the current support for DS18B20 (temperature), DHT22 (humidity), HC-SR04 (distance), HD44780 (2-line LCD), servo, keypad and RTC that are available out-of-the-box for beginners. 2. on the MX170, moving as much as possible of the colour LCD support into the LIBRARY to enable freeing up flash space for other routines that the user may wish to use instead. over time the available colour LCD controllers from ebay will change, and having specific drivers hard-coded poses a risk. also, there seems no reason why combined library + program memory need not be 70k, 80k, or more. 3. make the library editable with a LIBRARY EDIT command. this would likely require someone writing a c-function expander. it would make the library space far more accessible to users. as always, the above are just my opinions. comments? cheers, rob :-) |
||||
| Page 4 of 11 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
