Skip to content
Snippets Groups Projects
Select Git revision
  • phhw
  • captouch-threshold
  • t
  • dos
  • test2
  • test
  • slewtest
  • simtest
  • view-think
  • vm-pending
  • media-buf
  • scope
  • passthrough
  • wave
  • vsync
  • dos-main-patch-50543
  • json-error
  • rahix/big-flow3r
  • main default protected
  • pippin/media_framework
  • v1.3.0
  • v1.2.0
  • v1.2.0+rc1
  • v1.1.1
  • v1.1.0
  • v1.1.0+rc1
  • v1.0.0
  • v1.0.0+rc6
  • v1.0.0+rc5
  • v1.0.0+rc4
  • v1.0.0+rc3
  • v1.0.0+rc2
  • v1.0.0+rc1
33 results

sdkconfig.p3

Forked from flow3r / flow3r firmware
Source project has a limited visibility.
  • q3k's avatar
    ebe9f721
    flow3r_bsp: init, implement next gen SPI display driver · ebe9f721
    q3k authored
    This replaces the original GC9A01 driver with one optimized for our
    usecase, implemented directly in a brand-new BSP (board support package)
    component.
    
    The major differences between the drivers are:
    
     1. aware of different badge generations
     2. generic: still supporting the possibility that we might have to
        switch to a different SPI display at some point
     3. only supports writing entire screen at once from in-memory buffer:
        no line drawing, filling, etc.
     4. spi screen blitting does not waste CPU time, instead uses
        ESP-IDF/FreeRTOS DMA/Interrupt logic to perform transfers
        efficiently.
    
    We also drive-by enable SPIRAM, as we're starting to run out of memory.
    ebe9f721
    History
    flow3r_bsp: init, implement next gen SPI display driver
    q3k authored
    This replaces the original GC9A01 driver with one optimized for our
    usecase, implemented directly in a brand-new BSP (board support package)
    component.
    
    The major differences between the drivers are:
    
     1. aware of different badge generations
     2. generic: still supporting the possibility that we might have to
        switch to a different SPI display at some point
     3. only supports writing entire screen at once from in-memory buffer:
        no line drawing, filling, etc.
     4. spi screen blitting does not waste CPU time, instead uses
        ESP-IDF/FreeRTOS DMA/Interrupt logic to perform transfers
        efficiently.
    
    We also drive-by enable SPIRAM, as we're starting to run out of memory.