[Bug] Kernel-managed CS pins cause GPIO conflict when running alongside other SPI processes — fixed in feat/newRadios

[mattster98]

Environment

Hardware: Nebra Duo Hat (dual radio — E22P-915M30S SX1262 + E80-900M2213S LR1121)
OS: Raspberry Pi OS Bookworm 64-bit
pymc_core: v1.0.7
Running alongside: meshtasticd (also uses SPI bus)

Bug
With dtoverlay=spi0-2cs (required to expose both spidev0.0 and spidev0.1), pymcrepeater fails on startup:

FATAL: GPIO Pin 8 is already in use
[Errno 16] Opening output line handle: Device or resource busy

The root cause is in setSpi() in SX126x.py — it hardcodes _cs_define = 8 for CE0 and _cs_define = 7 for CE1. This causes _get_output(_cs_define) to attempt gpiochip ownership of those pins. However under spi0-2cs the kernel already owns them, making it impossible for any second process to claim them.

Fix confirmed in feat/newRadios
The feat/newRadios branch defaults _cs_define = -1 (kernel-managed) and skips all CS GPIO toggling in _writeBytes/_readBytes when _cs_define == -1. This is the correct behavior — spidev handles CS automatically.
Tested with this config:

sx1262:
  bus_id: 0
  cs_id: 0
  cs_pin: -1
  busy_pin: 23
  irq_pin: 24
  reset_pin: 22
  use_dio3_tcxo: true
  use_dio2_rf: true

Result with feat/newRadios:

SX1262 radio initialized successfully
TX 110 bytes (type=ADVERT, route=FLOOD)
Parsed advert: KD4HME-Tower (Repeater)
Retransmitted packet (124 bytes, 428.5ms airtime)

Full TX/RX working on a live MeshCore network with meshtasticd running simultaneously on the same SPI bus.

Would be great to see feat/newRadios merged to unblock this use case. Thank you!

[rightup]

I believe this has been fix already in the new radios branch. Thanks

[mattster98]

Correct. This is just a petition to roll it into main.