Interrupts And Porting Code To The P2
idbruce
Posts: 6,197
Please excuse my ignorance, since I have not kept up with all the P2 discussions, but there are a few questions that I would like answered.
As many of you already know, I am a firm believer in using existing public domain OpenSource code, instead of creating proprietary code, and as you may also know, I have had problems with porting Arduino code to the Propeller platform in the past, particularly as it relates to available memory and interrupts.
Question #1 - Will the P2 be able to provide easy solutions for interrupts used in existing Arduino code?
Question #2 - Does the P2 have a significant increase in the size of memory as compared to the P1?
Question #3 - Does anyone believe that GRBL can be ported to the P2?
As many of you already know, I am a firm believer in using existing public domain OpenSource code, instead of creating proprietary code, and as you may also know, I have had problems with porting Arduino code to the Propeller platform in the past, particularly as it relates to available memory and interrupts.
Question #1 - Will the P2 be able to provide easy solutions for interrupts used in existing Arduino code?
Question #2 - Does the P2 have a significant increase in the size of memory as compared to the P1?
Question #3 - Does anyone believe that GRBL can be ported to the P2?
Comments
I'm sure having interrupts in the P2 will make porting of some Arduino code easier.
P2 memory is 512KB vs the 32KB of the P1. That opens it up to a lot more applications.
What is GRBL? If it's C code that runs on an Arduino then for sure it can be ported to the P2.
Mind you, "porting" can mean anything from a simple recompilation to a massive rewrite.
Are the P2 interrupts basically equivalent to the interrupts used on other uCs, such as Arduino, programatically speaking?
Well that is a very significant increase.
It's in C.
Source: (grbl wiki) https://github.com/grbl/grbl/wiki
GRBL sounds like something a P2 could do on a single COG with plenty of free time. What can we do with the other 7 COGS whilst that is going on?
I presume "straight Arduino" means original 8 bit ATMEGA based boards. I don't follow the Arduino world but I get the idea they now have 32 bit ARM based Arduino's as well.
...once there is a C compiler for P2, of course. Dave Hein's p2gcc program to convert PropGCC output from P1 to P2 is a partial solution for now. Everyone expects that there will be a P2 C compiler at some point, but there's no schedule for it yet.
We kind of forget that somebody has to make that happen.
The tricky parts will not be the C code, but the hardware porting around peripherals and timers.
You could start studying the time-critical, interrupt paced code and annotate every time it talks to any hardware (timers, interrupts).
All of that needs to be re-coded for P2 hardware resource.
P2's smart pins and 32b timers, should simplify quite a lot of the code.
It may be easier to initially target two COGS, one that manages the time domain, and one that runs the vector code.
JMG and others are totally correct when they say that the P2 will make light work of what GRBL does.
GRBL would be a PERFECT project to port to the Propeller 2 !!
Smart pins, CORDIC, 32 bit math, high clock rate, etc, etc would make GRBL much simpler and more effective.
My local Maker Space has a CNC setup with GRBL and I have been doing some upgrades to it.
The latest version of GRBL still only has a max transfer rate of 115200 bps.
The Arduino board also has a significant limitation to the current draw for the steppers.
A P2 version could easily do 10x that transfer rate and a properly made P2 board should have stepper drivers that can handle higher current.
This combo could get A LOT of attention from those making CNC's for Maker Spaces or their own home.
Another project to port would be the code for the Maslow vertical CNC to P2 !!
Jason
Quadrature decode.
The P2 can bring GRBL to proper CNC :cool:
Joke (from some thread about programming machines):
Q: Is there any g-code for fast spindle stop?
A: G00 Z-1000.
Looks like workarounds there might be possible
https://lsicsi.com/#/products/Incremental-Encoder-Interface
https://www.usdigital.com/products/interfaces
LS7183N-S is a So8N chip, that converts QaQb to CkU CkD, or LS7366R-S, LS7366R-TS os So14/TSSOP 32b counter, SPI interface
The LS7183N-S seems to need the least code change, and drives 2 pins (I may have similar PLD code somewhere... )
When P2B arrives, the LS7183N-S is simply removed.
LOL....it was you who helped me out with this, years ago and I selected the 7366... I did thank you but I thank you again.
I used them on a PIC-based project but for the Prop, I used a cog which is plenty fast enough.
The P2 is at least 4X faster so I can do the same for now.
The 7366 can certainly do the task, as it is a full counter, but I also like the LS7183N, as that is a simpler front-end only,. that can flip a Quad signal, to two clocks (CkU, CkD) that drive two P2 up counters (which do work). The difference gives the location.
Using that means no pin changes in the design on P2B, & SW changes are just a mode init change and removal of Difference read.
I found some old code for a SPLD, but given the price/Icc/package of SPLDs, I might also explore using a CLU block in a MCU as a PLD, to copy a LS7183N operation.
This other one piqued my interest as it already incorporates line receivers:
https://www.ichaus.de/iC-MD
Being able to read the phase difference of 2 incoming signals on a pair of pins, that would be neat.
Resolvers are analog, so they suffer not from this limitation called resolution!
Commercial drives (I have a couple BLDC 941 drives) provide a 16bit counter when reading a resolver, so instead of 8000 counts (typical) per rev, you get 64k.
If you were able to measure the phase difference between the sin/cos outputs to a decent degree (many resolvers are driven at 10khz IIRC), you could have some high resolution feedback.
Of course, resolvers went out of vogue in the mid 90's, but some machine builders used them. Brother tapping centers had Toshiba BLDC motors with resolver feedback, and Fadal used them from 1985 to 1997-ish time frame. Fadal claimed that they provided better surface finish because there was no quantization error like low res encoders have.
You can still find BLDC motors with resolver feedback on Ebay, the late model resolvers were brushless, combined with a brushless motor, the only thing that wears out is the bearings! TBF, encoders are etched glass discs, so as long as the bearings are good, they continue to read, but bad bearings is the death of an encoder, I've seen a resolver that was horribly abused, but still worked!
This makes me wonder if the Goertzel circuit would be much improved by having TWO sets of sin/cos accumulators, instead of one. It doesn't directly relate to resolvers, but I wonder if there's much value in Goertzel'ing two ADC input streams simultaneously. I think relative phase measurements might be useful. It might be as significant as having a 2-channel scope over a 1-channel scope. It would add 512 flops to chip.
You could excite Sine/Cosine coils from a DAC pair, at any frequency you wanted, & other pins can resolve phase and precision duty cycle.
If you create the Sine/Cosine from P2, there is no timebase error, but some resolvers generate their own sin/cos signals, so those could need period extract in order to extract phase.
Provided this is true, and provided that the problems of timers and interrupts can be overcome by the P2, then I believe that creating a C compiler and IDE should become a top order of business for the P2 developers.
I am certain that P2 marketing and sales could benefit greatly from the massive amount of existing OpenSource C code that is readily available. I can easily envision many folks upgrading their Arduinos to P2s, providing there is a C compiler and IDE, as well as an easy workaround for timers and interrupts.
However, without the workaround for the timers and interrupts, I believe that it will become a hard sale, due to all the man hours that have gone into the OpenSource code that use these interrupts and timers.
Most folks like "EASY", but creating code from scratch is extremely difficult, and this is especially true for motion control, or at least I would not like to tackle such a task.
In my last post I stated:
I now contend that this is the time for some serious experimentation with the P2, being compared against Arduino and other uC products. This experimentation would attempt to answer one very important question, which is:
Can the P2 "easily duplicate" the behavior of the interrupts used in existing OpenSource C code?
So P2 has interrupts, but that doesn't mean it has the kind of interrupts any particular bit of open source software expects. The whole philosophy of the P1 was that you'd do this by letting another cog sit in WAITPEQ, which means the "interrupt" code would run concurrently with base code. That might or might not work for other reasons. So porting code is never going to just be a matter of pasting the sketch into a Propeller editor and clicking download.
Yes, I realize this. When I raised the question:
I should have asked:
When targeting a specific architecture, using a defined set of rules, can the P2 "easily duplicate" the behavior of the interrupts used in existing OpenSource C code?
This is definitely an area that should be explored, and if it is possible, then guidelines should be established, which would guide and instruct users during an upgrade of their uC to a P2. This type of exploration could possibly open a lot of doors for the P2, which were an impossibility for the P1.
a) In many cases dedicating a core to an event handler is a waste of resources. Perhaps a single core is more than enough to do the background job it has and handle any external events via interrupts. This was the argument for adding interrupts to the P2.
b) The mutual exclusion problem. Anything that handles asynchronous external events eventually has to share data with whatever "background" processing. In the interrupt world that is a simple case of disabling the interrupt in the background process when it fiddles with shared data. The interrupt handler does not need to worry about it as it is a high priority thing. When you replace interrupt handlers with parallel threads running on different cores you need to pay attention to mutual exclusion via locks and such. Or be careful to implement lock free data sharing algorithms. Arguably more complex to think about.
I agree, porting complex interrupt dependent Arduino code is not going to be trivial. Using interrupts or not.
Besides the problems that may be encountered with the timers and interrupts, what other complexities do you foresee?
If they'd had cogs, they probably wouldn't have needed interrupts at all.
Edit: I do see that their velocity is units/sec and accel is units/sec²
LOL... Yea, but now all those man hours have been spent on the wrong architecture, a bit too late now.
ErNa
Provided that the issues pertaining to the use of timers and interrupts can be overcome, that would be "a lot of code" to translate.
I believe I was pretty darn close with the Teacup port, but then I ran out of memory. Now that there will be 16X the memory of the P1, I think it is possible that it could be accomplished EDIT>with without<EDIT the use of interrupts. However any ports would be much easier if the behavior was simply duplicated.