Share Your [Working] Spin2 Snippets, Please :)
JonnyMac
Posts: 9,104
I like looking through small bits of successful code for ideas and solutions -- with Spin2 being new and having differences from Spin1, I thought I'd start this thread so that we can share what we've learned with each other.
If you would, post your snippet and detail syntax changes from Spin1.
If you would, post your snippet and detail syntax changes from Spin1.
Comments
Changes from Spin1
-- return value(s) must be declared on method slug-line
-- the =< and => operators become <= and >=
In this case, the changes were fairly minor from the Spin1 version which passed pointers to the value variables.
Changes from Spin1
-- return value(s) must be declared on method slug-line
-- >| operator becomes encod (P2 version behaves differently than P1)
-- uses new bmask operator to create mask for digit based on radix
Great idea! Would you like to place a link in the P2 Tricks and traps reference thread, and in the P2 Tools and sample code “sticky”.
New commands like PINL(), PINH(), PINF, PINW(), and PINR() make IO access very easy, and maintain the same flexibility as accessing the IO registers in the P1.
Here's the updated out() method that uses inline assembly for speed. Note that inline assembly only works with local variables, so I have to copy the pins and timing from the global vars of the object -- this is a very small price to pay for the increase in speed. I also have to pass the clock speed (in Hertz) to the updated object.
That's a very significant upgrade. Very cool!
While Spin on the P1 was way too slow for this, I think that there should be no problem doing this directly in Spin2, rather than assembly since the speed will be limited by the LED timing anyway. I demonstrated this at the Tachyon code level on the P1 (even though in practice I used a cog code module), so Spin2 should work fine. I basically broke up each data bit into 3 periods, the "from low" to high "clock" period, the data period, and then the clock idle low period. Let's see it done in pure Spin2!
That said, this is first draft code -- it's meant to inspire others to try inline PASM2.
Can you show the Spin2 code for SPI that was running at only 600KHz?
When will you add all the new Spin2 commands to your document? For the time being, I have been scanning the compiler listing for them.
QPI too...
Look in the Spin2_interpreter.spin2 file and you'll see all the commands listed in the comments, spread throughout. I hope to get to method syntax soon.
I don't know if the current docs are wrong or I'm completely misunderstanding something, but after failing for a couple days I found that I could do what I wanted with TAQOZ, so I downloaded and tore through the source code. Once I found the proper mode bits for PWM, everything came together.
For the Arduino lurkers (grin), this is the equivalent of analogWrite() with frequency control and the ability to use any pin.
I believe compiling the Spin2 code with fastspin should let you get full speed without requiring inline assembly, and perhaps Chip will be able to optimize his compiler/interpreter combo to get closer to full speed as well -- in fact I'm quite confident he could.
Inline assembly is nice, but really we want users to be able to program in high level languages as much as possible.
I think all of your examples could work with fastspin except that I need to add some new Spin2 operators (fastspin uses Spin1 syntax for operators for now) and the inline assembly syntax is slightly different. Fastspin uses asm / endasm instead of org / end. I hope to fix this once I'm active again, unless someone beats me to it (it really would be a minor change to the Spin yacc file).
For maximum speed you'd probably want to use -O2 optimization, which among other things tells fastspin to use LUT as cache for loops. But the default -O1 may suffice.
(1) thank you @JonnyMac for starting this thread, it's a great idea!
(2) Spin2 code that doesn't use inline assembly or P2 specific hardware features may be compiled for P1 by fastspin. Multiple return values, for example, make a lot of things easier and I'm glad Chip came up with this feature, and I use it a lot for my P1 code.
This version uses a timing constant for ticks per microsecond. I also did a version using inline PASM2 that reads clkfreq from the system. Question: Is is possible to read back the smart pin configuration? I would like the PASM version to check the pin for previous configuration and skip ahead to the wypin instruction if that is the case.