CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PMP support on PIC24HJ128GP504 or similar [Solved]

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PMP support on PIC24HJ128GP504 or similar [Solved]
PostPosted: Tue Oct 04, 2016 7:30 am     Reply with quote

Having chosen the PIC24HJ128GP504 for a new project, and my first with 24 series PICs, I have found that there doesn't appear to be any PMP (Parallel Master Port) support in the compiler, despite the chip definitely having the hardware.

I have checked the Microchip support list and PMP support is not listed for this device, nor its relatives :-( I am using PCD 5.056 in the CCS IDE, also 5.056.

I have fired off a support request, but as we've let our support lapse (yet again...) I am not expecting a quick response.

Has anyone any expereince of using the PMP on this chip or any from the same family? Any advice? I shall probably cut my own support code for it anyway.

This is for a remote interface project: I am using these PICs to talk to a TNT4882 GPIB chip on one and a 10/100 LAN chip, the ENC624J600, on another. A third PIC24HJ128GP504 handles control and USB (via an FTDI FT230X). This is also my first (mainly) 3.3V project, and so far all is going well, at least is was until I discovered there was no compiler support for the PMP.


Last edited by RF_Developer on Thu Oct 06, 2016 5:13 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Tue Oct 04, 2016 8:09 am     Reply with quote

Do you have the IDE?.

If so, Tools, Device editor. Select 'other features'. About three quarters the way down the list 'Par Mast Port'. Change to 'PMP'. Save.

Then find another chip with the same hardware, and copy the section from the include file giving the setup_pmp function prototypes, and defines, and add this to the include for your processor.

You should find it then works.

It appears to have been omitted from dozens of chips.

CCS are quite responsive to this sort of problem, and will probably correct it almost instantly for you. Don't be surprised if you have an answer overnight.
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Oct 04, 2016 9:04 am     Reply with quote

Ttelmah wrote:
Do you have the IDE?


Yes.

Quote:
If so, Tools, Device editor. Select 'other features'. About three quarters the way down the list 'Par Mast Port'. Change to 'PMP'.


Got that far... looking promising.

Quote:
Save.


This is where it fell down :-( I could not save, I just got a "File access denied" dialogue. Grrr. It's probably Windows 10 being over protective. I've tried taking off read-only on the PICC directory - no go. I DO have admin rights on this machine.

I'd already got to the point of editing (a copy of) the header, so that's covered. I just can't get the device facilities saved :-(( Good to hear CCS are responsive with this sort of issue, and it's nearly the end of the day here, so I'll probably wait and see if they can come up with a fix. On the other hand, bad to hear functionality such as this, yet again, is "missed" seemingly so casually.
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Tue Oct 04, 2016 9:13 am     Reply with quote

If you are on W10, you'll need to enable write permissions on 'devices.dat', and select 'run as administrator' when you launch CCS.
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Oct 04, 2016 9:27 am     Reply with quote

Ttelmah wrote:
If you are on W10, you'll need to enable write permissions on 'devices.dat', and select 'run as administrator' when you launch CCS.


That fixed the save problem; phew. Thanks.

At least I have got something PMP related compiling at last - spent most of the afternoon on this.

Let's see what the next few days brings...
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PMP support on PIC24HJ128GP504 or similar [Solved]
PostPosted: Thu Oct 06, 2016 5:11 am     Reply with quote

Well... the new header/database got the compiler up and running, but I was far from out of the woods as it turned out :-( Clearly the PMP is rarely used: there is very little about it here or on the web generally. I have got it to work, but the software support has a problem or two associated with it. Note that I am just talking about getting it to work in my application, which means with demuxed 8 bit data and less than 8 bit addresses. I am in Intel compatible mode, i.e. with CS, RD and WR signals, all active low.

The pmp_read() routine didn't. That's to say, it's meant to wait for a busy bit to clear and then trigger a read cycle by reading a data register. That's fine; it certainly waits, but then it simply doesn't read anything! I had to temporarily comment out #nolist in the header to see what code was really being generated. Then there is a sequencing issue: reading the register triggers a read cycle, but it does not return the result of the read, instead you get the result of the previous read. You have to read again to get the result, triggering a second cycle in the process! it would work better with blocks of sequential reads, where there would only be one read cycle overhead for the block. Random reads actually need two. For simple (i.e. non-multiplexed) reads, such as mine, the busy bit is not set by the hardware, so you can't wait for the read to finish.

Even two reads in hardware, wait states not withstanding, are likely to be faster than bit bashing the control signals, which is my fall-back in case of disaster with the hardware.

Getting the hardware to generate chip selects is... well, not simple. You have, in effect, to enable CS in three places: the control register, the address mask register and in the actual address sent to the external device! it probably would be simpler, and hardly any less effective/efficient to bit-bash.

I haven't even got to writes yet, but I think/pray that's easier.

My adventure with the PMP continues, but as far as the primary purpose of this thread is concerned, I consider this issue solved.
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Thu Oct 06, 2016 7:22 am     Reply with quote

Well done. Smile
newguy



Joined: 24 Jun 2004
Posts: 1908

View user's profile Send private message

PostPosted: Thu Oct 06, 2016 7:55 am     Reply with quote

When I first migrated to a dsPIC I found a similar issue with the v4 compiler at the time: the CAN routines that worked so well on lower PIC platforms (PIC18)...didn't. The v5 compiler was still fairly young at the time and the bug reports here didn't give me a lot of confidence in it - there was enough doubt to make me leery of using v5. So I studied the data sheet, the registers, etc and basically "rolled my own" CAN driver. A pain at the time, but looking back I'm glad that I was forced to learn it in such depth. I eventually used the processor's DMA capability to handle the CAN which made things hugely efficient and gave me a very substantial performance boost. And I had to write the DMA driver pretty much from scratch too.

I guess what I'm trying to say is that even though there's been some frustration and pain in getting PMP to work, you're ending up with more robust code than if CCS' drivers had worked "out of the box."
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Fri Oct 07, 2016 1:34 am     Reply with quote

20 years or so ago, this was true for even the most basic peripherals (SPI etc..). Now the libraries for this sort of thing are comprehensive and reliable. However on more complex peripherals, they almost invariably need some 'tweaking'. There is a problem here in the way CCS 'do things'. For USB for example, the whole library is done as include files, allowing you to change things (for instance I have USB MSD running, and for this you have to add quite a few extra bits to the interrupt handler). They are aware of this here, even having comments in the file saying that this is where stuff has to go. Unfortunately on many of the other complex peripherals, this is not the case (CAN PSP etc..).
I must admit I found the comment about #list amusing. The very first thing I do to the header file of every PIC I'm actually using, is to remark out the #list. I want to see everything that happens. Why put it back?. It doesn't make anything simpler, having bits of code that 'disappear', is not a way to really track down what is happening....
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group