cancel
Showing results for 
Search instead for 
Did you mean: 

TouchGFX - Library functions used (maths, strings).

AMars.4
Associate III

Hi all,

I currently working on a project using TouchGFX, multiple tasks are using functions from <math.h> which are not re-entrant, so I have them mutex protected. The drivers using these functions are written in C.

Does anyone know if the TouchGFX library uses any non re-entrant library functions? Do I need to be careful with anything I use in the application?

Kind Regards,

Anthony 

11 REPLIES 11
AMars.4
Associate III

Update:

My issue has been resolved, it turned out to be an issue with I2C which is being shared by two sensors, the data was being corrupted... looking at the comments in the <math.h> file confused me, it turns out most of these functions are thread safe according to ARM (as Tesla Delorean mentions above).

https://developer.arm.com/documentation/dui0475/m/the-c-and-c---library-functions-reference/thread-safe-c-library-functions

 

abs(), acos(), asin(),atan(), atan2(), atof(),atol(), atoi(), bsearch(),ceil(), cos(), cosh(),difftime(), div(), exp(),fabs(), floor(), fmod(),frexp(), labs(), ldexp(),ldiv(), log(), log10(),memchr(), memcmp(), memcpy(),memmove(), memset(), mktime(),modf(), pow(), qsort(),sin(), sinh(), sqrt(),strcat(), strchr(), strcmp(),strcpy(), strcspn(), strlcat(),strlcpy(), strlen(), strncat(),strncmp(), strncpy(), strpbrk(),strrchr(), strspn(), strstr(),strxfrm(), tan(), tanh()

These functions are inherently thread-safe.

I removed the mutexes after resolving the I2C issue and all is working.

Missing from the list, which I am using but not from multiple threads, I'm assuming they require a mutex unless ARM just missed them off the list (not tested yet).

  • asinh()
  • atanh()

Apologies for any confusion, lesson learnt... don't trust anything, don't jump to conclusions. 🙂

 

 

Yes, I think the inherent danger here is the lack of a proper context push at the interrupt handler or context switch when using the FPU (ARM, or 6888x). Normal ABI rules would have routines using FPU to VPUSH/VPOP things they need, but higher level routines wouldn't if they don't explicitly use the FPU registers, and would similarly be unaware of the deeper call-tree.

Interrupts might by default not push them, as the MCU pushes R0-R3, and normal ABI rules would have you pushing R4-R8, R14, etc.

I'd anticipate asinh(), atanh(), asoch(), atan2() etc to be safe. Functions are going to use the stack for auto/local variables and storage of intermediate solutions, if not in registers. They might use static/const tables to speed computations, but aren't going to stash thing in singular global memories.

I'd watch _set_errno() and exception handling

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..