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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
Last edit: Jacques Nilo 2015-04-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
Last edit: William Roth 2015-04-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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
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
Answer to myself: yes that was it ! The following two lines must be inserted BEFORE the two Dir PORTb statements:
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
Last edit: Jacques Nilo 2015-04-25
@Jacques. Keep posting these updates. We can update chip handler baseline code later for others.
@Anobium. Problem found. Will open a new thread in the compiler section.
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.
Last edit: William Roth 2015-04-26
@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
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.
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.
For more information on the Peripheral Pin Select, check out this Microchip Page:
https://microchip.wikidot.com/8bit:pps