Jump to content

inmarket

Moderators
  • Content Count

    1,271
  • Joined

  • Last visited

  • Days Won

    4

About inmarket

  • Rank
    µGFX Guru

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That screen needs to include the directory that has that stm header file. Your start up file, your compiler is complaining that it doesn't understand the assembly language. These are both problems relating to your ide and compiler. While we try to help here, we are not experts on those tools, we are ugfx experts. If the clues above don't help you, you will need to get help on a forum that understands your ide and compiler rather than here.
  2. with regard to your 2nd screen, that looks like you are using the wrong assembly language variant to compile that start up file. Use the start up file that matches your ide compiler, or alternatively, some ide's allow you to specify the assembler you use.
  3. Most likely cause for this is that the include directories path is not correct. I am not sure how to specify these in your ide, probably in the compiler options. These end up as -I directives in the compiler arguments. The -I directives must include the directory containing those stm header files.
  4. BTW, a native image in ugfx terminology is a image that has the same pixel format that the ugfx system uses in an unpacked pixel arrangement (maximum of 1 pixel per byte, word or dword depending on the number of the pixel bits)
  5. You can use the BMP image handling in ugfx. BMP images support a 1 bit per pixel format. The only thing you may need to do is to fabricate a BMP header. Because BMP also support RLE encoded formats you may also be able to compress your 1 bit images and so save rom/ram. Writing a bitblit routine for your driver to handle your "special format" image is probably not the best way to handle this. Similarly with your alpha request, use the image processing support built into ugfx. For example, ugfx handles transparent gif's. It also handles PNG images with an alpha channel although al
  6. Ginput handles mouse or touch events and any other input such as keyboard.
  7. It sounds like something is going on with your memory allocator. The uGFX logo is actually not an image. It is a series of rectangles drawn on the screen. It is therefore possible that this call is the first call to the memory allocator. That is something you can test and debug. The other possibility is that the image is corrupt somehow. This is easy to check by looking at the parameters that are going to be used by the palette allocation and seeing if they are reasonable. Another possibility is that you have stack checking turned on in your compile. Many memory allocators are
  8. Last I tested that was sufficient.
  9. Generally you would read the analog input in the dial driver directly. GADC is designed for when you have a single ADC device with multiple inputs, some of which you want to use for high speed sampling e.g. for audio, and some for low speed sampling such as dial devices. There is currently only one GADC driver, for the SAM7 cpu which has a single ADC that reads 8 input lines simultaneously. GADC is then required to pick off samples at low frequency from sampling that is occurring much faster say for the purpose of GAUDIO. If you are not in such a circumstance GADC is probably overkil
  10. I have finally had a chance to check the line in question. That line is never used - it is a comment put in for use by the documentation system doxygen. You can see the corresponding conditional compilation on line 132. The line that actually gets used is the block of macros between line 304 and 313 for true color pixel formats. So, in a proper compile it will correctly generate the color mapping.
  11. If you want to create a latched button use the checkbox instead with a button draw routine instead of the normal checkbox draw routine. The draw routine already exists and the checkbox provides the latched button state and events you are after.
  12. Each display driver creates a GDisplay object to hold its run-time data. The first display in the system gets assigned to the GDISP pointer. All drivers, of any type, are maintained in a GDriver list. In your case because the init process is not happening correctly GDISP is totally invalid.
  13. This looks like GDISP is set to some random value in flash. It is certainly not valid. The GDISP variable is not initialised until after the first display driver is initialised so don't expect it to be valid until after that. With regard to eclipse - I don't use it but I know there are many in the community that do. Personally I much prefer the make system - just create a makefile (I can't remember off the top of my head where the master example one is) and it does everything for you.
  14. The problem here is a build problem. GDISP builds in 2 possible modes - single display and multiple display. Which it uses is a complex combination of include paths, variables in gfxconf.h and linking. The build results in quite different code for the two options. If your gdisp_lld_init is not being called it means you have this process wrong. First GDISP_TOTAL_DISPLAYS, GDISP_DRIVER_LIST and GDISP_PIXEL_FORMAT should not be defined at all in your gfxconf.h for a single display. Instead the specific driver directory you want to use should be on your compiler INCLUDE path and the
×
×
  • Create New...