inmarket

To also add some more detail... Most small display controllers use a pixel framebuffer that is outside the CPU address space. This is because the CPU is talking to them over a very slow bus like SPI or even 8 bit parallel. These buses are far too slow to be feeding display data directly to the display. Instead graphic commands are sent to the display controller which then renders into the off-CPU framebuffer. This covers most of the GDISP drivers. The few CPU's that have the display controller built in (or are on a very high speed bus) will typically map the pixel framebuffer directly into the CPU address space. The framebuffer and fb24 drivers are for these displays. The only odd one out is the LTSC driver for STM32 CPU'S. While this is theoretically a framebuffer driver situation, it has very complicated initialisation and eccentricities due to its support of DMA operations thus warranting a specialised driver for it.

The divide by 2 when calling xyaddr() is incorrect. It is the xyaddr() macro itself that needs the divide by 2. As indicated by the macro name, it is supposed to take (x,y) as it's parameters.

Those routines are typical of routines you would see at the board file level. They describe how to convert a logical operation into a physical one. For example, the logical operation is writePixel, the physical requires the details inside SPI_DataWrite_Pixel. Your driver will call those routines. Those routines will be in the board file of the driver. Note: This actually looks like 16 bit SPI with the top bits indicating data/cmd and read/write. You might rearrange the board interface like follows... write_cmd8(g, c) = SPI_CmdWrite(c) write_data8(g, d) = SPI_DataWrite(d) write_data16(g, w) = { write_data8(g, (gU8)w) write_data8(g, w >> 8 ) } Read instructions are similar. If you compare this to other driver board interfaces you will see this is very similar. You then just need to write the driver itself. Note: By doing this board level extraction the same driver could be used with the display controller in 8080 bus mode simply by changing the implementation of the board routines above. For the driver, having had a quick look at the data sheet, it is basically a "window" model driver that effectively uses the "MCU write with ROP" controller instruction. When you have that working you can then add an accelerated block fill routine using the controller "rectangle fill" instruction. There is another controller that is similar in that it is a window driver and has a accelerated block fill routine. From memory (I am currently away from my computer) it might be the SSD1331 driver or one of the RA drivers. Hope this helps.

Also have a look at the code for an Olimex board. It is lying around somewhere probably in the boards directory in the source code. It also uses a 9th bit instead of a D/C line and was one of the first boards used when developing the uGFX project. Of note: This means of communication requires a CPU capable of 9 bit SPI. The standard ST processors don't but SAM processors do. Look at your CPU hardware specs to see if it is supported. Also, sometimes the display controller can operate in either 8 bit mode with D/C or in 9 bit mode. This is usually pin configurable. If your CPU doesn't support 9 bit SPI then you will need to modify the display board, use bit banging SPI (not simple), or find another display.

The problem here is a physical one that can't be overcome in software. There are 2 fundamental issues: SPI flash is SLOW SPI flash is not memory addressable by the CPU Yes, I know that some CPU's support memory addressing of SPI flash and in those the uGFX code works unchanged however the speed considerations are still a problem for practical use. So, how to make SPI work for storage of fonts... Treat the SPI flash as a disk and connect it with the GFILE module Use the dynamic loading font mechanism to load the font you want into memory. Whilst this still uses RAM for the font you have loaded, the advantage here is that it can be unloaded when not needed and potentially a different font can then be loaded from your SPI flash. So, not a full solution but instead a work around. Unfortunately it is the only way to get around what is a physical hardware limitation.

The function might be called sprintg or something like that (I am off-computer presently so can't see the proper function name). It is the ugfx equivalent of sprintf. Note: sprintf from the c library won't work as it is also not utf8 aware at all. Sprintg (the ugfx equivalent) may work when you use %s to include the character (obviously as part of a string). I don't expect it to work with %c or as part of the format string itself. Note: this is a work around that should work but there are no guarantees. To be fixed properly this requires substantial changes to the printf engine in ugfx. The extra complexity is the whole reason very few sprintf implementations support it except on desktop systems like Windows or Linux.

Also check you are not running X. If it is running it will take over the framebuffer device and then ugfx will not be able to set the video mode.

It looks like the "failed to set video mode" was correct. When you turn off USE_SET_MODE it assumes that the video mode has been set correctly before the ugfx application starts. This is obviously not true in your situation. I am surprised it was able to display anything at all. Whilst I haven't had a look at the code recently, from memory it tries to auto-detect the correct mode by looking for a framebuffer mode that matches the pixel format. Some questions here that might help you find the problem: 1. The original pi project was against an early pi hardware model. What model are you using? 2. What Linux variant are you using? Is it the same as the sample project? I suspect not given the differences in compiler flags. Your compiler obviously does not support the flags required by the original pi. 3. Check if the kernel you are using even has the Linux framebuffer compiled into it and what modes it supports. This is the most likely reason it is not working for you.

I have had a decent look at this. Unfortunately it is not easy to fix. The issue is that gwinPrintf is processing the string byte by byte rather than utf8 character by utf8 character. This is completely consistent with the original C standard printf but definitely not what you need. To get around this in the short term gsprintf it into a text buffer and then string print that. Note: even with this, %c will not work for utf8 extended chars but %s will. I am currently deep in implementing generic rotation for text drawing for ugfx v3 so it will probably be a while before I can come back to solve this properly.

Some adjustments are made by the window manager for things like borders. There is also a difference between inner and outer dimensions. The particular details I can't remember off the top of my head. Have a look through the code to see.

Sorry, I have been away and unable to respond. I will be back this coming weekend and will have a good look as soon as I can. The most likely reason is gwinPrintf is processing byte by byte rather than character by character.

A simple way is to just add a timeout value of x seconds instead of gDelayNone. If you get a NULL response then you have a timeout and the screen can be turned off. A non-NULL response can turn the screen back on if it was off.

Hmm. Without looking at the code, it looks like a utf8 encoding problem. The reason I have this suspicion is that for the label you are getting a single character output, for the console you are getting a two character output. I suspect that while the two strings look the same they are actually encoded differently. Both the console and the label use the same underlying font routines so the only way they would give different output for the same input is if perhaps the console is printing byte by byte instead of character by character or string print. Try putting the string into a variable and then using that variable to print both the label and the console. If you get the same result let me know and I will go digging.

Mixing licenses is not usually a problem unless one of the licenses is expansive i.e. it tries to govern source code not explicitly licensed under its own license. The most obvious example here is GPL which says you need to publish source code for the entire project (not just the GPL portion) if you distribute a binary. This is called "copy-left" and is incredibly restrictive particularly for commercial applications or when other source code in the system has intellectual property considerations. LGPL however is perfectly fine. Somewhere on the ugfx site or in the documentation is a good explanation of this particularly with regard to GPL. As always when mixing licenses you need to meet the conditions on each license.

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.

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.

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.

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)

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 alpha blending is supported to varying degrees based on your display controller.

Ginput handles mouse or touch events and any other input such as keyboard.

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 assumed to be single threaded and will hard-fault if running on a thread on a stack other than the main threads. Given you are running FreeRTOS which is multi-thread aware you can assume that its allocator is multi-thread capable however still check that you are compiling without stack checking turned on.

Last I tested that was sufficient.

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 overkill and the dial input analog input can be read directly in the dial driver.

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.

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.