CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC18F4580 CANBus TX/RX issue - Loopback works...
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PIC18F4580 CANBus TX/RX issue - Loopback works...
PostPosted: Wed Oct 27, 2010 2:30 pm     Reply with quote

Hello fellow thinkers...

I'm currently working on a project to which uses a pre-built board we designed in house. The board has a PIC184580 mcu connected to a TJa1040 canbus transceiver chip. I know for a fact that the board hardware works because we had a company do a similar canbus firmware application for us, to which I've loaded onto the board and have successfully communicated to a PC via a PCAN-view adapter and software program. Now, we are doing firmware in house with the CCS C compiler to which I like very much I might add.

So, my problem thus far is that I cannot send / or receive messages. I have a logic analyzer hooked up to CANH, CANL, TXD (from MCU) and RXD (to MCU) of the transceiver and from what I can see the idle state of the signals is H, H, H, L respectively. However when I program the pre-made firmware into it the lines are all High and when transmitting or receiving the signals go low (HI to LOW).

I can send a message to the transceiver using the PCAN software and adapter and I can see it on the scope. However there is no output on the RXD line from the transceiver to the mcu and it seems that the PC does not like this, so it continuously sends the data over and over again. I assume it is waiting for an acknowledgment return.

So moving onto my code. I used the ex_can.c file as a template in my initial try at getting simple communication. My main c file is as follows:
Code:

#include <18F4580.h>
#fuses XT,NOPROTECT,NOLVP,NOWDT
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

#define CAN_DO_DEBUG TRUE
#include <H:\AAV\can-18F4580.c>

int16 ms;

#int_timer2
void isr_timer2(void) {
   ms++; //keep a running timer that increments every milli-second
}

void main() {
   struct rx_stat rxstat;
   int32 rx_id;
   int in_data[8];
   int rx_len;

//send a request (tx_rtr=1) for 8 bytes of data (tx_len=8) from id 24 (tx_id=24)
   int out_data[8];
   int32 tx_id=36;
   int1 tx_rtr=0;
   int1 tx_ext=1;
   int tx_len=8;
   int tx_pri=3;

   int i;

   for (i=0;i<8;i++) {
      out_data[i]=0x19;
      in_data[i]=0;
   }
   port_b_pullups(TRUE);

   printf("\r\n\r\nCCS CAN EXAMPLE\r\n");

   setup_timer_2(T2_DIV_BY_4,40,1);   //setup up timer2 to interrupt every 1ms if using 20Mhz clock

   can_init();

   //can_set_mode(CAN_OP_LOOPBACK); // loopback mode

   enable_interrupts(INT_TIMER2);   //enable timer2 interrupt
   enable_interrupts(GLOBAL);       //enable all interrupts (else timer2 wont happen)

   printf("\r\nRunning...");

   while(TRUE)
   {

      if ( can_kbhit() )   //if data is waiting in buffer...
     {
         if(can_getd(rx_id, &in_data[0], rx_len, rxstat)) { //...then get data from buffer
            printf("\r\nGOT: BUFF=%U ID=%LU LEN=%U OVF=%U ", rxstat.buffer, rx_id, rx_len, rxstat.err_ovfl);
            printf("FILT=%U RTR=%U EXT=%U INV=%U", rxstat.filthit, rxstat.rtr, rxstat.ext, rxstat.inv);
            printf("\r\n    DATA = ");
            for (i=0;i<rx_len;i++) {
               printf("%X ",in_data[i]);
            }
            printf("\r\n");
         }
         else {
            printf("\r\nFAIL on GETD\r\n");
         }
      }

      //every two seconds, send new data if transmit buffer is empty
      if ( can_tbe() && (ms > 150))
      {
         ms=0;
         i=can_putd(tx_id, out_data, tx_len,tx_pri,tx_ext,tx_rtr); //put data on transmit buffer
         if (i != 0xFF) { //success, a transmit buffer was open
            printf("\r\nPUT %U: ID=%LU LEN=%U ", i, tx_id, tx_len);
            printf("PRI=%U EXT=%U RTR=%U\r\n   DATA = ", tx_pri, tx_ext, tx_rtr);
            for (i=0;i<tx_len;i++) {
               printf("%X ",out_data[i]);
            }
            printf("\r\n");
         }
         else { //fail, no transmit buffer was open
            printf("\r\nFAIL on PUTD\r\n");
         }
      }
     
      delay_ms(100);
      output_toggle(pin_D7);
    }
}


As you can see I have a 4MHZ crystal driving the MCU. I also have a serial port to which I have successfully run the loopback CAN mode to load the tX buffer and then read it into the RX buffer...

CCS CAN EXAMPLE

FINAL OPMODE SET TO 4
FINAL OPMODE SET TO 0
FINAL OPMODE SET TO 2
Running...
CAN_PUTD(): BUFF=0 ID=00000024 LEN=8 PRI=3 EXT=1 RTR=0
DATA = 19 19 19 19 19 19 19 19

PUT 1: ID=36 LEN=8 PRI=3 EXT=1 RTR=0
DATA = 19 19 19 19 19 19 19 19

CAN_GETD(): BUFF=0 ID=00000024 LEN=8 OVF=0 FILT=0 RTR=0 EXT=1 INV=
0
DATA = 19 19 19 19 19 19 19 19

GOT: BUFF=0 ID=36 LEN=8 OVF=0 FILT=0 RTR=0 EXT=1 INV=0
DATA = 19 19 19 19 19 19 19 19

CAN_PUTD(): BUFF=0 ID=00000024 LEN=8 PRI=3 EXT=1 RTR=0
DATA = 19 19 19 19 19 19 19 19

PUT 1: ID=36 LEN=8 PRI=3 EXT=1 RTR=0
DATA = 19 19 19 19 19 19 19 19

CAN_GETD(): BUFF=0 ID=00000024 LEN=8 OVF=0 FILT=0 RTR=0 EXT=1 INV=
0
DATA = 19 19 19 19 19 19 19 19

GOT: BUFF=0 ID=36 LEN=8 OVF=0 FILT=0 RTR=0 EXT=1 INV=0
DATA = 19 19 19 19 19 19 19 19


I have read some threads on here that said that:
Code:

   CIOCON.endrhi=CAN_ENABLE_DRIVE_HIGH;

should be set to 1 so I changed the .h file to do this.
Code:
#ifndef CAN_ENABLE_DRIVE_HIGH
 #define CAN_ENABLE_DRIVE_HIGH 1
#endif

Then I noticed that the Baud rate is not setup properly for a 4MHz crystal running at my preferred BAUD rate of 250 kBPS, so I used the "ics2510bit time" program to tell me what BRGCON 1-3 should be to set it up for this mode.

And so I changed can_set_baud to:
Code:

void can_set_baud(void)
{
BRGCON1 = 0x00;
BRGCON2 = 0x91;
BRGCON3 = 0x01;
/*
   BRGCON1.brp=CAN_BRG_PRESCALAR;
   BRGCON1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;

   BRGCON2.prseg=CAN_BRG_PROPAGATION_TIME;
   BRGCON2.seg1ph=CAN_BRG_PHASE_SEGMENT_1;
   BRGCON2.sam=CAN_BRG_SAM;
   BRGCON2.seg2phts=CAN_BRG_SEG_2_PHASE_TS;

   BRGCON3.seg2ph=CAN_BRG_PHASE_SEGMENT_2;
   BRGCON3.wakfil=CAN_BRG_WAKE_FILTER;
   */
}

After all of this I still get no communication. Has anyone experienced this or something similar to it? Is there a way to make the MCU CANTX output be H to L instead of L to H? I'm pretty lost!

Thanks in advance
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Wed Oct 27, 2010 2:39 pm     Reply with quote

Oh yea and I had to change can_set_mode so that I wouldn't get stuck in the while loop when I told it to go into loopback mode:
Code:

void can_set_mode(CAN_OP_MODE mode) {
 
   set_tris_b(0b11100011);
   output_high(PIN_B3);
   delay_ms(2);
   CANCON.reqop = mode;
   delay_ms(2); 
 
   while( (CANSTAT.opmode) != mode );
   PRINTF("\n\r FINAL OPMODE SET TO %u", canstat.opmode);
   set_tris_b(0b11101011);
}
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Oct 27, 2010 3:50 pm     Reply with quote

I didn't look at your program too much. But check the hardware on your
board. The TJA1040 CAN bus transceiver chip has a Standby input which
has an internal pull-up on it. If this pin is left floating, it will pull up and
put the transceiver into Standby mode. The data sheet says:
Quote:
Pin STB provides a pull-up towards VCC in order to force
the transceiver into standby mode in case pin STB is unsupplied.


Does your "firmware" control a pin on the 18F4580 that is sets the STB
pin to a low level ? Are you doing this in your code ?
collink



Joined: 08 Jan 2010
Posts: 137
Location: Michigan

View user's profile Send private message Visit poster's website

Re: PIC18F4580 CANBus TX/RX issue - Loopback works...
PostPosted: Wed Oct 27, 2010 5:26 pm     Reply with quote

LMS_EE wrote:
Hello fellow thinkers...
So, my problem thus far is that I cannot send / or receive messages. I have a logic analyzer hooked up to CANH, CANL, TXD (from MCU) and RXD (to MCU) of the transceiver and from what I can see the idle state of the signals is H, H, H, L respectively. However when I program the pre-made firmware into it the lines are all High and when transmitting or receiving the signals go low (HI to LOW).


It shouldn't work like that. CANH has a range between middle and hi, CANL has a range between middle and low. For instance, it's simplified but let's say they both are 2.5V at rest. The bus can then be actively changed so that CANH = 5V and CANL = 0v. The two signals don't really get that high or low normally but you get the point. What you are probably seeing is that both canbus lines will be around 2-2.5v at rest and your logic analyzer probably considers that hi. It's not.

However, the canbus transceiver should be very accommodating. They are supposed to work with either CANH or CANL disconnected, shorted to power, or shorted to ground.

Quote:

I can send a message to the transceiver using the PCAN software and adapter and I can see it on the scope. However there is no output on the RXD line from the transceiver to the mcu and it seems that the PC does not like this, so it continuously sends the data over and over again. I assume it is waiting for an acknowledgment return.


If you aren't getting the message through the transceiver then it's likely a transceiver problem. You already got a suggestion about that.

Yes, the message will automatically be resent if no canbus receiver sets
acknowledgement of the frame.

Quote:

Then I noticed that the Baud rate is not setup properly for a 4MHz crystal running at my preferred BAUD rate of 250 kBPS, so I used the "ics2510bit time" program to tell me what BRGCON 1-3 should be to set it up for this mode.


The transceiver won't care what the correct baud rate is. It just handles really low level stuff like bit stuffing and handling the differential bus. It's up to the canbus hardware in the PIC chip to handle the baud rate. So, if you aren't even getting frames through the transceiver then worry about that first.
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 6:17 am     Reply with quote

Quote:

I didn't look at your program too much. But check the hardware on your
board. The TJA1040 CAN bus transceiver chip has a Standby input which
has an internal pull-up on it. If this pin is left floating, it will pull up and
put the transceiver into Standby mode. The data sheet says:
Quote:
Pin STB provides a pull-up towards VCC in order to force
the transceiver into standby mode in case pin STB is unsupplied.


Does your "firmware" control a pin on the 18F4580 that is sets the STB
pin to a low level ? Are you doing this in your code ?


The transceiver STB pin is grounded on the board i am using and therefore cannot be controlled by the mcu.


collink: yes that is correct. i set my logic analyzer to CMOS mode which has a transition point of 2.5vdc. i measured the pins with a meter and both CANL/H signals are at 2.94V, pin 1 of the transceiver (TX from the mcu) is at 4.97vdc and pin 4 (RX from the mcu) is at 1.93 vdc. so based on the canbus 2.5v threshold they are at H, H, H, L receptively.

So if the tranceiver STB pin is grounded, then it shouldnt be pulling up/down the RX/TX canbus outputs of the mcu correct? do you think isolating the mcu from the transciever is a good next step to see if i can at least get some output from the mcu? its not that the transceiver isnt passing the data its that the mcu isnt outputting anything from the get go.

By the way thanks for the responses guys!
collink



Joined: 08 Jan 2010
Posts: 137
Location: Michigan

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 8:19 am     Reply with quote

[quote="LMS_EE"]
Quote:

The transceiver STB pin is grounded on the board i am using and therefore cannot be controlled by the mcu.

collink: yes that is correct. i set my logic analyzer to CMOS mode which has a transition point of 2.5vdc. i measured the pins with a meter and both CANL/H signals are at 2.94V, pin 1 of the transceiver (TX from the mcu) is at 4.97vdc and pin 4 (RX from the mcu) is at 1.93 vdc. so based on the canbus 2.5v threshold they are at H, H, H, L receptively.

So if the tranceiver STB pin is grounded, then it shouldnt be pulling up/down the RX/TX canbus outputs of the mcu correct? do you think isolating the mcu from the transciever is a good next step to see if i can at least get some output from the mcu? its not that the transceiver isnt passing the data its that the mcu isnt outputting anything from the get go.

By the way thanks for the responses guys!


The canbus should float at about 2.5v so you are somewhat close. The bus is dominant when the voltage difference between CANH and CANL is over 0.9v and recessive if the difference is less than 0.3v I think. A difference of more than 0.5 but less than 0.9 is considered an error. So you aren't so far off there.

But the RX and TX lines of the PIC are TTL serial lines and so should be either 0V or 5V but not strange voltages in between. Did you get those voltages by looking with an oscilloscope or with a multimeter? A multimeter will likely try to average the voltage it sees if the line is transitioning between 0 and 5v.

You might try disconnecting the transceiver from the PIC RX and TX lines and then try tests at both ends. Send from the PIC while watching with a logic analyzer or oscilloscope to see if you are getting nice sharp TTL transitions. Then try sending from the PC with a LA or OS on the RX output pin of the transceiver and see if it is outputting nice TTL signals toward where the PIC would have been connected.
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 9:07 am     Reply with quote

I disconnected the transceiver TX and RX lines from the pic. when i run my program, i get RS232 outputs every time i call the can_putd function. however, there is still no output on the can TX line of the MCU. it just remains high. from the PC to the transceiver i see a nice data signal. (all the data is on the CANL line. the CANH has no data but this may be a result of the PCAN adapter.

BTW i used an oscilloscope to find the voltage levels.

on another note, is this correct? (from can_set_mode())

set_tris_b((*0xF93 & 0xFB ) | 0x08); //b3 is OUT, b2 is IN

the comment seems to have the pins backwards... im pretty sure B3 is CANRX which is an input...
collink



Joined: 08 Jan 2010
Posts: 137
Location: Michigan

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 9:16 am     Reply with quote

LMS_EE wrote:
I disconnected the transceiver TX and RX lines from the pic. when i run my program, i get RS232 outputs every time i call the can_putd function. however, there is still no output on the can TX line of the MCU. it just remains high. from the PC to the transceiver i see a nice data signal. (all the data is on the CANL line. the CANH has no data but this may be a result of the PCAN adapter.


What do you see on the other end of the transceiver. That is, when you send a signal down CANL what comes out of the RX pin on the transceiver? Does the signal propagate through the chip?

Both CANH and CANL should have data on them. They should be mirror images of each other. When the bus is asserted the CANH line should jump up in voltage by the same amount that the CANL line lowers in voltage. This creates a big voltage difference between the two. If that's not happening it might cause troubles but transceivers are supposed to deal with it and try to work anyway.

It's odd that you are getting no output from the TX pin at the PIC chip. Obviously something is not being initialized properly in hardware. Which version of the CCS compiler are you trying to use?

Quote:

BTW i used an oscilloscope to find the voltage levels.

on another note, is this correct? (from can_set_mode())

set_tris_b((*0xF93 & 0xFB ) | 0x08); //b3 is OUT, b2 is IN

the comment seems to have the pins backwards... im pretty sure B3 is CANRX which is an input...


That is the exact same line I've got in code for an 18F2685 so I'd imagine that the line is probably correct. You might want to check your chip documentation to make sure though.
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 9:41 am     Reply with quote

The CANH line does have an inverted signal on it. I checked with the scope and its there its just too small of a swing to be picked up by the logic analyzer. Also there seems to be no propagation to the RXD pin (to the mcu) but this may be due to the chip seeing the wrong voltage on the TX pin and therefore timing out.
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 11:11 am     Reply with quote

Update: So with the RX and TX pins detached I managed to get the mcu to output a signal but only briefly. The signal seems to always be the same no matter what I set the ID and data to be. Its a low to high pulse followed by 15 much smaller pulses all evenely spaced. After a few seconds however the signal goes away and the TX pin of the mcu goes high again. When I reattach TX and RX this signal no longer appears. At power up the TX line imediatley goes high.

The linked image:

http://img338.imageshack.us/i/img20101028125922.jpg/

is a transmission I made using the premade firmware. As you can see all 4 lines are normally high and when data is transferred they goe low. The bottom signal is CANL then CANH then TX (from the MCU) and finally RX at the top. I know the firmware is supposed to ping a 303 ID message when it recieves a 302 ID message and everything seems to work correctly. Is the normally high signals normal for canbus? Why is my RX line normally low in my program?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Oct 28, 2010 11:35 am     Reply with quote

Quote:
set_tris_b((*0xF93 & 0xFB ) | 0x08); //b3 is OUT, b2 is IN

the comment seems to have the pins backwards... im pretty sure B3 is CANRX which is an input...

This comment has been known to be wrong for some time.
I vaguely remember emailing CCS about it years ago.
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 28, 2010 1:22 pm     Reply with quote

So it turns out the output signal tx, from the mcu, I was seeing was nothing but the mcu resetting itself many times over again.

Heres a picture of what I was seeing when I used the below code
http://img16.imageshack.us/i/img20101028150425.jpg/

Code:

void can_set_mode(CAN_OP_MODE mode)
{
   set_tris_b(0b11100011);
   output_high(PIN_B3);
   delay_ms(2);
   CANCON.reqop = mode;
   delay_ms(2); 

   //CANCON.reqop = mode;
   while( (CANSTAT.opmode) != mode )
   {
      PRINTF("\n\r CURRENT OPMODE SET TO %u", canstat.opmode);
      PRINTF("\n\r");
   }   
   PRINTF("\n\r FINAL OPMODE SET TO %u", canstat.opmode);
   set_tris_b(0b11101011);
}

... so I'm still stuck with no outputs from the mcu and also no inputs from the transceiver to the mcu... it seems like the lines are being held in their present states somehow. The RX pin of the mcu seems to hover at 2.5 volts...
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Oct 28, 2010 2:21 pm     Reply with quote

1. Post a schematic of your board.

2. Post your compiler version.

3. Read this 3-page thread. I maybe go a little overboard in lecturing
them but in the end, the problems are shorted pins and crossed signal lines:
http://www.ccsinfo.com/forum/viewtopic.php?t=40202
LMS_EE



Joined: 27 Oct 2010
Posts: 9
Location: Georgia VT

View user's profile Send private message Visit poster's website

PostPosted: Fri Oct 29, 2010 7:08 am     Reply with quote

1. Here is the canbus related part of the circuit:
http://img576.imageshack.us/i/shadowcanbus.png/

2. My company recently purchased the ccs compiler so i hope its up to date. version 4.112

I read through the entire thread and it seems they were having hardware issues. The board I am using is a proven canbus design (not bread boarded / prototyped) to which I can load a previous firmware project into and get full canbus functionality so I don't think I have any pins crossed or what not. It has to be something in the code that I am overlooking... I must say I'm starting to dream about this thing now! Shocked

thoughts? Question

Oh and solder bridge SB1 is bridged.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Oct 29, 2010 12:59 pm     Reply with quote

I was able to make it work with my test program and my test boards.

I used 18F2580 PICs because I don't have two 18F4580's. But they are
in the same PIC family. I don't have your CAN bus transceiver chips so
I used MCP2551 chips. I used 4 MHz crystals for the PICs.

Each board has a 120 ohm resistor across CANH and CANL. There is a 3
pin cable, about 12 inches long (30 cm) connecting CANH to CANH, CANL
to CANL, and ground to ground, between the two boards.

I compiled the program below with vs. 4.112 (your version). First I made
the .HEX file for Board #1 and programmed it into that board. Then I
commented out the "#define BOARD1 1" statement and re-compiled it,
and programmed it into board #2.

I connected the RS-232 serial port on Board #1 to my PC, and loaded
TeraTerm, running at 9600 baud.

I disconnected the ICD2 cable after programming and pressed the Reset
button on both boards. Then I started typing into TeraTerm and it worked.
Local echo is "off" on TeraTerm, so it's actually working. Here's what I
typed and got back. This is copied and pasted from TeraTerm.
Quote:

Now is the time for all good men.........


I think you should get another one of your boards, and connect them
together, and try this test. Here are the cable connections between
the boards:
Code:
    rs232          CAN
PC <-----> Board1 <---> Board2


I didn't edit the can-18F4580.c or can-18F4580.h files at all. They are
fresh files from the install of PCH vs. 4.112 that I did a few minutes ago.
Code:

#include <18F2580.h>
#fuses XT, PUT, BROWNOUT, NOWDT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)

#include <can-18F4580.c>

#define BOARD1_ID  24
#define BOARD2_ID  25

// Uncomment this line to compile code for Board #1.
// Comment it out to compile for Board #2.
#define BOARD1   1   

//======================================
void main()
{
struct rx_stat rxstat;
int32 rx_id;
int32 tx_id;
int8 rx_len;               
int8 buffer[8];

can_init();


#ifdef BOARD1   // For Board #1
while(1)
  {
   buffer[0] = getc();   // Wait for a character

   // Transmit it to board #2.
   can_putd(BOARD2_ID, buffer, 1, 1, 1, 0);

   buffer[0] = 0;   // Clear the buffer byte

   // Wait for the char to be echoed back.
   while(!can_kbhit());

   if(can_getd(rx_id, buffer, rx_len, rxstat))
     {
      if(rx_id == BOARD1_ID)  // Is it for this board ?
        {
         putc(buffer[0]);  // If so, display the char
        }
      }
  }
#else  // For Board #2
while(1)
  {
   if(can_kbhit())  // Message available ?
     {
      // If so, get the message.
      if(can_getd(rx_id, buffer, rx_len, rxstat))
        {
         if(rx_id == BOARD2_ID)  // Is it for this board ?
           {
            // If so, echo back the character.
            can_putd(BOARD1_ID, buffer, 1, 1, 1, 0);
           }
         }
      }
  }
#endif
 
}
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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