ISIS Demo

[JohnB]

Is there a demonstrator version of ISIS that supports the 18F27Kxxx series and if so where can I download it.

[top204]

The K42 devices are not supported in Isis yet John.

I have the 8.14 SP0 version that supports the 18FxxK40 devices, but it is rather full of anomalies, and even the simplest program to flash an LED on a K40 devices does not work, and some colour graphic LCDs have a tendency to crash the Proteus program altogether when they are initialised. :-)

[JohnB]

@top204
That's a shame, I am struggling to get my serial receive processing working, it all looks very opaque.
if I understand your implementation of the buffer correctly even when I take a value from the buffer the data still remains in the buffer.
if I am right, what is purpose of Global_TByteInBuffer2? As far as I can see it doesn't get cleared unless USART2_ClearSerialBuffer or USART2_DisableInterrupt are called.

[top204]

The buffer will keep its data in it, but its positions will change and that is how the program knows that there is still something in it, and where it is. For example:

__HRsin1__:
    While USART1_bIndexIn = USART1_bIndexOut : Wend        ' Wait for a byte to appear in the serial buffer before retrieving it

The "Global_tByteInBuffer1" bit is set when something appears in the serial buffer and must be reset in the main program when it has been read. This flag comes in very handy when a program is in a loop doing other things, then it checks the flag whenever it can and knows it needs to do something with the new serial data that has arrived. It also comes in handy if the microcontroller is sent to Sleep, so when it is woken up, it can check the flag and know that it was, probably, the USART that woke it up, so go look for the serial data before doing enything else.

If you want to clear the buffer and its pointers etc, after using the serial data, call the "USART1_ClearSerialBuffer()" procedure. Otherwise, the serial buffer will just go around and around, as a buffer should, and its index tells the program where the new data is within it:

Sub USART1_GetByte()
    Inc USART1_bIndexOut                                    ' Increment USART1_bIndexOut pointer (0 to 255)
    If USART1_bIndexOut >= _cUSART1_BufferSize Then        ' End of buffer reached?
        USART1_bIndexOut = 0                                ' Yes. So reset USART1_bIndexOut
    EndIf

And within the interrupt itself:

Inc USART1_bIndexIn                                ' Move up the buffer
If USART1_bIndexIn >= _cUSART1_BufferSize Then     ' End of buffer reached?
    USART1_bIndexIn = 0                            ' Yes. So reset USART1_bIndexIn
EndIf

[JohnB]

Thanks, that's what I was guessing.

If there are many unread bytes in buffer when the main loop reads it, I assume loop can do successive reads until USART1_bIndexIn = USART1_bIndexOut?  After that I need to reset the Global_tByteInBuffer1.

[top204]

The HRsin/HSerin commands, with and without timeouts, act just as normal, but read from the buffer instead of reading directly from the USART. So if there are bytes left in the buffer, they will read them.

The "Global_tByteInBuffer1" bit flag is not used by any of the routines, it is just an indicator to the user that something has arrived in the serial buffer. It does not need to be used at all, and can be removed from the program if not required. But its normal use is to reset it once it has been acknowledged that something has been received and the program is using the Hrsin/HSerin commands to fetch the data.

For example, I use it in an AT+ parser, so when the program is doing its thing, it looks at the flag and if it is set, it calls the AT Parser procedure:

Do
    '
    ' Do lots of things in the loop
    '
    If Global_tByteInBuffer1 = True Then  ' Has something been received by the USART?
        AT_Parser()                       ' Yes. So call the AT parser procedure to receive the data and parse it
    EndIf
Loop