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.p6

Blame
  • 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.