Spin to Spin2 for pnut

13»

Comments

  • fastspin does
  • Thank you ozpropdev and msrobots. In PNut Spin2 a parameter defaults to zero which may set an unexpected result. Mmm...
  • ElectrodudeElectrodude Posts: 1,374
    edited 2020-05-03 - 22:39:51
    (Nevermind, deleted. I was thinking of the P1.)
  • @avsa242 re sensor.accel.3dof.adxl345.spi.spin2

    0ff0ffc5ddfb2d3b8e2ad4c3094dd9.png
    For CASE_FAST to compile, the match values/ranges must be unique constants which are all within 255 of each other.

    I am guessing that the error message is caused by the above rule regarding CASE_FAST?

    Any thoughts?
    806 x 252 - 30K
  • @kg1
    Hmm I was pretty sure everything built successfully last commit - I'll have to take a look at it. In the meantime, changing case_fast to case should work.
  • kg1kg1 Posts: 98
    edited 2020-05-19 - 22:13:02
    @avsa242 Hi Jesse, In my message above I failed to indicate that at that time I was compiling with PNut_v34r. Initially I compiled with flexgui_414b which compiled your code without changes (first file attached). Next I compiled with flexgui_418 which required a few code changes (second file attached). Then I took the source from the second file (flexgui_418) and tried to compile with PNut_v34r (fourth file attached). I have made a large number of changes to your code for PNut_v34r and although I feel I am getting close to a compile on PNut_34r I am not quite there yet. With PNut_34r I am not improving your code. I am only making changes to clear compile errors. I have lost count of the compiler errors while using PNut_34r. My documentation is poor but if you use Notepad++ with the compare text files add-on you will see the differences between flexgui_418 and PNut_34r source code files.
    If you are able to suggest better ways of fixing any compile errors, i would be most grateful for your advice.
    I am very grateful for all the excellent work carried out by @ersmith. The path from SPIN1 to SPIN2 from the point of view of compile & run on P2, is far easier on flexgui.
  • @kg1
    I will try to see what I can do. I suspect most any errors with newer versions of FastSpin are because Eric is trying to adapt to the updated spin2 language definition. I downloaded the bleeding edge fastspin and indeed, much of my existing code no longer builds, although most differences are trivial. I'm updating many of my repos as we speak. The ADXL345 was the first driver I updated, and have created a new branch in the p2 spin-standard-lib which incorporates these changes.
  • Thanks Jesse. See photo above. I've had your code running on Flexgui 4.1.8 since Flexgui 4.1.8 was released. All 100% ok.
  • avsa242 wrote: »
    @kg1
    I will try to see what I can do. I suspect most any errors with newer versions of FastSpin are because Eric is trying to adapt to the updated spin2 language definition. I downloaded the bleeding edge fastspin and indeed, much of my existing code no longer builds, although most differences are trivial.
    In most cases just renaming the files from ".spin2" to ".spin" will probably make them compile. The main changes in fastspin are that it's becoming stricter about Spin2 compatibility for .spin2 files, but regular .spin files have changed very little.
  • Eric,

    Thanks, I'll try to remember that!

    @kg1
    Attached is a zip containing what I had to change to your changes to get it working
    The highlights of the changes are:

    Serial terminal:
    - Combine all of the serial-related libraries/child objects into one object (besides the low-level smart-pin serial driver). Without the aid of a preprocessor, I think it's much simpler this way.
    - Some of the ANSI terminal-related methods needed the plain old Dec() method - they wouldn't work with the one from string.integer.spin2

    SPI engine:
    - PNut didn't seem to like the PINW statements you had in Write() - it didn't complain, but the bits weren't getting shifted out. I moved the (val ROR 1) and (val ROL 1) outside of the pinw() statements and the bits started showing up on the scope.
    - I made a few other minor changes to the I/O pin setup - now the new builtin pinh/l/w() are used in place of the dir/out

    ADXL driver:
    - In a few of the methods, the "get current setting" cases (OTHER) were missing return statements, so after assigning the return values, they were continuing on past the case statement and writing out values: AccelADCRes(), AccelSelfTest() were those affected.
    - Part of the reg whitelist in readReg() was commented out - this has been uncommented

    The demo:
    - It didn't seem to be running with the more verbose-style clock setup constants and clkset(), so I tried the newer, yet more P1-like _xtlfreq and _clkfreq constants - now it runs.
    - PNut doesn't support optional/default parameters, so printf() statements must be called with all parameters set to something (this also means the driver methods can't be called without parameters to get the current accel. settings, like in FastSpin). Also it still needs string() around string constants. It's definitely not as pretty as it is in FastSpin, but at the same time, still better than a two or three line block of code to spit the same text out to the terminal.

    Cheers,
    Jesse
  • @avsa242
    PNut_v34s compiled avsa242 ADXL345-PNut_34s-fixed.zip attached above. Runs well. Many thanks
    436 x 245 - 11K
Sign In or Register to comment.