version 1.3 release
This commit is contained in:
Joel Bodenmann
parent
9bcabe082a
commit
e04654e6d9
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
|
|
||||||
|
|
||||||
119
docs/files.txt
119
docs/files.txt
|
|
@ -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
|
|
||||||
|
|
||||||
19
readme.txt
19
readme.txt
|
|
@ -1,19 +1,2 @@
|
||||||
## Doxygen
|
please visit http://chibios-gfx.com
|
||||||
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>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue