SPI driver for KINETIS K20.

[Giovanni]

You are going really fast

I recommend organizing things in order to share the code among the various subfamilies or you have a lot of rework ahead, talking because experience...

Giovanni

[utzig]

My plan was to finish I2C and then write SPI drivers but since Derek wrote it already, my next step will be to cleanup and merge families. I think that after cleaning up it will also be quite easier to add new sub-families. And after that "harder" drivers can be written like ethernet K6x, K7x and USB (which most have).

Cheers,
Fabio Utzig

[SpaceCoaster]

The EXT driver should be cross compatible between KINETIS series chips but not the SPI driver judging by the register changes required.

[utzig]

Yep, the SPI on KL2x is very different (and it's called DSPI on the K2x...). Don't know about other families. Btw, I applied all patches (all looked very good). Only did little changes to the header file (mk20d5.h). Please check that I didn't break anything.

Fabio Utzig

[SpaceCoaster]

A couple of issues

When I build RT-MCHCK-K20-SPI I get

Code: Select all

main.c: In function 'main':
main.c:103:3: warning: implicit declaration of function '_pal_lld_setpadmode' [-Wimplicit-function-declaration]
   palSetPadMode(GPIOC, 5, PAL_MODE_ALTERNATIVE_2);  /* SCK  */

I think it needs an extern in pal_lld.h for _pal_lld_setpadmode.

Also the ch.bin doesn't have the KINETIS flash protection bits at 0x400. It just has random data!

I think this is because I set USE_LTO to yes. Too much optimization. With it set to no I get the protection bits and it works.

Cheers,
Derek

[Giovanni]

Look for a missing KEEP in the scatter file.

Giovanni

[colin]

Yeah the DSPI peripheral is an odd beast. It is on the Freescale ColdFire MCUs and also Kinetis K series but not Kinetis L. It is the DMA SPI device, which most importantly takes data 16-bits at a time. MSB is the control byte, like start or end transfer, which slave to select, etc., and LSB is the data.

It is powerful because you can queue up multiple transfers to multiple slaves etc. using just DMA with no core intervention between transfers.

It is clumsy because you can't just point the DMA at a buffer of data and send it ... you need to copy/expand it in a buffer to 16-bits wide.

The Kinetis L's SPI peripheral is perhaps less powerful in a way, but I think would ironically be more convenient for DMA implementation?

[Giovanni]

You may look at the DSPI driver in the SPC5 port, it supports both IRQ and DMA modes, not sure if it is exactly the same version of DSPI but it is the same peripheral from Freescale.

Anyway, it is really an odd beast...

[fpga_comp]

There is a DMA SPI library for the Teensy 3.X (K20) here: https://github.com/crteensy/DmaSpi (actual code is in the DmaSpi.h header file!)
Hope that would be useful here.

As far as I can remember from the forum discussion that started that, they basically use 8-bit DMA write to the TXDATA FIFO.
http://forum.pjrc.com/threads/23253-tee ... A-nice-try

The upper control words are defaulted to all 0's. None of the fancy hardware SPI chip select stuff can be used. Those are handled in software for asserting/deasserting GPIO pins. You wouldn't care too much about that if you are doing big block of SPI transfer to a single device. You only need to toggle the chip select before and after the DMA.

[SpaceCoaster]

Earlier in this thread I noticed that

OK, everything looks better if the lines.

Code: Select all

__main_stack_size__     = 0x0400;
__process_stack_size__  = 0x0400;


are taken out of KL25Z128.ld and MK20DX128.ld

The attached patch removes the stack size definitions from the *.ld files and allows the rules.mk feature to work as intended.