Posts by hbarta

Hi Jörg, thank you for the suggestion.

Hi folks,
I would appreciate guidance on how best to approach a feature we need to implement. I've gotten a lot of mileage out of emWin but profess that I'm not really aware of what's going on under the covers and in particular how it is leveraging our LCD hardware.

The "custom drawn screen portion" is a portion of the screen to which we are blasting a camera image. We have configured this to use a buffer in SDRAM for the LCD frame buffer and are using DMA to write from the camera to that. The LCD controller is the same as is used in the STM32F429I-DISCO board as is the SDRAM. (Note to self - buy the H/W engineer a nice lunch next time I'm in the office!) The feature is to mark the camera image with 'corners' that indicate where the user should center the subject of the screen capture. (The screen display is 'live' and when the user presses a 'capture' button we complete a frame, stop the camera and ship it off to a server.)

One of the reasons we have a working system and yet I remain so blissfully ignorant of the connection between emWin and the H/W is that I was able to use considerable code from the ST examples to get the system up and running. For practical purposes, any solution that is likely to work with the DISCO is likely to work on our custom H/W.

My question is what solutions should I be considering.

The brute force solution would be to write the marker pixels directly into the LCD frame buffer as the camera writes the image to the frame buffer. I'm wondering if there is a better solution. I believe the video controller on this chip supports layers but so far I have not had the need to use that capability. Is that the sort of thing that could be used to write the markers once to a layer that is visually above the camera image and still be able to update the camera layer?

Is there a better way to tackle this?

Many thanks for your suggestions. If there is additional information that factors into a suggestion, do not hesitate to ask.

BTW, our configuration in LCDConf.c starts with:

#define XSIZE_PHYS 480
#define YSIZE_PHYS (800)


#define NUM_BUFFERS 2 // Number of multiple buffers to be used
#define NUM_VSCREENS 1 // Number of virtual screens to be used


#define BK_COLOR GUI_DARKBLUE


#undef GUI_NUM_LAYERS
#define GUI_NUM_LAYERS 1


//#define COLOR_CONVERSION_0 GUICC_M8888I
#define COLOR_CONVERSION_0 GUICC_M565
#define DISPLAY_DRIVER_0 GUIDRV_LIN_16


#if (GUI_NUM_LAYERS > 1)
#define COLOR_CONVERSION_1 GUICC_M8888I
#define DISPLAY_DRIVER_1 GUIDRV_LIN_32
#endif


#ifndef XSIZE_PHYS
#error Physical X size of display is not defined!
#endif
#ifndef YSIZE_PHYS
#error Physical Y size of display is not defined!
#endif
#ifndef NUM_VSCREENS
#define NUM_VSCREENS 1
#else
#if (NUM_VSCREENS <= 0)
#error At least one screeen needs to be defined!
#endif
#endif
#if (NUM_VSCREENS > 1) && (NUM_BUFFERS > 1)
#error Virtual screens and multiple buffers are not allowed!
#endif

Hi Adrian,
Thank you for looking into this. There will be no need to submit code as I have resolved it. While cleaning up all of the code I had tried as a work around, I found that if I call SCROLLBAR_SetValue() after calling SCROLLBAR_SetPageSize() the problem does not happen. It seems that the SCROLLBAR_SetPageSize() API has the side effect of changing the value. I'm not sure if that is intended but that seems to be the way it works.

If you still want code that demonstrates the issue I can provide the entire code file.

thanks,
hank

Hi folks,
I'm using a scrollbar on a dialog box and I need to initialize it on initialization of the dialog. Code calls SCROLLBAR_SetValue() to do so. Before that call returns, emWin sends a WM_NOTIFICATION_VALUE_CHANGED message to the scrollbar. In that message handler there is code that calls SCROLLBAR_GetValue() and gets a different value than what was just set set.

I have tried working around this problem by resetting the value on the first entry to the WM_NOTIFICATION_VALUE_CHANGED handler by calling SCROLLBAR_SetValue() but a subsequent call (as in next line of code) to SCROLLBAR_GetValue() returns the previous undesired value. I have checked the manual on this andI cound not spot any clue to what I am doing wrong.


The code file was created using the GUI builder. The widget is created using:

static const GUI_WIDGET_CREATE_INFO _aDialogCreate[] = {
...
{ SCROLLBAR_CreateIndirect, "Scrollbar", ID_SCROLLBAR_0, 234, 10, 30, 145, 8, 0x0, 0 },

// USER START (Optionally insert additional widgets)
// USER END
};

During initialization I have added

sliderHandle = WM_GetDialogItem(pMsg->hWin, ID_SCROLLBAR_0);
SCROLLBAR_SetNumItems(sliderHandle, 12); // 9 steps from 0-9, 100%-10%
// (Yes, with PageSize = 3, numItems =12 gives the desired number of slider steps.)
sliderPos = 10-backlightPCT/10;
initJustFinished = true;
SCROLLBAR_SetValue(sliderHandle, sliderPos);
SCROLLBAR_SetPageSize(sliderHandle, 3);
SCROLLBAR_SetWidth(sliderHandle, 40);
// USER END

In the WM_NOTIFICATION_VALUE_CHANGED message handler I have

if(initJustFinished) {
initJustFinished = false;
SCROLLBAR_SetValue(sliderHandle, sliderPos);
backlightPCT= SCROLLBAR_GetValue(sliderHandle);
}
backlightPCT= SCROLLBAR_GetValue(sliderHandle);
backlightPCT = 100-(SCROLLBAR_GetValue(sliderHandle))*10;
setBacklightPercent(backlightPCT);
sprintf(logBuf, "%d", backlightPCT);
EDIT_SetText(editHandle, logBuf);

Other than the initialization issue the scrollbar works well and does what I need. Any help getting the scrollbar initialized to the correct value would be most welcome!

thanks,
hank

You are welcome. I am only too happy to help. (Usually it is the other way around. )

Hi Adian,
The code file is generated using the GUI builder tool.

Creation is via an entry in _aDialogCreate[]

static const GUI_WIDGET_CREATE_INFO _aDialogCreate[] = {  { WINDOW_CreateIndirect, "Window", ID_WINDOW_0, 0, 0, 480, 800, 0, 0x0, 0 },  { IMAGE_CreateIndirect, "Image", ID_IMAGE_0, 0, 0, 180, 68, 0, 0, 0 },  { MULTIEDIT_CreateIndirect, "Multiedit", ID_MULTIEDIT_0, 10, 692-ENLARGE, 460, 48+ENLARGE, 0, 0x0, 0 },
...

Initialization in _cbDialog()

switch (pMsg->MsgId) {  case WM_INIT_DIALOG:    SCROLLBAR_SetDefaultWidth(20);    //    // Initialization of 'Multiedit'    // bottom MULTIEDIT (status area)to read only:    //#if MULTIEDIT_WORKS    hItem = WM_GetDialogItem(pMsg->hWin, ID_MULTIEDIT_0);    statusWinHandle = hItem;    MULTIEDIT_SetText(hItem, "");    MULTIEDIT_SetFont(hItem, GUI_FONT_8X16X2X2);//    MULTIEDIT_SetFont(hItem, GUI_FONT_8X18);    MULTIEDIT_SetReadOnly(hItem,true);      MULTIEDIT_SetAutoScrollH(hItem, true);            // turn on horizontal auto-scroll    MULTIEDIT_SetAutoScrollV(hItem, true);            // turn on vertical auto-scroll

(The SetAutoScroll calls are not necessary to provoke the problem but vertical scrolling us useful to visualize the situation.)

There is no 'notification' processing for this widget.

The widget is sized to hold four lines of text and the text is written using

MULTIEDIT_SetText( statusWinHandle, statusBuf);          // write to the screen

where statusBuf is a char array and would contain something that looks like "line1\nline2\nline3\nline4"

I suspect that somewhere the font vertical dimensions is getting doubled twice when determining how much of the text in the buffer is visible on the display.

Is this enough information? (Apologies for the one liners in the code snippets. They did not look that way when pasted into the edit window...)

Thanks!

Hi folks,
I have a MULTIEDIT which I have set to use font GUI_FONT_8X16X2X2. It seems like the Window only displays half the text it is capable of showing. In other words, if I size the MULTIEDIT to display four lines of text, it only shows the first two. If I enable vertical scroll bar, I can scroll up and down and see all four lines scrolling through the first two lines of the display.

(*) I am writing a single text string to the MULTIEDIT using MULTIEDIT_SetText() which contains three embedded '\n' characters. I am doing something similar with another MULTIEDIT and using the GUI_FONT_20_1 font and getting all possible lines displayed.

Is there a work around for this problem?

Thanks!

Many thanks, Thorsten, that works fine.

(Yes, there was something I had overlooked.)

This API seems to be AWOL.

I need to expand the width of a scroll bar on a MULTIEDIT widget and cannot see any way to do so. Is there something I have overlooked?

This is using STemWin 5.26.

many thanks,
hank

Hi Adrian,
Thank you for looking into that. Can you suggest anything I might investigate to resolve this? It seems odd that the single call (WM_MakeModal(dialogHandle))
would interfere with touch handling for the case of pen up events and I suspect some other configuration option may trigger this behavior.

Thanks!

And my code w/out 'code' (re)formatting:

static WM_HWIN CreateFramewin(void);
static WM_HWIN CreateFramewin(void) {
WM_HWIN hWin;

hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0);
return hWin;
}

// USER START (Optionally insert additional public code)

void CreateUserNameDialog(void)
{
dialogHandle = CreateFramewin();
// WM_MakeModal(dialogHandle);
}

// USER END

Hi Adrain,
The touch driver provides 'pen down' and 'pen up' events to the WM via:

GUI_TOUCH_StoreStateEx(&TS_State);

and with TS_State.TouchDetected set appropriately.

This works fine if the dialog is not modal but when I add the call to WM_MakeModal(dialogHandle); e.g.:

WM_HWIN CreateFramewin(void);WM_HWIN CreateFramewin(void) {  WM_HWIN hWin;
  hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0);  return hWin;}
// USER START (Optionally insert additional public code)
void CreateUserNameDialog(void){  dialogHandle = CreateFramewin();  WM_MakeModal(dialogHandle);}
// USER END

WM_NOTIFICATION_RELEASED events are not then received. Without WM_MakeModal(dialogHandle); they are.

Thank you for the suggestion. I will try displaying the image using GUI_BMP_Draw() (as I believe that is what you mean.)

In the mean time, here is the image I start with.

Thanks!

Edit: No joy yet with GUI_BMP_Draw() but I have something else to try WRT that.


The manual also mentions drawing PNG files directly after they are converted using Bin2C.exe. I cannot find that tool in the (ST) distribution. Is it something I can download directly from Segger?


Edit2: No positive results trying to draw w/out using an IMAGE widget. Nothing appears on the screen. I also tried eliminating the underlying IMAGE widgets (I have one 'stacked' on another) and that made no difference. Of course the WINDOW widget which roots this display is still there.


I am passing a GUI_BITMAP pointer to GUI_BMP_Draw() and it's not obvious that this is the correct argument. (As an aside, I really dislike void pointers which cast aside any type safety!)


I suppose there is some coordination required between the Window Manager and lower level code that is required for this to work (and which is not needed when an IMAGE widget is used.) A quick glance at the manual did not clue me in but I could have easily overlooked it. And FWIW the code uses a MEMDEV and is configured for two layers - and I'm sure that matters when trying to coordinate with the Window Manager.


And lastly, I cannot rule out that some of the lower level calls are not implemented correctly. I have tried to copy them faithfully from ST example code that uses the same processor and same display configuration (16 bpp, 565) and at least some of them are working. Behind the scenes emWin may be using different calls depending on the format of the data that is provided.

Hi folks,
I'm using Bitmap Converter (BmpCvtST.exe, v5.26, STemWin package) to convert images for display. Ordinarily when I save I select the "High color [565] compressed" output format and all is well. At the moment I am working with an image that has an Alpha channel and transparent portions. When I 'Save As' that option does not come up. The closest is "High color with Alpha [565]" but that doesn't work well. The image is a red X (255,0 0) and it appears black (but the transparency part works.)

The option that provides the visual results I like (Red X, background otherwise visible ) is when I save with the option "True color with alpha channel" but it uses gobs of flash since it is not compressed. I have tried "True color with alpha channel, compressed" and nothing appears when the code issues the call to draw the image.

Is there any to draw a compressed image with transparency on the LCD? The LCD is configured for 16 bit (565) color.

Code that draws the image looks like:

case ID_BUTTON_1: // Notifications sent by 'Submit'
switch(NCode) {
case WM_NOTIFICATION_CLICKED:
// USER START (Optionally insert code for reacting on notification message)
hItem = WM_GetDialogItem(pMsg->hWin, ID_IMAGE_2);
IMAGE_SetBitmap(hItem, &bmRedX);
// USER END
break;
case WM_NOTIFICATION_RELEASED:
// USER START (Optionally insert code for reacting on notification message)
hItem = WM_GetDialogItem(pMsg->hWin, ID_IMAGE_2);
IMAGE_SetBitmap(hItem, &bmclear);
// USER END
break;
// USER START (Optionally insert additional code for further notification handling)
// USER END
}
break;

bmRedX is the image with transparency and bmclear is a 1x1 pixel transparent image. The red X is painted when the button is touched and removed when the button is released. (That party works brilliantly assuming the button actually appears. )

Thanks!

(Uh, sorry. The forum S/W has hopelessly mangled the code if I use the 'code' tags. It looks better if I just copy and paste?)

Hi folks,
I am using a dialog (Window rooted with various widgets rooted in a Framewin) as a popup and want the dialog to be modal. However when I do this, the widgets in the modal dialog do not receive WM_NOTIFICATION_RELEASED events. This is awkward as some of them cannot then be pressed twice since they remain 'pressed' until another widget is touched.

I can work around this by not making the popup modal and instead disabling widgets in the parent dialog but this requires more code and logic than the single "WM_MakeModal()" call.

Is there a way to get WM_NOTIFICATION_RELEASED messages in a modal dialog?


Thanks!

Never mind. Displayable characters start at 160. Not obvious from the image on p229. Obvious from Table 10.28 (p 218)

It would be useful if the character set used for the various fonts was identified in a concrete way.

Hi Adrian,
Is there something else needed to display the extended ASCII characters (or are they not included in the ST version of the library?) I'm trying to display some with no luck. I've modified the STemWin "Hello World" example program (uses V5.26 library) as follows:

void MainTask(void) { 
GUI_Clear();
GUI_SetFont(&GUI_Font20_1); 


 GUI_UC_SetEncodeUTF8();


 GUI_DispString("Halöle");


 GUI_DispStringAt("Hal\xc3\xb6le", 0, 20);


 //GUI_DispStringAt(hiChars1, 0, 0);


 //GUI_DispStringAt(hiChars2, 0, 20);


 GUI_DispStringAt(hiChars3, 0, 40);


 GUI_DispStringAt(hiChars1, 0, 60);


 while(1);
}

(The first 2 lines use UTF-8 and are another subject.)
The third line displays nothing and the fourth displays the expected text ("uvwxyz{|}~");

I'd like to use the extended characters as I beliueve that would be simpler than UTF-8. (The first line displays "Halle" indicating the compiler did not like the "ö" and the second line displayed as desired.)

Thanks!

Thank you both for the replies.

GUI_ExecCreatedDialog() is definitely not for this application which operates via main loop (no RTOS.)

I think I smashed it. The procedure I'm using:

1. On entry to the main loop (and following all initialization) call GUI_CreateDialogBox() using arguments produced by the GUI builder.
2. Within the _cbDialog(WM_MESSAGE * pMsg) procedure (and with the WM_NOTIFICATION_RELEASED message for the button that should switch screens) call GUI_EndDialog() with the handle returned by the preceding GUI_CreateDialogBox(). Set a flag to indicate the next screen to load.
3. In the main() loop, call GUI_CreateDialogBox() for the next dialog to display.

It also seems to work to call GUI_CreateDialogBox() immediately following GUI_EndDialog() in the button handler. Originally that did not work until I had the brilliant idea to go into linker settings and increase stack and help. (smacks forehead.)


It seems a little costly to destroy and create the dialog each time, but I do not see a way to reuse a dialog that will work with a polling loop.


Further comments on this usage of the APIs is welcome!


thanks,
hank

Hi folks,
I'm trying to construct an app that will use several screens with buttons, text fields and so on. I've used the GUI Builder to construct skeletons for the screens and it includes a procedure that calls GUI_CreateDialogBox() to display the dialog. I've put this into the HelloWorld demo and added a call to GUI_Exec1() in my main loop. (No OS, just a polling loop.) With a little tweaking of the touch driver I get touch events for the windows (using GUI_TOUCH_StoreStateEx() to pass touch events along to STemWin.) My main procedure also calls __CRC_CLK_ENABLE() and GUI_Init() before looping.

Code switches to another screen by calling GUI_EndDialog() for the current dialog followed by the create procedure for the next dialog. At this point everything seems to be working. It can even switch to a third screen by calling it's create procedure. When it goes back to the initial screen, that comes up but the app no longer gets touch events. The driver seems to stop receiving touch events leading me to suspect that some kind of memory overwrite has corrupted some data structure the touch driver depends on.

My questions are:

1) Is this a typical model for switching between several screens? I tried to find example code that does this but the examples seem to either be HelloWorld which does practically nothing and various demos coded more to demonstrate lots of emWin capabilities ()and thus rather complex.) Pointers to a simple demo that moves between several simple screens would be really welcome!

2) Are there critical calls I have left out that are required for this to work? For example, I tried not calling GUI_EndDialog() and reusing the handle with GUI_ExecCreatedDialog() and that got a hard fault without returning.


I've studied the manual with hope that I would find a helpful clue but did not. If it exists and I have just not found it, feel free to suggest that I study it more (and hopefully point to a particular section.)

Thanks!

Hi Adrian,
Thank you for the quick reply and the confirmation that what I wish to do is possible.

I will direct further inquires to the ST forum.

best,
hank