diff --git a/examples/chapter02_03/readme.md b/examples/chapter02_03/readme.md index 9f70776ec..781dec7b5 100644 --- a/examples/chapter02_03/readme.md +++ b/examples/chapter02_03/readme.md @@ -1,4 +1,5 @@ # Example chapter02_03 + ## The LED program with timing This example implements the LED program (with timing) for the @@ -12,7 +13,7 @@ Building the example can be done with GNUmake in the command batch or shell script. The results of the build will be stored in the `bin` directory. After successful build, files such as the HEX-file -`led.hex` and othe name and map files can be found in `bin`. +`led.hex` and the name and map files can be found in `bin`. ## With `GNUmake` @@ -38,9 +39,9 @@ VC as well as Atmel Studio. In the LED program with timing, the blinking is controlled directly from the `main` subroutine of the program. The blinking -frequency is approximately 1/2Hz, controlled by a timer dely. +frequency is approximately 1/2Hz, controlled by a timer delay. The blinking loop can be found in the file `sys_start.cpp`. -It is reproduced below within its contect in `main`. +It is reproduced below within its context in `main`. Please note the MCAL initialization, which is essential for initializing clocks and interrupts. It is this layer that needs to be modified when porting to other microcontroller diff --git a/examples/chapter02_03a/readme.md b/examples/chapter02_03a/readme.md index 4c2b813d1..c51dcf0ca 100644 --- a/examples/chapter02_03a/readme.md +++ b/examples/chapter02_03a/readme.md @@ -1,4 +1,5 @@ # Example chapter02_03a + ## The LED program with cooperative multitasking scheduler This example implements the LED program with diff --git a/examples/chapter02_06/images/2020-01-12.png b/examples/chapter02_06/images/2020-01-12.png new file mode 100644 index 000000000..3c0ad1efa Binary files /dev/null and b/examples/chapter02_06/images/2020-01-12.png differ diff --git a/examples/chapter02_06/images/measurement.png b/examples/chapter02_06/images/measurement.png new file mode 100644 index 000000000..106057fdc Binary files /dev/null and b/examples/chapter02_06/images/measurement.png differ diff --git a/examples/chapter02_06/images/measurement2-cropped.png b/examples/chapter02_06/images/measurement2-cropped.png new file mode 100644 index 000000000..b44e56021 Binary files /dev/null and b/examples/chapter02_06/images/measurement2-cropped.png differ diff --git a/examples/chapter02_06/images/measurement2.png b/examples/chapter02_06/images/measurement2.png new file mode 100644 index 000000000..c09018924 Binary files /dev/null and b/examples/chapter02_06/images/measurement2.png differ diff --git a/examples/chapter02_06/readme.md b/examples/chapter02_06/readme.md index d24f15be4..dfa149927 100644 --- a/examples/chapter02_06/readme.md +++ b/examples/chapter02_06/readme.md @@ -1,4 +1,5 @@ # Example chapter02_06 + ## The Led Program (with template LED class) This example implements the LED program with a template @@ -24,15 +25,15 @@ to capture the runtime of the port toggle. The toggle signal has a width of approximately $310~\text{ns}$, which agrees well with the claim in the book. -![](./images/2020-01-12.pdf) +![port signal measured on oscilloscope](./images/2020-01-12.png) The toggle signal having a width of approximately $310~\text{ns}$ captured by a digital oscilloscope is shown. Manually measuring the toggle signal with a _scope_ might require laboratory skill, -as shown in the next two pictures featuring a hand-help oscilloscope +as shown in the next two pictures featuring a hand-held oscilloscope probe measurement on one of our self-made Arduino-like boards. -![](./images/measurement.pdf) +![hand-held measurement with oscilloscope](./images/measurement.png) -![](./images/measurement2.pdf) +![closer view of oscilloscope measurement](./images/measurement2-cropped.png) diff --git a/examples/chapter03_02/readme.md b/examples/chapter03_02/readme.md index e001ae65c..ac05ff2ac 100644 --- a/examples/chapter03_02/readme.md +++ b/examples/chapter03_02/readme.md @@ -1,14 +1,15 @@ # Example Chapter03_02 + ## Integer Types Having Fixed Widths and Prime Numbers

- - + + godbolt

Example chapter03_02 focuses on integer types having fixed widths. The example gets into a fascinating calculation of prime numbers -that is simultaneously intended to emphasize the usefullness +that is simultaneously intended to emphasize the usefulness and portability of fixed-width integer types. ## Fixed-Width Integer Types @@ -50,7 +51,7 @@ with the input `Prime[100]`. The example begins by querying the number of entries required in the sieve to calculate the prime 541. For this, a simple divergent -asymptotic series approximation of the lograithmic integral function is used. +asymptotic series approximation of the logarithmic integral function is used. Instead of 100, the approximation returns 108, which is adequately close to the desired limit and large enough. @@ -70,17 +71,17 @@ The approximate runtime of each task call required for the entire sieve calculation of $100$ prime numbers is approximately $5\text{ms}$. A debug port, in this case `portd.3` is toggled high and low -just prior to and after the call of the prime sieve cacle task. -A straightofrward digital oscilloscope measurement provides +just prior to and after the call of the prime sieve cycle task. +A straightforward digital oscilloscope measurement provides a timing indication for the runtime of the prime sieve cycle task. A running hardware setup is shown in the picture below. -![](./images/board03_02.jpg) +![running hardware setup](./images/board03_02.jpg) The runtime of the prime sieve cycle task is depicted below. -![](./images/scope03_02.jpg) +![runtime curve on oscilloscope](./images/scope03_02.jpg) ## A PC-Based example @@ -124,7 +125,7 @@ at this numerical point? Consider the following input. -``` +```text N[(LogIntegral[10006721] - LogIntegral[2])/664999, 20] ``` diff --git a/examples/chapter04_04/readme.md b/examples/chapter04_04/readme.md index 0d1826a83..63f9853d5 100644 --- a/examples/chapter04_04/readme.md +++ b/examples/chapter04_04/readme.md @@ -1,4 +1,5 @@ # Example Chapter04_04 + ## LED Objects and Polymorphism Example chapter04_04 uses an intuitive LED class hierarchy @@ -109,7 +110,7 @@ as shown in the following table. | LED4 | port expander pin `GPA2` | port toggle high/low, SPI software drive, $750~\Omega$ | In this example, we use ports from both the microcontroller as well -as an external port expander chip. Hardware adressing is used +as an external port expander chip. Hardware addressing is used on the port expander chip. The port expander address is hard-wired to the value 7 via connecting each of the three pins `A0` ... `A2` to $+{5}~\text{V}$. @@ -134,4 +135,4 @@ The connections of the port expander chip are tabulated below. The hardware setup is pictured in the image below. -![](./images/board4.jpg) +![hardware setup](./images/board4.jpg) diff --git a/examples/chapter04_04a/readme.md b/examples/chapter04_04a/readme.md index a0479095b..e4e69cc02 100644 --- a/examples/chapter04_04a/readme.md +++ b/examples/chapter04_04a/readme.md @@ -1,4 +1,5 @@ # Example Chapter04_04a + ## LED Objects and Polymorphism via References Example chapter04_04a implements the same basic functionality diff --git a/examples/chapter06_01/readme.md b/examples/chapter06_01/readme.md index 5123df3c4..c159bd33d 100644 --- a/examples/chapter06_01/readme.md +++ b/examples/chapter06_01/readme.md @@ -1,9 +1,10 @@ # Example Chapter06_01 + ## A CRC Benchmark

- - + + godbolt

Example chapter06_01 illustrates certain optimization @@ -73,8 +74,7 @@ std::uint32_t crc32_mpeg2(input_iterator first, ## Application Description One of the standard tests of a CRC is to compute the checksum -of the digits -. +of the digits $1 \ldots 9$. Please note here that the digits are not decimal values. They are the ASCII representations instead. In other words, the standard CRC test computes the checksum of a byte array such as @@ -101,7 +101,7 @@ of the the expected result. The benchmark port pin `portd.3` is toggled high prior to the CRC calculation and low following the calculation. This provides a time pulse that can easily be measured -on the oscilloscpoe. For the 8-bit target, expect +on the oscilloscope. For the 8-bit target, expect a CRC runtime of approximately $300~{\mu}\text{s}$. The benchmark port definition can be located in the file diff --git a/examples/chapter06_14/readme.md b/examples/chapter06_14/readme.md index 5ff92e5c1..339331bfc 100644 --- a/examples/chapter06_14/readme.md +++ b/examples/chapter06_14/readme.md @@ -1,4 +1,5 @@ # Example Chapter06_14 + ## A CRC Benchmark with ROM-based Table and Data Example chapter06_14 has essentially the same functionality @@ -39,7 +40,7 @@ The partial image of a memory map file from example chapter06_14 for the 8-bit target shows us that the data objects mentioned above have, in fact, been _ROM_'ed. -![](./images/romdata.jpg) +![snippet from map file](./images/romdata.jpg) The objects in the map-snippet above are in ROM. @@ -47,5 +48,5 @@ The objects in the map-snippet above are in ROM. The same standard CRC checksum and verification is carried out in the `app::benchmark::task_func` -function. Slight sylistic differences between the algorithms in +function. Slight stylistic differences between the algorithms in example06_01 and example06_14 reflect no functional change.