Jump to content

woodstock

Members
  • Posts

    13
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As a result of commit [45174c4] 'Fixing conflicting type qualifiers for ‘VirtualKeyboard_English1’', I get the following warning in function 'gwinKeyboardSetLayout': warning: assignment discards 'const' qualifier from pointer target type. I have attached the patch file that should fix this. patch.diff.zip
  2. Yes, turning off GINPUT_NEED_KEYBOARD fixed this problem – silly me :oops:. [EDIT] just remembered that I had to make a small fix to get it working. I'll send a pull request shortly.
  3. 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. 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. 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!
  6. Thanks for the fix, but I still get warnings on line 60 of gfx.h for the same reason (this time in relation to define the inline keyword). Again, I think this means that the #if statement will always be evaluated as TRUE. I should mention, if you haven't figured out already, I'm using GCC.
  7. 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. :?
  8. 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
  9. 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 ). See attached patch (I was not able to upload a *.patch file, so had to zip it as per your suggestion). patch.patch.zip
  10. Hi, I am very new to uGFX (discovered it two days ago!), but I have to say it is fantastic! When I compile my project with uGFX I get many warnings about "GFX_USE_OS_RAWRTOS" not being defined: 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...