Reply by rtstofer June 9, 20132013-06-09
> At this line:
>
> S0SPDR = value;
>
> Are you sure that the compiler issues an 16 bit write to the S0SPDR register?

I used the posted code to communicate with an ADC using 16 bit transfers. It certainly seemed to work. The code was written with Keil uVision4.

Richard

An Engineer's Guide to the LPC2100 Series

Reply by Zdravko June 9, 20132013-06-09
> thank you for your code. I wonder to know if "spi.h" is important in the code that you posted.
> I tested my code with SPI Debugger and found that the LPC2138 only transfers 8 bit data eventhough I set to transfer 12 bit! If your code already work fine with the real device, I think this might the problem with the simulation software. Thank you very much for your help.

At this line:



Are you sure that the compiler issues an 16 bit write to the S0SPDR register?
Reply by rtstofer June 7, 20132013-06-07
> thank you for your code. I wonder to know if "spi.h" is important in the code that you posted.
> I tested my code with SPI Debugger and found that the LPC2138 only transfers 8 bit data eventhough I set to transfer 12 bit! If your code already work fine with the real device, I think this might the problem with the simulation software. Thank you very much for your help.


I NEVER use simulation. It isn't real hardware and my code ultimately has to run on hardware.

spi.h is unimportant, it simply defines the two functions:



Richard
Reply by ntchien2013 June 7, 20132013-06-07
Dear Richard,

thank you for your code. I wonder to know if "spi.h" is important in the code that you posted.
I tested my code with SPI Debugger and found that the LPC2138 only transfers 8 bit data eventhough I set to transfer 12 bit! If your code already work fine with the real device, I think this might the problem with the simulation software. Thank you very much for your help.
Reply by rtstofer June 7, 20132013-06-07
As a side issue, I would be very careful about using:

IODIR0 = 0x400;

This will destroy any previous settings. It will probably become important in larger programs.

Use something like:

IODIR0 |= 0x400;

Richard
Reply by rtstofer June 7, 20132013-06-07
> i did the bit bang program as the following. It works fine. 12 bits, MSB first end there was no need to rise the CS at the last clock signal as the timing diagram in the datasheet of LTC1451. The question, however, is still there! Why it is not possible with SPI protocol of LPC2138. Should I use SSP instead of?

Back to your original code:



I usually use the SSEL pin as GPIO, set it to output and use it for CS' but it's your choice.



Otherwise, your code is similar to mine (for a different project):

Reply by ntchien2013 June 7, 20132013-06-07
Dear all,

i did the bit bang program as the following. It works fine. 12 bits, MSB first end there was no need to rise the CS at the last clock signal as the timing diagram in the datasheet of LTC1451. The question, however, is still there! Why it is not possible with SPI protocol of LPC2138. Should I use SSP instead of?
code:

Reply by ntchien2013 June 7, 20132013-06-07
Dear Richard and Jeff,

thank you for your comments. I will try with GPIO first to see if it works (I did in the real device with National Instrument card and it worked). However, I will try again with this LPC2138.
@Jeff: I just played around with the setting of sending LSB or MSB first, but the results seems to be all the way around with what I set!
Reply by ksdoubleshooter June 6, 20132013-06-06
You've set up the control register to send LSB first. I've looked at the LTC1451 data sheet and SPI mode 0 should work. The only requirement is that the clock should be low when CS is brought low. There is no requirement to raise the CS when the clock is high.

Jeff
Reply by rtstofer June 6, 20132013-06-06
It could be that you are right. However, your code doesn't work so maybe not...

If you actually have to raise the CS' signal during the last clock, as it shows in the diagram, there is no way you can do it with the SPI gadget. The timing diagram is not what I would expect from a true SPI device.

I would put the write operation in a continuous loop and look at it on a scope or logic analyzer.

I would still recommend bit-banging the signals just to see if it worked. I would only take a few minutes to write the loop. I'm pretty sure the LPC2138 is slow enough on GPIO that you won't violate the timing constraints even if you don't use any delays. Or, slow down the peripheral clock for testing purposes.

First you have to get it to work. Then you can try to make it pretty.

Richard