Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

I'm having a problem with a BX-24 project. It's about 10K of instructions and 270 to 275 bytes of RAM. If the RAM size gets to 275 to 280 bytes, the program will not execute after the compiler loads the EEPROM. It just hangs. If I get the RAM size down to 270 to 275 bytes the program runs just fine. I thought there was 401 bytes of RAM in the BX-24. I've been looking at the AT90S8535 docs and it appears there are 96 bytes of registers followed by 512 bytes of RAM which matches up with information of RAM from address 0 to 607. It seems to me that the first 111 bytes of RAM are allocated to the stack, and the user program gets the last 401. I only go 2 levels deep into subroutines and only pass two arguments sometimes. Most Sub Calls have no arguments. I can't believe I'm exceeding the stack and trashing user RAM. Or does the processor share its stack with the user's 401 bytes, and we don't really have 401 bytes to use? I cannot get a program to run with more than 280 bytes of user variables. Any idea what's going on here. I don't need 400 bytes of RAM, but 300 bytes would make life easier. Emil H

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Emil E. Hrivnak <> > [...] > If I get the RAM size down to 270 to 275 bytes > the program runs just fine. I thought there was > 401 bytes of RAM in the BX-24. It sounds like you're looking at only the RAM allocated to module-level variables. That's only part of the story -- RAM is also used by other things, such as stack frames. There is a section in the OS reference on measuring stack usage. > I've been looking at the AT90S8535 docs and it > appears there are 96 bytes of registers followed > by 512 bytes of RAM which matches up with > information of RAM from address 0 to 607. It > seems to me that the first 111 bytes of RAM are > allocated to the stack, and the user program > gets the last 401. The 111 bytes are dedicated to the operating system. The main stack takes up everything not allocated to the OS or to module-level variables. Check out the MPP file, line 21, to get the main stack size. > I only go 2 levels deep into subroutines and only > pass two arguments sometimes. Most Sub Calls have > no arguments. [...] The theoretical upper limit on nesting levels is about 40. In other words, subroutine A calls B, which calls C, etc. to a depth of 40. This assumes no memory allocated to variables. If each subroutine has an average of 9 bytes of local variables, the nesting limit is still pretty high -- about 20. -- Frank Manning -- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Only 1 subroutine has local variables, a byte and an integer, total of 3 bytes. Here's the info from the map file. Project file: C:\Basic X24\Stor\Receiver_04_07.bxp Date: 2003/04/07 00:07:56 DLL version: 2.0.24 Optimizer: On Max variable length string: 16 characters Strict syntax mode: On Processor type: BX-24 Code memory available: 32768 bytes Code memory allocated: 11041 bytes RAM available: 401 bytes RAM allocated: 270 bytes Main stack size: 131 bytes Persistent memory available: 480 bytes Persistent memory allocated: 5 bytes I have no other tasks defined, no interupts, no networking, 2 serial ports, COM 1 and COM3. It seems strange to me that the program won't start with that much RAM left for the Stack. From your comments it looks like a Subroutine call uses about 10 bytes for return address and whatever else goes on the stack. I've written 10's of thousands of lines of assembler for micros, some with a stack as small as 64 bytes and never had a stack overflow. I figured the OS might use some of the user's RAM for the stack and sort of planned on using 300 bytes for data storage and leave 100 bytes for the Stack. That seems like it ought to be enough. It seems that when the Stack size gets below 125, the program won't even start. After the download is complete, the first thing it does is initialize the display, and that doesn't work. Is this typical, or do I have to look somewhere else to clean things up? I read the section on Stack usage and figured I was no where near having a problem. The statement in there: "With good planning, programs with literally hundreds of tasks can be handled by the BasicX chip. The only limitations are total processing power and memory for variables and stacks. As a test, NetMedia created a program with 1000 tasks to test the multitasking engine. The program worked -- not fast, but it worked." How in the world did you get 1000 stacks for 1000 tasks out of 401 bytes of RAM??? Appreciate anything else to look for. Emil H At 12:17 AM 04/07/2003, you wrote: >From: Emil E. Hrivnak <> > > > [...] > > If I get the RAM size down to 270 to 275 bytes > > the program runs just fine. I thought there was > > 401 bytes of RAM in the BX-24. > >It sounds like you're looking at only the RAM allocated to >module-level variables. That's only part of the story -- RAM is >also used by other things, such as stack frames. There is a >section in the OS reference on measuring stack usage. > >The theoretical upper limit on nesting levels is about 40. In >other words, subroutine A calls B, which calls C, etc. to a depth >of 40. > >This assumes no memory allocated to variables. If each subroutine >has an average of 9 bytes of local variables, the nesting limit is >still pretty high -- about 20. > >-- Frank Manning >-- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Emil E. Hrivnak <> > Only 1 subroutine has local variables, a byte and > an integer, total of 3 bytes. Here's the info > from the map file. > [...] > > RAM available: 401 bytes > RAM allocated: 270 bytes > Main stack size: 131 bytes > [...] > I figured the OS might use some of the user's RAM > for the stack and sort of planned on using 300 bytes > for data storage and leave 100 bytes for the Stack. > That seems like it ought to be enough. It's difficult to say without knowing more about the code. In this case, the OS has been allocated 131 bytes for the stack, so the question is how much of that is actually being used. If you need to decrease stack use, generally speaking the best way is to reduce memory allocated to static variables and use local variables instead. That allows the OS to reclaim memory when it's not needed. > [...] How in the world did you get 1000 stacks > for 1000 tasks out of 401 bytes of RAM??? We used a BX-01 with 64 KB RAM: http://www.basicx.com/Products/BX-01/RamSandwich/RamSandwich.htm -- Frank Manning -- NetMedia, Inc.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I'm still trying to get a handle on RAM and Stack usage. I added a loop and debug.print statement to my program and printed out the RAM locations using RamPeek from address 207 to 607 (decimal). These were the first statements in the program. Then it ran and did everything it does and I looked for a switch closure to stop the program and print out the same RAM locations again. I compared the RAM locations. I saw lots of changes from 201 to 471 which are the 270 bytes of RAM used in the program. Looking at the map file I see one subroutine which looks like it uses 21 bytes for temps. If you add that to the end of the RAM used it would seem that RAM up to location 500 might get used. That's sort of what I saw. RAM locations: 491 to 516 not changed, 26 locations 517 to 518 changed, 2 locations 519 to 567 not changed, 49 locations 568 to 579 changed, 12 locations 589 to 607, not changed, 28 locations Now I'm confused more than ever. I would have expected the stack to start at the bottom, 607, and grow up to the user RAM. Or start from the user RAM and grow down to 607. But that's not what happens. There are over 100 locations not changed, which appears the stack did not write over the whole space. But there are 2 blocks in the middle with something written. Obviously I don't have enough information to figure out what's going on. If I recompile the program by adding 3 more bytes to one buffer length, using 273 bytes of RAM, the program will not run. I double checked the array indices and I'm not writing outside of the declared sizes. How can I determine, other than this, how much is being used by the stack? Why isn't it contiguous? Emil H At 12:53 PM 04/07/2003, you wrote: >It's difficult to say without knowing more about the code. In this >case, the OS has been allocated 131 bytes for the stack, so the >question is how much of that is actually being used. > >If you need to decrease stack use, generally speaking the best way >is to reduce memory allocated to static variables and use local >variables instead. That allows the OS to reclaim memory when it's >not needed. >-- Frank Manning >-- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Emil E. Hrivnak <> > I'm still trying to get a handle on RAM and Stack > usage. I added a loop and debug.print statement to > my program and printed out the RAM locations using > RamPeek from address 207 to 607 (decimal). These > were the first statements in the program. Then it > ran and did everything it does and I looked for a > switch closure to stop the program and print out > the same RAM locations again. I compared the RAM > locations. > > I saw lots of changes from 201 to 471 which are the > 270 bytes of RAM used in the program. [...] I think you mean 207 to 476? This is the 270 bytes allocated to static variables, judging by your map file. The main stack is 131 bytes in this case, which is addresses 477 to 607. The main stack starts at 477 and grows to 607. The first 15 bytes (477 to 491) are for the task frame. > How can I determine, other than this, how much is > being used by the stack? Why isn't it contiguous? It is contiguous, but it may appear to be noncontiguous because local and temporary variables, which occupy stack space, are not automatically initialized. So if those variables are never used, they won't affect data in RAM. Another thing you can look at is the stack pointer, which is a 16 bit unsigned integer at address 26. Code to access the stack pointer looks something like this: Private SP As New UnsignedInteger Private Const StackPointerAddress As Integer = 26 Public Sub DisplayStackPointer() Call BlockMove(2, StackPointerAddress, MemAddressU(SP)) Debug.Print "SP = "; CStr(SP) End Sub Here the SP should always be in range 492 to 607. Actually the lower value will be above 492 because of the overhead of a subprogram call. -- Frank Manning -- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I'm still cleaning up the program and adding things and stuff is moving around, but . . . I wrote "55" to RAM from address 480 to 601 using RAMPoke. Read it back and it was there. Ran the program and looked again. All but the last 16 bytes of stack space were over written. I added 12 more bytes of variable declarations and repeated. Everything moved down in RAM by 12 bytes and I had 4 bytes left at the bottom that was not over written. Now I'm convinced the Stack is that big, and I'm on the verge of being out of RAM. I did not expect the stack to grow that large. It's too bad in your spec sheets you don't mention that the 400 bytes of RAM are shared with the processor stack. Now that I understand what's going on and have a method to check on unused RAM, I'll begin tweaking my subroutines to minimize stack usage. I still need 20 or 30 bytes for some features I want to add. Thanks for your help and info. Emil H At 03:53 PM 04/08/2003, you wrote: >The main stack is 131 bytes in this case, which is addresses 477 >to 607. The main stack starts at 477 and grows to 607. The first >15 bytes (477 to 491) are for the task frame. > > > How can I determine, other than this, how much is > > being used by the stack? Why isn't it contiguous? > >It is contiguous, but it may appear to be noncontiguous because >local and temporary variables, which occupy stack space, are not >automatically initialized. So if those variables are never used, >they won't affect data in RAM. > >-- Frank Manning >-- NetMedia, Inc.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Emil E. Hrivnak <> > I wrote "55" to RAM from address 480 to 601 using > RAMPoke. Read it back and it was there. Ran the > program and looked again. All but the last 16 bytes > of stack space were over written. OK -- just be careful about avoiding writing to the stack where it's being used, and avoiding the task frame, which is the first 15 bytes of the stack. That's the trouble with measuring stack use if you have only one task. Normally you write data to a task stack array before starting the task, then measure the stack use after the task terminates. With only one task, of course, you just have to be more careful about writing to the stack while it's actually being used. > I added 12 more bytes of variable declarations > and repeated. Everything moved down in RAM by > 12 bytes and I had 4 bytes left at the bottom > that was not over written. Now I'm convinced > the Stack is that big, and I'm on the verge of > being out of RAM. > > I did not expect the stack to grow that large. System library code will use some of the stack, some subroutines more than others. Are you converting numbers to strings or vice versa? That tends to be expensive in RAM. > It's too bad in your spec sheets you don't > mention that the 400 bytes of RAM are shared > with the processor stack. [...] I'm not sure I follow. Are you saying the specs imply the 400 bytes are reserved exclusively for static data, and the stack is some other block of RAM somewhere? To me that sounds like an extremely inefficient way of using RAM. -- Frank Manning -- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Unfortunately I am doing a lot of numeric to string conversions. I'm receiving data from a telemetry transmitter with 8 analog channels of information, and am formatting it to put it on the 2 x 16 LCD display. This is the first micro I've purchased with an OS running and programmable in Basic. All my prior work has been in assembler language. I assumed that the 400 bytes of RAM was the user's RAM for variable storage, not shared with the OS or the processor stack. At least three places on your Web site you mention 400 bytes of RAM. You compare it with a BASIC Stamp 2 which you claim has 32 bytes of RAM, and a BASIC Stamp SX which has 96 bytes of RAM. I'm not familiar with either one of those. I would hope the Stamp 2 doesn't have to share that 32 bytes with the OS. Again I would assume that is the user's RAM for data storage. With that assumption, comparing apples to apples, the 400 bytes you advertise would be the same, for user data storage. I hope you can understand why I feel it's a little misleading. Again, thanks for your help. I still think it's a great processor and I was able to develop this project in less than a month, which included learning and ramp up time. It would have been much longer in assembler. Emil H At 12:55 PM 04/09/2003, you wrote: >System library code will use some of the stack, some subroutines >more than others. Are you converting numbers to strings or vice >versa? That tends to be expensive in RAM. > > > It's too bad in your spec sheets you don't > > mention that the 400 bytes of RAM are shared > > with the processor stack. [...] > >I'm not sure I follow. Are you saying the specs imply the 400 >bytes are reserved exclusively for static data, and the stack is >some other block of RAM somewhere? To me that sounds like an >extremely inefficient way of using RAM. > >-- Frank Manning >-- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Emil E. Hrivnak <> [...] > you mention 400 bytes of RAM. You compare it > with a BASIC Stamp 2 which you claim has 32 > bytes of RAM, and a BASIC Stamp SX which has > 96 bytes of RAM. I'm not familiar with either > one of those. I would hope the Stamp 2 doesn't > have to share that 32 bytes with the OS. Again > I would assume that is the user's RAM for data > storage. With that assumption, comparing > apples to apples, the 400 bytes you advertise > would be the same, for user data storage. I > hope you can understand why I feel it's a > little misleading. Yes, I can understand that, but only for programs in which all variables are global, or at least static. But that's a very restrictive way of writing programs. If you write code in such a way as to minimize the scope of each variable, not only is RAM use more efficient, the program is also easier to read and understand. In that case, if anything, we are being more conservative than the stamp, because BasicX implements a form of dynamic memory. It is possible to declare a variable, use the variable, then get rid of it. In C parlance, the variable would be automatic rather than static. Once the variable goes out of scope, the OS is able to reclaim that memory and make it available for other uses, including other variables. Overall it allows you to use memory more efficiently than would be the case if all variables were static. > Again, thanks for your help. I still think it's > a great processor and I was able to develop > this project in less than a month, which > included learning and ramp up time. It would > have been much longer in assembler. Glad to hear it -- let us know if we can help in the future. -- Frank Manning -- NetMedia, Inc.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )