inmarket

You will notice in our image api that we have calls that enable caching. These calls cache the image in a format that is most appropriate for each image decoder. For bmp images that happens to be similar to the internal native image format but for gif images it is an easy fast decode byte format. In both cases we don't support blitting from those internal image structures. The reason we don't have tagged memory support is simply due to complexity. Some operating systems support it and some don't. Additionally that support would need to be rippled through all the image code. Unfortunately that would be a significant increase in code complexity for little gain for most people. In reality you probably don't really need it especially with bmp images as they decode very quickly. If you really want the ability to use tagged memory with a blittable image format, there are two possibilities. 1. Instead of using bmp image format, use a native image format. Once you get past the header it can be blitted directly to the display. Creating the images in native format is a bit of a pain but once past creating the image you can you the existing ram loading mechanism. 2. Create a pseudo framebuffer display that uses your external ram for its frame buffer. You can then draw onto that display, including decoding images onto it and because you know the address of the framebuffer you can then bit blit from it as needed. This is effectively what pixmaps do except that with pixmaps you can't currently control the address of the framebuffer.

Thankyou. I will look at this shortly.

The easiest way is to cache this manually. Copy the file contents to the external ram you want to use. When you open the image use the api calls that allow you open an image from a memory buffer. Note there is no advantage in doing this with images in flash as flash (ROMFS) tends to be as fast or faster than external ram. It is definitely a good idea for images coming from something like an sdcard though.

Support has been added for the STM32F746G-Discovery board. Currently this includes support for only the LCD controller. Other peripherals will be added as we test them. As the STM32 m7 is a brand new processor you will need to update your software to versions that supports that cpu. Software that may need to be updated include: Your compiler eg GCC Your ST-Link drivers (This board uses ST-Link V2.1) The firmware on the ST-Link V2.1 controller. V2.J24.M10 is the first version to work correctly for debugging, the latest is currently V2.J24.M11 Your openocd version or other tool used for debugging. If you have trouble getting one to work ask us for the Windows version we compiled specifically for this. This board and processor is not currently supported by many operating systems (it is too new) so our example makefile uses the raw32 GOS port with the STM32 cube library for the m7. Make sure you use the STMcubeM7 version of the cube library (not the m4 version).

There is now a generic driver for the STM32 built-in LTDC controller. It currently uses the background layer for drawing operations and doesn't currently use the DMA2D controller available in some STM32 cpu's.

I have finally received a display module with the SSD1106 controller. I will test over the next few days and post the results.

I don't know if you noticed but I recently made this http://forum.ugfx.org/viewtopic.php?f=9&t=228 change. This should make incorporating ugfx as an arduino library MUCH simpler. When I get more time I will spend some more time on getting the arduino library tested and in the main repository. Note I also found and fixed an issue with the scheduler which should improve stability of ports like this.

I have finally had time to do a visual peruse of the drawing code to make sure that all the clipping would work for a zero sized area. Subsequently I have changed the behaviour of gdispSetClip() to allow zero size clipping regions as you suggested. The forum note is here: http://forum.ugfx.org/viewtopic.php?f=9&t=245 Thanks for the note and your work on researching this.

Previously gdispSetClip() would ignore the setting of a zero sized clipping area. It was treated as if the parameter was invalid. The behaviour has been changed to allow a zero sized clipping region to be set. This has the effect of not allowing any drawing as every drawing operation is completely clipped.

Sorry for it to take so long but I finally got some time to work on some strange crash issues. I found a problem with the raw32 scheduler that affects some of the more recent gcc versions. If you can please load the latest master and see if this fixes your crashing issues. This forum entry will provide more information on what was found. http://forum.ugfx.org/viewtopic.php?f=9&t=244

There is an issue with the raw32 & arduino scheduler that can cause hard faults on certain compilers. The issue has arisen due to recent gcc versions changing the way they calculate alignment for packing local variables on the stack. A fix has been added so it should work now with both new and older versions of the compiler. It will possibly also make it more compatible with other non-gcc compilers.

Having a clip size of zero should clip all display from happening as you suggest. Currently however setting a zero sized clip region is considered as invalid parameter values and is therefore ignored. If you believe that shouldn't be the case we will certainly listen however each drawing operation will need to be boundary tested to ensure that it doesn't cause any of the drawing operations to crash. If you are happy to test them all or even to visually verify that a zero sized clip area will be handled correctly then we will be happy to change the code to suit. Unfortunately it is the end of the financial year in our country and so I am too busy to do that testing myself currently at least for the next couple of weeks.

If you are using chibios and you are having speed issues then using spiPolledExchange may help. Note that the driver as talked about above was working, just not with the expected performance.

The polygon functions support translation and the gwin 3d widget supports full translation, rotation and scaling but other than that no. The reason is just complexity for embedded platforms. Come to think of it there might be suitable matrix operations in the GMISC module but I can't remember if they made the master repository. If they did make it they include those capabilities as either floats or fixed point math.

In ugfx there are two pixel formats involved; the system pixel format and the display pixel format. For a single display they are always the same. For multiple displays each display may have a different pixel format. The user selects (as part of their gfxconf.h file) the system format. It is normally picked to match the larger of the two device formats as translating colors is computationally expensive. Pixmaps always work using the system pixel format. 4bpp is definitely possible eg 16 color grayscale, but is not supported by the framebuffer driver. Translating to and from 4bpp to other standard formats is very computationally expensive so if you want to do that you should write a custom framebuffer that supports that format and use that format throughout to avoid color conversions.

By the way, for smallish displays (320x240) that you tend to see on embedded systems, the speed of the display itself is seldom an issue. A well written program, a well implemented board file (the software interface that describes the cpu - display electrical interface) make the biggest difference to display speed. The exception is some of the monochrome displays. These tend to be very slow

If you are wanting to display different parts of the image on different displays, this is easy to do in ugfx and you won't need to use pixmaps. The api calls for drawing an image allow you to specify which part of the image you want to show on each individual display. For speed reasons however you might consider using the image caching api or pixmaps unless your image is coming out of flash (using GFILE and ROMFS). Both caching mechanism however use a lot of ram. You will need to experiment as to which is best in your circumstance.

There is a difference between the two. From memory it is something to do with the runtime environment. A quick Google search should show you the difference. I do know however that the arm "none" compiler is the one you should be using for any embedded work.

I am hazy on the ecos details, it was a quite a while ago. The scheduler definitely needs to be started first before calling gfxinit. The details on how to do that I have forgotten. Essentially ugfx runs as a user thread once the scheduler is started as ugfx needs the multi-threading capabilities of ecos which are not available until the scheduler is started.

I didn't have that problem when I was tinkering with it but that was a while ago now. It looks like the ecos scheduler has not been initialised or something similar. Perhaps you can provide more back trace information so we can see the call hierarchy at the point of the exception.

There are a few things that might be happening here. .. 1/ The openocd file provided is designed to be used with the openocd driver for the st-link. If you are using the official st-link drivers you may need to change some lines in the file to match. 2/ openocd is a project that changes its api over time. It could be a version issue of openocd. The scripts have already been upgraded several times to take this into account. Maybe it is time to do it again. Later when I am on my computer I will look at which version we are currently using. I think this is the most likely issue. 3/ The scripts as provided are designed to be used using a combination of the script itself and parameters. The parameters tell it what to do eg whether to upload, or act as a debug target. It should be relatively obvious from the script itself but I can't remember how or if I documented how to use it.

Yes, I have run ugfx with ecos although it was a while ago. Can you please give us more detail on the error you are getting and we will help solving it.

Well done on getting it working! Yes. The default values can be set in your mouse board file or in your gfxconf.h If you look at the template board file you will probably find they are listed there already. If not look at a couple of the other mouse driver template files, you will see how it works.

Unfortunately chibios V3 is not stable. We have found lots of this sort of thing happening from time to time. Chibios V2 is much more stable although Giovanni from chibios sneaks changes to the api in from time to time that breaks things. The latest V2 version should work. I will look at updating the V3 chibios files as soon as I get a chance. Alternatively you could do that for us, we would definitely appreciate the contribution. The mikromedia STM32 m4 board with chibios V2.6.7 is what I use for a lot of my own development.

Just a additional thought... If you have one of the non m4 versions of the mikromedia boards you are still better off using our example m4 project but just change the cpu definition in the makefile. The reason is that I believe that mikromedia use largely consistant pin outs etc across their boards and just change the cpu. So you might still need to make modifications but it is a much better starting point than the STM32 100 board files.