When the firmware blob is exactly a multiple of 10 times the packet
size, the last checksum request causes the reply to the last program
request to be missed (there is only a response from the hub to the very
last program request). The program response is received, then the
checksum response is received. Since the saga is waiting for the
checksum response first, the program response is discarded.
Fix by breaking out of the loop when the firmware has been fully
transferred before making the checksum request.
Fixes: pybricks/support#178
clicking on a link with a URI fragment (e.g. https://docs.pybricks.com/en/latest/parameters.html#pybricks.parameters.Port)
inside the documentation iframe breaks the layout.
The browser seems to force the parent frame to scroll to the position as well.
As the toolbar is fixed, the rest of the content is scrolled under it.
Rerendering after the link click fixes the layout (at least if done manually).
But a more elegant solutions is to remove the absolute positioning of the toolbar.
It is not really necessary to pin it, as the rest of the layout always
spans over the complete width and height of the browser window.
This moves the .wasm file out of the static/js/ folder and into the
source tree. This way we can import it and webpack will pick it up
and version the file with a hash.
This fixes possibly running with an out of date file from the browser
cache and also fixes running offline.
The file extension had to be changed because there is a default rule in
webpack that matches the .wasm extension and causes the following error:
Failed to compile.
./src/sagas/mpy-cross.wasm
Module parse failed: magic header not detected
File was processed with these loaders:
* ./node_modules/file-loader/dist/cjs.js
You may need an additional loader to handle the result of these loaders.
Error: magic header not detected
The webpack configuration cannot be modified without ejecting
create-react-app or using something like react-app-rewired, which we
would like to avoid.
Also using ncp to copy file now which fixes building on Windows.
There have been some reports of firmware flashing not working with a
checksum timeout error, meaning that we probably overflowed a buffer
on the Bluetooth chip from sending data too fast.
We don't have info of the Bluetooth firmware so we are just guessing
here.
On Windows, we can get the GATT notification from the bootloader before
Windows says we are done writing to the characteristic. This was
observed on the erase and checksum messages with the Control+ hub.
For some reason this significantly improved bluetooth performance so we
had to readjust the frequency of getting the checksum. The new value
actually makes much more sense. It is unlikely that the bootloader
actually had an 8k buffer.
It seems that some container of the Editor component is breaking the
resize calculation when the page firsts loads. So we have to be bit
hacky and defer the call the resize until after all components have
been rendered.
David Lechner
Andreas Litt
Laurens Valk