CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

[SOLVED] PIC18F04Q40 UART problem
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
alan



Joined: 12 Nov 2012
Posts: 349
Location: South Africa

View user's profile Send private message

[SOLVED] PIC18F04Q40 UART problem
PostPosted: Wed Mar 16, 2022 1:10 am     Reply with quote

I am getting the following error in driver rs485 when using PIC18F04Q40.
Code:
RS485.c:121:18:  Error#102  Expect comma

for the line
Code:
setup_uart(TRUE);

Working fine for all other processors


Last edited by alan on Thu Mar 17, 2022 11:32 pm; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 2:05 am     Reply with quote

Two separate problems here.

This chip has multiple UARTs. These are also PPS peripherals.
So the compiler has to be told which UART to use, and what pins it
is on. The complaint is 'misleading', it really needs to be something like
"I don't know which UART you want to use and where it is connected".

So:
Code:

#include <18F04Q40.h>
#device ADC=12

#FUSES NOWDT                    //No Watch Dog Timer

#use delay(internal=16000000)

#pin_select U1TX=PIN_C4
#pin_select U1RX=PIN_C5
#use rs232(UART1, baud=9600, NOINIT)
//Tell the compiler which UART to use by default and assign pins to it
//but don't start it. This is now the default UART.

void main()
{
   setup_uart(TRUE); //This now merrily works & starts the UART
   while(TRUE)
   {
   }
}
alan



Joined: 12 Nov 2012
Posts: 349
Location: South Africa

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 2:32 am     Reply with quote

Thanks Ttelmah, that were just plain dumb from me. I had a pre-processor setting hardware depending on the 'device' and forgot to update it.

Any way I need 9 bit protocol and this does not work
Code:
  #use rs232(baud=38400, UART1, bits=9, long_data, errors, stream=RS485)

Complaining about the bits=9;
Quote:
Error#99 Option invalid 9 not supported by hardware UART peripheral

I know I am missing something here
alan



Joined: 12 Nov 2012
Posts: 349
Location: South Africa

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 2:47 am     Reply with quote

According to data sheet the chip can handle 9 bits.
Quote:

Half and full-duplex asynchronous transmit and receive
Two-byte input buffer
One-byte output buffer
Programmable 7-bit or 8-bit byte width
9th bit address detection
9th bit even or odd parity

CCS 5.105
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 4:37 am     Reply with quote

No, it doesn't.....

If you read, it says:

Programmable 7-bit or 8-bit byte width
9th bit address detection
9th bit even or odd parity

It only supports the 9th bit for parity or address detection. Not for normal
use for data. The actual transmitted character only supports 7 or 8 bits. Sad
alan



Joined: 12 Nov 2012
Posts: 349
Location: South Africa

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 4:51 am     Reply with quote

Thanks Ttelmah
Ok, then I might misunderstand the following, but according to me that is 9 bit protocol.
from datasheet
Quote:
Asynchronous 9-bit UART Address mode. 9th bit: 1 = address, 0 = data

Setting of UxCON0 to MODE 4
Quote:
Bits 3:0 – MODE[3:0] UART Mode Select (1)
Value
Description
1111 - Reserved
1101
1100 - LIN Host/Client mode (4)
1011 - LIN Client Only mode (4)
1010 - DMX mode (4)
1001 - DALI Control Gear mode (4)
1000 - DALI Control Device mode (4)
0111 - Reserved
0101
0100 - Asynchronous 9-bit UART Address mode. 9th bit: 1 = address, 0 = data
0011 - Asynchronous 8-bit UART mode with 9th bit even parity
0010 - Asynchronous 8-bit UART mode with 9th bit odd parity
0001 - Asynchronous 7-bit UART mode
0000 - Asynchronous 8-bit UART mode
alan



Joined: 12 Nov 2012
Posts: 349
Location: South Africa

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 4:53 am     Reply with quote

Ttelmah wrote:
No, it doesn't.....

If you read, it says:

Programmable 7-bit or 8-bit byte width
9th bit address detection
9th bit even or odd parity

It only supports the 9th bit for parity or address detection. Not for normal
use for data. The actual transmitted character only supports 7 or 8 bits. Sad


If this TRUE, it means I can't use this chip for 9 bit protocol
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 5:15 am     Reply with quote

You can use the PIC, but NOT the HW UART. You'll have to write your own SW(SoftWare) UART functions for transmit and receive 9 bit data.

I am curious as to what 'device' actually uses 9 data bits.

It may be possible to use 2 bytes from the HW UART by just masking off the top 7 bits of the 2nd byte ??
You might be able to use the 9th bit 'address or data flag' as the real 9th bit data ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 7:58 am     Reply with quote

It uses the 9th bit just two ways.
First as parity.
Second as a 'flag' to say an address is being sent.

You can't use it to send 9bit data. As Jay says to do this you'd have to
use software.
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 8:12 am     Reply with quote

curious was I...

so I found an article that the SENDER uses the parity bit as the 9th data bit and the Receiver then 'recovers' the 9th data bit by reading the parity bit in the UART registers.

Seems like a LOT of coding when sending/receiving 2 bytes is EASY.
It has to be some 'special' device that sends 9 data bits ??
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Wed Mar 16, 2022 8:50 am     Reply with quote

Two bytes takes a lot longer.
I must admit I use 9bit data quite often. Things like a display system,
where words with the 9th bit set are the commands, and stuff without
this are the data. For this type of system, the address ability could
potentially be used, but not on the receiver, because of the way this
is handled.
The trick way is to change the UART parity settings according to what
bit is required. However a lot of work and makes the data transmission
a lot more complex....
So a lot depends on how the 9th bit actually needs to be used. Perhaps
a description of what is wanted could be forthcoming?.
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Mar 17, 2022 7:12 am     Reply with quote

re:
Quote:
Two bytes takes a lot longer.

aww, not that much longer, especially at 9600 baud, so maybe 1ms ?
Hmm double the baudrate...it'd take the same time....

Used to fix Teletypes that ran at 300 Baud and my energy system runs at 24 Baud ( yes, twenty four baud) Very Happy
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Thu Mar 17, 2022 10:51 am     Reply with quote

Slight differences in scales....

Those display controllers use 500Kbaud.When you are sending 50KB of
data per screen Using 10 extra bit times for each transfer becomes very
significant!.
alan



Joined: 12 Nov 2012
Posts: 349
Location: South Africa

View user's profile Send private message

PostPosted: Thu Mar 17, 2022 11:32 pm     Reply with quote

Answer from CCS. PIC are capable of 9 bit, not yet implemented, so manually setup serial for me Mr. Green

Quote:
Currently the compiler's #use rs232() directive doesn't support setting up the PIC's UART in the Asynchronous Address Mode (9-bit) that the PIC18F04Q40 device family has. It is on our list to add support for that mode to the #use rs232() directive in the future.
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Fri Mar 18, 2022 2:32 am     Reply with quote

That I'm afraid is not the right answer.

Your chip does not support normal 9bit operation. It does support a 9bit
address mode. It is this that CCS are telling you the compiler does not
support, but even if they implement this, it won't allow you to send 9bit
data.
As already said, it does depend massively on what you actually want 9bit
support 'for'? If (for example), you want this for RS485, for an address
character, then the address mode support will work for this. It won't
though allow you to send 9bit data.

The CCS reply has answered "how can I enable this chip's 9bit mode",
but not "can I send/receive 9bit data with this chip".
The answer to this later question is "you can't".
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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