Discussion forum for the BasicX family of microcontroller chips.
|
Thanks to a posting I came across by dan bielecki (msg 7510), I quickly shaved 100 bytes off my ram useage by not submitting Sub Main () to just sleeping while running other tasks. In the process, his enlightening suggestion has posed questions. I thought I understood the reasoning behind guesstimating stack size for multi-tasks. I've seen the results of inadequate stack size in my programs and have seen postings regarding methods used to determine one's stack usage for tasks. Now, here is my ponderance... If I have three tasks started in Sub Main() and have allocated three stack areas for them... there are actually 4 tasks. Sub Main() is a task as well yet I don't have to set any stack size for it. The compiler determines the stack size for Sub Main() and adjusts this as code is added / removed from it. I have no control over the stack size of Sub Main() so I couldn't adjust this if I wanted to. My simple question is this.... since Sub Main() is a task, and the compiler creates (and adjusts) it's stack size accordingly... why is it more difficult for the compiler to do the same for tasks 2, 3 and 4? :-) TIA |
|
|
|
From: airmaledfw <> > [...] > If I have three tasks started in Sub Main() and have > allocated three stack areas for them... there are > actually 4 tasks. True. > Sub Main() is a task as well yet I don't have to set > any stack size for it. The compiler determines the > stack size for Sub Main() and adjusts this as code > is added / removed from it. It's true the compiler automatically allocates a stack for Main. But all the compiler does is allocate to Main whatever RAM is left over from static variables, including global variables. As an example, if you have 64 KB RAM, and you declare 10 KB worth of static variables, that leaves 54 KB left over. The compiler treats the 54 KB as the stack for Main. > I have no control over the stack size of Sub Main() > so I couldn't adjust this if I wanted to. It's true you can't adjust Main's stack size explicitly, the way you do with other tasks. But you do have implicit control, and you can check the MPP file to see what the compiler is using as the main stack size. > My simple question is this.... since Sub Main() is a > task, and the compiler creates (and adjusts) it's > stack size accordingly... why is it more difficult > for the compiler to do the same for tasks 2, 3 and 4? Good question. I can see where you might want to explicitly set the stack size for Main, and have the compiler check to make sure enough RAM is available. We may add that option in the future. -- Frank Manning -- NetMedia, Inc. |
|
|
|
Oh... my point "was" more like this. Since the compiler creates stack space for Sub Main()... then it should be able to create stack space for tasks 2, 3 & 4. What I didn't know is that Sub Main() is just getting what's leftover. This might not necessarrily the stack size Sub Main() needs for proper operation. The compiler isn't really doing a check like... "here's the required stack size needed for Sub Main() so here's what it gets"... it is just getting the leftover space from what's been previously declared. Thanks for your clarification --- In , "Frank Manning" <fmanning@n...> wrote: > From: airmaledfw <airmaledfw@h...> > > > [...] > > If I have three tasks started in Sub Main() and have > > allocated three stack areas for them... there are > > actually 4 tasks. > > True. > > > Sub Main() is a task as well yet I don't have to set > > any stack size for it. The compiler determines the > > stack size for Sub Main() and adjusts this as code > > is added / removed from it. > > It's true the compiler automatically allocates a stack for Main. > But all the compiler does is allocate to Main whatever RAM is left > over from static variables, including global variables. > > As an example, if you have 64 KB RAM, and you declare 10 KB worth > of static variables, that leaves 54 KB left over. The compiler > treats the 54 KB as the stack for Main. > > > I have no control over the stack size of Sub Main() > > so I couldn't adjust this if I wanted to. > > It's true you can't adjust Main's stack size explicitly, the way > you do with other tasks. But you do have implicit control, and you > can check the MPP file to see what the compiler is using as the > main stack size. > > > My simple question is this.... since Sub Main() is a > > task, and the compiler creates (and adjusts) it's > > stack size accordingly... why is it more difficult > > for the compiler to do the same for tasks 2, 3 and 4? > > Good question. I can see where you might want to explicitly set > the stack size for Main, and have the compiler check to make sure > enough RAM is available. We may add that option in the future. > > -- Frank Manning > -- NetMedia, Inc. |
|
From: airmaledfw <> > [...] > Oh... my point "was" more like this. Since the > compiler creates stack space for Sub Main()... > then it should be able to create stack space for > tasks 2, 3 & 4. Yes, I can see that now -- I should have done a better job reading your message. I agree it would be useful to have a compiler option where stack space is automatically allocated for every task. Sometimes this may be more convenient than explicitly allocating space yourself. > What I didn't know is that Sub Main() is just getting > what's leftover. This might not necessarrily the > stack size Sub Main() needs for proper operation. > The compiler isn't really doing a check like... > "here's the required stack size needed for Sub > Main() so here's what it gets"... it is just getting > the leftover space from what's been previously declared. True, but in general the compiler has no way of knowing how much memory a given task requires. About the best the compiler can do is divide the available RAM by the number of tasks, and allocate RAM that way, assuming you want to delegate that job to the compiler. -- Frank Manning -- NetMedia, Inc. |
|
|
|
Hello, Does the BasicX have any inline functions to do the follow: 1) Read character from a PS/2 keyboard eg. char = KeyIn(clkPin,dataPin) 2) Read X/Y values from a PS/2 Mouse eg. Dim m(2) as Byte m = MouseIn(dataPin) 2) Read 1-Wire devices or simply reads the serial number eg. Dim sn(14) sn = ReadOWSN(pin) 'Read-One-Wire-Serial-Number I've found a little MCU (PICAXE) that can do the above, but I was thinking if this little MCU can do the such things then BasicX should be more than capable of performing the above, correct? Does it have such functions? Any plans to implement such functions/modules? Also... How about supporting custom classs objects? ' class module Class MyClass public MyProperty as String Public MyFunction() as String 'some code here End Function End Class Sub Main Dim cls as New MyClass cls.MyProperty = 'Hello' Call cls.MyFunction() End Main -- Raymond Irving __________________________________ |
|
|
|
Hi, Object Oriented microprocessor code would be awesome... BUT - The problem is that objects would have too much overhead. you only have 400 bytes ram on the basicx. Someday C# will be available for microcontrollers I'm sure and that will be cool. -Trevor At 01:35 PM 5/27/2003 -0700, you wrote: >Hello, > >Does the BasicX have any inline functions to do the >follow: > >1) Read character from a PS/2 keyboard > eg. char = KeyIn(clkPin,dataPin) > >2) Read X/Y values from a PS/2 Mouse > eg. > Dim m(2) as Byte > m = MouseIn(dataPin) > >2) Read 1-Wire devices or simply reads the serial >number > > eg. > Dim sn(14) > sn = ReadOWSN(pin) 'Read-One-Wire-Serial-Number > >I've found a little MCU (PICAXE) that can do the >above, but I was thinking if this little MCU can do >the such things then BasicX should be more than >capable of performing the above, correct? Does it have >such functions? Any plans to implement such >functions/modules? > >Also... How about supporting custom classs objects? > >' class module >Class MyClass > public MyProperty as String > Public MyFunction() as String > 'some code here > End Function >End Class > >Sub Main > Dim cls as New MyClass > > cls.MyProperty = 'Hello' > Call cls.MyFunction() >End Main > >-- >Raymond Irving > >__________________________________ |
|
From: Trevor Pinkney <> > Raymond Irving wrote: >> >> [...] >>Also... How about supporting custom classs objects? >> >>' class module >>Class MyClass >> public MyProperty as String >> Public MyFunction() as String >> 'some code here >> End Function >>End Class >> [...] > > Object Oriented microprocessor code would be awesome... > BUT - The problem is that objects would have too much > overhead. you only have 400 bytes ram on the basicx. > [...] Or 64 KB. It's true that OO overhead is a problem if you want to implement a full-blown JVM or VB.NET environment, or the equivalent. A lot depends on how you define OO. Although BasicX doesn't allow you to write your own classes, it does implement system-defined block data classes, including parameterized constructors, and the modular structure of the language makes it easy to write Abstract Data Types (ADT), which are central to OO: http://www.instantweb.com/foldoc/foldoc.cgi?data+abstraction A significant amount of example code in BasicX application notes is written in ADT style, and a number of modules can in fact be converted to full-blown VB classes with only minor changes to source code. Examples from the V2.1 IDE: Accelerometer Capture Driver74HCT259 FlushSerialPort GPSDriver GPSSerialPort GPSVelocityDecoder IMux74HCT251 LCD2x16API LCDSerialPort LowPower SerialPort Timer1 As an example, to change Accelerometer.bas to a VB6 class, you would change the filename to *.cls, and add about 13 lines of header boilerplate. The VB6 IDE automatically adds the header, which is normally invisible to the programmer, so it might be argued that no change to the source is actually needed. I'm not as familiar with VB.NET, but I believe the same file requires only the addition of Class/End Class statements. Other files would require additional modifications because of language changes between VB6 and VB.NET, and public constants would need to be moved elsewhere, since they're not allowed in class declarations. But the overall structures wouldn't change. So the core ADT structure is already available and easy to use in BasicX. Although OO is more than ADTs, they are a big part of OO, and a properly written BasicX ADT can be nearly identical to a corresponding VB6 or VB.NET class. While we're on the subject, one thing that beginners sometimes have trouble with is the difference between "public" and "private" keywords. The difference is crucial to writing an ADT. Typically you store the internal state of an ADT in variables hidden or encapsulated in the ADT. In BasicX (and VB) the usual mechanism for doing this is to make the variables private. An outsider can access the variables only indirectly, through subprogram calls, which are public. Data hiding and all that. In the accelerometer example, "period" is an example of a hidden variable. Period is private to the module, and represents the inverse frequency of the pulses generated by the ADXL202 accelerometer. Within the module, procedure GetPeriod has write access, and procedure GetAccelerations has read access. Both procedures are public in this case. No code outside the module has direct access to period. One reason for this restriction is to prevent illegal values from being assigned to the variable. -- Frank Manning -- NetMedia, Inc. |