using fputc and kbhit with streams

[big_nige]

Hi all,

Using PCWH 4.107 with a 18LF2550.

I am trying to use a software uart on a couple of pins in conjunction with the main UART. I can't get the second uart to work however, the following code just hangs on the fgetc or kbhit (commented in this bit of code). I have isolated the circuit on my board and installed a loopback so the sent message appears on the receive pin. I have checked on the CRO and the message definitely gets to pin C1.

[Wayne_]

Two problems I see

1 is the use of msg

You define an array
char msg[60];

You then use
msg = "Marco";

This is wrong, what this will do is make the pointer msg point to the string "Marco" which would normally be placed in ROM.
This presents 2 problems later on.
1. If it is in read only memory then
msg[0] = fgetc(HILO); will fail.
2. If it places the string in RAM then it will only allocate the 6 bytes for the string and if you try to write past that you will be corrupting memory.

In order to put the string "Marco" in the array msg you need to use

strcpy(msg, "Marco");
or
sprintf(msg, "Marco");

2 is the fact you are using a software UART and you are sending to yourself. Not sure you can do this! do a search on here.

[big_nige]

Thanks for the reply Wayne,

1 - I dont think so. The code pasted is cut out of a larger piece of code. The msg array is used for variable length strings fed in from a GPRS module (SMS messages). I have been using this array elsewhere in code without any issues (I just manually check for CR/LF).

So it is more complex than it needs to be, but the possible overrun is not my issue here - the piece of code you pasted fails too.

Also the commented out while(!kbhit(HILO)); also hangs - in this second test case I am not even using the msg array.

2 - Don't know. It works just fine on the hardware UART and I have been testing RS232 comms on loopback many times before without problems. To address the possible lag in character detection on loopback, you will note there is a software delay commented out in this code. I have tried delays from 5us to 500ms without success.

Cheers,
Nigel

[Wayne_]

1.
char msg[60];
msg = "Macro";

This is wrong code for C but it appears CCS have implimented functionality to allow you to use the = operator to copy a const string to an array at some point. I am pretty sure you couldn't do this in the past with CCS.

2. Hardware UART will work on loop back because the hardware is toggling the pin to send the byte leaving your code to do what ever it likes.
With software UART the software has to toggle the pin. It will most likely do this either via an interrupt or in a tight loop. If it is in a tight loop then your code would not be able to read the input line to see if it is a 1 or 0 unless you have an interrupt on change for the incomming pin, this could disrupt the routine sending the byte out and mess up the baud rate.
If you toggle the pin using an interrupt then your pic can still run code to read the pin.
Either way, you need to free up the incomming buffer by reading the char before you can recieve another char. If the CCS code does this, how many chars can it buffer ?

Just my thoughts on the matter.

[big_nige]

Aah - understand what you are getting at now. I agree - it is very un-c - but, if if works . Must admit that I didn't think you could do it either - the actual code reads an external EEPROM into the array in a loop. I took the shortcut once to test a routine and was as suprised as you that it worked. I haven't been using ccs for long, so just assumed that it was a convenient quirk to the compiler.

We may be getting to the nub of the problem with you comments on point 2. There is no IOC on port C on the 2550. Because it is not a UART port there also isnt a character buffer - so after sleeping on it I realised that neither the test loop or the original code is going to work.

No matter - the two RS232 devices in my design operate mutually exclusively - just have to slave them up on the hardware UART.

Thanks for your help Wayne - when I saw your response this morning the penny finally dropped.

Cheers,
Nigel

[bkamen]

[PCM programmer]

Apparently CCS is doing a C++ like construct.
This guy compares string handling in C and C++.
http://cs.smu.ca/~porter/csc/ref/c_cpp_strings.html
On the left he shows C, and on the right C++:

[Wayne_]

The difference being between C and C++ is that in C a string is a char array which is null terminated, in C++ string is an object which has an overloaded operator = for copying other string objects or a string literal to the string object.