Help understanding HSERIN/HSEROUT

[flotulopex]

By just monitoring flag bits and doing a little house-keeping, you have tons of time to do other things while the hardware UART buffers inbound data for you...

Hello there,

I've been spending some hours on searching information about using HSERIN with its interrupt, RCIF (PIR1.5), and found an interresting info in one of Bruce's posts. It wasn't about the interrupt but he explained and other way around very clearly.

My project is about a 3G monitoring system and receiving SMS messages is crucial (= it is crucial not to miss any incoming SMS).

Why do I search for unsing interrupts? Because, IMO, it's the only way to make sure I will not miss any incoming SMS.

Am I right or not, I don't know and maybe one of you can tell. But in the doubt, I'd like to give the best chances to my program not to oversee any SMS.

Bruce states that there are tons of time to do whatever you need but in my case, where among others I'm controlling four latching relays, setting them and checking their states takes at least 0.5 seconds added to the rest.

I never had the case up to now but I imagine I could receive to SMS within 0.5 seconds (but, as said, I'm not sure).

Anyway, I have posted here under just a piece of my full code where the principle of the RX EUSART interrupt should be tested. Unfortunately, it doesn't work and I can't find why.

' ====== FUSES 16F690 =============================================================================
#CONFIG
    __config _FCMEN_OFF &_IESO_OFF &_CPD_OFF &_WDT_OFF &_INTRC_OSC_NOCLKOUT &_BOR_OFF &_CP_OFF &_PWRTE_OFF &_MCLRE_OFF
#ENDCONFIG
@ ERRORLEVEL -306

' ====== REGISTERS =================================================================================
OSCCON      = %01110000 ' Internal RC set to 8Mhz - Register not to be used with XTal
OPTION_REG  = %10000000 ' PORT A&B Pull-Ups (look WPUA & WPUB)
ADCON0      = %00000000 ' A/D Module
ANSEL       = %00000000 ' Select analog inputs Channels 0 to 7
ANSELH      = %00000000 ' Select analog inputs Channels 8 to 11

' ====== EUSART SETTINGS ==========================================================================
' Interrupts registers
PIE1.5      = 1         ' Enable interrupt on EUSART
INTCON.7    = 1         ' PEIE peripheral interrupt
INTCON.6    = 1         ' GIE global interrupt

' Hardware EUSART registers (RX = PORTB.5, TX = PORTB.7)
RCSTA       = %10010000 ' Enable serial port & continuous receive
TXSTA       = %00100000 ' Enable transmit, BRGH = 0
SPBRG       = 12        ' 9600 Baud @ 8MHz, 0.16%

' ====== DEFINES ==================================================================================
Define OSC 8
DEFINE HSER_CLROERR 1   ' Clear overflow automatically
DEFINE NO_CLRWDT 1      ' Forces manual use of CLRWDT

' ====== VARIABLES ================================================================================
LED1        VAR PORTC.4
LED2        VAR PORTC.5
Counter     VAR BYTE    ' ...a counter
RxBuffer    VAR BYTE(18)' maximum SMS length (in characters)

' ====== PROGRAM ==================================================================================
ON INTERRUPT GOTO INCOMING_SMS

WAITING_LOOP:
    TOGGLE LED1
    PAUSE 1000
    GOTO WAITING_LOOP

MAIN:
    ' Do whatever needs to be done and go back to waiting loop
    LED2 = 1
    GOTO WAITING_LOOP

END

' ====== ISR ======================================================================================
    DISABLE
INCOMING_SMS:
    WHILE PIR1.5
        RxBuffer(Counter) = RCREG
        Counter = Counter +1
    WEND
    RESUME MAIN
    ENABLE

[Ioannis]

I think there is no point in hunting down the incoming SMS as they are available in the GSM module.

You can once your MCU wants or is available to ask for the new messages, and select the most recent or decide from the list which one you want to read, deleted etc. Your GSM module may receive also messages from the Network operator, messages by error from someone that typed wrong number or ads. So you better check the list and see who sent it, then process it.

In this case you do not need Interrupts. Maybe if you want to raise a flag that a new SMS has arrived, but anyway, it is not necessary.

Also On Interrupts are slow by default! I think I never used them.

Ioannis

[richard]

My project is about a 3G monitoring system and receiving SMS messages is crucial (= it is crucial not to miss any incoming SMS).

the problem as i see it is that you are mixing up receiving a SMS message notification with receiving serial data without losing characters.


the question really is
how can i receive serial data as a background process with out data loss ?
how can i signal foreground process that a message has been received and not lose messages?


a workable solution is a interrupt driven ringbuffer for serial reception
that signals the foreground with a flag on completion of notification message.


the ringbuffer must be large enough to allow processing without data loss
the chip must have adequate speed and resources [not a 690, more like 16f1829]
hserin is not in the solution , its not flexible enough to be useful for this sort of task


you will find ringbuffer examples on both forums

[Ioannis]

Richard,

I think what you propose is the best solution and ultimately, Roger may follow it.

But it may be too complicated at the moment to have such an advanced data handling. Or not?

Ioannis

[richard]

its like trying to remove the head off a motor with a shifting spanner.
anyone who is serious about these things has a socket wrench in their toolkit

with proper tools things are easy, if your serious you make the investment.
not only that when you have some isr driven serial tools in your kit all sorts of
tasks become possible opening up a whole new vista

[Ioannis]

Totally agree, but Roger is still using On Interrupts...!

Ioannis

[flotulopex]

Hi,

I don't need to stick to interrupts; I just thought this would be a good idea....

The thing is, I don't know the right (or best) "tool" to use and I appreciate your help and comments to take the correct path for my project

"Ring buffer" is new to me so I'll first have to spend some hours of reading and searching to get more info. My monitor prototype is already in the field and every immediate improvement, the one I may have the skills to make immediately, is the always the best.

So, because of my lack of knowledge (but it is getting better every day), these are the tools I will rely on for now:

I think there is no point in hunting down the incoming SMS as they are available in the GSM module.

Having a routine checking the received message list every 5 seconds or so will allow me to start to improve the reliability of my monitor asap.

Richard is right: I'm mixing up things and tracking incoming serial data is actually not that crucial. For any reason, I was focusing on the wrong target....