Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

T4 dma low - Issues of trying to do DMA on T4 if object created in heap #3

Merged
merged 6 commits into from Oct 4, 2019

Conversation

@KurtE
Copy link
Contributor

commented Aug 24, 2019

Paul,

This is a couple of different things.

Probably the most important is that some of the key member variables are initialized. Did not show up with test sketches as if you do the normal like

ST7735_t3 tft = ST7735(cs, dc, rst);

As the memory in the DTCM for variables is either initialized or zeroed and so it worked fine. However uncanny eyes instead does something like:

ST7735_t3 *my_tft = new ST7735(cs, dc, rst);

So the object is created up on the heap and not initialized. This caused issues. Like the logical pointer to frame buffer was not nullptr so code assumed it was active and stored data off of this random pointer...

In addition to this. When doing DMA stuff, I could not get the code to work if the DMA structures where stored up in the OCRAM(heap). Things like DMAChannel and DMASettings. Also code currently copies portions of the Frame buffer to smaller sections that I can make sure the memory has the right values (Memory vs Cache values)... So have the class allocate space for DMA info for 3 objects (as there are 3 SPI busses)...

Would prefer to have system function to try to allocate lower memory instead as some form of system function, but this should work until then.

KurtE added 4 commits Aug 15, 2019
So instead try to allocate some static data, for the DMA outputs and move to lower memory, which does not have the cache issue.
The one constructor may not have initialized a few important variables, which in normal cases, did not matter as NULL was the valid vaue and if the variable was in DTCM it was zero.  But if created by NEW it might have garbage...

Also sort of hack for setAddrWindow/pushColor where it does not do endTransaction stuff...
As a GP, I put in some more init stuff, to try to make sure more of the object is initialized, if by chance someone does a new of the object.
Fix Crash if doing SPI  without using Hardware SPI...
I.e. bit bang
@KurtE KurtE force-pushed the KurtE:T4_DMA_LOW branch from 11c8661 to e44f9b9 Sep 18, 2019
KurtE added 2 commits Sep 18, 2019
Before if DC pin was NOT a hardware CS pin, the whole thing downgraded to using Software bitbang output...

In this version we detect this and if the main  MOSI/SCK, then setup for the actual SPI buss.  So _pspi->beginTransaction works, likewise we use _pspi->transfer instead of bitbang, plus now added function to also use _pspi->transfer16 if we are trying to output 16 bit values, like colors.
Issue with DMASettings on T3.6 when they are part of the main class object.  The constructor does not appear to be called to properly initialize them.  So created static member array, which wastes some memory as I create enough for 3 instances (one per buss)

Tested with three displays connected running DMA updates.
KurtE pushed a commit to KurtE/ST7735_t3 that referenced this pull request Sep 20, 2019
T3.6 did not work with DMASettings in object
@PaulStoffregen PaulStoffregen merged commit 6e458d9 into PaulStoffregen:master Oct 4, 2019
@KurtE KurtE deleted the KurtE:T4_DMA_LOW branch Oct 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.