Jump to content

woodstock

Members
 View Profile  See their activity

  • Posts

    13

  • Joined

  • Last visited

 Content Type 

Posts posted by woodstock

  3. GINPUT IRQ-based touch driver

    in Support

    Posted

    I should also add that I've just discovered some issues in relation to the PENIRQ signal itself.

    The problem is PENIRQ seems to reset when conversions are performed on the touch driver, therefore multiple edge triggers occur during the conversion process without the touch being removed (i.e. finger lifted off panel). Whilst I can't actually confirm this behaviour without an oscilloscope, I'm pretty sure that's what's happening.

    One potential solution I thought of is to have a mutex or semaphore or similar associated with the touch driver. Whilst performing the conversions etc. this mutex/semaphore/global should be owned or flagged by the low-level driver. Meanwhile the external interrupt callback should ignore any triggers while this mutex/semaphore/global is locked/flagged.

    Or.... we can simply disable the particular external interrupt during the LLD 'get' procedure... I'll try that and see if it improves anything.

    [EDIT] adopting the above approach of disabling the interrupt during the 'get' procedure I can reliably (I think) detect the initial touch and then the final release in the interrupt. This introduces a new problem however. Previously the interrupt was continuously triggered whilst the panel was pressed, which allowed the touches to be continuously registered whilst the panel was pressed. Now I only get two triggers: touch down and touch up.

    [EDIT^2] I've added in another little snippet of code at the end of my 'get' function that calls _gmouseWakeup() if the PINIRQ is triggered at the end of the routine. i.e. after performing one read of the touch driver check to see if the panel is still being pressed, and if it is jab the timer and set the NEED_READ flag. This overcomes the problem I described at the end of my last paragraph. Using code from the touch_raw_readings demo I am getting output as expected. However, button presses are not working reliably.

    [EDIT^3] I have narrowed down the strange behaviour of button presses to something in the GetMouseReading() function, but it's going to take a while to figure out exactly what's wrong. At this stage I'm guessing it has something to do with the update rate being too fast as a result of the IRQ method (rather than slow polling).

  4. GINPUT IRQ-based touch driver

    in Support

    Posted

    I've (kind of) implemented IRQ-based functionality for a touch driver (ADS7843) on a STM32 running ChibiOS, but I'm not certain if I'm doing it right...

    I have done this by setting up an external interrupt with a simple callback function that jabs the mouse timer and sets the GMOUSE_FLG_NEEDREAD flag:

    static void extcb(EXTDriver *extp, expchannel_t channel) {
      (void)extp;
      (void)channel;

      GMouse *m;
      // Find the instance
      if (!(m = (GMouse *)gdriverGetInstance(GDRIVER_TYPE_MOUSE, 0)))
        return;

      chSysLockFromISR();
      _gmouseWakeupI(m);
      chSysUnlockFromISR();
    }

    Since GetMouseReading(m) (which is what I believe does the actual work here) is a static function, we are not able to call it externally, hence why I have chosen to use the _gmouseWakeup() function instead.

    I assume that the idea is to set GINPUT_MOUSE_POLL_PERIOD to TIME_INFINITE in order to not waste time polling the device, however I encounter some problems when doing so.

    When setting the GINPUT_MOUSE_POLL_PERIOD to TIME_INFINITE the standard calibration routine does not recognise any touches (despite the driver's 'get' function being continuously called as expected while the panel is being touched). Additionally, when disabling the calibration routine, the system recognises a touch but (for example) will never release a pushbutton because there are no more interrupts to tell the system to recheck the touch device and determine whether or not the button is still being pressed.

    When setting the GINPUT_MOUSE_POLL_PERIOD to something sufficiently small (i.e. 10 ms) the calibration routine works fine (as does normal GFX operation); whilst setting GINPUT_MOUSE_POLL_PERIOD to something much longer (i.e. 1000 ms) results in the calibration routine not 'continuing' to the next point until up to one second (or whatever polling period is chosen) after the touch has been released.

    Also, when applying the GMOUSE_VFLG_NOPOLL flag to the touch driver, I get absolutely nothing... This is actually expected when using the approach that I have implemented due to the short-circuiting in line 327 of input_mouse.c (in the MousePoll function), although this is possibly intended to be the case.

    My question is, how should I be implementing IRQ handling for a touch driver?

    Do I need to implement some sort of routine that checks for a 'mouse up' and calls _gmouseWakeup() in a similar way to what I'm doing with the IRQ handler?

  5. [Feature] GWIN virtual keyboard

    in Development and Feedback

    Posted

    I'm struggling to get this feature working. I've borrowed the relevant code from the modules/gwin/textedit/ demo and switched on the required features in gfxconf.h, however I get the following linker error:

    undefined reference to `GKEYBOARDVMT_OnlyOne'

    I have noticed for touch devices, a VMT structure (i.e. GMouseVMT) is statically initialised in the LLD file for the particular touch device and this is how the VMT list is populated (I think), however such a driver or static initialisation does not exist for the Virtual Keyboard (as far as I know...).

    I must be missing something incredibly obvious here. :?

    Thanks in advance!

  7. Issue with GFX_COMPILER and TRUE/FALSE

    in Development and Feedback

    Posted

    Another preprocessor definition-related problem: when gfx.h is included it defines TRUE and FALSE before including gfxconf.h. This is definitely necessary, as pointed out by the comment immediately preceding those two definitions, however neither GFX_COMPILER_ARMCC or GFX_COMPILER_KEIL have been defined by this stage – hence the compiler warning. This is a new warning as a result of the ff01cc0 commit 'Adding GFX_COMPILER_ARMCC and GFX_COMPILER_KEIL'.

    The real problem here though relates to how (I think) this is interpreted by the preprocessor. It is my understanding that if GFX_COMPILER_ARMCC and GFX_COMPILER_KEIL have not yet been defined they will be treated as a value of 0, which would match the value of GFX_COMPILER if it has been set to GFX_COMPILER_UNKNOWN (or if it has not been defined itself). So I think the preprocessor statements on line 39 of gfx.h will always be evaluated as true (unless these defines have been made prior) and therefore TRUE will always be defined as 1.

    Another potential issue I have picked up is discrepancies in the definition of TRUE for GCC/ChibiOS. First up, I have noticed that TRUE is defined as -1 in gos_chibios.h, whereas it has been defined as 1 in ChibiOS/os/rt/ports/ARMCMx/compilers/GCC/chtypes.h and various other GCC-port files within the ChibiOS source.

    I'm sorry I don't have any solutions this time. :?

    Beta

    in uGFX-Studio

    Posted

    I think the table approach is great. Again, very similar to other GUI editors such as Visual Basic – hence it will provide a familiar environment for many developers. The drag-and-drop approach to adding widgets from a tree-based 'toolbox' is also a great addition.

    Another idea: copy-paste for widgets. Makes it much easier when you want to make multiple widgets that have the same settings.

    Keep up the great work! Happy to help where I can.

    Beta

    in uGFX-Studio

    Posted

    Looking forward to the next release! :D

    Another feature that might be useful to have (maybe someone has already suggested this) would be the ability to edit additional widget properties such as the label attribute (gwinLabelSetAttribute) through uGFX-Studio.

    Another much more advanced feature (I would not expect this for a while...) would be the ability to easily link the functional aspect of the GUI to the graphical aspect through uGFX-Studio like in MS Visual Studio. Although it's been many years since I last used Visual Basic, it was possible to "double click" on a particular GUI element (say a button) and it would open up a source file with an empty call back function. Whilst in the case of uGFX this kind of functionality is highly dependent on the user's implementation, it might be something to think about in some way. I'm just trying to think of how it might be possible to totally decouple the GUI building process from the actual functionality.

    Beta

    in uGFX-Studio

    Posted

    When using uGFX-Studio 0.8 (Win7) I have found a bug in the code generator:

    Two lines of initialisation code for the gwinList object appear to be missing, and without which the widget does not appear on the screen. These two lines are:

    	wi.customDraw = 0;
    	wi.customParam = 0;

    I would also like to add my support for a feature that would allow user code to be retained, OR perhaps a feature that allows GUI code to be generated in a separate source file which would be called from another source file containing the main() function. The 'main' source file could initially be created from a template that allows it to be compiled for preview, but should not be affected when code is regenerated – i.e. it is decoupled from the GUI. This way I can develop my GUI and preview it on PC and then copy the GUI source file into my embedded project without any need for modification.

  11. ChibiOS 3.0.x support

    in Development and Feedback

    Posted

    I'm not sure what your stance is on supporting ChibiOS 3.0.x vs 2.6.x, but I have noticed one bug when using ChibiOS 3.0.x and there may be others that I have not encountered.

    I've just noticed that in another source file you appear to support both major versions of the kernel through the preprocessor define CH_KERNEL_MAJOR. I have created a patch that uses this define to switch between two different chunks of code, however you may want to do something like the following instead:

    #if CH_KERNEL_MAJOR == 2
        #define MSG_OK      RDY_OK
    #endif

    patch.patch.zip

  12. "GFX_USE_OS_RAWRTOS" is not defined

    in Development and Feedback

    Posted

    Thank you for your help and for the commit.

    I should have noted that I have the following warning options enabled: -Wall -Wextra -Wundef -Wstrict-prototypes. Although I do like to be thorough with my warnings, maybe this is a little excessive...

    For small contributions (like this one), is it worth opening a new thread just for that single contribution?

    The reason I ask is because I have found another bug (I think :D ). See attached patch (I was not able to upload a *.patch file, so had to zip it as per your suggestion).

    patch.patch.zip

  13. "GFX_USE_OS_RAWRTOS" is not defined

    in Development and Feedback

    Posted

    Hi,

    I am very new to uGFX (discovered it two days ago!), but I have to say it is fantastic! :P

    When I compile my project with uGFX I get many warnings about "GFX_USE_OS_RAWRTOS" not being defined:

    ugfx/src/gos/gos_rules.h:27:140: warning: "GFX_USE_OS_RAWRTOS" is not defined [-Wundef]

    While this is not an error, it is slightly annoying. I have fixed this in my own working copy by adding the following lines into gos_options.h:

        /**
         * @brief   Use RAWRTOS
         * @details Defaults to FALSE
         */
        #ifndef GFX_USE_OS_RAWRTOS
            #define GFX_USE_OS_RAWRTOS      FALSE
        #endif

    I have attached the patch for this. Does anyone else also get this warning?

    Using arm-none-wabi-gcc (version 4.9.3), Eclipse, ChibiOS 3.0, Mac OSX 10.11, compiling for STM32F103.

    I am also quite new to version management and working on open source projects, so I would like to ask what is the usual procedure for suggesting fixes like this? Should I submit a pull request?

    Woodstock

    [EDIT] It appears I cannot upload the attachment...

×
×
  • Create New...