Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 4 FirstFirst ... 2 3 4
Results 76 to 82 of 82

Thread: How best to manage multiple SPI busses?

  1. #76
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,320
    FYI - I fixed an issue with my graphic library above, that did not work when I did an Async update screen... Forgot to put in begin/end transaction... Now in and zip file above was updated...

    Side Notes:
    Test program above can test this, by: entering in debug terminal: d<cr>
    Which toggles on DMA testing mode. So when you hit just <CR> for a line it toggles between drawing with or without frame buffer. Background is red in FB mode. In DMA mode when it draws RED it is using the ASYNC update...

    Also tests continuous screen updates: r<cr>
    Which checks frame counts and when it does 10 frame updates it changes colors... Which also worked.

    However: this code knows that the T3.6 DMA can only output 32K at a time, so it manually did it in three chunks.

    Would like to now have that done internal to the SPI.transfer(buf, retbuf, cnt, CallBack) function... As to not have to have the program know these constraints, especially since on T3.5 SPI1/2, current constraint is 512 bytes (9 bits for count as other bits are used for channel link)...

    Question to myself and others who have played with DMA...

    Currently I am using the DMAChannel.h functions like: _dmaTX->sourceBuffer(buf, cnt);

    Which work, when they complete they reset the SADDR in the channel back to where it started as the set: SLAST= -LEN...
    Likewise for use destinationBuffer...

    So Suppose I wish for the Transfer to output the full 76880 UINT16's which would take 3 writes (2.34..), Should I in the DMA RX ISR:

    a) Keep the counts and pointers separate in my SPI structure and do all the math to figure out the next starting points and bytes/words left...

    b) In the ISR simply update the SADR and DADR values by adding SLAST to these values....

    c) Or would it work to manually set the SLAST=0, so when each DMA is completed in theory it is already pointing to the start of the next transfer?

    It feels like b) or c) would be the cleanest, c) would would probably be slightly faster for turn around, but b) would be very very slightly faster for transfers that can complete in one chunk (majority)...

    Sounds like time to experiment.

  2. #77
    Senior Member
    Join Date
    Jan 2013
    Posts
    687
    Quote Originally Posted by KurtE View Post
    b) In the ISR simply update the SADR and DADR values by adding SLAST to these values....
    You mean subtract, SLAST is negative ('-len').

    c) Or would it work to manually set the SLAST=0, so when each DMA is completed in theory it is already pointing to the start of the next transfer?

    It feels like b) or c) would be the cleanest, c) would would probably be slightly faster for turn around, but b) would be very very slightly faster for transfers that can complete in one chunk (majority)...
    I vote for c).

    I don't see why b) would be faster. You can always access the TCD directly for stuff that's not supported.

  3. #78
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,320
    b) would be faster as I would not have to set SLAST=0.... Of course I could roll my own sourceBuffer/destBuffer functions which did that, in which case speed is a wash...

    I am leaning toward c) as well.

    Right now busy doing OK weather outside tasks.

  4. #79
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,320
    I just updated the SPI to use c) So far I have only tested using the display driver above. So far it is working where I now simply issue the full transfer
    of all of the bytes: _spi->transfer16(_pfbtft, NULL, _width*_height, asyncInterrupt);

    And the transfer takes care of doing the splitting. Again so far only tested on SPI on T3.6.

    I need to now go back and retest T3.5... May want to see how the SSD1306 is working. As I have not retested it with the updated chained DMAChannels that are now used and as such 511 bytes is max transfer and was outputting 512, so, will need to use this new code to recover...

  5. #80
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,320
    @admp - Not sure what you you responding to here?

    Quick update: My first version to allow transfer size > then one DMA request worked on T3.6, but not on T3.5 SPI1/2...

    So needed to rework and do like first transfer and spoon feed the first item with PUSHR. Now appears to work for the different busses.

  6. #81
    Senior Member mortonkopf's Avatar
    Join Date
    Apr 2013
    Location
    London, uk
    Posts
    748
    @admp - are you real. Your post is scraped content from here:http://www.microchip.com/forums/m660098.aspx

  7. #82
    Junior Member
    Join Date
    Oct 2012
    Posts
    12
    I am playing along big time. I have been using the library with spin and the clip buffer.
    Just saw the second branch on your spi github that mentioned this update.
    Glad i found it here.
    This is dynamite stuff. Thanks for all the hard work mate.
    I will load it up and let you know how it goes.
    Perfect timing for me as i am just pinning down franks flexibard 3 and will be wanting the extra spi for offboard.
    Will be available for a bit of testing.
    Hope this has been picked up upstream.
    Love your work!
    Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •