KurtE
Senior Member+
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:
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.
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.
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.