Microcontrollers & Embedded System Designs

 

So here’s the difficult part. The FBUS2 protocol is made up of numerous bytes and always start with ‘0x1E’ for cable type of connection (we are really not worried for IR or Bluetooth here)

 

Let’s see a frame of bytes which when sent to the Nokia 3310/5110 phone will reply back with the h/w and s/w version of the phone.

 

 

 

Byte0=Frame id 1E=cable

Byte1=Destination address=00=phone

Byte2=Source address=0C=terminal/micro/PC

Byte3=Type of command (D1=get version)

Byte4=MSB of frame length

Byte5=LSB of frame length=07 (7bytes ahead and more)

Byte6=Byte7=Byte8=Byte9=Byte10=Byte11=don’t need to worry about them! J

Byte12=Sequence number or Seq.No. (Very important)

Byte13=is padding byte and is present if Frame length is odd.

Byte14=Even checksum

Byte15=Odd checksum (embedtronics.com was wrong here)

 

 

Byte5 has the info of how many more bytes there are about to come till Seq.No.. comes (which means that after Seq.No.., minimum 2 bytes checksum are always present and a padding byte=0x00 is inserted to make the whole frame even .In our case padding byte=0x00 is present since frame length is odd=0x07)

 

A little more about the sequence number here: The Seq.No. as the name suggests defines the sequence of frames and goes from 0 to 7 and back to 0..and so on.

E.g: In above example if we were to send the same Get version frame 9 times in a row, what should be done? You are absolutely correct! In the first frame, Seq.No.. is 0x60, next its 0x61,next 0x62……0x67 (and back to..) 0x60. That’s all. The phone will be having a count of the source’s (micro) Seq.No.’s, and if it’s incorrect, then phone will not respond. And you will have to re-initiate the whole ‘U’ sending again.

 

Now about the checksums. These are nothing but the XOR of all bytes. In our case they are XOR of all bytes in even positions and odd positions

 

E.g.: in above example the even checksum will be calculated like this

Byte0 XOR Byte2 XOR Byte4 XOR Byte6 XOR Byte8 XOR Byte10 XOR Byte12

0x1E     ^    0x0C    ^      0x00      ^     0x00      ^    0x00    ^      0x00        ^     0x60

 

=0x72

 (Keil compiler)

Whereas odd check sum is obtained by XORing all odd placed bytes

Byte1^Byte3^Byte5^Byte7^Byte9^Byte11^Byte13=0xD5

 

Now we’ve understood how a frame is made up.

When such a frame is sent, the nokia phone replies with 2 frames

a)      An acknowledge frame to tell us that ‘he’ recd the frame.

b)      Actual data frame.

 

Let’s see how the ACK frame is made up

 

 

Keep in mind, the above frame is sent by Nokia. (Nokia is source now)

 

Byte0=Frame id 1E=cable

Byte1=Destination address=0C= terminal/micro/PC

Byte2=Source address=00= phone

Byte3=Type of command (7F=acknowledge frame)

Byte4=MSB of frame length

Byte5=LSB of frame length=02 (2 bytes)

Byte6= (replying to what was sent/asked by micro) D1=get version

Byte7=Seq.No. (no padding byte present after Seq.No. since

            Frame length=0x02=even)

Byte8=Even check sum

Byte9=Odd check sum

After this ACK frame, the phone will send the actual data frame, with the h/w and s/w version (check my excel sheet on this)

 

It isn’t over yet!..The phone also wants a confirmation that we/microcontroller have received the data, so it will be waiting for the ACK frame that we are supposed to send. If we don’t send this ACK frame, the phone sends the data two more times (after the first frame) which means that we are entitled to the data 3 times before phone stops sending data.

 

This also means we need to send an ACK frame to the phone now. This too is quite simple .The ACK frame that we should send is like this

 

 

 

I think there’s no need to explain the bytes now, but for the sequence number.

When we/micro sends an ACK frame, the sequence number is not the one we are generating (from x0 to x7) but it is the last three bits of the Seq.No. of previous received data frame. No? Haven’t got it? Let’s take the example of the Get-version frame.

 

The phone had sent 0x41 as the sequence number in its h/w , s/w data frame

0x41= 0100 0001 b

We need to send the lower three bits xxxx x001 b of this Seq.No. as our ACK frames sequence number. (But I have found that the lower nibble’s MSBit is never 1, so masking off the higher nibble just does the job)

You know how to calculate checksums.

 

 

The general idea is like this

a)      Abhijit asks for some data

b)      You say, “I understood what you want”

c)      You send what Abhijit wanted.

d)      You wait to see if Abhijit got what he wants.

e)      If Abhijit does not say that he received the data,You send the data one more time.

f)        You wait to see if Abhijit got what he wants

g)      If Abhijit does not say that he received the data,You send the data one more time.

h)      Now You stop sending data.(Since Abhijit is really deaf or he is rude)

i)        On the contrary if Abhijit says he got the data the very first time, you stop sending more data.

 

Just like 2 people are talking!!!