Thanks for your response. I will explain below the reasons that we looked at the possibility of using Hyperbuild instead of Autocode. But, at the beginning I would like to mention that the unix command "hyperbuild" supports "-t" amongst other options.
As I mentioned in the previous postings we are desperately struggling to generate a completely re-usable code from a general hybrid (continuous & multi-rate discrete) system.
The major difficulty in using Autocode is the lack of re-usable interface for the generated tasks. This problem is removed in the hyperbuild code generation which uses a UCB style hook for calling functions for different tasks (even though there are still other
problems such as global percent vars., static local outputs, static i
nputs for procedure call, ...).
We are going through many steps to post-processing of autocoded files (using script utilities such a sed or perl) to convert the format of the code. This is majorly because of the lack of flexibility of autocode TPL in allowing the user to affect some part of code generation governed by atomic internal TPL library functions such as "define_subsystem()".
The major problem in post-processing of the code outside of the TPL is that it become extensively time consuming for large size codes since the utilities used for this purpose are essentially search and replace programs that do not have any idea about the structure of the code. Moreover, in many cases one have to rely on code features such as comments which might not be presereved in future versions of the Autocode.
Any hints on how to by-pass these problems?
It is worth to mention that the Matlab Real-Time workshop provides the "grt_malloc" target that generates a fully re-usable code w
ith dynamic allocation for a system.
Thanks
