I'm curiously following CODESYS transitioning away from the CAA libraries, and I'm mostly in favor of these major changes. Naturally, I'd like to align my current (not end-user) developments accordingly.
I'm tracking , reading release notes, ... And want to figure out the future :)
Is it possible to hear / read more about the reasons, objectives and scope of these changes?
One important element is CAA Types - CAA Types Extern. What is the plan with that?
What's the future of CAA.SEMA, CAA.BOLT ?
I have never used them (always relied on SysLib*), but they are tempting...
Would be useful to have a platform independent "Macro" for this functionality...
Is there something in existing or planned ?
Are they suitable to be used in low level libraries...
For Example IO-Drivers, Components, "to-become system libraries"?
CAA.TaskLock, CAA.TaskUnlock ? Well, they don't claim platform independency, so I can't rely on those....
Any up-to-date advise, standard, pattern to follow in new libraries for task and resource locking?
Practical set of conditional defines to be used?
If this information is not publicly available, can you please send a private message about the proper way to achieve this? I have support agreement, just couldn't get trough with these questions...
P.
Last edit: Strucc.c 2025-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been moving in the same direction. For new libraries, I'm trying to minimize dependencies on APIs that look like they're being phased out unless the documentation explicitly recommends them.
For synchronization primitives like CAA.BOLT and CAA.SEMA, I'd love to see an official replacement or abstraction layer that's guaranteed to remain stable across runtimes. That would make library development much cleaner than relying on platform-specific SysLib* implementations or conditional compilation everywhere.
Until there's clearer guidance, my approach has been to isolate the locking mechanism behind a small wrapper interface. If CODESYS changes the recommended API in the future, only that wrapper needs to be updated instead of every library that uses it. It isn't perfect, but it's made maintenance much easier.
Dear All,
Dear CODESYS,
I'm curiously following CODESYS transitioning away from the CAA libraries, and I'm mostly in favor of these major changes. Naturally, I'd like to align my current (not end-user) developments accordingly.
I'm tracking , reading release notes, ... And want to figure out the future :)
Is it possible to hear / read more about the reasons, objectives and scope of these changes?
One important element is CAA Types - CAA Types Extern. What is the plan with that?
What's the future of CAA.SEMA, CAA.BOLT ?
I have never used them (always relied on SysLib*), but they are tempting...
Would be useful to have a platform independent "Macro" for this functionality...
Is there something in existing or planned ?
Are they suitable to be used in low level libraries...
For Example IO-Drivers, Components, "to-become system libraries"?
CAA.TaskLock, CAA.TaskUnlock ? Well, they don't claim platform independency, so I can't rely on those....
Any up-to-date advise, standard, pattern to follow in new libraries for task and resource locking?
Practical set of conditional defines to be used?
If this information is not publicly available, can you please send a private message about the proper way to achieve this? I have support agreement, just couldn't get trough with these questions...
P.
Last edit: Strucc.c 2025-03-14
I've been moving in the same direction. For new libraries, I'm trying to minimize dependencies on APIs that look like they're being phased out unless the documentation explicitly recommends them.
For synchronization primitives like CAA.BOLT and CAA.SEMA, I'd love to see an official replacement or abstraction layer that's guaranteed to remain stable across runtimes. That would make library development much cleaner than relying on platform-specific SysLib* implementations or conditional compilation everywhere.
Until there's clearer guidance, my approach has been to isolate the locking mechanism behind a small wrapper interface. If CODESYS changes the recommended API in the future, only that wrapper needs to be updated instead of every library that uses it. It isn't perfect, but it's made maintenance much easier.
https://forge.codesys.com/forge/talk/Engineering/thread/e6c20a740e/ https://zapgames.io/
Last edit: williamcorlin 4 days ago