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

Hello All, Thought I'd introduce myself, then ask a couple questions. My name is Steve Stover. I'm working on a project using the BX-01 chip and code as an embedded controller on a small box. The box does a mixture of ADC, DAC, Pin I/O, SPI bus, and RS-232 bus operations. The box is set up and (possibly) monitored across a RS-232 link to a LABView program. My job is the BasicX code, LABView code, and specifying the RS-232 interface between the two. The challenges have been many: relearning LABView, learning BasicX, working without a debugger, and the biggest problem so far, only 256 bytes (?) of RAM to play with, since the hardware designers didn't add any external RAM to the mix. Overflowing task stacks seem to interfere with the variables at the next higher address in the memory map. I had a generic routine to check for task stack usage, which doesn't seem to have worked all that well. Guess if the stack happens to store a value that you've pre-filled the stack with, it's hard to tell the actual stack usage. Some general questions, which I probably know the answers to already, but here goes: 1) For future reference, what debuggers or debugging tools are available, if any? 2) How much embedded RAM does the BX-01 actually have? I've seen 256 and 512 bytes. The MPP map file seems to indicate 512. 3) Where does the kernel put the main program stack? Does the stack grow up or down? Can stack size be specified? How does the kernel organize it's RAM in general? 4) Is it possible to somehow embed assembly code within the BasicX code? I could definitely use SHL and SHR operations, among others. Basic has some real limitations for embedded hardware control, in my personal prejudiced opinion... :) Steve Stover SRC Huntsville, AL

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

At 12:26 PM 2/7/2000 -0600, you wrote: >2) How much embedded RAM does the BX-01 actually have? I've seen 256 and >512 bytes. The MPP map file seems to indicate 512. 256 bytes, so say the specs. The Atmel 8515, upon which the BX-01 is based, has 512 bytes of internal SRAM, but apparently the BasicX code consumes about half of that. And of course, the BasicX code consumes all of the 8K of Flash that the 8515 offers. >3) Where does the kernel put the main program stack? Does the stack grow up >or down? Can stack size be specified? How does the kernel organize it's >RAM in general? Download: http://www.atmel.com/atmel/acrobat/doc0841.pdf which is the architectural overview of the 8515. It explains the program/data stacks, and how memory is used in the chip. >4) Is it possible to somehow embed assembly code within the BasicX code? I >could definitely use SHL and SHR operations, among others. Basic has some >real limitations for embedded hardware control, in my personal prejudiced >opinion... :) Inline assembly code would be nice, but for the hardware side of things, may not be absolutely necessary, since BasicX allows you to directly manipulate the hardware registers of the chip, which is where most of the action takes place anyway. The app note on using dual PWM (on the NetMedia site) is just one example of directly controlling the registers, in this case, the registers for the 16-bit Timer1. Of course, this doesn't mean you can manipulate just *any* register. Timer0 appears to be used for the real-time-clock, for example. -- Gordon

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

Hi Gordon, Thanks for the info! Inline assembly would allow bit shifts, enabling fast x2 and /2 operations, as well as making it easier to use bits as Boolean flags instead of whole bytes - a nice way to save precious RAM. I'm not really looking for hardware register control as much as easy bit manipulation. I finally managed to download the link you gave, but didn't find any info on actual compiler usage and organization of the RAM. There is a generic memory map, but I'm looking for memory usage by the compiler. I figure if I know where the stack is and how memory is organized, I'll have a much better chance of catching stack overflow. So far I've noticed about 6 different failure modes of stack overflow (I assume) in the program, but as of now I have no theory for the failure mechanism of the most insidious ones... :( Thanks again for the info. Steve Stover -----Original Message----- From: Gordon McComb [mailto:] Sent: Monday, February 07, 2000 1:30 PM To: Subject: Re: [BasicX] Introduction and Questions From: Gordon McComb <> At 12:26 PM 2/7/2000 -0600, you wrote: >2) How much embedded RAM does the BX-01 actually have? I've seen 256 and >512 bytes. The MPP map file seems to indicate 512. 256 bytes, so say the specs. The Atmel 8515, upon which the BX-01 is based, has 512 bytes of internal SRAM, but apparently the BasicX code consumes about half of that. And of course, the BasicX code consumes all of the 8K of Flash that the 8515 offers. >3) Where does the kernel put the main program stack? Does the stack grow up >or down? Can stack size be specified? How does the kernel organize it's >RAM in general? Download: http://www.atmel.com/atmel/acrobat/doc0841.pdf which is the architectural overview of the 8515. It explains the program/data stacks, and how memory is used in the chip. >4) Is it possible to somehow embed assembly code within the BasicX code? I >could definitely use SHL and SHR operations, among others. Basic has some >real limitations for embedded hardware control, in my personal prejudiced >opinion... :) Inline assembly code would be nice, but for the hardware side of things, may not be absolutely necessary, since BasicX allows you to directly manipulate the hardware registers of the chip, which is where most of the action takes place anyway. The app note on using dual PWM (on the NetMedia site) is just one example of directly controlling the registers, in this case, the registers for the 16-bit Timer1. Of course, this doesn't mean you can manipulate just *any* register. Timer0 appears to be used for the real-time-clock, for example. -- Gordon

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

Inline assembly is impossible due to the fact that assembly can only be executed out of the internal AVR chips's flash. This flash can only be written after complete erasure which would remove the operating system. We only have a few bytes left in the flash anyway for our own use. Globals are allocated from low ram upwards. Then comes the stack which grows upwards. The stack includes local variables, task and subroutine frames, and temporary execution of expressions and arguments for subroutines and system calls. Since it is dynamic, it is hard to estimate usage - as it is on all processors. Since we have a few bytes of ram, it becomes necessary to employ memory saving options. Some of them are: Use globals when locals are not necessary limit the number of subroutine calls within subroutines - each call needs a frame and the local variables. since you have 32K of code space, you can sometimes spend code and save memory. Please see the new system calls like GetBit and PutBit (BX24 only right now) for bit variables. We will be coming out with a BX2 which is a BX1 (same pinout) minus the network and plus many of the new BX24 system calls (like GetBit). It will also be serially downloadable. It will also have more RAM (400 bytes) available internally and can accept external RAM up to the 128K like the BX1. I hope this helps, Jack -----Original Message----- From: Steve Stover <> To: <> Date: Tuesday, February 08, 2000 7:55 AM Subject: RE: [BasicX] Introduction and Questions >From: "Steve Stover" <> > >Hi Gordon, > >Thanks for the info! > >Inline assembly would allow bit shifts, enabling fast x2 and /2 operations, >as well as making it easier to use bits as Boolean flags instead of whole >bytes - a nice way to save precious RAM. I'm not really looking for >hardware register control as much as easy bit manipulation. > >I finally managed to download the link you gave, but didn't find any info on >actual compiler usage and organization of the RAM. There is a generic >memory map, but I'm looking for memory usage by the compiler. I figure if I >know where the stack is and how memory is organized, I'll have a much better >chance of catching stack overflow. So far I've noticed about 6 different >failure modes of stack overflow (I assume) in the program, but as of now I >have no theory for the failure mechanism of the most insidious ones... :( > >Thanks again for the info. >Steve Stover > >-----Original Message----- >From: Gordon McComb [mailto:] >Sent: Monday, February 07, 2000 1:30 PM >To: >Subject: Re: [BasicX] Introduction and Questions > >From: Gordon McComb <> > >At 12:26 PM 2/7/2000 -0600, you wrote: >>2) How much embedded RAM does the BX-01 actually have? I've seen 256 and >>512 bytes. The MPP map file seems to indicate 512. > >256 bytes, so say the specs. The Atmel 8515, upon which the BX-01 is based, >has 512 bytes of internal SRAM, but apparently the BasicX code consumes >about half of that. And of course, the BasicX code consumes all of the 8K >of Flash that the 8515 offers. > >>3) Where does the kernel put the main program stack? Does the stack grow >up >>or down? Can stack size be specified? How does the kernel organize it's >>RAM in general? > >Download: > >http://www.atmel.com/atmel/acrobat/doc0841.pdf > >which is the architectural overview of the 8515. It explains the >program/data stacks, and how memory is used in the chip. > >>4) Is it possible to somehow embed assembly code within the BasicX code? I >>could definitely use SHL and SHR operations, among others. Basic has some >>real limitations for embedded hardware control, in my personal prejudiced >>opinion... :) > >Inline assembly code would be nice, but for the hardware side of things, >may not be absolutely necessary, since BasicX allows you to directly >manipulate the hardware registers of the chip, which is where most of the >action takes place anyway. The app note on using dual PWM (on the NetMedia >site) is just one example of directly controlling the registers, in this >case, the registers for the 16-bit Timer1. Of course, this doesn't mean >you can manipulate just *any* register. Timer0 appears to be used for the >real-time-clock, for example. > >-- Gordon >--------------------------- ONElist Sponsor ---------------------------- > >Want To Be Showered With Kisses? >Visit eGroups Valentine Gift Guide ><a href=" http://clickme.onelist.com/ad/SparksValentine9 ">Click Here</a> > >------------------------------------------------------------------------

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

Jack: I know that multiplies and divides by powers of two can be used for bit shifting however isn't that a significant perfomance hit since the AVR chip has bit shift instruction? Now if it is that VB does not have those operator then make them system function calls. Why does Netmedia continue to resist adding native mode shift commands to the Basic X system? Cheers... Rich > ---------- > From: Jack Schoof[SMTP:] > Reply To: > Sent: Tuesday, February 08, 2000 8:38 AM > To: > Subject: Re: [BasicX] Introduction and Questions > > From: "Jack Schoof" <> > > Inline assembly is impossible due to the fact that assembly can only be > executed out of the internal AVR chips's flash. This flash can only be > written after complete erasure which would remove the operating system. We > only have a few bytes left in the flash anyway for our own use. > > Globals are allocated from low ram upwards. Then comes the stack which > grows upwards. The stack includes local variables, task and subroutine > frames, and temporary execution of expressions and arguments for subroutines > and system calls. Since it is dynamic, it is hard to estimate usage - as it > is on all processors. Since we have a few bytes of ram, it becomes > necessary to employ memory saving options. > > Some of them are: > Use globals when locals are not necessary > limit the number of subroutine calls within subroutines - each call needs a > frame and the local variables. > since you have 32K of code space, you can sometimes spend code and save > memory. > > Please see the new system calls like GetBit and PutBit (BX24 only right > now) for bit variables. > > We will be coming out with a BX2 which is a BX1 (same pinout) minus the > network and plus many of the new BX24 system calls (like GetBit). It will > also be serially downloadable. It will also have more RAM (400 bytes) > available internally and can accept external RAM up to the 128K like the > BX1. > > I hope this helps, > > Jack > > -----Original Message----- > From: Steve Stover <> > To: <> > Date: Tuesday, February 08, 2000 7:55 AM > Subject: RE: [BasicX] Introduction and Questions > >From: "Steve Stover" <> > > > >Hi Gordon, > > > >Thanks for the info! > > > >Inline assembly would allow bit shifts, enabling fast x2 and /2 operations, > >as well as making it easier to use bits as Boolean flags instead of whole > >bytes - a nice way to save precious RAM. I'm not really looking for > >hardware register control as much as easy bit manipulation. > > > >I finally managed to download the link you gave, but didn't find any info > on > >actual compiler usage and organization of the RAM. There is a generic > >memory map, but I'm looking for memory usage by the compiler. I figure if > I > >know where the stack is and how memory is organized, I'll have a much > better > >chance of catching stack overflow. So far I've noticed about 6 different > >failure modes of stack overflow (I assume) in the program, but as of now I > >have no theory for the failure mechanism of the most insidious ones... :( > > > >Thanks again for the info. > >Steve Stover > > > >-----Original Message----- > >From: Gordon McComb [mailto:] > >Sent: Monday, February 07, 2000 1:30 PM > >To: > >Subject: Re: [BasicX] Introduction and Questions > > > >From: Gordon McComb <> > > > >At 12:26 PM 2/7/2000 -0600, you wrote: > >>2) How much embedded RAM does the BX-01 actually have? I've seen 256 and > >>512 bytes. The MPP map file seems to indicate 512. > > > >256 bytes, so say the specs. The Atmel 8515, upon which the BX-01 is based, > >has 512 bytes of internal SRAM, but apparently the BasicX code consumes > >about half of that. And of course, the BasicX code consumes all of the 8K> > >of Flash that the 8515 offers. > > > >>3) Where does the kernel put the main program stack? Does the stack grow > >up > >>or down? Can stack size be specified? How does the kernel organize it's > >>RAM in general? > > > >Download: > > > >http://www.atmel.com/atmel/acrobat/doc0841.pdf > > > >which is the architectural overview of the 8515. It explains the > >program/data stacks, and how memory is used in the chip. > > > >>4) Is it possible to somehow embed assembly code within the BasicX code? > I > >>could definitely use SHL and SHR operations, among others. Basic has some > >>real limitations for embedded hardware control, in my personal prejudiced > >>opinion... :) > > > >Inline assembly code would be nice, but for the hardware side of things, > >may not be absolutely necessary, since BasicX allows you to directly > >manipulate the hardware registers of the chip, which is where most of the > >action takes place anyway. The app note on using dual PWM (on the NetMedia > >site) is just one example of directly controlling the registers, in this > >case, the registers for the 16-bit Timer1. Of course, this doesn't mean > >you can manipulate just *any* register. Timer0 appears to be used for the > >real-time-clock, for example. > > > >-- Gordon > > > > > >--------------------------- ONElist Sponsor ---------------------------- > > > >Want To Be Showered With Kisses? > >Visit eGroups Valentine Gift Guide > ><a href=" http://clickme.onelist.com/ad/SparksValentine9 ">Click Here</a> > > > >------------------------------------------------------------------------ > > > > --------------------------- ONElist Sponsor ---------------------------- > > Finding a sweetheart is hard work. Shopping for one shouldn't be. > Click here for Valentine Surprises. > <a href=" http://clickme.onelist.com/ad/SparksValentine5 ">Click Here</a> > > ------------------------------------------------------------------------

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

> From: "Jack Schoof" <> > [...] > Globals are allocated from low ram upwards. Then comes > the stack which grows upwards. The stack includes local > variables, task and subroutine frames, and temporary > execution of expressions and arguments for subroutines > and system calls. [...] One improvement in V1.45 is that more detail was added to the map file (the one with the MPP extension). In particular it tells you the size of the main stack, which occupies whatever RAM is left over after allocations to static data such as global variables. -- Frank Manning -- NetMedia, Inc.

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

Jack S was kind enough to illuminate: -----Original Message----- From: "Jack Schoof" <> <snip> Globals are allocated from low ram upwards. Then comes the stack which grows upwards. The stack includes local variables, task and subroutine frames, and temporary execution of expressions and arguments for subroutines and system calls. Since it is dynamic, it is hard to estimate usage - as it is on all processors. Since we have a few bytes of ram, it becomes necessary to employ memory saving options. I guess my $100,000 question right now is: what happens if the stack tries to grow upwards past the end of RAM? Is any extra stack data lost? Does the stack wrap back to low(est) memory, or to the start of global variables? The different failure modes I've encountered don't seem to give a definitive answer. If I know what happens I can look for specific first signs of failure, instead of just noting catastrophic failure. <snip> What is included in a "subroutine frame"? Just a word return address, or more than that (not including local variables)? Anyone know a good program for displaying call trees? I also tried to return the register stack pointers (to estimate stack usage) in the call registers at different places in the program. I always got the same values, despite differing call-tree depth. Maybe I must pass the registers thru intermediate variables, instead of using the registers as arguments in a subroutine call? A separate issue has been the second task stack. FYI This does seem to grow upwards, and exceeding this stack will overwrite any variables after the stack variable. I have further noted that proper stack operation seems to require 6 bytes more than the stack seems to use (filling stack with value before using). I did check for 2 consecutive fill values before reporting the location of the fill value to determine stack usage... Last thing (for now) :) Where can I find specific info on the MPP file memory map, specifically local memory information? Do the local memory numbers indicate stack depth? It would be nice if the MPP file had an option to display system variables and info also... :( Steve Stover

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

Would you like a chip change then to accomodate this? Jack -----Original Message----- From: Johnson, Richard A <> To: 'BasicX List Server' <> Date: Tuesday, February 08, 2000 10:06 AM Subject: RE: [BasicX] Introduction and Questions >From: "Johnson, Richard A" <> > >Jack: > >I know that multiplies and divides by powers of two can be used for bit shifting however isn't that a significant perfomance hit since the AVR chip has bit shift instruction? > >Now if it is that VB does not have those operator then make them system function calls. Why does Netmedia continue to resist adding native mode shift commands to the Basic X system? > >Cheers... >Rich > >> ---------- >> From: Jack Schoof[SMTP:] >> Reply To: >> Sent: Tuesday, February 08, 2000 8:38 AM >> To: >> Subject: Re: [BasicX] Introduction and Questions >> >> From: "Jack Schoof" <> >> >> Inline assembly is impossible due to the fact that assembly can only be >> executed out of the internal AVR chips's flash. This flash can only be >> written after complete erasure which would remove the operating system. We >> only have a few bytes left in the flash anyway for our own use. >> >> Globals are allocated from low ram upwards. Then comes the stack which >> grows upwards. The stack includes local variables, task and subroutine >> frames, and temporary execution of expressions and arguments for subroutines >> and system calls. Since it is dynamic, it is hard to estimate usage - as it >> is on all processors. Since we have a few bytes of ram, it becomes >> necessary to employ memory saving options. >> >> Some of them are: >> Use globals when locals are not necessary >> limit the number of subroutine calls within subroutines - each call needs a >> frame and the local variables. >> since you have 32K of code space, you can sometimes spend code and save >> memory. >> >> Please see the new system calls like GetBit and PutBit (BX24 only right >> now) for bit variables. >> >> We will be coming out with a BX2 which is a BX1 (same pinout) minus the >> network and plus many of the new BX24 system calls (like GetBit). It will >> also be serially downloadable. It will also have more RAM (400 bytes) >> available internally and can accept external RAM up to the 128K like the >> BX1. >> >> I hope this helps, >> >> Jack >> >> -----Original Message----- >> From: Steve Stover <> >> To: <> >> Date: Tuesday, February 08, 2000 7:55 AM >> Subject: RE: [BasicX] Introduction and Questions >> >> >> >From: "Steve Stover" <> >> > >> >Hi Gordon, >> > >> >Thanks for the info! >> > >> >Inline assembly would allow bit shifts, enabling fast x2 and /2 operations, >> >as well as making it easier to use bits as Boolean flags instead of whole >> >bytes - a nice way to save precious RAM. I'm not really looking for >> >hardware register control as much as easy bit manipulation. >> > >> >I finally managed to download the link you gave, but didn't find any info >> on >> >actual compiler usage and organization of the RAM. There is a generic >> >memory map, but I'm looking for memory usage by the compiler. I figure if >> I >> >know where the stack is and how memory is organized, I'll have a much >> better >> >chance of catching stack overflow. So far I've noticed about 6 different >> >failure modes of stack overflow (I assume) in the program, but as of now I >> >have no theory for the failure mechanism of the most insidious ones... :( >> > >> >Thanks again for the info. >> >Steve Stover >> > >> >-----Original Message----- >> >From: Gordon McComb [mailto:] >> >Sent: Monday, February 07, 2000 1:30 PM >> >To: >> >Subject: Re: [BasicX] Introduction and Questions >> > >> >From: Gordon McComb <> >> > >> >At 12:26 PM 2/7/2000 -0600, you wrote: >> >>2) How much embedded RAM does the BX-01 actually have? I've seen 256 and >> >>512 bytes. The MPP map file seems to indicate 512. >> > >> >256 bytes, so say the specs. The Atmel 8515, upon which the BX-01 is based, >> >has 512 bytes of internal SRAM, but apparently the BasicX code consumes >> >about half of that. And of course, the BasicX code consumes all of the 8K> >> >of Flash that the 8515 offers. >> > >> >>3) Where does the kernel put the main program stack? Does the stack grow >> >up >> >>or down? Can stack size be specified? How does the kernel organize it's >> >>RAM in general? >> > >> >Download: >> > >> >http://www.atmel.com/atmel/acrobat/doc0841.pdf >> > >> >which is the architectural overview of the 8515. It explains the >> >program/data stacks, and how memory is used in the chip. >> > >> >>4) Is it possible to somehow embed assembly code within the BasicX code? >> I >> >>could definitely use SHL and SHR operations, among others. Basic has some >> >>real limitations for embedded hardware control, in my personal prejudiced >> >>opinion... :) >> > >> >Inline assembly code would be nice, but for the hardware side of things, >> >may not be absolutely necessary, since BasicX allows you to directly >> >manipulate the hardware registers of the chip, which is where most of the >> >action takes place anyway. The app note on using dual PWM (on the NetMedia >> >site) is just one example of directly controlling the registers, in this >> >case, the registers for the 16-bit Timer1. Of course, this doesn't mean >> >you can manipulate just *any* register. Timer0 appears to be used for the >> >real-time-clock, for example. >> > >> >-- Gordon >> > >> > >> >--------------------------- ONElist Sponsor ---------------------------- >> > >> >Want To Be Showered With Kisses? >> >Visit eGroups Valentine Gift Guide >> ><a href=" http://clickme.onelist.com/ad/SparksValentine9 ">Click Here</a> >> > >> >------------------------------------------------------------------------ >> > >> > >> >> >> --------------------------- ONElist Sponsor ---------------------------- >> >> Finding a sweetheart is hard work. Shopping for one shouldn't be. >> Click here for Valentine Surprises. >> <a href=" http://clickme.onelist.com/ad/SparksValentine5 ">Click Here</a> >> >> ------------------------------------------------------------------------ >> >> > >--------------------------- ONElist Sponsor ---------------------------- > >Valentine's Day Shopping Made Simple. ><a href=" http://clickme.onelist.com/ad/SparksValentine7 ">Click Here</a> > >------------------------------------------------------------------------

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

We do not publish the frame information, since we might change it in the future. When something gets out of memory, it could have problems in many different ways if it had happened in a expression, a subroutine call, a task, a system call.... each one could have different effects. The bottom line is to try to not run out of memory and then you dont have to worry about these effects. Jack -----Original Message----- From: Steve Stover <> To: <> Date: Tuesday, February 08, 2000 10:58 AM Subject: RE: [BasicX] Introduction and Questions >From: "Steve Stover" <> > >Jack S was kind enough to illuminate: > >-----Original Message----- > >From: "Jack Schoof" <> > ><snip> >Globals are allocated from low ram upwards. Then comes the stack which >grows upwards. The stack includes local variables, task and subroutine >frames, and temporary execution of expressions and arguments for subroutines >and system calls. Since it is dynamic, it is hard to estimate usage - as it >is on all processors. Since we have a few bytes of ram, it becomes >necessary to employ memory saving options. >I guess my $100,000 question right now is: what happens if the stack tries >to grow upwards past the end of RAM? Is any extra stack data lost? Does >the stack wrap back to low(est) memory, or to the start of global variables? >The different failure modes I've encountered don't seem to give a definitive >answer. If I know what happens I can look for specific first signs of >failure, instead of just noting catastrophic failure. > ><snip> > >What is included in a "subroutine frame"? Just a word return address, or >more than that (not including local variables)? > >Anyone know a good program for displaying call trees? > >I also tried to return the register stack pointers (to estimate stack usage) >in the call registers at different places in the program. I always got the >same values, despite differing call-tree depth. Maybe I must pass the >registers thru intermediate variables, instead of using the registers as >arguments in a subroutine call? > >A separate issue has been the second task stack. FYI This does seem to grow >upwards, and exceeding this stack will overwrite any variables after the >stack variable. I have further noted that proper stack operation seems to >require 6 bytes more than the stack seems to use (filling stack with value >before using). I did check for 2 consecutive fill values before reporting >the location of the fill value to determine stack usage... > >Last thing (for now) :) Where can I find specific info on the MPP file >memory map, specifically local memory information? Do the local memory >numbers indicate stack depth? It would be nice if the MPP file had an >option to display system variables and info also... :( > >Steve Stover >--------------------------- ONElist Sponsor ---------------------------- > >Don’t buy your Valentine a Gift by clicking here. ><a href=" http://clickme.onelist.com/ad/SparksValentine11 ">Click Here</a> > >------------------------------------------------------------------------

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

WADR, Jack, this is the kind or response I'd expect from MicroSoftSucks... -----Original Message----- From: "Jack Schoof" <> We do not publish the frame information, since we might change it in the future. I'm not necessarily asking for complete frame information, just how many bytes are pushed per subroutine call, not including local variables, of course. Exactly how often do you expect the OS call operation to change, anyway? Is the OS development is that immature and unstable? When something gets out of memory, it could have problems in many different ways if it had happened in a expression, a subroutine call, a task, a system call.... each one could have different effects. Understood. It's what I'm seeing. If I knew *HOW* the stack overflowed I could make an informed guess as to how and where the manifestation was likely to occur. If I knew the bytes pushed per subroutine I *could* manually find the max depth of the program call tree. The bottom line is to try to not run out of memory and then you don't have to worry about these effects. No shit, Sherlock! Let's see: I didn't seem to get reliable info out of the stack pointers. I can't get "frame information". There is no stack overflow checking. No published memory map of where the stack is located. No information on what the stack does when it overflows. I take it there is no emulator? Exactly how am I supposed to know I've running out of memory in the first place? I have seen the program return incomplete or invalid info without completely crashing. Can you (or someone) expound on the meaning of the local variables address scheme in the MPP memory map? I did not choose the CPU or operating system for this project. I certainly would not have chosen this setup for a real-time, embedded, RF power management and control system. But there is no time to change now. Can't add a RAM cause all the I/O pins are used up. Fortunately the erratic operation we've been chasing over the last 2 days has been hardware related... If I could somehow reasonably estimate the actual stack depth, I'd rather not go to the trouble of flattening the code. I'm aware of code packing techniques and stack operation - had to do it on E911 trunk multi-tasking firmware several years back. Ok, I'm done ranting. Back to the BasicX Mines. :) Guess I won't be able to use multiple tasks after all... :( Oops, today is time to draw pretty pictures in LABView... Everyone have a good day... Steve Stover

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

-----Original Message----- From: Steve Stover <> To: <> Date: Thursday, February 10, 2000 7:56 AM Subject: RE: [BasicX] Introduction and Questions >From: "Steve Stover" <> > >WADR, Jack, this is the kind or response I'd expect from MicroSoftSucks... Ouch, And then you want some help? >-----Original Message----- >From: "Jack Schoof" <> > >We do not publish the frame information, since we might change it in the >future. > >I'm not necessarily asking for complete frame information, just how many >bytes are pushed per subroutine call, not including local variables, of >course. Exactly how often do you expect the OS call operation to change, >anyway? Is the OS development is that immature and unstable? No it is dynamic. If we make a larger version of BasicX with 8 Megabytes of flash, then we might need a new scheme, or a smaller version with only 8K bytes of EEprom, we could make the frame larger or smaller to accomodate new processors. If people rely on the frame, then they could have problems. >When something gets out of memory, it could have problems in many different >ways if it had happened in a expression, a subroutine call, a task, a system >call.... each one could have different effects. > >Understood. It's what I'm seeing. If I knew *HOW* the stack overflowed I >could make an informed guess as to how and where the manifestation was >likely to occur. If I knew the bytes pushed per subroutine I *could* >manually find the max depth of the program call tree. You also need to know the biggest expression or values pushed on the stack too. f = (f + 3.14159) * f2 uses 8 bytes, 4 for each floating point number on the stack. call foo(a,b,c) where a,b,c are floats needs 12+9+(foo's local variables) just to get going. >The bottom line is to try to not run out of memory and then you don't have >to >worry about these effects. > >No shit, Sherlock! Let's see: I didn't seem to get reliable info out of >the stack pointers. I can't get "frame information". There is no stack >overflow checking. No published memory map of where the stack is located. >No information on what the stack does when it overflows. I take it there is >no emulator? Exactly how am I supposed to know I've running out of memory >in the first place? I have seen the program return incomplete or invalid >info without completely crashing. Can you (or someone) expound on the >meaning of the local variables address scheme in the MPP memory map? What I am getting at "Watson" is that coding techniques are available to allow very large programs to use very little ram. The entire BasicX operating system, basic language interpreter, multitasker, and floating point system use just 100 bytes in a BX24 and the network uses the rest in a BX01. I wish we had our BX02 ready for you which had 400 bytes free and had the same pinout as the BX1. It does not have the network. Do you use the network in your system? >I did not choose the CPU or operating system for this project. I certainly >would not have chosen this setup for a real-time, embedded, RF power >management and control system. But there is no time to change now. Can't >add a RAM cause all the I/O pins are used up. Fortunately the erratic >operation we've been chasing over the last 2 days has been hardware >related... Extended I/O allows you to have 128K of ram and lots of I/O - although you would need separate components like SPI or latches to provide the additional I/O. How many units are you going to make when you are done? We would be happy to help if possible. >If I could somehow reasonably estimate the actual stack depth, I'd rather >not go to the trouble of flattening the code. I'm aware of code packing >techniques and stack operation - had to do it on E911 trunk multi-tasking >firmware several years back. I hope that this information helps. >Ok, I'm done ranting. Back to the BasicX Mines. :) Guess I won't be >able to use multiple tasks after all... :( >Oops, today is time to draw pretty pictures in LABView... > >Everyone have a good day... >Steve Stover Toodles, Jack

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