Spin to Spin2 for pnut
kg1
Posts: 164
in Propeller 2
Please help me convert:
data := data <- 8 ' puts the 8MSB to the 8LSB
data := ~data ' extend sign
data := data <- 8 ' puts the 8MSB to the 8LSB
data := ~data ' extend sign
Comments
Edit: Fixed typo sognx to signx
I am unable to find: sognx in any of these:
Parallax Spin2 Documentation v34m.odt
Parallax Propeller 2 Instructions v33 - Rev B Silicon.ods
spin2_interpreter.spin2
Is it spelt correctly?
Should be SIGNX
Parallax Spin2 Documentation v34m.odt current version Spin2 Language Documentation 2020-04-07 v34Q
spin2_interpreter.spin2 from PNut_v34Q.zip
Parallax Propeller 2 Instructions v33 - Rev B Silicon.ods (Chip's spreadsheet)
However I am a beginner with SPIN and SPIN2 and PASM so my knowledge is limited.
I have converted ADXL345ObjectDemo_-_Archive__Date_2010.02.05__Time_20.48.zip by Andrew Colwell from OBEX.
I am using jm_serial.spin2 and jm_nstrings.spin2 and jm_i2c.spin2 hence it is not a simple SPIN to SPIN2 conversion but an exercise applying your excellent code.
Many thanks Jon.
Kevin.
I'm hoping that someone is is really good at a language like Python creates a utility that can ingest a P1 program and spit out P2 code -- even if the P2 code requires some touch-up. Some things are easy: keyword and operator changes, though some operators have behavior changes that have to be dealt with, and then, of course, there's the issue of having a return value in a method where the return value is not specified on the method definition line. I think the last bit, that of having to read an entire method to see if "return value" exists and then touch-up the previous definition line is the trickiest. Still, I may give it a go. I'm trying to get better at Python and this is a good excuse for practice.
Yesterday I was pondering (dreaming?) about the possibility of Parallax writing a conversion tool for P1 to P2 code. The OBEX system seems to have come to a standstill. I agree with you that there are some parts of SPIN that would be difficult to automatically convert but isn't this OBEX code sharing facility important for the future growth of the Parallax user base?
I have never written code in Python but I was enthused by your " I may give it a go" to the idea of creating a conversion tool in python. However you would need a timeline with an end date (i.e. a give up date). And unless you are about to retire the future support of such a tool may not give you much pleasure.
A preliminary goal may be to create a "P2 Core library" where a collection of generic objects (not hardware specific) are provided. This would be a continuation of the work you have already done e.g. jm_serial.spin2, jm_nstrings.spin2 and jm_i2c.spin2 as objects for serial, print, i2c etc.
These objects could then be used to speed up the manual process of conversion from SPIN to SPIN2 + PASM.
Next could be a table of SPIN keywords and syntax to SPIN2 or PASM snippets.
Later a team of users could be enticed to convert the 50 most popular examples in OBEX to SPIN2.
I could not have converted ADXL345ObjectDemo without your SPIN2 objects!
Your work is much appreciated.
Kevin.
If you want to compile Spin 1 objects for P2 there is a tool for that already. It just isn't an offical Parallax tool.
Kg1, give Eric's FastSpin a try. You can compile original Spin code with it.
I am a follower of the C programming language. I have looked at Catalina, FlexGUI version 4.1.3 and spin2cpp which are a tribute to their creators. However we all feel a little sad for their situation. If you were willing and able to rewrite PNut in C code and make it open source then the future would seem much brighter.
I have explained before that I am inferior in expressing myself in words. I hope that my effort here is accepted in the light of my limited talent.
Kevin.
It works by renaming PST to something else, and substituting the new executable as "PST" which the propeller tool calls when you hit F12. The new executable can in turn call the original PST terminal. The net result is just that you've inserted the new executable in the tool chain.
The new executable could easily do some P1 to P2 conversion, for things such as
- hub clock setup
- reformatting p1 code into p2 format
- perhaps some counter to smartpin conversion for common modes
- calling a compiler with the modified code
- loading the P2
- calling PST if compilation successful, or dropping out and returning to propeller tool if not
I haven't mentioned it because we hace Flexgui, and I know Jeff is working on the Propeller Tool side of things, so we'll soon have something better. But the above scheme is certainly possible and could be done now. I've read the comments you make at the end of each successful P1 to P2 conversion Jon, as these are the things that would need to be included in the automated translation. So far I haven't seen any showstoppers.
The hard bit from a user perspective would be remembering to press F12 instead of F10. But for people who are used to and like PropellerIDE this could retain that comfort
@Tubular Do you believe this is easily achieved with automated systems (no manual changes to the generated code) ?
Kevin.
http://forums.parallax.com/discussion/169259/spinedit-editor-for-spin-spin2-and-fastbasic/p4
Not as nice as Prop Tool, but has P2 syntax and can now compile with PNut...
That may be possible, but I would never trust such a program. When I look at the output Spin to C translators I often find my head shaking with confusion. To be fair, Spin1 to Spin2 is a smaller move, except on the PASM side -- that's going to be tricky. As Wuerfel_21 pointed out, some features in the P1 have dramatically changed; counters, for example. In the P1 I used a counter in a loop in its own cog to drive 8 servos. Now I don't need the loop (unless I need auto ramping), because any pin can be configured as a simple, stand-alone servo driver.
I doubt you can ever get to no manual changes.
As an example I had P1 code that modified a jmp instruction for fast instruction emulation. On the P2 the location of the address within the instruction word is different and thus required additional shift instructions. Without knowledge of what outcome is desired it's very difficult to convert code like this.
Another example would be that the movs, movd, etc. ("mov...") instructions have been replaced with set... or alt... instructions. If you replace a mov... instruction with a set... instruction you may have to insert an additional nop since you now need 2 instruction cycles due to pipelining. Ideally you could use alt... instructions instead but they must immediately precede the target instruction... which could mean moving instructions. In the first case you might run out of cog space and in both cases you might cause routines to malfunction.
Finally, how do you handle code for drivers such as I2C since much of this code is hand-tuned for performance and may run too fast (I've had this issue already).
There may be ways to automate these fixes. But someone would have to spend quite a bit of time doing so.
All 3 of these issues are issues that I've already run into converting to P2 code. By no means is this list complete!
Walter
Accepting that it is highly unlikely that we will ever see an automatic conversion tool for converting code from P1 to code for P2, please outline how you would carry out the conversion of OBEX code to code for P2.
Will someone write a complete book on how to do this?
I believe this book needs a group of P2 users all contributing via a common tool. A forum does not qualify.
Do you think providing P2 knowledge scattered throughout a forum for 10+ years is the answer?
Is the next step providing P2 in Schools?
Before this there needs to be a migration of P1 followers to becoming P2 followers.
P2 code examples....
I am most interested in your point of view,
Kevin.
We're way out front on this. We can either do the conversions ourselves, or wait on someone else. I don't like waiting.
Will Chip complete this on his own?
When will Parallax begin to attract P1 users to being P2 users?
Will P2 ever be used by schools?
Kevin.
As for P1 users moving to the P2, I suspect it will happen. I have two existing clients and one potential new client that are all interested in moving their products to the P2.
Ken has been amazing working with schools, so I suspect the education answer is yes, especially with the P2 able to run microPython.
You have a P2, right? Why not dig in and experiment versus worrying about things that you cannot control? There a many members here that will help -- we'll all learn together and anything that we do will help Parallax attack new users.
There are other things we can do, if we want. I have submitted an article on the P2 to Nuts & Volts magazine that is supposed to appear in their next issue. It's kind of an intro article and gets into some of the neat things one can do with Spin2 and smart pins. It's a start. In the end, it will take time to compete with the number of libraries available for the Arduino, but that happens by writing one library at a time.
Thank you for your comments Jon.
Regards,
Kevin.
Hi Kevin
There is a spectrum of what is easy through to what is likely difficult. Like others I believe a fully automated tool would be difficult, but it could provide a useful start and reduce the pain of adoption
I'm just a hobbyist, and certainly not an expert on the P1, much less the P2. I have a couple of P1 obex objects that I provided. Both involve hardware that I no longer have access to, so updating them would be difficult (although if someone is interested in the temperature sensor object being updated and has a sensor they could send to me for testing, I'd be willing to update it).
There was a movement a few years ago for "gold" objects or the like in the obex. That would be ideal. But... the P2 is so new, and has so many new features, that it seems like every time I read the manual (or look at @JonnyMac's code, thanks for your useful comments) I get ideas on how to do something faster/better. So what might be "gold" today could be "pot metal" tomorrow.
Also, there is a lot of obex code that may be obsolete (devices no longer available, etc.). If there was some way to mark that someone wanted an particular object converted to P2, maybe even with a ranking system, then someone might be able to do said conversion.
I do suspect that someone will want to create objects for easier manipulation of new features such as smart pins. For one, I'd like to see routines to keep the clock periods, etc. as close to a specified value as possible even with (reasonable) changes in the system clock rate.
To get to your point, we do need a "tips & tricks" document, not just individual forum posts. Could someone please set up a google doc for this purpose? And how about another one with a section for each instruction - even if nothing but headers - so that we can start to document all of these new instructions?
@cgracey is doing his best (when I'm not sending him down rabbit holes for nonexistent bugs) to get the tools working and to update the documentation. Maybe we forum members can step up and help in some way?
Finally figured out that I had to update the displays much slower (4x) than I thought I could. Oh well.