Search Results

Yep, that did it! The thought crossed my mind and I should have tried it before posting here but I suppose I am in a bit of denial over RAM usage. With FreeRTOS, emWin, and my app so far I have consumed 92% of the PSoC 5LP's available 64K DRAM. I really didn't want to face having to give more to emWin but there isn't a reasonable alternative at this point. Anyway, thanks for the help!

I am using CreateIndirect to populate a dialog box. It seems that I can include 31 widgets but when I add number 32 the call seems to fail. Is there a limit?

Update: I don't know the cause of the problem but I found that adding a delay in the callback avoids the problem: C Source Code (3 lines) CyDelay is the Cypress CMSIS delay instruction expressed in ms. On the off-chance you encounter this problem you might give this a try.

I use emWin with FreeRTOS and it works quite well now that I solved a problem I was having with a touch panel. The one remaining thing which seems like a bug even though it is rather benign occurs when I first create a window through CreateIndirect and react in a callback to a button push in the window. The paint event gets called an extra time causing the window to be redrawn with its original contents then another paint event happens and is drawn with the updated and correct information. This …

I have been struggling for a very long time trying to implement emWIN on an RA8875 with FreeRTOS. The problem (according to Segger) is caused by the touch controller being integrated into the graphics controller. Since the touch task runs separately from the Exec then each can asynchronously interrupt the other and if a memory write is done then the FIFO state can become invalid for the touch task. I have seen this repeatedly. Touches cause graphical changes (i.e. a button press) but the associa…

Chris, thanks! Guess I missed that. Appreciate the help.

At first glance it looks like the J-Link Debugger might do the job. Cypress Creator's outputted ELF from my application loaded just fine and I am able to do debug. I need to understand how to use the trace capability better and I will play with it until I come up with some informed questions. It wasn't included as part of the J-Trace for Cortex-M as it appears to be for some of your other probes. I can't find a place on your site to purchase it. Is it for sale as an add-on to my J-Trace?

I am developing an app in the Cypress Creator IDE and I want to use J-Trace to debug it. I am using GCC to build it and the output from Creator is an Elf map file and ".o" object files. I can't seem to figure out if it is possible to use Embedded Studio to load the app to do debug and trace. I tried a few different Open's of the files but never end up with anything that is debug-able. Is this possible to do? Edit: In a related question, if the above is indeed possible then is the Segger website …

OK, I am officially stupid. I looked at the cable I built for the J-Trace at least 5 times and swore each time it was correct but the 6th time I noticed it was 180 degrees reversed. Really hard to believe I made such an elementary mistake but now the J-Trace will connect to my target. On to my next issue (separate forum post).

Hello, I have a custom target that works fine with the Cypress MiniProg3 in both JTAG and SWD modes. I have tried everything I can think of to get the J-Trace to work with my target. I tried J-Link Commander, J-Flash, GDB Server and all report "Could not connect to target". My CPU is the CY8C5888 which is not listed on your CPU selection screen but it is just an 80MHz version of the CY8C5868 which runs at 67MHz. I tried setting it to the 5868 and I also tried Unspecified Cortex-M3. The cable pin…

Please post _cbDialogOrder code. It is most likely something you are doing there. EDIT: In my experience what causes this is something in the callback that causes it to call itself (e.g. modifying an attribute that changes the way the widget draws itself) and you end up with infinite recursion. You have to do those things outside the callback.

Probably obvious but if you had a H/W timer you could do it via an interrupt. In my case I use FreeRTOS and run the timer task at the highest priority which then very time-accurately updates several screen values.

I use FreeRTOS with emWin on the Cypress PSoC 5LP with GNU tool chain. It works fine for me.

There is one problem with this approach. There is no PROGBAR_GetText so I have no way to know what text would be drawn in the bar if was horizontal. Of course I can use a global variable but that is just a crude workaround. Unless there is something I am missing...?

That explains it. Perhaps a good addition to the user documentation?

The text in this progress bar displays: ahTempBar = PROGBAR_CreateEx(0, 150, 60, 200, 0, WM_CF_SHOW, PROGBAR_CF_HORIZONTAL, 0); PROGBAR_SetFont(ahTempBar, &GUI_Font8x16); PROGBAR_SetTextColor(ahTempBar, 0, GUI_BLACK); PROGBAR_SetTextColor(ahTempBar, 1, GUI_BLACK); PROGBAR_SetBarColor(ahTempBar, 0, GUI_GREEN); PROGBAR_SetBarColor(ahTempBar, 1, GUI_WHITE); PROGBAR_SetTextAlign(ahTempBar, GUI_TA_VCENTER); PROGBAR_SetText(ahTempBar, "Test"); When I change PROGBAR_CF_HORIZONTAL to PROGBAR_CF_VERTICAL…