Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: GlasgowEmbedded/glasgow
base: 80ff1c51a7e7^
Choose a base ref
...
head repository: GlasgowEmbedded/glasgow
compare: 81e3fadeba7c
Choose a head ref
  • 6 commits
  • 3 files changed
  • 1 contributor

Commits on Jul 19, 2019

  1. access.direct.demultiplexer: introduce soft_flush 

    flush() ensures that all written data has been sent to the device.
soft_flush() on the other hand ensures that all written data has been
queued as USB URBs, but does not wait for them to complete.

Use soft_flush() to ensure that every last byte of queued data will
make it to the device in a timely manner, without stalling the entire
USB transfer pipeline.
    @marcan
    marcan committed Jul 19, 2019
    Configuration menu
    Copy the full SHA
    80ff1c5 View commit details
    Browse the repository at this point in the history

  2. applet.video.ws2812_output: use soft_flush 

    We need to make sure that all video data will make it to the Glasgow in
a timely manner, to avoid "tearing" the frame (the LEDs cannot handle
gaps longer than a few microseconds in the data stream without
triggering a premature latch/reset), but we don't necessarily want to
block for the data to actually be sent.
    @marcan
    marcan committed Jul 19, 2019
    Configuration menu
    Copy the full SHA
    39f2ce2 View commit details
    Browse the repository at this point in the history

  3. access.direct.demultiplexer: introduce software side queue length limits 

    This implements a configurable thireshold for FIFO data queueing on the
Python side, with pushback. Previously, any data was buffered eagerly,
e.g. an applet sending data on the hardware side and never receiving
it on the software side (or vice versa) would cause the data to pile up
in Python buffers at full speed, with no memory usage limit.

With this patch, the user may specify queue size limits. These limits
are not strict, but rather just thresholds for pushback. If the user
configures a 1MB FIFO limit and writes 100MB, the write will complete
immediately, but a subsequent write will block until 99MB of data has
been successufully queued with the USB subsystem (URB buffers do not
count towards the limit). Similarly, configuring a 1MB read limit
will allow a URB completion that crosses that threshold to complete,
but no further URBs will be re-queued until the application reads data
from the FIFO, eventually causing the on-device FIFO to fill up and
stop accepting writes from the gateware.
    @marcan
    marcan committed Jul 19, 2019
    Configuration menu
    Copy the full SHA
    b65b721 View commit details
    Browse the repository at this point in the history

  4. support.endpoint: introduce queue_size argument 

    This limits the receive queue size and pushes back on the underlying
transport when the receive queue is full.
    @marcan
    marcan committed Jul 19, 2019
    Configuration menu
    Copy the full SHA
    10f27e6 View commit details
    Browse the repository at this point in the history

  5. applet.video.ws2812_output: implement pushback

    @marcan
    marcan committed Jul 19, 2019
    Configuration menu
    Copy the full SHA
    bbcf1ba View commit details
    Browse the repository at this point in the history

  6. applet.video.ws2812_output: reduce reset time to 300µs as documented

    @marcan
    marcan committed Jul 19, 2019
    Configuration menu
    Copy the full SHA
    81e3fad View commit details
    Browse the repository at this point in the history