printf in an include file?

arrow · Joined: 17 May 2005 Posts: 213

Hi

I have the following code in file code0.c:

Ttelmah · Guest

The 'use RS232' statement, defines what output 'method' putc, and printf, are going to use. Hence this _must_ be before any useage of these statements. Similarly, the 'use delay', must be before the use RS232.
So the 'order', needs to be:

'processor definition' (normally by including the CCS processor file)
'delay definition'
'fuses'
'R232 definition'
'other setups (I2C/SPI etc.)'
'code'

The 'fuses', and the delay definition can be reversed (this only 'matters' when using an internal RC oscillator, where it will change how the compiler configures the oscillator).
Any of the items can themselves be in an 'include' file, but the basic order the statements are met, needs to be close to this.

Best Wishes

arrow · Joined: 17 May 2005 Posts: 213

Hi Ttelmah

I have changed the code as you suggest, and now the compiler
reports an error:

"Expecting a variable"

just after the printf("we are here A"); command

If I remove the printf line, it compiles ok.

Could you please tell me what I am doing wrong?
Thank you
a.

arrow · Joined: 17 May 2005 Posts: 213

Hi Ttelmah

Sorry please scrap the previous post- I have fiddled with the code
(rearranged some lines), and now things compile.

May I ask you about SPI and PC RS232 serial communications.
I see that on my chip the RS232 Xmit is the same SDO for the SPI.

What should I do, if I would like to communicate both with and SPI device
and with my PC?

Thank you for all your help.
a.

Ttelmah · Guest

You need to either use flow control, or a 'gate' to disable the RS232 TX connection, while SPI takes place.
Basically the sequence will run:
Disable the serial connection (turn off the flow control, or disable the gate on the TX line).
Disable the UART.
Enable the SPI peripheral.
Clock out the SPI data (and retrieve the reply).
Disable the SPI peripheral.
Enable the UART.
Re-enable the serial connection.

The compiler has support for disabling and enabling the devices, but the 'extra' bit needed is some way of disabling the SDO data affecting the serial connection. The obvious way, is to use another pin as an output (serial select), and have a 'OR' gate with this feeding one input, and the SDO/TX pin feeding the other. The output of this gate then feeds to the RS232 transceiver. Setting the 'serial select' pin high, will disable RS232 transmission, and hold the line feeding into the transceiver high, while setting it low will allow serial comms. Using flow control, will only work, if the receiving device, genuinely stops receiving, when signalled o do so. Otherwise the SPI data will appear as garbage. Depending on how much SPI data you need, and whether you need to read the device, you might also consider 'bit banging' the SPI operation.

Best Wishes

arrow · Joined: 17 May 2005 Posts: 213

Hi Ttelmah

Thank you for your thorough explanations.

What I will do is choose another set of pins for the RS232 communication.
Since the baud rate is only 19.2kbaud software RS232 should be fine (am I right?).

I appreciate all your help.
Regards
a.

Guest · Posted: Mon Jul 31, 2006 11:23 am

It'll depend what you are doing with the serial.
The problems with software serial, are first that it is easy to miss characters on the receive, and secondly, that getting accurate timings, require nothing else to be going on when you send or receive.
There is an option that may not be 'obvious', which is to define one 'stream', using the two hardware pins, and another implementing a 'transmit' only on another pin. Then use the required pins for SPI, and the hardware _receive_pin only. This gives you the advantage of interrupt driven receive, and the two characters of hardware buffering present on this. Do all your transmission on the software UART on another pin.

Best Wishes