PMP support on PIC24HJ128GP504 or similar [Solved]

[RF_Developer]

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.

[Ttelmah]

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]

[Ttelmah]

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]

[RF_Developer]

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]

Well done.

[newguy]

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]

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