Digital digitizer -> Now mixed signal Scope + DDS

Rayman · 2020-03-16 18:09

I'm working on a digital digitizer with graphical display...

Update: Better acquisition scheme described below.

Here's a binary of current program and a photo of the setup showing which pins things are on.

Update2: Adding two analog channels
Update3: Added Cursors and fixed timing.
Update4: Added SP (SmartPin) settings buttons for each channel and also vertical gain knob for analog channels

Note: Using jumpers (see image) so analog input pins #8 and #9 can look at DDS output pins #12 and #13.

jmg · 2020-03-16 19:47

maybe you could run two streamers alternating, so you have a continual sample, and that always operates.
( I don't think a single streamer wraps continually into a block of RAM ?)

A separate trigger test can then freeze those (after some delay), and where the delay:capture ratios fall, determine the pre-trigger view.
It would need to capture the streamer index, but maybe that can be inferred ?

evanh · 2020-03-17 08:17

The streamer just feeds the FIFO at a rate and quantity of samples desired. The FIFO via a WRFAST defines if and where any hubram block wrapping might occur.

A smartpin could assist with concurrent trigger capture. The cog then doesn't have to spin on a tight point and instead just decide, after the fact, on when to stop the streamer.

Rayman · 2020-03-20 14:27

I set up one pin as NCO smartpin and another to look at it.
This revealed some need for improvements...
Think it's in good shape now.

It now acquires in three steps:
1. Fill the buffer with data (so have something to show in case trigger happens right off)
2. Wait for the no-trigger condition
3. Wait for trigger condition

The trick was going from step to step with the same number of clock ticks between data collections...

I've added a slider that can move the trigger point (indicated by yellow bar).
Getting close to being useable now...

'First, fill buffer with data
PreLoop     
            nop
            nop
            nop
            add     d1,#8       
            wflong  ina
            wflong  inb
            'wait
            waitx   acqWait 'making a register so don't need ##   
            
            djnz    PreTrig,#PreLoop

'Now, wait for trigger condition to clear
ClearLoop
            nop
            nop
            add     d1,#8 
                  
            wflong  ina
            wflong  inb
            'wait
            waitx   acqWait 'making a register so don't need ##  
            testpn  TrigPin wz          
            
            
    if_z    jmp     #Clearloop    
    
     
'Now, aquire while checking for trigger            
AqLoop
            'check for trigger            
    'if_nc   testpn  #60 wc  'leave carry flag set

    if_nc   testpn  TrigPin wc  'leave carry flag set       
    if_c    sub     d2,#1
    if_nc   add     d1,#8  'keep track of where trigger occurred

            'save all ins
            wflong  ina            
            wflong  inb
            
            'wait
            waitx   acqWait 'making a register so don't need ##

            'loop
            tjz     d2,#FlagDone            
            jmp     #AqLoop

Rayman · 2020-03-23 20:04

It's almost done!

Publison · 2020-03-23 20:19

That's super Ray!

Rayman · 2020-03-25 21:38

put some work into the "Smartpin Configurator"...
These screens are useful for setting it up...

I made it so that when you click on a table, the value get set accordingly.

evanh · 2020-03-25 23:39

That's quite a lot of help. Good stuff. I see you've started separating the register names from the instruction names with the RxPIN for the Z register. Just straight call them X, Y and Z.

I'd recommend renaming the "digital filter" to "de-glitch filter". That'll help clarify its real purpose and won't get hopes up that it'll do more. I should hassle Chip to do the same.

EDIT: Chip's write-up for the %TT field is problematic because that field is intertwined with both M and P fields and even changes modes in the cases of BIT_DAC and COG_DAC.

Rayman · 2020-03-26 00:32

I just discovered this digital filter stuff while doing this... Still need to play with that...

I changed "RxPIN" to "RZPIN", that's what you mean, right? (see new image below)

I'll look at %TT some more.

evanh · 2020-03-26 01:10

I was thinking just plain "X", "Y" and "Z" or maybe "X paramter", "Y parameter" and "Z register".

Rayman · 2020-03-26 17:11

This app does help to figure out some things about the smartpins.
I posted the binary to the top post and a photo of the setup.

There's an interesting TT mode where you can AND, XOR, etc. the A and B inputs.
Here's what I got before and after ANDing the signal displayed on P54 with that of P56.
Look at the top trace to see what I mean in these two images.

Rayman · 2020-03-26 17:37

Kind of a shame that you can't directly look at a Pin's output using either INA or OUTA when it is smartpin mode.
Fortunately, you can look at a neighboring pins smartpin output using the %AAABBB wrpin setting.

In the above, I have P54 looking at P55, P56 looking at P57 and P58 looking at P59.
The INA for the ones in smartpin mode are all high even though they are actually outputting square waves.

Rayman · 2020-03-26 19:50

The docs for NCO duty mode are not very clear...
It doesn't actually tell you how to set the %duty.

I just played with it and see now that Y controls duty.
Y=$FFFF_FFFF is 100% duty, Y=$8000_0000 is 50% duty and Y=0 is 0% duty.

Makes some sense now...

X controls the minimum pulse width apparently. Not exactly sure how...

Rayman · 2020-03-26 20:43

The PWM mode documentation also hard to understand.
But, I see now that X[31..16] times X{15..0] decides clocks in a frame.

The pulse width fraction is decided by Y[15..0] divided by X[31..16].
Y[15..0] must be less than X[31..16] so the fraction of on time ranges from 0 to 1.

I don't see any external difference between sawtooth and triangle other than the triangle's frame width being twice as long.

evanh · 2020-03-26 21:03

The triangle mode will be for some synchronous feature when aligning multiple output timings. I've ignored it so far.

EDIT: Or maybe it's good for holding centre phasing when wanting a rock solid frequency.

JonnyMac · 2020-03-26 21:14

I struggled with the PWM nomenclature -- sawtooth and triangle refer to the behavior of the counter. The way Chip explained it to me, use triangle if you want the pulse centered around the time frame boundary, otherwise use sawtooth, which does what we expect by starting the pulse on the timing frame boundary. I'm sure people far smarter than I can explain the benefit of triangle.

I'm working on a P2 article for N&V right now. I will be including these two examples of PWM sawtooth mode that handle common tasks. The pwm() method is to emulate analogWrite() from the Arduino, with the added benefit of using any pin and being able to specify PWM frequency.

pub pwm(pin, duty, hz) | x

'' DMX-compatible PWM
'' --  pin - output pin (0..55)
'' -- duty - duty cycle of output 0 to 255 (100%)
'' --   hz - pwm output frequncy

  if (hz == 0)
    pinclear(pin)
  else
    x := (255 << 16) | (1 #> ((CLK_FREQ / 255) / hz) <# $FFFF)
    pinstart(pin, P_PWM_SAWTOOTH, x, duty)


pub servo_pos(pin, pos) | x

'' Create servo-compatible pulse on pin every 20ms
'' -- pin - servo output
'' -- pos - position in microseconds (600 to 2400)

  pos := 600 #> pos <# 2400                                     ' keep legal
  x := (20_000 << 16) | US_001                                  ' setup timing
  pinstart(pin, P_PWM_SAWTOOTH, x, pos)                         ' servo output

Of course, once setup, both PWM and servo pins can be updated with wypin().

evanh · 2020-03-26 21:23

I vaguely remember JMG asked for triangle to be included. And I now think it was the second reason JMG wanted it - for maintaining a solid frequency without phase shift.

Phil Pilgrim (PhiPi) · 2020-03-26 22:00

Symmetrical (triangle) PPM generates fewer harmonics than edge-aligned PWM. This can be important in motor control and some power supply applications, since less energy goes into the harmonics. By extension, less RFI occurs at harmonic frequencies.

Of course, if the pulse width never changes, both generate the same harmonic energy, since the waveforms are indistinguishable.

-Phil

Rayman · 2020-03-26 22:45

I'm having a hard time imagining any application where this would be important...
Usually I imagine hundreds if not thousands of PWM cycles before a change is made to the setting.
Servos just use this as input. Not as the actual value going to the motor...

Ok, I guess I see that if you are generating a modulated PWM signal like on the Wikipedia page, it could be important.

evanh · 2020-03-27 01:19

Rayman wrote: »

Servos just use this as input. Not as the actual value going to the motor...

ManAtWork is already working on motor phase modulation direct from the prop2.

jmg · 2020-03-27 01:35

JonnyMac wrote: »

I struggled with the PWM nomenclature -- sawtooth and triangle refer to the behavior of the counter. The way Chip explained it to me, use triangle if you want the pulse centered around the time frame boundary, otherwise use sawtooth, which does what we expect by starting the pulse on the timing frame boundary. I'm sure people far smarter than I can explain the benefit of triangle.

If you have a single channel, they are almost the same on a pin.
Triangle becomes important when you have multiple channels (eg) 6 pins driving an AC inverter.
Here, you want dead bands between the Top and Bottom fets - you cannot do that with sawtooth counter PWM.
Triangle also allows multi-phase PWM, with less changes on a single edge, in a SMPS you may want 2 or 3 phases, designed so they nominally hand-over at the ideal operating point. This gives lowest ripple in the filters.
As Vin varies from that, the edges move slightly to give small gaps or overlaps in the times, but that still equates to low ripple currents in the filters.

IIRC Chip has a means to launch multiple smart pins in a known phase, that remains fixed.

jmg · 2020-03-27 01:39

JonnyMac wrote: »

I'm working on a P2 article for N&V right now. I will be including these two examples of PWM sawtooth mode that handle common tasks. The pwm() method is to emulate analogWrite() from the Arduino, with the added benefit of using any pin and being able to specify PWM frequency.

If you have time, it would be great to include
* A 6 pin PWM driver example (triangle) as may be used to drive the 6 MOSFETS of a 3 phase AC inverter.
* A 2 pin PWM driver example, as may be used in a 2 phase SMPS (usually high current)

evanh · 2020-03-27 01:47

JMG, that's your baby!

JonnyMac · 2020-03-27 03:34

jmg wrote: »

JonnyMac wrote: »

I'm working on a P2 article for N&V right now. I will be including these two examples of PWM sawtooth mode that handle common tasks. The pwm() method is to emulate analogWrite() from the Arduino, with the added benefit of using any pin and being able to specify PWM frequency.

If you have time, it would be great to include
* A 6 pin PWM driver example (triangle) as may be used to drive the 6 MOSFETS of a 3 phase AC inverter.
* A 2 pin PWM driver example, as may be used in a 2 phase SMPS (usually high current)

This is an intro article so those topics may be advanced, but let's talk about it for down the road. Also, Parallax is going to need material for good app notes when the P2 launches -- these sound like real opportunities.

Rayman · 2020-03-27 16:31

Yay! I'm attempting to add in two analog channels and I think it's going to work.

See pic for analog top trace.

On the down side, the minimum clock period increased from 12 to 20 clocks.
Also, had to use last remaining cog to do DDS...

Rayman · 2020-03-27 18:10

Think it's looking good now. But, out of cogs and now over 400 kB.
Fortunately, I think it almost does everything I wanted now.

Just need to add in analog trigger and DDS controls. And, maybe some cursors to measure stuff...

Publison · 2020-03-27 18:33

Ray, This is awesome. Been watching since first post.

Rayman · 2020-03-27 20:31

Was just tracking down this bug...

Before that changed one NOP in the waiting for no trigger code to an AKPIN.
This let the same code work for both digital and analog triggering (magically).

Everything was good until set trigger on Pin 23. Then, everything just froze.

Spent more time than I should have figuring out what was going on...
Turns out P23 is a USB pin. Seems it doesn't like being AK'd
Seems I have to put in some safety nets to keep from doing something not advisable...

cgracey · 2020-03-28 10:17

Ray, that's fantastic! Looks very nice and sharp.

Rayman · 2020-03-28 10:23

You can probably tell I borrowed heavily from your hdmi scope example while I figure this out ...

Rayman · 2020-03-28 23:42

Ok, I have the two analog channels working and you can trigger off any pin in analog or digital mode now.

Digital digitizer -&gt; Now mixed signal Scope + DDS

Comments

Digital digitizer -> Now mixed signal Scope + DDS