Trainiot SPI 2 DCC rev 1.3 PCB

KiCad

Så har jeg lavet mit første PCB layout. Generelt set er KiCad rimeligt let at bruge, men det lider under samme problemer som så meget open source software - det er nu engang langt sjovere for udviklerne at lave ny features i et development branch ind det er at få dem pudset af og inkluderet i et stabel release. Jeg kan ikke ligefrem sige at jeg bebrejder dem noget - jeg har det selv på samme måde - men det giver ikke ligefrem den bedste oplevelse når man bruger det. Jeg overvejer at skifte til development branch, men det er ikke noget jeg ville gøre få dage inden mit board røg til produktion.

For eksempel er de biblioteker der beskriver komponenterne ikke helt up-to-date. Jeg har godt nok læst at KiCad skulle kunne bruge bibliotekerne direkte fra github, men jeg fandt ikke nogen indstilling til det - der var eventuelt noget i en konfigurationsfil, men jeg vil lave PCB design - ikke rode i konfig filer, så det holdt jeg hurtigt op med at spilde min tid på.

Jeg brugt følgende komponent i mit skema - det er det shift register hvor kommandoen indlæses med SPI fra computeren:

Som jeg skrev tidligere har jeg kun et enkelt af disse shift registrer på mit breadboard - for hvor svært kan det være at forbinde flere? Man tager jo bare bit 7 (her med label QH) og smider den viddere til serial ind på den næste register. Det inverterede output på ben 9 har jeg ikke noget at bruge til, så den lader vi bare forblive uforbundet. Da jeg sad og lavede traces i mit layout begyndte jeg at undre mig lidt. De digitale outputs er fra et storage register - de skifter ikke værdi før min kommando er afsluttet. De bits der sendes videre mellem shift registrerne skal følge klokken på selve shift delen af chippen, ikke storage delen. Et hurtigt kig på et datasheet og jeg kunne rette fejlen så det nu ser sådan her ud:

ben 9 er ikke QH inverteret - det er derimod den bit der skal sendes videre til næste register - og datasheetet bruger lablen QH' for dette ben.

Det var let rettet, men man sidder jo og tænker på hvor mange andre fejl der er.

PCB layout

Mit PCB layout er lavet med 10mil trace bredde og afstand. 10 mil er 0.254mm. Producenterne kan godt klare 6/6 (og endnu mindre mod merbetaling), men jeg så flere steder anbefaling om at køre med lidt større værdier end minumum af to grunde. For det første giver det færre produktionsfejl, for det andet er det lettere at hacket et board hvis der mangler en forbindelse - man kan godt få en lille ledning loddet på.

Da der er 30 mil mellem de kobber "pads" mine IC'er skal loddes på, så 10/10 gør det muligt at køre et enkelt trace imellem benene. Jeg kunne få to imellem hvis jeg kørte 6/6, men det var ikke noget jeg fik brug for.

Jeg har valgt at kører min forsyningsstrøm (3v3) i breddere traces - 20mil til forsyning af mine komponenter, og 30mil hvor eksterne output forsynes (boostere og sensorer). Det er egentlig ikke nødvendigt da jeg ikke trækker meget strøm i mit kredsløb, men jeg har pladsen så det betyder ikke noget. Det gør det også lidt lettere for mig at få et overblik over min 3v3 net på mit PCB layout.

KiCad har funktionalitet der automatisk sikrer at nogle forbindelser bruger breddere traces - men jeg gav op da det kræver ændringer af diagrammet. For eksempel har jeg forbundet mine IC'rs power pin til VCC. Men jeg har også forbundet nogle data pins til VCC - og så bliver de lige pludselig også 20mil brede selv om de kun trækker 1mA eller mindre. Man kan indsætte dummy komponenter i diagrammet for at adskille disse, men den vej vil jeg ikke gå. Diagrammet skal ikke reflekterer mangler i mit PCB layout software hvis det kan undgås. Det betyder at KiCad ikke selv kan validerer jeg har sat bredden rigtig - men da 10mil egentlig er nok til alt det jeg laver betyder det ikke noget funktionelt hvis jeg har lavet en fejl.

Der er også en afrundingsfejl et eller andet sted i KiCad. Så hvis man router med 10/10 bredde/afstand, så finder den stadig fejl når man kører DRC (Design Rule Check). Jeg er langt fra de 6/6 krav producenten har, så det betyder ikke noget at jeg er en anelse under 10mil afstand nogle steder. Så jeg routede med 10mil clearing (0,254mm) men ændrede minimum til 0.253mm når jeg kørte DRC. Simpelt men ikke ligefrem elegant.

Uden ground planes (hvor ubenyttet plads på boardet bliver fyldt med kobber og forbundet til 0v/jord) ser mit board sådan her ud:

Det er 10x6.5cm. De to power decoupling kapacitorer i venstre side er stadig throughhole - man vinder ikke det store ved at bruge SMD på dem. Stik og status LED er også throughhole, resten er SMD. Der er et par "løse" vias (de hvide huller der forbinder de røde traces på forsiden med det grønne traces på bagsiden). De forbinder et ground plane på forsiden.

Egentlig havde jeg kun ground plane på bagsiden, og det er vist også det der anbefales efter hvad jeg har kunnet google mig til. Men, jeg har valgt at lave mine boards gule - det er en farve der ikke er så udbredt. Men så vidt jeg kan se fra billeder, ser den bedst ud ovenpå kobber. Og de problemer folk omtaler med ground planes på begge sider er kun noget man løber ind i med RF (radio) circuits og boards der kører flere hundrede megahertz. Så jeg lod fornuften gå fløjten og smed noget kobber på forsiden hvor det egentlig ikke er nødvendigt.

Forsiden ser nu sådan her ud:

Det er ikke et egentlig render - bare en SVG export (som det forrige) hvor jeg har ændret farverne så de minder lidt om de board der bliver produceret.

Bagsiden ser sådan her ud:

Open source hardware

Som det fremgår af bagsiden har jeg valgt at lave boarded open source og KiCad filerne er på på https://trainiot.github.io/. Jeg regner ikke med at der er den store efterspørgsel efter dette kredsløb da der jo er langt lettere måder at generere et DCC signal - men hvem ved, måske dele af det eller noget jeg laver senere kan bruges af en eller anden.

Jeg regner med at tilføje noget dokumentation af kredsløbet på github - når jeg får tid og lyst. Så i fremtiden vil det meste af den "tørre" dokumentation af mit hard- og software nok være at finde på github, og denne blog vil så indeholde mere generelle kommentarer og naturligvis en mere kronologist oversigt om hvad jeg laver.