Question regarding spin2

pilot0315 · 2021-01-13 21:28

@cgracey

Am I missing something really simple or is this a bug?
I am using the new propeller tool with the p2.
I ran the hello blinky code and it ran fine.
I used it for a base line for toggling some pins worked fine.
Copied and pasted to a new page and keep getting this error:
Unrecognized character

It is a simple copy and paste. Commented out those lines and nothing works at all either.
Thanks

Kaio · 2021-01-13 22:32

pilot0315 wrote: »

Am I missing something really simple or is this a bug?
I am using the new propeller tool with the p2.

The debug feature is currently not implemented in the Propeller Tool, but it will be soon available. Until then please use PNut if you want to use debug. It is currently only working there.
You'll find the recent version here.

DigitalBob · 2021-01-13 22:49

Your program works, but for the F12 serial debug you can use the Jonny Mac serial that's in my Simple Blinky

pilot0315 · 2021-01-14 19:55

@cgracey
@DigitalBob
@Kaio
I was using the blink program that came in the examples of the new propeller tool.
All I did was copy and paste and rename. This is where the error is.
I copied and pasted the hdmi and gave it a new name. Got this error.
This is the same thing I did with the blink. Still getting errors.
Same error in pnut.
Thanks

Rayman · 2021-01-14 21:15

It looks to me like the Prop Tool has you in P1 mode...

There must be a PUB routine in P1 mode.

Maybe rename file extension to .Spin2, close it, then reopen...

pilot0315 · 2021-01-14 22:02

I will look.
Is there a setting to change??

pilot0315 · 2021-01-14 22:06

@Rayman

THAT DID THE TRICK!

Did not notice the drop down that chooses p1 or p2

Thanks

JonnyMac · 2021-01-14 23:19

Did not notice the drop down that chooses p1 or p2

We all bump into that. Long term, I'm hoping that Propeller Tool can sense the target through special comment tags, {$P1} or { $P2} -- this strategy is used in the BASIC Stamp editor.

msrobots · 2021-01-18 08:08

I think the file extension is good enough, why clutter code with stuff like that.

'.spin' is spin 1 and '.spin2' is spin 2?

confused,

Mike

JonnyMac · 2021-01-18 10:08

I think the file extension is good enough, why clutter code with stuff like that.

It allows the compiler to identify the code without needing to be saved (like when using Spin1). It can also help the save dialog by selecting the correct file type automatically. I have had many frustrating moments when I save a file and it gets .spin attached instead of .spin2 because I neglected to specify the file type.

As you've noted many times, I keep my files neat and tidy; adding a small comment tag in my header does not clutter the code.

ersmith · 2021-01-18 10:22

msrobots wrote: »

I think the file extension is good enough, why clutter code with stuff like that.

'.spin' is spin 1 and '.spin2' is spin 2?

In FlexProp, at least, the choice of language is independent of the choice of processor. That's not true of the PropTool yet, but perhaps some day it could be. A comment tag to indicate processor would be useful. It may also allow us to distinguish between different versions of the P2, if any of those exist some day (I suppose for now Rev A versus Rev B/C).

Kaio · 2021-01-18 15:36

ersmith wrote: »

In FlexProp, at least, the choice of language is independent of the choice of processor. That's not true of the PropTool yet, but perhaps some day it could be.

I appreciate your work regarding FlexProp. But this is one of the features I don't like.

It makes porting code back to PropTool difficult if one can mix e.g. the Spin operators of P1 and P2 in the same code. This is also hard to see for one who believe to use the code for P2 and don't have experience with P1, that one must have to check the documentation for the P1 too to figure out what's going on.

As FlexProp does support the #if-directive and the PropTool not, it would be more useful if one would use it to differentiate parts of code to the related Propeller. So, it would be clear to see the difference of coding between P1 and P2 for everybody.

ersmith · 2021-01-18 16:41

Kaio wrote: »

I appreciate your work regarding FlexProp. But this is one of the features I don't like.

It makes porting code back to PropTool difficult if one can mix e.g. the Spin operators of P1 and P2 in the same code.

The "Spin operators of P2" are really "Spin 2 operators", they don't have to "belong" to the P2. The P1 can implement most of those operators just fine. Similarly the Spin1 operators can be implemented for P2.

There are two reasons I seperated language and processor:

(1) Logical: there's no reason that Spin2 (the language) cannot run on P1, and the new language features like the SEND operator are nice for P1 users. The exception is some of the built in functions for smart pins, of course, but the language structure itself is platform independent.

(2) Practical: it's very useful to be able to compile legacy Spin1 code for the P2. I think the lack of backwards compatibility with Spin1 is the biggest flaw in Spin2 (which is otherwise a very nice extension to Spin1).

There is a warning you can enable to show when you use FlexProp extensions for Spin. That doesn't cover everything yet, but it will help with making sure code in a .spin2 file can compile with P2 PNut.

That said, I really like @JonnyMac 's suggestion of comment tags like {$P1} and {$P2} to mark files that are processor dependent. This would help to sort out portability -- some Spin2 code is generic and can work on both processors, but some relies on P2 specific features like the smart pins.

I really hope Parallax will add a preprocessor to PropTool as well, since having #ifdef would make a lot of things easier.

JonnyMac · 2021-01-18 16:47

When the BASIC Stamp family expanded from the BS1 to the BS2, and later to derivatives of the BS2 (e, sx, p), the type tag and preprocessing were added. As Jeff has done that once, I hope he'll do it again. It would be nice to do conditional compilation with the Propeller like we can with the BASIC Stamp.

Cluso99 · 2021-01-19 01:49

IMHO PropTool really needs to support #INCLUDE and the #IFDEF conditional compilation. These should have been supported for P1 for at least the past 10 years! That's why bst and homespun were written. At least we have FlexProp thanks to Eric.

Ken Gracey · 2021-01-19 03:38

According to a discussion with @"Jeff Martin" this morning, we could have the debug features implemented in Propeller Tool as early as February 1st. We have several customers (and a few big educational ones) depending on the addition. So, we're pressing to get it done.

Ken Gracey

jrullan · 2021-01-19 04:32

Ken Gracey wrote: »

According to a discussion with @"Jeff Martin" this morning, we could have the debug features implemented in Propeller Tool as early as February 1st. We have several customers (and a few big educational ones) depending on the addition. So, we're pressing to get it done.

Ken Gracey

These are excellent news specially for people like me new to the P2! The debug features are really impressive, but Pnut is not adequate for novices IMHO.

Cluso99 · 2021-01-19 05:24

jrullan wrote: »

Ken Gracey wrote: »

According to a discussion with @"Jeff Martin" this morning, we could have the debug features implemented in Propeller Tool as early as February 1st. We have several customers (and a few big educational ones) depending on the addition. So, we're pressing to get it done.

Ken Gracey

These are excellent news specially for people like me new to the P2! The debug features are really impressive, but Pnut is not adequate for novices IMHO.

pnut was never meant to be for novices. It is the cutting edge for the experienced to get a preview into the P2, and to develop techniques before adding to PropTool.

Question regarding spin2

Comments