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 support@ccsinfo.com

Software UART problem
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
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

Software UART problem
PostPosted: Wed Nov 27, 2013 11:00 am     Reply with quote

Hello, I'm trying to use 18f14k50 software UART and just relaying data from the software one to the hardware one, but when I want to use the direction software>hardware the output is saying continuously "000000..."..in the other way ( hardware>software) everything is ok.
Code:

if(kbhit(SU)){
fputc(fgetc(SU),celerom);
}


SU- SOFTWARE UART STREAM
CELEROM - HW UART STREAM

What could be the problem?
Thank you very much

Noticed something strange , sometimes the fake characters stops but if i slightly blow on the board direction they start again
Gabriel



Joined: 03 Aug 2009
Posts: 1067
Location: Panama

View user's profile Send private message

PostPosted: Wed Nov 27, 2013 12:02 pm     Reply with quote

Why would you want to send an internal value via software serial out to the world, on a cable, and back into the PIC via Hardware serial?

Why not just .... errr... use the value?


G.
_________________
CCS PCM 5.078 & CCS PCH 5.093
temtronic



Joined: 01 Jul 2010
Posts: 9198
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Nov 27, 2013 12:05 pm     Reply with quote

could be 20 to 30 different causes.....without being there and seeing the entire code it's anyone's guess..
some are...
1) bad solder joint
2) solder whisker
3) bad cap/xtal connection
4) component running hot
5) if 'breadboard' ,bad connection
6) out of spec cap/xtal
7) faulty MAX232 or similar chip
8) faulty PIC
9) intermittant wiring connection
10) out of spec power supply.
11) not using xtal ?
12) static ?
....

would have to see a small,compilable program to check all the code.could be a bottleneck problem(different UART speeds,no buffers,handshaking,???)

as a general comment, software UARTs are not the best, though I've used them for 30+years.....
better PIC might be the 18F46K22 as it has 2 hardware UARTS.might cost a few pennies more but has a LOT of features.
while most designers try to use the smallest,cheapest PIC for the job at hand they forget to consider the cost of R&D lost time figuring out WHY something(like a software UART) doesn't work like it should(on paper).
I tend to 'overspec' the PIC as you always need more RAM,ROM, UARTS,timers,pins, etc. It's a whole lot cheaper at the end of the day!!

hth
jay
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

PostPosted: Wed Nov 27, 2013 12:54 pm     Reply with quote

Hi again
Code:

#include <18F14K50.h>
#FUSES NOWDT, WDT128, CPUDIV1, INTRC_IO, NOFCMEN, NOIESO, BORV27, NOHFOFST, NOMCLR, NOLVP, NOXINST
#use delay(clock=32000000)
#use rs232(uart1, BITS=8,baud=9600, PARITY=N, STOP=1, STREAM=SU,ERRORS)
#use rs232(baud=9600, BITS=8, PARITY=N, STOP=1, STREAM=CELEROM,xmit=PIN_C3,RCV=PIN_C7)

void main()
{
setup_comparator(NC_NC_NC_NC);
setup_adc_ports( NO_ANALOGS );

while(1)
  {
   if(kbhit(celerom))
     {
      fputc(fgetc(celerom),SU);
     }
   if(kbhit(SU))
     {
      fputc(fgetc(SU),celerom);
     }
  }
}


This is my very basic program. Trying just to move data from one place to another. Gabriel, I'm doing this as later I want to parse the data that is coming through both ways.
Gabriel



Joined: 03 Aug 2009
Posts: 1067
Location: Panama

View user's profile Send private message

PostPosted: Wed Nov 27, 2013 1:07 pm     Reply with quote

To receive via software uart you basically have to be constantly polling the line.... this means you get stuck in fgetc() once you call it until a character arrives... and THEN kbhit gets set...

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093
Ttelmah



Joined: 11 Mar 2010
Posts: 19434

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 2:20 am     Reply with quote

Lets just clarify slightly.

kbhit on the software stream goes 'true', when the incoming line is seen as 'low'. Nothing else.
Once it goes low, you need to get into getc, within a few uSec, and the code will then stay in getc, for the whole character time.
putc on the serial stream, stays in putc, for a character time. During this time, anything happening on the incoming side, _will_ be missed.

The software serial, is 'half duplex'. It can only send _or_ receive at any point in time. If data arrives, while characters are being sent, it is lost.

The CCS software serial is not going to do what you want. If data is arriving, needs to be parsed, and retransmitted at the same time, you are going to lose data.

Choices:

1) Simplest, cheapest, switch to a PIC with multiple hardware serial ports. There are dozens now, often with the second serial 'relocatable' onto different pins. Makes the job very easy.
2) Add a second PIC. One of the small chips with hardware serial, then have this buffer the data and send it to the main chip via I2C etc..
3) Add an external I2C UART.
4) Get slightly more complex, and do timer interrupt based 'software' RS232. I've posted the receive side for such an implementation (the harder half), on the code forum. It is fairly easy to add a transmit half to this (I have code for this if required).

What you are trying to do, just won't work with the CCS software UART.

Best Wishes
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 4:06 am     Reply with quote

Thank you very much , i got my hands today on some 18f25k22 , I`l try with them.
Gabriel



Joined: 03 Aug 2009
Posts: 1067
Location: Panama

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 6:16 am     Reply with quote

Quote:
Lets just clarify slightly
.

Thanks for that... its clearer now to me as well.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 9:36 am     Reply with quote

More and more problems...I setup a board with 18f25k22 and do a fprintf for both hardware uarts , but the 2ND one it wont output nothing...is this a faulty pic..or what?
the #use rs232 are the default ones from the compiler:
Code:


#use rs232(baud=9600,parity=N,bits=8,stream=PORT1)
#use rs232(baud=9600,parity=N,bits=8,stream=PORT2)

I checked the wires 10 times , no problem there..
Gabriel



Joined: 03 Aug 2009
Posts: 1067
Location: Panama

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 9:47 am     Reply with quote

the second uart is probably sharing pins with another peripheral.. like a comparator or whatever...

make sure you have disabled any hardware sharing that pin.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 10:03 am     Reply with quote

I see in the datasheet that the second UART TX shared only with the PGC programming pin...witch i plug it out when running...so..it must be something else..
in the meanwhile I come back to my 18f14k50 design..on each UART the RX/TX pins are "Bridged" togheter via a HEX BUFFER 74LS07 for half/duplex operations. but it wont work corectly at all..I`m receiving bad data in the terminal test..just trying to "move" data from one UART to another whitout getting the ECHO that comes from bridging the pins togheter...here is the code:
Code:

#include <18F14K50.h>
#FUSES NOWDT, WDT128, CPUDIV1, INTRC_IO, NOFCMEN, NOIESO, BORV27, NOHFOFST, NOMCLR, NOLVP, NOXINST
#use delay(clock=32000000)
#use rs232(uart1, BITS=8,baud=9600, PARITY=N, STOP=1, STREAM=A,errors)
#use rs232(baud=9600, BITS=8, PARITY=N, STOP=1, STREAM=B,xmit=PIN_C3,RCV=PIN_C7,float_high) //SOFTWARE UART


 
#int_RDA
void  RDA_isr(void)
{
putc(fgetc(A),B); // As software UART dont have buffer it is not necesarly to empty stream B RX buffer.
}

void main()
{
setup_comparator(NC_NC_NC_NC);// This device COMP currently not supported by the PICWizard
setup_adc_ports( NO_ANALOGS ); // disable analog inputs
enable_interrupts(INT_EXT);
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);


WHILE(1)
{
while(!kbhit(B));
disable_interrupts(INT_RDA); // Disable RX to prevent character echo
fputc(fgetc(B),A);
enable_interrupts(INT_RDA);
}
}
Ttelmah



Joined: 11 Mar 2010
Posts: 19434

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 10:07 am     Reply with quote

pulurumbuluruciu wrote:
More and more problems...I setup a board with 18f25k22 and do a fprintf for both hardware uarts , but the 2ND one it wont output nothing...is this a faulty pic..or what?
the #use rs232 are the default ones from the compiler:
Code:


#use rs232(baud=9600,parity=N,bits=8,stream=PORT1)
#use rs232(baud=9600,parity=N,bits=8,stream=PORT2)

I checked the wires 10 times , no problem there..


Er. That sets up two _streams_, but both are using UART1....

Code:

#use rs232(UART1,baud=9600,parity=N,bits=8,ERRORS,stream=PORT1)
#use rs232(UART2,baud=9600,parity=N,bits=8,ERRORS,stream=PORT2)


Get in the habit of always using 'ERRORS' when using a hardware UART. This is _required_, when using the hardware UART, unless _your code_ handles errors. Without this, if a received character is missed, the UART will be hung...

Then fputc(PORT1,val) will talk to UART1, and fputc(PORT2,val) will talk to UART2.

Best Wishes
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 10:30 am     Reply with quote

Hahah...Ttelmah...spot on..like always..it works now
pulurumbuluruciu



Joined: 06 Nov 2013
Posts: 27

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 10:40 am     Reply with quote

Code:

#int_RDA
void  RDA_isr(void)
{
DISABLE_interrupts(INT_RDA2);
fputc(fgetc(U1)U2);
ENABLE_interrupts(INT_RDA2);
}
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
#int_RDA2
void  RDA2_isr(void)
{
DISABLE_interrupts(INT_RDA1);
fputc(fgetc(U2)U1);
ENABLE_interrupts(INT_RDA1);
}
////////////////////////////////////////////////////////////////////////////////

Is this wrong to do? disable one interrupt within another? Trying to prevent echo.
temtronic



Joined: 01 Jul 2010
Posts: 9198
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Nov 28, 2013 12:25 pm     Reply with quote

generally speaking it is wrong to disable/enable interrupts witin the ISR as the compiler will handle it however you're disabling the other UART, kinda bad programming.

you should look at the CCS example 'ex_sisr.c' in the examples folder to see how to handle data from the UARTS using ISRs and buffers. Their code is easy to modify for 2 UARTs and works flawlessly at 115K200 baud.

hth
jay
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