steved

Just come across this thread: http://forum.chibios.org/phpbb/viewtopic.php?f=13&t=1637 which explains the original error - possible wrong version of msys-1.0.dll

I have a widget which has to be able to redraw just a fixed part of the area it occupies on the screen (it's displaying a changing value within various fixed information). Is there an intended way to signal a partial redraw, such that the widget can determine whether it needs to update the whole display area (e.g. due to closing another window) or just the value part?

Here's the driver interface I'm using with the INT070ATFT. I've basically done a diff between my working copy of ugfx and the latest trunk repository, so there may be a few irrelevant files there. Note that I've modified the standard mouse driver to give the option of storing calibration data in a central repository (rather than being a bit application specific); the additional files for that are posted in the development section of this forum. Tectu - still using the 'old' mouse interface, so if you get the chance to modify what I've done I'm happy to test. UGFx_my_mods_161014.zip

Wait until the morning - I've got that display (and touch screen) working, but the driver hasn't made it into the repository yet. I'll upload it once I'm at work.

ChibiStudio actually ships with gnu mingw-32 make. There's a batch file start.bat that also ships with ChibiStudio which should be used to start eclipse: @echo off set PATH=C:\ChibiStudio\tools\gnutools\bin;%PATH% set PATH=C:\ChibiStudio\tools\openocd\bin;%PATH% set PATH=C:\ChibiStudio\tools\GNU Tools ARM Embedded\4.7 2014q2\arm-none-eabi\bin;%PATH% set PATH=C:\ChibiStudio\tools\GNU Tools ARM Embedded\4.7 2014q2\bin;%PATH% cd eclipse start eclipse.exe mingw-32 make is in the C:\ChibiStudio\tools\gnutools\bin directory. Possibly starting eclipse directly, rather than using the batch file?

It does. I think its from here: https://launchpad.net/gcc-arm-embedded Certainly my experience of using ChibiStudio is that it 'just works' - just need to modify the path to ChibiOS in the make file if you copy a demo project into the workspace.

These lines: 0 [main] sh 8212 sync_with_child: child 6808(0x168) died before initialization with status code 0xC0000142 28 [main] sh 8212 sync_with_child: *** child state waiting for longjmp /usr/bin/sh: fork: Resource temporarily unavailable suggest to me some sort of installation/setup error with ChibiStudio, or possibly a problem with the PC itself. Never seen that type of error myself, but have had problems sometimes when Windows decides to 'lock' a directory so that make can't access or delete it.

Thanks for this - makes sense to have a uniform behaviour. Actually the event sending action needed adding in two places, not one. The attached works on a quick check - note that if the event is sent before the _gwinDestroy() call, it appeared to lock up the system. However I'm not sure whether the line I've added is accessing freed up memory - certainly it would be logical to send the event prior to the _gwinDestroy() call. Also note a possible typo around line 312 where I've made a change (not tested) frame.zip

The recently updated frame handler is much more memory efficient, but a side effect is that we've lost the ability to notify a frame close (destroy) event. Previously I assigned a tag value to the 'frame close' button, so got an identifiable touch event on frame close, which I could use to reset some of my own logic. I can see possible ways to restore this functionality - probably by triggering a button event on close if the frame tag value is non-zero. Any better ways?

Are undefined preprocessor symbols handled consistently across compilers? Defensive coding might suggest: #ifdef tskKERNEL_VERSION_MAJOR #if tskKERNEL_VERSION_MAJOR == 8 /* Types for 8.x */ #else /* Types for 7.x (and lower?) */ #endif #else /* Types for 7.x (and lower?) */ #endif

They are hardware drivers for the SPI - if you use chibiOS they are already implemented as part of the operating system. There are no doubt similar routines in other embedded RTOS.

I took the view that we don't care where the tag comes from; our only concern is that if it's non-zero we process it, and carry out some action determined by the tag's value. So zero for 'do nothing' is convenient.

Unless its well buried, looks like the passed parameters determine the overall window size. The 'raw' border information is already available through the VMT (type gcontainerVMT), which supports methods to return the width of each of the four borders. So its really a matter of how this information should be made accessible. (I imagine one could access the VMT routines directly, and do the relevant calculations, but I feel its a method that should be embedded in the container class to ensure the flags are handled correctly, and to allow for future possibilities.)

Its that option - I know the required size of the client window, so need a generic method to set the correct overall window size (which obviously has to happen before the window is created).

If creating a frame with a border and suchlike, the size of this 'overhead' reduces the available window area. It would be useful to know the size of this overhead in advance of creating the window, to facilitate the creation of a window with a client area of a given size. At present I've hardcoded the adjustments, but it would obviously be preferable to determine these adjustments programatically, in advance of creating the frame. Number of ways of doing this; how about something like: bool_t gwinFrameAdjust(GWidgetInit *pInit, uint32_t flags); This could update the width and height values in the GWidgetInit structure to reflect the flags.

The encoder could be incrementing/decrementing all sorts of values, including list pointers, floating point values and the like. In most cases I wouldn't want any scaling to cause rounding errors.

Thanks for the suggestions - its certainly another way of looking at it. Presumably with option (2) one would just signal 'toggle on' events? I've found mention of 'role' on some of the input devices, but it wasn't entirely clear what this meant. For a toggle, for example, are 'on' and 'off' simply separate roles? Or does it have a meaning which is separate from that of the state of the source? I'm envisaging creating a display widget whose value increments and decrements with the dial, so the analogue representation isn't relevant to my requirements.

I'm integrating a rotary encoder (for front panel input) into ugfx, and wondering about how best to treat it. The encoder has two out of phase inputs which can be decoded to generate clockwise and anti-clockwise (CW, CCW) movement events - typically 12 or 24 per revolution. It also (optionally) has a switch which is activated when the knob is pressed. My initial thought is to treat these events as keypresses - Left/Right (or Up/Down) for CW/CCW, and Enter/Escape for knob pressed/released. However I could also treat the events as specific flags (as is done with mouse clicks and the like). The role of such an encoder is potentially context-dependent, so there could even be merit in keeping it outside the widget/window structure. Any thoughts? N.B. I looked using a dial implementation, but don't feel it's the right approach, since it constrains what you can do in response to the encoder events.

That sounds a little drastic! But it does seem to have sorted the problem - on a quick test, no more lockups. Thanks for quick response.

Might have discovered what is going on with the frame 'close' button. 1. Frame 'close' button generates an event 2. Button event handler finds the frame's listener using geventGetSourceListener(), which locks the listener event buffer. 3. Frame's event handler is called, identifies that its 'close' button has been pressed, and destroys the frame 4. The frame destroy routine attempts to kill its listener by calling geventRegisterCallback(&gh2obj->gl, NULL, NULL); 5. geventRegisterCallback() calls gfxSemWait(&pl->eventlock, TIME_INFINITE); to lock the listener. 6. The listener is already locked, so gfxSemWait() results in task suspending 7. Context switch to main loop, which does pe = geventEventWait(&gl, TIME_IMMEDIATE) In 'normal' circumstances the listener event buffer is unlocked when the event is fully processed. However it looks as if its possible to create deadlock by destroying the frame directly in response to the event. There's a difference I'd missed before - I normally process events on the 'main' thread. A 'window close' is processed on a ugfx thread. Quite possibly of significance.

Behaviour reverted to the original - crashing on first button press on main screen after the popup has been destroyed. Might have partially fixed it, with a change to line 155 of gevent.c: // if (gsh == psl->pSource) { if ((gsh == psl->pSource) && psl->pListener) { Now works fine when a 'normal' button is pressed in the popup frame. What I think was happening with the 'normal' button press: 1. All button and frame events are registered with a source handle of GWIDGET_SOURCE [defined as ((GSourceHandle)(void *)_gwidgetCreate)] 2. Initially there is one event handler linkage in the Assignments list - all OK 3. Creating the popup adds a second event handler linkage 4. Destroying the popup clears down the Listener field of the second event handler linkage (, but not the source) 5. A subsequent button event checks the list, and gets a source match. 6. Attempt to check the listener - which is zero - so semaphore doesn't exist. Still locks if the frame is closed with its 'close' button - get a chibiOs SV#5 error from the event handler loop in the main code - 'misplaced chSysUnlock()'. Semaphores again!

Thanks for looking at this - I've updated my local copy with the changes. One thing I found is that the test on line 42 of frame.c needs to be on gh->flags (not flags). Can't comment on whether my problem is solved yet - the various changes seem to have stopped things working at all! Back to debugging.....

When you do get round to a rewrite, a method of including 'simple' objects (lines, fixed text, etc) within the scope of redrawing would be nice. One thought is a widget that collects them all into a group, but even that may be overkill. It certainly does seem that any window object is relatively memory hungry, but on a quick look I couldn't see anything surplus. If you have a frame 'close' button - it (quite correctly) destroys the frame, and other parts of the code need to know that the window had been closed. To solve this I assigned a tag value (as per submitted mod) to each of the frame's buttons: #define TAG_SCREEN_CLOSE 0x0b /* Tag value assigned to the 'Close' button on frames - ASCII 'Escape' */ #define TAG_SCREEN_MAX 0xfe /* Tag value for the 'Maximise' button on frames */ #define TAG_SCREEN_MIN 0xfd /* Tag value for the 'Minimise' button on frames */ Thus my control loop became aware of the event and could take action to re-enable the background screen. And only destroy the popup on a 'normal' exit, of course.

I have the following sequence to re-enable a window after my popup has been destroyed: gwinSetEnabled(ghFrameScreen, TRUE); displayFixedScreenItems(); displayFixedScreenItems() shows lines, fixed text etc that aren't window objects. I found that with the above code, the first fixed screen item wasn't displayed. It turns out that the screen isn't redrawn until after the first fixed item was written, thereby deleting it. So I modified the code as follows: gwinSetEnabled(ghFrameScreen, TRUE); gwinRedraw(ghFrameScreen); // Needed else first fixed text element not shown displayFixedScreenItems(); Is this the best way to handle this, or should redraw happen before anything is drawn on the newly enabled screen? (Or maybe I should use a widget to manage my fixed items in some way??)

Looks like there could be two problems! Initially the popup frame was created without a 'close' button (or min/max). On investigation, the _frameDestroy() routine 'disconnects' the frame listener regardless. So I added a check: static void _frameDestroy(GHandle gh) { // Following added if ((gh->flags & (GWIN_FRAME_CLOSE_BTN|GWIN_FRAME_MINMAX_BTN))) { /* Deregister the button callback */ geventRegisterCallback(&gh2obj->gl, NULL, NULL); geventDetachSource(&gh2obj->gl, NULL); } /* call the gcontainer standard destroy routine */ _gcontainerDestroy(gh); } ... and everything works fine. I then enabled the frame 'Close' button - and the problem recurred. So there may be a problem with the operation of geventRegisterCallback(&gh2obj->gl, NULL, NULL);