can I update the Spin2 Interpreter underneath Spin-Tools?
refaQtor
Posts: 164
the latest version of Spin-Tools v48 includes Spin2 Interpreter v51, but I need v54 to get to use the recent Structs language feature. is there a way to update underneath it?
I only semi-installed PropellerTool, as it turns out. Because the Parallax font is critical to make it functionally readable interface/editor. I couldn't practically read the compile message around the Struct. if that's the only way, I guess I'll try re-install - and stay stuck on a Windows machine.
or try the VS Code route.
which is the easier path?
opinions?
Comments
v51 looks like latest to me. v45 was when structs got a redesign. https://forums.parallax.com/discussion/171196/pnut-spin2-latest-version-v51-new-pow-log2-exp2-log10-exp10-log-exp-floating-point-ops/p1
BTW: Propeller Tool is way out of date. It's using v38 Spin2 engine. https://www.parallax.com/package/propeller-tool-software-for-windows-spin-assembly-2/
In those rare times when the Spin Tools compiler is a bit behind PNut, you can always call PNut from Spin Tools instead of using the internal compiler.
perfect, thank you!
The latest Spin Tools release already supports the structs feature and, AFAIK, is on par with PNut. As other pointed out there is no v54 as far as I know.
Upgrading the interpreter binary is a bit complicated and requires to unpack and repack the spin-tools jar file, however without the corresponding compiler support it is useless.
The parallax font can be selected from the Spin Tools Editor Preferences.
Feel free to report bugs or ask if things doesn't work as expected.
@evanh @macca d'oH! a bit of the dyslexia for me. again and again I transposed 45 / 54 in my head.
putting this bit at the top " {Spin2_v46} " as in the documented sample helped clear my head up
not sure why, now in the light of day, it all works. but last night, SpinTools kept calling out my STRUCT declaration, which sent me down this road. now, I can't get it to not like it ¯_(ツ)_/¯
thanks again, all
Good stuff. Yeah, I suspected the 45 / 54 transposition. And I've done those wont-work then wont-not-work circles before too.
When I was working on the SD mode SD card driver development, I found I needed absolute confidence in every low level instruction and the calculated timings to go with them. Otherwise every bug became a suspicion of that mechanic and its timings. Many times, as new bugs occurred, I was digging deeper, in particular, into the runtime timing calculations. I rewrote the comments many times as the understanding evolved. Different parts of a transaction needed different accommodations. Knowing what was latency and phase and what was extra bits all mattered. And it panned out in the end too. I was able to explain each number and why there is differences.
Partly I put extra pressure on myself by deciding from the outset that I wanted a single mechanic to manage the streamer with runtime settable full flexible clock divider from max speed of sysclock/2 all the way down to the SD power up clock rate of 200 kHz.