Sign in

username:

password:



Not a member?

Search basicx



Search tips

Subscribe to basicx



basicx by Keywords

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

Ads

Discussion Groups

Discussion Groups | BasicX | Re: BasicX Commands

Discussion forum for the BasicX family of microcontroller chips.

Multi-tasking stack size.... - airmaledfw - May 26 17:43:00 2003

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





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


Re: Multi-tasking stack size.... - Frank Manning - May 27 13:19:00 2003

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.





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

Re: Multi-tasking stack size.... - airmaledfw - May 27 13:56:00 2003


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.




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

Re: Re: Multi-tasking stack size.... - Frank Manning - May 27 14:46:00 2003

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.





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

BasicX Commands - Raymond Irving - May 27 15:35:00 2003

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
__________________________________






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

Re: BasicX Commands - Trevor Pinkney - May 27 19:43:00 2003

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 >
>__________________________________





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

Re: BasicX Commands - Frank Manning - May 31 12:09:00 2003

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.




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