Joel Bodenmann
-
Posts
2,656 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
Thanks for testing. I updated the repository.
~ Tectu
-
Thank you for reporting this warning. It has nothing to do with the ChibiStudio example.
When I remember correctly the ChibiOS/RT PWM HAL was updated quite a while ago and the PWMConfig struct gained an additional member. Can you please try to replace it with the config below and let us know if the warning vanished? We will update the repository code in that case.
static const PWMConfig pwmcfg = {
100000, /* 100 kHz PWM clock frequency. */
100, /* PWM period is 100 cycles. */
0,
{
{PWM_OUTPUT_DISABLED, 0},
{PWM_OUTPUT_DISABLED, 0},
{PWM_OUTPUT_ACTIVE_HIGH, 0},
{PWM_OUTPUT_DISABLED, 0}
},
0,
0
};~ Tectu
-
This is a 3rd party demo. This means that we (the µGFX developer) did not provide the demo/example project and therefore we don't know it.
In order for us to help you efficiently please open a new thread and provide us with all the information we need (Your hardware setup, your wiring, your board file and so on).
I'm sorry for this inconvenience but otherwise we'd have to digg through all the example projects that are out there and this costs us a lot of time. I hope that you understand.
~ Tectu
-
I never had any problems with using USB and µGFX at the same time.
Please open a new thread that addresses your problem (good thread name and all the information we need to help you).
~ Tectu
-
So your display is finally running?
~ Tectu
-
The errors you are getting is because your board file ueses the PWM peripheral of your microcontroller but you didn't enable it in your ChibiOS/RT configuration. You have to enable the PWM peripheral in your halconf.h and you then have to enable the corresponding PWM driver in your mcuconf.h.
Which readme told you to copy the board_SSD1289.h & gdisp_lld_SSD1289.c sources? That is completely wrong. The only thing that you copy into your project directory is the board_SSD1289.h.
~ Tectu
-
We have added the driver to the repository: https://bitbucket.org/Tectu/ugfx/commit ... eb6b2dfb90
Can you please check if everything works for you?
~ Tectu
-
I'll be out of the country from the 13th to the 17th of August for vacation. I had to promise my girlfriend not to take my notebook with me so I won't be able to maintain the forum.
The second uGFX maintainer, Andrew aka inmarket, will have a look at the forum during his spare time and handle posts accordingly.
Note: This will be my last vacation trip for a long time.
Thank you for your understanding.
~ Tectu
-
We also renamed the FreeRTOS files to avoid file name conflicts on case insensitive systems: https://bitbucket.org/Tectu/ugfx/commit ... e619ac333f
~ Tectu
-
We have added the missing type definitions for the FreeRTOS 7.x versions: https://bitbucket.org/Tectu/ugfx/commit ... cabe37a83a
Can you please make sure that everything compiles fine?
~ Tectu
-
No reason to be sorry
Did it work?
~ Tectu
-
You cannot simply return that string. You have to copy that string into a buffer and return the pointer to that buffer. Trunet showed how it's done in his code:
strcpy(buf, "\x75\xD4\x84\xBD\x94\xE3\x72\xBA\x73\x76\x7E\x43\x2D\x67\x28\xBA\x17\x3A\xBB\x3D\x41\x05\xFA\xC1");
return buf;P.S. Can you please stop quoting the previous post all the time? Quotes are used to answer specific text parts, not the whole post. It's getting very messy otherwise ;-)
~ Tectu
-
I can save the string like this: "Z,\202=\\\221b¹\037FaÁÅdI:䨹½´>³Cè\017" within the mysave function:
Can you please elaborate how exactly you get this string? Some GDB examination?
The normal process:
- Make 100% sure that your ginputSetMouseCalibrationRoutines() routine gets called before the ginputGetMouse() routine.
- At the first execution, make sure that the third parameter of the ginputSetMouseCalibrationRoutines() routine is NULL.
- Execute the program
- Either extract the calibration data using a debugger / serial console or any other kind of output or store it on non-volatile memory
- Set the third parameter of the ginputSetMouseCalibrationRoutines() routine to point to your actual loading routine which provides the data that you just exctracted/saved.
- Done. Your touchscreen should now automatically load with the correct calibration data.
The wiki does also have this information.
~ Tectu
- Make 100% sure that your ginputSetMouseCalibrationRoutines() routine gets called before the ginputGetMouse() routine.
-
Are undefined preprocessor symbols handled consistently across compilers?
I'm not sure, that's why I am asking ;-)
Thank you for your suggestion. Looks like a safe way to go.
~ Tectu
-
how can I convert the calibration values into this format?
What format do you mean? You can just assign them as any normal struct member:
cal->ax = 32;
cal->bx = 37;
...If you refer to the strcpy() command of trunets code sample; it looks like he used some debugging tool to retrieve those values and simply copy pasted them.
~ Tectu
-
Too bad that they don't have separate macros for each individual digit before 8.x.
I don't know FreeRTOS that well, what do you think about this?
#if tskKERNEL_VERSION_MAJOR == 8
/* Types for 8.x */
#else
/* Types for 7.x (and lower?) */I assume taht this should work as the tskKERNEL_VERSION_MAJOR macro should not be implemented at all at any < 8.x release.
~ Tectu
-
Thank you for the link. We'll take a look if it's possible to make the types conditional by reading out the FreeRTOS version (is there such a macro?) at compile time. We are doing the same to support ChibiOS/RT 2.x and 3.x in the same way.
~ Tectu
-
Thank you very much for your feedback.
We are aware of the conflicting file names on a case insensitive operating system since a short while. The changes have been made but not yet tested and pushed. We will push a fix to the repository this evening (GTM+01:00).
About the definitions: Which FreeRTOS version are you using? We have tested with FreeRTOS 8.x without any problems so far. Neither did any user report a conflict there.
~ Tectu
-
There is currently no such feature under development.
However, we are planning to work on that in the future.
~ Tectu
-
There are no doubt similar routines in other embedded RTOS.
Only if your RTOS comes with it's own HAL. Otherwise you have to manually implement these functions.
~ Tectu
-
Done
~ Tectu
-
I know that this starts to get unrelated but in my opinion the efficiency of the error branch (0 returned) is far from important as the expected behavior should be that in 99.9999% of the cases a proper tag is returned.
~ Tectu
-
Sorry that this took so long, trunet.
We have finally added your driver to the official repository. Furthermore we have added you to the contributors table.
If you want to tell us your real name, we can add it there as well.
~ Tectu
-
Probably we could just typedef the widget tag type so it is a signed value and we can use -1 for an invalid widget (so the user can check for < 0) and use the positive values including zero as the real tag values?
Otherwise I'll just note that down in the documentation very very carefully.
~ Tectu
lcd ssd1289 fsmc stm32f4discovery fuzzy
in Support
Posted
First of all we can be sure that this is no wiring issue as the display actually displays what it is supposed to (µGFX logo).
How long are your wires? Everything longer than 20cm will cause problems with the default board file.
As you said yourself you have to lower the FSMC speed. Look at the reference manual to learn about the different settngs. There are timings for address setup, data and burst operations. The timings are set in the init_board() routine of your board file (line 89 in your case).
~ Tectu