serial data ideas please

[languer]

A few ideas perhaps...

I could substitue a 18F2620 which i have tried but I haven't got the clock speed/usart settings or anything right with that :?
It worked at 8mhz but not at 32MHz.
I did set the osc define to 32.

I believe you need to specify the PLL as active to get 32MHz from the 8MHz (which I think is what your trying to use).

I'm guessing you have something like this:

Main Loop:
 loop doing SERIN stuff

Interrupt Service:
 Service HW USART for receive data, and re-send

Perhaps you can create a ring buffer, and every time the HW-UART interrupt fires save the the data. The main loop would then look like.

Main Loop:
 Disable HW-USART interrupt
 Check HW-UART TX buffer is empty
 If empty, send next ring buffer data through HW-UART (you will do this writing directly to the TXREG and not using HSEROUT)
 Do SERIN stuff
 Enable HW-USART interrupt (for receive only)

Interrupt service would then look like:

Interrupt Service:
 Service HW USART for receive only (store in ring buffer)

[amgen]

use DT int for the 104K serial on HWusart TX/RX and do the 9K serial in basic ???

[retepsnikrep]

Thanks for the ideas.

Amgen sadly the hardware is from an old project the 10.4K serial is fixed on normal pins and the 9.6k continious data is on the usart.

Languer at the moment when the RX INT fires my routine gets the incomming byte and fires it straight out of the USART TX, it then checks in case a second byte has arrived (Two tend to arrive together) and repeats the above if it has. Then it returns and by that time has missed a byte on the other serial in data.

My INT Handler looks like this.

'-------------------------------------
' INTERUPT HANDLER
'-------------------------------------
        
INT_Serin:                                      'Serial Interrupt routine

    IF OERR Then usart_error                 'Check for USART errors
    ptr_in = (ptr_in + 1)                       'Increment ptr_in pointer (0 to 48)
    IF ptr_in > (BufMax-1) Then ptr_in = 0             'Reset pointer if outside of buffer
    IF ptr_in = ptr_out Then Buffer_Error            'Check for buffer overrun
    HSerin [buffer[ptr_in]]                     'Read USART and store data in next empty location
    ptr_out = (ptr_out + 1)                         'Increment ptr_out pointer (0 to 48)                          
    IF ptr_out > (BufMax-1) Then ptr_out = 0              'Reset pointer if outside of buffer 
    bufchar = buffer[ptr_out]                       'Read buffer location
    HSEROUT [BufChar]                       'Send the character
    Toggle RedLed                               'Flash the Red Led
    IF RCIF Then INT_Serin                     'Check for another character while we're here

@ INT_RETURN                                   ;Return to program

[retepsnikrep]

Just trying the 18F2620 chip at 8mhz it works as expected. Lags behind after a few characters etc. But otherwise fine.

But at 32mhz with PLL enabled the usart seems to have gone from outputing data at 9600 to 2400 according to my logic analyser :?

If anything i would have expected it to go to 38400 not the other way round. I'm obviously missing a gothca somewhere.

#CONFIG
 __CONFIG _CONFIG1H, _OSC_INTIO67_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
 __CONFIG _CONFIG2L, _PWRT_OFF_2L & _BOREN_OFF_2L
 __CONFIG _CONFIG2H, _WDT_OFF_2H
 __CONFIG _CONFIG3H, _PBADEN_OFF_3H & _LPT1OSC_OFF_3H & _MCLRE_OFF_3H
 __CONFIG _CONFIG4L, _STVREN_OFF_4L & _LVP_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L
#ENDCONFIG

DEFINE OSC 32            'Set PicBasic Pro processor speed to 32 Mhz   
OSCCON = %01110110         'Internal 8 mhz Osc and stable 
OSCTUNE= %01000000        'Pllen Frequency Multiplier Enabled for 8mhz Clock enables 32mhz Clock!!

CMCON  = %00000111        'Comparators Off
CVRCON = %00000000        'CvRef Powered Down 

CCP1CON= %00001100        'CCP1 Module PWM Mode
CCP2CON= %00000000        'CCP2 Module Disabled 

HLVDCON= %00000000        'HLVCON Disabled

T1CON  = %00110000        '$30 = Prescaler 1:8, TMR1 OFF
    
TRISA = %00001011         'SET PORTA0, A1 & A3 AS INPUTS, REST AS OUTPUTS
TRISB = %00000000         'SET PORTB AS OUTPUTS
TRISC = %10010000         'SET PORTC AS OUTPUTS EXCEPT PORT C4 & C7 
    
ADCON0 = %00000001        'SETUP ADC & ENABLE ADC MODULE on AN0
ADCON1 = %00001110        'SETUP ADC SET REFV to VDD & VSS AN0 
ADCON2 = %00100010        'SETUP ADC FOSC/32 LEFT JUSTIFY TAD 8

Any ideas?

[retepsnikrep]

Just checked and a pause is taking 4 x longer than before so looks like pbpro has compensated but that the pic is still stuck at 8mhz :?

[HenrikOlsson]

Hi,
Do you have to echo the char from within the ISR? Perhaps you could set a flag indicating that there is data to send and then do the sending a out_ptr handling in the main routine. That way you'll spend less time in the ISR. Changing:

bufchar = buffer[ptr_out]               'Read buffer location
HSEROUT [BufChar]                       'Send the character

to

HSEROUT [buffer[ptr_Out]]

Might also save a couple of cycles.

However, I think the main culprit is the saving/restoring of the system variables when entering and exiting the ISR (which DT-INTS does for you). You should be able to run the 18F2620 at 32Mhz by enabling the PLL as languer says.

Just thinking out loud.....

[retepsnikrep]

I think I'm stuck with enabling the 32mhz mode. PBPRO is aware but the pic is not running at 32mhz :?

[HenrikOlsson]

Hi,
Normally you need to enable the PLL by setting the correct CONFIG (which you now have set to INTIO67) but it seems as if, when using the internal oscillator, you enable it by setting PLLEN bit (OSCTUNE.6) - which apparently have done... So, right now I can't think of anything in particular but I'd take an extra read thru the Oscillator section of the datasheet and take a look if there indeed IS a CONFIG which seems reasonable for internal oscillator WITH PLL.

/Henrik.

[languer]

The one thing I can see would help is not to do the transmission inside the interrupt loop. Not sure how PBP implements the HSEROUT (you'll need to look at the ASM list for that), but most compilers will check the buffer empty condition, load the USART, and (many times) wait until the buffers empty again before exiting the routine.

The USART normally consists of two registers: TXREG and TSR. You load the TXREG with the information you want to send, if the TSR is empty then the TXREG is loaded into the TSR on the next Tcy; this is not an issue. But if the TSR is full (or currently sending data) then you must wait until it empties before the TXREG can load it and create the Buffer Empty condition. Because the USART is a serial device, you could potentially need to wait for 8-bits to be serially sent, before the TXREG is emptied. This could cause a bottleneck on the transactions.

In your case, since you are receiving and sending at 9600bps on one side, and receiving at 10400bps on another; you could potentially hold the 10400bps, while waiting for the TXREG to clear. To work around this, you can load the TXREG directly (if it's empty), and if not, wait for the next go-around until it empties. That way you eliminate the potential of holding the 10400bps reception waiting for the 9600bps transmission. Hopefully this is a bit more clear.

Some Pseudo code:

Main_Loop:
    PIE1.RCIE = FALSE '(disable EUSART Receive Interrupt Enable bit)
    IF PIR1.TXIF = TRUE THEN '(if TX buffer empty)
        nextout = nextout % buffer_size
        HSEROUT buffer[nextout]   
        nextout = nextout + 1
    ENDIF
    SERIN.... (perform SERIN routine, with timeout - this is important)
    PIE1.RCIE = TRUE '(enable EUSART Receive Interrupt Enable bit)
    GOTO Main_Loop

Interrupt Service:
    nextin = nextin % buffer_size
    HSERIN buffer[nextin]   
    nextin = nextin + 1