UART on PIC16F1709 does not work. A PPS issue ?

[Jacques Nilo]

Hello all
I have just received my PIC16F1709 and was eager to test it with the new 0.94 GCB release.
I was able to flash a led :-) but I cannot succeed to run the following program trying to test the serial connection to a terminal

#chip 16F1709, 8
#define USART_BAUD_RATE 19200
Dir PORTb.7 Out
Dir PORTb.5 In
wait 500 ms
do Forever
  HSerPrint "Hello World"
  HSerPrintCRLF
  wait 200 ms
Loop

I am suspecting that the dir portb statements do not work since the 16F1709 has a Peripheral Pin Select module that need to be used - I suspect - to declare the TX and RX ports.
Has anyone ever tried to use PPS with GCB ?
Jacques

[Jacques Nilo]

Answer to myself: yes that was it ! The following two lines must be inserted BEFORE the two Dir PORTb statements:

RXPPS=0xD          'Peripheral input is RB5 (p140 of the datasheet)
RB7PPS=0x14        'Pin RB7 source is TX/CK (p141 of the datasheet)
Dir PORTb.7 Out
Dir PORTb.5 In

After that the program compiles and runs ok.
I now have a new problem: HSerReceive statement does not compile ok with this chip. I have to investigate that further...
Jacques

[Anobium]

@Jacques. Keep posting these updates. We can update chip handler baseline code later for others.

[Jacques Nilo]

@Anobium. Problem found. Will open a new thread in the compiler section.

[William Roth]

If the PPS bits must be configured before there is any TX output then this will likely affect the PIC Models Listed below. This may also affect the operation of other peripherals.

Device            Status

PIC16F1703      In Production    
PIC16F1574      In Production    
PIC16F1704      In Production    
PIC16F1614      In Production    
PIC16F1575      In Production    
PIC16F1705      In Production    
PIC16F1618      In Production    
PIC16F1707      In Production    
PIC16F1578      In Production    
PIC16F1615      In Production    
PIC16F1708      In Production    
PIC16F1579      In Production    
PIC16F1619      In Production    
PIC16F1709      In Production    
PIC16F1713      In Production    
PIC16F1716      In Production    
PIC16F1718      In Production    
PIC16F1717      In Production    
PIC16F1719      In Production    
PIC18F24J11     In Production    
PIC18F25J11     In Production    
PIC18F24J50     In Production    
PIC18F44J11     In Production    
PIC18F25J50     In Production    
PIC18F26J11     In Production    
PIC18F45J11     In Production    
PIC18F44J50     In Production    
PIC18F26J13     In Production    
PIC18F26J50     In Production    
PIC18F45J50     In Production    
PIC18F46J11     In Production    
PIC18F27J13     In Production    
PIC18F46J13     In Production    
PIC18F46J50     In Production    
PIC18F27J53     In Production    
PIC18F46J53     In Production    
PIC18F47J13     In Production    
PIC18F47J53     In Production

PIC16F1764      Samples Available    
PIC16F1765      Samples Available    
PIC16F1768      Samples Available    
PIC16F1769      Samples Available    
PIC16F18313     Future Product   
PIC16F18323     Future Product   
PIC16F18324     Future Product   
PIC16F18325     Future Product   
PIC16F18344     Future Product   
PIC16F18345     Future Product   
PIC16F18854     Future Product   
PIC16F18855     Future Product   
PIC16F18856     Future Product   
PIC16F18857     Future Product   
PIC16F18875     Future Product   
PIC16F18876     Future Product   
PIC16F18877     Future Product   
PIC18F26K40     Future Product   
PIC18F27K40     Future Product   
PIC18F46K40     Future Product   
PIC18F47K40     Future Product   
PIC18F24K40     Future Product   
PIC18F25K40     Future Product   
PIC18F45K40     Future Product

[Jacques Nilo]

@William: you are right. What I proposed is a "quick fix" to illustrate how to adress the problem for a specific chip (i.e. 16F1709) and a specific module (EUSART) if of one wants to use those kind of chips, which - as you mention - are getting more and more popular (and inexpensive :-) ). But I guess we would all agree on the fact that it is clearly not the purpose of an high level language to write directly into a PIC register...
So I guess the key question is how to handle Microchip Peripheral Pin Select (PPS) module in GCB in the future. A question to Hugh and the development team I guess. Should we think about developping a pps.gcb library ?
Jacques

[Chuck Hellebuyck]

If possible, I would propose that each chip file have predefined PPS connections so there is a default setting for each pin. The same way configuration settings are predefined.
Then using #define these PPS connections can be changed.
i.e.

#define uarttx1 PORTA.0

This would require a new set of reserved names for each peripheral pin but would allow the GCB user to change pin locations as easy as they assign an alias name to a port pin or currently control libraries like LCD connections.
i.e.

#define LED1 PORTB.2
#define LCD_Enable PORTD.2

For more information on the Peripheral Pin Select, check out this Microchip Page:
https://microchip.wikidot.com/8bit:pps