This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I have a work around for the problem using multiple delay calls. Just FYI. Document is wrong or it's a bug.
according to table 5-4 in SPRUHV7C – July 2014 – Revised July 2018
void __delay_cycles( unsigned int cycles ); varies Delays PRU execution for the specified number of cycles.
The number of cycles must be a constant.
any value exceeding INT32_MAX (signed int) results in a 64 bit rollover error.
WARNING! at line 106: [W0001] Constant value out of range,
will be truncated to 32 bits
LDI32 r0, 9223372035781033983
after truncation this results in an incorrect wait time.
tool chain Version numbers
PRU C/C++ Compiler v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU EABI C/C++ Parser v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU C/C++ File Merge v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU C/C++ Optimizer v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU C/C++ Codegen v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Assembler v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Embed Utility v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU C Source Interlister v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Linker v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Absolute Lister v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Strip Utility v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU XREF Utility v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU C++ Demangler v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Hex Converter v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Name Utility v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Object File Display v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
PRU Archiver v2.3.3
Build Number 1TKVO-2LI-UASAR-TAR-C08D
sample code to reproduce
#include <stdint.h> const uint32_t MAX_CYCLES_WITHOUT_ERROR = INT32_MAX; void main(void) { __delay_cycles(MAX_CYCLES_WITHOUT_ERROR); __delay_cycles(MAX_CYCLES_WITHOUT_ERROR+1); }
Thank you for submitting that sample code. When I build it, I do not see a diagnostic similar to ...
WARNING! at line 106: [W0001] Constant value out of range,
will be truncated to 32 bits
LDI32 r0, 9223372035781033983
For the source file that does see this diagnostic, please follow the directions in the article How to Submit a Compiler Test Case.
Thanks and regards,
-George
George,
I am using the stand alone Linux tool chain. I still see the same warning.
ti_cgt_pru_2.3.3_linux-x64
README.txt says
TI PRU C/C++ CODE GENERATION TOOLS
2.3.3 Release Notes
November 2019
from the compiler directory I compile the sample file.
no options
$ bin/clpru -I include main.c
"/tmp/TIDny1tPjK5", WARNING! at line 76: [W0001] Constant value out of range,
will be truncated to 32 bits
LDI32 r0, 9223372035781033993
No Assembly Errors, 1 Assembly Warning
Possibly there is a difference in CCS and stand alone versions.
I'll look at link and resubmit the test case. Not sure it can be any simpler than what I currently have.
Linux x86 PRU cross compiler 2.3.3
CGT link software-development ti_cgt_pru_2.3.3_linux_installer_x86.bin
install compiler tools in home directory
option set emit warnings as errors (-pdew)
makefile
CC := "${HOME}/ti/ti-cgt-pru_2.3.3/bin/clpru" #----------------------------------------------------------------------------- # Name the object files #----------------------------------------------------------------------------- OBJS := main.obj #----------------------------------------------------------------------------- # Develop C_OPTS: The compiler build options #----------------------------------------------------------------------------- C_OPTS := -I${HOME}/ti/ti-cgt-pru_2.3.3/include -k -ss -al --gen_preprocessor_listing -pdew #----------------------------------------------------------------------------- # Link build rule #----------------------------------------------------------------------------- test_case.out : $(OBJS) $(CC) -z -i${HOME}/ti/ti-cgt-pru_2.3.3/lib --rom_model $(OBJS) -llibc.a -o=$@ #----------------------------------------------------------------------------- # Compile build rule #----------------------------------------------------------------------------- %.obj : %.c $(CC) -version $(CC) $(C_OPTS) $<
source file
#include <stdint.h> const uint32_t MAX_CYCLES_WITHOUT_ERROR = INT32_MAX; void main(void) { __delay_cycles(MAX_CYCLES_WITHOUT_ERROR); __delay_cycles(MAX_CYCLES_WITHOUT_ERROR+22); }
Thank you for submitting a test case. I can reproduce the same behavior. This is the first time, in several years, that a problem has occurred only on Linux. I was not expecting that. I filed EXT_EP-11231 to have this investigated. You are welcome to follow it with that link.
Thanks and regards,
-George