[DNM] zephyrCommon: Changing pin numbering rules #134

soburi · 2025-08-23T07:47:46Z

Zephyr's ba48d83b
changes make it easy to configure pin numbering at compile,
so we'll change the pin numbers to be based on the GPIO pin numbers.

This is same as the traditional Arduino, using the GPIO numbers as
pin numbers. Pin names written on the board, such as D1 and D2,
are aliases for these pin numbers.

When using multiple GPIO ports, pin numbers are numbered consecutively
from the beginning. For example, if you have two 16-port GPIOs,
16 refers to the first pin (idx=0) of the second port.

pillo79 · 2025-09-25T12:52:36Z

Just chiming in for the Arduino side to say, please don't drop custom pin numbering.

The technical implementation is great 👍 and it removes the need for bulky pin lists 💛, but AFAICS also makes it "impossible" to assign specific numbers to pins, and this is something that is really important for backwards compatibility with traditional Arduino sketches.

[ OTOH, I do hate having to write those lists; tried several alternative DTS mappings myself but haven't yet found one that is flexible enough and/or enough of an improvement... 🙁 ]

soburi · 2025-09-25T13:24:32Z

Just chiming in for the Arduino side to say, please don't drop custom pin numbering.

The technical implementation is great 👍 and it removes the need for bulky pin lists 💛, but AFAICS also makes it "impossible" to assign specific numbers to pins, and this is something that is really important for backwards compatibility with traditional Arduino sketches.

[ OTOH, I do hate having to write those lists; tried several alternative DTS mappings myself but haven't yet found one that is flexible enough and/or enough of an improvement... 🙁 ]

The main purpose of this change is to make pins that are not exposed on the connector usable.
The pin change itself is necessary to deal with edge cases, so it needs to remain.
My current idea is to use the zephyrproject-rtos/zephyr#87595 change to extract pin information from the gpio-nexus node that is labeled as arduino_header.
With this method, as long as the connector is defined on the devicetree, I think it will be possible to make it behave like an "Arduino" without writing any additional config. For edge cases that still cannot be solved, I think we'll have to deal with them with the current settings, but some consideration may be needed to find the best way to handle them.

By the way, zephyrproject-rtos/zephyr#87595 is stalled because only a few people reviewed it.
If you can review this part, please help with this PR review.

soburi · 2025-09-27T03:58:54Z

@pillo79

The technical implementation is great 👍 and it removes the need for bulky pin lists 💛, but AFAICS also makes it "impossible" to assign specific numbers to pins, and this is something that is really important for backwards compatibility with traditional Arduino sketches.

Does this mean you want to freely map the direct values passed to digitalOut?

I understand that traditionally, Arduino's D1-based values were logical pin numbers,
while values like digitalOut argument were physical pin numbers (i.e., implementation-dependent).

Until now, the gsoc-2022-arduino-core implementation has assumed logical = physical due to various constraints. (i.e., D0 = 0, D1 = 1)

In this implementation, only mapped pins are usable, so the intention of this PR is to introduce physical pin numbers to handle all pins on the board.

If the answer to the initial question is yes, I think this can be addressed by adding one more LUT.

DhruvaG2000

I have seen the PR, and have some catching up to do on the new zephyr commit that has been mentioned. I will need some more time to actually go through since this seems to have a large impact overall. Please excuse the delay!

DhruvaG2000 · 2025-09-29T18:42:50Z

cores/arduino/zephyrCommon.cpp

-  return sum_of_list(sum + head, tail...);
+constexpr inline size_t port_index_r(const struct device *target,
+                                     const struct device *const *table, pin_size_t idx, size_t n) {
+  return (n == 0)               ? size_t(-1)


Is it me or is the alignment really messed up on this one?

DhruvaG2000

@Ayush1325 if possible can you test for any regressions on the Beagleconnect freedom?
I am ok with the general idea here, and it does seem like an improvement for handling gpio ports.
Just need to be careful about the code though, and hence giving some comments from maintenance and debugging perspective.

cores/arduino/Arduino.h

cores/arduino/zephyrCommon.cpp

DhruvaG2000 · 2025-10-09T08:45:43Z

I'll merge this as soon as I am done fixing the CI failures. Please excuse the delay

Ayush1325 · 2025-10-11T10:57:09Z

@Ayush1325 if possible can you test for any regressions on the Beagleconnect freedom? I am ok with the general idea here, and it does seem like an improvement for handling gpio ports. Just need to be careful about the code though, and hence giving some comments from maintenance and debugging perspective.

Apologies for the late reply. Seems to be working fine on bcf.

pillo79 · 2025-10-12T14:43:03Z

@soburi, apologies for getting back so late, was derailed by the linked PR and most importantly all of this week's chaos. 😅

Does this mean you want to freely map the direct values passed to digitalOut?

I understand that traditionally, Arduino's D1-based values were logical pin numbers, while values like digitalOut argument were physical pin numbers (i.e., implementation-dependent).

In fact, and very unfortunately, the "official" way of referring to pins is by number. Some cores don't even define Dx symbols; all samples use integers to access pins, so do 99% of sketches out there... for existing boards, numbers are the standard we need to maintain compatibility with.

In [the current] implementation, only mapped pins are usable, so the intention of this PR is to introduce physical pin numbers to handle all pins on the board.

Understood; with this change you assign a number for any "GPIO bit" (even if unconnected or not even exposed by the SOC!), and then map Dx=x.

If the answer to the initial question is yes, I think this can be addressed by adding one more LUT.

My issue with a LUT is that it will create two sets of indistinguishable integers : the "logical" ones (inputs to the LUT) and the "physical" ones (after the LUT is applied).

Now, 🥁, when a sketch then calls digitalWrite(4, HIGH), does 4 refer to a logical or physical pin?
Surely it must be logical (otherwise, what's the point of the LUT?), but it must also be physical (otherwise, the objective of this PR is broken!). ❓ 🫤

We have been bitten HARD by this with the Arduino Nano ESP32 - the GPIO controller there already uses numbers, but we need to map them to keep "standard Nano" pin layout. We added a LUT so that APIs would input logical and address physical. Chaos ensued, and 2 years later this is still a raw topic on the Arduino Forums.

(brainstorming)

There MAY be a way out. The default index pin type pin_size_t is 8-bit unsigned, and very few targets exceed that (but we do have a 32-bit option by defining EXTENDED_PIN_MODE). What if you enabled that and made your physical mapping in some high enough range? Numbers below, say, 32k would be logical, the others physical.

All APIs with pin numbers would accept an uint32_t and, if it's logical, apply the LUT to get a physical index.
As long as you use int or the more correct pin_size_t to store a pin number, you have no problems.
Existing sketches that use uint8_t work fine on existing boards, because numbers < 256 are definitely logical and thus mapped by the LUT.
The only issue is if you want to use an existing sketch on previously unmapped physical pins, but then you're breaking new ground, might as well fix the sketch.

(all of this needs a constant LUT, probably magically generated from the DT in some way. Would the recent maps help?)

Let me know what you guys think!

soburi · 2025-10-18T01:28:50Z

@pillo79

Sorry for my late response.

@soburi, apologies for getting back so late, was derailed by the linked PR and most importantly all of this week's chaos. 😅

I know it was a difficult situation. You must be tired.

In fact, and very unfortunately, the "official" way of referring to pins is by number. Some cores don't even define Dx symbols; all samples use integers to access pins, so do 99% of sketches out there... for existing boards, numbers are the standard we need to maintain compatibility with.

I understood what that means is "all is device dependent'.
And there is a requirement to make it compatible with it.

My issue with a LUT is that it will create two sets of indistinguishable integers : the "logical" ones (inputs to the LUT) and the "physical" ones (after the LUT is applied).

Now, 🥁, when a sketch then calls digitalWrite(4, HIGH), does 4 refer to a logical or physical pin? Surely it must be logical (otherwise, what's the point of the LUT?), but it must also be physical (otherwise, the objective of this PR is broken!). ❓ 🫤

In my opinion, they are distinct clearly.

First, there is a need to clarify the terminology.

physical pin number: The number statically derived from the hardware configuration. The 'serialized GPIO pin number' in the my proposal can be derived from the GPIO port and the pin number, so it is a type of "physical pin number".

Logical Pin Number = The number defined by the rule.
Usually, that is ruled by the API specification.
(It is not required in the term definition, but) and it is expected to map to the physical pin number without contradiction.
Of course, "use as is" rule can also be applied in this context.

digitalWrite() (And all other APIs) must take a logical pin number.
The physical pin number is derived via LUT from the logical pin number.
In other words, the physical pin number is just an internal representation. and the logical pin number is an alias for it.
All API must use the logical pin numbering system.

If we keep this principle, it will not cause a serious problem.

We have been bitten HARD by this with the Arduino Nano ESP32 - the GPIO controller there already uses numbers, but we need to map them to keep "standard Nano" pin layout. We added a LUT so that APIs would input logical and address physical. Chaos ensued, and 2 years later this is still a raw topic on the Arduino Forums.

I couldn't understand the details, I need to check a little more carefully.
But as far as I understood,
This seems to be a problem caused by two different numbering systems existing concurrently.

The API numbering system should always be based on a single rule.

This is the principal.

In situations where this rule is not followed, individual, topical　handling should be taken.

On that basis,

It is possible to create comprehensive pin mapping.

(brainstorming)

There MAY be a way out. The default index pin type pin_size_t is 8-bit unsigned, and very few targets exceed that (but we do have a 32-bit option by defining EXTENDED_PIN_MODE). What if you enabled that and made your physical mapping in some high enough range? Numbers below, say, 32k would be logical, the others physical.

Zephyr's pin numbers are specified in 32 bits, so I don't think there's any problem with this policy.
I also think it's a good idea to make EXTENDED_PIN_MODE the default.

Zephyr's ba48d83b changes make it easy to configure pin numbering at compile, so we'll change the pin numbers to be based on the GPIO pin numbers. This is same as the traditional Arduino, using the GPIO numbers as pin numbers. Pin names written on the board, such as D1 and D2, are aliases for these pin numbers. When using multiple GPIO ports, pin numbers are numbered consecutively from the beginning. For example, if you have two 16-port GPIOs, 16 refers to the first pin (idx=0) of the second port. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Now that GPIO can be specified generically, we will discontinue the definition generation of LED_BUILTIN from builtin_led_gpios. Delete this definition where automatic generation from led0 is not an issue, and define it in variant.h in all other cases. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Copilot

Pull request overview

This PR refactors the pin numbering system in the Zephyr Arduino core to align with recent Zephyr upstream changes. The new approach uses GPIO pin numbers directly as Arduino pin numbers, similar to traditional Arduino. Pin aliases (like D1, D2) now reference these GPIO-based pin numbers instead of using a separate indexing scheme.

Key Changes:

Replaced the builtin-led-gpios devicetree property with variant-specific LED_BUILTIN definitions using pin aliases (e.g., D13)
Added gpio-ports property to overlay files to specify which GPIO ports are used for pin numbering
Refactored pin lookup logic from devicetree-based arrays to compile-time calculations based on GPIO port offsets

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 14 comments.

Show a summary per file

File	Description
variants//.overlay	Added `gpio-ports` property and removed `builtin-led-gpios` property for each board variant
variants/cc3220sf_launchxl_cc3220sf/variant.h	Updated LED definitions to use pin aliases (D4, D3, D19) instead of numeric constants
variants/arduino_nano_33_ble_*/variant.h	Added `LED_BUILTIN` definition using D13 alias
cores/arduino/zephyrCommon.cpp	Completely refactored GPIO pin mapping from array lookups to constexpr functions that calculate port/pin from GPIO numbering
cores/arduino/Arduino.h	Refactored macro definitions for pin enumerations and LED_BUILTIN to work with new GPIO-based numbering scheme
documentation/variants.md	Updated documentation to describe new `gpio-ports` configuration and LED_BUILTIN behavior

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-12-19T14:26:51Z

documentation/variants.md

+
+The `gpios` node lists the GPIO ports to use.
+Pin numbers will be assigned sequentially starting from 0 to the GPIOs of the ports specified here.
+For example, if gpio0 and gpio1, each with 16 outputs, are specified, pin 1 of gpio1 will be assigned 17.


The example code shows pin 1 of gpio1 being assigned pin number 17, but the description states it should be 16. If gpio0 has pins 0-15 (16 pins total), then the first pin (idx=0) of gpio1 would be pin 16, not 17. Please update either the example or the explanation for consistency.

Suggested change

For example, if gpio0 and gpio1, each with 16 outputs, are specified, pin 1 of gpio1 will be assigned 17.

For example, if gpio0 and gpio1, each with 16 outputs, are specified, pin 0 of gpio1 will be assigned 16.

Copilot · 2025-12-19T14:26:52Z

cores/arduino/zephyrCommon.cpp

+}
+
+constexpr inline pin_size_t global_gpio_pin_(size_t port_idx, pin_size_t lpin) {
+  return port_idx == size_t(-1) ? size_t(-1) : end_accum(port_idx) + lpin;


In the global_gpio_pin_ function, the return type is pin_size_t but it returns size_t(-1) on error. This is inconsistent with the function signature and could cause issues. Either change the error value to pin_size_t(-1) or update the return type to size_t.

Suggested change

return port_idx == size_t(-1) ? size_t(-1) : end_accum(port_idx) + lpin;

return port_idx == size_t(-1) ? pin_size_t(-1) : end_accum(port_idx) + lpin;

Copilot · 2025-12-19T14:26:52Z

cores/arduino/zephyrCommon.cpp

+    gpio_pin_set(local_gpio_port(pt->pin), local_gpio_pin(pt->pin), 0);
  } else {
-    gpio_pin_toggle_dt(spec);
+    gpio_pin_toggle(local_gpio_port(pt->pin), local_gpio_pin(pt->pin));


Missing error handling. These function calls don't check if local_gpio_port(pinNumber) returns nullptr before dereferencing, which could lead to crashes if an invalid pin number is provided.

Copilot · 2025-12-19T14:26:52Z

cores/arduino/zephyrCommon.cpp

 unsigned long pulseIn(pin_size_t pinNumber, uint8_t state, unsigned long timeout) {
+  const struct device* port = local_gpio_port(pinNumber);
+  const size_t pin = local_gpio_pin(pinNumber);
  struct k_timer timer;
  int64_t start, end, delta = 0;
-  const struct gpio_dt_spec *spec = &arduino_pins[pinNumber];

-  if (!gpio_is_ready_dt(spec)) {
+  if (!device_is_ready(port)) {
    return 0;
  }

  k_timer_init(&timer, NULL, NULL);
  k_timer_start(&timer, K_MSEC(timeout), K_NO_WAIT);

-  while(gpio_pin_get_dt(spec) == state && k_timer_status_get(&timer) == 0);
+  while (gpio_pin_get(port, pin) == state && k_timer_status_get(&timer) == 0);
  if (k_timer_status_get(&timer) > 0) {
    goto cleanup;
  }

-  while(gpio_pin_get_dt(spec) != state && k_timer_status_get(&timer) == 0);
+  while (gpio_pin_get(port, pin) != state && k_timer_status_get(&timer) == 0);
  if (k_timer_status_get(&timer) > 0) {
    goto cleanup;
  }

  start = k_uptime_ticks();
-  while(gpio_pin_get_dt(spec) == state && k_timer_status_get(&timer) == 0);
+  while (gpio_pin_get(port, pin) == state && k_timer_status_get(&timer) == 0);
  if (k_timer_status_get(&timer) > 0) {
    goto cleanup;
  }


Missing error handling. The port variable is obtained from local_gpio_port(pinNumber) which could return nullptr. While there's a device_is_ready check, if port is nullptr, this would still cause undefined behavior.

Copilot · 2025-12-19T14:26:53Z

cores/arduino/zephyrCommon.cpp

 void enableInterrupt(pin_size_t pinNumber) {
-  struct gpio_port_callback *pcb = find_gpio_port_callback(arduino_pins[pinNumber].port);
+  struct gpio_port_callback *pcb = find_gpio_port_callback(local_gpio_port(pinNumber));

  if (pcb) {
-    pcb->handlers[arduino_pins[pinNumber].pin].enabled = true;
+    pcb->handlers[local_gpio_pin(pinNumber)].enabled = true;
  }
 }

 void disableInterrupt(pin_size_t pinNumber) {
-  struct gpio_port_callback *pcb = find_gpio_port_callback(arduino_pins[pinNumber].port);
+  struct gpio_port_callback *pcb = find_gpio_port_callback(local_gpio_port(pinNumber));

  if (pcb) {
-    pcb->handlers[arduino_pins[pinNumber].pin].enabled = false;
+    pcb->handlers[local_gpio_pin(pinNumber)].enabled = false;
  }


Missing error handling. local_gpio_port(pinNumber) could return nullptr, which would cause issues when passed to find_gpio_port_callback.

Copilot · 2025-12-19T14:26:54Z

documentation/variants.md

+The `gpios` node lists the GPIO ports to use.
+Pin numbers will be assigned sequentially starting from 0 to the GPIOs of the ports specified here.
+For example, if gpio0 and gpio1, each with 16 outputs, are specified, pin 1 of gpio1 will be assigned 17.
+
+```
+/ {
+       zephyr,user {
+               gpios = <&gpio0>, <&gpio1>;
+       };
+};
+```


The documentation mentions a node named gpios, but the actual overlay files use gpio-ports. The documentation should use the correct property name gpio-ports to match the implementation.

Copilot · 2025-12-19T14:26:54Z

cores/arduino/zephyrCommon.cpp

+constexpr inline const struct device *local_gpio_port_r(pin_size_t pin,
+                                                        const struct device *const *ctrl,
+                                                        const uint32_t accum,
+							const uint32_t *end, size_t n) {


Inconsistent spacing in function parameters. The parameter list has inconsistent tab/space alignment. The third parameter starts at a different column than the others, making the code harder to read.

Suggested change

const uint32_t *end, size_t n) {

const uint32_t *end, size_t n) {

Copilot · 2025-12-19T14:26:54Z

cores/arduino/zephyrCommon.cpp

 void pinMode(pin_size_t pinNumber, PinMode pinMode) {
-  if (pinMode == INPUT) { // input mode
-    gpio_pin_configure_dt(&arduino_pins[pinNumber],
-                          GPIO_INPUT | GPIO_ACTIVE_HIGH);
-  } else if (pinMode == INPUT_PULLUP) { // input with internal pull-up
-    gpio_pin_configure_dt(&arduino_pins[pinNumber],
-                          GPIO_INPUT | GPIO_PULL_UP | GPIO_ACTIVE_HIGH);
-  } else if (pinMode == INPUT_PULLDOWN) { // input with internal pull-down
-    gpio_pin_configure_dt(&arduino_pins[pinNumber],
-                          GPIO_INPUT | GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH);
-  } else if (pinMode == OUTPUT) { // output mode
-    gpio_pin_configure_dt(&arduino_pins[pinNumber],
-                          GPIO_OUTPUT_LOW | GPIO_ACTIVE_HIGH);
+  if (pinMode == INPUT) {
+    global_gpio_pin_configure(pinNumber, GPIO_INPUT | GPIO_ACTIVE_HIGH);
+  } else if (pinMode == INPUT_PULLUP) {
+    global_gpio_pin_configure(pinNumber, GPIO_INPUT | GPIO_PULL_UP | GPIO_ACTIVE_HIGH);
+  } else if (pinMode == INPUT_PULLDOWN) {
+    global_gpio_pin_configure(pinNumber, GPIO_INPUT | GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH);
+  } else if (pinMode == OUTPUT) {
+    global_gpio_pin_configure(pinNumber, GPIO_OUTPUT_LOW | GPIO_ACTIVE_HIGH);
  }


Missing error handling. The functions local_gpio_port, local_gpio_pin, and global_gpio_pin_configure can return error values (nullptr or -1), but they are used without checking the return value. This could lead to dereferencing a null pointer or operating on an invalid pin number when an invalid pin is provided.

Copilot · 2025-12-19T14:26:54Z

cores/arduino/zephyrCommon.cpp

+  pcb = find_gpio_port_callback(local_gpio_port(pinNumber));
  __ASSERT(pcb != nullptr, "gpio_port_callback not found");

-  pcb->pins |= BIT(arduino_pins[pinNumber].pin);
+  pcb->pins |= BIT(local_gpio_pin(pinNumber));
  setInterruptHandler(pinNumber, callback);
  enableInterrupt(pinNumber);

-  gpio_pin_interrupt_configure(arduino_pins[pinNumber].port, arduino_pins[pinNumber].pin, intmode);
+  gpio_pin_interrupt_configure(local_gpio_port(pinNumber), local_gpio_pin(pinNumber), intmode);
  gpio_init_callback(&pcb->callback, handleGpioCallback, pcb->pins);
-  gpio_add_callback(arduino_pins[pinNumber].port, &pcb->callback);
+  gpio_add_callback(local_gpio_port(pinNumber), &pcb->callback);


Missing error handling. local_gpio_port(pinNumber) could return nullptr, which would cause undefined behavior when passed to GPIO functions.

Copilot · 2025-12-19T14:26:55Z

cores/arduino/zephyrCommon.cpp

 int digitalPinToInterrupt(pin_size_t pin) {
  struct gpio_port_callback *pcb =
-      find_gpio_port_callback(arduino_pins[pin].port);
+      find_gpio_port_callback(local_gpio_port(pin));

  return (pcb) ? pin : -1;
 }


Missing error handling. local_gpio_port(pin) could return nullptr, which would cause issues in find_gpio_port_callback.

soburi force-pushed the global_pin_number branch from 93e11fa to 084197c Compare August 23, 2025 11:50

soburi requested review from DhruvaG2000, beriberikix and szczys as code owners August 23, 2025 11:50

soburi force-pushed the global_pin_number branch 2 times, most recently from 0747e08 to 014a6ed Compare August 23, 2025 22:46

soburi changed the title ~~zephyrCommon: Changing pin numbering rules~~ [DNM] zephyrCommon: Changing pin numbering rules Aug 23, 2025

soburi force-pushed the global_pin_number branch 4 times, most recently from 7ca4da5 to b009050 Compare August 30, 2025 13:18

soburi force-pushed the global_pin_number branch 2 times, most recently from 26d967e to bb1ef24 Compare September 10, 2025 07:31

soburi force-pushed the global_pin_number branch from bb1ef24 to e8dced1 Compare September 24, 2025 23:31

soburi force-pushed the global_pin_number branch from e8dced1 to 199421c Compare September 27, 2025 02:21

soburi changed the title ~~[DNM] zephyrCommon: Changing pin numbering rules~~ zephyrCommon: Changing pin numbering rules Sep 27, 2025

soburi force-pushed the global_pin_number branch from 199421c to 934a931 Compare September 27, 2025 03:16

DhruvaG2000 reviewed Sep 29, 2025

View reviewed changes

DhruvaG2000 requested changes Oct 6, 2025

View reviewed changes

cores/arduino/Arduino.h Show resolved Hide resolved

cores/arduino/zephyrCommon.cpp Show resolved Hide resolved

cores/arduino/zephyrCommon.cpp Show resolved Hide resolved

DhruvaG2000 approved these changes Oct 8, 2025

View reviewed changes

DhruvaG2000 force-pushed the global_pin_number branch from 934a931 to 4abaf6a Compare October 14, 2025 05:44

soburi added the DNM This PR should not be merged (Do Not Merge) label Oct 14, 2025

soburi changed the title ~~zephyrCommon: Changing pin numbering rules~~ [DNM] zephyrCommon: Changing pin numbering rules Oct 14, 2025

soburi added 2 commits December 19, 2025 23:21

Copilot AI review requested due to automatic review settings December 19, 2025 14:21

soburi force-pushed the global_pin_number branch from 4abaf6a to e9c47e4 Compare December 19, 2025 14:21

Copilot started reviewing on behalf of soburi December 19, 2025 14:22 View session

Copilot AI reviewed Dec 19, 2025

View reviewed changes

	For example, if gpio0 and gpio1, each with 16 outputs, are specified, pin 1 of gpio1 will be assigned 17.
	For example, if gpio0 and gpio1, each with 16 outputs, are specified, pin 0 of gpio1 will be assigned 16.

	return port_idx == size_t(-1) ? size_t(-1) : end_accum(port_idx) + lpin;
	return port_idx == size_t(-1) ? pin_size_t(-1) : end_accum(port_idx) + lpin;

	const uint32_t *end, size_t n) {
	const uint32_t *end, size_t n) {

[DNM] zephyrCommon: Changing pin numbering rules #134

Are you sure you want to change the base?

[DNM] zephyrCommon: Changing pin numbering rules #134

Uh oh!

Conversation

soburi commented Aug 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pillo79 commented Sep 25, 2025

Uh oh!

soburi commented Sep 25, 2025

Uh oh!

soburi commented Sep 27, 2025

Uh oh!

DhruvaG2000 left a comment

Choose a reason for hiding this comment

Uh oh!

DhruvaG2000 Sep 29, 2025

Choose a reason for hiding this comment

Uh oh!

DhruvaG2000 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

DhruvaG2000 commented Oct 9, 2025

Uh oh!

Ayush1325 commented Oct 11, 2025

Uh oh!

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

Uh oh!

Uh oh!

soburi commented Oct 18, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

soburi commented Aug 23, 2025 •

edited

Loading

pillo79 commented Oct 12, 2025 •

edited

Loading