Port Control Module and PORTx_PCMy

[flightyalrighty]

K60 Sub-Family Data Sheet, Rev. 3, 6/2013, section 8.1 provides a table with 10 different configurations for each pin, and states the PCM "is responsible for selecting which ALT functionality is available on each pin."  Simple enough, I want the ALT2 configuration according to that table. Is that one write to a PCM register or multiple writes? How do I decode what's in the table in 8.1 to lines of code? I see lots of examples in the forums where people suggest code snippets like:

     PORTC_PCR16=PORT_PCR_MUX(3); 

I am using KDS and ProcessorExpert. I find a file called MK60F12.h under ProcessorExpert/lib/Kinetis/iofiles which has a collection of these #defines, so we have basically a statement with three arguments:

      PORTx_PCRy = PORT_PCR_MUX(n) ; 

• "x" in PORTx (for my chip, x is from the set {A, B, C, D, E, F})
• "y" in _PCRy (for my chip, y goes from 0-31)
• (n) in PORT_PCR_MUX(n) (PORT_PCR_MUX is a macro taking a 32-bit unsigned integer)

So it seems there might be a rather large number of possible combinations, but one would naturally assume there's some simple means of matching up Section 8.1 with the appropriate values of x, y and n for each ALT configuration? I don't find any further details in the K60 Sub-Family Data Sheet, nor in the User's Guide for the dev boards I'm using (NXP TWR-K60F120M and NXP TWR-K60D100M). Is there one "missing link" document that closes this gap?

Thanks

[mjbcswitzerland]

Hi

To configure and use a port pin there are 3 things to do (if peripheral) or 4 if GPIO:
1. Enable the clocks to the port in question
2. Configure the peripheral/GPIO function
3. Configure the characteristics (pull-up/down/open-drain, driver strength, slew rate)
4. If GPIO, define the direction and state

The macro you show is for step 2.

Eg. to set PTA13 for CAN0_RX function it would be


PORTA_PCR13 = PORT_PCR_MUX(2);

This means that you need to look up the ALT function in the data sheet and plug it into the macro (it may or may not be portable between devices since sometimes the ALT number changes).

The uTasker project (see its macros at http://www.utasker.com/forum/index.php?topic=1875.0) is more user friendly and portable since it does it with

_CONFIG_PERIPHERAL(A, 13, (PA_13_CAN0_RX | PORT_PS_UP_ENABLE));
which handles all steps and makes it more readable and reduces error possibilities.

In the uTasker simulation the pin capabilities and actually programmed one are shown as below:

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K60:
- http://www.utasker.com/kinetis/TWR-K60N512.html
- http://www.utasker.com/kinetis/TWR-K60D100M.html
- http://www.utasker.com/kinetis/TWR-K60F120M.html
- http://www.utasker.com/kinetis/ELZET80_NET-KBED.html
- http://www.utasker.com/kinetis/ELZET80_NET-K60.html

For less questions and faster, cheaper developments: try uTasker for Kinetis

[flightyalrighty]

Thanks Mark. It turns out that selecting the AsynchroSerial bean from ProcessorExpert is the better choice than the Init_UART bean; the former provides more integration and allows me to select the appropriate mux pins from the dropdown.

I am using the AsynchroSerial bean in a project for the "F" version of the dev board, and the same bean in a project for the "D" version. They both are configured through ProcessorExpert with the same set of parameters, and the D board is able to communicate over the serial line to a PC. The F board, however, has some weirdness with the clock generator - the baud rate is just enough off that a PC can't understand it. I'm not sure if this is a defect in my F board, or some subtle difference between them that ProcessorExpert hasn't accounted for. They appear to be using the same source clock, clock multipliers and dividers and parameters to all those devices. Of course with asynch comms, it's difficult to perfectly determine the clock rate since it's not explicit in any output signal. I have attempted to measure it with characters like 0x5As and so on.