According to the specs the Cortex has 64k ram, however I only seem to be able to access about 10k of it in RobotC, is there a way around this, or a good reason why this is so.
thanks
Steve
Ok a bit more searching and I now know why, maybe it should be a FAQ.
so I actually have 12k, still seems a bit excessive that RobotC’s firmware needs 52k 
I’m aware that most people just want to use it for advanced controller configuration and so 12K is more then enough, but there are some of us who might want to do something more complex.
I saw a question about allowing some of RobotC’s features to be optional, and the answer being that having a single firmware per platform kept things simple.
I don’t see why having a single firmware excludes allowing things to be optional. All you’d need is to be able to set some options in the IDE. these are tagged to a header when the code is downloaded, and the firmware can set some flangs and select alternative memory maps depending on what the user wants.
You could then allow the user to set the maximum amount of threads they want, how much stack space to allocate to each thread, what debugging support they need etc.
And personally, except on multi core machines, I prefer to only use threads where absolutely necessary, ignoring all the interesting bugs I’ve had to track down due to thread misuse, I just like to have more control over what mine and other peoples code is doing.
My 2nd computer only had 48k ram and a basic interpreter, but I still had 40k for my sole use… ok no debugging tools etc, but still.
And My 3rd Computer had 64K of ram, and to remote debug and compile for that I only lost about 4k if ram as all the hard work was done on the source computer, the target computer just needed respond to requests for memory info etc… ok that wasn’t a virtual machine and I was debugging assembly…
anyway
Hi Steve,
Thanks for the feedback and enthusiasm toward the products.
The ROBOTC firmware is a complete virtual machine, not just a collection of libraries. Removing “optional” functionality would actually mean having to rebuild the virtual machine on our end several times and offer several different firmware files based on the selections.
Thanks for the reply
I don’t know how your virtual machine is structured internally ,
but even though the firmware contains full functionality, couldn’t how and what it executes be dependent on a parameter table stored in ram, instead of some hard coded values, perhaps with an extra level of indirection. These could be setup based on data included in some sort of header when the code is downloaded?
also on a very slightly different note, RobotC supports the Pic and that only has 2k of ram, how does it manage there?
ta
Steve