Hardware uart parity

[fobi]

Ttelmah, i'm sorry:

The definition of the RS232_ERRORS is as follows:

No UART:
· Bit 7 is 9th bit for 9 bit data mode (get and put).
· Bit 6 set to one indicates a put failed in float high mode.

With a UART:
· Used only by get: <<<<<<<<<<<<<<<<<<<<<< !!!!!!
· Copy of RCSTA register except:
· Bit 0 is used to indicate a parity error.

[Ttelmah]

Use this instead then:

[fobi]

I will try, but i really like this style

[Ttelmah]

Makes it bulkier, easier to go wrong, and harder to read....
The actual 'out_spi' function is pointless, You can just use spi_write2. The encapsulation is only needed if you want to make some form of change to the data. Hence needed for 9bit. The whole thing just becomes:

[fobi]

I give up. I have not enough brain to understand these #use statements. I guess they are amazing for software communication,
but i can't get working hardware peripheral with them.

[Ttelmah]

Look at the thread 'SPI Enable pin'.

You are doing exactly what is causing the problem here.

[fobi]

With my minor XP here, i can point what puzzle me in these #use statements.
I had no success to run a hardware spi or uarts on 18F23K22 with them.

1.
#USE SPI (options)
SPI1 Use the hardware pins for SPI Port 1 // Only the pins or whole hw ????
SPI2 Use the hardware pins for SPI Port 2
FORCE_HW Use the pic hardware SPI. // Which one if there are 2 or 4?

result = spi_xfer(stream, data, bits) // looks perfect

2.
This works well and do not require #USE. But require separate spi_write() and spi_read() ???
setup_spi (mode)
setup_spi2 (mode)

3.
#USE RS232 (options)
BITS =X Where x is 5-9 (5-7 may not be used with the SCI).
LONG_DATA Makes getc() return an int16 and putc accept an int16. This is for 9 bit data formats.

Completely unclear for me.
BITS =X ? Which one, transmit, receive or both ? I guess both. But on PIC i can set them separately. I can receive 9 bits and

send 8. Which i am doing in my case.
LONG_DATA ? Do i have to specify the bits beforehand ? Ok, i will check

4.
set_uart_speed (baud, [stream, clock])
Availability: This function is only available on devices with a built in UART.
Requires: #USE RS232 ???

As comparison with SPI i do not expect this, but something as setup_uart2 (baud, bits, [stream]).

Let me clear this. I do not criticize anyone or anything!
The compiler looks great. I wrote working test for 3 days without having any expirience
with C!! In comparison i lost 3 weeks for my real asm code. Imagine printf(fname, cstring, values...) function in assembler
I just ask questions.

fobi

PS How to attach file here ?

http://postimg.org/image/8a1kpxpwh/

[Ttelmah]

1) The SPI port on the pins you are using.

2) Just use spi_read(val) to send and receive a value at the same time.

3) No you can't. The UART hardware can only be set to one data format on any selected port. If you are setting two different word lengths, the one will use the hardware, and the other a software implementation. The abilities of the commands are those of the hardware. One port can only have one data format.

4) If you want to change the bits, then just use another #use rs232. The point about set_uart_speed is it allows on the fly changing without stopping the UART

[Ttelmah]

As a comment, you could save yourself an enormous amount of hassle, by switching up to a PIC24 or above.
Unlike the PIC16/18 chips, these have _hardware_ parity generators, so the parity problems you have seen, would not apply. Settings would still apply to the whole port, but a lot of fiddling would be saved. You could even change parity by just changing the PDSEL bits in UxMODE .

[fobi]

I can receive 9 bits and send 8bits with same PIC hw uart. There is separate TXSTA.TX9 and RCSTA.RX9 bits.
I just wanted to see how looks C code and learn something. I found some benefits and little drawbacks. I choose CCS as good looking and PIC with more peripherals. I choose already written by me assembler code for test. I could choose another mcu or Arduino, FlowCode, CodeWarrior, PicBasic and who knows whatever more. CCS is fine. I have full low level control of the PIC and some ... pamperings here Any time i can write my own functions and use them or convert macros to C functions. I have few free days (i.e. nights ) more and i will fun with this. But my real code will stay in pure assembler. I can not use C only because it works. I have to know how exactly works, because my projects are for customers.
Thank you for the answers, you were very kind.
fobi

[temtronic]

just to let you know...

You can printout the 'filename.lst' and get the complete program in asm. this will allow you to see how CCS codes their functions. Very often they are most efficient code possible.


Jay

[Ttelmah]

If you rem out the #nolist near the top of the processor's include file, this will include the core functions as well.

[fobi]

Yes, thanks, i do that. I found this :

[Ttelmah]

No.

If you want to read the buffer after sending, then use spi_read(val), which will write then read.

They read the buffer before sending, because if something is in the buffer there will be an overflow flagged. Data sheet quote:
"The user must read the SSPBUF, even if only transmitting data, to avoid setting overflow".

To read after sending, you have to wait for the transmission to complete. They don't. They let the hardware get on sending while you can carry on doing other things. The function returns as soon as the byte is loaded.

[fobi]

you are right, yes .....

Ttelmah !!!

I found the bug. Parity works ok, but it is confused!
Parity=EVEN mean Parity=ODD.

After