Framing error if I disable transmitter after shift register is empty?

[tumbleweed]

I'm not sure exactly what you intend to do, but TRMT gets asserted half-way into the STOP bit, so if you immediately disable the TX then the STOP bit will be half the time and generate a framing error.

The datasheet doesn't really specify that TXEN controls the state of the TX output pin (see datasheet section 25.1.1.1), but if it does return control back to the IO PORTC/TRISC registers then you'd have to make sure that the TX pin (RC6) is set to output high.

If you want it to be an input/tristate with an external pullup then set TRISC6.

[amgen]

checking your stuff........ if you use interrupts (DT ints), for RX interrupts, you would not use PB hserin in the int routine. Rather get the characters in your routine and store them in the locations you designated and advance counter and check for some beginning or ending character....... with this I receive up to 1000 characters and store them in ram on 18f with 4k ram..... you would fix for your code. If successful receive, raised a flag telling basic to process the data for whatever your looking for

'''-------------RCV INT ROUTINE----------------''''
RCint:
RCX=RCREG
'@ bcf RCSTA,4 
'@ bsf RCSTA,4   
'''@ CLRF CREN     ;RESET RCV overrun
'''@ SETF CREN

  

IF RCX=8 THEN     '''CHECK FOR BACK SPACE BS 8dec
SELECT CASE RCVindx
    CASE 0
        GOTO LEAVEOK1
    CASE 1
       RCVindx=RCVindx-1 :RCVOK=0
        RCVdata[RCVindx]=0    
       GOTO LEAVEOK1
    CASE IS >1
       RCVindx=RCVindx-1
       RCVdata[RCVindx]=0
       GOTO LEAVEOK1
END SELECT
ENDIF

if RCX = "[" then 
RCVindx=0:RCVok=1:DATAready=0   
goto leaveok 
endif  
if RCVok=0 then   LEAVEOK1    
if RCX = "]" then
rcvok=0:dataready=1 
endif 
    
leaveok:           'LEAVE AND STORE RCVD CHAR
RCVdata[RCVindx]=RCX
RCVindx=RCVindx+1
RCVdata[RCVindx]=0  'TACK A 0 AT END OF ARRAY
IF RCVindx > 999 THEN  
RCVindx=999
ENDIF
       
LEAVEOK1:          'LEAVE WITHOUT STORING RCVD CHAR
RCFLAG=1

[Demon]

checking your stuff........ if you use interrupts (DT ints), for RX interrupts, you would not use PB hserin in the int routine. Rather get the characters in your routine and store them in the locations you designated and advance counter and check for some beginning or ending character...

But the 2nd RX PIC receives perfectly. It's the 1st TX PIC that gives a framing error. And yet the 2nd RX gives an ACK using the HSEROUT structure, and it can DISABLE transmitter just fine.

I just don't get why PIC #1 cannot TXSTA.5 = 0, but PIC #2 can.

(I am going to keep that code on file, cause I'm sure it's going to be useful one day)


EDIT: I'm starting to think maybe I'm too dense to see the forest...

[Demon]

Question: why do people use TX INT?

I can understand why you want to use RX INT, cause you don't know when the data will be incoming, but I do know when the data is being transmitted.

I'm just wondering out loud that maybe I'm not using the best technique to transmit...?

[amgen]

don't give up on yourself or sell yourself short !...... it is a good project

[Demon]

don't give up on yourself or sell yourself short !...... it is a good project

It's an awesome project. I can almost see the light at the end of the tunnel. I've done unit tests of every component all the way up to interfacing with MS Flight Sim. I'm just not seeing why I can't disable the transmitter in PIC #1.

I added a PAUSE to guarantee that everything is sent on PIC #1. The 2 PICs transmit successfully back and forth, and then I get a lone FRAMING ERROR all by itself, and PIC #2 locks up (there are no more blinking LED on channel 3).

    TXSTA.5 = 1                     ' TXEN: Transmit Enable bit
    hserout [   "[1]"    ]                             
    while TXSTA.1 = 0               ' Check TRMT: Transmit Shift Register Status bit
    wend
    
    PAUSE 100
    
    TXSTA.5 = 0                     ' <----- Causes Framing error after last byte !

So it's not an issue of losing bytes, it's definitely something peculiar about TXSTA.5 = 0.

[tumbleweed]

DISABLE transmitter causes a FRAMING ERROR on 1st PIC, but not on Ack message on 2nd PIC

In post 8 the trace is showing that the analyzer is detecting a framing error being generated by the transmitter when it sends the ']' and disables TXEN.
The TX data line should never idle low... that looks like a serial BREAK condition to the receiving side and will likely generate framing and overrun errors on that end.

A framing error by itself doesn't really cause any issues, but an overrun error will stop everything in its tracks until you clear the error. I see you have 'DEFINE HSER_CLROERR 1', so hopefully that's trying to take care of it, but maybe not. The way you have the receive arranged if things get out of sync then it might lock up waiting for something that's not going to happen.

As I said, if setting TXEN=0 causes the TX data line to go low that you need to change the TRIS/LAT register settings in your setup to stop that from happening.
Try initializing the pins with LATC6 = 1 and TRISC6 = 1. That should set the default state of the TX pin to high, which is the proper idle state.

You'll have to rethink all of this later when you try to add more devices since you can't just tie multiple TX outputs together, even if they're "disabled".
They would need to be tri-state/open-drain in the idle state, not driven high or low.

[Demon]

...You'll have to rethink all of this later when you try to add more devices since you can't just tie multiple TX outputs together, even if they're "disabled".
They would need to be tri-state/open-drain in the idle state, not driven high or low.

Yes, they'll definitely be tri-state.

[Demon]

I decreased the pause to 300uSec so everything is in the window when zoomed in.

The 2 transmits are working just fine, with the framing error over on the right.

[Demon]

I'm not sure exactly what you intend to do, ...

I'll be adding several more PICs on the network later, along with a tri-state BUSY line. The BUSY line will determine which PIC will be permitted to TRANSMIT at any given time. And that's why I ENABLE / TX / DISABLE, that code is in anticipation of more PICs being added.

...If you want it to be an input/tristate with an external pullup then set TRISC6

I have 4K7 pull-ups on both TX and RX pins. I only have RX set as Input. I plan on using a separate Busy line as tri-state.


I still don't see why PIC #1 gets a framing error, when PIC #2 doesn't and it's using essentially the exact same code...?