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.
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.
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.
@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.
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.
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.
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.
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.
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!
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.
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.
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):
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.
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!
Comments
https://lastminuteengineers.com/rotary-encoder-arduino-tutorial/
Ken Gracey
Just an example of your code, running with some Adafruit NeoPixel rings, as a Christmas Tree: https://youtu.be/Vu4qSBq1EUU
dgately
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.
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
Mike
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.
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.
John Abshier
Paul
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
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
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.