Jump to content

inmarket

Moderators
  • Posts

    1,295
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by inmarket

  1. This is something I have been thinking about for a while now. I have been thinking that there is potentially another layer of abstraction that can be applied here. That is as a general settings register much like the windows registry but without all the complications. This background thinking was part of the recent addition of the gfile module. The register could be implemented as a file or pseudo file on any storage system that can be hooked into gfile. Storage in raw flash blocks, in a ROM file, in a file on a FAT file system would all be possible. The delay in making this happen is always time. Gfile is not complete enough yet and more api needs to be designed and tested. We are currently working on adding FAT file system support to gfile. So perhaps we are getting close. A contribution in the area of a general settings register appropriate for an embedded platform would be highly appreciated.
  2. I have not specifically had much to do with that particular touch device however we used to have similar problems with the MCU touch driver. The reason ended up being due to spurious readings occurring across the touch event as the touch is being depressed or released. The workaround was to lower the polling rate (less chance of getting the reading during the indeterminate period). The fix was to not accept a reading until you had two readings in the same depression state. I suspect that something similar is going on with your controller. I will look in the next few days. At least it is operating acceptably for you currently. Thanks also for the hint with the back light.
  3. Nice work. Looking at the repository we now seem to have 3 drivers that handle the ILI93xx range... The repository ILI9320 driver (which also seems to handle 9325's) The repository ILI9325 driver (based on chinese code?) Your driver. As I do not have one of these particular displays, could you please have a look at the 3 drivers and see if it is possible to easily integrate them into a single driver or at least tell me which is the best so that I can remove the duplicates from the repository. Also, what board was your board file for? I will then add it to the appropriate directory in the repository. Many thanks for your contribution.
  4. Thank-you for your contribution. I have added it into the repository under the boards/addons/gdisp directory.
  5. Good and bad accessing the SPI registers directly. On one hand it is operating system independent (a good thing for uGFX), but on the other hand that then makes it CPU specific. So pluses and minuses.
  6. This has now been updated in the source repository. Thanks for finding this bug.
  7. The problem is in the example gfxconf.example.h In your gfxconf.h replace the lower-case "x" in the font name with an upper-case "X" and it should all work. I have updated the source repository to fix this.
  8. This is now fixed in the master source repository. Thanks for bringing it to our attention.
  9. Thanks for finding it! I will adjust the code to fix this problem. I am a little swamped with my day job so it may be a little while but it will eventually be in there.
  10. It looks like the bit order is reversed relative to the display. In other words: Bit 0 is where Bit 7 should be Bit 1 is where Bit 6 should be etc Hope that helps.
  11. Interesting problem as the two methods should be completely equivalent. FYI - I am currently using the same compiler with no troubles but with a different processor. To give you some background... There are a number of other places in the code where structure copy is used (although not all that commonly) We generally try to avoid using memcpy() to avoid dependence on system header files and system libraries (which are not always 100% compatible) Some things to look at: Stack - perhaps the stack is being overrun? Does changing the compiler optimiser flags change the code generated (ie could this be an optimiser problem)? Exactly what hard-fault is being generated as that might indicate what is going on? Perhaps it is the compiler flags for code generation are not quite right for your processor? If it is using an implicit system library call to do the structure copy, perhaps the system library has been compiled incorrectly for your processor. Is it a bus alignment issue - ie the memory returned by the load function is non-bus aligned and the structure copy is assuming bus aligned data. If you can please investigate these things that would be appreciated as I would prefer to avoid the use of memcpy unless necessary. This problem may also affect other area's of the code if it is a systemic problem that we need to handle. Thanks for bringing this to our attention.
  12. I have an idea on what might be going on. Can you please define GDISP_NEED_CLIP as FALSE in your gfxconf.h file and see if the symptoms continue. I suspect it is a multi-threading issue with the way that gwin uses the clipping calls. If the symptoms dissappear i know what needs to be done to fix it properly.
  13. Thanks, that test was perfect. The problem has been fixed in the current master repository.
  14. The old arc routines were significantly broken and have definitely been updated for the new code. Arc's on the old system were VERY problematic and almost never got it right. Filled arc's previously did not even fill the arc area properly leaving a moire type pattern of gaps. It is however quite probable that there are some boundary cases which my testing didn't include. Can you please upload me a short demo program that demonstrates the problem. Replace any variable numbers with absolutes (for example replace things like gfxGetWidth()/2 with an actual number) as the problem could be location and size specific. I will get right on to fixing the problem for you.
  15. inmarket

    How To Start

    The reason that the readme just says to include the one file but the example file includes two different files is because the Mikromedia board is not a board that is supported by default in ChibiOS. The additional line in the example Makefile was to add the support for that board to ChibiOS (which is really quite independent of uGFX). The additional line is included in the example Makefile so that the makefile is complete and compilable with potentially no other change than to change the location of where uGFX and ChibiOS has been stored relative to your project directory. Similiarly the ChibiOS_board directory is purely to add the files to ChibiOS to support that board.
  16. We have currently written full GOS layers for Linux, OSX, Win32 and ChibiOS. We have chosen these simply because those are the operating systems that most of our user community want. A bare metal implementation will be very dependant on what that bare metal is so bare metal implementations would normally be written by the end user for their specific hardware. We might in future do one for the most popular hardware but this is not high on our priority list currently. We would be very happy to receive a contribution from a user for this however. In practice, implementing the full GOS layer is probably not required for many situations. For example, if you are only using the GDISP module you will not need to implement any of the multithreading support (or mutexes, semaphores. memory allocation etc) in the GOS layer. If however you are using GTIMER timers, the GINPUT subsystem and/or the GWIN widget library then you will probably need most of the GOS layer implemented. Have a look at the existing GOS layers. They are VERY easy to implement. In most cases it is just a bunch of macro definitions to the equivalent functions in your OS or hardware library. Note that while all the drivers are operating system independent, many board files use the operating system mechanisms to talk to the real hardware. You might need to adjust the board.h files for your drivers in order to talk directly to your hardware (just as you would have to if you were using custom hardware). We would happy for a contribution to implement a partial or full GOS layer for a hardware specific library.
  17. inmarket

    SSD1306 driver

    Just a little explanation of the new driver/board directory structure... Drivers are in the "drivers" subdirectory. They will include a board_XXXXX_template.h file which is obviously an empty template for the board_XXXXX.h file used in the real project. The template file can be copied into your project directory and compiled without changing (except for the rename). It will obviously do nothing as there is no real code but it enables all the drivers to atleast be compiled on any platform. The "boards/base" directory contains all the necessary files for a predefined "base" board. For example, if you have a Mikromedia-STM32-M4 you can include the board.mk file in that directory into your makefile and it will add in all the drivers (and the necessary board files) for the hardware on that board. You only need to add any extra custom hardware drivers. In each board directory there is also a example project that you can just copy and have a working demo for your hardware. The "boards/addins" directory contains example board files for any other hardware. They illustrate various ways of interfacing to the drivers. Typically a suitable one would be copied into your project directory and then modified to suit your hardware. This scheme enables us to support standard boards whilst still allowing you to add the extra bits into your project for any non-standard hardware bits you have. Even the predefined boards are optional - they just make getting started on those boards a lot quicker.
  18. inmarket

    SSD1306 driver

    There are a couple of problems with the scrolling routine as implemented and why I took out the original implementation. I also have a suggestion for a better way to implement it... The scroll routine as implemented assumes that you are always scrolling the full width of the display and exactly one page line in the upward direction. This does not match the GDISP API which allows arbitrary scrolling window sizes and either direction It is no longer needed in the new driver to get scrolling as the higher level layer supports scrolling provided a readpixel is defined (which it is for your driver) The new requirements for gdisp_lld_scroll() no longer requires anything to be cleared as the high level layer does that separately. Instead the gdisp_lld_scroll() routine only needs to move the bits around that are being scrolled The biggest problem of the above is that the new routine doesn't match the API specification. I can see however that a special hardware assisted scroll may be useful in the limited situations your scroll supports and it would be faster on slow cpu's. I will look at adding code to the high level to support a special hardware accelerated but limited situation scroll if the parameters to gdispVerticalScroll() match what is supported in hardware. It will use software emulation if the parameters don't match. This however is a bit of work so it won't happen right now. Quite a large number of displays support full width only scrolling in hardware so this may be a useful addition particularly for small displays where a full width scroll is more likely. I am reluctant to include that scroll routine in its current form as it doesn't match the API specification. I would suggest then that your special situation scroll be implemented as a driver specific gdisp_lld_control() code (much like the flush was in the v1.9 driver) for the moment. If you can make that change I will then include it in the new driver for the SSD1306. Although Version 2 has not been released yet, I will happily include any updates to GDISPStreaming branch either before the merge or after it becomes v2.0. As for the source control - we use to use GitHub but migrated to bitbucket because of various problems we had. Setting up a bitbucket account is free. If you are running Windows they also have a very nice piece of free software called sourcetree.
  19. inmarket

    SSD1306 driver

    The master branch is at a point where we have locked it off and stopped making any changes. We are about a week away from merging the GDISPStreaming branch into the master and releasing it as v2.0. The code in the GDISPStreaming branch is ready to go now - Tectu is just busy this week and he needs a bit of time to write release documents and update the website to match. If you have any updates and changes relative to the GDISPStreaming branch I will be happy to incorporate them. I am guessing from your previous post that there are a few changes to be made relative to the spi board file in the GDISPStreaming branch. Can you please post the updated SPI board file and I will integrate it immediately. Note the location for the example board files has now changed. They are now stored in the boards/addons/gdisp directory if they are not specific to a particular base board. Thanks for your work. It is very much appreciated.
  20. inmarket

    SSD1306 driver

    The issue with the command byte has now been fixed. Have a look at the updated code as I found a way of doing it without copying the data onto the stack. The overhead is one byte of RAM per page line (8 bytes total). Can you also please test again.
  21. inmarket

    SSD1306 driver

    Thanks for the testing. I thought that might be the case with the board file. Does that also apply to the spi interface? I will see if I find another way of including the extra byte as it seems a shame to allocate a whole new buffer and copy the line particularly as stack seems to be a critical resource for most processors. I should have the fix up later today. The GDISP_NEED_SCROLL turns on the gdispVerticalScroll() function - in other words the GDISP API for scrolling. GDISP_HARDWARE_SCROLL says that the controller supports hardware accelerated scrolling. Note with the new code that GDISP_NEED_SCROLL now works even if there is no hardware support for scrolling provided the low level driver provides a read pixel routine (and yours does). With the new code, provided there is a read pixel routine (which there is for your driver) you don't need to specifically implement a scrolling routine any more as the high level code will do it for you. If you want to define a hardware accelerated version you need to specify GDISP_HARDWARE_SCROLL in the gdisp_lld_config.h file for the driver. Note that most controllers only support full screen width scrolling which is not sufficient to support the GDISP vertical scroll method. I think I glanced at the datasheet for your controller and that was the case for the SSD1306 as well (although don't quote me on that - you know the controller much better than I) and if so then the only possible implementation is via the high level code using the read pixel routine. This was actually why I added the vertical scroll handling to the higher level code - it is a common operation but few controllers seem to support a variable width vertical scroll natively.
  22. inmarket

    SSD1306 driver

    I have integrated the changes into the GDISPStreaming branch of development (which will soon become version 2.0 of uGFX). There has been significant changes to the GDISP low level driver interface to enable some major new features such as support for multiple displays, a formal gdispFlush() call and even automatic flushing. Can you please test the GDISPStreaming branch for your controller as I don't have equivalent hardware myself. One change you will need to be aware of is that the gdisp_lld_board.h in your project directory should now be called board_SSD1306.h. The interface has also changed so start from one of the template ones provided. Thanks for your contribution. It is appreciated. I also notice that you have started adding a GTimer to your code (although it does nothing yet). I presume this is so you could do flushing using the timer. I really like the idea and now that flushing is officially supported by the new GDISP framework, I think I will add that concept to the framework itself so it can be used by any driver that needs flushing.
  23. There is currently work being done on restructuring the internals of the GDISP module. The API will stay compatible with existing code. Included in this work are some nice new features... GDISP streaming. This could, for example, enable video playing in a window while still allowing normal GDISP calls to be used around the edges to draw controls etc. This is also very useful for games and other programs that need to access an area of the screen in a super-fast sequential manner. GDISP low level driver restructure. This is to simplify the writing of most drivers. Complexity to do with optimization, clipping etc have been moved to higher level code, significantly reducing the amount of code for most low level drivers. Drivers for devices that support window streaming type operations are now extremely easy to write with full optimization applied by the higher level layers. Multiple displays. Currently GDISP supports only a single display. The new code will allow multiple displays to be simultaneously used on the same board even if they use different controllers. Support for memory mapped displays. Every memory mapped display currently requires its own driver. With the new low level drivers a generic "memory map" driver allows for connection to any memory mapped display (eg a Linux framebuffer) simply by changing the interface board file. Support for virtual RAM based surfaces. This enables a bitmap display to be created in RAM, of any size (subject to available RAM). It can be drawn on using the standard GDISP calls. It can then be used to fast bitblit to a real display, or can be saved in a file. A video demo showing the new streaming features and drawing optimization can be seen here http://youtu.be/GMfb97wbwq4 This is definitely a work in progress and not all the features listed above are available yet. In fact currently only the Win32 and the Nokia6610 drivers have been ported. If you feel like having a play or porting your current driver, the code is in the GDISPStreaming branch of the source repository.
  24. Currently the GDISP clipping area is an inclusive clipping box i.e. the area INSIDE the box gets drawn, anything outside does not. I can see that for menu's and other "pop-up" or on top items an exclusive clipping area would be useful (only things OUTSIDE the box get drawn). If I get time I might add support for an exclusion area to the new GDISP code I am currently working on. This would certainly be useful for single window overlaps like menu's. It would have to be called manually when displaying your pop-up until GWIN supports maintaining an expose list.
  25. GWIN comes with a VERY basic window manager. Whilst it handles visibility etc, it currently does not support overlapping windows. Drawing is only clipped to the window boundary not to the windows expose area. If fact, with the current window manager, an expose area for each window is not even kept. This restriction is fine for most small embedded systems as it is simple and requires minimal RAM and speed overheads to manage. This principal of keeping things tiny and simple even extends to some of the window types. Whilst all widgets can redraw themselves if requested (eg if they are revealed by the removal of another window), other window types like graph and console cannot. To enable them to do so would require that they "save state" in RAM and this would make them very expensive for small CPU's (and possibly impossible due to insufficient RAM). As the window manager is now a "plug-in" interface it should be possible to write your own more complex window manager and use it by calling gwinSetWindowManager(). See src/gwin/gwm.c for the implementation of the current basic window manager. I suspect that extra support will be required in the basic GWIN code to help support this, simply because GDISP currently only supports simple box type clipping area's. This is not insurmountable however if you implement a box region cache within the window manager. When the first window manager gets written that supports overlapping windows we can adjust what is necessary in the basic GWIN code. This is not simple stuff to get right and so for now it has been on the back-burner as we implement higher priority items. We would love it if someone (perhaps you) took on the challenge of writing a window manager capable of handling overlapping windows and then contributed it back to the project.
×
×
  • Create New...