inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
Thank-you for this excellent contribution.
I will integrate it (possibly with a few minor changes) into the master repository over the next week or so.
Unfortunately this doesn't meet the requirements for the competition which is really about the GWIN widget set. We would however be very interested in your ideas for a new competition. Please post your idea's in this thread http://ugfx.org/forum/viewtopic.php?f=25&t=123
-
Ugfx doesn't currently support drawing to an off-screen pixmap. There is a work around however that will enable this to be done.
ugfx supports multiple displays. It would be possible to create a board file for the framebuffer driver for the off-screen pixmap and treat it as if it was a secondary display. If you set the pixel format of that pixmap to match your real display you can then use gdispGBlitArea to transfer that to your real display.
Using the new dynamic driver registration api it would also be possible to do this at run - time. In fact it is our intention to eventually add an api for creating off-screen pixmap drawing using exactly this method. Unfortunately this is however lower on our agenda so if you go to this extent please contribute it back as it would be useful for the community.
-
I am not sure I am reading your problem correctly but I think you are saying that the gfxMount fails because the driver is already active and it tries to initialise it again.
If that is correct, look for where the driver is being previously initialised in your code and disable that piece of code. GFILE assumes that it is the one that is going to be initialising and controlling the block device driver
-
No problem. We are here to help.
-
Optimization can definitely be a problem. I am not sure it is the problem in this case though. Easiest way to check is to simply turn off all optimisation and do a full build.
GCC in particular has some bad optimization bugs.
-
Wow! Now that is nice!
Very good work indeed and it is interesting the techniques you have used to make it work.
Can we reference your video on our demo page on the website?
Also, are you looking to turn it into a commercial product or is this a hobby project?
-
I just had a thought - have you seen the audio and/or the gadc demos. They similarly define a scope widget (although very basic) which demonstrates another way of doing it without a full frame buffer or even the ability to read pixel ram. It would be interesting to compare the approaches.
At the time I was developing on an Olimex SAMEX256 board with a Nokia6610GE8 display (a slow display with no pixel read capability).
-
Thanks for the description. Very interesting!
Unfortunately I don't have that hardware so I will await a video.
-
The master has now been updated. Set the define GDISP_NO_DMA_FROM_STACK to TRUE in your board file to tell it to use main memory instead of stack space for the define.
By the way, why are you using main ram for a framebuffer? Ugfx should work without a framebuffer for the SSD2119 controller.
-
Yes interesting problem.
Removing the local variable means that the translation from user pixel format to driver pixel format doesn't occur. This ok if the pixel formats are the same (your case) but is not ok generally.
There is however a simple solution - make c a static variable. This can also be conditioned on the use of dma, and optionally a define indicating the use of ccr memory.
I will make the change to the master to reflect this (and in other drivers the can use dma too)
-
These have been updated to the latest master. Can you please test the latest master.
-
Yes you are 100% correct.
Board files are always meant to be tweaked for the specific hardware and cable lengths etc to displays are often a critical factor.
In terms of initial settings, what tends to happen is that we (or someone else from the user base) gets a board file working on their hardware. That is then posted as the "reference" board file and it is only when someone else complains about it not working that it may be re - examined.
The main reason we don't perform a testing of conservative settings etc is just time. With ugfx there is just so much to do and Tectu and myself fit this around our normal work lives. In many cases we don't own the hardware as the driver/board files have been donated by a user (although I like to do a quality pass over the code before it makes the master repository).
It is for this reason that we so highly value your contribution in fine tuning these parameters to work on a much wider range of hardware. Without efforts such as yours ugfx would not be usable by a wide enough base of users.
Thank - you.
Your changes should make the master repository in the next few hours.
-
Thanks. I will integrate these changes asap.
-
Thanks for your work on this. Can you please post your updated board files and we will integrate the changes into the master repository?
Also the mouse testing, was that done against the current master. We have completely rewritten the mouse sub system since your previous post in June. The new system is much more tolerant of bad data and transitions.
The work you have done with frequency of the busses is fantastic and will be very helpful in getting great results. Thank you for your hard work.
-
Thank you. We will correct that asap.
-
Thankyou. We will fix it immediately.
-
There are a few reasons that the font files are currently in c files rather than h files...
- Historically it has just always been done this way
- The font generator generates a c file and to alter this would require changing old and fragile code (I am not sure we can even still compile the mcufont font generator utility)
None of these are really good reasons, it however just takes time to change these things and the effort involved has been very low priority considering the other work that we want to get done.
Note: this is not the only place in uGFX that c files get included into other sources rather than being compiled directly. Other places this happens include where we are incorporating third party code into uGFX such as FATFS. Doing it this way allows us to leave the original code unchanged and "patch" necessary changes into it using macro definitions from the file including the source. Unfortunately, other than directly modifying the third party code (which may create license issues) this is the only way this can be done.
Although using the IDE to directly "build" the project is possible - it is not our supported configuration. Our supported configuration is using a "custom makefile" project.
This avoids all of these sorts of dramas. Source files can then be included into the IDE without them affecting the build process. As proof of this, more than 30% of my development of the uGFX library itself is done using Em:Blocks (the other 70% is using the Eclipse IDE or the command line).
The original source of this thread related to an IDE that supposedly could not do custom makefile builds. That particular situation is still being investigated.
- Historically it has just always been done this way
-
It is not a bug so much as a difference in how the display is spoken to via a 16 bit interface versus a 8 bit interface.
The code you have changed is correct for a 16 bit hardware interface but will break an 8 bit bus interface. The code has previously only been used on such chips with an 8 bit processor interface. This driver is currently used successfully as-is on such boards as the Mikromedia STM32m4 board (which use an 8 bit cpu interface for the display).
Note that changing the bus interface width may also require changing some of the initialisation code to ensure the controller expects 16 bit wide data.
I will re-examine the code for the driver. It should be possible to define a MACRO that specifies 8 or 16 bit bus width and to alter the code correspondingly.
Can you please post your board file and your (modified) driver file and I will build an integrated solution for the master repository so we don't break boards that are using it with an 8 bit bus.
-
One more thing to try if you must use the chibios supplied makefile...
try changing the direction of the slashes in your absolute path to forward slashes.
-
I suspect you are running into a problem with make under windows. Depending on the version of make you are using it struggles to handle Dos style paths like c:\...
The way around this is to try using one of our example makefiles rather than a chibios based makefile. These makefiles can be found in /boards/base/xxx/example.
We have spent considerable effort trying to get the makefiles working properly under win32. The chibios supplied makefiles don't work properly under win32 using absolute paths.
Please also read our wiki article on your first project in win32.
One other bit... Make sure you are using the latest master as we found bugs in our makefiles as late as last week to do with absolute paths under win32
-
It looks like your GFXLIB define in your makefile (describing the location of the ugfx directory) is not correct.
I suspect that is why you get the permission denied errors - it just cannot find that directory
Similarly the "no rule to make" seems to indicate the same thing.
Hope this helps.
Andrew.
-
We are unsure of how to handle an IDE that won't allow such basic operations as to exclude files from a project tree or do a makefile build. We have not come across that sort of behaviour before on the many IDE's we have used. We will test mbed.org and get back to you
-
I would suspect the error is in the original font. A font with every character the same width is not the same as a monospace font because of kerning. If there is no kerning information in the original font then the two are equivalent.
That your font changed its display based on kerning information implies the original font had kerning information in it which a true monospace font should not have had.
Well done on finding the problem.
-
Whilst we are not the developers of MCU font, we should still be able to help you.
The function you mention is the correct one. What you are missing is that it also adds an inter - character gap which is font dependant. It could be that it is just an extra single gap but more likely your drawing routine is not taking into account the gap between characters thus leading to incorrect rendering and an error that appears to be string length dependent.
When implementing the gfxGetStringWidth() function for ugfx and the matching drawing implementation, the code needed to take account of this. The ugfx function should return the correct result.
In general you should use the ugfx functions rather than the base mcufont functions where ever possible if you are using ugfx. If not you will need to contact the author directly.
small frame buffer
in Support
Posted
Have a look at the new pixmap functions and demo that were added to the master just today.
Whilst images support caching in ugfx, it basically caches the whole image frame or nothing. Pixmap will probably be a much better fit for what you want.