Zelfgemaakt BiDiB modules

[Dennis1984]

Ha,

Begin dit jaar ging ik proberen een van de bestaande OpenDCC BiDiB-decoders te "resizen" naar een printplaatje van 5 bij 8 cm, omdat ik dat een handig formaat vindt en heb besloten dat formaat printplaten op mijn modules te gaan gebruiken (ruimte is daar beperkt met het idee wat ik heb).

Dat project slaagde op zich, maar ik bleef tegen die sterk verouderde Atxmega's aan lopen die op die printplaten gebruikt worden. Die bovendien ontzettend duur zijn bij JLCPCB.

Lang verhaal kort heb ik toen besloten zelf maar wat BiDiB-decoders te gaan ontwerpen from scratch. Na wat maandjes denkwerk, wat maandjes tekenen en al die tijd learning on the job (ook via tientallen YouTube-video's) heb ik inmiddels een vijftal printplaten gereed: een BiDiB-interface (met USB-PD aansluiting), een BiDiB-RailCom 16-voudige feedbackmodule, een BiDiB PowerBoard om op elke module de stroom te verdelen, een 8-voudige BiDiB servodecoder en tot slot een 32-voudige BiDiB leddecoder. Nog een aantal ontwerpen ben ik een heel eind mee op weg. Eerlijk is eerlijk: ik heb af en toe ook een AI-hulplijn ingeschakeld .

Alle modules zijn op dezelfde manier opgezet: zelfde formaat, zoveel mogelijk hergebruik van componenten over de verschillende printplaten, duidelijke statusindicatoren van voeding en systeem met leds, omzetten van spanningen in principe met bucks en gebruik van moderne chips. Dat laatste vind ik stiekem ook wel een leuk aspect: lekker ontdekken wat voor mooie chips er wel niet allemaal te vinden zijn op internet. De centrale microcontroller is steeds een STM32C091. Alleen bij de feedback-module ben ik daarvan afgeweken want daar moet ik 16 ADC-kanalen hebben en dan moet je uitwijken naar de STM32F3 of G4 (ik heb de laatste gekozen).

Ook goed om te weten: doel van de printplaten waar iets op aangesloten is is om er steeds een 'hat' op te plaatsen waar soldeerpads op komen. Ik ga draden dus niet vastschroeven maar het idee is dat je heel makkelijk de boel kunt solderen op de hat. Lekker solide. De printplaten komen ook niet aan de onderkant van de modules te hangen, maar plaats ik aan de achterkant zodat je er eenvoudig bij kunt en ook direct aan de lampjes kunt zien of alles goed werkt.

De 32-voudige leddecoder wil ik binnenkort laten fabriceren in China. Zelf solderen is met de kleine componenten die ik heb gekozen in principe niet meer mogelijk. De laatste missende componenten heb ik net besteld en komen ergens begin december binnen. En ik dacht: misschien vindt iemand het leuk om nog even een laatste blik mee te kijken of ik nog ergens een domme fout gemaakt heb. Ik doe deze als eerste omdat hij het simpelst is (en daarom ook het goedkoopst) en er veel ruimte is om een groot aantal testpads te plaatsen, zodat ik bij het schrijven van de software (ergens volgend jaar beginnen) makkelijk kan debuggen.

Plaatjes:





PDF van het schema hier: klik
PDF van de printplaat (alle 4 koperlagen en fab) hier: klik

Elke tip, suggestie of verbetering is welkom. Als ik nog iets moet toelichten: vraag het vooral.

Met vriendelijke groet,
Dennis

[Albert de Heer]

Ook goed om te weten: doel van de printplaten waar iets op aangesloten is is om er steeds een 'hat' op te plaatsen waar soldeerpads op komen. Ik ga draden dus niet vastschroeven maar het idee is dat je heel makkelijk de boel kunt solderen op de hat. Lekker solide. De printplaten komen ook niet aan de onderkant van de modules te hangen, maar plaats ik aan de achterkant zodat je er eenvoudig bij kunt en ook direct aan de lampjes kunt zien of alles goed werkt.

Ik ben heel benieuwd hoe dat solderen van draden op de print je gaat bevallen.

Printplaten aan de onderkant van een module heb ik inmiddels ook als "absoluut niet handig" bestempeld. Leds op een printplaat die van alles aangeven is wel weer superhandig 

[Dennis1984]

Inderdaad Albert. Ik zie het bij ons op de club: het is een crime om overal bij te kunnen. Wat je wil is gewoon alles eenvoudig toegankelijk aan de achterzijde. Maar ruimte aan de achterkant is doorgaans wel meer beperkt en vandaar dus mijn drive om alles zo klein mogelijk te maken.

Met vriendelijke groet,
Dennis

[Klaas Zondervan]

Als ruimte aan de achterkant beperkt is, waarom dan niet aan de voorkant?

[Dennis1984]

Omdat aan de voorkant helemaal geen ruimte is . Het gaat om modulebakken en de voorkant moet er mooi uitzien zonder elektronica.

Met vriendelijke groet,
Dennis

[AP3737]

Hi Dennis

Ziet er heel mooi uit. Het enige dat ik zou kunnen opmerken, is dat je geen beveiliging hebt / lijkt te hebben voor het geval de polarisatie verkeerd wordt aangesloten.

Het ziet er echt mooi uit. Redelijk wat originele / nieuwe componenten, die ik niet vaak elders zie. Je bent niet bang wat nieuws te proberen. Daar houd ik van 

Ik denk dat de software best wel een uitdaging gaat worden. Je gebruikt daarvoor Cube van STM? En  neem je, net als OpenDCC/Bidib, een RTOS? Of worden het makkelijk herbruikbare Arduino libraries? Het zou mooi zijn als er zoiets komt.

Leuk!
Aiko

[Dennis1984]

Ha Aiko,

Dank voor je feedback. De reverse polarity protection heb ik wel op de printplaat zitten in de eFuse waar de stroom op binnenkomt. De 'unieke' componenten word ik een beetje toe gedwongen omdat ik het allemaal zo klein wil maken .

Voor wat betreft de software: ik weet nog niet of ik dat in STM32Cube ga maken of op een of andere manier in Visual Studio Code. Ik neig naar deze laatste, omdat er veel betere support in zit voor AI. Maar ik vind het opzetten van het een en ander wel ingewikkelder dan met Atmel Studio. Een RTOS ben ik niet van plan te gebruiken, ik wil eigenlijk gewoon native C libraries maken en dat aan elkaar knutselen.

Mij lijkt het inderdaad handig als er een goede BiDiB library komt. Ik zag laatst nog ergens iets van een universiteit waar ze een modern protocol zochten voor modelspoor. BiDiB kwam langs in hun analyse van geschikte protocollen, maar ze gingen het niet gebruiken omdat er geen goede vrije implementaties waren. Gemiste kans.

Ik kwam trouwens nog een klein foutje tegen: ik heb de PCA9685 chips gekloond in het schema maar ben nog vergeten het I2C adres aan te passen bij de tweede chip. Dat moet ik nog even fixen.

Met vriendelijke groet,
Dennis

[AP3737]

Hi Dennis

Ja, klopt. Ik zat even te kijken naar een MOSFET, maar je hebt de TPS25947. Een mooi voorbeeld van wat ik eerder schreef over je keuze voor nieuwe type componenten. Vooral de inrush protectie van de TPS25947 lijkt me interessant. Misschien dat ik die ook maar moet gaan gebruiken in volgende schakelingen.

Als je in VS code gaat werken, hoop ik dat je een Bidib implementatie maakt die binnen de Arduino library structuur past. Ik weet ook eigenlijk niet of je daar op een STM toch (zoals de “trage” XMega) specifieke hardware (zoals DMA) voor moet gebruiken, of dat je het generiek kan maken. Als je toch specifieke hardware peripherals gaat gebruiken, dan hoop ik dat je de processor specifieke code in aparte “drivers” kan stoppen, die je met #ifdef en #includes kan selecteren.

Leuk:-)
Aiko

[Dennis1984]

Ha Aiko,

Hoe ik precies een en ander ga opzetten moet ik nog bedenken. Ik heb al wel eens voor microcontrollers software geschreven, maar ik vind de STMCube software alleen al complex ogen. Als ik het een beetje goed heb begrepen is het in ieder geval wel wenselijk om UART verkeer via de DMA aan te spreken. Maar dat hoeft me natuurlijk niet te beletten om de daadwerkelijke BiDiB-implementatie in een library te stoppen.

Met vriendelijke groet,
Dennis