Exact match. Not showing close matches.
'[PIC] UART address mode'
As hinted at in another post, I'm porting an application over
from a 16F88 to the 18F1320. Several F88s slaves are on an
I2C buss with an 18F4550 Master. Realising (now) that the
18F1320 doesn't have I2C, I have to come up with PlanB
At present the F88s self-detect via h/w comparison of SSPADD.
Those not being addressed go back to sleep or whatever they
were doing. All quite simple and efficient
I have to decide how to best replicate this without I2C. As the
I2C buss doesn't extend outside of the micros, I could do it
with bit-banging, s/w I2C or serial, INT pins etc etc
But aside from how it eventually gets done, I'm wondering
about the 9-bit address detect mode on the 18F1320. The
paragraph below is in the datasheet. AFAICT, no more is
said about it, and what is said hardly explains anything
Can someone enlighten me as to what the purpose of an
addressed mode is ? Is there a way I can use this in a similar
fashion to I2C addressing ? Step 9 looks DIY, rather than
an automatic comparison
16.3.3 SETTING UP 9-BIT MODE WITH ADDRESS DETECT
This mode would typically be used in RS-485 systems
To set up an Asynchronous Reception with Address
1. Initialize the SPBRGH:SPBRG registers for the
appropriate baud rate. Set or clear the BRGH and
BRG16 bits, as required, to achieve the desired
2. Enable the asynchronous serial port by clearing
the SYNC bit and setting the SPEN bit
3. If interrupts are required, set the RCEN bit and
select the desired priority level with the RCIP bit
4. Set the RX9 bit to enable 9-bit reception
5. Set the ADDEN bit to enable address detect
6. Enable reception by setting the CREN bit
7. The RCIF bit will be set when reception is complete
The interrupt will be Acknowledged if the RCIE and
GIE bits are set
8. Read the RCSTA register to determine if any
error occurred during reception, as well as read
bit 9 of data (if applicable)
9. Read RCREG to determine if the device is being
10. If any error occurred, clear the CREN bit
11. If the device has been addressed, clear the
ADDEN bit to allow all received data into the
receive buffer and interrupt the CPU
Alan B. Pearce
>Can someone enlighten me as to what the purpose of an
>addressed mode is ? Is there a way I can use this in a
>similar fashion to I2C addressing ? Step 9 looks DIY,
>rather than an automatic comparison
I believe this is done the same as the 9 bit mode that is available in the
UARTS of the 8051 series processors.
Essentially the UART stream is ignored by the slave device until a character
with the 9th bit set is received, which invokes an interrupt, at which point
the slave micro has to check the address byte to see if it is the addressed
device. If it is then it has to deal with all characters received, if not it
ignores them until the next byte with bit 9 set.
It is an easy way of having a polled serial line, without all the slave
devices having to deal with every received character. I presume that when a
slave device sets 9 bit mode, that the error checking is disabled for all
received characters unless the bit 9 of the received character is set,
otherwise there would be a backup of the errors in the UART, and the address
byte would never be seen.
Alan B. Pearce wrote:
>> Can someone enlighten me as to what the purpose of an addressed mode is
>> ? Is there a way I can use this in a similar fashion to I2C addressing
>> ? Step 9 looks DIY, rather than an automatic comparison
> I believe this is done the same as the 9 bit mode that is available in the
> UARTS of the 8051 series processors.
> Essentially the UART stream is ignored by the slave device until a character
> with the 9th bit set is received, which invokes an interrupt,
That's my understanding, too. E.g. in the PIC18C Family Reference Manual
21.4.2 USART Async Rec
"The USART module has a special provision for multi-processor
communication. When the RX9 bit is set in the RCSTA register, 9-bits are
received and the ninth bit is placed in the RX9D status bit of the RSTA
register. The port can be programmed such that when the stop bit is
received, the serial port interrupt will only be activated if the RX9D bit
is set. This feature is enabled by setting the ADDEN bit in the RCSTA
register and can be used in a multi-processor system in the following
"To transmit a block of data in a multi-processor system, the master
processor must first send an address byte that identifies the target slave.
An address byte is identified by the RX9D bit being a ¡1¢ (instead of a ¡0¢
for a data byte). If the ADDEN bit is set in the slave¢s RCSTA register,
all data bytes will be ignored. However, if the ninth received bit is equal
to a ¡1¢, indicating that the received byte is an address, the slave will
be interrupted and the contents of the Receive Shift Register (RSR) will be
transferred into the receive buffer. This allows the slave to be
interrupted only by addresses, so that the slave can examine the received
byte to see if it is addressed. The addressed slave will then clear its
ADDEN bit and prepare to receive data bytes from the master.
"When the ADDEN bit is set, all data bytes are ignored. Following the STOP
bit, the data will not be loaded into the receive buffer and no interrupt
will occur. If another byte is shifted into the RSR register, the previous
data byte will be lost."
21.4.3 Setting up 9-bit mode
"Address detect mode allows an Addressable USART node to ignore all data on
the bus until a new address byte is present. This reduces the interrupt
overhead since not every byte will generate an interrupt (only bytes that
are directed to that node)."
Figure 21-7 illustrates that a bit.
> I presume that when a slave device sets 9 bit mode, that the error
> checking is disabled for all received characters unless the bit 9 of the
> received character is set, otherwise there would be a backup of the
> errors in the UART, and the address byte would never be seen.
They don't write about error detection being disabled, but you're right of
> in the PIC18C Family Reference Manual
Thank you so much for reminding me Gerhard. There's been
something nagging me all day but I couldn't put my finger on
what it was. I made a mental note last night to download the
FRM but of course forgot all about it this morning
What about using an external I2C interface with a UART on it?
More parts, but might be easier than rolling the code too?
On 10/18/06, Jinx <clear.net.nz> wrote: joecolquitt
> > in the PIC18C Family Reference Manual
> Thank you so much for reminding me Gerhard. There's been
> something nagging me all day but I couldn't put my finger on
> what it was. I made a mental note last night to download the
> FRM but of course forgot all about it this morning
> What about using an external I2C interface with a UART on it?
> More parts, but might be easier than rolling the code too?
I should be OK with altering the code I've got thanks. With the F88s
they were on a simple I2C buss. Simple in that the master sends out
1pps to tick all the slaves' clocks. Each slave is assigned a window of
10ms within that second according to its address, so there'll be no
buss collisions. Also, as confirmation the other way, the master knows
by the time from the last tick pulse which slave is active on the buss.
So as long as I keep that timing system in place, I have fairly free
reign over what comms I design. I think probably the simplest will
be write a second UART for the 4550 and send to the UARTs on
the 1320s. That keeps it at 2-wire with no extra h/w needed (can
actually lose the I2C pullups)
Pearce, AB (Alan)
>I think probably the simplest will be write a second UART
>for the 4550 and send to the UARTs on the 1320s.
have a look at the library for the C18 compiler - there is a software
UART in the library that would be easy to either link in or transcribe
More... (looser matching)
- Last day of these posts
- In 2006
, 2007 only
- New search...