RobotC limits the number of subroutines??? Oh boy, how do I get around this one?

Perhaps you can refactor some of your code? The only time I ran into this problem was when I wrote a test program for the HiTechnic SMUX and included the drivers for all of the supported sensors and some additional ones.

- Xander

This happened when I include the "LEGOLS-driver.h". If I commented that out, the error disappeared. Looking at LEGOLS-driver.h, it has quite a number of overloaded functions that I don't need and the ones I need are making simple HTSMUX calls. So I could skip including LEGOLS-driver.h and call those HTSMUX functions directly. But it still means I am very close to the limit. So if I create more functions, I will go over...

Again, it is always possible to rewrite the code to use fewer functions. But to make the code more modular and for maximum reusability, it is essential to be able to create more functions. In theory, one could write the entire program in task main without ever create a single function, but it is not practical.

Why does RobotC have this limitation? It sounds like RobotC's implementation is using some fixed size function table (with 160 entries). Is this a table in the compiler or in the compiled RXE file?

The limit used to be less than 100, this 160 limit was put in with 2.x. There is a limit to the max number of functions that an .rxe file can have, it has to do with function tables and all sorts of other stuff.

The problem is that a lot of functions in the drivers are not optmised out because they are called by other functions, even though those are dead code, too. It has to do with the way ROBOTC optimises code. Once a function is referenced by another, it becomes part of the compiled code, even if there's no "live" code that calls it. I will try and come up with some way to deal with this using #defines but it won't be done over night as this would require a major rewrite of -most- of the drivers.

- Xander

Thanks for the explanation. Knowing why it happens will also help me to avoid it. In a way, I am writing a library too. There may be functions in the library that are unused so I may be able to #ifdef them out to save a few entries.

But honestly, a compiler should not put a limit on the number of functions the programmer can write especially with a limit as low as 160. This limits the complexity of the code you can write.

The limit is in the firmware, not the compiler The compiler merely enforces the limit.

- Xander