Jump to content

inmarket

Moderators
  • Posts

    1,295
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by inmarket

  1. Ahh.

    GDISP_NEED_STREAMING is completely different to GDISP_HARDWARE_STREAM_WRITE.

    The first is whether the streaming API is enabled in GDISP, the second tells GDISP whether a specific display hardware requires a streamed write methodology. The two are completely different things and are completely independent of each other.

    My guess is that you have been playing with the GDISP_HARDWARE_xxx definitions. Please restore these to the defaults and then try a make clean before compiling again.

  2. With pixmap you don't need to include it in your driver list (or even add the driver list config) as pixmap is handled differently to all other drivers.

    You should also not include the following in your gfxconf.h:

    The GDISP_SCREEN_xxx or GDISP_INITIAL_xxx variables. These should be in your RA8875 board file as they are display specific.

    The GDISP_HARDWARE_xxx variables as they are already appropriately defined in the respective display config file and are modified and played with by the multi-display handling code.

  3. 1. Widget drawing requires a gtimer event to fire. As RAW32 is non-preemptive it requires a gfxYield() to trigger that context switch. When you comment out geventWait, unless you put a gfxYield or gfxSleepMilliseconds call in you will not get drawing. Any geventWait should be sufficient even with only a 1ms delay (even a TIME_IMMEDIATE I think).

    2. Users are commonly interrupt driven and therefore Async so there should be no need for a non-blocking geventWait. The strategy is to create a gtimer task to read the uart buffer data. You can add a gtimerJabI call in your interrupt handler when your uart buffer has enough data which will then wake up the gtimer task. If you really want to make geventWait return immediately use TIME_IMMEDIATE or 1 (1ms) as the parameter.

    3. Without a look at all the code it is impossible for us to say. 

     

  4. I can't answer the SDL questions but I have answers for the other aspects.

    1. You can use the Linux event driver to get mouse/touch input when using framebuffer. Similarly I believe there is also a Linux tty keyboard driver.

    2. You can use the X driver to provide display, mouse & keyboard. Although it is slower than framebuffer or SDL, for something being used for prototyping before moving to real hardware, it is ideal and much easier to get working than SDL.

  5. Many years ago we had a stored write command style interface. We dropped it very quickly however for two reasons; 1. Noone was using it, and 2. It consumed lots of RAM and could quickly become unbounded in resource use and the complexity of controlling that got onorous.

  6. This is a very complex question and given that we can't see what you are talking about it is very hard for us to provide an answer.

    The only hint I can give you is to say that if you are using GWIN to render buttons etc there are gfxconf configuration macros that can affect GWIN's synchronisation methodology. Have a look at the GWIN redraw settings.

  7. Don't forget to also do a make clean once you have your configuration correct (gfxconf.h)

    For Linux based boards there are 3 alternatives:

    1. SDL

    2. X

    3. Linux kernel framebuffer and the Linux kernel event system.

    Options 1 & 2 are best for desktop, 3 is definitely best for embedded situations because of its low footprint and good performance. I have always personaly disliked SDL due to its linking nastyness, even though it is faster than the X driver. Still the framebuffer driver is the best solution for a real Linux based embedded device.

    As an input driver I believe the uGFX Linux event driver works on the beagle bone black so as long as your capacitive touch screen sends events to the standard Linux event driver everything should just work.

    I did some testing when the first beagle bone black board was released. At the time the framebuffer driver in the Linux kernel didn't work at all (kernel/hardware problem) so I ended up using the X uGFX driver for my testing. I am glad to see the Linux kernel framebuffer driver now works (even though at reduced bit depth) on the more modern hardware versions. 

     

     

  8. If you are directly drawing using GDISP calls, or manipulating GWIN flags directly, or having to understand the drawing lock then you are definitely approaching the problem incorrectly. 

  9. The implicit conversion warning is just that, a warning. It is perfectly valid C and perscribed behaviour for the C language. That the compiler is warning is being overly cautious and should be ignored. The reality is that the code is perfectly fine and is 100% valid C.

    The gtimer.c warning is a situation of dammed if you do and dammed if you don't. As gtimer is run as a thread process most operating systems require a return value for the function. So even though the code is unreachable most compilers will complain if you don't have a suitable return statement. On the other hand most compilers don't bother to complain about unreachable code in that situation unless the warning levels are set too high. So, in either case you will get a warning message from the compiler. You are just less likely to get a warning the way we have coded it.

    Without checking the code I suspect the gwin.c situation is the same.

    In summary, the code is fine. If the warnings bother you then turn down the warning level on the compiler.

  10. Double buffering is complex and how to do it is invariably application specific.

    In your case I would do what you are doing now - just drawing traces to alternative buffers.

    Don't try copying from one buffer to the other, you would have lost all the benefits of using 2 pages. Instead draw each frame from scratch or just wipe the old traces (by block fill or redrawing the trace). Yes buttons will be a problem but if your swap speed is fast enough it may not be noticeable.

    Another hint that may help is to use the 2nd ltdc layer to display the outer area with the buttons and then double page the centre background with the traces. Note this will however increase ram bandwidth requirements. This is probably the approach I would use provided the bandwidth numbers match.

    Another hint is to use a lower colour depth. Using RGB565 will halve the bandwidth compared to RGB888. The ltdc driver already support both - just change the gdidp_lld_config.h for the ltdc controller.

  11. Dma2d is not significantly faster than using the CPU with a well written block routine. It's advantage is that it releases the CPU to prepare for the next operation thus reducing latency between operations.

    In your case, with a 800x480 display on a f4 you are approaching the limits of the sdram bandwidth and therefore the number of pixels you need to write is definitely a consideration that will affect performance. Writing over a trace will definitely be much faster than block filling and will provide a better visual appearance.

    If you really want to do the block write there is a method that will be much better than using a pixmap but will require a custom extension to the ltdc driver. The method is to use the ltdc's ability to change the base sdram address. Using this you could create 2 display pages and swap between the pages, drawing on one while displaying the other. You still need 2 framebuffers of ram but it doesn't require the bandwidth sucking framebuffer copy that using pixmap requires. Ram bandwidth will still be a limiting factor but just not as limiting as with your current strategy.

    With ram bandwidth make sure that you are not using the display sdram chips for any other purpose even if there is spare ram available as the extra CPU access to the ram will contend with display refresh and drawing bandwidth.

    I hope that helps in finding a solution that will work for your situation.

  12. There are much easier and faster ways to draw the traces. Have a look at the oscilloscope demo in the repository. It demonstrates doing an oscilloscope using a really slow processor and even demonstrates a mechanism to do software triggering. From memory there are two versions, one in the Gaudio demos and one in the gadc demos.

  13. Thanks for leaving this hint for other users.

    It can also be accessed by typing C:\windows\fonts into the file explorer address bar. While the font folder is not displayed it can still be accessed directly (much like other hidden directories).

×
×
  • Create New...