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

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.