Starting New Cogs and FullDuplexSerial.spin

NickMikhay

Hello,
I am attempting to write a program which uses the FullDuplexSerial.Spin object.
When I view the info for my top spin file, or top object if I can call it that, the clock mode is configured for Crystsal and multiplier. However, looking into the child objects I see that the clock mode defaults to RC at 12 Mhz.

There is also no stack space.
I am assuming that the child objects will inherit the clock setting from the parent. Is this correct?
As far as the stack I realize that I would have to set that in the child object with a global variable to point into main program memory. But
The immediate question is whether the fullduplexserial.spin needs stack space, since it is written mostly in assembly, I presume no.

JonnyMac

Most serial drivers, including FullDuplexSerial.spin, read the system clock frequency to set the bit rate. Look for this line in the start() method.

  bit_ticks := clkfreq / baudrate

The clkfreq value is based on the parent app settings that control the system clock.

I am assuming that the child objects will inherit the clock setting from the parent. Is this correct?

Yes. See clkfreq.

...question is whether the fullduplexserial.spin needs stack space...

As you correctly surmised, PASM cogs do not need a declared stack. A Spin cog, on the other hand, does.

evanh

When an object file is brought in using the OBJ section then those special clock mode constants , eg: _XTLFREQ and _CLKFREQ, inside that object file are ignored. Those constants only function when that object file is compiled as the top/first source file.

So, as Jon says, objects like FullDuplexSerial.Spin will use the runtime system variable clkfreq.

PS: There is another pair of compile time constants that the compiler itself generates. They are CLKFREQ_ and CLKMODE_. These contain the resolved compile time frequency and mode that the compiler actually sets at startup. As opposed to what was declared by the source code. These can be referenced at runtime in any object and even if there wasn't any declared mode. Since they provide both the board's XI/XO config and derived crystal frequency, this allows to correctly set the clock to a new frequency at runtime. Err: This point only applies to Spin2. Sorry, had missed this being in the Spin1 forum.