Hi,
Is this ok?
C

[Moderator: Added code tags, highlighted lines (9, 29, 49, 51, and 57)

If PIE1.RCIE = 1 Then
'overrun error
    If RCSTA.OERR = 1 Then
        RCSTA.CREN = 0  'disable UART
        RXIRQchar = RCREG  '1    'clear UART RX registers
        RXIRQchar = RCREG  '2
        RCSTA.CREN = 1  'reenable UART
        Gosub IRQinitBuf  're-init buffer, discard bad sentence
        Goto RXIRQdone  'done, wait for next character
    Endif  'OERR

'framing error
    If RCSTA.FERR = 1 Then
        RXIRQchar = RCREG  'Read char to clear RCIF and FERR
        'ADD second line¦
        Gosub IRQinitBuf  'Re-init buffer, discard bad sentence
        Goto RXIRQdone  'wait for next
    Endif  'FERR

    'No UART errors, process character
    If PIR1.RCIF = 1 Then
            RXIRQchar = RCREG  'read the received char, clears RCIF

    'Look for $, start/restart filling buf when found
        If RXIRQchar = "$" Then  'Start (re)filling buf on any $
            Gosub IRQinitBuf  'init buffer, index and flags
            robi(robipsn) = RXIRQchar  'store $
            robi_fill = 1  'start storing the sentence
            Goto RXIRQdone  'done with this character
        Endif  'char was $

'no UART errors and character was not $
'If $ was found previously, process character looking for W and no buffer overflow.
'If haven't found $ yet, just ignore character.

        If robi_fill = 1 Then  'if filling buffer, see if there is room in buf
            If robipsn >= (rxbufsize - 1) Then  'last char was at end of buf - buffer overflow so..
                Gosub IRQinitBuf  'restart buffer, discard sentence
                RXerr = 1  'let main know that the buffer overflowed and is restarting
                Goto RXIRQdone  'done, resume looking for next $
            Endif  'buffer overflow

            robipsn = robipsn + 1  'else, there's room in buf so bump index and store character, might be W
            robi(robipsn) = RXIRQchar

            If RXIRQchar = "W" Then  'if end of sentence..
                RCSTA.CREN = 0  'shut down UART
                PIE1.RCIE = 0
                robi_fill_state = 1  'flag buf full
  
                Goto RXIRQdone  'and bye!
            Endif  'RXIRQchar was W
        Endif  'if robi_fill = 1
    Endif  'RCIF=1
Endif  'RCIE=1
'Exit point for each RXinterrupt. Process timers
                RXIRQdone:

 

Hi C.. I normally don't care for framing errors as the CRC takes care of those, but I do restart the continuous read on an overrun.

But your coding has definitely improved.. I'm sure I did a circular buffer on the Oshonsoft compiler. I'll have to have a look.

 

Hi C.. I normally don't care for framing errors as the CRC takes care of those, but I do restart the continuous read on an overrun.

But your coding has definitely improved.. I'm sure I did a circular buffer on the Oshonsoft compiler. I'll have to have a look.

Hi I,
I don't quite follow, but tomorrow, I'm going to a mates house, and I'll point out my list of 'things to do'
I'm modifying old CODE, where many things have changed since it was posted, and as I'm getting mixed up, we can make a flow chart to tidy it all up.
Cheers, C

 

Hi,
Gotos and gosubs are frowned on! If a gosub is substituted by a PROCEDURE is this considered ok?
C

 

Not frowned upon. But they can cause major debug headaches.

When using goto's you have to stay in the same scope. ie within the boundaries of the last stack push.

You have 16 levels of stack, when you call a subroutine you use a position ( two for an interrupt )
take this example:-

main:
   call subroutine1  '<--- say Program counter is 0x40.  Stack now has 0x40 on top
goto main

subroutine1

   goto main ' < ---  Oh no underflow as  0x40 wasn't popped off the stack
            ' even worse goto may not get there as its an 8 bit jump.

end sub ' <--  ( pop 0x40 back into program counter ) going back to 0x41

 

Use of GOTO is discouraged. In BASIC it is unavoidable. The same does not apply to GOSUB.

GOSUB must go to to a part of the program that must end with RETURN. That part of the program, called a subroutine, must be self contained in order to comply with the rules of Structured Programming.

Using PROCEDURE or FUNCTION is a cleaner way to implement subroutines. Not all implementations of BASIC support functions and procedures.

 

Hi I and MrC,
I think I've got it, Thanks C.

 

I have always ben an advocate of the "programmers need a basic ASM knowledge" theory.
Knowing how the chip works really helps when high level programming.

There are C programmers out there that do not understand the software stack , let alone the hardware stack. It just assumed it works and that's enough for them.

 

I have always ben an advocate of the "programmers need a basic ASM knowledge" theory.
Knowing how the chip works really helps when high level programming.

There are C programmers out there that do not understand the software stack , let alone the hardware stack. It just assumed it works and that's enough for them.

Hi I,
Yesterday I was at my mate who is skilled at programming, and I spent the afternoon driving him nuts with frustration, with how I work (It's also frustatrating for me) At the end of the day, we had a broken program!
Today I fixed it and this is how I progress.

One thing I did, which is normal to me but nuts to my mate, and perhaps to you now, is I printed out the secion of program (11 pages) we're working on, and joined it end to end. I colour marked all of the GOSUBS and GOTOS and we could scoll up and down the program instead of our small screens.

You explained the stack, which I almost understand, then I get more questions in my mind which I won't post as I have enough info to be going on with and it would be a diversion. I have too many questions all of the time!

Regarding Gotos and the stack! We checked them all, and none of them now upset the flow.

I'm a visual learner, and this is why I rely on the Oshonsoft SIM that I can watch, and of course these forums.
Cheers, C

 

One of the tenets of Structured Programming is that no program, subroutine, or function should be longer than a printed page (8x10 sheet of paper).

As arbitrary as this may sound, there is a lot of rationale for this.

1) No GOTO must target code on another page.
2) You don't have to flip through pages to find the target line of code.
3) Since functions and subroutines are limited to a single page, you cannot unintentionally GOTO another page.
4) It forces the programmer to think in terms of functional modules.
5) Dividing the entire program into modules makes it manageable and easier to follow and maintain.
6) Dividing the program into functional modules brings opportunity for reusable code, i.e. code libraries of functional routines.

 

One of the tenets of Structured Programming is that no program, subroutine, or function should be longer than a printed page (8x10 sheet of paper).

As arbitrary as this may sound, there is a lot of rationale for this.

1) No GOTO must target code on another page.
2) You don't have to flip through pages to find the target line of code.
3) Since functions and subroutines are limited to a single page, you cannot unintentionally GOTO another page.
4) It forces the programmer to think in terms of functional modules.
5) Dividing the entire program into modules makes it manageable and easier to follow and maintain.
6) Dividing the program into functional modules brings opportunity for reusable code, i.e. code libraries of functional routines.

Hi Mr C,
( I would have to think for a while to remember what arbitary means)

1) No GOTO must target code on another page.
OK.
2) You don't have to flip through pages to find the target line of code.
When I use the 'long' sheet of paper with all of the CODE on, I can find lines.
Once it disappears into INCLUDES, FUNCTIONS and PROCEDURES I have trouble
3) Since functions and subroutines are limited to a single page, you cannot unintentionally GOTO another page.
I'll try not to.
4) It forces the programmer to think in terms of functional modules.
I'm no programmer, and I simply can't think of modules, only 'why is that thing doing what it's supposed to do?', then I find out why, and try to change it.
5) Dividing the entire program into modules makes it manageable and easier to follow and maintain.
Since my mate 'tidied the FULL porgram up and did just that, I have had to get used to it, and it is getting easier. At the moment, I do it my way with the long sheet of paper, then integrate it into the 'tidy' porogram.
6) Dividing the program into functional modules brings opportunity for reusable code, i.e. code libraries of functional routines.
That I get
Thanks
C