Dspic33Fj128MC706A UART<> pic18F25K80 – 119 days old

[basparky]

Hi,

I have a pic18F25K80 sending every 500ms a byte array.

Proc SendMessage()
Dim ID As Byte
Dim StrToMain[8] As Byte
Dim wCheckSum As Word




    StrToMain[0] = 1
    StrToMain[1] = Modus
    StrToMain[2] = Command
    StrToMain[3] = HallFwd
    StrToMain[4] = HallBwd
    StrToMain[5] = HallLeft
    StrToMain[6] = HallRight
    wCheckSum = StrToMain[0] + StrToMain[1] + StrToMain[2] + StrToMain[3] + StrToMain[4] + StrToMain[5] + StrToMain[6]
    bCheckSum = wCheckSum.LowByte    
    StrToMain[7] = bCheckSum
    TMR0ON = 0
    TMR0IE = 0
    HRSOut Str StrToMain
    Interval = 0
    TMR0ON = 1
    TMR0IE = 1    
EndProc


GoTo Main

I would like to catch this array in a ISR routine. In this case using the second UART RX2 from the dsPic.
Setup:

    Declare Hserial2_Baud = 9600
    Declare HRSOut2_Pin = PORTF.5 
    Declare HRSIn2_Pin  = PORTF.4
  
    U2MODEbits_URXINV       = 0     'Rx inverse    
    IPC7bits_U2RXIP0 = 1                          ' \
    IPC7bits_U2RXIP1 = 1                          ' | Priority interrupt level 1
    IPC7bits_U2RXIP2 = 1  
            
    U2MODEbits_UARTEN       = 1
    U2STAbits_UTXEN         = 0
    IEC1bits_U2RXIE         = 1

ISR Routine:

Isr U2RXInterrupt


    Toggle LedRd
    If U2STAbits_OERR = 1 Then 
        Clear U2STAbits_OERR
        GoTo ExitInterrupt2
    EndIf
    
    InputByte[Index] = U2RXREG
    
    Inc Index
    If Index > 7 Then
        ReceivedFromJoystick = 1
    EndIf
    
    
    
    
    ExitInterrupt2:
    Clear IFS1bits_U2RXIF
EndIsr

In the main loop i just send out the byte array to serial terminal through U1TX.

The problem is that the ISR is triggert (led blinks) but the U2RXREG is always empty. I have been trying all kind of scenarios but i do not get any data from this register.
If i use something like:
USART2BRX = HRSIn2
HRSOut Dec USART2BRX,"\r\n"

in the main routine i get the byte as expected...

Does anyone know how to solve this issue?

[top204]

Comment out the error checking part of the Isr, just to make sure you are not receiving errors all the time and the array will not be filled.

Also, if the Hrsin2 or Hrsout2 commands are not used in a program, the Baud rate and pins used in the declares will not be entered in the Asm file, so the SFRs will not be configured, so you will always receive errors. To make sure they are being used, place a simple Hrsout2 13 command in the main of the program.

Then take a look in the Asm file (Press F2) and go to the block of asm text after "proton_main_start_:". You will see:

bset.b TRISF,#4
bclr.b TRISF,#5
bset.b LATF,#5
mov.w #0x8808,W0
mov.w W0,U2MODE
bset.w U2STA,#pp_utxen
mov.w #416,W0
mov.w W0,U2BRG

This is the setting up of the USART2 from the declares.

If that is the problem, and you cannot use a standard Hrsin2 or Hrsout2 in your program, you can create that code in your program by making the same Asm code in BASIC form:

Input __hrsin2_port.__hrsin2_pin
High __hrsout2_port.__hrsout2_pin
U2MODE = $8808
Set U2STAbits_UTXEN
U2BRG = 416

Place this in your setup procedure so it is run before USART2 is accessed.

[basparky]

Thanks top204, after following your instructions by checking the generated ASM file i noticed your remarks and got to a workable solution. I have an issue with the data received. I hope you have time for another look at my code please.



Init receiver UART code: (dspic)

    Input __hrsin2_port.__hrsin2_pin
    High __hrsout2_port.__hrsout2_pin
    U2MODE = $8808
    Set U2STAbits_UTXEN       
    Set IEC1bits_U2RXIE


    
    Declare Hserial2_Baud = 9600
    Declare HRSOut2_Pin = PortF.5 
    Declare HRSIn2_Pin  = PortF.4    
    
    IPC7bits_U2RXIP0 = 1                          ' \
    IPC7bits_U2RXIP1 = 1                          ' | Priority interrupt level 7 highest priority interrupt
    IPC7bits_U2RXIP2 = 1

I'm currently receiving a string with data every 500ms. The ISR routine looks like this:

Isr U2RXInterrupt    
    ID = 121 'Id from joystick
    Toggle LedRd    
    If U2STAbits_OERR = 1 Then
        Clear U2STAbits_OERR
        GoTo ExitInterrupt2
    EndIf
        
    USART2bRx = U2RXREG    
    
    'catch start off message
    If USART2bRx = ID Then
        SOM = 1
        Index2 = 0
    EndIf
    'load 8 bytes into array
    
    If SOM = 1 Then
        StrJoyStick[Index2] = USART2bRx
        Inc Index2
        If Index2 > 7 Then
            Index2 = 0
            ReceivedFromJoystick = 1
            SOM = 0
        EndIf
    EndIf
    
    ExitInterrupt2:
    Clear IFS1bits_U2RXIF
EndIsr

The sender (18F pic) code is:

Proc SendMessage()
Dim ID As Byte
Dim StrToMain[10] As Byte
Dim wCheckSum As Word


'0'1        ID = 1
'1'0-3      Modus
'2'         Command
'3'         HallFwd 
'4'         HallRev
'5'         HallLeft
'6'         HallRight
'7'         ChecckSum
    StrToMain[0] = 121
    StrToMain[1] = Modus
    StrToMain[2] = Command
    StrToMain[3] = HallFwd
    StrToMain[4] = HallBwd
    StrToMain[5] = HallLeft
    StrToMain[6] = HallRight
    wCheckSum = StrToMain[0] + StrToMain[1] + StrToMain[2] + StrToMain[3] + StrToMain[4] + StrToMain[5] + StrToMain[6]
    bCheckSum = wCheckSum.LowByte    
    StrToMain[7] = bCheckSum
    TMR0ON = 0
    TMR0IE = 0
    HRSOut Str StrToMain
    Interval = 0
    TMR0ON = 1
    TMR0IE = 1    
EndProc

If StrToMain[0 to 7] is the number 0 the receiver ISR doesnt work anymore? anything else than 0 is fine...
I will try to find why this is myself but it doesn't make sense to me

[basparky]

Aha, I think the number 0 in the string is recognized as end of string / null terminator. Mmmm does this mean i cannot send 0? The number in StrToMain[3-6] are between 50 and 230 so adding 48 as ascii doesnt work without splitting the bytes i guess...

[towlerg]

FWIW the number 0 has a value of $30 or 48 decimal, the string terminator is usually $00, as in win32 ASCIIZ

[tumbleweed]

I think the number 0 in the string is recognized as end of string / null terminator. Mmmm does this mean i cannot send 0?

I don't know if it's always been this way, but you're right... the 'STR' modifier is causing it to treat the array as a null-terminated string, and not just an array of bytes. If you want to send binary data you'll have to do it another way.

[towlerg]

Sorry basparky, I misunderstood what you meant by "the number 0".

[top204]

Sorry for the delay in replying, I'm currently working on 2 projects so my mind is constantly at work. :-)

I see no reason why a 0 would not be accessed, the Str modifier on PIC24 devices does not use them as a null or a terminator. To make sure it is not that, and that you are actually receiving the data, transmit each element of the array seperately, then you will have a definate answer to where the problem lies. For example:

Hrsout Dec StrToMain[0], ",", Dec StrToMain[1], ",", Dec StrToMain[2], ",", Dec StrToMain[3] etc...

With any coding problem, it is always better to simplify the code to try and identify the bottleneck, then when it is working, use different techniques to improve the code and test as changes are made. In the thousands of programs I've created over the, far too many years :-) , this is the way I have always implemented changes, or the beginnings of a code project. i.e. Make sure the principle works, then make changes to improve it.

[tumbleweed]

The library routine [email protected] terminates when it sees a 0 byte in the array.

[email protected] is called when using

Dim StrToMain[10] As Byte

HRSOut Str StrToMain

; generated asm
[email protected]
    ....
    movff PP2,FSR0L
    movff PP2H,FSR0H
    movf INDF0,W,0     <<<<<<<<
    btfsc STATUS,2       <<<<<<<<
    return
    rcall _BYTE__SEND_

[top204]

That code is for an 18F device only. The PIC24 and dsPIC devices have an entirely different mnemonic set. :-) The code for the 14-bit core devices is also different to the 18F, and so is the enhanced 14-bit core code different to 18F and standard 14-bit.

The question is concerning a dsPIC device.

The Str modifier was first implemented before I added true strings to the Proton compiler, so I had to leave it as it was, but Proton24 had Strings from the start, so the Str code for them is:

mov.w #4,W0
mov.w W0,__OSM
mov.w #MyArray,W1
mov.w #0,W3
1:
push W3
push W1
mov.b [W1 + W3],W0
call __hrsout1
pop W1
pop W3
inc.w W3,W3
mov.w #20,W0
sub.w W3,W0,[W15]
bra leu,1b

And there is no null termination. It cycles the length of the array.

I've never been a one to use the built in modifiers when scanning arrays and strings etc. I always like it better doin git in a loop:

For Index = 0 To Bound(MyArray)
Hrsout MyArray[Index]
Next

The above loop can also be elaborated to exit when a particular byte is found or stop certain values being outputted etc...

[tumbleweed]

I think basparky is having a problem with the 18F25K80 side of things...

The sender (18F pic) code is:

That's where his HRSOUT is giving him grief... it's not sending his binary packet.

[top204]

Oops. Sorry Tumbleweed. Having both sets of code in the question confused me. :-(

Then yes, Tumbleweed is correct! The Str modifier will not send nulls (0). It will terminate at one because it is simulating a string variable. A loop to output the arrays elements is all that is needed. The array transmitter can be made into a procedure to keep the code clean:

Proc SendArray(ByRef pArrayAddr As Word, pSize As Byte)
    Dim Index As Byte
    For Index = pSize - 1 To 0 Step -1 
        WREG = Ptr8(pArrayAddr++)
        HRSOut WREG 
    Next
EndProc

Then it is called with:

SendArray(StrToMain, SizeOf(StrToMain))