Addressable USART 16F628A

[fowardbias]

The addressable USART is setup with the 9th bit. Is the following byte (address byte) read and compared by the PIC itself or does this code have to be written as part of the program? Either way, can I poll an input while the ID and comparsion is going on since the USART is a stand alone peripheral? The data sheet doesn't cover USART operations with addressing in detail. Some PIC's have addressable USARTS and some do not. Thanks for insight or direction.

[Darrel Taylor]

It needs to be part of the code.

On the TX end, setting the TX9D bit (TXSTA.0) indicates that you are sending a "Device Address". Put the address in TXREG. Then when it's done sending the address, clear the TX9D bit and send the data. It needs to be either a fixed size packet, or have a terminator at the end so the receiving end knows when it's finished.

On the RX end. With ADEN = 1 (RCSTA.3), the USART will ignore everything that doesn't have the 9th bit set (data).
When it recieves a byte with the 9th bit set (an address), it will set the RCIF interrupt flag.
You can either poll the flag or use interrupts, doesn't matter.

So now you check the received byte against the device's address, and if they match, turn off the ADEN bit and the USART will receive the data like normal. You can also have a Master or even Group addresses if you want. Address 0 means all devices listen, 1 = any device in Group 1, 11 = single device #1. Or however works best for you.

After it's done receiving data, turn ADEN back on, and it will ignore everything but addresses again.

HTH,

[fowardbias]

Excellent info, so I can store the ID in the EEPROM or load it upon start up as a lookup table, either way OK? Another area which is unclear is the use of the built in chip ID code (4 bits I believe). Not much mention about its use by Microchip or users. Seems to be very restricted in what can be done with it? Thanks again, I'm going to start experimenting (breadboard) with a communications project.

[Darrel Taylor]

>> so I can store the ID in the EEPROM or load it upon start up as a lookup table

Might be difficult to modify the program each time you program a new chip.
Maybe you could Poll the master (if there is one) for a new unique ID, and store that in EEPROM. Could be tricky if 10 devices all want an ID at the same time though.

The ID Locations (4 bytes) aren't much use on the 16F's. The program can't read them. You can only read/write them with a programmer.
On the 18F's (8 bytes), the program can read/write the ID's (with a little help).

Along with the Config words, this program can read/write the ID Locations too.
Added: And some programmers can auto-increment the ID's

Run-Time Config
http://www.picbasic.co.uk/forum/showthread.php?t=4093

[fowardbias]

Very good DT, what I'm up to is a modified one wire bus in asyncro mode no master/slave and in the beginning a one way communications to two remote units from a main command station. A return data status from the remotes can happen later. Nothing critical here , just fun stuff and if it works out well a few of my friends are saying make me one too. Us geeks never stop.