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);
Sounds good.
I wonder if one or two other people could test it before I copy it into the repo?
Thanks
Roger
Sounds good.
I wonder if one or two other people could test it before I copy it into the repo?
Thanks
Roger
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;
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)
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.
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
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.
https://github.com/victorpv/Arduino_STM32
edit: ok, victor was faster

I am trying to resync my other repo with Roger and only upload tested stuff for pulls, while making changes in the _Modified one.
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 ?
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 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"