9 changed files with 1 additions and 576 deletions
@ -1,289 +0,0 @@ |
|||
ChibiOS/GFX coding style |
|||
|
|||
To provide an easy-to-read code, we want to have a uniform |
|||
coding style within ChibiOS/GFX. |
|||
Because I personally like the widley used linux kernel coding style, |
|||
I decided to use it for ChibiOS/GFX as well. |
|||
Therefore, the coding style documentation is a 1:1 copy from the |
|||
codingstyle.txt of the linux kernel source code. |
|||
|
|||
Please make sure you match these coding styles before you contribute |
|||
any code. If you find any existing code which dosen't match these rules, |
|||
please feel free to submit a patch. |
|||
|
|||
There are only two rules which are not similar to the following |
|||
documentation: |
|||
|
|||
- Prefered tabsize is 4, not 8 |
|||
- We don't use 80 character columns |
|||
|
|||
|
|||
Please read through the following carefully: |
|||
|
|||
|
|||
|
|||
Linux kernel coding style |
|||
|
|||
This is a short document describing the preferred coding style for the |
|||
linux kernel. Coding style is very personal, and I won't _force_ my |
|||
views on anybody, but this is what goes for anything that I have to be |
|||
able to maintain, and I'd prefer it for most other things too. Please |
|||
at least consider the points made here. |
|||
|
|||
First off, I'd suggest printing out a copy of the GNU coding standards, |
|||
and NOT read it. Burn them, it's a great symbolic gesture. |
|||
|
|||
Anyway, here goes: |
|||
|
|||
|
|||
Chapter 1: Indentation |
|||
|
|||
Tabs are 8 characters, and thus indentations are also 8 characters. |
|||
There are heretic movements that try to make indentations 4 (or even 2!) |
|||
characters deep, and that is akin to trying to define the value of PI to |
|||
be 3. |
|||
|
|||
Rationale: The whole idea behind indentation is to clearly define where |
|||
a block of control starts and ends. Especially when you've been looking |
|||
at your screen for 20 straight hours, you'll find it a lot easier to see |
|||
how the indentation works if you have large indentations. |
|||
|
|||
Now, some people will claim that having 8-character indentations makes |
|||
the code move too far to the right, and makes it hard to read on a |
|||
80-character terminal screen. The answer to that is that if you need |
|||
more than 3 levels of indentation, you're screwed anyway, and should fix |
|||
your program. |
|||
|
|||
In short, 8-char indents make things easier to read, and have the added |
|||
benefit of warning you when you're nesting your functions too deep. |
|||
Heed that warning. |
|||
|
|||
|
|||
Chapter 2: Placing Braces |
|||
|
|||
The other issue that always comes up in C styling is the placement of |
|||
braces. Unlike the indent size, there are few technical reasons to |
|||
choose one placement strategy over the other, but the preferred way, as |
|||
shown to us by the prophets Kernighan and Ritchie, is to put the opening |
|||
brace last on the line, and put the closing brace first, thusly: |
|||
|
|||
if (x is true) { |
|||
we do y |
|||
} |
|||
|
|||
However, there is one special case, namely functions: they have the |
|||
opening brace at the beginning of the next line, thus: |
|||
|
|||
int function(int x) |
|||
{ |
|||
body of function |
|||
} |
|||
|
|||
Heretic people all over the world have claimed that this inconsistency |
|||
is ... well ... inconsistent, but all right-thinking people know that |
|||
(a) K&R are _right_ and (b) K&R are right. Besides, functions are |
|||
special anyway (you can't nest them in C). |
|||
|
|||
Note that the closing brace is empty on a line of its own, _except_ in |
|||
the cases where it is followed by a continuation of the same statement, |
|||
ie a "while" in a do-statement or an "else" in an if-statement, like |
|||
this: |
|||
|
|||
do { |
|||
body of do-loop |
|||
} while (condition); |
|||
|
|||
and |
|||
|
|||
if (x == y) { |
|||
.. |
|||
} else if (x > y) { |
|||
... |
|||
} else { |
|||
.... |
|||
} |
|||
|
|||
Rationale: K&R. |
|||
|
|||
Also, note that this brace-placement also minimizes the number of empty |
|||
(or almost empty) lines, without any loss of readability. Thus, as the |
|||
supply of new-lines on your screen is not a renewable resource (think |
|||
25-line terminal screens here), you have more empty lines to put |
|||
comments on. |
|||
|
|||
|
|||
Chapter 3: Naming |
|||
|
|||
C is a Spartan language, and so should your naming be. Unlike Modula-2 |
|||
and Pascal programmers, C programmers do not use cute names like |
|||
ThisVariableIsATemporaryCounter. A C programmer would call that |
|||
variable "tmp", which is much easier to write, and not the least more |
|||
difficult to understand. |
|||
|
|||
HOWEVER, while mixed-case names are frowned upon, descriptive names for |
|||
global variables are a must. To call a global function "foo" is a |
|||
shooting offense. |
|||
|
|||
GLOBAL variables (to be used only if you _really_ need them) need to |
|||
have descriptive names, as do global functions. If you have a function |
|||
that counts the number of active users, you should call that |
|||
"count_active_users()" or similar, you should _not_ call it "cntusr()". |
|||
|
|||
Encoding the type of a function into the name (so-called Hungarian |
|||
notation) is brain damaged - the compiler knows the types anyway and can |
|||
check those, and it only confuses the programmer. No wonder MicroSoft |
|||
makes buggy programs. |
|||
|
|||
LOCAL variable names should be short, and to the point. If you have |
|||
some random integer loop counter, it should probably be called "i". |
|||
Calling it "loop_counter" is non-productive, if there is no chance of it |
|||
being mis-understood. Similarly, "tmp" can be just about any type of |
|||
variable that is used to hold a temporary value. |
|||
|
|||
If you are afraid to mix up your local variable names, you have another |
|||
problem, which is called the function-growth-hormone-imbalance syndrome. |
|||
See next chapter. |
|||
|
|||
|
|||
Chapter 4: Functions |
|||
|
|||
Functions should be short and sweet, and do just one thing. They should |
|||
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, |
|||
as we all know), and do one thing and do that well. |
|||
|
|||
The maximum length of a function is inversely proportional to the |
|||
complexity and indentation level of that function. So, if you have a |
|||
conceptually simple function that is just one long (but simple) |
|||
case-statement, where you have to do lots of small things for a lot of |
|||
different cases, it's OK to have a longer function. |
|||
|
|||
However, if you have a complex function, and you suspect that a |
|||
less-than-gifted first-year high-school student might not even |
|||
understand what the function is all about, you should adhere to the |
|||
maximum limits all the more closely. Use helper functions with |
|||
descriptive names (you can ask the compiler to in-line them if you think |
|||
it's performance-critical, and it will probably do a better job of it |
|||
that you would have done). |
|||
|
|||
Another measure of the function is the number of local variables. They |
|||
shouldn't exceed 5-10, or you're doing something wrong. Re-think the |
|||
function, and split it into smaller pieces. A human brain can |
|||
generally easily keep track of about 7 different things, anything more |
|||
and it gets confused. You know you're brilliant, but maybe you'd like |
|||
to understand what you did 2 weeks from now. |
|||
|
|||
|
|||
Chapter 5: Commenting |
|||
|
|||
Comments are good, but there is also a danger of over-commenting. NEVER |
|||
try to explain HOW your code works in a comment: it's much better to |
|||
write the code so that the _working_ is obvious, and it's a waste of |
|||
time to explain badly written code. |
|||
|
|||
Generally, you want your comments to tell WHAT your code does, not HOW. |
|||
Also, try to avoid putting comments inside a function body: if the |
|||
function is so complex that you need to separately comment parts of it, |
|||
you should probably go back to chapter 4 for a while. You can make |
|||
small comments to note or warn about something particularly clever (or |
|||
ugly), but try to avoid excess. Instead, put the comments at the head |
|||
of the function, telling people what it does, and possibly WHY it does |
|||
it. |
|||
|
|||
|
|||
Chapter 6: You've made a mess of it |
|||
|
|||
That's OK, we all do. You've probably been told by your long-time Unix |
|||
user helper that "GNU emacs" automatically formats the C sources for |
|||
you, and you've noticed that yes, it does do that, but the defaults it |
|||
uses are less than desirable (in fact, they are worse than random |
|||
typing - a infinite number of monkeys typing into GNU emacs would never |
|||
make a good program). |
|||
|
|||
So, you can either get rid of GNU emacs, or change it to use saner |
|||
values. To do the latter, you can stick the following in your .emacs file: |
|||
|
|||
(defun linux-c-mode () |
|||
"C mode with adjusted defaults for use with the Linux kernel." |
|||
(interactive) |
|||
(c-mode) |
|||
(c-set-style "K&R") |
|||
(setq c-basic-offset 8)) |
|||
|
|||
This will define the M-x linux-c-mode command. When hacking on a |
|||
module, if you put the string -*- linux-c -*- somewhere on the first |
|||
two lines, this mode will be automatically invoked. Also, you may want |
|||
to add |
|||
|
|||
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode) |
|||
auto-mode-alist)) |
|||
|
|||
to your .emacs file if you want to have linux-c-mode switched on |
|||
automagically when you edit source files under /usr/src/linux. |
|||
|
|||
But even if you fail in getting emacs to do sane formatting, not |
|||
everything is lost: use "indent". |
|||
|
|||
Now, again, GNU indent has the same brain dead settings that GNU emacs |
|||
has, which is why you need to give it a few command line options. |
|||
However, that's not too bad, because even the makers of GNU indent |
|||
recognize the authority of K&R (the GNU people aren't evil, they are |
|||
just severely misguided in this matter), so you just give indent the |
|||
options "-kr -i8" (stands for "K&R, 8 character indents"). |
|||
|
|||
"indent" has a lot of options, and especially when it comes to comment |
|||
re-formatting you may want to take a look at the manual page. But |
|||
remember: "indent" is not a fix for bad programming. |
|||
|
|||
|
|||
Chapter 7: Configuration-files |
|||
|
|||
For configuration options (arch/xxx/config.in, and all the Config.in files), |
|||
somewhat different indentation is used. |
|||
|
|||
An indention level of 3 is used in the code, while the text in the config- |
|||
options should have an indention-level of 2 to indicate dependencies. The |
|||
latter only applies to bool/tristate options. For other options, just use |
|||
common sense. An example: |
|||
|
|||
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then |
|||
tristate 'Apply nitroglycerine inside the keyboard (DANGEROUS)' CONFIG_BOOM |
|||
if [ "$CONFIG_BOOM" != "n" ]; then |
|||
bool ' Output nice messages when you explode' CONFIG_CHEER |
|||
fi |
|||
fi |
|||
|
|||
Generally, CONFIG_EXPERIMENTAL should surround all options not considered |
|||
stable. All options that are known to trash data (experimental write- |
|||
support for file-systems, for instance) should be denoted (DANGEROUS), other |
|||
Experimental options should be denoted (EXPERIMENTAL). |
|||
|
|||
|
|||
Chapter 8: Data structures |
|||
|
|||
Data structures that have visibility outside the single-threaded |
|||
environment they are created and destroyed in should always have |
|||
reference counts. In the kernel, garbage collection doesn't exist (and |
|||
outside the kernel garbage collection is slow and inefficient), which |
|||
means that you absolutely _have_ to reference count all your uses. |
|||
|
|||
Reference counting means that you can avoid locking, and allows multiple |
|||
users to have access to the data structure in parallel - and not having |
|||
to worry about the structure suddenly going away from under them just |
|||
because they slept or did something else for a while. |
|||
|
|||
Note that locking is _not_ a replacement for reference counting. |
|||
Locking is used to keep data structures coherent, while reference |
|||
counting is a memory management technique. Usually both are needed, and |
|||
they are not to be confused with each other. |
|||
|
|||
Many data structures can indeed have two levels of reference counting, |
|||
when there are users of different "classes". The subclass count counts |
|||
the number of subclass users, and decrements the global count just once |
|||
when the subclass count goes to zero. |
|||
|
|||
Examples of this kind of "multi-reference-counting" can be found in |
|||
memory management ("struct mm_struct": mm_users and mm_count), and in |
|||
filesystem code ("struct super_block": s_count and s_active). |
|||
|
|||
Remember: if another thread can find your data structure, and you don't |
|||
have a reference count on it, you almost certainly have a bug. |
@ -1,43 +0,0 @@ |
|||
There are serval macros available to configure the behaviour of the GFX-Library. |
|||
|
|||
HAL macros: |
|||
|
|||
#define HAL_USE_GFX // enables the GDISP sub system. This is essentially needed to use the display |
|||
#define GFX_USE_TOUCHPAD // enables the TouchPad sub system. This is essentially needed to use the touchpad |
|||
|
|||
|
|||
|
|||
GDISP macors: |
|||
|
|||
#define GDISP_USE_GPIO // GDISP is connected to the MCU using GPIO interface, involves using lld_lcdWriteGPIO() and lld_lcdReadGPIO() |
|||
#define GDISP_USE_FSMC // GDISP is connected to the MCU using FSMC interface |
|||
#define GDISP_USE_SPI // GDISP is connected to the MCU using SPI interface |
|||
|
|||
#define GDISP_SCREEN_WIDTH // defines width of panel in pixels. This is essentially needed to use the display |
|||
#define GDISP_SCREEN_HEIGHT // defines height of panel in pixels. This is essentailly needed to use the display |
|||
|
|||
#define GDISP_NEED_MULTITHREAD // GDISP will be accessed across different threads -> thread safe mode |
|||
#define GDISP_NEED_CONTROL // must be set to TRUE if controll access to the LCD controller is needed, eg for changing orientation or power mode |
|||
#define GDISP_NEED_CLIP // when clipping is needed |
|||
#define GDISP_NEED_CIRCLE // for circle drawing support (filled and frame) |
|||
#define GDISP_NEED_ELLIPSE // for ellipse drawing support (filled and frame) |
|||
#define GDISP_NEED_ARC // for arc drawing support (filled and frame) |
|||
#define GDISP_NEED_TEXT // for font rendering support |
|||
#define GDISP_NEED_PIXELREAD // to read a pixels color value back |
|||
#define GDISP_NEED_SCROLL // is scrolling is needed (pixel shift) |
|||
#define GDISP_NEED_QUERY // to make certain queries to the LCD controller |
|||
|
|||
#define GFX_USE_CONSOLE // for the console abstraction |
|||
|
|||
|
|||
TouchPad macros: |
|||
|
|||
#define TOUCHPAD_NEED_MULTITHREAD // TouchPad will be accessed across different threads -> thread safe mode |
|||
|
|||
#define TOUCHPAD_XY_INVERTED // output of tpReadX() and tpReadY() swapped - needed if touchpad writes swapped to touchpad controller |
|||
|
|||
#define TOUCHPAD_STORE_CALIBRATION // calibration values can be stored if set to true. Therefore tpCalibration() is not neccessary to call on each reset. involves using lld_tpWriteCalibration() and lld_tpReadCalibration() |
|||
|
|||
|
|||
|
|||
|
@ -1,20 +0,0 @@ |
|||
The console module acts as a BaseSequentialStream at a user defined area of the LCD. |
|||
|
|||
Requirements: |
|||
The console code requires a lld that has vertical scroll implemented. |
|||
It is also necessary to enable the scroll code: |
|||
|
|||
#define GDISP_NEED_SCROLL TRUE |
|||
|
|||
Usage: |
|||
|
|||
#include "console.h" |
|||
|
|||
/* Define a console object */ |
|||
GLCDConsole CON1; |
|||
|
|||
/* initialise the console to take up the entire screen */ |
|||
lcdConsoleInit(&CON1, 0, 0, 320, 240, &fontLarger, Black, White); |
|||
|
|||
/* print something */ |
|||
chprintf((BaseSequentialStream *)&CON1, "Hello the time is %d\nGoodbye.", chTimeNow()); |
@ -1,27 +0,0 @@ |
|||
This file is a complete history of persons who contributed to the GLCD Library. |
|||
|
|||
At this point we want to thank all of these people for their work. |
|||
|
|||
|
|||
NickName RealName Contribution |
|||
======== ======== ============ |
|||
|
|||
Mobyfab Fabien Poussin SSD1963 driver, TOUCHPAD_XY_INVERTED macro |
|||
|
|||
inmarket Andrew Hannam GDISP (restructorizing the entire library) |
|||
VMT |
|||
ASYNC and MULTITHREAD implementation |
|||
|
|||
Badger Thomas Saunders console implementation |
|||
FSMC for STM32F1 and F4 |
|||
lld orientation fixed for S6F1121 and SSD1289 |
|||
|
|||
Abhishek Abhishek Kumar S6D1121 GPIO |
|||
font rendering |
|||
touchpad noise filtering & optimizations |
|||
|
|||
benwilliam - lcdDrawEllipse() |
|||
fastMath |
|||
|
|||
dxli Dongxu Li lcdDrawEllipse() filled option |
|||
|
@ -1,119 +0,0 @@ |
|||
This is a tree of the toplevel directory of the GLCD library. |
|||
The maintainer is supposed to keep it up to date at any new release. |
|||
|
|||
. |
|||
├── demos |
|||
│ ├── console |
|||
│ │ └── main.c |
|||
│ ├── lcd |
|||
│ │ └── main.c |
|||
│ ├── notepad |
|||
│ │ └── main.c |
|||
│ ├── readme.txt |
|||
│ └── touchpad |
|||
│ └── main.c |
|||
├── docs |
|||
│ ├── codingstyle.txt |
|||
│ ├── configure.txt |
|||
│ ├── console.txt |
|||
│ ├── contributors.txt |
|||
│ ├── files.txt |
|||
│ ├── readme.txt |
|||
│ ├── releases.txt |
|||
│ └── usage.txt |
|||
├── Doxygenfile |
|||
├── drivers |
|||
│ ├── gdisp |
|||
│ │ ├── Nokia6610 |
|||
│ │ │ ├── gdisp_lld_board_example.h |
|||
│ │ │ ├── gdisp_lld_board_olimexsam7ex256.h |
|||
│ │ │ ├── gdisp_lld.c |
|||
│ │ │ ├── gdisp_lld_config.h |
|||
│ │ │ ├── gdisp_lld.mk |
|||
│ │ │ ├── GE12.h |
|||
│ │ │ ├── GE8.h |
|||
│ │ │ └── readme.txt |
|||
│ │ ├── S6D1121 |
|||
│ │ │ ├── gdisp_lld.c |
|||
│ │ │ ├── gdisp_lld_config.h |
|||
│ │ │ ├── gdisp_lld.mk |
|||
│ │ │ ├── readme.txt |
|||
│ │ │ └── s6d1121_lld.c.h |
|||
│ │ ├── SSD1289 |
|||
│ │ │ ├── gdisp_lld.c |
|||
│ │ │ ├── gdisp_lld_config.h |
|||
│ │ │ ├── gdisp_lld.mk |
|||
│ │ │ ├── readme.txt |
|||
│ │ │ └── ssd1289_lld.c.h |
|||
│ │ ├── SSD1963 |
|||
│ │ │ ├── gdisp_lld.c |
|||
│ │ │ ├── gdisp_lld_config.h |
|||
│ │ │ ├── gdisp_lld.mk |
|||
│ │ │ ├── gdisp_lld_panel.h |
|||
│ │ │ ├── readme.txt |
|||
│ │ │ └── ssd1963.h |
|||
│ │ ├── TestStub |
|||
│ │ │ ├── gdisp_lld.c |
|||
│ │ │ ├── gdisp_lld_config.h |
|||
│ │ │ ├── gdisp_lld.mk |
|||
│ │ │ └── readme.txt |
|||
│ │ └── VMT |
|||
│ │ ├── gdisp_lld.c |
|||
│ │ ├── gdisp_lld_config.h |
|||
│ │ ├── gdisp_lld_driver1.c |
|||
│ │ ├── gdisp_lld_driver2.c |
|||
│ │ ├── gdisp_lld.mk |
|||
│ │ └── readme.txt |
|||
│ └── touchpad |
|||
│ ├── ADS7843 |
|||
│ │ ├── readme.txt |
|||
│ │ ├── touchpad_lld.c |
|||
│ │ ├── touchpad_lld_config.h |
|||
│ │ └── touchpad_lld.mk |
|||
│ └── XPT2046 |
|||
│ ├── readme.txt |
|||
│ ├── touchpad_lld.c |
|||
│ ├── touchpad_lld_config.h |
|||
│ └── touchpad_lld.mk |
|||
├── gfx.mk |
|||
├── include |
|||
│ ├── console.h |
|||
│ ├── gdisp_emulation.c |
|||
│ ├── gdisp_fonts.h |
|||
│ ├── gdisp.h |
|||
│ ├── gdisp_lld.h |
|||
│ ├── gdisp_lld_msgs.h |
|||
│ ├── touchpad.h |
|||
│ └── touchpad_lld.h |
|||
├── license.txt |
|||
├── old |
|||
│ ├── graph |
|||
│ │ ├── graph.c |
|||
│ │ ├── graph.h |
|||
│ │ └── graph.mk |
|||
│ └── gui |
|||
│ ├── gui.c |
|||
│ ├── gui.h |
|||
│ └── gui.mk |
|||
├── readme.txt |
|||
├── src |
|||
│ ├── console.c |
|||
│ ├── gdisp.c |
|||
│ ├── gdisp_fonts.c |
|||
│ ├── gdisp-readme.txt |
|||
│ └── touchpad.c |
|||
├── templates |
|||
│ ├── gdispXXXXX |
|||
│ │ ├── gdisp_lld.c |
|||
│ │ ├── gdisp_lld_config.h |
|||
│ │ ├── gdisp_lld.mk |
|||
│ │ └── readme.txt |
|||
│ ├── readme.txt |
|||
│ └── touchpadXXXXX |
|||
│ ├── touchpad_lld.c |
|||
│ ├── touchpad_lld_config.h |
|||
│ └── touchpad_lld.mk |
|||
└── tools |
|||
└── readme.txt |
|||
|
|||
26 directories, 87 files |
@ -1,2 +0,0 @@ |
|||
This folder contains documentation about this GLCD library. |
|||
|
@ -1,31 +0,0 @@ |
|||
***************************************************************************** |
|||
*** Releases *** |
|||
***************************************************************************** |
|||
|
|||
current stable: 1.2 |
|||
|
|||
*** changes after 1.2 *** |
|||
|
|||
|
|||
*** changer after 1.1 *** |
|||
FIX: orientation macros changed |
|||
FIX: huge internal bugfix in orientation stuff (big thanks to Abhishek) |
|||
FEATURE: added TOUCHPAD_XY_INVERTED macro |
|||
FIX: struct cal renamed to struct cal_t |
|||
FIX: SCREEN_WIDTH and SCREEN_HEIGHT renamed to GDISP_SCREEN_WIDTH and GDISP_SCREEN_HEIGHT |
|||
FIX: struct TOUCHPAD_t renamed to struct TOUCHPADDriver_t |
|||
FIX: struct GConsole renamed to struct GConsole_t |
|||
FIX: lcdConsoleXXX() functions have been renamed to gfxConsoleXXX() |
|||
FEATURE: FSMC for SSD1289 F2/F4 |
|||
|
|||
*** changes after 1.0 *** |
|||
FIX: removed gdisp and touchpad prefix of driver directories |
|||
UPDATE: added SSD1963 driver |
|||
FIX: fixed Validation, VMT driver, console and BitBlit |
|||
FEATURE: added clipping support |
|||
FEATURE: addad gdispDrawArc() |
|||
FEATURE: added SSD1963 DMA support |
|||
FEATURE: added touchpad interface for storing calibration values (#define TOUCHPAD_STORE_CALIBRATION) |
|||
CHANGE: replaced every GDISP_XXX macro with GDISP_XXX |
|||
CHANGE: removed last digit of version number |
|||
|
@ -1,27 +0,0 @@ |
|||
To include any of these functions/drivers in your project... |
|||
|
|||
1/ Specify the path to the GFXLIB. If none defined, default is $(CHIBIOS)/ext/lcd |
|||
|
|||
2/ In your project Makefile (amongst similiar lines but after the hal line) add the line... |
|||
include $(GFXLIB)/gfx.mk |
|||
|
|||
3/ Add $(GFXSRC) and $(GFXINC) to your SRCS and INCDIR of your projects Makefile |
|||
|
|||
4/ In your project Makefile add the makefiles for any specific drivers you want e.g |
|||
include $(GFXLIB)/drivers/touchpad/XPT2046/touchpad_lld.mk |
|||
include $(GFXLIB)/drivers/gdisp/SSD1289/gdisp_lld.mk |
|||
|
|||
5/ In your project halconf.h turn on the support you want. Please take a look to |
|||
docs/configure.txt for a list and description of all available macros. For example: |
|||
|
|||
#define GFX_USE_GDISP TRUE |
|||
#define GFX_USE_TOUCHPAD TRUE |
|||
|
|||
#define GDISP_USE_GPIO TRUE |
|||
#define GDISP_GDISP_SCREEN_WIDTH 240 |
|||
#define GDISP_GDISP_SCREEN_HEIGHT 320 |
|||
#define GDISP_NEED_CONTROL TRUE |
|||
#define TOUCHPAD_NEED_MULTITHREAD TRUE |
|||
|
|||
6/ Do a make clean |
|||
|
@ -1,19 +1,2 @@ |
|||
## Doxygen |
|||
run doxygen in the toplevel directory to generate the doxygen documentation in html |
|||
|
|||
|
|||
|
|||
## Wiki |
|||
please read the wiki pages to this project carefully, before you ask any questions: |
|||
|
|||
http://chibios.org/dokuwiki/doku.php?id=chibios:community |
|||
|
|||
|
|||
|
|||
## Maintainer & Contributors |
|||
please read the contributors.txt file which contains a full history of each contribution |
|||
|
|||
Maintainer: |
|||
- Joel Bodenmann aka Tectu <joel@unormal.org> |
|||
|
|||
please visit http://chibios-gfx.com |
|||
|
|||
|
Loading…
Reference in new issue