 |
 |
| View previous topic :: View next topic |
| Author |
Message |
pieter
Joined: 16 Jan 2011
Posts: 27
|
| Pic24 Second RS232 port not working |
 Posted: Fri Mar 11, 2011 12:40 pm |
 |
|
Dear all,
I use 2 uarts. In my example below, Uart 1 works fine but uart 2 does not transmit. I measure the Tx lines with a scope. Do I have a mistake somewhere?
| Code: |
//
//***********************************************
// *
// Test Program
// *
//***********************************************
//
//
#list
#include <c:\mpc\devices\24HJ256GP610.h>
#device ADC=12
#FUSES WDT //Watch Dog Timer
#FUSES NOWRTB //Boot block not write protected
#FUSES NOBSS //No boot segment
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOWRT //Program memory not write protected
#FUSES FRC_PLL //Internal Fast RC Oscillator with PLL Enabled
//#FUSES NOCKSFSM //Clock Switching is disabled, fail Safe clock monitor is disabled
#FUSES NOOSCIO //OSC2 is general purpose output
//#FUSES PR_PLL //Pimary oscillator
//#FUSES XT
//#FUSES NOWINDIS //Watch Dog Timer in Window mode
#FUSES WPRES128 //Watch Dog Timer PreScalar 1:128
#FUSES WPOSTS16 //Watch Dog Timer PostScalar 1:32768
#FUSES PUT128 //Power On Reset Timer value 128ms
//#FUSES IOL1WAY //Allows only one reconfiguration of peripheral pins
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES NORSS //No secure segment RAM
#FUSES NOSSS //No secure segment
#FUSES NOWRTSS //Secure segment not write protected
#FUSES NORBS //No Boot RAM defined
#FUSES NODEBUG //No Debug mode for ICD
//#FUSES NOCOE //Device will reset into operational mode
#FUSES NOJTAG //JTAG disabled
//#FUSES ICSP3 //ICD uses PGC3/PGD3 pins
//#FUSES NOALTI2C //I2C mapped to alternate pins
#use delay(clock=7370000,RESTART_WDT) // rc osc <---------
#use rs232(baud=19200,Uart2, xmit=PIN_F5, rcv=PIN_F4,Errors, STREAM=PUSB) // Rs232 2
#use rs232(baud=19200,Uart1, xmit=PIN_F3, rcv=PIN_F2,Errors, STREAM=RS232) // Rs232 1
#id 0x0001
#PRAGMA ZERO_RAM
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
#use fast_io(F)
#use fast_io(G)
#byte PLLFBD = 0x746 // bits 8--0 = Pll div = 0x1e
#byte CLKDIV = 0x744 // bits 7--6 = Pll post = 0 // bits 4--0 = Pll Pre = 0
//
// Pin definitions
#define Led Pin_A0
#define Buzzer Pin_G13
#define Led2 Pin_E4
#define URst Pin_B12
//
//**********************************************************************************
//
main()
{
PLLFBD=0x1e;
CLKDIV=0;
RESTART_WDT();
SETUP_ADC_PORTS(No_Analogs);
SET_TRIS_A(0xffca); // 1111 1111 1100 1010
SET_TRIS_B(0xeffb); // 1110 1111 1111 1011
SET_TRIS_C(0x9fff); // 1001 1111 1111 1111
SET_TRIS_D(0x003e); // 0000 0000 0011 1110 //
SET_TRIS_E(0xe7); // 0000 0111 //
SET_TRIS_F(0xfe57); // 1111 1110 0101 0111 //
SET_TRIS_G(0x8ff8); // 1000 1111 1111 1000
Output_A(0x0000);
Output_B(0x0000);
Output_C(0x0000);
Output_D(0x0000);
Output_E(0x00);
Output_F(0x0000);
Output_G(0x0000);
Output_High(Led);
Output_High(Buzzer);
delay_ms(100);
Output_High(URst); // enable USB
Output_Low(Buzzer);
fprintf(PUSB,"TestProg 4 USB Port");
fprintf(RS232, "TestProg 4 RS-232");
//
while (TRUE)
{
RESTART_WDT(); // reset watchdog
Output_High(Led);
Output_Low(Led2);
delay_ms(300);
Output_High(Led2);
delay_ms(300);
fprintf(RS232, "TestProg 4 RS-232 1");
Output_Low(Led);
delay_ms(400);
fprintf(PUSB,"TestProg 4 RS-232 2");
}
}
|
Thanks |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9188
Location: Greensville,Ontario
|
|
| Posted: Fri Mar 11, 2011 1:47 pm |
|
|
While I don't use that chip, a general observation.
Since you're not a true 'expert' programmer, get rid of the 'use fast_io, and set_tris...' functions.
Let the compiler handle the those details.You might lose a microsecond or two in execution speed but a simple misuse of those functions can cause you no end of problems!
I suggest letting the compiler do the work, then IF you need more speed,try the commands but read up on them first!!! |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Mar 11, 2011 5:06 pm |
|
|
| temtronic wrote: | While I don't use that chip, a general observation.
Since you're not a true 'expert' programmer, get rid of the 'use fast_io, and set_tris...' functions.
Let the compiler handle the those details.You might lose a microsecond or two in execution speed but a simple misuse of those functions can cause you no end of problems!
I suggest letting the compiler do the work, then IF you need more speed,try the commands but read up on them first!!! |
There is not enough awareness of how problematic it can be letting the compiler handle I/O direction automatically. For example, any application that needs to drive a chip select to an external device should not let the compiler drive the I/O direction.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 11, 2011 5:19 pm |
|
|
Are you saying that output_high() and output_low() don't work reliably
in Standard i/o mode ? If so, it's very rare, and would be a temporary
bug in the compiler .DLL for a newly released PIC. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Mar 11, 2011 5:33 pm |
|
|
| PCM programmer wrote: | Are you saying that output_high() and output_low() don't work reliably
in Standard i/o mode ? If so, it's very rare, and would be a temporary
bug in the compiler .DLL for a newly released PIC. |
I first encountered the problem in 3.x software and just spent two weeks helping a customer debug an issue in current software that was caused by this issue. The compiler, when manipulating the direction, even when manipulation was not required, effectively floats the I/O pin long enough for an external SPI attached device, such as an SD/MMC card, to see a transition on the chip select.
I think the reason the problem "appears" rare is because most external devices would not notice such a short term transition.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 11, 2011 5:44 pm |
|
|
I compiled the following program in vs. 3.249. I assume pin C2 is used
for chip select. That's fairly common.
| Code: |
#include <18F452.h>
#fuses XT,NOWDT,PUT,BROWNOUT,NOLVP
#use delay(clock=4000000)
//======================================
void main(void)
{
output_low(PIN_C2);
output_high(PIN_C2);
while(1);
} |
Here's the .LST file. In the Pin C2 statements, the TRIS is always set to
be an output. I don't see how the compiler is doing anything that floats
pin C2.
| Code: | .................... void main(void)
.................... {
0004: CLRF TBLPTRU
0006: BCF RCON.7
0008: CLRF FSR0H
000A: CLRF FSR0L
000C: BSF ADCON1.0
000E: BSF ADCON1.1
0010: BSF ADCON1.2
0012: BCF ADCON1.3
.................... output_low(PIN_C2);
0014: BCF TRISC.2
0016: BCF LATC.2
....................
.................... output_high(PIN_C2);
0018: BCF TRISC.2
001A: BSF LATC.2
....................
.................... while(1);
001C: BRA 001C |
|
|
|
sseidman
Joined: 14 Mar 2005
Posts: 159
|
|
| Posted: Fri Mar 11, 2011 6:07 pm |
|
|
| asmallri wrote: | | PCM programmer wrote: | Are you saying that output_high() and output_low() don't work reliably
in Standard i/o mode ? If so, it's very rare, and would be a temporary
bug in the compiler .DLL for a newly released PIC. |
I first encountered the problem in 3.x software and just spent two weeks helping a customer debug an issue in current software that was caused by this issue. The compiler, when manipulating the direction, even when manipulation was not required, effectively floats the I/O pin long enough for an external SPI attached device, such as an SD/MMC card, to see a transition on the chip select.
I think the reason the problem "appears" rare is because most external devices would not notice such a short term transition. |
I agree. I've helped out some folks locally, and I swear their code should have worked, but it didn't until I specifically set up ports with the TRIS command. I didn't delve into it deeply enough to convince myself that it was a compiler bug, but I've stopped letting the compiler set this on its own, and I control the directions of the ports. If your bits are unidirectional, I don't understand why this would be problematic.
I also find it helps students understand things at a more fundamental level, even with things that seem simple, like simple conversions between hex and binary, and some of the concepts students just seem to have trouble picking up when they come from a classical programming environment, like the relationships between the hardware and the software.
When people advise that programmers should let the compiler handle the tris, what sort of mistakes do they worry about people making?? It seems much simpler to me than, say, working out counter math (dividers, preloads, etc.) to get your timing right. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Mar 11, 2011 6:09 pm |
|
|
Your right. I see nothing in this code segment that would cause a problem. Perhaps a more complicated example is required to see if it an optimization issue. Unfortunately I do not have the customer's code to see where it went wrong.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9188
Location: Greensville,Ontario
|
|
| Posted: Fri Mar 11, 2011 7:55 pm |
|
|
| I must be one of the 'lucky' ones since I've been programming PICs for over 1/4 century and have never run into any problems by letting the compiler handling the I/O ports automatically. Yes, you can get a small increase in speed and performance in doing it 'manually', but the OP's test program wouldn't really have benefitted from this.From a training perspective(ie: teaching students) it's far better to start them off in assembler.Heck, most PICs only have 35 instructions, so you hardly need a 'cheat sheet' pocket guide unlike the Z80 and 6800 of past decades! It is important to dump the listings of programs you create to actually see what's going on.Reviewing the code may show better(faster or less memory) ways of doing a certain function or routine.Comparing how two compilers create code for the same program can be an eye opener. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Mar 12, 2011 3:07 am |
|
|
Although the above discussion is interesting, the original poster may consider it as off-topic related to his clearly stated problem.
As far as I see, the code is correctly accessing the respective SFR registers when compiled with a recent PCD version. Are you sure that you are probing the right output pin? What's your PCD version? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
