Serial communication between 2 Microcontrollers

[basparky]

Hi All,

I have a dsPic (a) which communicaties with a Pic(b) over UART. The Dspic is the master and the Pic the slave. The slave(b) can be a unique device with his own data packet output.
In my current deisgn i have the slave sending his datapacket like following:

Code Select Expand

Proc SendMessage(Nr As Byte)
'Str = 255-3-200-0-100-100-233 wChecksum = 891 bCheckSUm = 123 
    StrToMain[0]    = 255           'Fixed ID
    StrToMain[1]    = Modus   
    StrToMain[2]    = Command     
    StrToMain[3]    = Throttle
    StrToMain[4]    = Dir
    StrToMain[5]    = SafetySwitch
    StrToMain[6]    = 233 'dummy           
    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 
   
    For bIndex = 0 To 7
      HRSOut StrToMain [bIndex]
    Next
   
    Interval = 0             
    TMR0ON = 1
    TMR0IE = 1         
EndProc

The master is receiving like:

Code Select Expand

Isr U2RXInterrupt   
    ID = 255'121 'Id from joystick
       
    If U2STAbits_OERR = 1 Then
        Clear U2STAbits_OERR
        SOM = 0
        Index2 = 0
        GoTo ExitInterrupt2
    EndIf
       
    USART2bRx = U2RXREG   
   
    'catch start off message
    If USART2bRx = ID And SOM = 0 And Index2 = 0 Then
        SOM = 1
        Index2 = 0
    EndIf

    '   
    If SOM = 1 Then
        StrJoyStick[Index2] = USART2bRx
        Inc Index2
        If Index2 > 7 Then
            Index2 = 0
            ReceivedFromJoystick = 1
            SOM = 0
            Toggle LedRd
        EndIf
    EndIf
   
    ExitInterrupt2:
    Clear IFS1bits_U2RXIF
EndIsr


So the slave is sending his ID and a data packet in a fixed length. As shown the receiver waits for the ID 255 and then expects the payload before waiting for the next startbyte (ID).

I would like to make this communication more robuust and create somehow a ID based receive routine.
At this moment i have 3 types of slave. each with their own different datapacket and ID. Does anyone have some suggestions how to build this robuust?
I had issues with sending the SLaves ID because the value 255 van also be the value of one of the bytes in the payload. After knowing this i made a catch start off message as shown in the ISP but i think its too basic to have this working for 3 slave ID's.

I think i'm asking a direction and some help make this work in practise. I have no experience with dynamic data packages but believe this is what it should be on the receiver side.

Any hints or information how to do this would help me a lot. Thanks in advance!

[John Lawton]

You could use ninth bit addressing to indicate the packet start?

John

[trastikata]

Is it possible to include a MAC address to each packet?

[TimB]

I would recommend that you use the 3.5T end of packet system. It's pretty simple to implement you start a timer after the RX of every byte.  In your RX routine when you get a new byte just check if the timer has zeroed out. If that is the case then clear pointers etc and presume this is the address byte.

Check the address against your own and if it matches set your RX state machine to load the rest of the packet.

Just to clarify the 3.5T is the time to send 3.5t bytes

[basparky]

Thanks! I like the simplicity of the use of 9th bit usage to detect start.
Just wondering which register present this bit in my dspic33FJ.
i will dive into the datasheet

[John Lawton]

For instance: https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/70292G.pdf

Pages 221/223/224/226 look for "9-bit data" and "address-detect"

John

[shantanu@india]

You can also implement Modbus RTU if packet integrity is an issue.

[Gamboa]

Basparky,

I use a very structured frame model. This is cumbersome to manage, but it's very useful and versatile.

A typical frame might look like this:
{STX}{TRANSMITTER_ADDRESS}{TRANSMITTER_DEVICE_TYPE}{RECEIVER_ADDRESS}{RECEIVER_DEVICE_TYPE}{VER_PROTOCOL}{COMMAND1}{COMMAND2}{DATA_0}...{DATA_N}{NUMBER_BYTES}{CHCKSUM1}{CHCKSUM2}{ETX}

If you use point-to-point communication you don't need addresses, but on an RS485 bus you do need to address the devices.

STX and ETX are the frame delimiters. This is very useful because you know in advance when a frame has arrived.
With this structure, you don't need the frame length to always be the same; it can be variable, giving you flexibility for each command.

Now, with a structure like this or a similar one, we need to see how the reception is carried out.

I always use an array for USART reception, an index that indicates array fill level, and a USART reception interrupt. You also need a Timer interrupt to clear the array if the frame arrives incomplete within a specified time (three times the character's lifespan or more). The reception process is simple: as characters arrive, you store them in the array and check if the end of the frame has been reached and if the array has overflowed. You continue filling the array until the end of the frame is reached. When the end of the frame is reached, you set a flag in the interrupt, FLAG FRAME RECEIVED, which will indicate to your main program that a frame has arrived.

Now, in the main program, you analyze the frame to see if it is correctly formatted:

Does it start with STX and end with ETX? Yes

Is the frame length correct? Yes

Is the checksum correct? Yes

Are the command and data within acceptable limits? Yes
Etc..Etc
If everything is correct, you proceed to execute the received command. If something goes wrong, you send a NACK with the error and discard the frame.
Once the command has been executed successfully, you send an ACK.

This is how I usually handle communications through USART. I hope it helps give you some ideas.

Regards,
Gamboa