Teensy 3.2 SSD1351 issue

[pix-os]

hi all, sorry i have been off for a while, been rather busy.

i have a question/issue:

when i use legacy SPI on my teensy 3.2 to drive a SSD1351 oled screen, it works

but when i try to implement a DMA based solution, it fails.

is it that the SSD1351 doesn't like DMA or is it my code that doesn't work? (i hope it's the second, although i couldn't find a issue)

the zip files containing every bit of code i have is in the zip files (SSD1351.zip works, the SSD1351_dma.zip doesn't)

View attachment ssd1351.zip

View attachment ssd1351_dma.zip

the oled with breakout board i'm using is: www.ebay.com/itm/160897462664

anyone knows what's wrong? :S

 

[macaba]

I've just had a quick look through - I think you're nearly there. You appear to be pushing values into the SPI FIFO rather than any sort of DMA (that's fine, it should speed things up still).

What I couldn't see anywhere and may be part of the problem - where is the DC line being set LOW for commands and HIGH for data within the setAddrWindow_cont method (and subsequently writecommand_cont and writedata16_cont)? Also, I think you might be sending 4 bytes to the SSD1351_CMD_SETCOLUMN and SSD1351_CMD_SETROW commands instead of the 2 bytes that the datasheet requires.

 

[macaba]

It might interest you to know that I'm working on the same thing, I've got it working so the entire display can be updated with very little CPU involvement using DMA from a frame buffer at 15FPS using a 4MHz SPI rate. Unfortunately I can't yet increase the SPI rate due to a issue that I've reported. [Edit: Now solved]
(Actually that's not quite true, if I edit the core teensy library so the default SPISettings() constructor uses a 12MHz clock instead of 4MHz, I see a frame rate of 40FPS! But this core library editing isn't ideal. I can't go above 12MHz either due to the capacitance in the breadboard I'm using.)

Also - whilst I may be able to update the display's frame buffer at 40FPS, I don't think it displays it that fast, I shall be testing this next.

 

[tenkai]

Macaba, would you mind sharing your SSD1351 DMA driver code? I am using this display and was thinking about getting it to work with DMA, but if you have already done most of the work, I would very much like to look at your code.

 

[macaba]

Macaba, would you mind sharing your SSD1351 DMA driver code? I am using this display and was thinking about getting it to work with DMA, but if you have already done most of the work, I would very much like to look at your code.

I'm hoping to publish a library at some point but this is a work in progress - I want all my drawing primitives to be anti-aliased and they have to all write to a frame buffer rather than direct to the display. Even the Adafruit_Gfx library isn't quite suitable - it has hardware abstraction (so it's trivial to make it write to a frame buffer instead of hardware) but not anti-aliased primitives. I have arbitrary rotation working nicely, so I'm no longer constrained to 0/90/180/270 screen rotations.

I can post an example sketch that shows the very basics of using DMA for the SSD1351?