Skip to content
Snippets Groups Projects
Select Git revision
  • nick-adjustable-colors
  • alters
  • main default protected
  • blm_docs
  • release/1.0.0
  • fm_fix2
  • fm_fix
  • sec/blinky
  • pippin/wip
  • pippin/make_empty_drawlists_skip_render_and_blit
  • pressable_bugfix
  • moon2_gay_drums
  • moon2_applications
  • schneider/application-remove-name
  • anon/webflasher
  • pippin/display-python-errors-on-display
  • bl00mbox
  • bl00mbox_old
  • schneider/recovery
  • schneider/bhi581
  • 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
27 results

sdkconfig.p6

Blame
  • Forked from flow3r / flow3r firmware
    1387 commits behind, 3 commits ahead of the upstream repository.
    • 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.
    sdkconfig.p6 1.19 KiB