<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: K64 as SPI master with DMA, TX only, don't need RX in Kinetis Microcontrollers</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1242778#M59841</link>
    <description>&lt;P&gt;Hey&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/106476"&gt;@gerhardheinzel&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm doing exactly what you are trying to do with an OLED controlled by an SSD1322.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I started with the dspi_edma_b2b_transfer code and focused on the transmission (master) side of things (which ignores the receive and does not require an SIN pin or receive buffer).&amp;nbsp; When I specify the Kinetis pins using the Mux, I ignore the SIN pin (and actually use it for something else).&amp;nbsp; Going further, I updated the transmission callback so that after the block of data (I chose 510 bytes as a maximum) had been transmitted if there was more data to send, I would restart the transmission for the next block of data until it was all done.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;[EDIT: Added SPI Code]&lt;/P&gt;&lt;P&gt;I've attached my SPI code to this post - looking at it again, the "OLEDSPIProcs.c/.h" are not all that receiving device specific (when I wrote the post originally, I thought they were).&amp;nbsp;&lt;/P&gt;&lt;P&gt;To setup the port, called the unfortunately named "OLEDSPIInt" method to initialize the port.&amp;nbsp; I specify the pins/mux in the MCUXpresso Pin Wizard.&amp;nbsp; &amp;nbsp;At the end of the method, you'll see a couple of pin writes which are specific to the SD1322 (which probably should be moved outside the method to make it more generic.&amp;nbsp; You'll have to check your clocks as well but if you look at my code as well as the SDK example(s) you shouldn't have any issues getting it working.&amp;nbsp;&lt;/P&gt;&lt;P&gt;With the SPI port initialized, you can send data through the SPI port by calling "OLEDSPI_BulkTransfer" after setting up the variables.&amp;nbsp; You must send at least two bytes (tthere is no maximum) so if you have a single byte transfer, you will need to start off with a byte that the receiver will ignore.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I recommend calling OLEDSPI_BulkTransfer using something like:&lt;/P&gt;&lt;PRE&gt;  for (; !oledSPITransferCompleted;) { }&lt;BR /&gt;  oledSPITransferCompleted = FALSE;&lt;BR /&gt;&lt;BR /&gt;  oledSPIXfer.txData = oledSPICmdBuffer;&lt;BR /&gt;  for (i = 0, oledSPIXfer.daaSize = numberofBytes; numberOfBytes &amp;gt; i; ++i) {&lt;BR /&gt;    oledSPICmdBuffer[i] = sourceData[i];&lt;BR /&gt;  }&lt;BR /&gt;&lt;BR /&gt;  OLEDSPI_BulkTransfer();&lt;BR /&gt;&lt;BR /&gt;//  Note the start which waits for the previous transfer to complete before starting the next one&lt;/PRE&gt;&lt;P&gt;I should also point out that EDMA needs at least two transfers - if you're going to send one, find a byte that the receiver will ignore with the second one being the required one to send.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Looking over the code, it could be written better (and used some better method names), but I was doing a lot of experimenting trying to get things working right (and fast).&amp;nbsp;&amp;nbsp;I can say that the code is rock solid running at 10Mbps.&amp;nbsp; It was written for FreeRTOS, but the assumption was that display updates had to happen as fast as possible which is why I do not put in a delay (to force a task swap) when sending multiple instructions to the display.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm happy to answer some questions, but please understand that I'm not in a position nor do I have the time to support you or modify the code for your application.&amp;nbsp;&lt;/P&gt;&lt;P&gt;As a suggestion, you may want to first get byte sends working first, to ensure you understand the operation of your peripheral, before blasting data at it using the SPI.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Goodl luck!&lt;/P&gt;&lt;P&gt;myke&lt;/P&gt;</description>
    <pubDate>Wed, 10 Mar 2021 03:21:36 GMT</pubDate>
    <dc:creator>myke_predko</dc:creator>
    <dc:date>2021-03-10T03:21:36Z</dc:date>
    <item>
      <title>K64 as SPI master with DMA, TX only, don't need RX</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1242690#M59840</link>
      <description>&lt;P&gt;Hi, I want to use K64 to send lots of data to a display with SPI. It works using polling but is too slow, and moreover the CPU also has other stuff to do. So I want to use DMA instead, using large buffers (~kbytes) at a time. However, the example provided in sdk/boards/frdmk64f/driver_examples/dspi/edma_transfer activates DMA for both TX and RX directions. But I don't want any activity for RX since no useful data is coming in. So I want to avoid the overhead of assigning an RX buffer that I don't need and any DMA activity associated with RX, but instead simply ignore RX. How can I achieve that?&lt;/P&gt;&lt;P&gt;Many thanks,&lt;/P&gt;&lt;P&gt;Gerhard&lt;/P&gt;</description>
      <pubDate>Tue, 09 Mar 2021 17:54:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1242690#M59840</guid>
      <dc:creator>gerhardheinzel</dc:creator>
      <dc:date>2021-03-09T17:54:35Z</dc:date>
    </item>
    <item>
      <title>Re: K64 as SPI master with DMA, TX only, don't need RX</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1242778#M59841</link>
      <description>&lt;P&gt;Hey&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/106476"&gt;@gerhardheinzel&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm doing exactly what you are trying to do with an OLED controlled by an SSD1322.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I started with the dspi_edma_b2b_transfer code and focused on the transmission (master) side of things (which ignores the receive and does not require an SIN pin or receive buffer).&amp;nbsp; When I specify the Kinetis pins using the Mux, I ignore the SIN pin (and actually use it for something else).&amp;nbsp; Going further, I updated the transmission callback so that after the block of data (I chose 510 bytes as a maximum) had been transmitted if there was more data to send, I would restart the transmission for the next block of data until it was all done.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;[EDIT: Added SPI Code]&lt;/P&gt;&lt;P&gt;I've attached my SPI code to this post - looking at it again, the "OLEDSPIProcs.c/.h" are not all that receiving device specific (when I wrote the post originally, I thought they were).&amp;nbsp;&lt;/P&gt;&lt;P&gt;To setup the port, called the unfortunately named "OLEDSPIInt" method to initialize the port.&amp;nbsp; I specify the pins/mux in the MCUXpresso Pin Wizard.&amp;nbsp; &amp;nbsp;At the end of the method, you'll see a couple of pin writes which are specific to the SD1322 (which probably should be moved outside the method to make it more generic.&amp;nbsp; You'll have to check your clocks as well but if you look at my code as well as the SDK example(s) you shouldn't have any issues getting it working.&amp;nbsp;&lt;/P&gt;&lt;P&gt;With the SPI port initialized, you can send data through the SPI port by calling "OLEDSPI_BulkTransfer" after setting up the variables.&amp;nbsp; You must send at least two bytes (tthere is no maximum) so if you have a single byte transfer, you will need to start off with a byte that the receiver will ignore.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I recommend calling OLEDSPI_BulkTransfer using something like:&lt;/P&gt;&lt;PRE&gt;  for (; !oledSPITransferCompleted;) { }&lt;BR /&gt;  oledSPITransferCompleted = FALSE;&lt;BR /&gt;&lt;BR /&gt;  oledSPIXfer.txData = oledSPICmdBuffer;&lt;BR /&gt;  for (i = 0, oledSPIXfer.daaSize = numberofBytes; numberOfBytes &amp;gt; i; ++i) {&lt;BR /&gt;    oledSPICmdBuffer[i] = sourceData[i];&lt;BR /&gt;  }&lt;BR /&gt;&lt;BR /&gt;  OLEDSPI_BulkTransfer();&lt;BR /&gt;&lt;BR /&gt;//  Note the start which waits for the previous transfer to complete before starting the next one&lt;/PRE&gt;&lt;P&gt;I should also point out that EDMA needs at least two transfers - if you're going to send one, find a byte that the receiver will ignore with the second one being the required one to send.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Looking over the code, it could be written better (and used some better method names), but I was doing a lot of experimenting trying to get things working right (and fast).&amp;nbsp;&amp;nbsp;I can say that the code is rock solid running at 10Mbps.&amp;nbsp; It was written for FreeRTOS, but the assumption was that display updates had to happen as fast as possible which is why I do not put in a delay (to force a task swap) when sending multiple instructions to the display.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm happy to answer some questions, but please understand that I'm not in a position nor do I have the time to support you or modify the code for your application.&amp;nbsp;&lt;/P&gt;&lt;P&gt;As a suggestion, you may want to first get byte sends working first, to ensure you understand the operation of your peripheral, before blasting data at it using the SPI.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Goodl luck!&lt;/P&gt;&lt;P&gt;myke&lt;/P&gt;</description>
      <pubDate>Wed, 10 Mar 2021 03:21:36 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1242778#M59841</guid>
      <dc:creator>myke_predko</dc:creator>
      <dc:date>2021-03-10T03:21:36Z</dc:date>
    </item>
    <item>
      <title>Re: K64 as SPI master with DMA, TX only, don't need RX</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1243295#M59847</link>
      <description>&lt;P&gt;Dear &lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/58763"&gt;@myke_predko&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Many thanks! That is exactly what I was looking for. My device is of course different (ILI9341) but I already succeed in talking to it with the slow SPI methods, so the DMA init part what what as I was lacking.&lt;/P&gt;&lt;P&gt;Cheers,&lt;/P&gt;&lt;P&gt;Gerhard&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 10 Mar 2021 13:20:36 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1243295#M59847</guid>
      <dc:creator>gerhardheinzel</dc:creator>
      <dc:date>2021-03-10T13:20:36Z</dc:date>
    </item>
    <item>
      <title>Re: K64 as SPI master with DMA, TX only, don't need RX</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1243358#M59849</link>
      <description>&lt;P&gt;Dear&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/58763"&gt;@myke_predko&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;after looking at your code (from which I threw out things that I don't need) I am still confused.&lt;/P&gt;&lt;P&gt;Even though I believe that both of us do neither need not want any DMA activity for the RX direction,&lt;BR /&gt;there is still code referring to RX like&lt;/P&gt;&lt;P&gt;#define LCD_SPI_DMA_RX_REQUEST_SOURCE kDmaRequestMux0SPI1&lt;/P&gt;&lt;P&gt;DMAMUX_SetSource (LCD_SPI_DMA_MUX_BASEADDR, masterRxChannel, LCD_SPI_DMA_RX_REQUEST_SOURCE);&lt;BR /&gt;DMAMUX_EnableChannel (LCD_SPI_DMA_MUX_BASEADDR, masterRxChannel);&lt;BR /&gt;...&lt;BR /&gt;EDMA_CreateHandle (&amp;amp;oledDSPIEdmaMasterRxRegToRxDataHandle, LCD_SPI_DMA_BASEADDR, masterRxChannel);&lt;/P&gt;&lt;P&gt;-------------&lt;/P&gt;&lt;P&gt;The only places where I could guess the RX DMA is de-activated are the three NULL pointers in the following:&lt;/P&gt;&lt;P&gt;dspi_transfer_t oledSPIXfer = {.rxData = NULL, .configFlags = kDSPI_MasterCtar0 | kDSPI_MasterPcs0 | kDSPI_MasterPcsContinuous};&lt;/P&gt;&lt;P&gt;dspi_transfer_t actualOLEDSPIXfer = {.rxData = NULL,.configFlags = kDSPI_MasterCtar0 | kDSPI_MasterPcs0 | kDSPI_MasterPcsContinuous};&lt;/P&gt;&lt;P&gt;DSPI_MasterTransferCreateHandleEDMA (LCD_SPI_BASEADDR, &amp;amp;oledDSPIEDMAMasterHandle, OLEDDSPI_MasterEDMACallback, NULL, &amp;amp;oledDSPIEdmaMasterRxRegToRxDataHandle, &amp;amp;oledDSPIEdmaMasterTxDataToIntermediaryHandle, &amp;amp;oledDSPIEdmaMasterIntermediaryToTxRegHandle);&lt;/P&gt;&lt;P&gt;Is that the trick?&lt;/P&gt;&lt;P&gt;With best greetings&lt;BR /&gt;Gerhard&lt;/P&gt;</description>
      <pubDate>Wed, 10 Mar 2021 14:59:15 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1243358#M59849</guid>
      <dc:creator>gerhardheinzel</dc:creator>
      <dc:date>2021-03-10T14:59:15Z</dc:date>
    </item>
    <item>
      <title>Re: K64 as SPI master with DMA, TX only, don't need RX</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1243383#M59850</link>
      <description>&lt;P&gt;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/106476"&gt;@gerhardheinzel&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;That's the trick.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The issue isn't that we don't want SPI RX - SPI will always receive data when it's working (ie transmitting) - we just don't want to store the incoming data.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;myke&lt;/P&gt;</description>
      <pubDate>Wed, 10 Mar 2021 15:42:39 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/K64-as-SPI-master-with-DMA-TX-only-don-t-need-RX/m-p/1243383#M59850</guid>
      <dc:creator>myke_predko</dc:creator>
      <dc:date>2021-03-10T15:42:39Z</dc:date>
    </item>
  </channel>
</rss>

