IRCOM support

[mqhapx]

Are there any plans to add support for IRCOM to UART? As far as I understand, the controllers support modulation-demodulation of infrared signals. How difficult is it to switch the uart into this mode? Not enough USART0.CTRLC = USART_CMODE_IRCOM_gc :(((

[SpenceKonde]

No there are no plans to implement this. I have never been able to find any devices that used it, and concluded that it's long obsolete and that there is insufficient demand to justify adding it. It's one of the three features that I made the decision not to support in Serial: (well, 3.5)

1. 9-bit serial because it imposes 2:1 worse memory overhead even if you don't use it, and nobody does.I don't even know how you test it - no computer serial adapter I've seen can handle 9-bit! It wouldn't be hard to make an external library that did that. But it can't go into HardwareSerial class that Serialn is a member of, because of the overhead it would force on everyone else for a feature nobody wants.
2. LIN-constrained autobaud, because it's only relevant in automotive applications, and neither this core nor the arduino IDE is appropriate for developing life safety critical equipment (even if the chips are, you need to use their development tools to qualify under those standards they like talking about), and I don't want to abet people doing things that put the lives of others at risk, and few places do you have more chance to cause injury or death to others without intending to than behind the wheel of a vehicle.
3. IRCOM for any case except turning off the pulse length encoding and using an event channel as RX, which I think lets you arbitrarily reroute any pin to Rx. Extreme niche use, and I have no hardware that I could test anything with nor would I even know what that hardware would be.
   The half feature: USART RS485 mode 2, removed from subsequent parts. Documentation is incredibly terse, as if the documenter didn't really know how it worked and couldn't find anyone who did. and thinking about what it could do led to them

You might have success setting up the USART normally then doing:

uint8_t temp=USART0.CTRLB; // This song and dance with the temp variable is faster and more efficient than an &= then an |= 
USART0.CTRLB = temp & 0x3F; // set RXEN and TXEN to 0. Preserve the rest of the register. USART now off. 
// Note that on some ATtiny parts, the TX pin is still not released for GPIO when you disable the USART - but the next write to a USART0 register will fix it. 
USART0.CTRLC = USART_CMODE_IRCOM_gc | ((~USART_CMODE_gm) | USART0.CTRLC); // you can't trash the rest of the register! Thats where you tell it how many bits are in a character, whether parity is in use and some other important things. 
// Configure these two registers appropriately; I don't know much about IRDA other than that there never seemed to be any use for it, but these control the pulse length's accepted and sent. As the IRDA expert in this conversation, figuring out what these should be is on you. 
USART0.TXPLCTRL = [insert value appropriate to your application requirements here]
USART0.RXPLCTRL = [insert value appropriate to your application requirements here]
USART0.CTRLB = temp; //Set em back to what they were before, almost certainly both 1's
// Notice we're turning the USART off while we reconfigure it, this might not be needed. 

the song and dance here is a faster way of doing the intuitive approach

//Song and dance
uint8_t temp=USART0.CTRLB; -> ld or lds gets currenv value into register (2-3 clocks)
USART0.CTRLB = temp & 0x3F; -> mov, andi (2 clock)
USART0.CTRLB = temp; st or sts (1-2 clocks)
//5-7 clocks, 4 or 6 words. 
/* the intuitive but worse way */
USART0.CTRLB &= 0x3F; -> ld or lds, andi, st or sts - 4-6 clocks
USART0.CTRLB |= 0xC0; ->ld or lds, ori, st or syts - 4-6 clocks
// So 8 or 12 clocks, in 6 or 10 words. Not much worse, but definitely not better.  

Note that either method of modifying CTRLB needs to be done with interrupts disabled if you are doing anything in an interrupt which changes the the state of CTRLB (unless the change is ephemeral - like how we are changing it to something else then back to what it was, if the interrupt exits with it in the same state as it started, the rest of the app will be none the wiser - the hardware serial ISR does this in order to support autobaud in spite of the widespread erratum. If we see the ISFIF - that must first be cleared, then the RXEN bit turned off and back on, to restore the receiver after an inconsistent sync field error. Busted like that in almost every modern AVR, per silicon errata (it's supposed to block receiving until the intflag is cleared, but clearing the intflag alone was meant to be sufficient to restart receiving; it's not)

[rocketjosh]

I am working on a project to interface with a device that uses IrDA modulated (3/16) UART. The IRCOM should be perfect for this.

I was able to detect some data with your suggestions, but it doesn't seem to be capturing correctly. Not able to get TX to function either.

Could use some guidance on this (willing to compensate for your time) to get things working.