Why this PBP code will blink PortB LED's but not the one on PortC?
I am seeing a very strange thing in this very simple code (PBP v 2.6C) when I try to run it on my EASYPIC6. The EASYPIC6 has built in LEDs for every Port output. I have two that are blinking on PortB but the one that is coded the very same way on PortC will not blink. Can anyone tell me why?
I also don't understand why the FineLine Editor automatically bolds the PORTC alias but not the PORTB aliases??
Code:
'< FL_PIC18F4550 >' ' First valid PIC found within the first 200 lines will
' highlight AND set device.
'***********************************************************************
'* Name : BLINKY_EASYPIC6.pbp *
'* Author : John R. Ellis *
'* Notes : 1) This code was designed/devloped on an EasyPic6 *
'* Compiler: PICBASIC PRO Compiler 2.60C from microEngineering Labs *
'* Device : 18F4550 *
'* Memory : 188 bytes of Program Memory required. *
'***********************************************************************
' -----------------------[ Program Description ]------------------------
' PICBASIC PRO program to blink LED on EASYPIC6 *
''**********************************************************************'-----------------18F2550/4550 Port/PIN Connections ]-------------------
'I/O pin connections to the 18F4550 MCU are as follows:
'PORTC.4 (15) connected as RED_LED
'PORTC.5 (16) connected as GRN_LED
'INCLUDE "CodeSize.pbp" 'FOR TEST ONLY
DEFINE Measure 1
;@ StartSize(LOOKUP) 'FOR TEST ONLY
INCLUDE "18F2550_4550_CONFIGS.pbp" ' Setup CONFIGS for MCU
'--------------[ Define Hardware / Set Registers ]------------------------
DEFINE OSC 16 ' Using 8 MHz crystal
Include "Modedefs.Bas" ' Mode definitions for Debug,Serin/out,
' Shiftin/out, Xin/out.
INCLUDE "ALLDIGITAL.pbp" ' Sets all registers for digital ops.
' User must make sure AllDigital.pbp file
' is in same or higher directory location as
' this source code before compiling.
'DEFINE SHOWDIGITAL 1 ' When uncommented will show analog settings
' in Assembler Results window.
TRISA = 0 ' PortA reserved as output connections to LCD interface
TRISB = %00001100 ' RB2 & RB3 reserved as RTC Alarm1 & Alarm2 inputs
' PORTB.2 is also an input from switch grounding
' PortB.4 is used for LED_RED
' PortB.5 is used for tthe GRN_LED
TRISC = 0 ' PortC is all Outputs
CLEAR
'--- Variables -----------------------------------------------------------
LED_RED VAR PORTB.4 ' Red LED
LED_GRN VAR PORTB.5 ' Green LED used to indicate Routine entries
LED_EASYPIC VAR PortC.5
'Setup for starting Main Program
'Initialize LEDs to off
LOW LED_GRN
LOW LED_RED
LOW LED_EASYPIC
'--------------------[ Begin Main Program Loop ]-------------------------
;@ StartSize(MainLoop) ; FOR TEST ONLY
mainloop:
' Blink LEDs
PAUSE 5000
HIGH LED_GRN
HIGH LED_RED
HIGH LED_EASYPIC
PAUSE 1000
LOW LED_GRN
LOW LED_RED
LOW LED_EASYPIC
WRITE 255,9 'Write to EEPROM as Test if executing to this location
GOTO mainloop
;@ EndSize(MainLoop) ; Uncomment FOR TEST ONLY
End ' Safety measure to insure program stops if reaches here
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Data sheet section 10.3
Quote:
Unlike other PORTC pins, RC4 and RC5 do not have
TRISC bits associated with them. As digital ports, they
can only function as digital inputs. When configured for
USB operation, the data direction is determined by the
configuration and status of the USB module at a given
time. If an external transceiver is used, RC4 and RC5
always function as inputs from the transceiver. If the
on-chip transceiver is used, the data direction is
determined by the operation being performed by the
module at that time.
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Which model of PIC does this refer to??
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Hi,
The code targets the 18F4550 so I'm guessing that's it. PortC4-5 are the USB-pins which is probably why they can't be made into normal outputs - for some specific reason.
/Henrik.
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Quote:
Originally Posted by
HenrikOlsson
Hi,
The code targets the 18F4550 so I'm guessing that's it. PortC4-5 are the USB-pins which is probably why they can't be made into normal outputs - for some specific reason.
/Henrik.
Thanks, Dave and Henrik. Yes, I am using a 18F2550_4550, and I missed that in the Data sheet. Since my PCB is already designed for the 28 pin 18F2550, I guess my only recourse now is to find a 28 pin chip counterpart to the 18F2550 that doesn't have USB that will let me use the RC4 and RC5 pins as outputs. Thanks so much for setting me straight on this....I have been troubleshooting this for 5 days and never thought to check out the multiplexing of the RC4/RC5 pins.
Re: How to replace 18F2550 with function/pin equivalent that still provides I2C?
OK guys...one more question that I hope you will help me answer. I have been looking for a replacement MCU that has all the functions of the 18F2550 that I have been using except the USB module, and that is pin compatible to the 28 pin version of the 18F2550. The closest I have so far been able to find is the 16F886, which appears to be pin compatible and has all the functions. However, one difference I can't quite resolve:
1) The 18F2550 in my application is wired on my PCB to use its SDA pin 21 and its SCL pin 22 in an I2C interface to control two peripheral devices.
2) Since I am looking to replace the 18F2550 on an existing PCB that is already routed that way, I need to confirm I can still use the 16F886 pins 21/22 as SDA/SCL signals to control the I2C devices.
3) The data sheet on the 16F886 says it supports I2C interface, but requires use of RC3(pin15)/RC4(pin16) as SCL and SCD respectively, which pins I already have routed on my PCB for other functions.
Somewhere I seem to remember someone on this forum saying that the SCL and SCD pins on MCUs only have to be used in an I2C interface when the MCU is operating as a slave and if it is the Master controller for other devices operating as slaves, that any I/O pins can be used as the outputs for the I2C control bus. Is that true? If so, how do I set up other PortB pins 21/22 as the I2C bus interface to control my peripherals?? Would really appreciate your advice on this!
Re: How to replace 18F2550 with function/pin equivalent that still provides I2C?
If you can re-do your code to use the I2CREAD/I2CWRITE command then you should be good.
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Hi,
To expand on Dave's answer a bit... If you're using the I2C peripheral (MSSP module) in the PIC then you must use the pins to which this peripheral is connected (on some PICs you can switch them to alternative pins but I don't think that's possible on the 16F886). If you're using I2CWRITE/I2CREAD, which is bit-banged and doesn't use the MSSP module, you can use "any" pins you want - as long as the pin used for clock can be an output and the pin used for data both in (for I2CREAD) and out (for I2CWRITE).
It's true that the MSSP module (the SCL/SDA pins) HAVE to be used when the PIC is the slave but it CAN equally well be used when the PIC is the master. However, there are no PBP commands to directly "drive" the use of the MSSP module (like there is for the USART etc).
/Henrik.
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Really? I never thought about pbp doesn't support slave mode for I2C. This certiainly makes me re think so mtuff I am currently working on. Hmmmm shame.
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
When using I2CREAD/WRITE the PIC is "in control" of the line, ie it supplies the clock and is therfor the master (same as with SHIFTIN/OUT). Because of this IC2READ/WRITE won't work for a slave type device, however the MSSP module setup in I2C mode will, you just have to "drive it manually".
/Henrik.
Re: Why this PBP code will blink PortB LED's but not the one on PortC?
Thanks henrik, just in time to fix what I was doing. I think I did some bit banging slave stuff a few (>5) years ago in ASM, no desire to repeat that!! Off to make sure chip selection supports slave mode I2C.
