Is there any way to declare a method for universal use?

evanh

As in like adding to the built-in methods of the language. eg: Alongside waitcnt() also adding a waitms() that can then be used by all objects in the project.

avsa242

I don't think so, though you could get kinda close by putting the methods in a file and #include'ing it any object you wanted to use them in (needs FlexSpin of course). A little manual, but it wouldn't have the child object syntax, or whatever memory overhead declaring a child object would.

JonnyMac

In the P1, I tend to have a support cog that runs a loop at 1ms and updates a timer variable called millis. In order to share this across cogs, you'd have to pass a pointer to that variable. For simple delays, I have an object called time that includes a pause() method.

Phil Pilgrim (PhiPi)

You could declare a PUB method in a separate wait object and name it ms. Then do this everywhere you want to use it:

OBJ

  wait: "wait"

Then you can use it like this:

wait.ms(milliseconds)

Is that equivalent to what you want to accomplish?

-Phil

evanh

@"Phil Pilgrim (PhiPi)" said:
You could declare a PUB method in a separate wait object and name it ms. Then do this everywhere you want to use it:

OBJ

  wait: "wait"

Then you can use it like this:

wait.ms(milliseconds)

Is that equivalent to what you want to accomplish?

-Phil

The problem is, to make the wait.ms() method visible in other objects alongside of the "wait" object, it seems to also require having another wait object within each of the other object instances as well as the top level one.

Whereas I can use waitcnt() at any level without growing extra code duplication of its workings.

evanh

Jon,
The wait()ing is just an example. I want to have many more universally shared methods. Ones that can be used across all objects without having extra instances. This would put restrictions on what such methods could do. Namely only use other universal resources.

avsa242,
Yeah, thanks, I almost listed #include myself but thought I'd wait for suggestions before muddying the conversation with what is basically "don't make any objects of your own". I'll experiment down this path I think.

evanh

The one that has smacked me right now is an equivalent to Spin2's debug(). Using PST is a poor equivalent not just for the string formatting but also for accessibility from multiple objects. It can't without also having multiple comports as well.

Thinking about a solution, I guess there would have to be a client/server arrangement. Where each object to be debug()ed would have it's own client debug sub-object that would connect to the comms server cog.

PS: But I won't be attempting this. #include will do for the moment.

Phil Pilgrim (PhiPi)

The problem is, to make the wait.ms() method visible in other objects alongside of the "wait" object, it seems to also require having another wait object within each of the other object instances as well as the top level one.

The code doesn't get duplicated. Only the object's VAR variables do.

-Phil

evanh

@"Phil Pilgrim (PhiPi)" said:
The code doesn't get duplicated. Only the object's VAR variables do.

Cool! Thanks, that solves my concern with simple methods. Which I guess accounts for most of it.

Any solutions for generalised diagnostic printing? Like Spin2's debug().

JaanDoh

I was under the impression that Dave Hein's Method Pointer object does just that?

https://forums.parallax.com/discussion/128397/callbacks-and-method-pointers-in-spin

evanh

Wow, the time machine.
Looks like just what I wanted alright. Notably Dave has chosen FullDuplexSerial.spin to demonstrate with.

evanh

Uh-oh, reading the descriptions in the MethodPointer sources it looks like it relies on specific compiled offsets to both caller and callee internal data structures. I'm guessing that'll fail badly with FlexSpin ...

EDIT: Right, PropTool 2.6 is good, not surprisingly. Flexspin with and without --interp=rom both fail. Bstc also fails but Openspin seems fine.

Wuerfel_21

Flexspin has Spin2-style method pointers. In bytecode mode, the implementation is rather similar to the ol' MethodPointer object, except less of a hack since the interpreter internal registers are accessible directly (__interp_pcurr and friends). Annoyingly, it kindof necessarily has to pull in the heap allocator as of right now, which is a bit less-than-ideal.

evanh

@Wuerfel_21 said:
Flexspin has Spin2-style method pointers.

What, so there is a way to do this built into Flexspin, targetting Prop1? Me goes looking for docs on mysterious method pointers ...

ersmith

@evanh said:

@"Phil Pilgrim (PhiPi)" said:
The code doesn't get duplicated. Only the object's VAR variables do.

Cool! Thanks, that solves my concern with simple methods. Which I guess accounts for most of it.

Any solutions for generalised diagnostic printing? Like Spin2's debug().

With flexspin you can compile Spin2 code for P1. There are some obvious restrictions (the smart pin methods won't work on P1, and the PASM has to be P1 PASM not P2) but processor independent things like method pointers and DEBUG() will generally work fine.

evanh

Holy cow! How? Just name the source files with .spin2, maybe?

ersmith

@evanh said:
Holy cow! How? Just name the source files with .spin2, maybe?

Yes. As far as flexspin is concerned, .spin2 files indicate a variant (Spin2) of the Spin language, just as .cpp files indicate a variant (C++) of the C language. The processor choice is solely determined by the presence or absence of the -2 flag to indicate compilation for P2.

evanh

Gotta try that tomorrow. Thanks.