Example getkey
When you submit a text for review, the tag needs to be changed from InProgress to Review. Your initials need to be in the list of tags. KY's initials did not belong in the list of tags.
This does not need to be in a larger font than the rest. This should be an introductory paragraph, not a disclaimer. You should introduce the reader to the example first, then use this sentence as a transitional sentence into the explanatory text below. This procedure provides an overview of how to compile and run the getkey C example project. It assumes familiarity with the C programming language and is intended to be used by experienced programmers who are looking to learn the EMAC SDK.
Contents
1. Open the C/C++ editing perspective
This is not how you use headings. Headings are for denoting sections of a document, not for indicating steps of a process.
2. Open the egpc project
If you give directions for opening a project, building it, and running it from within an IDE, then you need to have screenshots. You also don't mention anything about building the example from the commandline. This section needs to be completely rewritten. Also keep in mind that we will have a different IDE and a different commandline build system in OE 5.0.
3. Build, upload and run
What it does
"What it does" is not a proper heading. 1. it is not capitalized as a heading 2. A sentence fragment does not present a good title.
This is an example program for mapping keypad input to a character matrix using the keypad interface on the SOM-150ES. It requires a SOM-150ES board and the keypad that goes with it. You mislead the reader into believing that the SOM-150ES includes a keypad, which is not the case. You need to be more clear about what's required, give a part number for the keypad in case the reader wishes to order one, explain to the reader that they will have to order one, and note that the carrier also needs a SoM. List the compatible SoMs.
Usage for getkey
The getkey line needs to be in courier
getkey [-d device -b -g -s file]
This needs to be in a table, with bold to indicate the command letter. Device nodes (/dev/keypad) don't belong in italics; they belong in courier. Similarly, filenames should be in courier. Each description of a command should be an actual sentence, and should be structured as such. In cases like 'd', there should be more than one sentence, or the description should be reworded into a form that fits into one sentence.
d: specify the device node, default is /dev/keypad
b: read blocking, sleep until a key is pressed.
g: returns the current keypad matrix.
s: sets the keypad matrix to the matrix specified in file (see project for example file Key-E020-21).
If a matrix operation is not specified then the last key pressed is returned.
Blank lines should be inserted before notes. The word note, as I mentioned before, should be in bold.
Note: Arguments are evaluated in order. If blocking or device specifications are used, they must be declared before the matrix arguments on the command line.
Usage example #1 needs to be specified as a heading, not just put in bold. It also needs to be capitalized as a proper heading, and needs to be given a name rather than a sequential number. The same applies to the rest of the usage examples. Additionally, example output should be given.
Usage example #1 All code must be in a code block so that it shows in courier ./getkey -d /dev/keypad0 -g
The program will display the matrix presently associated with the keypad at /dev/keypad0.
Usage example #2
./getkey -d /dev/keypad0 -s Key-E020-21
The program will map the keypad at /dev/keypad0 to the matrix file Key-E020-21.
Usage example #3
./getkey -d /dev/keypad0 -b
The program will wait until a key is pressed on the keypad. When a key is pressed it will display the corresponding character mapped to that pressed key, as specified in the matrix file.
