AVR Freaks

No,  I have not checked.

From memory it makes no difference if you make the TX pin an output before or after "enabling" with TXEN bit on Xmega or AVR8X.

Traditional AVR do not need to set output.  USART TXEN bit overrides the DDR bit.

David.

(from tiny416 datasheet, assume they are the same except for any copy/paste errors they have introduced)

...If the USART is configured for one-wire operation, the USART will automatically override the RxD/TxD pin to output, when the transmitter is enabled.

24.3.2.3.2
...When the transmitter is disabled, it will no longer override the TxDn pin, and the PORT
module regains control over the pin. To protect external circuitry the pin is automatically configured as an
input by hardware. The pin can now be used as a normal I/O pin with no port override from the USART.

one-wire mode = USART has total control (it has to)
else = USART controls PORT but not DIR
when disabled = tx pin DIR set to input

rx = DIR has to be set to input by user
 

You can also check out the PORT block diagram to see where some of these overrides are located, and where any inverted signal is wanted it can be seen the port takes care of that before-in/after-out a digital peripheral.

I am programming on USART on one-wire mode.

I hope one master communication with multi sensor modules through USART.

For there are double direction transferring and no synchronization mechanism , conflict can't be gotten rid of.

That's why choice one-wire : check  whether RXDATA is equal to data transferred, for TxD connected to RxD internal in one-wire mode, this is mentioned in datasheet.

But ,there is a problem for me : RXDATA is empty(0 always) ( the TXC interrupt triggered indeed).

I don't know what is the exact meaning of " the USART will automatically override the RxD/TxD pin to output, when the transmitter is enabled "

This is my understanding:

1) one-wire mode is only used to decrease the pins required, TxD + RxD  ->  TxD;

2) Though only 1 pin used, the TxD & RxD hardware peripherals are taken over for use;

3) In sending mode, TxD pin configured as output by hardware automatically;

        Question: what is the state of RxD peripheral?

                       Does hardware disable it automatically? or leave it as user configured?

                       In my case, I enabled RxD peripheral at the beginning, and don't change later. 

4) In receiving mode,  TxD disabled by user.

        Question: Do we need to enable RxD peripheral every time?  Do we need to set TxD pin to input?

ATMEL just highlights the situation  transmitter enabled, no word for my questions above.

Maybe for RxD should be treated as normal way.

Here you go:

https://github.com/MicrochipTech...

via

https://github.com/MicrochipTech...

Please check:

https://www.avrfreaks.net/forum/...

You are welcome.

Regards,

Moe

Moe:

I need to discuss with you further.

In the sample project :  https://github.com/MicrochipTech/TB3216_Getting_Started_with_USART/tree/master/One_Wire_Mode

The RXCIF  will not be set in status register after I canceled the RXCI interrupt.

Origal:

void USART0_oneWireSend(char* str)

{

    PORTA.DIR |= PIN0_bm; /* A0 pin must be output to transmit */

    USART0.CTRLA |= USART_RXCIE_bm; /* Receive Complete Interrupt must be enabled */

    for(size_t i = 0; i < strlen(str); i++)

    {

        charToSend = str[i];

        waitTxReady();

        USART0.TXDATAL = charToSend;

        if(waitSendConfirmation() != OK)

         {

           break;

         }

    }

    USART0.CTRLA &= ~(USART_RXCIE_bm);

    PORTA.DIR &= ~PIN0_bm;

}

 

 changed:

void USART0_oneWireSend(char* str)

{

    PORTA.DIR |= PIN0_bm; /* A0 pin must be output to transmit */

    //USART0.CTRLA |= USART_RXCIE_bm; /* Receive Complete Interrupt must be enabled */

    for(size_t i = 0; i < strlen(str); i++)

    {

        charToSend = str[i];

        waitTxReady();

        USART0.TXDATAL = charToSend;

        //if(waitSendConfirmation() != OK)

        while (!(USART0.STATUS & USART_RXCIF_bm)) {;}

         if (USART0.RXDATAL != charToSend)

         {

           break;

         }

    }

    //USART0.CTRLA &= ~(USART_RXCIE_bm);

    PORTA.DIR &= ~PIN0_bm;

}

The program blocked at this sentence:

       while (!(USART0.STATUS & USART_RXCIF_bm)) {;}

That means RxD does not work? Or cleard by other operation?

This happened in my code too.

According to the comment " /* Receive Complete Interrupt must be enabled */" ,

it hints that this is the only way?

If what I said is true earlier, then this should probably work (based on the example)-

#define F_CPU 3333333
#define USART0_BAUD_RATE(BAUD_RATE) ((float)(F_CPU * 64 / (16 * (float)BAUD_RATE)) + 0.5)

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <stdint.h>
#include <stdbool.h>

bool    USART0_oneWireSend   (char*);
int16_t USART0_oneWireReceive(void);
void    USART0_oneWireInit   (void);

//blocks for 1 frame
//if any collision, give up and return false
bool USART0_oneWireSend(char* str){
    for( ; *str; str++){
        while (!(USART0.STATUS & USART_DREIF_bm));
        USART0.CTRLB &= ~USART_RXEN_bm; //clear rx buffer/rxcif
        USART0.CTRLB |= USART_RXEN_bm; //re-enable rx
        USART0.TXDATAL = *str;
        int16_t rxval;
        while( rxval = USART0_oneWireReceive(), rxval == -1 );
        if( rxval != *str ) return false;
    }
    return true;
}
//non-blocking, -1 = no data available, <0 (not -1) = error, >=0 = good data
int16_t USART0_oneWireReceive(void){
    int16_t ret = USART0.RXDATAH<<8;
    if( !(ret & 0x8000) ) return -1; //rxcif=0, no data
    ret |= USART0.RXDATAL; //always get data even if errors
    if( ret & 0x4600 ) return ret; // error bits set, return will be <0 (rxcif set)
    return ret & 0xFF; //only data (could use 0x1FF if 9bit used)
}
//loopback, open drain, usart handles tx pin
void USART0_oneWireInit(void){
    USART0.BAUD = (uint16_t)USART0_BAUD_RATE(9600);
    USART0.CTRLA = USART_LBME_bm;
    USART0.CTRLB = USART_RXEN_bm | USART_TXEN_bm | USART_ODME_bm;
}

int main(void){
    USART0_oneWireInit();
    PORTA.PIN0CTRL |= PORT_PULLUPEN_bm;

    while (1){
        USART0_oneWireSend("Microchip.\r\n");
        _delay_ms(500);
    }
}

I haven't used 1 wire and have not thought out what the isr usage would look like or if there is any benefit (on the receive side I guess), but in the example they provide there is no point to it. The rx isr in the example only handles checking for valid rx vs tx, and the tx is blocking on it, so is of no use.

The above modification is a polling only receive, and a blocking tx for 1 frame. The tx should probably poll the oneWireReceive() before doing anything in case other rx data came in, but this is a simple example that does not take into account any comm protocol in effect.

"Try to substitue the {;} with just ; "

that does not matter.

If you dont mind guys, I will refer to this thread in my other thread "Getting started with Attiny 1 & 0 series":

https://www.avrfreaks.net/forum/...

Moe:

I have studied the docs you advised.

Based on the structure of 

https://github.com/MicrochipTech/TB3216_Getting_Started_with_USART/blob/master/One_Wire_Mode/main.c

I re-composed my code as attached files.

There is a strange problem,the received data will not be equal to RXDATA again when I add this configuration:

USART0.CTRLC =
          USART_CHSIZE_9BITH_gc        // Character size: 9 bit read high byte first
        | USART_PMODE_EVEN_gc ;         // Even Parity

Those settings should not change the data received and sent.

Parity check finished inner, and the high byte first rule was obeyed.

I debugged with atmel-ice, found that it getting different from second byte.

I'll try error this weekend.

Let me know your any advice.

Now, I have no so much time to study further, here is my experience ,for refrence.

1) the framework code provided by Moe works fine, and it is the very good start point;

    my code posted upper works fine too.

2) in my case, if turn to poll mode + 9bit + even check, the RXCIF bit will not set as desired,

    it maybe caused by code, but I have no time to dig it.

   ---------->update: RXCIF set as desired, but MPCM related function works wrong.

3) check the hardware first.

    I'm luckly faced problem comes from hardware twice:

      A. the PA4 hardware connect is not stable, lead to EVSYS does not work;

      B. I use 2 ATTINY814 to test the USART,  the Vin & GND & TX pin connected together each of them, 

          This will cause the interrupt doesn't work too, it will works fine if you disconnect one of the ATTINY814.

          I have to power them seperately.

          ------------>update: it does not matter now, don't know why too :)

Thank Moe & curtvm.