Thank you all, much appreciated.
As for balancing memory vs computational overhead as part of a workaround, there are other aspects and considerations to it as well of course, including the use case (e.g. are we displaying only some text or graphics or a full screen image?), when to best perform any related computation (e.g. inline in the graphics code when updating a pixel in the primary buffer - often also meaning fewer computations overall as not all pixels on the screen are always drawn - or as an end-of-cycle full screen batch job into a secondary buffer for DMA transfer - where the computational cost is more contained - etc), and so forth. White and black pixels (say e.g. if the background you're drawing onto is black) don't need to be byte swapped either, being all 1's and 0's respectively, though checking specifically for those two colours might not be worth the effort compared to treating all pixels the same. Even more use case specific would be those instances where if you know you're only going to be working with a limited palette of colours in your graphics drawing routines, you could instead pre-swap those few colour values once during initialization/update instead of for every pixel drawn, etc. However, once you add mixed use cases including bitmap images etc to the mix, other considerations including readability and overall keep-it-simple also come into play. Bottom line, the trade-offs of each approach has to be weighed against each other.
All in all, being now aware of the endianness aspects of RP2xxx DMA, I need to revisit some of my code and decide what is most important - computational cost, memory cost, complexity cost, future maintenance cost, etc - and what approach makes the most sense for each subsystem and use case. In any case, I'm of course already seeing major benefits of using DMA for my displays, even with the current "quick fix" approach of a second buffer and byte-swapping computation just before sending it off via DMA - after all, those things are still overall inexpensive compared to the alternative of thousands of regular SPI calls to otherwise update a display. UX-wise it's also a lot snappier, of course.
(As a to-be-confirmed sidenote, by the way, I see indications of other benefits of using DMA for my SPI0 displays, which are managed on core0, in that my SPI1 devices, managed on core1, seem to be contributing less to the overall load of their managing cycle than before, i.e. said cycles seem to be running much faster now than before. Very much FFS of course, but maybe I should ask you whether you're aware of any not-so-obvious dependencies between SPI0 and SPI1 that could indirectly benefit from the use of DMA on either or both of them?)
Thanks again!
BR//Karl
As for balancing memory vs computational overhead as part of a workaround, there are other aspects and considerations to it as well of course, including the use case (e.g. are we displaying only some text or graphics or a full screen image?), when to best perform any related computation (e.g. inline in the graphics code when updating a pixel in the primary buffer - often also meaning fewer computations overall as not all pixels on the screen are always drawn - or as an end-of-cycle full screen batch job into a secondary buffer for DMA transfer - where the computational cost is more contained - etc), and so forth. White and black pixels (say e.g. if the background you're drawing onto is black) don't need to be byte swapped either, being all 1's and 0's respectively, though checking specifically for those two colours might not be worth the effort compared to treating all pixels the same. Even more use case specific would be those instances where if you know you're only going to be working with a limited palette of colours in your graphics drawing routines, you could instead pre-swap those few colour values once during initialization/update instead of for every pixel drawn, etc. However, once you add mixed use cases including bitmap images etc to the mix, other considerations including readability and overall keep-it-simple also come into play. Bottom line, the trade-offs of each approach has to be weighed against each other.
All in all, being now aware of the endianness aspects of RP2xxx DMA, I need to revisit some of my code and decide what is most important - computational cost, memory cost, complexity cost, future maintenance cost, etc - and what approach makes the most sense for each subsystem and use case. In any case, I'm of course already seeing major benefits of using DMA for my displays, even with the current "quick fix" approach of a second buffer and byte-swapping computation just before sending it off via DMA - after all, those things are still overall inexpensive compared to the alternative of thousands of regular SPI calls to otherwise update a display. UX-wise it's also a lot snappier, of course.
(As a to-be-confirmed sidenote, by the way, I see indications of other benefits of using DMA for my SPI0 displays, which are managed on core0, in that my SPI1 devices, managed on core1, seem to be contributing less to the overall load of their managing cycle than before, i.e. said cycles seem to be running much faster now than before. Very much FFS of course, but maybe I should ask you whether you're aware of any not-so-obvious dependencies between SPI0 and SPI1 that could indirectly benefit from the use of DMA on either or both of them?)
Thanks again!
BR//Karl
Statistics: Posted by xoblite — Sun Nov 17, 2024 7:10 pm