Svenska ElektronikForumet

Hej alla!
Jag kommer länka till denna tråd frånde inlägg jag gör här angående mitt projekt samt uppdatera första posten löpande.
Diskutioner i tråden bör därför hållas till ämnet samt ha ett konstruktivt innehåll.

Mitt mastodont-projekt är en blygsam ljus- och ljud-controller, med framtida ambitioner med både mobil-integration samt motor-styrning (styra en e-motor-controller).
Tanken med projektet är att ge en flexibel helhetslösning för allt möjligt fordons-relaterat och kunna ersätta ett komplett elsystem (minus laddning/tändning osv) i en bil, moped, elcykel eller barnens eldrivna gocart.
Målet är att fritt kunna välja ingångar från olika källor (tex befintliga eglage) och styra olika typer av belysning, kunna köra 12-V blinkers&lampor direkt från biltema el dyl, alternativt kunna köra hemmabyggda strömsnåla led-ramper på säg 6.25V om man hellre vill det.
Grunden jag bygger nu kommer att användas som en hub till mitt "SmartFordon™", där jag kan koppla in moduler för att bygga ut systemet, tex styra telefonen via blåtand och utnyttja fast installerad ljudanläggning som musik-utgång.
Tanken jag har just nu är att meny/display-systemet kan bli just en sådan modul, där driving av displayen samt logik för menysystemet är lokalt i skärm-modulen, men att den får inputs(knapptryckningar) samt data (tex hastighet osv) från den centrala enheten via befintlig i2c-bus.

Min design bygger på ett huvud-kontrollerkort (arduino osv) samt en klase dotter-kort som tex baklykte-kretskortet, som har alla funktioner (blinkers, bakljus, bromsljus osv) styrda av en I2C pin extender (mcp23008).
Effektivt innebär det at jag har ett dotterkort för respektive "installations-zon" och samma 5 ledare till varje zon.
Jag ansluter alltså en blinker-utgång till det kretskort som är närmast, som via inbyggda transistorer kan styra högre strömstyrkor och som styrs via det "lokala nätverket"(i2c) från huvudkretskortet.

Knappar, reglage, lampor osv skapar alltså bara en lokal kabelhärva att ta itu med, men då alla enheter ansluts till samma ledare så påverkas inte huvud-enheten av att man kopplar in/ur ytterligare in-/utgångar.
Med andra ord kan jag, om jag vill, koppla på en släpvagn till mitt projekt, som ansluts på samma sätt som en extra baklykta, till samma 4-5 ledare, men att släpvagnen har full ljus-uppsättning samt också möjlighet att kommunicera med huvud-enheten, tex om jag vill ha knappar i barn-kärran eller en våg i lastkärran.

Så kabeldragningen är planerad till 5 ledare för både ström och signal.
I2C kräver data och klocka, samt strömförsörjning och jord.
Alla lampor och tyngre strömförbrukare får en separat ledare, kallad högströmsledaren då den ska kunna leverera kräm upp till till några hundra watt till ett fordons alla lampor. (högströmsledarens dimensioner anpassas till förväntade laster)
så med gemensam jord för data och "högströmsledaren" så är våra ledare följande: i2c_data, i2c_klocka, +5V, jord, +batteriV.

Jag har designat en hög med kretskort och beställt dem från fabrik, dessa är ungefär 4 kompletta uppsättningar till en cykel/moped, men jag har ju aldrig gjort något sånt här förut, så det finns några buggar i planeringen om vi säger så..
Bland annat har jag bara 4 ledare, ingen batteri-ledare.

Men det duger som test-rigg för mjukvaru-utvecklingen!

På mjukvaru-sidan finns det en hel del, hastighets- och trip-mätare, elektronisk auto-off och soft-off, (mekanisk on).
Jag har även medvetet byggt koden så att det inte spelar någon roll för hur enskilda knappar är kopplade, man konfigurerar varje knapp separat.
Vare sig knapp 5 är kopplad via i2c, lokalt direkt till arduino digital pin eller del av ett kluster av knappar till en enda arduino analog pin, så läses varje knapp, räknar antalet gånger i rad som knappen varit intryckt och när den väl släpps, räknar ut om den var kort- eller lång-klickad.

På mjukvaru-sidan är arbetet nästan i mål, alla (nuvarande) funktioner är där och är bekräftat fungerande, men display-systemet behöver en lösning.


Hårdvaru-sidan släpar lite efter pga inbyggda begränsningar i det nuvarande huvudkontroller-kortet, jag kan inte ha strömförsörjningen inkoplad när jag har datorn inkopplad för då bränner arduinon.
Jag kan heller inte ha mer än några enstaka dotterkort inkopplade utan att störa ut USB-porten när datorn är inkopplad, så det är ett väldans in/ur-kopplande för en mjukvaru-uppdatering..

Så kvar att göra här är följande:
# att modda ett par bromsreglage (hydrauliska) för att kunna med magnet+hall-sensor bygga en justerbar broms-trigger.
# att testa hastighets-sensor / varvtals-sensor (för kadens)
# debugga knapp-hårdvaran (i2c), läser slumpartat nu (hw-debounce?)
# konfigurera utgångar (lampor)


Rent generellt är jag på två ställen o jobbar, mjukvaran, eller planerar ombyggnad av "moderkortet", kärnan av logik i mitt projekt.
Hårdvarumässigt behöver jag några förbättringar:
# Strömförsörjning (inbyggd laddning, valbar strömkälla (batteri/nät-adapter))
# Flexibel dator-anslutning (för att närsomhelst kunna koppla datorn till arduinon för t.ex seriell konsoll eller mjukvaru-uppgradering)
# Mer logisk placering av bl.a I/O anslutningar och ström.

Rent konkret så är inte nuvarande moderkort misslyckade, de fungerar som tänkt och jag kan övervaka batteri-spänningen osv men många av funktionerna blev fel, jag anslöt exempelvis framlyktan till fel drivkrets(den hamnade på arduinons 5V ist f den Vreg som var avsedd för externa lampor) och missade att helljuset skulle styras separat.
Jag löste det med en hårdvaru-mod och en TO-92 transistor (ist f ytmonterat) men det blev inte "sexigt"..

En annan detalj som irriterar mig är att jag designade dem för temperatur-övervakning av både inbyggda ström-regulatorer och batteri men valde fel fotavtryck för ic-kretsen på moderkortet så mina sensorer passade inte..
Jag hade också helt missat att jag fick en cut-off funktion på köpet med mina temp-sensorer, så hade jag bara anslutit en extra pinne på rätt sätt så hade jag sluppit mätningen i mjukvaran.

Så jag behöver ett nytt moderkort på sikt och har där följande kriterier:
# Ska klara av att drivas från batteri och nät-adapter, ska laddas från nät-adaptern. (okej med sw reset vid strömbyte, men helst inte)
# Ska ha usb-anslutning för in-system-programming och debugging (kunna koppla in datorn/surfplattan för feedback oavsett hur jag driver resten av systemet)
# Ska ha separat strömförsörjning (Vreg) till ett flertal separata enheter/grupper, möjligen/troligen på separat kort.
# Förberedd för en modul med bl.a bletooth, ljud osv. (hål+lödytor för att bygga en "sandwitch" av flera staplade kretskort)
# Ha en uppsättning utgångar för diverse funktioner (blinkers, positions-/broms-ljus osv)
# Passa i ett grovt rör, alternativt fejk-vattenflaska.

Notera att detta första inlägg kommer att hållas uppdaterat och att detta ska fungera som en "snabb introduktion" till mitt projekt.
Mvh Liggisten (liggcyklisten)

Hej igen!
Jag tänkte att det vore ju trevligt att presentera människan bakom projektet också..
Jag har pysslat med detta projektet i ett antal år och använt det för att lära mig om programmering, arduinos, elektronik occh el-lära, styr- och regler-teknik och så vidare.

Jag har jobbat som cnc-operatör i ett antal år och där blev jag nyfiken på programmering och eftersom min hobby handlar mycket om att ligga ner o cykla, så blir min trafiksäkerhet lite viktigare än när jag kör tantens gamla damcykel.
Dels är jag lika hög som en femåring när vi cyklar och dels är styrningen lite knepigare, vilkett gör det ibland svårt att signalera till medtrafikanter.
Men min hastighet på liggcykel är ofta dubbelt så hög jämfört med en damcykel, så det kändes logiskt att utrusta den med ett ljus-"språk" lånat från en moped.

Så jag har spenderat snart ett årtionde på att utrusta min liggis med blinkers för att jag ville undvika reläer..

Men annars är jag en skapligt välfungerande individ, med både hundar och barn, foliehatten till trots! B-)

Spännande projekt, men det saknas ju bilder!

Intressant att se hur bra I2C-bussen fungerar att använda på detta sätt. Vad kör du för hastighet?
Personligen så hade jag gått på CAN för en sådan tillämpning, men så jobbar jag ju med fordonselektronik också.

Mina funderingar:
* En I²C-bus är ju INTE tänkt att dra ut "externt" från ett kretskort, den är för störkänslig. Jag hade vald RS485 eller CAN.
* Jag ser det som onödigt komplicerat - men jag ser även lusten att göra en häftig grej och av dessa två vinner den siste varje gång! Lust att göra saker är BRA! Jag hade dock vald en annan µC - men det är jag det.

Tja, valet av I2C som bas är väl förankrad i efterforskning och egna experiment.
Jag har rotat i specifikationer och datablad och teoretiskt ska man kunna ha runt 100 meter kabel mellan modulerna.
Men man måste placera och dimensionera pullUp-resistorerna med omsorg!

Här är det fråga om max 5 meter, inklusive släpvagn.


Jag hade faktiskt tänkt använda CAN från början, men priset var markant högre och det är svårare att hitta tex display, temp-sensor och pin-extender som stödjer CAN.
Visst, de finns, men ofta är de då för fordon, dvs 12V och resten av min logik är 5V.
Eftersom jag vill ha minimalt antal sladdar och ledare mellan varje modul så behövde jag en enda bus som kunde prata med alla enheter, så SPI gick ju bort, liksom flera andra.
Jag behövde ju också få alla modulerna med samma interface vilket ledde till ett himmelskt pusslande, kalkylblad och letande för att få något grepp och det visade sig att allt fanns med i2c, det mesta med CAN var för bilar och de andra serie-interfacen saknade antingen moduler eller dokumentation/bibliotek för c/arduino.


Så från ett ekonomiskt och praktiskt perspektiv ter sig ju I2C som det självklara valet, med alla lätt tillgängliga och billiga moduler, men sen kan jag mycket väl springa på en proverbial mina angående signal-fel och störningar.
Men vad vore livet utan chansningar?
Om jag skulle lyssna på alla "nej, det går inte" hade jag ju aldrig kommit nån vart..

Dessutom; troligen kan jag minimera sådana problem med någon form av filter, alltså ett gyllene tillfälle att lära mig mer om sånt, om det skulle visa sig nödvändigt.

Angående I2C-bus-hastigheten; jag är osäker men jag har för mig att "default" blir 400kHz.


Jag har börjat jobba lite med omdesignen av det nya "moderkortet" till projektet, med bland annat ny strömhantering, nu på separat kretskort.
Jag kommer använda en identisk hålbild för anslutande ledare mellan korten (flatsida mot flatsida) och kan därför förenkla moderkortet genom att få "ström från ovan".
Rent krasst blir då korthögen som ett 4-lagers kretskort fast med 4 ytor för komponenter och där de anslutande ledare som nämndes ovan fungerar som " pcb vias" samt struktur för att hålla isär korten på lagom avstånd.

Så bilder kommer, när jag lyckas komma ihåg att ta dem..
De ursprungliga bilderna och dokumentationen, samt all programkod blev otillgängliga när jag bjöd min macbook på en kopp kaffe.
Trots att vi känt varann i nästan 10 år så höll vår relation inte för det, disken e mac-formatterad och troligen krypterad..

Jag har dock börjat om på dokumentationen, baserat på de kopplings-scheman jag har sparat i molnet hos min kretskorts-dealer, easyeda.com.
Programmet testas i simulator på tinkercad.com och båda sajterna erbjuder samarbeten, så om någon vill ta sig en närmare titt så kan det nog ordnas.

Om man nu skall vara lite tråkig så vid ett CE test där du har 5 meter kablar
så strålar man på en hel del energi in i kablarna som systemet då skall tåla.
Att dra 5 meter I2C och då även med systemets 5V blir då en tuff utmaning.

Skall man vara ännu tråkigare så är Bil Elektronik besläktad med en hel del utmaningar i sig eftersom
12V sällan är 12V.
Ta t.ex. Load dump, det som kan hända om batterisladden lossar under laddning.
https://en.wikipedia.org/wiki/Load_dump
Du får då mer än 100v över inkommande 12V under ett kort ögonblick
Jag brukar ha en 5kW tranzil i dessa tillämpningar på inkommande,
Skulle aldrig låta 5V matningen lämna varje enskilt kretskort.
All kommunikation isolerad.

Swech

Hejja, Hejja! Kul och intressant tråd! Kör på bara. Jag och många fler läser med stort intresse.

En I²C-bus består av 2 ledare, en RS485-bus består av 2 ledare.
Fordonskiljö är ett synnerligt "smutsigt" miljö rent störningsmässigt.

Jag vill tillråda att du testar en del först, innan du beslutter dig.

Och jag håller också med: den reglerade matningen på ett kretskort lämnar ALDRIG kretskortet!

Jag hade konsekvent monterat reglering på varenda kretskort och matat med 12V.

Om man inte vill blanda in ett nytt protokoll så verkar det finnas i2c-extenders som skickar datan differentiellt. Har inte själv använd någon så kan inte svara om det finns fallgropar men kan vara värt att titta på som ett mellanting till att gå över till ett annat protokoll som CAN.

Exempel på krets från NXP:
https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf

Verkar även finnas varianter från TI och säkert flera.

Låter intressant och kommer att följa.
Skall börja med ett mer jordnära projekt med fläktstyrning till slutstegen back i bilen med I²C-bus för att hämta temperaturer och styra framifrån.
Så jag plockar lite idéer från din tråd.
Jag har beställt hem TCA9511 som jag tänkt använda till 3-4m I²C buffer, får se om den fungerar bilmiljö (ser i kommentarerna att det inte verkar så enkelt som jag trodde).
Det finns även en buffert P82B96TD som alternativ.

Så hittar du någon mer intressant info om I2C får eller praktiska tester får du gärna dela med dig, mina kunskaper är obefintliga.
/Conny