Shop Learn
Spin2 for Beginners -- Session 8 Files Available Now - Page 4 — Parallax Forums

Spin2 for Beginners -- Session 8 Files Available Now

1246

Comments

  • According to this article, CLK is the same as A and DT is the same as B.

    https://lastminuteengineers.com/rotary-encoder-arduino-tutorial/
  • Agreed -- in fact, I documented that in my listing.
    1422 x 169 - 12K
  • You mean I need to read the comments in addition to the code? :smile:
  • The video from JonnyMac's presentation is here https://youtu.be/59oUoNd9TbQ - still rendering as of 2:10 pm Pacific.

    Ken Gracey
  • dgatelydgately Posts: 1,447
    edited 2020-12-26 16:20
    Thanks JonyMac!

    Just an example of your code, running with some Adafruit NeoPixel rings, as a Christmas Tree: https://youtu.be/Vu4qSBq1EUU



    dgately
  • JonnyMacJonnyMac Posts: 7,568
    edited 2020-12-26 18:32
    Excellent! My friend, Matt, whom I mentioned in the presentation, make an animated tree-topper with Neopixel strips.



    I wrote my APA102C pixel driver when Matt needed it to light the insides of a robot for the movie, "Zoe." Matt and I have done a lot of neat projects with the Propeller.
  • Ok, who pick the NOYITO LCD display.

    This thing has been nibbling at me all day. I guess in the end it does work although the Parallax models are much easier to program. Although if your looking for a challenge this should do the job.

    Mike
  • Ok, who pick the NOYITO LCD display.
    I did, but you're free to use anything. Why did I choose it? Well, it's low-cost, and uses I2C which is one of the topics of an upcoming training session. The attached demo will get you going.
  • Ya, the 4 bit 8 bit thing got my head spinning for a while.

    Mike
  • 4-bit mode is a little trickier to do via I2C, but as you can see, it's doable.
  • @JonnyMac Your quadrature decoder works quite well with my rotary encoders. Is there equivalent P1 code for handling rotary encoders? I've found some code but it isn't nearly as smooth as your P2 code. The values jump back and forth even when you turn the knob in one direction. Do you have a P1 object I can use?
  • Yes -- been using them in commercial P1 projects for a long time. Let me do a bit of code clean-up so that my simple P1 encoder object matches my P2 encoder object.
  • JonnyMac wrote: »
    Yes -- been using them in commercial P1 projects for a long time. Let me do a bit of code clean-up so that my simple P1 encoder object matches my P2 encoder object.
    Thanks! Looking forward to it. I'm becoming increasingly convinced that I need to replace the dumb port expander on my current project with a P1. This will be helpful for that.

  • Give me a few days. Between a client project, work, and prepping for tomorrow, things are hectic.
  • JonnyMac wrote: »
    Give me a few days. Between a client project, work, and prepping for tomorrow, things are hectic.
    No problem. I have other things to do before that anyway. For one, I need to wire up an ESP8266 and a P1 and get them talking to each other.

  • Thanks for doing this tutorial Jon, very helpful and well done. And thanks for all of the P1 code over the years as well!
  • My pleasure, Dave. I enjoy sharing what I've learned, because the interaction makes me a better programmer.
  • I have attached the files for Week 2 of our sessions to the first post in this thread.

    If you're using FlexProp, get the latest (5.0.4 or later). If you don't have it, you'll need to change a constant name for one of the demos (not a big deal).

    For those who are are using an ANSI/VT100 terminal instead of PST, there is a post Hanukkah/Christmas present for you.
  • Jon, once again you made a great and easily understood presentation. I wouldn’t worry about going long, there was a lot of good information there and I think everyone learned something new. I use 18 magnetic rotary encoders in my robot and bit banged the interface on the P1, I see now how to write the same interface on the P2 much more easily.
  • Thanks, Bob!
  • Another great presentation today JonnyMac.

    Chip's and JonnyMac's suggestion of adding some AB filtering on the Quad Encoder setup made my encoder a lot more stable.

    In "jm_quadrature.spin2" I did the following:

    Change: pinstart(apin, P_QUADRATURE | dif.[2..0] << 24, 0, 0)
    To: pinstart(apin, P_FILT2_AB | P_QUADRATURE | dif.[2..0] << 24, 0, 0)

    I was getting a lot of jumping of values before the change, after it I pretty much only get smooth changes when rotating the encoder either quickly or slowly. Great fix, thanks Chip and JonnyMac.
  • Thank you, Francis. I will add a filter selection to my object and put it into the Library folder with the files for next week. Happy New Year.
  • I added the filter, but still find the inexpensive encoders are, well, not great. The little test program shows the occasional wonkiness, even with filtering.
  • I wonder if the Schmitt trigger would work?

    John Abshier
  • I tried. It didn't make a difference with the low-cost encoder. I think it just has very noisy mechanical contacts.
  • Sounds like it was another great lesson. I had to bail out early and missed most of it. Looking forward to watching the video. Thanks @JonnyMac for your time as teacher!

    Paul
  • Thank you, Paul. Happy New Year!
  • octettaoctetta Posts: 113
    edited 2020-12-31 19:39
    Thanks for all the hard work doing this JonnyMac (as well as Parallax making all this possible).

    I'm the person who did the Python/Processing example in the General Discussion list on the forum.

    I'm glad you are performing your Processing learning with the non-Python native mode, as most of the examples and documentation are tailored for a C-ish language.

    At least for others who want to learn by example, this is probably the best path forward, and at least from my perspective, some of the weirdness converting strings to/from byte arrays will seem a little less weird under the "native" Processing language mode.

    I used Python mode mainly because I thought it would make following along easier for Ken ;-).

    On the browser side, the "version" of Processing that runs there is called p5.js. The creator of that variant is Professor Lauren McCarthy down at UCLA (https://lauren-mccarthy.com/Info). She periodically hosts exhibits where p5.js people can show off their digital artistry.

    For both Processing and p5.js, NYU Professor Daniel Shiffman (https://shiffman.net/about/) has many resources available but most popularly has cool videos on YouTube via his "Coding Train" channel (https://www.youtube.com/user/shiffman).

    Anyone know if either of these folks have a presence on this forum?

    Reach out to me if you want help or to bounce ideas off me... I'm up in Thousand Oaks, so at least we're in the same time zone.

    In the meantime, now that you're looking at this, I'm off to (re)learn about PPP and see if I can get something simple for networking the P2 via UART. I'll try to document my progress in the relevant P2 thread.

    Happy New Year everybody!

    -joe/octetta
  • YanomaniYanomani Posts: 1,166
    edited 2021-01-01 18:58
    Hi Jon

    As usual, your coding style is very informative, and I'm really learning a lot, by simply following your presentations and studying the driving/processing routines, thus, in the sense to made it a little more clear, I would like to contribute someway:

    At the original P2 docs, the filter configurations were calculated based on a 160MHz sysclk, and I noted your routines uses 200MHz, so the basic sysclk period would need to be changed, from 6.25nS/clock to 5nS/clock.

    Doing so, the new values would be (keeping the lenght and tap values the same as the stated at the docs):

    filt0 -> 10nS
    filt1 -> 480nS
    filt2 -> 13.1mS
    filt3 -> 167.8mS

    Also note that, by properlly using HUBSET, you have a lot of freedom to change the lenght and tap for each one of the original values, as to better addapt the final filtering-periods, in order to match the needs of each application (provided there is agreement between the multiple routines that can be running at individual cogs).

    Since you are trying to filter-out mechanical-derived, electrical noise, perhaps having multiple choices in the range of 10 to 50 mS (or even a bit more) would let you achieve better results, and find a sweet spot, even with the "wonkiness-prone" encoders.

    Hope it helps

    Henrique
  • JonnyMacJonnyMac Posts: 7,568
    Thank you for the feedback and suggestions. I'm glad you're enjoying the sessions -- I'm getting a lot out of them too.

    I will explore making that making that filter timing a little more user friendly, and clock speed agnostic. Funny, I ported the assembly code from the 2nd P2 example back to the P1, and even with the cheap encoder it runs very cleanly. I attribute this to the raw speed differences between the P1 and P2; the P2 is so fast it catches all the noise!

    Happy New Year.
Sign In or Register to comment.