Shop Learn
P2 PASM SIN 16Bit - Page 4 — Parallax Forums

P2 PASM SIN 16Bit

124»

Comments

  • without interpolation

    with interpolation

    I polish the rest away with an RC combination.

  • evanhevanh Posts: 10,800

    Nice. Though adding more modelled data points instead would be better still.

  • Do you have a piece of code on how to do this?
    But it should not be bound to the pure sine.
    After all, up to 32 oscillators with different frequencies and amplitudes can work here.

  • evanhevanh Posts: 10,800

    Not me. I thought the discussion on staggered Cordic use was leading that way.

  • evanhevanh Posts: 10,800

    Have a good read of source for Chip's Spiral Demo.
    Here's a video of an early version of the spiral demo. It's updating the whole display area at that rate. And that was before Chip unrolled the Cordic calculations. We are running it at much higher resolutions now and it still runs quite smoothly.

    https://forums.parallax.com/uploads/FileUpload/83/e4983d5634ca3c0a7ab28fabdfc284.mp4

  • If I were to do multiple calculations to improve the signal quality, I would have to synchronise the oscillators. From 2..30, the variation would be a maximum of 10 groups of 3 oscillators each. (e.g. piano 10 fingers with 3 sides per note).
    Which brings new problems and consumes recourses.
    As it stands, I can increase from 250k to 500k.


  • I think for 20kHz the signal is good enough.
    In the object are 32 oscillators at one output.
    Each can be adjusted independently in frequency and level.
    The propeller works with 348Mhz, but other frequencies are possible.

    When I have time I will clean the project and put it on #001.

    The Cordic only wants to work up to 400Mhz.

  • evanhevanh Posts: 10,800

    @pic18f2550 said:
    The Cordic only wants to work up to 400Mhz.

    Put an ice pack on top. :P

    Actually, what did happen at 400 MHz? Data corruption in GETQX/GETQY?

  • The propeller hardly gets warm.
    The spiral demo gets warmer.

    COG and DAC work but the Cordic only delivers 0h.

    But this is no problem because even at 256Mhz a usable signal with 20Khz comes out.

    I encountered this problem when trying to use BLDCs.

  • evanhevanh Posts: 10,800

    I can assure you the ice pack works alright. It wasn't just an impractical joke.

  • evanhevanh Posts: 10,800
    edited 2021-04-04 22:47

    @pic18f2550 said:
    COG and DAC work but the Cordic only delivers 0h.

    Good to know. Others had said they'd found things went badly before the clock slowed down on high temperature. So Cordic will be one of the areas that isn't protected by the self-limiting of the PLL that was added with revB silicon.

  • If the propeller had a better housing, it would now be water-cooled.
    But in this case, it doesn't do much good. :)

  • evanhevanh Posts: 10,800

    Well, refrigeration could be applied to the exposed pad. I'd probably go with leaving the PCB in place for good grounding and just use lots of vias for thermal transfer between the exposed pad and the chilled plate. Metallic transfer paste would be excellent interface choice for the chilled plate.

  • Cluso99Cluso99 Posts: 17,666

    I found when testing the SD that catastrophic failure occurred just above 380MHz. All instructions started failing without using SD. COoling the P2 will increase the max freq. This max may also vary with P2 chips.

  • Does anyone know why this does not translate?

    If I leave out the "return" everything is OK.
    But I need the COGID.

    It bumps into the coginit. for whatever reason.

    PUB ini(psync, pstatus, sstatus, parray, sarray1, pchan1, pchan2)
      sync    := psync
      stat1   := pstatus
      stat2   := sstatus
      indat   := parray
      outdat  := sarray1
      chan1   := pchan1-1
      chan2   := pchan2-1
    
      return coginit(COGEXEC_NEW, @pha0, 0) + 1   {{ Phasenberechnung starten}}
    
  • Cluso99Cluso99 Posts: 17,666
    edited 2021-04-07 20:07

    You need to specify that a return value is being used. eg
    PUB xyz(a,b,c) : retn
    ...
    Retn := coginit(....

  • OK then there is probably a change here to the P1.

    var { object globals }
      long  cog                                                     ''cog (+1) running uart code
    
    pub start(rxp, txp, mode, baud)
    '' Start serial driver (uses a cog, returns 1 to 8 if successful)
      stop                                                          '' stop if running
    
      longfill(@rxhead, 0, 4)                                       '' clear buffer indexes
      longmove(@rxpin, @rxp, 3)                                     '' copy pins and mode
      bitticks := clkfreq / baud                                    '' system ticks per bit
      bufpntr := @rxbuffer                                          '' hub address of rxbuffer
    
      cog := cognew(@fdsuart, @rxhead) + 1                          '' start the fds uart cog
    
      return cog                                                    '' return 1..8 if started, 0 if not
    
    

    pub start(rxp, txp, mode, baud):xyz <---- ?

    Why that does not bring an error when expanding, I do not know?

    OK what learned. --> : do not forget.

  • File "SINE_2021_04_08.spin2" inserted in 001.

    This is a simple model, which shows how to generate 32 tones with enough computing time. B)

  • Oh, waitatn was already available for the P1?
    I hadn't noticed. Probably because I've never had this situation before. I'll take a closer look.
    I want to use the computing power of the Cordic more.

    I want to feed the Cordic with one COG and read out the results with another. Is that possible at all?
    The load would then be approx. 90% of the cycle time.😊

    I am in favour of each COG getting its own cordic.👍

  • Cluso99Cluso99 Posts: 17,666

    No. There was no waitatn for P1.

  • evanhevanh Posts: 10,800

    @pic18f2550 said:
    I want to use the computing power of the Cordic more.

    Here's a better optimised version of one of your already unrolled sections:

    {{ ==== 1. Sampelausschnitt und Sinus berechnen }}
            add     ph1, fr1         ' 2
            qrotate am1, ph1         ' 0  (2..9)
            add     ph2, fr2         ' 
            qrotate am2, ph2         ' 8
            add     ph3, fr3         ' 
            qrotate am3, ph3         ' 16
            add     ph4, fr4         ' 
            qrotate am4, ph4         ' 24
            add     ph5, fr5         ' 
            qrotate am5, ph5         ' 32
            add     ph6, fr6         ' 
            qrotate am6, ph6         ' 40
            add     ph7, fr7         ' 
            qrotate am7, ph7         ' 48
            add     ph8, fr8         ' 
            qrotate am8, ph8         ' 56
            getqy   outws            '       #1
            add     outwn, outws     ' 
            add     ph9, fr9         ' 
            qrotate am9, ph9         ' 64
            getqy   outws            '       #2
            add     outwn, outws     ' 
            add     ph10, fr10       ' 
            qrotate am10, ph10       ' 72
            getqy   outws            '       #3
            add     outwn, outws     ' 
            add     ph11, fr11       ' 
            qrotate am11, ph11       ' 80
            getqy   outws            '       #4
            add     outwn, outws     ' 
            add     ph12, fr12       ' 
            qrotate am12, ph12       ' 88
            getqy   outws            '       #5
            add     outwn, outws     ' 
            add     ph13, fr13       ' 
            qrotate am13, ph13       ' 96
            getqy   outws            '       #6
            add     outwn, outws     ' 
            add     ph14, fr14       ' 
            qrotate am14, ph14       ' 104
            getqy   outws            '       #7
            add     outwn, outws     ' 
            add     ph15, fr15       ' 
            qrotate am15, ph15       ' 112
            getqy   outws            '       #8
            add     outwn, outws     ' 
            add     ph16, fr16       ' 
            qrotate am16, ph16       ' 120
            getqy   outws            ' 122   #9
            add     outwn, outws     ' 
            getqy   outws            ' 130   #10
            add     outwn, outws     ' 
            getqy   outws            ' 138   #11
            add     outwn, outws     ' 
            getqy   outws            ' 146   #12
            add     outwn, outws     ' 
            getqy   outws            ' 154   #13
            add     outwn, outws     ' 
            getqy   outws            ' 162   #14
            add     outwn, outws     ' 
            getqy   outws            ' 170   #15
            add     outwn, outws     ' 
            getqy   outws            ' 178   #16
            add     outwn, outws     ' 
            waitct1                  '
    
  • evanhevanh Posts: 10,800

    @pic18f2550 said:
    I want to feed the Cordic with one COG and read out the results with another. Is that possible at all?

    No. That would be very hard to keep the data through the cordic and the cogs in order. It's hard enough already.

  • Is it only difficult or not possible?
    Difficult is not an argument for giving up, but rather for a PidBull.

    I think the question can only be answered by someone who is familiar with the internal function of the P2.

    The goal is to do 220 cordic calculations in 450 clocks.

  • evanhevanh Posts: 10,800
    edited 2021-04-10 16:53

    @pic18f2550 said:
    Is it only difficult or not possible?

    No, not possible with the Prop2. The reason is why it wasn't even considered a good idea to have.

    Also, if allowing that, it mixes things up too much. There is a level of separation between cogs that allows a modular approach to "objects", making able to take a whole cog for itself and not be too concerned with a mix of objects by different authors.

    The philosophy was a natural fit with the Prop1. Prop2 might be a tad more effort to make it work. Just the flexibility of setting the clock frequency alone will be an unwanted spanner when mixing some objects.

  • evanhevanh Posts: 10,800

    @pic18f2550 said:
    The goal is to do 220 cordic calculations in 450 clocks.

    That would require all the cogs doing a part each to have a chance. Peak calculation throughput is one per clock but as you've already seen, it's not simple to get close to one cog's potential let alone them all.

  • evanhevanh Posts: 10,800
    edited 2021-04-10 17:40

    @pic18f2550 said:
    I think the question can only be answered by someone who is familiar with the internal function of the P2.

    A particular cog's Cordic operations are strictly tracked along the pipeline. Those results appear only to said cog. It's part of the fixed slot numbering in hub rotation mechanism.

    I have to say, you're the first person to even question it! afaik :)

    EDIT: Possibly more accurately, the Cordic doesn't have to track cog numbers through the stages but rather the cog number is inherently known by which slot number that the result pops out the end of the pipeline at.

    EDIT2: So what will need tracked is what, if any, operation is required of each stage. The "if any" will be important for whether or not to overwrite the QX/QY result registers for each cog. And also for generating events.

Sign In or Register to comment.