diff --git a/README.md b/README.md index f7ad83f..e6e446b 100644 --- a/README.md +++ b/README.md @@ -94,7 +94,7 @@ Compiling and running [jetgpio_output.c](https://github.com/Rubberazer/JETGPIO/b | Average | 0.6 us | 2 us ** | -**Yes, the new Orin has a slower response/higher latency than the old Jetson Nano, this is due to the fact that writing to some registers is being monitored by an external Arm R5 MCU called SPE (Sensor Processing Engine). This CPU is an addition to what is called CPU Complex (the 6 Arm A78A cores that are described on the Orin Nano/NX specs), this CPU is running FreeRTOS and is completely independent from the main system. Some of the tasks performed by this CPU are clock and power supply management for peripherals inside the SOM e.g. PWM, GPIO... but it also plays a "firewall" role, in other words before writing to some registers in the standard CPU Complex the writing instructions have to pass through this "firewall" making the whole thing slower. This extra, out of the system security manager can be very useful on some applications but it has obviously a downside. Again sorting this out goes beyond the scope of any user space application (library) and it would imply flashing the Orin after modifying stuff, which is something along with other things like modifying the device tree (and reflashing probably) that I wanted to avoid when I created this library. +**Yes, the new Orin has a slower response/higher latency than the old Jetson Nano, this is due to the fact that writing to some registers is being monitored by an external Arm R5 MCU called BPMP (Boot and Power Management Processor). This MCU is an addition to what is called CPU Complex (the 6 Arm A78A cores that are described on the Orin Nano/NX specs), this CPU is running FreeRTOS and is completely independent from the main system. Some of the tasks performed by this MCU are clock and power supply management for peripherals inside the SOM e.g. PWM, GPIO... but it also plays a "firewall" role, in other words before writing to some registers in the standard CPU Complex the writing instructions have to pass through this "firewall" making the whole thing slower. This extra, out of the system security manager can be very useful on some applications but it has obviously a downside. Again sorting this out goes beyond the scope of any user space application (library) and it would imply flashing the Orin after modifying stuff, which is something along with other things like modifying the device tree (and reflashing probably) that I wanted to avoid when I created this library. ![oscillo_output](https://github.com/Rubberazer/JETGPIO/assets/47650457/7f42ef1d-17f6-45bd-a4ce-68e6481ab7a8) diff --git a/docs/html/index.html b/docs/html/index.html index 2b6b82f..52e908d 100644 --- a/docs/html/index.html +++ b/docs/html/index.html @@ -154,7 +154,7 @@

THE NEED FOR SPEED:

Average 0.6 us 2 us ** -

**Yes, the new Orin has a slower response/higher latency than the old Jetson Nano, this is due to the fact that writing to some registers is being monitored by an external Arm R5 MCU called SPE (Sensor Processing Engine). This CPU is an addition to what is called CPU Complex (the 6 Arm A78A cores that are described on the Orin Nano/NX specs), this CPU is running FreeRTOS and is completely independent from the main system. Some of the tasks performed by this CPU are clock and power supply management for peripherals inside the SOM e.g. PWM, GPIO... but it also plays a "firewall" role, in other words before writing to some registers in the standard CPU Complex the writing instructions have to pass through this "firewall" making the whole thing slower. This extra, out of the system security manager can be very useful on some applications but it has obviously a downside. Again sorting this out goes beyond the scope of any user space application (library) and it would imply flashing the Orin after modifying stuff, which is something along with other things like modifying the device tree (and reflashing probably) that I wanted to avoid when I created this library.

+

**Yes, the new Orin has a slower response/higher latency than the old Jetson Nano, this is due to the fact that writing to some registers is being monitored by an external Arm R5 MCU called BPMP (Boot and Power Management Processor). This MCU is an addition to what is called CPU Complex (the 6 Arm A78A cores that are described on the Orin Nano/NX specs), this CPU is running FreeRTOS and is completely independent from the main system. Some of the tasks performed by this MCU are clock and power supply management for peripherals inside the SOM e.g. PWM, GPIO... but it also plays a "firewall" role, in other words before writing to some registers in the standard CPU Complex the writing instructions have to pass through this "firewall" making the whole thing slower. This extra, out of the system security manager can be very useful on some applications but it has obviously a downside. Again sorting this out goes beyond the scope of any user space application (library) and it would imply flashing the Orin after modifying stuff, which is something along with other things like modifying the device tree (and reflashing probably) that I wanted to avoid when I created this library.

oscillo_output

JETSON NANO AND ORIN PINOUT:

The library uses the typical 40 pin header numbering, taking the dev kit as reference so for instance pin 3 is I2C_2_SDA, pin 1 is 3.3 VDC power and so on. You can check the official NVIDIA pinmux configuration for reference or if not available you can use the ones below: