iframe-proxy

wiznet-grace · 2025-09-04T00:39:18Z

Summary

This PR adds full support for WIZnet Ethernet controller EVB (Evaluation Board) series
(W5100S, W5500, W6100, W6300, W55RP20) to the MicroPython RP2 port.

Key Changes

Migration from wiznet5k → wiznet6k
- W5100S_EVB_PICO
- W5500_EVB_PICO
New Board Support (7 boards)
- W5100S_EVB_PICO2 – Pico2 with W5100S (#16280)
- W5500_EVB_PICO2 – Pico2 with W5500 (#16280)
- W55RP20_EVB_PICO – RP2040 + W5500 SiP (#16476)
  → Dedicated PIO driver files added
- W6100_EVB_PICO – Pico with W6100
- W6100_EVB_PICO2 – Pico2 with W6100
- W6300_EVB_PICO – Pico with W6300 QSPI
  → Dedicated PIO driver files added
- W6300_EVB_PICO2 – Pico2 with W6300 QSPI
  → Dedicated PIO driver files added
Network Stack Integration
- extmod/network_wiznet6k.c (~1,197 lines) – full-featured network driver
- lib/wiznet6k – WIZnet official ioLibrary as a submodule
- LWIP integration – supported on all boards
- Official HAL support – stable and validated hardware abstraction
PIO-based SPI Driver
- wiznet_pio_spi.[c|h|pio], machine_wiznet_pio_spi.c (~1,223 lines)
- High-performance SPI via RP2040/RP2350 PIO
- QSPI support – W6300 Single/Dual/Quad mode

Driver Code Size

network_wiznet6k.c: 1,197 lines
PIO-related files: 1,223 lines
Total ~2,420 lines added

File Structure

extmod/
└── network_wiznet6k.c

lib/
└── wiznet6k/ # new submodule

ports/rp2/
├── machine_wiznet_pio_spi.c
├── wiznet_pio_spi.[c|h|pio]
└── boards/
├──── W5100S_EVB_PICO2/
├──── W5500_EVB_PICO2/
├──── W55RP20_EVB_PICO/ # PIO-based SPI
├──── W6100_EVB_PICO/
├──── W6100_EVB_PICO2/
├──── W6300_EVB_PICO/ # PIO-based SPI + QSPI
└──── W6300_EVB_PICO2/ # PIO-based SPI + QSPI

Testing

Verified successful builds on all supported WIZnet EVB boards
Verified TCP (loopback, client/server) and DHCP functionality on all WIZnet boards
Verified QSPI Single/Dual/Quad modes on W6300 boards

Trade-offs and Alternatives

Driver code size increases (~2,420 LOC) due to the new driver and PIO/library integration
In return, this provides a unified driver model across all WIZnet EVB boards with official ioLibrary integration, plus access to TOE and QSPI features
Alternative: keep lwIP-only raw mode to reduce size, but this would forgo TOE and QSPI optimisations

codecov · 2025-09-04T00:45:51Z

github-actions · 2025-09-04T00:53:56Z

Code size report:

Reference:  unix/mpconfigport: Use setjmp GC helper on macOS for Intel. [b006887]
Comparison: rp2/boards: Add WIZnet EVB boards and wiznet6k submodule. [merge of 0db4474]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

MilhouseVH · 2025-09-04T22:50:17Z

+
+```
+>>> import network
+>>> nic = network.WIZNET5K()


Suggested change

>>> nic = network.WIZNET5K()

>>> nic = network.WIZNET6K()

... and presumably the same in the other W5K examples below?

An example demonstrating the use of an explicit call to SPI/PIO_SPI might be nice too, as that allows the default speeds to be overridden... last time I tried this the SPI and PIO_SPI constructor calls weren't 100% compatible.

Thank you for pointing this out
You are right — I missed updating the README. I’ll fix this and add the correct README sections for each board.
I’ll also update the examples to use WIZNET6K() and add explicit SPI/PIO-SPI initialization examples as you suggested.
Thanks again for the helpful feedback!

SteveSpencer · 2025-09-09T22:13:48Z

See #18024. The existing wiznet5k code does not propagate the hostname when using DHCP.
I have a tentative fix, but wondered if this was already resolved in the new wiznet6k code?
Would it be possible to include it?
if not, otherwise I would need to do a PR for the 5k code and then potentially another one for the 6k code.

I also identified that when the hostname is set by the DHCP server (such as dnsmasq), it is ignored by LWIP (so not just the wiznet drivers), but it is possible to workaround that by sending a DNS request for the assigned IP to get the hostname, and then set it.

wiznet-grace · 2025-09-10T01:50:27Z

See #18024. The existing wiznet5k code does not propagate the hostname when using DHCP. I have a tentative fix, but wondered if this was already resolved in the new wiznet6k code? Would it be possible to include it? if not, otherwise I would need to do a PR for the 5k code and then potentially another one for the 6k code.

I also identified that when the hostname is set by the DHCP server (such as dnsmasq), it is ignored by LWIP (so not just the wiznet drivers), but it is possible to workaround that by sending a DNS request for the assigned IP to get the hostname, and then set it.

Thank you for pointing this out! I’ve revised the code accordingly and will push the changes again. To summarize the modifications:

MICROPY_PY_LWIP = 1 (LwIP stack enabled)

In this mode, the DHCP hostname is taken from MicroPython’s modnetwork layer. By default it uses the value defined in the board configuration (mpconfigboard.h via MICROPY_PY_NETWORK_HOSTNAME_DEFAULT), and it can also be overridden at runtime in Python with network.hostname("...").

MICROPY_PY_LWIP = 0 (ioLibrary TOE stack)

In this mode, the DHCP client logic comes from ioLibrary. Here, the hostname is hardcoded as "WIZnet" with the last 3 bytes of the MAC address appended, resulting in something like WIZnetABC123. As seen in Wireshark captures, DHCP Option 12 is always set in this format.

In summary:

LwIP mode: uses the hostname defined in the board configuration (mpconfigboard.h).
TOE/ioLibrary mode: hostname is always fixed to WIZnet+MAC suffix.

Thanks again for highlighting this—it helped clarify the difference between the two paths.

novaplusplus · 2025-09-12T15:50:19Z

I just tested this applied against the 1.26.0 release version, with just an RPi Pico and a W5500 module on a breadboard, and now network.hostname() seems to work as it's supposed to as far as mDNS is concerned. I can reach it via a .local address properly now when I couldn't before, though it doesn't seem to have sent out the hostname to my router. However it may just be caching a previous DNS lease so I think that's likely an issue on my end.

Also - I noticed an extreaneous 2.5mb ports/rp2/build_log.txt file in the diff which I assume should not be there.

edit: I changed the MAC on the module so it would get a new lease but it still didn't seem to send out the hostname to the router. Very possible I just configured my board variant wrong however. Still maybe worth other testing

wiznet-grace · 2025-09-15T00:20:43Z

I just tested this applied against the 1.26.0 release version, with just an RPi Pico and a W5500 module on a breadboard, and now network.hostname() seems to work as it's supposed to as far as mDNS is concerned. I can reach it via a .local address properly now when I couldn't before, though it doesn't seem to have sent out the hostname to my router. However it may just be caching a previous DNS lease so I think that's likely an issue on my end.

Also - I noticed an extreaneous 2.5mb ports/rp2/build_log.txt file in the diff which I assume should not be there.

Thanks a lot for testing this!
Really glad to hear that .local resolution is now working properly via mDNS. The router not showing the hostname might indeed be due to a cached DHCP lease, as you mentioned — I’ll double-check that on my side as well.

And thanks for pointing out the stray ports/rp2/build_log.txt file — that was accidentally included. I’ll delete it right away.

wiznet-grace · 2025-09-15T01:57:05Z

edit: I changed the MAC on the module so it would get a new lease but it still didn't seem to send out the hostname to the router. Very possible I just configured my board variant wrong however. Still maybe worth other testing

I just reviewed the details you added.
As you mentioned, which DHCP options are required or respected depends on the router’s configuration.

MICROPY_PY_LWIP = 1 (lwIP mode)

→ DHCP Discover/Request includes Option 12 (Host Name).
MICROPY_PY_LWIP = 0 (TOE mode)

→ DHCP Discover/Request includes both Option 12 (Host Name) and Option 61 (Client Identifier).

So the device is already sending the Host Name correctly.
However, some routers only check Option 12, while others require Option 81 (Client FQDN). In such cases, the router may ignore or not display the Host Name depending on its settings or firmware policy.

This means the issue is more likely on the router configuration or firmware behavior side rather than on the device code.
I recommend testing with a different router, or checking your current router’s DHCP settings (especially how it handles Host Name / FQDN options).

Lobo-T · 2026-02-17T13:55:40Z

Hi, I have been using this version (MicroPython v1.27.0-WIZnet on 2025-12-30; W5500-EVB-Pico2 with RP2350) on a pico2 with an external W5500 based LAN Adapter and it has been working quite well. that being said, I would have a question regarding the flash size? Is there any reason to have the same Flash available on the pico2 as on the pico (about 1.4MB). This is fine for a pico having 2MB in total. For a pico2 with twice the flash, I would have expected to have about 3MB for files, leaving the last MB for Micropython itself...?

This should probably be moved from this pull request to a discussion instead.
But, that's a choice that Wiznet has made with the W5500-EVB-Pico2. It only has a 2MB flash IC.
If you use it with a Pico2 with 4MB you can compile Micropython yourself with support for 4MB flash and W5500.

tofDE · 2026-02-17T14:21:32Z

@Lobo-T , thanks a lot for the fast feedback. I didn't know there were pico 2 chips with only 2MB of Flash....
I guess I have to re create a pull request on this as I am quite a newbie on this topic and have no idea which files I would need to look at and modify to increase the flash available before re compiling it....

wiznet-grace · 2026-02-25T00:10:56Z

Hello. @tofDE.
As @Lobo-T mentioned, while the official Raspberry Pi Pico 2 comes with a 4MB Flash, the W5500-EVB-Pico2 board is equipped with a 2MB (16Mb) Flash IC (W25Q16JVUXIQ).

Because the MicroPython firmware for RP2350 with W5500 support is larger than the original, we have allocated the maximum possible space for the filesystem, which results in the current 1.4MB (1408KB) storage limit.

Also, while investigating this, I noticed a small typo in the ports/rp2/boards/W5500_EVB_PICO2/board.json file and have corrected it.

Thanks for your valuable feedback!

wiznet-grace · 2026-03-11T06:13:08Z

Rebased this PR onto latest master at 4319927. Resolved the ports/rp2/CMakeLists.txt merge conflict, and I’ve re-run builds/tests locally to confirm everything is working. Force-pushed, so commit SHAs have changed.

wiznet-grace · 2026-05-18T07:41:29Z

Hi @dpgeorge,

I'd like to add two additional commits to this PR:

[extmod/network_wiznet5k,6k: implement timeout and setsockopt for provided stack.](WIZnet-ioNIC@2906a93)
- Implements settimeout() and setsockopt() (SO_REUSEADDR, SO_BROADCAST, SO_KEEPALIVE, SO_SNDTIMEO/SO_RCVTIMEO) which were previously TODO stubs returning EINVAL.
[extmod/network_wiznet5k,6k: Return 0 (EOF) on recv when peer closes connection.](WIZnet-ioNIC@5a8e293)
- When SOCK_CLOSE_WAIT is detected with no remaining RX data, recv() now returns 0 (EOF) instead of ENOTCONN, matching POSIX behavior. This was a pre-existing issue that caused failures in HTTP client usage.

Would it be okay to include these in this PR? Happy to split into a separate PR if you'd prefer.

wiznet-grace · 2026-06-18T05:29:58Z

Rebased onto latest master (b05f9a5). Resolved conflicts in .gitmodules, W5100S_EVB_PICO/mpconfigboard.cmake, and W5500_EVB_PICO/mpconfigboard.cmake — keeping WIZNET6K and compiler flags while incorporating the upstream MICROPY_HW_FLASH_STORAGE_BYTES cmake migration.

Also aligned all 9 WIZnet EVB boards to consistently set MICROPY_PY_NETWORK, MICROPY_WIZNET_PIO, and MICROPY_HW_FLASH_STORAGE_BYTES in cmake (moved from .h).

MilhouseVH · 2026-06-18T16:07:04Z

b05f9a5 tested fine on top of current master (d901e98): W55RP20-EVB-PICO, W5500-EVB-PICO, W5500-EVB-PICO2 and W6300-EVB-PICO2. 👍

wiznet-grace · 2026-08-06T07:15:20Z

Rebased onto master and force-pushed with the fixes amended in.

This addresses a W6300-EVB-Pico2 report where status() was stuck at 0 with the link LEDs on, DHCP timing out, and wiznet6k_send_ethernet: fatal error -5 on transmit. All changes are in extmod/network_wiznet6k.c:

wizphy_getphylink() reads the latching-low BMSR link bit over MDIO only once, so it reported link-down after any reset. isconnected() and status() now read PHYSR directly on W6100/W6300.
A transfer error took the netif down with nothing to bring it back up, which also stopped RX polling and the lwIP timers. Those calls are removed.
wiznet6k_deinit() ran after the chip reset, so lwIP's multicast leave was sent on a closed socket and printed a spurious -5. It now runs before the reset.
regs() passed a raw offset where W6100/W6300 expect (offset << 8) | block, so the dump was meaningless. Fixed — it now reaches Sn_SR at 0x30.
DHCP_time_handler() had no caller, so DHCP_run() never retransmitted a lost request. The DHCP loop now calls it once a second.
wiznet6k_init() pushed a zeroed netinfo before the defaults were filled in, clearing SHAR and the IP config. The premature call is removed.

Basic ethernet operation confirmed on all boards.

MilhouseVH · 2026-08-11T22:53:33Z

Thanks @wiznet-grace

It took me a while to work out this PR (4671b80) doesn't apply cleanly on current master (b006887) but does apply clean on the older commit 06bcfd5 from 1 August 2026 - dunno what the problem is, but this PR may require another small rebase?

I've built this PR for all the supported boards, no issues.

I've tested it on W5500_EVB_PICO, W5500_EVB_PICO2, W55RP20_EVB_PICO and W6300_EVB_PICO2 - again no issues, all working as expected.

Unfortunately I don't have the time to review the source code in detail.

@dpgeorge is there any chance of this landing soon? I'm sure that would make a lot of people very happy! Thanks. 😃

Signed-off-by: wiznet-grace <Grace@wiznet.io>

wiznet-grace · 2026-08-12T02:28:51Z

Thanks @wiznet-grace

It took me a while to work out this PR (4671b80) doesn't apply cleanly on current master (b006887) but does apply clean on the older commit 06bcfd5 from 1 August 2026 - dunno what the problem is, but this PR may require another small rebase?

I've built this PR for all the supported boards, no issues.

I've tested it on W5500_EVB_PICO, W5500_EVB_PICO2, W55RP20_EVB_PICO and W6300_EVB_PICO2 - again no issues, all working as expected.

Unfortunately I don't have the time to review the source code in detail.

@dpgeorge is there any chance of this landing soon? I'm sure that would make a lot of people very happy! Thanks. 😃

Rebased onto current master (b006887) — the rebase is the only change, no code
changes since you tested.

Thank you for the builds and the hardware testing, it's always appreciated.

MilhouseVH

PR applies cleanly, builds and works fine on the following boards:

W5500_EVB_PICO
W5500_EVB_PICO2
W55RP20_EVB_PICO
W6300_EVB_PICO2

Many thanks Grace! 👍

MilhouseVH · 2026-08-24T15:49:07Z

I really hope this finally lands in 1.30... it's missed the cut enough times to perhaps start thinking there's some sort of agenda against it. \o/

projectgus

Thanks @wiznet-grace for keeping this PR up to date for so long, and sorry it's taken so long to review it.

One reason it's taken so long is that it is a very big PR that touches multiple parts of MicroPython and adds multiple features.

Do you think it could be possible to split it up? Maybe as 3 PRs in order:

Add Wiznet6k driver for W6xxx chips and boards only. I think we could merge this PR quite quickly.
Add PIO_SPI driver. I have some questions below about whether this is a "Wiznet" feature, or a feature we add on the rp2 port for general use.
Update Wiznet5k driver to use Wiznet6k code, PIO_SPI driver. This raises some complex questions (also below).

Splitting the PRs up will be more work at the beginning, but it'd be a lot easier for us to review and merge each one.

I've left some inline comments but I haven't reviewed everything because this PR is so big. From the high level view, some other things to consider:

The new Wiznet6k driver will need documentation (i.e. docs/library/network.WIZNET5K.rst equivalent).
Need to understand what the future for Wiznet5k driver is, and how we manage backwards compatibility and documentation so this is clear for users. Using different drivers for the same chip on different boards isn't really an option.
Has the new W6xxx support been tested on any ports apart from rp2?

projectgus · 2026-08-26T01:03:17Z

 } mp_machine_soft_spi_obj_t;

+// PIO QSPI object.
+typedef mp_machine_soft_spi_obj_t machine_wiznet_pio_spi_obj_t;


extmod/ is generally for cross-port machine features. If I understand correctly, the "Wiznet PIO SPI" function is only relevant for rp2 port.

Is there anything Wiznet-specific about this class? For MicroPython, it seems like it would make more sense to:

Add a machine.PIOSPI object to the rp2 port, that can be used anywhere that regular machine.SPI can be used.

Add support to the Wiznet driver to accept any "SPI object" as the driver, including the "PIOSPI" object.

What do you think?

I'm not necessarily saying you have to make this change for this PR, but if we're adding these features then it's important for us to think about how it works for the whole of MicroPython and not just the Wiznet drivers.

Agreed. I'll rework it as a general-purpose PIO SPI rather than a WIZnet-specific one, and submit that as a separate PR.

projectgus · 2026-08-26T01:10:54Z

+    #if _WIZCHIP_ < W5200
+    uint8_t sn_size[8] = {8, 0, 0, 0, 8, 0, 0, 0};
+    #elif (_WIZCHIP_ == W5200 || _WIZCHIP_ == W5300 || _WIZCHIP_ == W5500 || _WIZCHIP_ == W6100)
+    uint8_t sn_size[16] = {16, 0, 0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0};


We already have drivers for the Wiznet 5K series in network_wiznet5k.c. How should we approach this, can we remove the network_wiznet5k.c driver and replace it with this one?

Answered in the main review thread — yes, it can be removed and replaced with this one.

projectgus · 2026-08-26T01:14:39Z

 if(NOT DEFINED MICROPY_HW_FLASH_STORAGE_BYTES)
    set(MICROPY_HW_FLASH_STORAGE_BYTES 1441792)  # 1408 * 1024
 endif()
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-unused-but-set-variable -Wno-unused-variable -Wno-misleading-indentation -Wno-incompatible-pointer-types -Wno-error=unused-function -Wno-comment -Wno-unused-function")


We can't disable warnings for all source files like this.

If there are external files which need this change applied then can do it for single source files in ports/rp2/CMakeLists.txt like this:
https://github.com/micropython/micropython/blob/master/ports/rp2/CMakeLists.txt#L641

However if the warnings are coming from MicroPython code then they need to be fixed, not ignored.

(Same comment applies for all of the new mpconfigboard.cmake files.)

Yes, I added those deliberately, because the vendored ioLibrary_Driver still has warnings of its own. I'll take them out and check whether any of the warnings are coming from the MicroPython code rather than the library.

projectgus · 2026-08-26T01:14:56Z

    set(MICROPY_HW_FLASH_STORAGE_BYTES 1441792)  # 1408 * 1024
 endif()
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-unused-but-set-variable -Wno-unused-variable -Wno-misleading-indentation -Wno-incompatible-pointer-types -Wno-error=unused-function -Wno-comment -Wno-unused-function")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb -mcpu=cortex-m0plus")


This line shouldn't be necessary, the rp2 build process should already be setting these flags.

(Same comment applies for all of the new mpconfigboard.cmake files.)

Understood — I'll test that and confirm.

projectgus · 2026-08-26T01:19:26Z

 ```
 >>> import network
->>> nic = network.WIZNET5K()
+>>> nic = network.WIZNET6K()


This will be a breaking change for anyone already using this board, the driver name is changing.

It's also a confusing API if some boards need WIZNET5K() for Wiznet 5K and some need WIZNET6K(). See earlier comment about the future of the wiznet5k driver.

Answered in the main review thread!

wiznet-grace · 2026-08-26T08:05:33Z

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch from 2235bff to 9f9fb87 Compare September 4, 2025 00:42

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch 3 times, most recently from 8dbf4bc to 7a8344d Compare September 4, 2025 02:20

MilhouseVH reviewed Sep 4, 2025

View reviewed changes

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch 9 times, most recently from d1e15d5 to 8653aae Compare September 5, 2025 08:14

SteveSpencer mentioned this pull request Sep 9, 2025

rp2/W5100S-EVB-PICO does not seem to send a hostname to DHCP server when getting address. #18024

Open

wiznet-grace closed this Sep 10, 2025

wiznet-grace reopened this Sep 10, 2025

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch 2 times, most recently from 3faaedd to c43f168 Compare September 10, 2025 08:39

This was referenced Sep 11, 2025

ports/rp2/boards: Add support for W55RP20-EVB-Pico and WIZNET_PIO_SPI communication. #16476

Closed

ports/rp2/boards: Add support for WIZnet-EVB-Pico2 #16280

Closed

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch from c43f168 to a4af5ef Compare September 15, 2025 00:21

MilhouseVH mentioned this pull request Sep 15, 2025

rp2: boards: Add W5100S-EVB-Pico2 board definition. #18064

Open

projectgus self-requested a review February 17, 2026 23:03

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch 2 times, most recently from 0821ce2 to 408ef41 Compare February 24, 2026 04:19

dpgeorge added this to the release-1.28.0 milestone Feb 25, 2026

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch from 408ef41 to e0768ba Compare March 11, 2026 05:35

dpgeorge modified the milestones: release-1.28.0, release-1.29.0 Mar 22, 2026

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch 2 times, most recently from 72b9ccb to b05f9a5 Compare June 18, 2026 04:45

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch 2 times, most recently from b799301 to 4671b80 Compare August 6, 2026 07:05

wiznet-grace requested a review from MilhouseVH August 6, 2026 07:15

rp2/boards: Add WIZnet EVB boards and wiznet6k submodule.

0db4474

Signed-off-by: wiznet-grace <Grace@wiznet.io>

wiznet-grace force-pushed the WIZnet-EVB-Pico-micropython branch from 4671b80 to 0db4474 Compare August 12, 2026 02:23

MilhouseVH approved these changes Aug 12, 2026

View reviewed changes

dpgeorge modified the milestones: release-1.29.0, release-1.30 Aug 13, 2026

projectgus reviewed Aug 26, 2026

View reviewed changes

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Uh oh!

Conversation

wiznet-grace commented Sep 4, 2025

Summary

Key Changes

Driver Code Size

File Structure

Testing

Trade-offs and Alternatives

Uh oh!

codecov Bot commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

github-actions Bot commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveSpencer commented Sep 9, 2025

Uh oh!

wiznet-grace commented Sep 10, 2025

Uh oh!

novaplusplus commented Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wiznet-grace commented Sep 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wiznet-grace commented Sep 15, 2025

Uh oh!

Lobo-T commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tofDE commented Feb 17, 2026

Uh oh!

wiznet-grace commented Feb 25, 2026

Uh oh!

wiznet-grace commented Mar 11, 2026

Uh oh!

wiznet-grace commented May 18, 2026

Uh oh!

wiznet-grace commented Jun 18, 2026

Uh oh!

MilhouseVH commented Jun 18, 2026

Uh oh!

wiznet-grace commented Aug 6, 2026

Uh oh!

MilhouseVH commented Aug 11, 2026

Uh oh!

wiznet-grace commented Aug 12, 2026

Uh oh!

MilhouseVH left a comment

Choose a reason for hiding this comment

Uh oh!

MilhouseVH commented Aug 24, 2026

Uh oh!

projectgus left a comment

Choose a reason for hiding this comment

Uh oh!

projectgus Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

projectgus Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

codecov Bot commented Sep 4, 2025 •

edited

Loading

github-actions Bot commented Sep 4, 2025 •

edited

Loading

novaplusplus commented Sep 12, 2025 •

edited

Loading

wiznet-grace commented Sep 15, 2025 •

edited

Loading

Lobo-T commented Feb 17, 2026 •

edited

Loading

projectgus Aug 26, 2026 •

edited

Loading

projectgus Aug 26, 2026 •

edited

Loading

projectgus Aug 26, 2026 •

edited

Loading