I2C bus occupancy: read on-board chip address strapping and confirm segment topology; resolve Haar 0x48 and Walrus 0x57 clashes
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 42/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- embedded-iot
Direzione di ricerca
Start by reading the Okapi v1.0 schematic files under Hardware/KiCAD-10import and the NW-Device-Specification Bus occupancy table. Record the address strapping for each listed chip, verify whether the on-board and sensor segments are joined when the external bus is enabled, and document the resulting addresses and resolutions for the Haar and Walrus clashes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
The NW-Device-Specification address registry now carries a bus-occupancy table covering NW devices, the loggers' on-board chips, and chips driven by sensor libraries on the controller bus (registry → Bus occupancy). Several Okapi v1.0 on-board chips set their address by pin strapping, and the strapping has not been read from the schematic, so two potential clashes cannot yet be confirmed or cleared.
To do
- Read the address strapping from the Okapi v1.0 schematic (
Hardware/KiCAD-10import) for: ADS1115 (both), VEML6030, PAC1934, MB85RC FRAM, BMA456, MLX90393. - Confirm the I²C segment topology: is the on-board segment electrically joined to the sensor segment when the external bus is switched on (via the TCA9406 level shifters / the segment switch)? If the segments are always isolated, on-board addresses cannot clash with sensor addresses and the table only needs to say so.
- Fill the strapped addresses into the spec's bus-occupancy table.
- Resolve the two potential clashes, preferring to restrap the Okapi chip since Okapi is a prototype under revision:
- Haar
0x48vs the on-board ADS1115 at0x48(and VEML6030 if strapped high). - Walrus
0x57vs the MB85RC FRAM range0x50–0x57.
- Haar
Why now
Sensor addresses are moving to their Schema 1 values (Apis → 0x41, Haar → 0x48, Walrus → 0x57) as each firmware is converted; this check should land before those addresses are burned into provisioned boards.
🤖 Generated with Claude Code
- Lingua principale
- G-code
- Stelle
- 8
- Fork
- 2
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NorthernWidget/Project-Okapi
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
IC1 AREF tied directly to AVCC (5V_AUX) with no bypass cap — internal reference conflict riskApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
bug
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Tutte le issue di NorthernWidget/Project-Okapi
Issue simili
-
tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
prestonbrown/helixscreen#1885 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 71/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
logicog/RTLPlayground#699 ·
I maintainer di solito rispondono entro 1 giorno
-
Status: Opened
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno