| View previous topic :: View next topic |
| Author |
Message |
Study
Joined: 09 Apr 2009
Posts: 29
|
| question about getc()!! |
 Posted: Sun May 29, 2016 8:38 am |
 |
|
Hi friends
As i read on CCS help, on getc function it waits for new char but in my program it skips getc if no char recieve too!!
this is my main loop:
| Code: | while(1)
{
input_buffer[0] = getc();
//! if(input_buffer[0] == device_address)
//! {
//! input_buffer[1] = getc();
//! input_buffer[2] = getc();
//! input_buffer[3] = getc();
//! make_decision();
//! }
//delay_ms(500);
output_toggle(run_led);
}
|
and this is my #use
| Code: | #use delay(crystal=8MHz,restart_wdt)
#use rs232(baud=9600,parity=N,xmit=PIN_C3,rcv=PIN_C4,bits=8,stream=PORT1,restart_wdt) |
When i run this program "run_led" blinks ever no char receive from uart!!
I mean it doesn't wait on "input_buffer[0] = getc();"
why?!! i use only stdio.h.
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
 |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sun May 29, 2016 10:06 am |
|
|
Hi,
You should always post a small, compilable test program for us to test, rather than just a few code snippets....
What PIC?
What compiler & version?
Hardware or software UART?
What is connected to the Rx input?
Now, a couple of things. You've defined a 'stream' in your #use rs232 directive, but don't use it. You should be using 'fgetc(Port1)' instead. Also, you should never do anything with the WDT while testing your code! This will only lead to headaches!
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sun May 29, 2016 10:19 am |
|
|
also
ALWAYS ADD 'errors' to the use rs232(... options...) or the hardware will choke !
Jay |
|
|
Study
Joined: 09 Apr 2009
Posts: 29
|
|
| Posted: Sun May 29, 2016 10:58 am |
|
|
| ezflyr wrote: | Hi,
You should always post a small, compilable test program for us to test, rather than just a few code snippets....
What PIC?
What compiler & version?
Hardware or software UART?
What is connected to the Rx input?
Now, a couple of things. You've defined a 'stream' in your #use rs232 directive, but don't use it. You should be using 'fgetc(Port1)' instead. Also, you should never do anything with the WDT while testing your code! This will only lead to headaches! |
Thanks for your answers
16F877a
PCM 5.048
software uart
tx from avr micro
I didn't know about what stream is!!
It's not my final program, i have to add wdt on my final program so i add it in my wizard now but wdt is disable in this program and i'll enable it later.
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun May 29, 2016 11:55 am |
|
|
C4 on this PIC, is a Schmidt input. Requires the signal to go up to 4v, to be seen as a 'high'. The Arduino, is a 3.3v device internally. It's output, will never be seen as 'high' by your PIC input. Result getc will return about 1mSec after it is called, and will always return 0.
Seriously, your approach is not likely to work. Using software serial, the PIC has to be sitting _waiting_ for the data to arrive. It'll miss the data if it arrives before the PIC is ready. There is no buffering on software serial. You really need to have the Arduino send a signal to say 'I am about to send', just before it transmits, connected to perhaps the PIC EXT_INT pin, which then triggers the PIC code to be ready to receive. |
|
|
Study
Joined: 09 Apr 2009
Posts: 29
|
|
| Posted: Sun May 29, 2016 12:24 pm |
|
|
| Ttelmah wrote: | C4 on this PIC, is a Schmidt input. Requires the signal to go up to 4v, to be seen as a 'high'. The Arduino, is a 3.3v device internally. It's output, will never be seen as 'high' by your PIC input. Result getc will return about 1mSec after it is called, and will always return 0.
Seriously, your approach is not likely to work. Using software serial, the PIC has to be sitting _waiting_ for the data to arrive. It'll miss the data if it arrives before the PIC is ready. There is no buffering on software serial. You really need to have the Arduino send a signal to say 'I am about to send', just before it transmits, connected to perhaps the PIC EXT_INT pin, which then triggers the PIC code to be ready to receive. |
Thanks Ttelmah
I didn't say anything about arduino!! i said avr microcontroller, our avr TX output is 5 volt and can be detect by pic RX input pin, we have enough time between each byte that avr sends and nothing will lost.
As i said the only problem here is that i don't know why program skips putc() ever while nothing on pic software rx pin exist!!
+: i have removed stream and wdt too but nothing changed at all.
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun May 29, 2016 1:22 pm |
|
|
Take pin C4.
Disconnect it from the input.
Pull it up to 5v.
Does the PIC still not stop?.
Now, as an earlier poster has said, your test program should be _complete_. Something we can compile.
There are all sorts of things that could cause problems. For instance you might have fast_io or fixed_io selected, and not have C4 programmed as an input. What is then 'seen' when this bit is read, would depend on what was in the output latch.
Your output pin on the AVR, _will not be 5v_. If you think it is, you need to think again. Look in the data sheet at what Voh is specified to be for the pin you are using. |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Sun May 29, 2016 1:38 pm |
|
|
Post a SHORT complete compilable program we can copy and paste.
(Only include the minimum to show your problem.)
Otherwise we are all wasting our time.
Mike |
|
|
Study
Joined: 09 Apr 2009
Posts: 29
|
|
| Posted: Sun May 29, 2016 3:17 pm |
|
|
| Code: |
#include <16F877A.h>
#device ADC=10
#FUSES PUT, NOLVP
#use delay(crystal=8MHz,restart_wdt)
#use rs232(baud=9600,parity=N,xmit=PIN_C3,rcv=PIN_C4,bits=8,restart_wdt)
#define m_pwm PIN_C1
#define m_dir PIN_C2
#define power_led PIN_C5
#define run_led PIN_C6
============================
#include <8.h>
#include <stdio.h>
//------------------ global vars ----------------
unsigned int8 device_address;
unsigned int8 input_buffer[4];
//------------------- functions -----------------
void setup();
void address_select();
void make_decision();
void pwm_stop();
//--------------------- main --------------------
void main()
{
setup();
//set_pwm2_duty(100);
while(1)
{
input_buffer[0] = getc();
if(input_buffer[0] == device_address)
{
input_buffer[1] = getc();
input_buffer[2] = getc();
input_buffer[3] = getc();
make_decision();
}
//delay_ms(500);
output_toggle(run_led);
}
}
//-------------------- setup --------------------
void setup()
{
set_tris_b(0x00);
set_tris_c(0x10);
set_tris_d(0xFF);
output_high(power_led);
output_low(run_led);
address_select();
setup_ccp2(CCP_PWM);
setup_timer_2(T2_DIV_BY_1, 127, 1);
set_pwm2_duty(0);
output_b(0xFF);
}
//---------------- address_select ---------------
void address_select(void)
{
unsigned int8 temp;
// make sure portd is input
temp = input_d();
temp &= 0x0F;
switch(temp)
{
case 0x00: device_address = 130; break;
case 0x01: device_address = 131; break;
case 0x02: device_address = 132; break;
case 0x03: device_address = 133; break;
case 0x04: device_address = 134; break;
case 0x05: device_address = 135; break;
case 0x06: device_address = 136; break;
case 0x07: device_address = 137; break;
case 0x08: device_address = 138; break;
case 0x09: device_address = 139; break;
case 0x0A: device_address = 140; break;
case 0x0B: device_address = 141; break;
case 0x0C: device_address = 142; break;
case 0x0D: device_address = 143; break;
case 0x0E: device_address = 144; break;
case 0x0F: device_address = 145; break;
}
}
//--------------- make_decision -----------------
void make_decision()
{
if( ((input_buffer[0]+input_buffer[1]+input_buffer[2])&127) == input_buffer[3])
{
if(input_buffer[1] == 0)
{
output_low(m_dir);
}
if(input_buffer[1] == 1)
{
output_high(m_dir);
}
if(input_buffer[2]>120)
{
input_buffer[2] = 120;
}
if(input_buffer[2]<4)
{
input_buffer[2] = 0;
}
//if(input_buffer[1] == 0)
//setup_ccp2(CCP_OFF);
set_pwm2_duty(input_buffer[2]);
output_b(input_buffer[2]);
}
}
|
it doesn't stop on getc in proteus simulator too!
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun May 29, 2016 3:48 pm |
|
|
Measure the idle voltage on the Rx pin (Pin C4 in your case) with a
voltmeter or an oscilloscope. The idle voltage is the voltage that is
on the pin when no data is being transmitted by the AVR to the PIC.
What is the voltage that you measure ? |
|
|
Study
Joined: 09 Apr 2009
Posts: 29
|
|
| Posted: Sun May 29, 2016 4:13 pm |
|
|
| Ttelmah wrote: | Take pin C4.
Disconnect it from the input.
Pull it up to 5v.
Does the PIC still not stop?.
|
I have been testing on simulator and it didn't work, after pulling it up it stops now.
Thanks friends and sorry for wasting your time 
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sun May 29, 2016 4:35 pm |
|
|
| Let me guess... Proteus/ISIS ??? |
|
|
Study
Joined: 09 Apr 2009
Posts: 29
|
|
| Posted: Sun May 29, 2016 10:54 pm |
|
|
| temtronic wrote: | | Let me guess... Proteus/ISIS ??? |
Yes, I said proteus on my post why you want to guess?
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon May 30, 2016 1:12 am |
|
|
Read the sticky at the top of the Forum.
Isis _does not work_.
It has faults in a lot of it's parts.
Trying to 'design' PIC circuits using Isis, wastes your time, and ours. |
|
|
Study
Joined: 09 Apr 2009
Posts: 29
|
|
| Posted: Mon May 30, 2016 1:33 am |
|
|
| Ttelmah wrote: | Read the sticky at the top of the Forum.
Isis _does not work_.
It has faults in a lot of it's parts.
Trying to 'design' PIC circuits using Isis, wastes your time, and ours. |
but here my problem was not about isis!! after using pull up on proteus isis it works well and i'm going to do it on real hardware. I accept isis has some bugs but not so bad too!! maybe it's better than nothing, isn't it?!! 
_________________
Sorry if i have much mistakes, my english is not good.
Thanks a lot for your helps.
Have a good time |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
