Mindboards

Hi,

as you can see, I ask a lot of question here since I work on new NXT-606 version. Thanks to all for your interest and your advices.
The first NXT-606 http://youtu.be/CilCI2kSXnA

I have to say I am very curious (for a long time) on how NXT deal with memory allocation. NXT-G and NXC have same firmware, so I think they act the same way. I have to say I'm a NXT-G user only.

To make real time operation, NXT-606 plays with a lot of variables which are faster to read than .txt files. I use .txt file to save song when I shutdown NXT.
Most of you should think I use array block to deal with hundreds of values but I'm not. Because access time could increase very much when reading end of array values in NXT-G. In fact it is faster to use text variable (is it what you call strings?), pointing values with TextSubset block.

My question is about variable and text variable allocation. When I'm working with very big text variable (>1000 characters) I found no way to understand how NXT deal with it.
It seems text variable size is limited by free memory. More the program is big, less the text variable can be big. I'm surprised because I never thought variables were stored in flash memory as programs. But it could be logical....

The other strange thing is the weird NXT behaviour when testing variable size limits.
When creating very big text variable, allocation seems to be non linear. For this I make little program that increase text variable character number and wait to NXT to stop cause of a memory error. NXT stop when it can't deal with text anymore.

When create 1 text variable: Variable size is limited to about 6272 characters
----------2-------------------------------------4464
----------3-------------------------------------3456
----------4-------------------------------------2816
Why this curve is non linear ? It seems these limits are subject to change depending on many things: program size, way program have been downloaded, line where task "create text" is called. in fact it seems to be very unpredictable and I found no logical way to understand it, what is very frustrating.

May be I'm wrong but I "feel" like a multiple memory allocation, perhap's NXT try to deal with 8 memories allocation and store text variables by cuting it in several parts... really I don't get it.

Does someone know about all that?

Thanks.

Peter.

peter-cocteau wrote:Most of you should think I use array block to deal with hundreds of values but I'm not. Because access time could increase very much when reading end of array values in NXT-G. In fact it is faster to use text variable (is it what you call strings?), pointing values with TextSubset block.

Theoretically, both should have the same access times: O(1), or constant time. A text block is really an array of bytes in disguise, except that you can do certain magical things with it.

peter-cocteau wrote:My question is about variable and text variable allocation. When I'm working with very big text variable (>1000 characters) I found no way to understand how NXT deal with it.

You can use a drastically higher number of characters using alternative programming languages (NXC, and even higher with LeJOS and even even higher with RobotC). In NXT-G, however, you cannot store much in variables. The NXT-G generated RXE file is already bloated and filled with redundant/useless instructions which end up wasting memory, in addition to the already large size of the program itself. (The entire program is loaded into memory during execution, IIRC.)

If you end up exceeding what the NXT can handle in memory, you should use files. Just load chunks that you need into memory. This may be slow; I never figured out exactly how to use files with NXT-G.

peter-cocteau wrote:Why this curve is non linear ? It seems these limits are subject to change depending on many things: program size, way program have been downloaded, line where task "create text" is called. in fact it seems to be very unpredictable and I found no logical way to understand it, what is very frustrating.

I don't get it much either, but it goes something like this: Maybe that's exaggerated (or maybe not ), but what happens is the program ends up making multiple copies of a string, and doesn't deallocate the memory after using it. (The LEGO Firmware developers were going for something simple and easy to develop for use with simple programs, I suppose.)

It is weird. I haven't done thorough testing, but the curve looks kind of exponential, but also linear at times, IIRC. (This was with NXC over an year ago.)

muntoo wrote: You can use a drastically higher number of characters using alternative programming languages (NXC, and even higher with LeJOS and even even higher with RobotC).

I am not certain that you are correct with respect to RobotC. Where did you get this information from? I think strings are (or at least used to be) severely limited in their maximum length in RobotC. I'd be very surprised if it allowed a huge amount of variable/array memory beyond the 32k that the standard NXT firmware provides.

John Hansen

AFAIR RobotC supports only 20k for variables, CMIIW.
But it's admittedly faster, and they say that soon there will be support for pointers.
(No idea if "soon" already "is" or when it maybe will be - there already have been some issues about "soon" in previous releases) .

Anyway, I strongly recommend you to learn C or Java.

afanofosc wrote:I think strings are (or at least used to be) severely limited in their maximum length in RobotC.

I am probably wrong about this then. Maybe I mixed up 'speed' with 'more memory'.

And doc-helmut is recommending Java, so we all know that something must be wrong.