inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
The inclusion of the path when including the gdisp_lld_config.h has historically been required. This is due to multiple display support. I have been slowly changing things to a directory relative path where possible in the latest code. The full path should have worked for you anyway as you included "../ugfx_lib" in your include path and that path is relative to that directory.
The board file that you are using has been written assuming the ChibiOS operating system. It is ChibiOS that has provided the rccEnableAHB() function and the FMSC_Bank1 global variable.
Board files are the interface between the driver and the real hardware. They don't need to know about how to drive the controller but they do need to know how to talk to the hardware. As this often involves SPI or some other function that is wrapped by the operating system, these board files tend to be hardware and operating system specific.
As you are using RAW32 the board file will need to be updated using whatever mechanism you have available to you to talk to the hardware eg some combination of the STM32 library and direct bit banging.
FMSC_Bank1 refers to the STM32 FMSC registers, FSMC_BCR1_MBK is a STM32 bit within that register set and rccEnableAHB() is a function provided by ChibiOS to enable FMSC operation on a STM32 cpu. Similiarly palClearPad() and palSetPad() are functions for GPIO pin manipulation provided by ChibiOS.
I hope that helps.
-
You might find it easier to move forward the ugfx integration. Reasons this may help...
1. ugfx supports bare bones implementation using the raw32 pseudo operating system. You only need to provide a tick counter. This also supports (cooperative) multitasking.
2. Ugfx already has implementations of printf etc.
3. Many of the drivers you mention are already provided by ugfx. You only have to write the driver to real hardware interface layer. This layer is written in the ugfx "board" files.
In short it could save you a lot of work.
-
The 3d extensions for ugfx using the tinygl library can certainly do what you are asking. Unfortunately it is ram heavy as it requires a depth buffer.
The rotation could otherwise be implemented using fixed point matrix operations. Scaling could be implemented in the same step. Floating point operations should be avoided as most small micros don't have floating point units so the operations are emulated (very slow).
If you would like to assist in such an implementation we would love your contribution. Other than that this sort of functionality will probably only be implemented when our development queue shortens a bit unless the demand for these operations is high.
-
-
Over the last couple of months we have been communicating with various experts over the issue of linking to GPL and other open-source licenses. It is a difficult area and the licenses are generally poorly written. This means that the licenses are often misunderstood.
Based on those discussions we have now updated our licensing page http://ugfx.org/licensing to provide a much better description of the compatibility of various licenses and what you have to watch out for.
We hope this will clarify many of the questions that have been put to us about licensing. If you have any questions that are not covered by that page please feel free to contact us.
-
I may be stating the obvious but you will need to turn on the FATFS support (GFILE_NEED_FATFS). That is what provides the ability to read the FAT file system on the SD-Card.
The connection between FATFS and the SD-Card itself is currently done using the FATFS method - see the FATFS documention about their diskio interface.
We have already implemented that interface for ChibiOS and we intend to simplify this for other operating systems soon by creating a block device driver abstraction.
For the moment for anything other than ChibiOS you need to do what Tectu said - implement the FATFS diskio.
If it helps, the ChibiOS version is found in src/gfile/gfile_fatfs_diskio_chibios.c
Also of interest might be the PETITFS option (GFILE_NEED_PETITFS). It also provides a FAT file system interface but with much less code. That also means it has restrictions that FATFS doesn't; mainly it is read-only and only one file open at a time. It's diskio interface is similar but slightly different to that of FATFS.
-
We are currently making some changes to the API that may affect some user programs.
Some have occurred already whilst some are still in the pipe-line.
Note these will only affect programs using the current master in the repository. It will not affect "releases" such as the V2.1 release.
The changes that have already occurred are:
- GEvent's that are sent by GWIN components have had the field containing the GWIN handle renamed to 'gwin'. Eg For GButtonEvent, pe->button has become pe->gwin. All GWIN events now have commonly named (and positioned) members wherever possible.
- All driver makefiles have been renamed "driver.mk". Although this was the name used by some drivers previously, it is now used for all driver makefiles. You may need to alter the includes for drivers in your project makefile.
The changes that will be happening within the next month (depending on how quickly we get it done) are:
- The driver infrastructure will be changing to support multiple drivers of any type. Previously multiple displays were the only multiple driver situation allowed. Unfortunately this will change the driver API for most drivers. Any drivers in the repository will be updated but any custom drivers in a users project will require modification when this is released. If you have a driver you would like us to upgrade for you as part of this transition then please send us it now to add to the repository. Note: custom board files will not need to be modified - only custom driver code.
- As part of the driver structure transition, the current configuration settings for multiple displays will change. If you use multiple displays, you will need to change your gfxconf.h once this change is released.
- A number of old deprecated API functions that still compile will be removed. In most cases these functions currently produce a compiler warning so you should be aware already if your code currently uses these functions. An example is the old functions for loading images from various sources. These were replaced with functions that use GFILE to load the image some time ago.
For most users these changes should result in little or no changes to their project code. If you have any difficulties with the changes please let us know in the appropriate section of the forum and we will help you where we can.
- GEvent's that are sent by GWIN components have had the field containing the GWIN handle renamed to 'gwin'. Eg For GButtonEvent, pe->button has become pe->gwin. All GWIN events now have commonly named (and positioned) members wherever possible.
-
It is also possible that your fonts are not valid ttf fonts (atleast as far as the freetruetype library is concerned).
Try converting a known working font such the UI font found in the repository. That will tell you whether it is the font converter or your fonts that are the problem.
-
The framebuffer driver is not the best one to model it from.
Monochrome drivers don't fit into the framebuffer model because there is more than one pixel packed into a byte. To add that capability to the framebuffer would needlessly complicate the code.
Instead try using the PCD8544 driver as a base.
It also is a monochrome driver running over SPI.
-
Those changes have been put back into the repository.
I also removes the Portrait and Landscape orientation cases as they are handled automaticly by the higher level code.
I have also added your board file to the boards/addons/gdisp directory.
Thank-you.
-
Good catch. It is now fixed in the repository.
There are two cases for the close - one with GWIN_BUTTON_LAZY_RELEASE and one without. In one case it was using the wrong destroy routine which would have caused the lockup, in the other it wasn't sending the close event.
The close event MUST be sent before the destroy because the send code accesses the structure to get the tag to put into the event.
You are right, line 312 was a typo and has also been fixed.
Thanks.
-
This has now been fixed and a GEVENT_GWIN_CLOSE event is now sent.
Because I have changed the structure slightly for GWIN events you may have some small changes to make in your code.
Basically pe->button, pe->slider, pe->frame, pe->list etc have all been renamed to pe->gwin (being the handle of the window creating the event). All GWIN event structures now have the same "type", "gwin" and "tag" elements.
-
Thank you for this great work. We will add it to the master repository.
-
I will re-add this event for you asap.
I am thinking of adding events for all gwin significant opens such open, close, resize. Now might be the time to do it.
-
This bug has been found and now fixed.
-
The c standard says that undefined macro variables if used in an expression will evaluate as 0.
Not all compilers always follow the rules though.
Try...
#if defined (var) && var == 8
-
Write the save routine to output the data to a debug console in binary hex. You will then be able to read the results and potentially hard code them into your load routine.
Note the data is binary not text and may contain as ascii null characters.
-
General anti-aliasing is a hard thing. With some displays it is actually impossible. Anti-aliasing requires knowing the surrounding pixel values. If a display has no read back capability this obviously cannot happen. With text anti-aliasing on these types of displays we can still anti-alia but only if we are also filing the background.
So, any general anti-aliasing support will only ever be possible on certain types of display. This is the primary reason it had been low priority for us. There is just so much else to do.
-
Send us your board file and/or the link to your repository and I will add it ti the official ugfx repository as either a full board definition or in the boards/addons directory.
It is a pleasure to help where we can. Well done on getting it going.
-
It is pretty hard to tell from the video however it appears it might be a problem with the back-light or with the display not being driven.
Close visual inspection might help you determine which is happening.
- For a back-light issue: At reset it appears the backlight turns full on and then partially fades out leaving horizontal bars. Check the black-light is set to 100% and this is done as a solid logic level drive rather than a PWM signal. A PWM signal to the back-light at too high a frequency might cause this behaviour. If it is definitely the backlight but not a PWM issue then there is a hardware fault with the LCD panel.
- If it is not the back-light: It appears as if the display might not being driven at all. That explains the "fade" affect as the capacitance on the display charges or discharges. Perhaps the display is still in the "OFF" state or the address you are using to talk to the display is incorrect. Check the board file for the display matches your physical display connection. Double check that the display controller is what you think it is and that it matches the driver you are using. There are many E-Bay purchased displays that are mis-labeled with regard to their controller chip. Also, because physical line length to the display significantly affects timing, use the shortest possible connections between the display and your board. In your board file also choose the most conservative timings possible at least until you have the display operational.
Hope that helps.
- For a back-light issue: At reset it appears the backlight turns full on and then partially fades out leaving horizontal bars. Check the black-light is set to 100% and this is done as a solid logic level drive rather than a PWM signal. A PWM signal to the back-light at too high a frequency might cause this behaviour. If it is definitely the backlight but not a PWM issue then there is a hardware fault with the LCD panel.
-
The rawrtos code has been added to the repository.
There were a couple of minor changes made to the code for compatibility with other platforms so can you please test it to make sure I haven't broken anything?
For the helper2416 board, in your code parts of the mouse and video drivers have been located in routines outside the uGFX framework. Whilst this is fine for the video driver as it is localised to the hardware specific board file, I will have to think about how to integrate the mouse driver so that uGFX driver can be stand-alone but still allow you to share part of the driver code with systems outside of uGFX. I should get this done over the next week or so.
Many thanks for your great work.
-
If using consecutive tag values starting from 1, 0 as the do nothing case works well as the compiler should generate a switch jump table where 0 is the first element of that table thus leading to the most efficient code (no table offsets to add by the compiler).
-
Wow, that is fantastic work!
Over the next few days we will look through the code and integrate the important bits back into our official master repository so that raw-os becomes a fully supported platform.
-
Getting round this behaviour is difficult and relies on "error" values. It is easier to assume that 0 is that error value. It correspond nicely to an default initialised init structure. As the user sets tag values there is no reason that zero is any worse an error value than any other and there are a number of implemtation reasons why it makes a good one in this situation.
Using uGFX on bare metal with Coocox coIDE
in Support
Posted
Just as a little tidy up aside,
gfx.h does not need to be copied to a local project directory. It is never changed by a ugfx program and can be found from the include path "../ugfx_lib".
Similiarly, as the gdisp driver files are not altered you could just add them to the compile from where they normally sit in the master ugfx source. The board_ILI9325.h file would then be placed in the same directory as your gfxconf.h file.
Well done on the work you are doing here. Documenting as you go is a great idea.
Thank-you.