UserUNFRIENDLY port mappings on PIC24F series!

[Thermal Runaway]

Hi all,

I'm experimenting with a 16-bit micro for the first time and, as I've traditionally used PICs for all my designs (I'm not a fanboy I just stick to what I know), I decided to give the PIC24F series a go.  To that end, I've started designing a development board that I can play around with.

Now that I'm starting to go through the datasheet for the device in some detail, I've found that the port mappings for it are a real pain in the backside.  Details as follows:

Ports B and D are full 16-bit wide ports, so no problem there.

Port A is only 12 bits wide, and instead of just mapping them as RA0 to RA11 they've done it as follows: RA0 to RA7, RA9 to RA10, and then RA14 to RA15.  WHY?!?!

Port C is even more annoying.  It's only a 6-bit port for a start, which is pretty annoying as it means you can't use it for any 8-bit wide tasks, but the REALLY annoying thing is the way they've mapped it: RC1 to RC4 (yes that's right, no RC0) and then RC12 to RC15.

Other ports are mapped in a similarly annoying fashion.

I don't understand why they would design it this way.  It's not a show stopper of course - I can create bit masks to make sure I write to the bits that I want to - but I just find the port mappings to be unnecessarily annoying.

Any comments?

Device in question: PIC24FJ128GA010

Brian H

[mikeselectricstuff]

It is pretty unusual to need contiguous ports on a microcontroller - most of the time you're using individual bits. You've already got two full 16 bit ones and an 8 bit which is more than a lot of other parts, especially considering that the PIC24 goes way better than many other parts in that the peripheral functions can be mapped to a very wide range of pins to avoid breaking up port groups.

[EEVblog]

I agree with Mike, I'm mostly using them as individual pins anyway, so it's not a problem.
No idea why they would map them like that though, likely something to do with compatibility across devices/packages or some such.

Dave.

[TheDirty]

I've been getting a lot of this with other microcontrollers.  I thought the PIC24 had definable peripherals to pins?  I don't have any experience with PIC24, but the reason it's done on the chips I'm using is that they have peripherals mapped to specific pins throughout the line, so port 0, pin 4 and 5 are UART RX and TX, so if they want UART on a smaller chip they have to include those pins, but maybe not pin 6 and 7 which are CAN H and L, and so it goes so you have a few pins here and there from each port.  Usually a full port or two will be included, though.

[Mechatrommer]

this complaint is quite similar to mine with pic banking system in a thread here sometime ago. yeah! annoying! i guess there is specific design constraint that unable them to sort nicely, or maybe other ergonomics reason to the pcb design generally, they made their research? who knows? i dont know. but you can remap the port and define your own map such as

Code: [Select]

#define MYPORT0 PORT11
#define MYPORT1 PORT2
#define MYPORT2 PORT8
etc

more annoying if i have to redefine the bank for each pin as well!

Code: [Select]

#define MYPORT0BANK BANK2
#define MYPORT1BANK BANK0
#define MYPORT2BANK BANK1 !!!



ps: my previous answer was... to reduce production/design cost, and hence cheaper chip.

[monpjc]

I've been getting a lot of this with other microcontrollers.  I thought the PIC24 had definable peripherals to pins?  I don't have any experience with PIC24, but the reason it's done on the chips I'm using is that they have peripherals mapped to specific pins throughout the line, so port 0, pin 4 and 5 are UART RX and TX, so if they want UART on a smaller chip they have to include those pins, but maybe not pin 6 and 7 which are CAN H and L, and so it goes so you have a few pins here and there from each port.  Usually a full port or two will be included, though.

this is what feedback I've had from Microchip. The silicon is designed for the top end xhundres of pin device so when they scale it back to say 24 pins this odd chopping off of I/O happens. Its as you say - you still want to offer UARTs are I2C etc but these 'happen' to be only mappable to certain I/O pins though the PPS system the microchip use. Hence you will find RC0 missing blah, blah blah.

Also agree that 'normally' you will not need continuous I/O unless interfacing with something like a LCD display. But one sub routine to chop up a word and throw it a differing I/O pins is not too hard - annoying yes - not clean, but all part of the firmware engineers plight against the silicon designers! ;o)

[mikeselectricstuff]

If you think about a big chip with ports neatly arranged in order around the edge of the die, then shrink that die, it is a lot easier to just omit pins periodically than shuffle everything round the edge.

[Thermal Runaway]

Thanks for the replies everyone - some quite valid points.  I also have to conceed that the use of contiguous pins is much less common than the use of separate pins/peripherals.  I also agree with monpjc that it is possible to solve the dodgy port numbering in software, so it's no show stopper or anything like that.  But if you do need some contiguous pins and you have to use one of the 'dodgy' ports to do it, then this can be quite annoying.

On a very similar subject, I also find the physical pin layout on these devices a bit irritating.  For example, instead of having all of porta on one side of the chip, the porta pins are scattered around the entire device - and same for the other ports too.

Again, if your use of the pins is strictly on an individual basis or if you're using peripherals (for which the pins do generally seem to be bunched together) then it's not too much of a problem.  But if you're trying to access an entire port as a bus then it makes the PCB routing an absolute 'mare.  I have that problem with my current project because, although I am designing with a specific circuit in mind, my board needs to be 'hackable' in such a way that circuitry can be wired to it retrospectively, so I've decided to break out all of the port pins to some standard 2.54mm (inches do not exist - sorry guys) connectors.  Naturally, my preference is to have a connector devoted to each port and to number them sensibly, so the PCB routing is a right pain!

Brian.