No more GENERIC_SPIRAM board? #12253
Comments
|
|
They were merged in 2fbf42d; now instead of being a separate board they're a "variant" of the generic board. You can select these with the We should probably update the README section to reflect this. |
|
Can you remove the bug label? It is not a bug. I fixed may build scripts, because of this change. Code to generate make commands: #!/usr/bin/env python3
import json
from collections.abc import Generator
from pathlib import Path
# micropyton is in my home directory
MICROPYTHON = Path.home() / "micropython"
PORTS = MICROPYTHON / "ports"
def get_ports() -> Generator[Path, None, None]:
for port in sorted(PORTS.iterdir()):
if port.is_dir() and port.joinpath("boards").exists():
yield port
def get_boards(port: Path) -> Generator[Path, None, None]:
for board in sorted(port.joinpath("boards").iterdir()):
if board.is_dir():
if board.exists() and board.is_dir():
yield board
def get_variants(board: Path) -> list[str]:
try:
with board.joinpath("board.json").open() as fd:
return json.load(fd).get("variants", [])
except FileNotFoundError:
return []
def make_command(port: Path, board: Path, variant: str | None = None) -> None:
cmd = cmd = f"make -C {port} -j 8 BOARD={board.name}"
if variant:
cmd += f" BOARD_VARIANT={variant}"
output_dir = port.joinpath(f"build_{board.name}_{variant.upper()}")
else:
output_dir = port.joinpath(f"build_{board.name}")
cmd += f" BUILD={output_dir}"
sub = f"{cmd} submodules"
print(sub)
print(cmd)
for port in get_ports():
for board in get_boards(port):
make_command(port, board)
for variant in get_variants(board):
# skipping idf3
if variant == "idf3":
continue
make_command(port, board, variant)
print()Example for esp32 GENERIC with SPIRAM. |
|
Sorry but not clear what need to be done to compile for GENERIC_SPIRAM. |
|
make BOARD=GENERIC BOARD_VARIANT=spiram |
|
That's what I get. The board has 2MB of RAM |
|
Thanks for the |
|
That's the confusing result of the recent PR #12141. gc.mem_free() does not show all memory. micropython.mem_info shows more. And even if mem_free() just shows about 50 k, you can allocate more RAM, up to the physical max. The available RAM will be expanded on request. |
|
Confusing and IMO a regression. I hope it will be fixed. Thank you very much. |
@DvdGiessen We did, but it's in the subsequent PR which hasn't been merged yet. #12240 Note that once that PR is merged, it will be
This will of course all be in the v1.21 release notes. And #12240 includes a notice when you try and use the old "GENERIC" board name. We're also trying to make this less confusing for the S2/S3 boards by just not having a spiram variant at all, the one build just works for both types. Unfortunately this isn't possible for the original ESP32. It wasn't our intention to have a several-day gap between merging the two halves of this work (#12088 and #12240) but life (and a weekend) got in the way.
It's not clear what you mean here... what do you need "fixed" ? We often have to make changes to improve consistency, but unfortunately this by its nature means that we have to break the "inconsistent" part.
@robert-hh This will definitely take some explaining, but this is a very important feature to make ESP32 support SSL and not be unnecessarily slowed down by large PSRAM. Definitely open to suggestions on further improvements we can make to the API... |
Where is the GENERIC_SPIRAM board definition (ESP32)?
It was merged into another board type?
The text was updated successfully, but these errors were encountered: