 |
 |
View previous topic :: View next topic |
Author |
Message |
Mike Walne
Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK
|
|
Posted: Sun Jun 24, 2012 1:30 pm |
|
|
You've got a fundamental problem getting a PC to talk to your PIC.
CCS supplies two programmes which show you how.
(1) EX_STISR.C
(2) EX_STR.C
One uses interrupts, the other doesn't.
Maybe some clues?
Try one or the other, see if they help.
Mike |
|
 |
Dave_25152
Joined: 11 Dec 2010 Posts: 60
|
|
Posted: Sun Jun 24, 2012 1:43 pm |
|
|
OK.
Thank you!
I'll test both and see what results. |
|
 |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Jun 26, 2012 2:29 am |
|
|
The ex_stisr and ex_str programs are good examples of how to implement an interrupt driven serial communication but the interrupt also make things more complex to understand. In your simple application things are not working so it is best to get this right before moving on to the interrupt driven approach.
Quote: | The problem is that when I write "num = valor[1]" (for example) appears in the terminal "num = 50". | I'm not really sure I understand what you are doing, but this doesn't look like a problem to me.
valor[1] is the second character you type because in C array counting starts at 0.
Your second character in the string "1234" is a '2'
Note that you are sending a string, not a value.
In the ascii-table you see that the binary representation of the character '2' is the decimal value 50.
Situation explained, there is no problem.
Code: | printf ("%s\n\n\n", valor); | Strange, but in your posted code I don't see a response corresponding with these 3 newline characters. Is the code as posted belonging to the screen capture?
Quote: | I've tried to take "setup_uart", but after the serial port no longer works. | This is not how it is supposed to be.
- What is your compiler's version number? (a code like 4.xxx)
- Post your complete code, including the #fuses at the program start. Especially important because in your first versions you had an unusual sequence of configuration lines.
A few more hints:
- Indentation has improved but is still not optimal.
- Try to minimize the use of delay_ms. You are using it in many places where it has no effect at all and only makes your program less responsive. |
|
 |
Dave_25152
Joined: 11 Dec 2010 Posts: 60
|
|
Posted: Tue Jun 26, 2012 10:10 am |
|
|
Thanks to everyone for the answers.
After the first cycle, the string is "null" at position 0.
I did some tests and concluded that the value remained after the first cycle.
In the code below I set aside the first and only receive data in subsequent cycles is that do the processing.
Code: | #include "16lf1827.h"
#use delay (internal=1000000)
#fuses INTRC_IO, NOLVP, NOWDT, NOMCLR, NOIESO, PUT, NOBROWNOUT
#use RS232(baud=4800, xmit=PIN_B2,rcv=PIN_B1,PARITY=N,BITS=8)
void main()
{
int16 num;
int8 i, valor[8];
setup_adc(0);
setup_oscillator(OSC_1MHZ|OSC_NORMAL);
setup_uart(TRUE);
output_high(PIN_A6);
delay_ms(150);
output_low(PIN_A6);
delay_ms(150);
fgets(valor);
while(TRUE)
{
output_high(PIN_A6);
delay_ms(150);
output_low(PIN_A6);
delay_ms(500);
fgets(valor);
delay_ms(1000);
num=0;
for(i=1;i<=4;i++)
{
num=num*10;
num=num+valor[i]-48;
}
printf ("\n\r\r%s\n\r", valor);
delay_ms(1000);
printf("valor=%Ld\n\r\r", num);
output_high(PIN_A6);
delay_ms(1000);
output_low(PIN_A6);
}
} |
Computer terminal.
Code: |
1803 - PC to PIC - This is the first line, so the program does not process these data.
1803 - PC to PIC
1803 - PIC to PC
valor=1803 - PIC to PC
1234 - PC to PIC
1234 - PIC to PC
valor=1234 - PIC to PC
|
A bit confusing, but it works ....  |
|
 |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Jun 26, 2012 3:51 pm |
|
|
1) The sequence of the first #include and #fuses lines is not as told by PCM Programmer.
2) Temtronic told you about the very important ERRORS directive. It is missing in the #use RS232 line and the UART will stall after 3 unread characters. That would also explain why you need the extra call to setup_uart(TRUE).
3) You didn't post your compiler version as asked so we can't reproduce your exact situation.
4) To make it work you are processing starting at valor[1] instead of offset 0. Probably because you are sending CR+LF (it is shown in your screen dump). Ttelmah explained why this is a problem and gave a solution of just sending CR.
You are hard headed, aren't you?
I'm going to follow the advice of my other forum members and get out of here.
Good luck. |
|
 |
Dave_25152
Joined: 11 Dec 2010 Posts: 60
|
|
Posted: Tue Jun 26, 2012 6:19 pm |
|
|
Hello
This code results of several tests, using all advice given by the members here.
1 - I've seen in some places on the internet as well and used that way. I'll fix immediately!
2 - If I put the call to "ERRORS" and take "setup_uart" I no longer can use port ...
I do not know if it's just my problem, but does not work here.
3 - It was missing the compiler version: v4.114
4 - I searched but can not find how to send only "CR" to toll the pickit. Can you tell me how I should do?
If I take the selection of the "CR + LF" the PIC fails to respond to my commands.
I think I'm doing poorly understood.
When you write here, I'll test the code right solutions.
Sometimes better, but sometimes not. When no improvement, I try to go drawing lines to see what happens.
Probably I'm doing me misunderstand.
My apologies.
Thanks to everyone for the support! |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 19803
|
|
Posted: Wed Jun 27, 2012 1:26 am |
|
|
I have a 'nasty suspicion', that the terminal code you are using has faults. I think if you select to not send 'CR+LF', it sends 'LF' only, not 'CR'. The standard 'gets' function, looks for the 'CR' character, so 'LF' is not accepted....
Now, there is a better replacement in input.c. This is better in two ways:
First, you have the source code, so can change what characters it accepts.
Second (and importantly), it allows you to limit the maximum number of characters accepted, avoiding buffer overruns.
So. Load this (#include <input.c>), and modify it with:
Code: |
//Add this line after the c==getc(); line
if (c==10) continue; //Throw away LF
|
Then you can leave your terminal program sending CR+LF.
Then where you currently call 'gets', call 'get_string(valor,7);'
Now there are some code faults that may be partially causing your problems. You are calling 'fgets', which is the function expecting to receive from a _STREAM_, which expects a _stream name_ parameter, but you are not giving it this parameter. Look at the manual entry for this.
You are not using streams.
This may be what is leading to the unexpected behaviour with ERRORS, and setup_uart.
You do understand you don't "call errors". You just add it as an entry to the #use RS232 setup. Use:
#use RS232(baud=4800, UART1,PARITY=N,BITS=8,ERRORS)
You also call 'setup_adc(0)', which turns off the ADC, but don't call 'setup_adc_ports', which is the call to actually disable the ADC multiplexor channels.
Code: |
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_spi(FALSE);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
|
Basic calls to disable the comparator, SPI, vref, and ADC.
Then, _get rid of your delays_.
The code will _wait_ for serial to arrive, so just display what has been seen, and go back to waiting for the serial. The delays are _dangerous_. If characters arrive before you are back waiting for them, though 'ERRORS' will prevent the chip getting hung up, data will still be lost.
So:
Code: |
#include "16lf1827.h"
#use delay (internal=1MHz)
#fuses INTRC_IO, NOLVP, NOWDT, NOMCLR, NOIESO, PUT, NOBROWNOUT
#use RS232(baud=4800, xmit=PIN_B2,rcv=PIN_B1,PARITY=N,BITS=8)
#include <input.c> //Modified as described
void main(void) {
int16 num;
int8 i, valor[8];
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_spi(FALSE);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
output_high(PIN_A6);
delay_ms(150);
output_low(PIN_A6);
while(TRUE)
{
get_string(valor,7);
num=atol(valor);
printf ("\n\r\r%s\n\r", valor);
printf("valor=%Ld\n\r\r", num);
output_high(PIN_A6);
delay_ms(1); //enough delay for pulse to be detected on a scope
output_low(PIN_A6);
}
}
|
I compiled this with your compiler version, and it runs, accepting strings from a terminal program set to send CR+LF, and correctly decoding the values and displaying them.
Best Wishes |
|
 |
Dave_25152
Joined: 11 Dec 2010 Posts: 60
|
|
Posted: Wed Jun 27, 2012 6:10 am |
|
|
Thank you for all the explanations you gave me.
I'll try. |
|
 |
Dave_25152
Joined: 11 Dec 2010 Posts: 60
|
|
Posted: Wed Jun 27, 2012 7:06 am |
|
|
Now it works fine!
Matter resolved.
Thank you to all who could help!
I apologize if it was inconvenient, but it was not my intention.
Best regards! |
|
 |
|
|
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
|