Spin to Spin2 for pnut

Please help me convert:
data := data <- 8 ' puts the 8MSB to the 8LSB
data := ~data ' extend sign
«13

Comments

  • ozpropdevozpropdev Posts: 2,688
    edited 2020-04-09 - 03:52:47
    Try this
    data := data rol 8 ' puts the 8MSB to the 8LSB
    data :=  data signx 7 ' extend sign
    

    Edit: Fixed typo sognx to signx
  • Thank you ozpropdev.
  • Hi ozpropdev,
    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?
  • Oops!
    Should be SIGNX
  • That's good thanks
  • I don't remember where, but Chip made a chart of P2 operators. I added P1 operators to shortened version of it for reference as I'm porting P1 to P2.
  • The operator list is in the documentation in the top post of the thread about the latest version of PNut.
  • @JonnyMac Thank you Jon for your file. I use the current versions of:
    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 glad you're finding the code useful, Kevin. I really need to set a GIT repository so that I can keep my updates in public place. As I'm settling in to Spin2 I and constantly going back and refining.

    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.
  • Hi Jon, @JonnyMac
    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.
  • kg1 wrote: »
    Yesterday I was pondering (dreaming?) about the possibility of Parallax writing a conversion tool for P1 to P2 code.
    I hate to say it, but: Parallax has pretty clearly expressed by their actions just how little they care about Spin compatibility between P1 and P2. So I wouldn't hold my breath for such a tool coming from them.

    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.



  • I think the majority of shared P1 objects can't be translated to P2 automatically, anyways - They use counters, P1 ROM data or PASM code.
  • ersmith wrote: »
    kg1 wrote: »
    Yesterday I was pondering (dreaming?) about the possibility of Parallax writing a conversion tool for P1 to P2 code.
    I hate to say it, but: Parallax has pretty clearly expressed by their actions just how little they care about Spin compatibility between P1 and P2. So I wouldn't hold my breath for such a tool coming from them.

    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.
  • @cgracey Hi Chip,
    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.
  • JonnyMacJonnyMac Posts: 6,661
    edited 2020-04-10 - 00:39:31
    Yesterday I was pondering (dreaming?) about the possibility of Parallax writing a conversion tool for P1 to P2 code.
    In my opinion, that's something best done by someone in the community as a small "thank you" for the P2. Honestly, how many other manufactures would allow so much input to the product development process? Since it is new and unique, I would rather that Chip focus on getting the Spin2 interpreter ported to C so that it can be compiled on any OS, and then create a really nice library of objects that 1) help people get up and running, and 2) show people how to take advantage of the P2.
  • TubularTubular Posts: 3,955
    edited 2020-04-10 - 03:33:39
    I did some experimenting (proof of concept) with inserting a small executable that could be invoked when you press F12 from Propeller tool.

    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
  • @JonnyMac
    I would rather that Chip focus on getting the Spin2 interpreter ported to C so that it can be compiled on any OS
    So Chip's interest in a command line compiler written in C is not in the plan?

    @Tubular
    reformatting p1 code into p2 format
    Do you believe this is easily achieved with automated systems (no manual changes to the generated code) ?

    Kevin.
  • @Tubular: If you're that desperate, you might try the version of SpinEdit posted here:
    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...
  • JonnyMacJonnyMac Posts: 6,661
    edited 2020-04-10 - 14:26:48
    So Chip's interest in a command line compiler written in C is not in the plan?
    Chip was asking about C compilers the other day, so I think that project -- which he told me he would do -- is in the works. What I was saying is that I think the Spin2 compiler written in C is much more important than a Spin1 to Spin2 language translator.
    Do you believe this is easily achieved with automated systems (no manual changes to the generated code) ?
    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.
  • kg1 wrote: »
    reformatting p1 code into p2 format
    Do you believe this is easily achieved with automated systems (no manual changes to the generated code) ?

    Kevin.

    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
  • JonnyMacJonnyMac Posts: 6,661
    edited 2020-04-10 - 15:40:25
    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).
    It's funny, isn't it? -- we don't usually complain about code running "too fast" on a new machine, but there are times when that can be problematic. I also rewrote my I2C code for the P2. The great news is that I don't need a cog to get fast I2C anymore.
  • kg1kg1 Posts: 98
    edited 2020-04-10 - 20:29:45
    @JonnyMac @wmosscrop
    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.
  • I have a personal library of 200+ P1 objects, though only 10-15% of them get very regular use with my clients. IMO, there is no magic wand that's going to convert everything in the old P1 Obex to the P2 -- nor should there be. I'm going through my P1 library now, reviewing it, making updates and improvements as required, and then porting it to the P2. I was never happy with most of the material posted in Obex which is why I wrote my own objects -- only two are from Obex, and both have been modified by me. Since I charge for my time, I want to make sure the libraries I use are reliable. If something breaks, it's on me.

    We're way out front on this. We can either do the conversions ourselves, or wait on someone else. I don't like waiting.
  • I would rather that Chip focus on getting the Spin2 interpreter ported to C so that it can be compiled on any OS, and then create a really nice library of objects that 1) help people get up and running, and 2) show people how to take advantage of the P2.
    What is the time line? Is this a project that will take years?
    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.
  • JonnyMacJonnyMac Posts: 6,661
    edited 2020-04-10 - 21:00:07
    Only Chip knows the answer to the first three questions, but I believe a few months, not years.

    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.
  • I think many P2 users would like to see a plan and a time line.
    Thank you for your comments Jon.
    Regards,
    Kevin.
  • That's not how Chip operates.
  • kg1 wrote: »
    @JonnyMac
    @Tubular
    reformatting p1 code into p2 format
    Do you believe this is easily achieved with automated systems (no manual changes to the generated code) ?

    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

  • kg1 wrote: »
    @JonnyMac @wmosscrop
    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 am most interested in your point of view,
    Kevin.

    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?
  • JonnyMac wrote: »
    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).
    It's funny, isn't it? -- we don't usually complain about code running "too fast" on a new machine, but there are times when that can be problematic. I also rewrote my I2C code for the P2. The great news is that I don't need a cog to get fast I2C anymore.
    In my case it was 2 supposedly identical display modules, both in use at the same time with the same code. One didn't seem to mind a particular speed that was within the published timings. The other would work at that same speed... for a while, say several minutes. Then the display would garble just a little, a little more, and finally go blank. All while the other display worked perfectly.

    Finally figured out that I had to update the displays much slower (4x) than I thought I could. Oh well.

Sign In or Register to comment.