TMS570LS07 MIBSPI Design idea needed for our requirement

Rambabu,

Rambabu Pillalamarri said:

1. one MIBSPI master controller should communicate with 4 similar slaves. Slaves are different micro controllers. Each slave has different chip select line. All slaves have same data format. like clock phase, polarity, speed, character length ( 16 bits).

ok.

Rambabu Pillalamarri said:

2. Need to send 3 kind of data length dynamically. 4 bytes, 10 bytes, 15 bytes. Since each buffer is 2 bytes, we can define 2,5,8 buffer lengths for a Transfer group.

How do i need to choose transfer groups and buffer lengths of each transfer group.

Ok good. It really doesn't matter what order the transfer groups are used in because you are using the one-shot triggering method and writing to the transfer group data buffer with the CPU not DMA.

I would just use TG0,TG1,TG2, and TG3 for simplicity.

Even if two TG share the same data format and length, they have different chip selects so I would just use different transfer groups for these, that way you avoid having to reprogram the control field of the transmit buffer.

Rambabu Pillalamarri said:

1. I should check transfer complete of each group through polling. Currently don't want to check through interrupts.

2. Approach should involve very minimal CPU intervention, that is the reason we choose MIBSPI over normal SPI.

There is a potential conflict in these two statements, depending on what you mean by polling.

If you poll in a simple while() loop, and the CPU doesn't do anything else while waiting, then this will wind up utiliing 100% of the CPU for the duration of the SPI transfer.   So polling is OK but you need to be using some technique like an RTOS where you poll but the task sleeps for a while between each poll so that another task has a chance to execute...   IF you don't want 100% of the CPU going to polling the SPI while SPI transfers are ongoing.

Rambabu Pillalamarri said:

3. Trigger of each transfer group is software trigger. settings presently are ONE SHOT, CSHOLD for entire transfer of group, TRG ALWAYS. 

CSHOLD would normally be used with the CSHOLD bit set for all buffers *except* the last buffer in the transfer group.   This would allow the CS\ to go high again (or inactive whatever logic level that turns out to be..) after the transfer completes.   In halcogen there are two buttons for CSHOLD,  you would pick the first button that is just the normal CSHOLD but not the second.  If you do this you should see CSHOLD=0 on the last buffer in each transfer group but CSHOLD=1 on all the other buffers in the TG.

The CSNR field of each transfer group should be different.  So let's say you are using CS[0],CS[1], CS[2], and CS[3] for each slave.  (You can change this to match your board).

Also assume the CS\ are all active low,  so '1' on the CS\ pin means not selected.

You would set CSDEF to 0xFF  so that when the SPI is inactive you have all four CS high.

For the transfer group that is talking to slave on CS[0] you would program it's CSNR to be 0xFE = 11111110b.

For CS[1] you would program CSNR to 0xFD = 11111101b.   For CS[2] -> 0xFB = 11111011b, and for CS[3] = 0xF7 = 11110111b ..   In other words, CSNR is really the 'pattern' you will see across the chip selects during the transfer.

Hi Anthony,

Thank you for looking into my query. Each of my concern is clarified except following. May be i haven't explained it better.

My question is what buffer length should i need to choose for each transfer group as my requirement will be changing as per command that should be sent on SPI. I need to send 3 types of messages each time. vis. 4 bytes, 12 bytes, and 15 bytes.

Q1: How many buffers should i need to choose for each TG for my requirement, assuming i choose 4 TGs for 4 slaves?
Q2: How do i change length dynamically of each buffer since i need to send 3 types of commands each time for a particular slave.
Q3: Following is the way i usually used to send data on MIBSPI

mibspiSetData(mibspiREG1,0,buffer);
mibspiTransfer(mibspiREG1,0);
while(!mibspiIsTransferComplete(mibspiREG1, 0);
mibspiGetData(mibspiREG1,0,p_response);

Here
while(!mibspiIsTransferComplete(mibspiREG1, p_source[i]));

while loop waits till TG0 of MIBSPI1 completes data transfer. so this is what polling i was referring in the above question.
How the check for transfer completed should be done if length is changed dynamically and next TG lengths should not be disturbed because of this change. That too these dynamic change should be minimal such that CPU time won't be wasted.

CPU time of poll for transfer completed is also a bit overhead but this is better for our application than interrupts.

Regards,
Rambabu

Hi,

Can some one please answer my query.

Regards,
Rambabu

Rambabu

Rambabu Pillalamarri said:

Q1: How many buffers should i need to choose for each TG for my requirement, assuming i choose 4 TGs for 4 slaves?

Each transfer group gets 1 buffer.   The buffer length should match the message length.   So first buffer would be 4 bytes, next 12 bytes, and so on.

Change the CSNR field to be appopriate for each slave you are using.

Rambabu Pillalamarri said:

Q2: How do i change length dynamically of each buffer since i need to send 3 types of commands each time for a particular slave.

In this example you wouldn't change the length - you would simply use the TG with the appropriate length already preconfigured.

If you have to change the length within a TG - you can manage this by setting the buffmode to disabled for the individual entries that you are not using.  

Rambabu Pillalamarri said:

Q3: Following is the way i usually used to send data on MIBSPI

If you use more than one transfer group,  you need to make sure that the TG is configured with 'One Shot'.

You will need to software trigger the transfer group each time you want to initiate a transfer.  This is done by setting bit 31 in the TGCTRL register.

If you have a higher priority transfer group say TG0 that is enabled but it's buffers are not 'ready' then it will block a transfer on a lower prority TG say TG1 or TG2 even if they are ready.   This is why you should use one-shot - so that the TG disables itself when complete and doesn't block other TG.

I am not sure if the HalCoGen functions you are using do this - if not you may need to write your own variant of the function to perform correctly for the mode you are using.

-Anthony

Hi Rambabu, did this answer your question?