SPI DMA new functions

EDIT:
The new functions are integrated in the latest update of Roger’s repo.
Check the .h file for a short explanation of the parameters and what they do, right before each of the functions.

**************************************************************

Roger,

I am opening a thread for this as we haven’t discussed it since you opened the new forums.

I just went back to the ILI 9163C library that I had ported, and gave a quick thought to the DMA functions, and just made a small change to allow to select Memory Increment or Circular mode with an optional parameter.

The function declarations look like this:
/**
* @brief Sets up a DMA Transfer for "length" bytes.
*
* This function transmits and receives to buffers.
*
* @param transmitBuf buffer Bytes to transmit. If passed as 0, it sends FF repeatedly for "length" bytes
* @param receiveBuf buffer Bytes to save received data.
* @param length Number of bytes in buffer to transmit.
*/
uint8 dmaTransfer(uint8 *transmitBuf, uint8 *receiveBuf, uint16 length);

/**
* @brief Sets up a DMA Transmit for bytes.
*
* This function transmits and does not care about the RX fifo.
*
* @param transmitBuf buffer Bytes to transmit,
* @param length Number of bytes in buffer to transmit.
* @param minc Set to use Memory Increment mode, clear to use Circular mode.
*/
uint8 dmaSend(uint8 *transmitBuf, uint16 length, bool minc));

/**
* @brief Sets up a DMA Transmit for half words.
* SPI PERFIPHERAL MUST BE SET TO 16 BIT MODE BEFORE
*
* This function transmits and does not care about the RX fifo.
*
* @param data buffer half words to transmit,
* @param length Number of bytes in buffer to transmit.
* @param minc Set to use Memory Increment mode (default if blank), clear to use Circular mode.
*/
uint8 dmaSend(uint16 *transmitBuf, uint16 length, bool minc);

Victor,

Sounds good.

I wonder if one or two other people could test it before I copy it into the repo?

Thanks

Roger

RogerClark wrote:Victor,

Sounds good.

I wonder if one or two other people could test it before I copy it into the repo?

Thanks

Roger

That pigoscope is so cool!

Now on the SPI DMA Subject:

Roger, the spi_dev struct has this content:
typedef struct spi_dev {
203 typedef struct spi_dev {
204 spi_reg_map *regs; /**< Register map */
205 rcc_clk_id clk_id; /**< RCC clock information */
206 nvic_irq_num irq_num; /**< NVIC interrupt number */
207 } spi_dev;

Victor

Do we need 3 things not 2, I thought we need the DMA device and also the channel numbers. (I’m not sure about the nomenclature but I think you will know what I mean)

Roger, I know what you mean, the DMA controller and the channel number.
I think you are right.
I’ll need to check, I know the CB mcu has only 1 controller, but the R, V and Z may have two, so we would need to know that too.
As there is only a few SPI devices, that should only take a 6 or 9 bytes from RAM, which we should be able to leave with. Specially since spi2 or spi3 are not instantiated by default.

Hi Victor

Yes. Thats the thing I mean

Actually, given the controller, I think its actually possible to work out the channels, I recall there is some code that checks this (sorry I forget where it is)

But when I saw it, I wondered why that the check wasn’t done in reverse. However it could be one of these things where there are more than one possible option

In dma_f1.c it has a function called preconfig_check which calls a whole series of sub functions

So when I didnt know what channel to use for a device, I just ended up looking in that code to work out what was a valid channel number

But I guess this is something for the future and just to get it going we should include the DMA controller and also the TX and RX channels in the struct

I don’t think a few more bytes of ram used, are going to make any difference

@Victor – where do I find your updated libs?

I am having some problems with github resynchronizing with Roger’s repo, once I get it all sorted out I will send him a pull for the relevant files.
In the meanwhile my fork has the latest modifications I have done to graphic libraries and the SPI functions:
https://github.com/victorpv/Arduino_STM32

It also includes FreeRTOS 8.2.1. and CoOS 1.1.6 and 1.12(oldest version) which seem to work fine. There is one example that uses an ILI9163 display, but can be adapted to any other display very easily.
Could be something useful to manage multiple tasks in the oscilloscope project.

@ahull: I’m sure they are on Victors github account:
https://github.com/victorpv/Arduino_STM32
edit: ok, victor was faster

Pull them better from https://github.com/victorpv/STM32F1_Modified
I am trying to resync my other repo with Roger and only upload tested stuff for pulls, while making changes in the _Modified one.

Getting lots of warnings on the use of deprecated calls in SPI.c My project is using the Ethernet_STM lib, which uses the SPI lib which in turn uses DMA lib. The DMA library has declared a number of calls as deprecated, so the SPI calls need to be updated.

If I knew how to do this, I would gladly volunteer, but knowing ones limitations is a virtue in this case. DMA is a bit of a mystery to me (I do know what the letters mean). I see in SPI.h that getting rid of the deprecated calls is on someones to do list.. Don’t suppose it will be anytime soon ?

can you post your compile verbose output showing what is deprecated

I am aware of these messages, I tried to replace the deprecated functions, but that involves more code/RAM size and longer runtime.
As the DMA setup within SPI send/transfer functions should be fast (which is the case at the moment), I rather tend to remove the “deprecated” keyword from the sources so that the compiler does not warn anymore.
What do you think, Roger? Would it make sense?

I’m with Steve on this one.
I often just use #pragma … to shut up the noise. There is a full list ofGCC Pragma settings that can be enabled in source code.

This one should disable depreciated warnings:
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"

In this case this line should be removed/commented out.

Thanks Steve. I’ve done as you suggested.