Shop OBEX P1 Docs P2 Docs Learn Events
Interrupts And Porting Code To The P2 — Parallax Forums

Interrupts And Porting Code To The P2

idbruceidbruce Posts: 6,197
edited 2018-10-06 15:47 in Propeller 2
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?
«1

Comments

  • Heater.Heater. Posts: 21,230
    There is no "public domain" code. It's almost impossible for any work to enter the public domain unless it's author has been dead for tens of decades or it's the work of a government. For this reason Open Source and Free software comes with licenses that specifically allows anyone to use it for anything. It is still subject to copyright.

    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.



  • Okay Heater, public domain was a lack of thought on my part, I meant OpenSource.
    I'm sure having interrupts in the P2 will make porting of some Arduino code easier.

    Are the P2 interrupts basically equivalent to the interrupts used on other uCs, such as Arduino, programatically speaking?
    512KB vs the 32KB

    Well that is a very significant increase.
    What is GRBL? If it's C code that runs on an Arduino then for sure it can be ported to the P2.

    It's in C.
    Grbl is a free, open source, high performance software for controlling the motion of machines that move, that make things, or that make things move, and will run on a straight Arduino. If the maker movement was an industry, Grbl would be the industry standard.

    Source: (grbl wiki) https://github.com/grbl/grbl/wiki
  • Heater.Heater. Posts: 21,230
    Thanks.

    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.



  • Heater. wrote: »
    What is GRBL? If it's C code that runs on an Arduino then for sure it can be ported to the P2.

    ...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.

  • Heater.Heater. Posts: 21,230
    Ah, good point. I was casually assuming that wherever a processor goes a C compiler follows...

    We kind of forget that somebody has to make that happen.
  • jmgjmg Posts: 15,140
    idbruce wrote: »
    Grbl is a free, open source, high performance software for controlling the motion of machines that move, that make things, or that make things move, and will run on a straight Arduino. If the maker movement was an industry, Grbl would be the industry standard.

    Source: (grbl wiki) https://github.com/grbl/grbl/wiki

    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.
  • thejthej Posts: 232
    edited 2018-10-06 23:55
    GRBL is highly tuned to the 16MHz, 8-bit Arduino.
    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
  • Don't forget the feature that I got all excited about...that, naturally for my luck, doesn't currently work :swear:
    Quadrature decode.

    The P2 can bring GRBL to proper CNC :cool:
  • Just came across this:

    Joke (from some thread about programming machines):
    Q: Is there any g-code for fast spindle stop?
    A: G00 Z-1000.

    :lol:
  • jmgjmg Posts: 15,140
    Mickster wrote: »
    Don't forget the feature that I got all excited about...that, naturally for my luck, doesn't currently work :swear:
    Quadrature decode.

    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.


  • jmg wrote: »
    Mickster wrote: »
    Don't forget the feature that I got all excited about...that, naturally for my luck, doesn't currently work :swear:
    Quadrature decode.

    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.
  • jmgjmg Posts: 15,140
    Mickster wrote: »
    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.
  • I was considering the 7183 and using the P1 counters but I think you mentioned that it was an older device and that EOL might be imminent.

    This other one piqued my interest as it already incorporates line receivers:
    https://www.ichaus.de/iC-MD
  • I'm interested in feedback from resolvers :smile:

    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!
  • cgraceycgracey Posts: 14,133
    edited 2018-10-07 06:59
    pedward wrote: »
    I'm interested in feedback from resolvers :smile:

    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.
  • jmgjmg Posts: 15,140
    pedward wrote: »
    I'm interested in feedback from resolvers :smile:

    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!

    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.



  • cgraceycgracey Posts: 14,133
    It would be tough to add in another set of Goertzel accumulators, but there's no need to. Each cog can make a simultaneous measurement, so we have 8 concurrent channels, if needed.
  • Hmmm, I find that resolvers are still popular today and their drives provide an emulated quadrature output. I heard something similar to what came from Fadal; where the tightest possible velocity control is required (I think it was flying shears) DC tach generators are still preferred.
  • It sounds like you folks believe that GRBL can be ported to the P2, provided someone creates a C compiler and hopefully an IDE.

    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.
  • idbruceidbruce Posts: 6,197
    edited 2018-10-07 10:40
    Let me take it one step further... Or should I say clarify

    In my last post I stated:
    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 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?
  • There's more to it than just "emulating interrupts." Interrupt systems vary in edge case behavior. What happens if another interrupt comes in while an interrupt service routine is running? Some quick searching reveals that the Arduino won't interrupt an ISR, and interrupts that come in are serviced after it returns, in an order determined by a priority structure. I believe some other architectures will let a high priority interrupt interrupt a low priority ISR. In order to get around the bottleneck some systems have a special non-maskable interrupt which can interrupt any of the other interrupts that can't interrupt each other. And what happens if you get another NMI while a NMI is being serviced? This rabbit hole is why Chip didn't impement interrupts at all in the P1. They get complicated quick.

    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.
  • ErNaErNa Posts: 1,738
    Interrupts is about running programs in parallel on a single machine. Who without need would run programs interrupt driven, if he has a parallel machine? Porting a C program written for a single processor architecturer by just compiling and linking to a different machine with a different architecture is not a simple, but a challenging task. But it is still less difficult than moving a load balanced distributed machine solution to a fine tuned single processor machine.
  • @localroger
    So porting code is never going to just be a matter of pasting the sketch into a Propeller editor and clicking download.

    :smiley:

    Yes, I realize this. When I raised the question:
    Can the P2 "easily duplicate" the behavior of the interrupts used in existing OpenSource C code?

    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.
  • Heater.Heater. Posts: 21,230
    ErNa,
    Who without need would run programs interrupt driven..
    Indeed, that has been an age old question around here. Historically there was only one processor so responding to external events in a timely fashion required interrupts. That is what people got used to. It was a bit of stretch for them to get the idea that if you have many processors, like the P1, each one of them can do the work of an interrupt handler. With great benefits in timing determinism as a bonus. Still I can see some arguments for wanting interrupts on a multi-cpu system:

    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.
  • Heater
    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?
  • MicksterMickster Posts: 2,588
    edited 2018-10-07 17:11
    Not familiar with the GRBL code but surely it can only be using a timer interrupt to dish out the stepper pulses via a trajectory generator?

    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²
  • I'd be very interested in GRBL adapted to utilize the capabilities of the P2 :cool:
  • ErNaErNa Posts: 1,738
    There is no secret in GRBL. It's just a lot of code. On one side, there is a real time task to handle the steppers, on the other side it needs a parser to decode the G-CODEs. Ands some I/O is needed to stream the data. I can imagine, to do this in an interrupt driven environment, the code is spilt into parts, that now have to be brought together. Shouldn't it be possible to code this, using TaQOz? That would allow to firstly generate stepper motor drivers, then interpolation, then....
  • Mickster
    If they'd had cogs, they probably wouldn't have needed interrupts at all.

    LOL... Yea, but now all those man hours have been spent on the wrong architecture, a bit too late now.

    ErNa
    There is no secret in GRBL. It's just a lot of code.
    Shouldn't it be possible to code this, using TaQOz?

    Provided that the issues pertaining to the use of timers and interrupts can be overcome, that would be "a lot of code" to translate.
  • idbruceidbruce Posts: 6,197
    edited 2018-10-07 17:48
    Mickster

    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.
Sign In or Register to comment.