Need to program my own (extra) SSP interface for the LPC1768

[lpcware]

Content originally posted in LPCWare by OrbiHans on Tue May 13 01:00:15 MST 2014
Hi all,

Well, have anyone here tried to program their own SSP interface for a LPC1768. I allready use both the internal SSP0 and SSP1, but I need total 3 interfaces, therefore I need to manually program a new extra SSP driver using the existing GPIO port pin.

Can anyone here help me to program my own SSP interface?. Some examples?

Thanks

[lpcware]

Content originally posted in LPCWare by OrbiHans on Tue May 20 04:46:32 MST 2014
Thanks for your help.

Well, the SRAM is basically used for a blackbox function ( updated every 50 ms ) and some system counters etc, and the SD card is used to store all the blackbox data after a given event in a file system (fat). So the blackbox is updated every 50 ms, and when we have an error event, we save all the data collected in the blackbox( SRAM ) to the SD card.

So normally the system are just saving data to the blackbox (SRAM) every 50 ms and some slowly asynchronous system counter updates, and when we got an error event, we need to read all data from the blackbox (SRAM) and write the data to the SD card.
So mostly of the time we writes data to the SRAM, and very rare we need to move a large data amount from the SRAM to the SD card.

It is acceptable that we stop all the blackbox saving function ( 50 ms ) during the saving process to the SD card, no problem.

I have created two tasks, Task_Blackbox and Task_SDcard, where the Task_Blackbox takes care of saving data to the blackbox every 50 ms, and the Task_SDcard manages the entire SD card control including the file system.

I’ll go on designing the system to use the mutex solution, and then switch between the SRAM and SD card on the SSP0 interface.

[lpcware]

Content originally posted in LPCWare by leluno on Mon May 19 23:31:02 MST 2014
easyest way will be, solder a new sd-card holder on the ssp1-pins.

[lpcware]

Content originally posted in LPCWare by rocketdawg on Mon May 19 09:49:03 MST 2014
the mutex may work.  Depends.
How critical is the 50ms period?  what if it is 60 or 70ms?
How critical is it that it the SRAM Read/Write is performed every 50ms?
if SDCard driver takes mutex and the SDCard write duration is over 50ms then SRAM is blocked until SDCard is finished.
SRAM Read/Write should be very fast, so it has the higher priority thread, but it might get blocked by SDCard.

so wrap a task/thread around the code that access the SRAM and another task/tread around the SDCard code.
I assume some timer fires every 50ms, that sets an event, that wakes up the SRAM thread to perform it duty.
So I would hook up a logic analyzer or scope to an unused pin or two and toggle that pin to measure the duration of SRAM and SDCard tasks
that will give you an idea if timing can be maintained.

another possibility is that one thread controls both the SRAM and SDCard access.  The timer can set the event that wakes the thread, or another thread can set another event that wakes the thread to do SDCard access.  If the thread is currently accessing SDCard and the timer event occurs, you might be able to suspend the SDCard access, write SRAM, and resume SDCard access.

lots of possibilities.

the PWM idea may very well work, never thought about that option.

[lpcware]

Content originally posted in LPCWare by OrbiHans on Mon May 19 03:03:11 MST 2014
Thanks for your reply and help.
Well, to clarify my problem. Unfortunately the hardware developer have placed the serial SRAM and SD card “on the same” SSP0 interface in a FreeRtos based system environment.

Then we have the possibility to simply switch between the SRAM and SDcard (slaves) or make a custom SPI driver specific for the SDcard. ( We use DMA on the SRAM and like to keep the SRAM on the fast SSP0 ). The SDcard is not interfaced so often.

Guess it’s not so complicated to switch between the SRAM and SDcard and initialize them separately, the only thing that worries me is the FreeRtos system. The SRAM is called periodically ( 50 ms ) and the SDcard is not so often called, therefore I need to control the sharing by a mutex or something like that, to manages the permission of the SSP0 interface and avoid any crash!. I need a mutex function to control the permission of the SSP0 interface.
I have to prevent that only one task have taken the SSP0 interface for use.

Maybe you can assist me here, if some of you have worked with shared SSP0 interface in FreeRtos environment.

Right now I’m examine the possibility to make a custom SPI driver where I use a PWM output to generate a SPI clock signal, and then manages the data bit banging in the belonging PWM interrupt routine to avoid the spin-in-place delays. What do you guys think about that?.

Looking forward to hear from you.
Thanks.

[lpcware]

Content originally posted in LPCWare by rocketdawg on Fri May 16 08:44:40 MST 2014
No you don't.  You have several seriously powerful DMA capable SPI peripheral capable of controlling multiple slaves.  One needs individual Chip Selects for each slave and you might have to change clock/modes between slaves devices, but that will be a lot faster than bit banging.  Serious old school crap.
I seriously doubt that all your current SSP are running flat out.  Didn't they teach you to share in school  :bigsmile:
I have one SPI bus that has 4 slaves.

but if you must, what you want is
http://en.wikipedia.org/wiki/Bit_banging
and you will need 4 pins, CLK, MISO, MOSI, CS
and it will consume a load of CPU time since you will have to have spin-in-place delays to match clock, data, and correct mode.  Or use a timer ISR driven state machine, still serious overhead.

[lpcware]

Content originally posted in LPCWare by leluno on Fri May 16 07:54:11 MST 2014
for it is hardware, you have to work very carefuly when connecting the gpios to the  ssp -shurely impossible. you can easyly make a software spi with each gpio you want. but that is not "ssp". it works much slower then ssp but it will work.

[lpcware]

Content originally posted in LPCWare by OrbiHans on Tue May 13 04:02:55 MST 2014
Well, I guess you mean SSP0, SSP1 and SPI.

Anyway, I can't and I'm not going to use the SSP0, SSP1 or the SPI, but I simply want to implement my own custom made SSP driver  using some of the existing GPIO left in my hardware application.

Have anyone here made their own custom made SSPx driver?
I simply want to make my own independent SSP driver, I can use on every given GPIO available left.

Thanks

[lpcware]

Content originally posted in LPCWare by leluno on Tue May 13 02:50:23 MST 2014
there are  three SSP-interfaces on lpc1768: SSP0-0, SSP0-1, SSP1.

I have an sd-card and a spi-lcd at the same interface. That is no problem. Therefore you can use the Cipselect-pin.

[lpcware]

Content originally posted in LPCWare by OrbiHans on Tue May 13 02:31:23 MST 2014
leluno

Well, the problem is that I allready uses all the SSP0 and SSP1 and therefore want to program my own software based SSP2 on a given GPIO section. If I chose to use the SPI I must use some allocated GPIO defined for the SPI.

I simply want to implement my own SPI2 driver, using the GPIO pin I want/need to use.

Thanks

[lpcware]

Content originally posted in LPCWare by leluno on Tue May 13 01:52:34 MST 2014
That will not work because ssp is hardware.

SSP0 has two possibilitys to connect pins:

__set_PINSEL(1, 20, 3); // Attach SCK0 to I/O pad
__set_PINSEL(1, 23, 3); // Attach MISO0 to I/O pad
__set_PINSEL(1, 24, 3); // Attach MOSI0 to I/O pad
pinSEL(0,15,2);//0.15-4:ck
pinSEL(0,17,2);//0.17-4:miso
pinSEL(0,18,2);//0.18-4:mosi


easier is it to use SSP0, SSP1 and SPI:

pinSEL(0,15,3);//0.15-4:ck
pinSEL(0,17,3);//0.17-4:miso
pinSEL(0,18,3);//0.18-4:mosi