Announcement

Collapse
No announcement yet.

Very strange problem with the LCD43 and 4DGL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Very strange problem with the LCD43 and 4DGL

    I'm finishing up a 4DGL program with my LCD43 (non-touch version) and I've encountered a very odd bug that has me quite stumped. I have an 8 position rotary switch hooked up to the bus_In() pins and have the code written to switch to certain graphics depending upon the position. I have no issue with the screen responding properly to the switch position and displaying certain graphics accordingly, so I'm certain it is NOT a hardware problem. I've also tested playing wave files and these too work wonderfully. But, if I have the code set up to play a wave file in between "mode" changes, then whenever I switch to the first or second positions, my screen goes black and graphics will not appear again until I do a power reset. The wave file will continue to play properly though every time the switch turns, but my graphics have vanished. This only happens if I switch to the first two positions, however the graphics and sound responds properly if I only switch between the last 6 "modes" which I find strange as they all contain only simple text and gfx functions with nothing worth noting in the first and second modes(I've already tried commenting out the code with these modes and replacing it with graphics from the other modes, but this has no effect, neither does changing which wave file is played). Here's the main part of my code with the filler graphic functions removed:
    mode := bus_In();
    if (mode == lastMode) drawn := 1;endif
    if (mode != lastMode) gfx_Cls(); lastMode := mode; drawn := 0; file_PlayWAV("beep.wav"); endif
    if (mode == 127) //mode 1 essentially if(drawn == 0) //draw graphics functions here etc. endifendif
    if (mode == 191) //mode 2 etc....
    Anyone have an idea what might be going on? The code in each mode only differs in what text is printed and where rectangles are placed, so I can't see how switching to the first two is causing an error.

  • #2


    I'm wondering if your power supply is marginal.



    The uSD card is usually the first thing to play up when the 3.3v gets too low.



    I'm guessing the sound (which draws a bit) is dropping the 3.3v far enough to cause the the uSD to lose itself
    Mark

    Comment


    • #3


      The uLCD43 is powered from a full power USB 2.0 port. The wave files always work, and the graphics will work too (including images from the SD card), but only if I only switch between my last six modes, which simply doesnt make sense as they are all virtually identical. Also, by graphics I mean calls to the print(), gfx_rectangle(), gfx_line functions etc So shouldn't these continue to display regardless if the SD card resets itself?

      Comment


      • #4


        Sorry, without seeing your full code that's all I could suggest.



        Sometimes when the uSD 'browns out' it locks up any I/O to the card, so your gfx_ functions not working maybe because the display is still waiting for the uSD for a previous setting.



        Hmm, wave files always working pushes it back in the other direction.



        Some manufacturers have been 'greening' their computers by cutting back the amount of power available to USB ports, quite silly, but anyway.



        Can you zip up all the code (i.e. .4dg, .4dvisi and the folder 'beneath') and either put it here, or email it to mark at 4dsystems dot com dot au and I'll have a proper look
        Mark

        Comment


        • #5


          Thanks! However I did try powering it by plugging the USB into an Apple USB wall wart, which certainly provides enough power at 5v/1000mA. No luck This bit of code is purely a cosmetic feature in my project so it's no big deal. The uLCD43 I'm using is part of a much larger secret project that I'm entering into a few contest in a few days, so once everything's set up, I will release all source code and supporting data to the masses, including on the 4D Systems forums. Thank you for the quick correspondence though! I really do appreciate it, you guys make awesome hardware

          Comment


          • #6


            Hard to tell without seeing your code, but it could be a result of contact bounce or make-before-break on your switch. It is possible that your code is seeing multiple pins active from the switch at the same time.
            Make sure you handle invalid states by resampling the switch, otherwise you may clear the screen, and get stuck in a state where you have no valid input.....
            _______________
            Best Regards,
            Howard

            Comment

            Working...
            X