Search Results

Search results 1-16 of 16.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • So it is as I expected. If I use the 16 bit interface I get the memdev memory area directy in the low level functions without swapping. And I can transmit the bytes in the order so that my raw images have the right colors, but then any drawing actions I do (st)emwin will have the wrong colors. Eg if I fill the screen with red (RGB: 255,0,0), then the memdev memory area contains 1E 00 1 00 1E 00 (etc) resulting in a green screen if i transmit the bytes in that order to the LCD controller. (note: …

  • Small update: If I use GUIDRV_FLEXCOLOR_M16C0B16 I get pointers directly inside the memdev region so that is nice. There is a lot of tricky stuff going on though to get it right. Eg to set CASET values of the controller in 8 bit mode the following values are transferred : { 0x00, 0x00, 0x00, 0x7F } Now in 16 bit mode, he still transfers this (calling the functions 4 times), instead of only 2 times { 0x0000, 0x007F } This means that in my pfWrite16_A1 function i have to throw away the upper byte …

  • Quote from Sven: “Actually, I'm the one [img]https://forum.segger.com/wcf/images/smilies/wink.png[/img] I will add a note to the manual. ” Haha, of course, there can be only one. Thanks Now looking at the buffers for my little color problem I see 2 issues: 1. The memdev region (0x6804008c) is NOT passed directly to the low level function, it seems and intermediate 256 byte buffer (0x6804f674) is used. This is hugely unfortunate, given my attempt to do this whole operation without extra (useless)…

  • I assume in your Task2 if you would have wanted the 1. GUI_GotoXY(0, 0); 2. GUI_DispString("Task2"); to be run on the memdev and not directly on the screen that you would have put a GUI_MEMDEV_Select(hMem); / GUI_MEMDEV_Select(0); around it right ? I have 'guarded' all my functions with these calls now and that seems to work without any further crashes :). Thanks ! (maybe tell the person(s) responsible for the manual to add a note about this in the GUI_MEMDEV_Select documentation ? ) The problem…

  • Quote from Sven: “Did you unselect the memory device after GUI_Clear() ” Aha, no I did not ! What I do now is : m_hMemDev = GUI_MEMDEV_CreateEx(0,0,DISPLAY_WIDTH_PIXELS,DISPLAY_HEIGHT_PIXELS, GUI_MEMDEV_NOTRANS) GUI_MEMDEV_Select(m_hMemDev); from my initialization thread to setup the memdev. And then the other threads that need to do something with the display would do: - Get the pointer with GUI_MEMDEV_GetDataPtr( m_hMemDev ) and fill the raw memory directly if needed - Do drawing actions like …

  • Hi Sven, GUI_OS is set to 1. GUI_MAXTASK is not defined. Manual says the default is 4. I have more tasks in my system but I am only calling it from 2 tasks now. The * GUI_X_GetTime() * GUI_X_Delay(int) * GUI_X_InitOS() * GUI_X_GetTaskId() * GUI_X_Lock() * GUI_X_Unlock() * GUI_X_GetTaskId * GUI_X_WaitEvent * GUI_X_SignalEvent functions have an implementation (provided by ST, if you think these may be involved i can go start checking them) I am actually not calling GUI_Exec/GUI_Delay at all at the…

  • Hi, Based on the discussion in Direct framebuffer access, I started using memdevs. But now I run into an exception during when calling GUI_Clear() when the memdev is active (though it might not be memdev related, so i created new topic). Background: I am using stemwin in a freertos multitasking environment. The memory I give to emwin (and in which the memory buffer is located) is located in external SRAM. IAR linker file: place in ExtSRam_region { block HEAP, section EXT_MEMORY_IF_AVAILABLE }; G…

  • Direct framebuffer access

    BramPeeters - - emWin related

    Post

    Hi, Quote: “Unfortunately, not. the hardware routines called by emWin only receive the pure data. ” Yes, but as far as I understand emwin transfers that data to the LCD controller using the GUI_PORT_API.pfWriteM8_A1 function. This function takes a pointer and a number of elements as arguments. And I would expect that this pointer argument points directly inside the cache region ? So if I write (or simulate to write) the entire screen, the lowest address given to me via this callback function wil…

  • Direct framebuffer access

    BramPeeters - - emWin related

    Post

    And another realisation: If emwin does now work with a framebuffer, does this mean then when working with a memdev and caching not enabled, a GUI_MEMDEV_CopyToLCD command will do a direct write from the memdev memory area to the display (so no intermediate copy). Because that would be the perfect solution then (I think) ?

  • Direct framebuffer access

    BramPeeters - - emWin related

    Post

    And thinking around the box about my getting to my 'ideal' scenario a bit more: does emwin 'leak' the cache location towards the lower level functions ? Eg if i would trigger a write of the entire screen by filling it with a color will he pass a buffer with the start address of the cache to the low level drivers ? And is the location of that cache constant or does it get relocated under certain circumstances. (I understand that this is totally dirty & bad and Segger is not responsible if a black…

  • Direct framebuffer access

    BramPeeters - - emWin related

    Post

    Hi, Ok, thanks for the super clear & spot on explanation. It even answers one of the questions i had not asked yet, what is the advantage of using the cache :). My ideal scenario would be then to have a cache I can write into but sadly that is not option then :/. I will evaluate the speed of the other options then (cache + GUI_MEMDEV/cache + GUI_BITMAP/ no cache and readbacks) and pick what works best for me. Have a nice weekend ! Bram

  • Direct framebuffer access

    BramPeeters - - emWin related

    Post

    Hi Sven, Ok that is super interesting to know :), thank you. So that means Emwin is not 'aware' of what is currently visible on the screen ? And if i write eg some text on the screen, it will *only* transfer the pixels of the text ? I would have expected that it would overlay the text on the current background in a buffer, and then send the result to the LCD controller, or maybe a 'dirty' partial rectangular area or something . Anyway, that also means i can write my raw image directly to the LCD…

  • Direct framebuffer access

    BramPeeters - - emWin related

    Post

    Hi, I already posted a similar question to the stemwin forum but so far without result. I have a board with an external controller connected via an 8bit bus to my cpu, and my pixels are 16bit 565 format. Relevant calls setting this up: GUI_DEVICE_CreateAndLink(GUIDRV_FLEXCOLOR, GUICC_565 , 0, 0); GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709 , GUIDRV_FLEXCOLOR_M16C0B8 ) I am looking for a way to write raw image data (565 format) directly into the emwin framebuffer (which i …

  • Hi, Indeed, you are right, it turns out the SW puts the chip in 'suspend' after a while so that explains why the JTAG connection is lost, and why it does not work if i set the bootmode to use the application present in flash (which will do the same). I also tried a few more times using jlink.exe directly and these always seem to be "good" runs, i can step 's', or run 'g' and hit the next breakpoint without running into the problem (until he goes into suspend but ok) of: ERROR: Bad JTAG communica…

  • >Use a valid speed (Please note: ARM926EJ-S only support speeds up to a 1/8 - 1/6 of the current clock speed, therefore you probably need to use a speed of 4 - 50 kHz at the start of a session) What is this "current clock speed" are you referring to here ? CPU core clock speed ? Anyway i tried with 50 Khz in Eclipse and it does not seem to make a difference. I also tried the jlink approach using breakpoint positions i took from eclipse. Not sure how i can figure out of a breakpoint needs to be i…

  • that I am attempting to use an Econ Denebola board which has a Cypress CX3 cpu with a JLink Pro debugger and eclipse debugging. ( Cypress CX3 =ARM926EJ-S core) (The Denebola board is powerd via an external 5V power supply ) [1] The Denebola board has a number of boot modi which you can select via dip switches, if i select the default 'boot from spi flash' boot option i cannot connect with the debugger in Eclipse. The JLinkGDBServerCL console output says: Source Code (39 lines) I did quite a lot …