Wrapping up.
The RP2350 and SDK2.0 are indeed fully compatible with the RP2040 and SDK1.5… nearly. This would be true of most normal applications. This based on the fact that the cortex-m33 supports a superset of the cortex-cm0+ instruction set, and the attention paid to keeping SDK2.0 backwards compatible.
So, the cm0+ code generated by pshell should run as-is, right? Well, almost but not quite! Contrary to initial expectations though, the required changes were minimal. First recompiling for the RP2350, after correcting link errors, got most of it working, with the sole exception being the compiler.
The few required compiler changes:
-The compiler relies on a couple of symbols not present in the default linker script. A modified version had to be provided as an RP2350 specific .ld linker script.
-The second, and last issue: the void __wrap___aeabi_idiv, __wrap___aeabi_i2f, __wrap___aeabi_f2iz, __wrap___aeabi_fadd, __wrap___aeabi_fsub, __wrap___aeabi_fmul(), __wrap___aeabi_fdiv, __wrap___aeabi_fcmple, __wrap___aeabi_fcmpgt, __wrap___aeabi_fcmplt and __wrap___aeabi_fcmpge RP2040 wrapper functions are not present in the RP2350 ROM. This is the link error that needed fixing.
-For the integer divide and modulus operators the compiler is updated to generate sdiv for division and sdiv mls instructions for the modulus operator. The cortex-m33 has hardware integer divide.
-That leaves those functions above that involve floating point operators or conversions. The cortex-m33 has 16 (I think?) floating point registers and a bunch of floating point operators, hence the missing ROM functions. Functional equivalents using the hardware floating point operators could have been generated as inline instructions. Unfortunately, the disassembler doesn’t understand the floating-point vector extension instructions and really messes up the disassembly listings, so a different approach was needed. Instead, functional equivalents for these floating-point functions using hardware support are provided as static functions in the compiler’s C code, which is always resident in phell. This way they are invoked the same as for the RP2040, via function calls to external functions. So, no code generator changes.
All in all, minimal changes given the overall size of the project. I think that speaks volumes for the compatibility of the RP2350 vs. the RP2040, at least for a software-centric projects such as this one.
There remains updating the predefined symbols and functions where there are differences for the RP2350. The tedious part!
The RP2350 and SDK2.0 are indeed fully compatible with the RP2040 and SDK1.5… nearly. This would be true of most normal applications. This based on the fact that the cortex-m33 supports a superset of the cortex-cm0+ instruction set, and the attention paid to keeping SDK2.0 backwards compatible.
So, the cm0+ code generated by pshell should run as-is, right? Well, almost but not quite! Contrary to initial expectations though, the required changes were minimal. First recompiling for the RP2350, after correcting link errors, got most of it working, with the sole exception being the compiler.
The few required compiler changes:
-The compiler relies on a couple of symbols not present in the default linker script. A modified version had to be provided as an RP2350 specific .ld linker script.
-The second, and last issue: the void __wrap___aeabi_idiv, __wrap___aeabi_i2f, __wrap___aeabi_f2iz, __wrap___aeabi_fadd, __wrap___aeabi_fsub, __wrap___aeabi_fmul(), __wrap___aeabi_fdiv, __wrap___aeabi_fcmple, __wrap___aeabi_fcmpgt, __wrap___aeabi_fcmplt and __wrap___aeabi_fcmpge RP2040 wrapper functions are not present in the RP2350 ROM. This is the link error that needed fixing.
-For the integer divide and modulus operators the compiler is updated to generate sdiv for division and sdiv mls instructions for the modulus operator. The cortex-m33 has hardware integer divide.
-That leaves those functions above that involve floating point operators or conversions. The cortex-m33 has 16 (I think?) floating point registers and a bunch of floating point operators, hence the missing ROM functions. Functional equivalents using the hardware floating point operators could have been generated as inline instructions. Unfortunately, the disassembler doesn’t understand the floating-point vector extension instructions and really messes up the disassembly listings, so a different approach was needed. Instead, functional equivalents for these floating-point functions using hardware support are provided as static functions in the compiler’s C code, which is always resident in phell. This way they are invoked the same as for the RP2040, via function calls to external functions. So, no code generator changes.
All in all, minimal changes given the overall size of the project. I think that speaks volumes for the compatibility of the RP2350 vs. the RP2040, at least for a software-centric projects such as this one.
There remains updating the predefined symbols and functions where there are differences for the RP2350. The tedious part!
Statistics: Posted by lurk101 — Wed Sep 04, 2024 7:44 pm