Jump to content

spinnenfeind

Members
  • Posts

    9
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you Joel, this is very helpful for me. I did a local modification as recommended by you. I don't know anything about software versioning systems. If I want to do a pull request, I guess I need to sign up for GIT or CVS or something like that!? I will have a look at it, but it will need some time. Have a nice day!
  2. Thanks for your reply. It's not a high priority topic, because as I found out my STM32 micro has lot of computing power and I get high refresh rates also when I have to overwrite with my desired color. However, I just don't like the idea of having superfluous pixmap color filling - I always try to optimize, even it it's not necessary ? Is there a way to completely disable the background color initializations of all GDISPs (including pixmaps) that I use in my project? I would prefer to take care of it on my own and just get an uninitialized piece of display buffer / pixmap RAM.
  3. Hello, when I started to use pixmaps I thought that it is an area with undefined content which you have to clear manually. As I learned, a new pixmap is initialized with the default background color GDISP_STARTUP_COLOR. Is there a way to choose the default color of a new pixmap dynamically at runtime? I think it's a waste of runtime to fill it with GDISP_STARTUP_COLOR first, and then overwrite it with the actually desired background color. Similar question for the orientation: I have to change the orientation of each pixmap that I create by using gdispGSetOrientation. Is there a way to set a default pixmap orientation? Thanks, spinnenfeind
  4. inmarket, thanks again for your hint. I've been working on that for days and it drove me crazy. Finally, it was a problem with my toolchain. I was using plain command line gcc based on devkitPro. After importing the uGFX demo into Chibi Studio, everything is fine. Soft FPU, hard FPU, no problems at all. I'm happy, although I lost trust in my former toolchain.
  5. Ok thanks for answering. You're right, hard float should work with pure Chibi before switching to uGFX. I will analyse that. However, as far as I understood, also USE_FPU=softfp will use the hardware floating point unit, it's only a difference in calling convention!? I need to take a closer look. Thanks so far, Tobias Bye the way, just to give some positive feedback as well - it's really cool stuff what you can do with uGFX. A complete window manager with a lot of widgets, even tabs, touch input elements. It's easy to use those elements, since there is a good documentation & Wiki. Thumbs up!
  6. Hello, I'm using the ChibiOS/STM32F429Discovery demo and wanted to start using float datatype together with math.h functions (therefore I added -lm the the options in the makefile). In the uGFX demo (based on ChibiOS 17.6) I have the following problems: If I set USE_FPU=hard, the software traps immediately (I have no debugger, but I think it doesn't even reach main()). If I set USE_FPU=no or USE_FPU=softfp, the software starts but it traps as soon as I call a float math lib function like powf(). So I downloaded a plain ChibiOS 17.6.4 without uGFX and put the same test calculations into main(). It works fine with USE_FPU=no or USE_FPU=softfp If I set USE_FPU=hard, the software starts but it traps as soon as I call a float math lib function like powf(). In the uGFX STM32F429Discovery demo, are the any FPU specific changes? Different startup code (which is needed to enable hard FPU) or anything else? I'd like to use float, preferred solution is hardware FPU, but soft float would also help a lot. Thanks, Tobias
  7. Hello Joel, thanks for your welcome and quick response! I tried both finger and a dedicated touchscreen pen, makes no difference. From what I saw in the source code, it should show an error message if calibration fails, but in my case, nothing happens after pressing the 4th crosshair. The crosshair disappears, the text "Calibration" remains forever. No error message, it just blocks. For my first tries I do not need touch input, and the demo slider even works well with self calibration, so I'm happy. However, when I go deeper into touch input, I can try to switch finger/pen mode. Thanks so far!
  8. OK, I solved the problem by setting GMOUSE_STMPE811_SELF_CALIBRATE to TRUE. No calibration screen anymore, demo starts directly into the graphics screen including a working slider, and LED is blinking. However, would be interesting to know why the calibration routine blocks.
  9. Hello uGFX community, I'm absolutely new to uGFX - up to now I was just using some simple alphanumeric displays. However, I've been working with ChibiOS for some years, so I would like to give the combination of a nice OS with a nice gfx lib a try :-) For my first steps I chose this example: I can compile it without error, however there are several warnings. If I execute the hex, I get a blue screen with text "Calibration" and some kind of cursor which I have to press on the touchscreen. After pressing, the cursor shows at another position: 1. Uppler left corner 2. Upper right corner 3. Lower right corner 4. Center of screen After having pressed the center cursor, the cursor disappears, but nothing happens. The screen still shows "Calibration". I guess this calibration takes place somewhere in the uGFX initialization function. Because when I look into main.c, there is nothing about calibration, but a lot of text and graphics drawing, which does not seem to be executed in my case. Also there is no blinking LED on the board. Is there a technical problem, or did I just not understand how to use the example? Any other screen position or hardware button which I have to press to leave the calibration? Thanks for your help! Tobias
×
×
  • Create New...