Add PSRAM support #2919
No reviewers
Labels
No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk!2919
Loading…
Reference in a new issue
No description provided.
Delete branch "pico-psram"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds a
hardware_psramlibrary to the SDK to add PSRAM support, as requested in https://github.com/raspberrypi/pico-sdk/issues/2372Adds PSRAM defines to board headers for boards that have PSRAM - I may not have captured them all
Has three ways it will detect PSRAM when you link
hardware_psram, in order of priority:PICO_AUTO_DETECT_PSRAMis set it will attempt to detect PSRAM size and GPIO on CS1PICO_PSRAM_SIZE_BYTESis set (eg configured in board header, or withpico_override_psram_size) it will initialise PSRAM with that size and GPIOVariables can be placed in PSRAM using
__psramor__psram_uninitialisedmacros, and you can also write directly to the memory addresses.If there are variables placed in PSRAM, it will setup ATRANS to prevent any access to PSRAM addresses greater than the size available (from flash_devinfo, auto-detection, or
PICO_PSRAM_SIZE_BYTES), which will cause bus faults. Thepsram_is_availablefunction should be used before accessing variables in PSRAM when auto-detection is on, to prevent these bus faults.This support uses flash_devinfo to enable the bootrom support for PSRAM, then adds a callback with
flash_set_qmi_cs1_setup_functionwhich runs as part offlash_rp2350_restore_qmi_cs1to enable quad mode and setup faster timings. The RP2350-E14 workaround is included.The CS pin auto-detection iterates through all possible CS pins, skipping any that are defined as defaults in board header files with
remove_defaults_from_cs_gpios- this is an ugly function, but without it you get some garbled characters on the UART as pin 0 is a possible CS pin. Maybe some of the defaults could be removed from this, if they are unlikely to be affected by this auto-detection?This has
psram_or_mallocandpsram_or_freemacros, which statically allocate in PSRAM and use that if available, but usemallocif not available - not sure how useful these are, could be removed if we don't want them. They were to demostratepsram_check_addresswhich checks if an address is in available PSRAM, so you can avoid busfaults when using variables in PSRAM.In passing this also:
Does it make sense to include this into an RP2040-specific file?
@ -140,1 +139,4 @@* implementation of pico_get_unique_id() for an example of this.** \if rp2040_specific* On RP2040 the chip select index is ignored, as there is only one chip select.Should we document that the
csparameter is ignored on RP2040?@ -140,1 +139,4 @@* implementation of pico_get_unique_id() for an example of this.** \if rp2040_specific* On RP2040 the chip select index is ignored, as there is only one chip select.Is it worth adding one of the
invalid_params_ifchecks on RP2350 to check thatcs < 2?@ -140,1 +139,4 @@* implementation of pico_get_unique_id() for an example of this.** \if rp2040_specific* On RP2040 the chip select index is ignored, as there is only one chip select.Perhaps the earlier "Low-level function to execute a serial command on a flash device attached to the QSPI interface." wording needs to be updated to say something like "flash or PSRAM device" ? 🤷
@ -140,1 +139,4 @@* implementation of pico_get_unique_id() for an example of this.** \if rp2040_specific* On RP2040 the chip select index is ignored, as there is only one chip select.@ -0,0 +1,269 @@/*type=bool?@ -0,0 +1,269 @@/*Isn't the entirety of
hardware_psramunusable if we're not running on RP2350?@ -0,0 +1,269 @@/*I guess this might be more readable as
133 * MHZ? 😉 Or would that introduce an unwanted header dependency?@ -0,0 +1,269 @@/*IMHO "time in ns of psram" here should be "time of psram in ns" ?
@ -0,0 +1,269 @@/*The defaults described here don't seem to match the
#defines below?@ -0,0 +1,269 @@/*Should the description and the function both use "initialised" or "available", rather than mixing the two terms?
@ -0,0 +1,269 @@/*?
@ -0,0 +1,269 @@/*?
@ -0,0 +1,269 @@/*Yes, but the default CS pins need to be defined for each platform
@ -0,0 +1,269 @@/*@ -0,0 +241,4 @@/*! \brief Provide a static PSRAM allocation, or malloc if PSRAM is not available* \ingroup hardware_psram** This will allocate a static buffer in PSRAM and if available use that, otherwise it will use the heap.@ -0,0 +1,269 @@/*Should there be a bunch of
\paramcomments here?@ -0,0 +1,269 @@/*Yes, but I'm leaving fixing up this API until after it's decided if it's wanted, so it's easy to back out the one commit - I'm not sure how much utility it has
I've added some more RP2040 incls, so this has been removed
@ -140,1 +139,4 @@* implementation of pico_get_unique_id() for an example of this.** \if rp2040_specific* On RP2040 the chip select index is ignored, as there is only one chip select.I'll removel the reference to PSRAM, and remove the word "flash" from the top paragraph so it's just "device" and "chip"
@ -0,0 +1,269 @@/*Have gone for "available and initialised" in the docs, and left the function name the same
@ -261,15 +274,16 @@ static void __no_inline_not_in_flash_func(flash_cs_force)(bool high) {IO_QSPI_GPIO_QSPI_SS_CTRL_OUTOVER_BITS);If the doxygen for
flash_do_cmd_csis explicitly saying "On RP2040 the chip select index is ignored, as there is only one chip select." then should thisinvalid_params_ifbe wrapped in a#if !PICO_RP2040?Also, should the same
invalid_params_ifbe added toflash_cs_force?@ -0,0 +1,269 @@/*Is what is written here about "during flash programming" also true for "during psram writing"? Or are Flash and PSRAM sufficiently different that less precautions are needed with psram?
@ -0,0 +1,269 @@/*Should this be made conditional on RP2350A versus RP2350B? (as GPIO 47 obviously only exists on RP2350B)
@ -0,0 +157,4 @@/*! \brief Detect PSRAM size* \ingroup hardware_psram** This will read the ID of the PSRAM chip and return the size based on the ID.(this is just a hunch based on the doxygen for
psram_eid_to_size😉 )@ -104,0 +106,4 @@## \param\ TARGET The target to override the FLASH size for# \param\ FLASH_SIZE The FLASH size to set for the targetfunction(pico_override_flash_size TARGET FLASH_SIZE)It looks like this is only used/useful for testing, so perhaps it makes sense to just add it to
kitchen_sinkrather thanpico_standard_link? 🤷(unintentional rhyme 😂 )
@ -104,0 +106,4 @@## \param\ TARGET The target to override the FLASH size for# \param\ FLASH_SIZE The FLASH size to set for the targetfunction(pico_override_flash_size TARGET FLASH_SIZE)It could be useful for creating universal binaries, if you wanted to force a smaller flash size to ensure your code always fits in that? Or if you wanted to build for multiple flash sizes in a single build directory?
I mostly added it because I was adding the PSRAM one and it was simple to add flash too.
@ -104,0 +106,4 @@## \param\ TARGET The target to override the FLASH size for# \param\ FLASH_SIZE The FLASH size to set for the targetfunction(pico_override_flash_size TARGET FLASH_SIZE)I'm showing my lack of CMake knowledge here, but do we need a specific override function for this, given that the board-header files all seem to follow the
pattern? Or are the override functions only needed because of the way that these values interact with the linker-scripts?
Hmmm, although that also raises an interesting side-question... are there some
#defines thatcheck_board_header.pyought to error about if they aren't guarded by an#ifndefclause? Because whilst it checks that the#ifndefmatches the enclosed#define, so that this would error:currently both
and
are considered equally valid. (And presumably the latter version wouldn't work properly with your
pico_override_flash_sizefunction? 🤔 )@ -104,0 +106,4 @@## \param\ TARGET The target to override the FLASH size for# \param\ FLASH_SIZE The FLASH size to set for the targetfunction(pico_override_flash_size TARGET FLASH_SIZE)It's needed to override the
pico_flash_region.ldfile, which sets the flash size in the linker script - the linker doesn't usePICO_FLASH_SIZE_BYTES.I think that second version without
#ifndefshould be marked as invalid - definitely for any define with apico_board_cmake_set_default, but more generally anything that wants to be overridable. Anything that is definitely fixed can just be a#define(eg the boot2 choice, rp2350 variant), but everything else should be overridable (eg I want to use an external LED because my on board one is broken). But that can probably come in a separate PR to develop, with specific exclusions for the defines which don't need to be#ifndefed.@ -104,0 +106,4 @@## \param\ TARGET The target to override the FLASH size for# \param\ FLASH_SIZE The FLASH size to set for the targetfunction(pico_override_flash_size TARGET FLASH_SIZE)Yup, that's what I was planning to do, rather than polluting #2924 (and apologies for the off-topic questions in this PR).
EDIT: This
#ifndefchecking has been done in #2927@ -261,15 +274,16 @@ static void __no_inline_not_in_flash_func(flash_cs_force)(bool high) {IO_QSPI_GPIO_QSPI_SS_CTRL_OUTOVER_BITS);I'll move it into
flash_cs_forceas that handles both of these issues@ -0,0 +1,269 @@/*It's a typo from copying - will use "while running these functions" instead
@ -0,0 +1,269 @@/*Annoyingly that ruins the utility of this for me, as I'm compiling for RP2350A but running on an RP2350B board with PSRAM on CS 47 - but looking at the code, using GPIO 47 on RP2350A will trigger an assertion when
PARAM_ASSERTIONS_ENABLED_HARDWARE_GPIOis enabled, so you are correct that this needs to be conditional.@ -0,0 +157,4 @@/*! \brief Detect PSRAM size* \ingroup hardware_psram** This will read the ID of the PSRAM chip and return the size based on the ID.EID is part of the ID - it also uses the KGD part, and returns 0 if that doesn't match what is expected, so I will leave this description as-is
@ -138,16 +137,44 @@ void flash_get_unique_id(uint8_t *id_out);* it is recommended that this function only be used to extract flash metadataShould these also be updated to say "device" rather than "flash"?
@ -0,0 +1,269 @@/*Presumably there'll be a separate PR adding this program to
pico-examples?@ -0,0 +171,4 @@* \ingroup hardware_psram** This runs \ref psram_detect_size() for each CS GPIO in the array in turn,* and returns the size as soon as a PSRAM chip is detected.This may be a stupid question, but would it be useful for the code calling this function to be able to determine which of the CS GPIOs got selected?
@ -0,0 +1,449 @@/*Looks like it might make sense to swap these?
That way the sizes in the comments would be in the order: 1 MiB, 16 MiB, 8 MiB, 4 MiB, 2 MiB
@ -0,0 +171,4 @@* \ingroup hardware_psram** This runs \ref psram_detect_size() for each CS GPIO in the array in turn,* and returns the size as soon as a PSRAM chip is detected.It can read the value from flash_devinfo with
flash_devinfo_get_cs_gpio(1)@ -0,0 +28,4 @@// Currently supports APS6404 and ISSI PSRAMsize_t psram_size = 0;if (kgd == PICO_DEFAULT_PSRAM_ID) { // Known Good Die - expects 0x5DI know nothing about PSRAM, but how likely is it that the code inside this
ifblock would still be correct if somebody changesPICO_DEFAULT_PSRAM_IDto a value other than0x5D?@ -0,0 +28,4 @@// Currently supports APS6404 and ISSI PSRAMsize_t psram_size = 0;if (kgd == PICO_DEFAULT_PSRAM_ID) { // Known Good Die - expects 0x5DI have no idea, as the only chips I've seen so far have had the same KGD value - if it doesn't work they can just write their own
psram_eid_to_sizeas it is a weak function@ -0,0 +1,449 @@/*I guess this ought to check that
num <= 4to prevent line 76 causing a buffer overflow?@ -0,0 +1,449 @@/*Hmm, I guess if you pass in 3 GPIO pins to this function, and the PSRAM CS is on the second GPIO pin, then the immediate
returnabove means that the GPIO function would be restored on the first GPIO, but not restored on the third GPIO?@ -0,0 +1,269 @@/*I'll remove as this doesn't have examples yet - was copied from flash.h
@ -0,0 +1,269 @@/*Having read through the code I can now see what
PICO_AUTO_DETECT_PSRAM_CS_SKIP_DEFAULTSis doing, but IMHO the "skip default GPIOs" description here is far too vague.@ -0,0 +1,449 @@/*Is it possible that this reorders the entries in the (trimmed down)
cs_gpiosarray? Does that matter?@ -0,0 +1,449 @@/*Yes it reorders them, but I don't think that matters
@ -0,0 +1,269 @@/*Happy for a suggestion of better wording - I agree "skip default GPIOs" is too vague, it's skipping anything that is defined as a
PICO_DEFAULT_XXX_PINor aCYW43_DEFAULT_PIN_XXX, although that list can probably be trimmed down as I mentioned in the PR description@ -0,0 +1,449 @@/*Yes, I will fix that and restore all GPIOs (the bootrom will then put the chosen GPIO back to CS1 when configuring PSRAM)
@ -0,0 +1,449 @@/*Actually, I can just use
gpio_function_t prev_funcs[num];to avoid that issue@ -0,0 +171,4 @@* \ingroup hardware_psram** This runs \ref psram_detect_size() for each CS GPIO in the array in turn,* and returns the size as soon as a PSRAM chip is detected.Perhaps this description needs updating now that the implementation has changed 😉
Also, maybe this function-description should warn that it will "wiggle" the CS GPIOs?
@ -0,0 +173,4 @@* This runs \ref psram_detect_size() for each CS GPIO in the array in turn,* and returns the size as soon as a PSRAM chip is detected.** This will setup the CS GPIO using flash_devinfo if PSRAM is found.I think this might be clearer like:
@ -0,0 +179,4 @@* \param num Number of CS GPIOs in the array* \return size of PSRAM, or 0 if none found*/size_t psram_detect_cs_and_size(uint8_t *cs_gpios, size_t num);Maybe this function should assert if
PICO_PSRAM_CS_PINhas been set? 🤔@ -0,0 +82,4 @@gpio_set_function(gpio, GPIO_FUNC_XIP_CS1);psram_size = psram_detect_size();if (psram_size > 0) {// CS GPIO found, so will be left configured in flash_devinfoIf no PSRAM was found, should we also restore flash_devinfo to the original value?
@ -0,0 +1,449 @@/*Should this also be saved and then restored, in case external code is relying on the isolation behaviour?
@ -0,0 +1,449 @@/*Perhaps it makes sense to rename this to e.g.
psram_initialized?@ -0,0 +179,4 @@* \param num Number of CS GPIOs in the array* \return size of PSRAM, or 0 if none found*/size_t psram_detect_cs_and_size(uint8_t *cs_gpios, size_t num);If you enable auto-detection it ignores
PICO_PSRAM_CS_PIN, so you can force auto-detection even ifPICO_PSRAM_CS_PINis defined - all of that is handled inruntime_init_setup_psram.These individual functions should be callable regardless of the compile definitions, as you may want to run manual auto-detection, so they don't look at the
PICO_PSRAM_XXXdefines.@ -0,0 +82,4 @@gpio_set_function(gpio, GPIO_FUNC_XIP_CS1);psram_size = psram_detect_size();if (psram_size > 0) {// CS GPIO found, so will be left configured in flash_devinfoWe haven't set the size, so the bootrom will be ignoring the flash_devinfo CS1 GPIO anyway, so I think it's fine
@ -0,0 +320,4 @@}bool psram_check_address(void* addr) {uint32_t offset = (uint32_t)addr - (XIP_BASE + flash_devinfo_size_to_bytes(FLASH_DEVINFO_SIZE_MAX));Could
addrever be less than(XIP_BASE + flash_devinfo_size_to_bytes(FLASH_DEVINFO_SIZE_MAX))?@ -0,0 +1,449 @@/*Why is setting the
PICO_PSRAM_CS_PINconditional on the value returned byflash_devinfo_get_cs_size?@ -0,0 +346,4 @@bool __unused flash_devinfo_not_configured = flash_devinfo_get_cs_size(1) == FLASH_DEVINFO_SIZE_NONE;// Setup flash_devinfo from compile definitions#if defined(PICO_PSRAM_CS_PIN) && !PICO_AUTO_DETECT_PSRAM_CSMaybe
#if defined(PICO_PSRAM_CS_PIN) && PICO_AUTO_DETECT_PSRAM_CSought to be a compile-time error? Or is there a reason why that configuration would be useful?Same question also for
#if defined(PICO_PSRAM_SIZE_BYTES) && PICO_AUTO_DETECT_PSRAM_SIZE@ -0,0 +1,449 @@/*Actually, I think I should use
gpio_set_function(gpio, GPIO_FUNC_XIP_CS1);here instead, rather than manually changing the isolation@ -0,0 +1,449 @@/*flash_devinfo_get_cs_size(1)appears in this function multiple times - is it worth caching the value into a local variable?@ -0,0 +320,4 @@}bool psram_check_address(void* addr) {uint32_t offset = (uint32_t)addr - (XIP_BASE + flash_devinfo_size_to_bytes(FLASH_DEVINFO_SIZE_MAX));Yes, if you're passing it a flash or bootrom address - but in that case it will still return false as
offsetwill be very large@ -0,0 +1,449 @@/*So that if flash_devinfo is already configured by OTP that is always used - there isn't an equivalent NONE value for the cs_gpio as 0 is valid, so checking the cs_size is the correct thing to do
@ -0,0 +346,4 @@bool __unused flash_devinfo_not_configured = flash_devinfo_get_cs_size(1) == FLASH_DEVINFO_SIZE_NONE;// Setup flash_devinfo from compile definitions#if defined(PICO_PSRAM_CS_PIN) && !PICO_AUTO_DETECT_PSRAM_CSCould be useful if you're compiling for a board with PSRAM, but want to enable auto-detection to work on other boards with different CS pins, or boards without PSRAM - enabling auto-detection overrides whatever is defined in the board header, see my priority list in the PR description
@ -0,0 +1,449 @@/*I found this code pretty hard to read. Instead of setting a
clear_startvalue and then iterating fromclear_startto7, would it make more sense to have aclear_regionsvalue and then iterate from(8 - clear_regions)to7? (or similar, if I've got the maths slightly wrong)@ -0,0 +1,269 @@/*Might be worth adding a comment that these values are only used by
runtime_init_setup_psramand are simply passed as a parameter topsram_detect_cs_and_size? When I first read this header file I incorrectly assumed thatpsram_detect_cs_and_sizewas doing some kind of filtering based on these values.But that raises an interesting question - what happens if
psram_detect_cs_and_sizeis given a GPIO number (e.g. 2) which isn't valid as a PSRAM CS pin?@ -0,0 +1,269 @@/*Maybe something like
skip any _DEFAULT_ GPIOs defined in the board-header when auto-detecting psram chip select pin?@ -0,0 +320,4 @@}bool psram_check_address(void* addr) {uint32_t offset = (uint32_t)addr - (XIP_BASE + flash_devinfo_size_to_bytes(FLASH_DEVINFO_SIZE_MAX));Ahh yes, I keep forgetting about that behaviour of unsigned arithmetic 😂 (too much time spent writing Python)
@ -0,0 +1,449 @@/*Ahhh, so if (upon entering this function)
flash_devinfo_get_cs_size(1) != FLASH_DEVINFO_SIZE_NONEthen I guess that must mean that the PSRAM was configured in OTP, and so large chunks of this function are effectively redundant, regardless of what other#defines have been set? Might be worth adding a comment about that.@ -0,0 +346,4 @@bool __unused flash_devinfo_not_configured = flash_devinfo_get_cs_size(1) == FLASH_DEVINFO_SIZE_NONE;// Setup flash_devinfo from compile definitions#if defined(PICO_PSRAM_CS_PIN) && !PICO_AUTO_DETECT_PSRAM_CSThanks for the expanded PR description, feels like some of that might be useful in
psram.h@ -0,0 +1,269 @@/*I can move them into
psram.cso they're only available thereIf you pass an invalid GPIO it will still try, but it will always fail to find PSRAM, as it will be configuring the pin for a different function (GPIO_FUNC_CORESIGHT_TRACE, GPIO_FUNC_GPCK, or just an invalid function) - same as if you passed an invalid function to
gpio_set_function@ -0,0 +1,449 @@/*It gets modified at the start, but I can cache it for the last section
@ -0,0 +1,269 @@/*Ahh, so no harmful side-effects; good to know 🙂
Looks like you could do something similar for
flash_devinfo_size_to_bytes(psram_flash_devinfo_size)😉@ -0,0 +1,449 @@/*I've rearranged the function to make it clearer what's going on
@ -0,0 +346,4 @@bool __unused flash_devinfo_not_configured = flash_devinfo_get_cs_size(1) == FLASH_DEVINFO_SIZE_NONE;// Setup flash_devinfo from compile definitions#if defined(PICO_PSRAM_CS_PIN) && !PICO_AUTO_DETECT_PSRAM_CSHave added lots of it there
@ -0,0 +1,449 @@/*Seems like this could just be:
?
@ -0,0 +392,4 @@uint32_t psram_words = (uint32_t)(&__psram_end__ - &__psram_start__);if (psram_words > psram_word_size) {// Setup to bus fault for variables that don't fit in available PSRAMint clear_regions = 0; // Clear no regions by defaultThis is more readable now thanks, and I can now see that this "Clear no regions by default" applies when the PSRAM size is 16MB 🙂
@ -0,0 +1,269 @@/*I was confused by this line at first, and thought it was missing a comma after "CS1" 😉 But now that I see what it's saying, would this be clearer?
@ -0,0 +1,269 @@/*might be slightly clearer?
@ -0,0 +23,4 @@* 2. If `PICO_AUTO_DETECT_PSRAM` is set it will attempt to detect PSRAM size and CS GPIO* on CS1. This will attempt to use all available QMI CS1n GPIOs as chip selects, so they* will be wiggled. By default, it will skip over some which are defined in the board* header (see `PICO_AUTO_DETECT_PSRAM_CS_SKIP_DEFAULTS`).Hmm, I wonder if there's a use-case for being able to say "never attempt to probe this list-of-GPIOs for PSRAM CS" if there are certain pins which the user doesn't want to get wiggled, but which aren't covered by any of the board-header
_DEFAULT_defines? 🤔@ -0,0 +1,269 @@/*@ -0,0 +1,269 @@/*Should this be
?
@ -0,0 +41,4 @@* If there are variables placed in PSRAM, XIP will be set up to cause bus faults on any* access to PSRAM addresses greater than the size available. The \ref psram_check_address* function should be used before accessing variables in PSRAM when auto-detection is on,* to prevent these bus faults.Should / could the kitchen_sink example demonstrate doing this?
@ -0,0 +1,269 @@/*? (I assume that PSRAM isn't write-only 😉 )
@ -0,0 +1,269 @@/*This might be one of my stupid questions, but if you wanted to have variables placed in PSRAM and also read/write PSRAM directly, is there a way of knowing which addresses in PSRAM aren't used by the variables placed in PSRAM?
(or maybe that's something you'd never need to do in practice?)
Should this PR also be adding
hardware_psramtodocs/index.h?Should line 15 of
src/rp2_common/hardware_psram/include/hardware/psram.hbe declaringhardware_psram(as used on e.g. line 133) instead ofpico_psram?@ -0,0 +41,4 @@* If there are variables placed in PSRAM, XIP will be set up to cause bus faults on any* access to PSRAM addresses greater than the size available. The \ref psram_check_address* function should be used before accessing variables in PSRAM when auto-detection is on,* to prevent these bus faults.Yes, it already tests this using
psram_or_mallocwhich bus faults in the tiny PSRAM version - a demonstration would be more suited to a pico-example@ -0,0 +1,269 @@/*You can read
extern uint32_t __psram_end__;to get the end of the region allocated to variables@ -0,0 +1,269 @@/*I'll go for this, as it's a sub-method, rather than a different method
@ -0,0 +23,4 @@* 2. If `PICO_AUTO_DETECT_PSRAM` is set it will attempt to detect PSRAM size and CS GPIO* on CS1. This will attempt to use all available QMI CS1n GPIOs as chip selects, so they* will be wiggled. By default, it will skip over some which are defined in the board* header (see `PICO_AUTO_DETECT_PSRAM_CS_SKIP_DEFAULTS`).Maybe, and that could be a better way of including the default pins
@ -0,0 +94,4 @@}return psram_size;}"comma separated list..." "type=bool"
🤔 😆
Also, might be better to just remove the
default=..., rather than sayingdefault=undefined@ -0,0 +205,4 @@}uint32_t rxdelay = divisor;if (clock_hz / divisor > 100000000) {rxdelay += 1;Depending on what other
#definesare set, I guess this might end up as e.g.(i.e. with nothing after the last comma). Is that allowed in C?
@ -0,0 +205,4 @@}uint32_t rxdelay = divisor;if (clock_hz / divisor > 100000000) {rxdelay += 1;Yes, trailing commas are fine in C
@ -0,0 +94,4 @@}return psram_size;}@ -0,0 +94,4 @@}return psram_size;}Unfortunately extract_configs.py only supports
type=int,type=boolandtype=enum😕Although given that there are so few QMI CS pins, maybe we could just use e.g.
(all with
type=bool)🤷
@ -0,0 +94,4 @@}return psram_size;}The extract_cmake_configs.py supports list, so I've copied that support in, and it seems to work fine
@ -0,0 +1,449 @@/*IIRC we normally put the
PICO_CONFIG:entries in the header file? (although this isn't a hard'n'fast rule as we currently have 16 exceptions)@ -0,0 +94,4 @@}return psram_size;}Nice.