• AVR Freaks

Hot!dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC?

Author
firmwareNovice
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/02/17 22:01:18
  • Location: 0
  • Status: offline
2020/05/19 18:28:31 (permalink)
0

dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC?

Hi All,
 
I'm currently using the dsPIC33CK256MP506 on a personal project of mine. I'm liking it a lot, and am using the peripheral trigger generator (PTG) and DMA to trigger and store data from the ADC at a sample rate of 5 Msps at 12 bits, ( and this is at with two channels independently, way past the specs of the part actually). 
 
This has worked well for me, but I'm hoping to use external ADCs to obtain faster sampling, using the parallel port peripheral.
 
The ADC I was planning on using was the AD9283, link below.
https://www.analog.com/en/products/ad9283.html#product-overview
 
 
 
However, when I try to configure the parallel port peripheral with MCC, the code configurator, I get some text saying that the peripheral is not supported for my device.
 
So I've got two questions:
 
1. Does does my device (dsPIC33CK256MP506 in a TQFP-64 package) even have a parallel port peripheral? If it does, then I can configure it by just reading the manual, but I just want to confirm that my device has this peripheral before doing a hardware design. For reference, I'm getting the prompt shown below.
 
2. If it does have a parallel port, can I use the REFCLOCK out of my device to trigger the AD9283 to perform a conversion AND trigger my device to read the result via the parallel port?
 
Any help would be appreciated. Thanks!
 
 
 
 
#1

9 Replies Related Threads

    JPortici
    Super Member
    • Total Posts : 1017
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/19 22:55:40 (permalink)
    0
    "Does does my device (dsPIC33CK256MP506 in a TQFP-64 package) even have a parallel port peripheral?"
    datasheet, device pinout. Table 1-1 has the description of the pins if you don't know what you are looking for!
     
    Haven't used it so i don't know how much faster you can get than from a peripheral in the internal bus.. Man it's been on my to do list since forever!
    What are you planning to do that require a faster ADC? have you thought about how much time you have between samples to process the data?
    #2
    du00000001
    Just Some Member
    • Total Posts : 3675
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/20 02:51:55 (permalink)
    5 (2)
    • Although the MP506 has a PMP, I'd go for a simple DMA scheme instead as this won't add a delay.
    • I don't see that you can trigger PMP reads directly via REFCLOCK, although there are ways to do it indirectly.
    firmwareNovice
    ... before doing a hardware design. ...
     

     
    You think about doing a hardware design but cannot extract the most simple information from the datasheet? Really? Might result in some entertaining threads in the forum...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #3
    firmwareNovice
    New Member
    • Total Posts : 11
    • Reward points : 0
    • Joined: 2019/02/17 22:01:18
    • Location: 0
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/20 10:15:29 (permalink)
    0
    Thanks!
     
    So I've seen Table 1 on the datasheet and seen that the device does have a PMP. I just didn't know if I should trust it, since the datasheet also has known silicon bugs (such as the SCCP peripheral being able to trigger an ADC conversion, which it cannot grin: grin)
     
     
    "Haven't used it so i don't know how much faster you can get than from a peripheral in the internal bus.. Man it's been on my to do list since forever!
    What are you planning to do that require a faster ADC? have you thought about how much time you have between samples to process the data?"
     
     
    I'm using the two independent ADC cores on the dspic33ck256MP506 to capture transmit and receive waveforms simultaneously. I then run cross-correlation to get time-of-flight in post-processing on the dspic, using the dspic libraries, which are really nice but kind of a pain to start learning at first. So there's actually no need to process data in between the ADC samples.
     
    An external faster ADC would give me more time resolution, vs. the 200ns time resolution I'm getting now using the dspic's ADCs.
    #4
    firmwareNovice
    New Member
    • Total Posts : 11
    • Reward points : 0
    • Joined: 2019/02/17 22:01:18
    • Location: 0
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/20 10:36:09 (permalink)
    0
    Hi du00000001,
     
    That's a fair point in extracting this info from the datasheet before contemplating a hardware design. It's been a while since I've looked at the datasheet for my device actually. 
     
    • Although the MP506 has a PMP, I'd go for a simple DMA scheme instead as this won't add a delay.
    • I don't see that you can trigger PMP reads directly via REFCLOCK, although there are ways to do it indirectly
     
    Really quick question. The external (8-bit) ADC I was planning on using has 8 parallel outputs. In order to read that data, wouldn't I have to do a "port read" using the PMP?
     
    Or maybe there's another way. What did you mean by using a simple DMA scheme? Sorry if these questions seem simple to you. I'm a little new to this microcontroller stuff
    #5
    firmwareNovice
    New Member
    • Total Posts : 11
    • Reward points : 0
    • Joined: 2019/02/17 22:01:18
    • Location: 0
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/20 10:43:29 (permalink)
    0
    Hi du00000001,
     
    I'm looking through the DMA datasheet right now and I'm just wondering.
     
    Can we actually just use the DMA, put it in Fixed Source, Incrementing Destination mode, and set the Source Address to say....Port A (if I was connecting the 8 ADC outputs to Port A)?
     
    #6
    du00000001
    Just Some Member
    • Total Posts : 3675
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/20 13:50:07 (permalink)
    0
    firmwareNovice
    Hi du00000001,
     
    That's a fair point in extracting this info from the datasheet before contemplating a hardware design. It's been a while since I've looked at the datasheet for my device actually. 
     
    • Although the MP506 has a PMP, I'd go for a simple DMA scheme instead as this won't add a delay.
    • I don't see that you can trigger PMP reads directly via REFCLOCK, although there are ways to do it indirectly
     
    Really quick question. The external (8-bit) ADC I was planning on using has 8 parallel outputs. In order to read that data, wouldn't I have to do a "port read" using the PMP?
     
    Or maybe there's another way. What did you mean by using a simple DMA scheme? Sorry if these questions seem simple to you. I'm a little new to this microcontroller stuff



    To cut things a bit short:
    • A DMA transfer from a port would just cooy the value available at the pins. If you implement this by using DMA (which needs some trigger as well), this would be the fastest way to access the data.
    • A PMP read triggers a lot of action (that also takes some time, thus adding delay) and copies - - - the value acquired as a result of the last PMP read trigger. Thus adding even more delay.
    Your external ADC doesn't have control lines to be serviced (other than the conversion start input). Thus, the PMP approach (that is designed to service all the fancy control lines your ADC doesn't need) would be overkill.
     
    Answering your 2nd post:
    Yes - it's about that simple. Could be you have to route the REFCLOCK signal through 1 CLC (as you need some DMA trigger - and to cope for the ADC's delay following the conversion start event), but I'd consider this a minor issue. What you have to be aware of: the ADC adds a 4-stage pipeline delay to be considered when calculating the TOF.
    BTW: why don't you try to use one of these fancy and reasonably priced TOF sensors ?

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #7
    firmwareNovice
    New Member
    • Total Posts : 11
    • Reward points : 0
    • Joined: 2019/02/17 22:01:18
    • Location: 0
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/20 20:39:46 (permalink)
    0
    Hi du00000001,
     
    Wow, I didn't even think about that. Okay, a parallel port read it is then. I'm actually thinking about using the peripheral trigger generator to initiate a DMA transfer. This is what I have in my current hardware/firmware revision, and it works really well.
     
    I'm not really too concerned about the 4-stage pipeline delay. Because I sample both the transmit and receive waveforms and perform a cross-correlation, a relative time-of-flight between the two is what I'm really after.
     
     
    I've done a little bit of investigation on TOF sensors and time-to-digital-converter (TDC) ICs, particularly the TDC7200 and TDC1000. While those may have been the easier and more compact solution, the real reason I went for the approach I did was because I had pretty weak embedded hardware/firmware development, so I wanted to improve that skillset.
     
    I had to say, it was a pretty great learning experience, after many dozens of hours of reading the datasheet and troubleshooting and perusing through online forums LoL: LoL
     
     
    #8
    du00000001
    Just Some Member
    • Total Posts : 3675
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/21 04:00:06 (permalink)
    0
    Oh - I somewhat missed the 2-channel measurement:
    Provided there's at least 1 port that has all 16 bits routed to pins (I didn't go as far as checking this - checked only for 8 Bits), you could even get away with a synchronous word-wide read of both ADCs (synchronously triggered as well) per DMA - resulting in the least-possible resource consumption.
     
    If this project is intended to improve your skills: accepted. Have fun!  Smile
     
    Re TOF sensors:
    ST has created a nice set of TOF sensors - especially the VL53* family. While they are somewhat secretive about their algorithms, I consider these chips state of current art. THey may be hard to use as they have a real mass of features. And most important: they do not rely on really measuring the time oF - there exists a clever scheme that employs what I'd call "charge ratiometric measurements" - the only way to have arrays of e.g. 16x16 TOF sensors evaluated simultaneously.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    firmwareNovice
    New Member
    • Total Posts : 11
    • Reward points : 0
    • Joined: 2019/02/17 22:01:18
    • Location: 0
    • Status: offline
    Re: dsPIC33CK: dsPIC33CK256MP506 Parallel Port Peripheral (PMP) "not supported" on MCC? 2020/05/22 11:48:22 (permalink)
    0
    Hi, 
     
    Yep. That's what I was thinking. Route both 8-bit ADC outputs to a single port and do a single port read. Then do an 8-bit shift to separate the ADC outputs from one another.
     
    Interesting. These are not quite what I was looking for, since these use optical transmitters, (whereas I'm using ultrasonic transducers). Noted though. They could be useful for me in the future.
    #10
    Jump to:
    © 2020 APG vNext Commercial Version 4.5