diff --git a/.wordlist.txt b/.wordlist.txt index 881d973ccf..009599e7d6 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -7405,4 +7405,61 @@ requantized requantizing signedness virsh -virt \ No newline at end of file +virt +Autoboot +BOOTMODE +DTB +Decompile +EVM +FITs +HSM +Jamil +Keywriter +LBA +MBR +MCUboot +MoltenVK +SPL +ScaledObjects +Scaler's +Securable +TI's +TIFS +Terraform's +UBOOT +adab +adbc +afaf +arago +autoboot +bafb +bceffbb +bcfc +beeb +befc +bootloader's +caidas +cded +ceefb +cffee +decompiling +eFuses +eadeefc +edcf +efbc +evm +fbcacd +fcea +fcfa +fdaaaca +fdbc +lastmod +lxx +shaderFloat +subimages +swin +tiboot +tisdk +tispl +uboot +codename diff --git a/content/learning-paths/automotive/_index.md b/content/learning-paths/automotive/_index.md index 0ec2943ade..ede5cbdffa 100644 --- a/content/learning-paths/automotive/_index.md +++ b/content/learning-paths/automotive/_index.md @@ -19,7 +19,7 @@ subjects_filter: - Performance and Architecture: 10 operatingsystems_filter: - Baremetal: 1 -- Linux: 14 +- Linux: 15 - macOS: 1 - other: 1 - RTOS: 2 @@ -33,7 +33,7 @@ tools_software_languages_filter: - CMake: 1 - CPP: 1 - DDS: 1 -- Docker: 6 +- Docker: 7 - FreeRTOS: 1 - FVP: 2 - Gazebo: 1 @@ -43,17 +43,17 @@ tools_software_languages_filter: - Multipass: 1 - Navigation2: 1 - Perf: 1 -- Python: 2 +- Python: 3 - Raspberry Pi: 2 - rmw_zenoh: 2 -- ROS 2: 6 +- ROS 2: 7 - Rust: 1 - RViz: 1 - SME2: 1 - Tinkerblox: 1 - topdown-tool: 1 - Yocto: 3 -- Zenoh: 3 +- Zenoh: 4 # auto-generated padding to avoid Hugo YAML alias limit # auto-generated padding to avoid Hugo YAML alias limit # auto-generated padding to avoid Hugo YAML alias limit diff --git a/content/learning-paths/automotive/freertos-zena-css/Console_tmux.png b/content/learning-paths/automotive/freertos-zena-css/console_tmux.png similarity index 100% rename from content/learning-paths/automotive/freertos-zena-css/Console_tmux.png rename to content/learning-paths/automotive/freertos-zena-css/console_tmux.png diff --git a/content/learning-paths/cross-platform/cca_rme/_images/l1gpt_0xA.png b/content/learning-paths/cross-platform/cca_rme/_images/l1gpt_0xa.png similarity index 100% rename from content/learning-paths/cross-platform/cca_rme/_images/l1gpt_0xA.png rename to content/learning-paths/cross-platform/cca_rme/_images/l1gpt_0xa.png diff --git a/content/learning-paths/cross-platform/cca_rme/bare-metal.md b/content/learning-paths/cross-platform/cca_rme/bare-metal.md index 96855f4d6c..68d15c1195 100644 --- a/content/learning-paths/cross-platform/cca_rme/bare-metal.md +++ b/content/learning-paths/cross-platform/cca_rme/bare-metal.md @@ -66,7 +66,7 @@ The L1 table defines permissions for each 16KB granule. Use the Arm Debugger MMU/MPU pane to observe these attributes: -![Screenshot of Arm Debugger MMU/MPU pane showing L1 Granule Protection Table entries for memory region 0xA0000000, displaying Realm access permissions for 16KB granules#center](_images/l1gpt_0xA.png) +![Screenshot of Arm Debugger MMU/MPU pane showing L1 Granule Protection Table entries for memory region 0xA0000000, displaying Realm access permissions for 16KB granules#center](_images/l1gpt_0xa.png) ![Screenshot of Arm Debugger MMU/MPU pane showing L1 Granule Protection Table entries for memory region 0x80000000, displaying the protection attributes for this address range#center](_images/l1gpt_0x8.png) diff --git a/content/learning-paths/embedded-and-microcontrollers/_index.md b/content/learning-paths/embedded-and-microcontrollers/_index.md index 323b576e3e..9d3f43f7cf 100644 --- a/content/learning-paths/embedded-and-microcontrollers/_index.md +++ b/content/learning-paths/embedded-and-microcontrollers/_index.md @@ -15,19 +15,19 @@ pinned_learning_paths: operatingsystems_filter: - Android: 1 - Baremetal: 31 -- Linux: 60 +- Linux: 62 - macOS: 24 -- RTOS: 13 +- RTOS: 14 - Windows: 12 subjects_filter: - CI-CD: 7 - Containers and Virtualization: 10 - Embedded Linux: 6 -- Libraries: 5 +- Libraries: 6 - ML: 31 - Performance and Architecture: 24 - RTOS Fundamentals: 8 -- Security: 3 +- Security: 4 - Virtual Hardware: 2 subtitle: Learn best practices for IoT, embedded, and microcontroller development. title: Embedded and Microcontrollers @@ -53,7 +53,7 @@ tools_software_languages_filter: - Baremetal: 1 - Bash: 1 - BitBake: 1 -- C: 12 +- C: 13 - ChatGPT: 1 - Clang: 1 - CMake: 2 @@ -66,7 +66,7 @@ tools_software_languages_filter: - Containerd: 1 - CPP: 1 - DetectNet: 1 -- Docker: 19 +- Docker: 20 - DSTREAM: 2 - Edge AI: 2 - Edge Impulse: 2 @@ -77,7 +77,7 @@ tools_software_languages_filter: - Fusion 360: 1 - FVP: 11 - Gazebo: 1 -- GCC: 16 +- GCC: 17 - Generative AI: 3 - GitHub: 4 - GitLab: 2 @@ -113,19 +113,20 @@ tools_software_languages_filter: - ONNX: 1 - ONNX Runtime: 1 - OpenSSH: 1 +- OpenSSL: 1 - Paddle: 1 - Performance analysis: 1 - picocom: 1 - Porcupine: 1 -- Python: 24 +- Python: 25 - PyTorch: 9 -- QEMU: 2 +- QEMU: 3 - Raspberry Pi: 11 - Reachy Mini: 1 - Remote.It: 1 - remoteproc-runtime: 1 - rmw_zenoh: 2 -- ROS 2: 3 +- ROS 2: 4 - Runbook: 4 - RViz: 1 - SEGGER JLink: 1 @@ -144,14 +145,16 @@ tools_software_languages_filter: - Trusted Firmware: 2 - TrustZone: 2 - TVMC: 1 +- U-Boot: 1 - vcpkg: 1 - Vela: 2 - VGF: 1 -- Visual Studio Code: 2 +- Visual Studio Code: 3 +- Workbench for Zephyr: 1 - YAML: 1 - Yocto: 1 - Yocto Project: 1 -- Zenoh: 2 -- Zephyr: 6 +- Zenoh: 3 +- Zephyr: 7 weight: 5 --- diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md index 4bb4d2bdfb..390f9818fc 100644 --- a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md +++ b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md @@ -92,7 +92,7 @@ plt.show() The expected output is shown below -![output1](images/lab4_1.PNG) +![output1](images/lab4_1.png) Next, normalize all the training and testing data to have values between 0 and 1. This normalization facilitates machine learning. Each RGB value ranges from 0 to 255, so divide the training and testing data by 255. @@ -125,7 +125,7 @@ You are going to create a small convolutional neural network for image classific Here is an image illustrating the network architecture. Note that only convolution and dense layers are illustrated in this image. -![output2](images/lab4_2.PNG) +![output2](images/lab4_2.png) Execute the code blocks below to create a sequential model and add the layers diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/deploy_nn.md b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/deploy_nn.md index d1131ba245..ffa2fa35de 100644 --- a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/deploy_nn.md +++ b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/deploy_nn.md @@ -53,15 +53,15 @@ In this section, you will deploy the model directly on the STM32 board. 5. Set `Toolchain/IDE` as `STM32CubeIDE` -![output3](images/lab4_3.PNG) +![output3](images/lab4_3.png) 6. Go to `Pinout & Configuration` and clear pinouts from the `Pinout` menu. -![output4](images/lab4_4.PNG) +![output4](images/lab4_4.png) 7. In `Software Packs` menu, click `Select Components`. Enable `X-CUBE-AI`. For device application, choose `Validation`. Click `OK` to save. -![output5](images/lab4_5.PNG) +![output5](images/lab4_5.png) 8. Navigate to `X-CUBE-AI` configuration. @@ -71,7 +71,7 @@ In this section, you will deploy the model directly on the STM32 board. 11. Generate the validation code for the model by clicking `Generate Code`. -![output6](images/lab4_6.PNG) +![output6](images/lab4_6.png) 12. Open STM32CubeIDE. @@ -81,10 +81,10 @@ In this section, you will deploy the model directly on the STM32 board. 15. Ensure that the board is connected to your computer. If it is correctly connected, build and flash the code by clicking `Run As`. -![output7](images/lab4_7.PNG) +![output7](images/lab4_7.png) 16. If you get an ‘undefined reference’ error, go to `Core/Src/main.c`. Remove `static` from the declaration of the `MX_USART1_UART_Init()` function and also from its definition. Try `Run As` again. -![output8](images/lab4_8.PNG) +![output8](images/lab4_8.png) With the model now deployed on the STM32 board, you are ready to test it. diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_1.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_1.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_1.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_1.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_10.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_10.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_10.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_10.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_11.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_11.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_11.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_11.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_12.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_12.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_12.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_12.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_2.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_2.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_2.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_2.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_3.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_3.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_3.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_3.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_4.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_4.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_4.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_4.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_5.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_5.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_5.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_5.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_6.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_6.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_6.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_6.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_7.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_7.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_7.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_7.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_8.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_8.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_8.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_8.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_9.PNG b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_9.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_9.PNG rename to content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/images/lab4_9.png diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/run_nn.md b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/run_nn.md index cec4f2ef55..4a73da5d5f 100644 --- a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/run_nn.md +++ b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/run_nn.md @@ -38,20 +38,20 @@ If the board is not detected, click the black button on the board to reset, then Select the model network from the list of models deployed on the board. -![output9](images/lab4_9.PNG) +![output9](images/lab4_9.png) Select the network and the label file (`Data/labels/cifar10_labels.txt`) -![output10](images/lab4_10.PNG) +![output10](images/lab4_10.png) Open an image to test. The tool will automatically launch a new pane, and show the inference result. Observe that the model correctly predicted the label. In addition, note the time taken to finish the prediction. -![output11](images/lab4_11.PNG) +![output11](images/lab4_11.png) You can also use your workstation camera to test image classification. Hold an appropriate picture up to your camera, then press `S`. The tool captures the image and sends it to the board. -![output12](images/lab4_12.PNG) +![output12](images/lab4_12.png) You have now successfully ran the model on your STM32 board. diff --git a/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/2setup.md b/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/2setup.md index d9980ff787..7b45eff1ff 100644 --- a/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/2setup.md +++ b/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/2setup.md @@ -23,7 +23,7 @@ Click on the box titled "JETSON XAVIER NX DEVELOPER KIT & ORIN NANO DEVELOPER KI 1. Open balenaEtcher 2. Click "Flash from file" -![balenaEtcher interface](./balenaEtcher1.png) +![balenaEtcher interface](./balenaetcher1.png) 3. Select the zip file of the image you just downloaded (you don't need to unzip the file). 4. Click "Select target" and choose your microSD card 5. Click "Flash" and wait for the process to complete which will take around 10 minutes. You may be prompted to enter a username and password before it will start. diff --git a/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/balenaetcher1.png b/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/balenaetcher1.png new file mode 100644 index 0000000000..6318e740ea Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/jetson_object_detection/balenaetcher1.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/4_sl_profile_oot.md b/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/4_sl_profile_oot.md index 54afad166d..613321e8aa 100644 --- a/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/4_sl_profile_oot.md +++ b/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/4_sl_profile_oot.md @@ -86,7 +86,7 @@ Open the **Functions** tab. In the counters list, select one of the counters you In the **Functions** tab, look for the function `char_dev_cache_traverse()`. You'll see that it has the highest L1 Cache refill rate, which is expected for this example. Check the **Image** column on the right. This should show your module file name, `mychardrv.ko`. This confirms that Streamline is capturing performance data for your kernel module. -![Streamline Functions tab displaying a list of functions with performance metrics such as L1 Cache refill rates. The primary subject is the function char_dev_cache_traverse which is highlighted and shows the highest cache refill value. The right side of the table lists the image name as mychardrv.ko. The wider environment is a desktop profiling application window with columns labeled Function, Image, and various performance counters. Visible text includes function names, image names, and numerical metric values. The emotional tone is neutral and technical, supporting detailed analysis for Arm kernel module profiling. alt-text#center](./images/img08_Functions_Tab.png "Identify functions with highest cache refill rates") +![Streamline Functions tab displaying a list of functions with performance metrics such as L1 Cache refill rates. The primary subject is the function char_dev_cache_traverse which is highlighted and shows the highest cache refill value. The right side of the table lists the image name as mychardrv.ko. The wider environment is a desktop profiling application window with columns labeled Function, Image, and various performance counters. Visible text includes function names, image names, and numerical metric values. The emotional tone is neutral and technical, supporting detailed analysis for Arm kernel module profiling. alt-text#center](./images/img08_functions_tab.png "Identify functions with highest cache refill rates") To view the call path for `char_dev_cache_traverse()`, right-click the function name and select **Select in Call Paths**. diff --git a/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/images/img08_functions_tab.png b/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/images/img08_functions_tab.png new file mode 100644 index 0000000000..cd23986177 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/streamline-kernel-module/images/img08_functions_tab.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/features.md b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/features.md index a558fb2e34..4bbe133a6e 100644 --- a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/features.md +++ b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/features.md @@ -55,7 +55,7 @@ for idx, file in enumerate(data_files): You can check the extracted features with this code block. These are the extracted features from one data sample. Expected output shown below: -![output5](images/output5.PNG) +![output5](images/output5.png) ## Feature based model diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output1.PNG b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output1.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output1.PNG rename to content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output1.png diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output2.PNG b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output2.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output2.PNG rename to content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output2.png diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output3.PNG b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output3.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output3.PNG rename to content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output3.png diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output4.PNG b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output4.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output4.PNG rename to content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output4.png diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output5.PNG b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output5.png similarity index 100% rename from content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output5.PNG rename to content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/images/output5.png diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/test.md b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/test.md index 0aab5f115d..4472fff631 100644 --- a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/test.md +++ b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/test.md @@ -78,7 +78,7 @@ plt.legend(loc='lower right') ``` In this example, see that the training and validation accuracy start to converge after around 150 epochs. This means that the 200 epochs are enough to train the model. If you train the model for too many epochs, then the validation accuracy may drop due to overfitting. If you experience this, re-run [training](#train) with an appropriate epoch value. -![output2](images/output2.PNG) +![output2](images/output2.png) ## Investigate learning rate (optional) @@ -103,7 +103,7 @@ plt.legend(loc='lower right') ``` Expected output shown below: -![output3](images/output3.PNG) +![output3](images/output3.png) Now try a lower learning rate, which is 0.0001. Execute the code block. The graph shows the training and validation loss values decrease much more slowly. So, it is important to use a proper learning rate in training. @@ -125,7 +125,7 @@ plt.legend(loc='lower right') Expected output shown below: -![output4](images/output4.PNG) +![output4](images/output4.png) With the model trained, you are now ready to test it. diff --git a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/train_nn.md b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/train_nn.md index 5b4fb1b521..4017d26cb3 100644 --- a/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/train_nn.md +++ b/content/learning-paths/embedded-and-microcontrollers/tflow_nn_stcube/train_nn.md @@ -163,4 +163,4 @@ plot_single_sample(data_sample=data[idx], label=labels[idx]) Example output is shown below: -![output1](images/output1.PNG) +![output1](images/output1.png) diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/2_basics.md b/content/learning-paths/embedded-and-microcontrollers/uv_debug/2_basics.md index 09763f606d..3a4a9e5ae2 100644 --- a/content/learning-paths/embedded-and-microcontrollers/uv_debug/2_basics.md +++ b/content/learning-paths/embedded-and-microcontrollers/uv_debug/2_basics.md @@ -22,12 +22,12 @@ To use hardware breakpoints in µVision follow the steps outlined below: 1. ![Run](./b_uv4_run.png) **Run (F5)** the application. 1. Bring `Blinky.c` in focus by clicking on its tab. If it is not visible, double-click on it in the **Project** window. 3. In `Blinky.c`, scroll down to the `while (1)` loop in the `main` function near line 42 as shown here: -![Inside the while loop](./mainWhileLoop.png) +![Inside the while loop](./mainwhileloop.png) 4. Note the darker grey blocks on the left of the line numbers. They indicate assembly code being present and that you can set a hardware breakpoint on these lines. You can also see these blocks in the **Disassembly** window: -![while loop Disassembly](./mainWhileLoopDisassembly.png) +![while loop Disassembly](./mainwhileloopdisassembly.png) 5. While the program is still running, click to the left of a suitable line in the `while` loop (for example at line 47) and a red circle will be created. This is a hardware breakpoint. The simulated Arm Cortex-M55 has eight hardware breakpoints. μVision will warn you if you exceed this limit. 6. The program will soon stop at the line where you have set the breakpoint on as shown below. The yellow arrow is the current program counter position. This will be the next instruction executed. The cyan arrow is a placeholder you can use to explore the relationship between a source window and the **Disassembly** window. -![Program execution stopped](./mainWhileLoopStopped.png) +![Program execution stopped](./mainwhileloopstopped.png) 7. Add another breakpoint in `while (1)` (for example at line 50). 8. Each time you click on ![Run](./b_uv4_run.png) **Run (F5)**, the program will cycle to the next breakpoint. @@ -42,7 +42,7 @@ To use hardware breakpoints in µVision follow the steps outlined below: ### Manage Breakpoints 1. Go to **Debug - Breakpoints (Ctrl-B)** to manage breakpoints: -![Manage Breakpoints](./manageBKPT.png) +![Manage Breakpoints](./managebkpt.png) 2. You can temporarily unselect, delete or create breakpoints in this window. It is easier to create a breakpoint by clicking in a source file or the **Disassembly** window. 3. [Watchpoints](#watchpoints) are also created in this window. 4. Select **Kill All** to remove all breakpoints. @@ -64,7 +64,7 @@ When the program is stopped, the list of stacked functions is displayed. This is 1. Stop the program with the ![Stop](./b_uv4_stop.png) **Stop** icon. The program will probably stop in the `Delay` function. 2. Click on the **Call Stack + Locals** window in the bottom right corner of μVision. 3. Inspect the various entries in the Call Stack + Locals window as shown below in this simple example. Local variables are displayed only when they are in scope: - ![Call Stack + Locals Window](./callStackLocals.png) + ![Call Stack + Locals Window](./callstacklocals.png) 1. Set a breakpoint in the `while (1)` loop at line 50 on the `g_ledSet = 1;`. 5. ![Run](./b_uv4_run.png) **Run (F5)** the application. 6. Shortly after, the program will stop there. @@ -72,7 +72,7 @@ When the program is stopped, the list of stacked functions is displayed. This is 9. Note how the variables displayed change in the **Call Stack + Locals** window. 1. ![Step into](./b_uv4_stepinto.png) **Step (F11)** a few more times. 1. Right-click on a function and select either **Show Caller Code** or **Show Callee Code** and this will be highlighted in the **Disassembly** and **source code** windows: - ![Call Stack + Locals Window](./callStackLocals_caller_callee.png) + ![Call Stack + Locals Window](./callstacklocals_caller_callee.png) 1. ![Step out](./b_uv4_stepout.png) **Step Out (Ctrl+F11)** to exit a function immediately. 1. Remove the **Breakpoint** (by clicking on its red circle ![Breakpoint](./bkpt.png)) to continue. @@ -95,9 +95,9 @@ There is a global variable `g_msTicks` located in `Blinky.c` near line 11 that y 1. ![Run](./b_uv4_run.png) **Run (F5)** the application. 2. Right click on `g_msTicks` in `Blinky.c` near line 11 and select **Add 'g_msTicks' to…** and select **Watch 1**. 3. Go to **View** in the main menu and enable **Periodic Window Update**: -![Periodic Window Update](./periodicWindowUpdate.png) +![Periodic Window Update](./periodicwindowupdate.png) 4. `g_msTicks` will be displayed in **Watch 1**: -![g_msTicks in Watch 1 Window](./gmsTicksWatch.png) +![g_msTicks in Watch 1 Window](./gmstickswatch.png) 5. The values of `g_msTicks` are updated in real-time if *Periodic Window Update* is enabled. 6. You can modify the value in a **Watch** window when the program is stopped or changing slowly. You can modify a variable in a **Memory** window anytime (see next section). @@ -118,7 +118,7 @@ You do not need to stop the program execution to enter variables, raw addresses 3. Right click in **Memory 1** and select **Unsigned Long** to see the data field as 32-bit numbers. 4. Add an ampersand `&` in front of the variable name `g_msTicks` and press Enter. Now the physical address is shown (0x2000_0008) in this case. This physical address could change with different compilation optimizations. 5. The data contents of `g_msTicks` is displayed as shown: -![g_msTicks in Memory 1 Window](./gmsTicksMemory.png) +![g_msTicks in Memory 1 Window](./gmsticksmemory.png) 6. Right click on the memory data value and select **Modify Memory at 0x3000000C**. Enter a value and this will be pushed into `g_msTicks`. Since `g_msTicks` is updated often, you will only see the new value displayed for a very short time. 7. ![Stop](./b_uv4_stop.png) **Stop** the application. diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/callstacklocals.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/callstacklocals.png new file mode 100644 index 0000000000..afc60d58ec Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/callstacklocals.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/callstacklocals_caller_callee.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/callstacklocals_caller_callee.png new file mode 100644 index 0000000000..2d0fa0acc6 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/callstacklocals_caller_callee.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/gmsticksmemory.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/gmsticksmemory.png new file mode 100644 index 0000000000..c9a1e662d5 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/gmsticksmemory.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/gmstickswatch.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/gmstickswatch.png new file mode 100644 index 0000000000..6f97e3a9ea Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/gmstickswatch.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloop.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloop.png new file mode 100644 index 0000000000..48728386a2 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloop.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloopdisassembly.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloopdisassembly.png new file mode 100644 index 0000000000..872f26252a Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloopdisassembly.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloopstopped.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloopstopped.png new file mode 100644 index 0000000000..ce8dd7a005 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/mainwhileloopstopped.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/managebkpt.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/managebkpt.png new file mode 100644 index 0000000000..496dc1cef9 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/managebkpt.png differ diff --git a/content/learning-paths/embedded-and-microcontrollers/uv_debug/periodicwindowupdate.png b/content/learning-paths/embedded-and-microcontrollers/uv_debug/periodicwindowupdate.png new file mode 100644 index 0000000000..82fafd16f1 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/uv_debug/periodicwindowupdate.png differ diff --git a/content/learning-paths/mobile-graphics-and-gaming/_index.md b/content/learning-paths/mobile-graphics-and-gaming/_index.md index dd91335a71..22a4c93cc5 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/_index.md +++ b/content/learning-paths/mobile-graphics-and-gaming/_index.md @@ -13,13 +13,13 @@ pinned_learning_paths: - nfru-unreal - model-training-gym-nfru operatingsystems_filter: -- Android: 54 +- Android: 55 - Linux: 54 - macOS: 27 - Windows: 25 subjects_filter: - Gaming: 6 -- Graphics: 8 +- Graphics: 9 - ML: 46 - Performance and Architecture: 38 subtitle: Optimize Android apps and build faster games using cutting-edge Arm tech. @@ -40,12 +40,11 @@ tools_software_languages_filter: - Bash: 2 - Bazel: 2 - C: 7 -- C++: 2 - CameraX: 1 - CCA: 1 - Clang: 13 - CMake: 6 -- CPP: 20 +- CPP: 22 - csharp: 3 - Docker: 2 - ETDump: 1 @@ -102,7 +101,7 @@ tools_software_languages_filter: - VGF: 3 - Visual Studio: 4 - Visual Studio Code: 1 -- Vulkan: 12 +- Vulkan: 13 - Vulkan SDK: 3 - XNNPACK: 10 weight: 3 diff --git a/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/7-analyzing.md b/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/7-analyzing.md index c5b193bb42..66c4a0ee35 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/7-analyzing.md +++ b/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/7-analyzing.md @@ -33,7 +33,7 @@ To compare the results you will use the Analyzer to import all three datasets bu You now have two datasets loaded, one from the unoptimized mode and one from the Burst mode. This is what the data looks like collected from our sample device. -![Plain vs Burst#center](images/analyzer-plain-vs-burst.PNG) +![Plain vs Burst#center](images/analyzer-plain-vs-burst.png) Focus on the collision-related markers by searching for _collisioncalc_ in the _Name Filter_. Select a representative frame by clicking on a later frame where both seem relatively settled (and with no odd spikes). @@ -45,6 +45,6 @@ In the top 10 markers, the unoptimized data is in blue. The Burst data is in ora Follow the same process again but this time we will compare Burst against Neon. -![Burst vs Neon#center](images/analyzer-burst-vs-neon.PNG) +![Burst vs Neon#center](images/analyzer-burst-vs-neon.png) Again, we can see an improvement, mostly with the dynamic (character-character) collision detection but together it still makes a meaningful improvement. diff --git a/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-burst-vs-neon.PNG b/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-burst-vs-neon.png similarity index 100% rename from content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-burst-vs-neon.PNG rename to content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-burst-vs-neon.png diff --git a/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-plain-vs-burst.PNG b/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-plain-vs-burst.png similarity index 100% rename from content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-plain-vs-burst.PNG rename to content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/images/analyzer-plain-vs-burst.png diff --git a/content/learning-paths/servers-and-cloud-computing/_index.md b/content/learning-paths/servers-and-cloud-computing/_index.md index a7e2bb052c..6edb9b3634 100644 --- a/content/learning-paths/servers-and-cloud-computing/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/_index.md @@ -344,7 +344,8 @@ tools_software_languages_filter: - Vectorscan: 1 - Velox: 1 - Veraison: 3 -- virsh / virt-manager: 1 +- virsh: 1 +- virt-install: 1 - Visual Studio Code: 7 - vLLM: 4 - VMAS: 1 diff --git a/content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/http-scaling.md b/content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/http-scaling.md index 7a38357e19..849354eb69 100644 --- a/content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/http-scaling.md +++ b/content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/http-scaling.md @@ -27,7 +27,7 @@ If you use an existing ingress controller, set `INGRESS_ADDRESS` to its endpoint ## Deploy the application and configure ingress -Now you'll deploy an HTTP server and expose it using an `Ingress` resource. For more informaton, see the [Kedify sample HTTP-server source code](https://github.com/kedify/examples/tree/main/samples/http-server). +Now you'll deploy an HTTP server and expose it using an `Ingress` resource. For more information, see the [Kedify sample HTTP-server source code](https://github.com/kedify/examples/tree/main/samples/http-server). Run the following command to deploy your application: diff --git a/content/learning-paths/servers-and-cloud-computing/net-aspire/_index.md b/content/learning-paths/servers-and-cloud-computing/net-aspire/_index.md index 3bded7640c..a4d26cb135 100644 --- a/content/learning-paths/servers-and-cloud-computing/net-aspire/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/net-aspire/_index.md @@ -13,7 +13,7 @@ learning_objectives: prerequisites: - A Windows on Arm machine such as the Lenovo Thinkpad X13s running Windows 11, to build the .NET Aspire project - An [Arm-based instance](/learning-paths/servers-and-cloud-computing/csp/) from AWS or GCP - - A code edito, such as [Visual Studio Code for Arm64](https://code.visualstudio.com/docs/?dv=win32arm64user) + - A code editor, such as [Visual Studio Code for Arm64](https://code.visualstudio.com/docs/?dv=win32arm64user) # START generated_summary_faq generated_summary_faq: diff --git a/content/learning-paths/servers-and-cloud-computing/nginx_tune/_index.md b/content/learning-paths/servers-and-cloud-computing/nginx_tune/_index.md index 0dbe89f092..aa9951355f 100644 --- a/content/learning-paths/servers-and-cloud-computing/nginx_tune/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/nginx_tune/_index.md @@ -15,7 +15,7 @@ learning_objectives: prerequisites: - An NGINX file server, reverse proxy, or API gateway running on a cloud instance, bare-metal server, or Arm AGI CPU platform - A repeatable HTTP workload or load test that you can run before and after tuning - - An [NGINX setup](learning-paths/servers-and-cloud-computing/nginx/) + - An [NGINX setup](/learning-paths/servers-and-cloud-computing/nginx/) # START generated_summary_faq generated_summary_faq: