 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 : Weird GUI Numberbox
| Author | Message | ||||
| Malibu Senior Member  Joined: 07/07/2018 Location: AustraliaPosts: 260 |
G'day All, Not sure what I've done here, but I have weird things happening when I use the GUI Numberbox... Around 75% of the time it seems to do what it's supposed to, but sometimes it plays up. If I touch the NumberBox area on my screen, the background dims and highlights the numberbox area - but NOT show the actual 'keypad' on the screen. The numbers will work and I can enter a number (say "123") by 'guessing' where the numbers are located. As I enter each numeral, the number keys then show in full brightness (only the numbers I hit) By this time, if I select the "enter" key to finish up, the number is displayed on the numberbox area, the screen goes back to full brightness, but the keypad is shown ghosted and hides everything under it.... Here's the code that I'm trying to use gui NumberBox #64, 20,20,100,30,cYellow,cBlack and I'm using an MM+E 64 with an ILI9341 screen None of the other GUI controls seem to be a problem and here's a picture of what I'm blathering about...  It's got me baffled, so any pointers to what I've done wrong would be appreciated  John John |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
What version of MMBasic are you using? In the current beta (V5.04.10 beta 2 and 3) I messed around with the NUMBERBOX code so something could have gone wrong. But nothing was touched in previous versions so they should be OK. The randomness of the occurrence is a worry. That points to degradation of the signal to the LCD panel or the power supply. Do you have anything loading down the SPI bus. Final thing to check is your power supply. Try a solid lab supply, not a USB charger (these have very noisy outputs). Geoff Graham - http://geoffg.net |
||||
| Malibu Senior Member Joined: 07/07/2018 Location: AustraliaPosts: 260 |
Hmmmm.. Ok, the versions are throwing a bit of confusion my way, so I'll give you all the version numbers I can come up with... - The editor I'm using is "MMEdit Ver 3.7.3" for Windows according to the help (That's the latest version I could find to download) - The Upload Progress screen reports - "Micromite_Plus_V5.3 Version V5.4H detected". I can't find a V5.4 in the Syntax list, so I picked the latest one. - Running code of MM.VER gives "5.0408" & MM.DEVICE$ is "Micromite Plus" - and an "option list" command says - *OPTION LCDPANEL ILI9341, LANDSCAPE, 43, 42, 44 *OPTION TOUCH 45, 46 *OPTION SDCARD 12, 14 and those were taken from one of the PDF manuals (I don't remember which one at the moment) So now I don't know what version I have!  My wiring consists only of the LCD and touch screen, plus I have an SD card in as well. All of it runs directly from the USB cable from the computer. Just for quick and easy workflow, I haven't connected an external supply but I could try that. To check any voltage dips, I could hook up the Fluke meter to supply on the record function to check the MAX and MIN voltage levels if you think it might help. John As a post Note: I just ran your demo program for the MM+ (The modified one for the smaller screen) starting on page 45 of the MM+ manual and THAT NumberBox ran sweet 35 times... Hmmm, curious! John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
You almost certainly need a proper power supply. John |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Yes, the power supply is probably the issue. > Micromite_Plus_V5.3 Version V5.4H detected That is strange, perhaps something created by Silicon Chip. I would recommend updating to the latest version. Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
No, that's MMEdit not up to date with the current numbering system. H is the 8th letter so it is seeing version 5.408 Jim VK7JH MMedit |
||||
| Malibu Senior Member Joined: 07/07/2018 Location: AustraliaPosts: 260 |
Thanks to everyone for their assistance Ok, here's the morning's effort - I downloaded Ver V5.04.10 Beta3, fired up the PicKit3 (first time I've used that one, but I've used PicKit2 many times) I took a backup of the Version that was on the chip (just in case) and flashed the chip with the latest version... I had no screen connected, no SD Card in and power was supplied by the PicKit. All good on the verify, so I got everything wired back up, plugged in and windows did it's "doo-dup" for the connection. I started up MMEdit, got the right port (Com12) and in MM Chat, did an "option list" command, which came back with nothing - as expected... So, I sent the command OPTION LCDPANEL ILI9341, LANDSCAPE, 43, 42, 44 ... and restarted the board by unplugging the USB cable and got the "da-doop" Plugged back in, windows did the "doo-dup" and gave me an error on the driver. I did the usual windows driver stuff, but when I tried a re-install it said I already had the best driver. So...... I flashed with V5.04.09 and you can re-read the last paragraph for those results. A long story short, I'm now running the original V5.04.08 that I backed up with, windows is happy, the driver is happy and I'm back on Com12 again. Another "option list" command says I have my original options back in - as expected. I uploaded some code and everything is back to normal, so I don't know what that problem was either. Once i get myself organised, I'll try power from another source and see what happens with that attempt I'll keep you posted.. Speaking of separate power supply, is there any reason why I couldn't use a diode in place of J1 instead of fiddling with the jumper? I would guess that something like a schottky would be best? John John |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
With the EXplore64, I found it much easier to use a USB-TTL adapter and connect to the console pins. That way you ignore the inbuilt USB and can do things like reset and power cycle without loosing the USB connection. Windows doesn't like you playing with USB while in use. Separate power is also a mist for sanity. Jim VK7JH MMedit |
||||
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446 |
There are 2 things that may cause trouble. 1. That still feeds the USB power to your other input voltage (not good), so it would also need a blocking diode. 2. That is getting very close to the limits of what the LDO regulator can make work. The USB power is going to be slightly below 5V at the board (after the USB lead). With a low forward voltage drop Schottky it only leave a few hundred mV at best without sending the LDO below its required Vin so it can maintain the refgulated output voltage. That approach is normally used when there is more headroom between the supply voltages and the required output voltage. |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
@Malibu, As TassyJim said, Windows does some crazy things when you plug/unplug the USB. It can assign a different COM number and some programs won't pick up the new assignment. Even if the assignment stays the same, MMEdit for example, will not automatically reconnect. You need to close MMEdit, plug the USB in again and then re-start MMEdit (no criticism Jim, I love MMEdit and use it every day - thanks). You should never need to re-load any USB drivers. I use Teraterm to quickly check what COM ports are available, then close it and connect with MMEdit. As Jim said, during any sort of developement stage, it is a great deal easier to use a USB to Serial adaptor and power the MM via an external power source - that way when you power reset the MM, the USB connection (from the PC's perspective) stays active all the time. panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Malibu Senior Member Joined: 07/07/2018 Location: AustraliaPosts: 260 |
Thanks for the input I hooked up my Fluke for a while on 1ms record function to watch the power supply (just out of curiosity - I'll power externally once I get a few other jobs out of the way) ------------------------------------------------------------ Maximum: 5.045V, Minimum: 4.813V, Average: 4.959V over 1h32m ------------------------------------------------------------ I wouldn't have called it as being a problem, but I don't know a whole lot about power supply by USB systems... No probs, it's on the to-do list One thing I do know about USB's is that windows has a wobbly with plugging/unplugging, so I'm comfortable with that side of things. When I do disconnect, I find it's easier to leave the MM unplugged, reset the Comms connection in MMEdit, plug it back in and re-allocate the port. A bit of a hassle, but I know what windows does, so I'm good with that. What I didn't understand is why windows suddenly give me a port problem when I configure the screen, even though it was happy previous to the screen command. Again, it's on the to-do list and I'll play around with the firmware upgrades a little later... Thanks for everyone's help (I'll keep you updated as I try things)John John |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
The Explore-64 was designed before the wonderful 1455 USB chip became the now-standard way to connect USB to a Micromite, and also allow easy upgrading of the firmware in the PIC32 WITHOUT needing a PicKit-3 or the Microchip IPE. The built-in USB on the PIC32 chip is technically under control of the PIC32 core - and that is fair enough. But what that means, is that when you press RESET on the E64 or earlier model E100, the core restarts. Windoze then throws a fit, and drops the VCP(Virtual COM port). The only way to get it back, is to remove the USB plug and put it back in again. This is such a PITA, that the native PIC32 USB connection has now been discontinued. All of this was only discovered after some testing with the E64 and E100 module. The MMX has a 1455 chip, the latest versions of the E100 have a 1455 chip. The E64 does not, mainly due to space restrictions. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Malibu Senior Member Joined: 07/07/2018 Location: AustraliaPosts: 260 |
I'm happy to say my numberbox mystery is solved  I shelved the idea of using a numberbox, but it bothered me that I hadn't worked out what the problem was, so I added some temporary code in to try and get to the bottom of the NumberBox problem. With putting the code in exactly how the rest of the code is structured and basically how I had it previously, the problem popped up again right away - the ghosted keypad. Then in a "What was I thinking?!?!?" moment, I realised that my TOUCHUP interrupt is probably way too long. At 106 lines of code, the poor uController was having a brain-freeze trying to keep up. So... I wrote a new SUB, put all of the interrupt code in that and set a flag in the interrupt to get dealt with elsewhere... Aaaaahhh, that was it... I used the keypad over 100 times and it didn't miss a beat! Ooops, a basic mistake that's caught me more than a few times before now.  Thanks for everyone's help! (Oh, and I have an external supply hooked up now) John John |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
As Grogster said... "Thou shalt not hang around or process code in interrupts." Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Yes, you must not spend any real processing time inside interrupts. I did the same as you, when I was learning the GUI controls. It's natural to think you should put all that you want to happen inside the interrupt, inside the interrupt.  I also used to get odd things happening when I would put the code in the interrupt, so I know what you have just been through. It really does require that you rethink your approach to the code, and I pretty much have settled on just setting and clearing flags, usually with a single IF/THEN/ELSE statement, then exit the interrupt so the main loop takes command of the ship again. It is really easy to check the flags - ANY flags, outside of the interrupt. Essentially, your interrupts should be ASAP - As Short As Possible.  Glad you got it sorted. You will have noted how having the interrupt so long, DID create a very obscure bug, which is never a good think unless you LIKE scratching all your hair out.  EDIT: Actually, when I just looked up some of my interrupts, I use SELECT CASE rather then IF/THEN/ELSE, but the concept is the same. Just set or clear flags. As an example, my interrupt for OK and EXIT buttons used on lots of pages - this is how the system detects them, and the main loop waits for one of those flags to become true, then it does the work. Loop until LCD_OK kind of idea. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Malibu Senior Member Joined: 07/07/2018 Location: AustraliaPosts: 260 |
"Amen!" to that! It's funny though, I already knew that from hard learned lessons in assembly code on 16F's... I was kicking myself when I realised what I had done. Maybe I just spent too long coding in VB6 and forgot all the "good" coding rules. Here's what I finished up with sub TouchUp TouchControl=touch(LastRef) Touched = 1 end sub The code stays in a DO:LOOP until I get the flag set, then it operates on which button was touched. MUCH better! John John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
MUCH better, indeed. That's a lovely little interrupt now. Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
