suspect-devices/circuitpython/ports/raspberrypi/Makefile, branch 6.2.xCircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.2.x2021-03-24T22:03:33+00:00Use GCC @file to shorten linker command length2021-03-24T22:03:33+00:00Scott Shawcroftscott@tannewt.org2021-03-24T22:03:33+00:00urn:sha1:f79d60b20575bc848050ac213b79f86d9c317052
This hopefully fixes linking on Windows with cmd.exe
Fix doc build and address feedback2021-03-22T22:24:27+00:00Scott Shawcroftscott@tannewt.org2021-03-22T22:24:27+00:00urn:sha1:f200e6a21e851ab541027d33baf897fa5e5d4b0cRedo RP2040 flash settings2021-03-18T23:55:42+00:00Scott Shawcroftscott@tannewt.org2021-03-04T21:12:24+00:00urn:sha1:5d2b60cbf69c99abd6984c298d4f052514221177
This switches stage2 to C and uses Jinja to change the C code based
on flash settings from https://github.com/adafruit/nvm.toml. It
produces the fastest settings for the given set of external flashes.
Flash size is no longer hard coded so switching flashes with similar
capabilities but different sizes should *just work*.
This PR also places "ITCM" code in RAM to save the XIP cache for
code execution. Further optimization is possible. A blink code.py
still requires a number of flash fetches every blink.
Fixes #4041
Speed up a bit more2021-03-13T00:00:16+00:00Scott Shawcroftscott@tannewt.org2021-03-12T23:58:38+00:00urn:sha1:45487f14a0c0623af8fad817ca8ab43c9490ca2cLower default flash speed.2021-03-12T19:06:39+00:00Scott Shawcroftscott@tannewt.org2021-03-12T19:06:39+00:00urn:sha1:aec03a409f66cdb90e1b51c7ffb827750eadd830
/ 6 leads to ~40mhz. 2M and 4M have a max 0x03 read speed of 60mhz.
If the divisor is / 4 then the speed is just over 60mhz.
Fixes #4377
clean up2021-03-10T12:03:27+00:00hathachthach@tinyusb.org2021-03-10T12:03:27+00:00urn:sha1:58fb0110700fb96a9bfd5a4ae9a4f812e4b4af02rp2040 add double reset to uf2, also update pico-sdk to 1.1.02021-03-10T11:58:23+00:00hathachthach@tinyusb.org2021-03-10T11:58:23+00:00urn:sha1:d1c6bb092722867c7581022d993486a6ef2ae4c6add 1sec timeouts for I2C read and write2021-03-03T14:43:57+00:00Dan Halberthalbert@halwitz.org2021-03-03T14:43:57+00:00urn:sha1:fb7a0f7efcdd639ff4a14a2985f9381c426b2321raspberrypi: allow directly specifying the original boot .S file2021-03-02T03:08:19+00:00Jeff Eplerjepler@gmail.com2021-03-02T02:54:57+00:00urn:sha1:5a00862b1db24c11356b99c15ff9b449b50e9580
.. all the necessary steps to transform it into a padded, checksummed
file are now done by the build system.
Since it is assigned by "?=", it _should_ be the case that individual
builds can override it.
I did not "test" this per se, but it gives the same content and checksum
(except for the identifying comment with a path) as #4302.
raspberrypi: implement os.urandom2021-02-17T23:49:25+00:00Jeff Eplerjepler@gmail.com2021-02-17T22:50:49+00:00urn:sha1:ab5eb86118f5b446d9cb1996b07cae56e3f45643
Since the datasheet cast some doubt on the strength of the "rosc_hw->randombit",
I use the SHA256 hash function to create a high quality random seed
from random values of uncertain entropy, as well as to generate a sequence
of random values from that seed using SHA256 as a cryptographically-secure
random number generator.
In practice, it produces over 100kB/s of random data which does not
have any gross problems according to _PractRand_.