STM32 har allt - Utom trådlöshet

[AndLi]

Det beror ju helt på vad du ska ansluta till och användas till..
Men kör du modbus det blir säkert bra... det går ju att köra över tcp/ip med..

[DanielM]

Det beror ju helt på vad du ska ansluta till och användas till..
Men kör du modbus det blir säkert bra... det går ju att köra över tcp/ip med..

Är inte Modbus en mjukvara/protokoll och TCP/IP är själva stacken som är under modbus?

Jag uppfattar som att TCP/IP är alltså "Socket-kommunikation", dvs förmågan att skicka data fram och tillbaka och lyssna efter inkommande data.
Modbus är hur datan ska formas för att det ska uppnå en viss ISO standard.

[TomasL]

Nej, modbus är ett protokoll av samma slag som TCP/IP, däreemot kan man kappsla in Modbus-protokollet i TCP/IP
Modbus liksom TCP/IP ställer har likartade krav på hur data skall utformas, samt hur det skall skickas.
När det gäller timing, så är modbus väldigt strikt, TCP/IP är det inte.
Och kapslar man in MODBUS i ett TCP/IP-paket, så försvinner timing-kravet.
MODBUS innehåller sin egen stack.

[AndLi]

TCP/IP har inget med hur de skickas på de fysiska lagret att göra, visst finns det timing i TCP/IP men det handlar mer om omsändning av hela paket, och precis som ThomasL säger långt ifrån strikt..
Det är ju Ethernet eller vilket media/standard man nu väljer köra TCP/IP över som bestämmer den riktiga lågnivå timingen och signalnivåer och dylikt...

[DanielM]

Nej, modbus är ett protokoll av samma slag som TCP/IP, däreemot kan man kappsla in Modbus-protokollet i TCP/IP
Modbus liksom TCP/IP ställer har likartade krav på hur data skall utformas, samt hur det skall skickas.
När det gäller timing, så är modbus väldigt strikt, TCP/IP är det inte.
Och kapslar man in MODBUS i ett TCP/IP-paket, så försvinner timing-kravet.
MODBUS innehåller sin egen stack.

Vad rekommenderar du för mig i detta fall om jag vill ha proper kommunikation med en server?

TCP/IP har inget med hur de skickas på de fysiska lagret att göra, visst finns det timing i TCP/IP men det handlar mer om omsändning av hela paket, och precis som ThomasL säger långt ifrån strikt..
Det är ju Ethernet eller vilket media/standard man nu väljer köra TCP/IP över som bestämmer den riktiga lågnivå timingen och signalnivåer och dylikt...

Vad rekommenderar du mig då?

En fråga!

Nu är jag snart klar med att dra linjer.
Kan jag ha vias på paddarna?

[TomasL]

Kan jag ha vias på paddarna?

Nej, inte bra.
Dock, om du handlöder funkar det, men skall det automonteras och ugnslödas, så är det ingen jättebra ide.

Din fråga om vad som som rekommenderas, tja, det är som att fråga hur långt ett snöre är.
Det bertor helt och hållet på vad du vill uppnå, vilken miljö du skall jobba i osv.
I vissa lägen är MODBUS-RTU perfekt, i vissa lägen är MODBUS/TCP att föredra, i vissa lägen är BACNet att föredra.
Dock är det ju så att MODBUS-RTU bara fungerar på en RS485-lina och MODBUS/TCP bara på ethernet.
För BACNet gäller samma, men jag gissar iofs att BACNet kanske är lite fr komplicerat för dig.
Så kör MODBUS, enkelt och effektivt, lätt att implementera, dock somm allt så har det sina begränsningar.
Framförakllt är det så att använder man register längre än 16 bitar, så finns ointe det med i standarden, utan realiseras på olika sätt av olika tillverkare.
En del kör med heltal, en del med flyttal osv, en del kör BE på word-nivå och en del LE, så det är lite stökigt.

[AndLi]

TCP/IP har inget med hur de skickas på de fysiska lagret att göra, visst finns det timing i TCP/IP men det handlar mer om omsändning av hela paket, och precis som ThomasL säger långt ifrån strikt..
Det är ju Ethernet eller vilket media/standard man nu väljer köra TCP/IP över som bestämmer den riktiga lågnivå timingen och signalnivåer och dylikt...

Vad rekommenderar du mig då?

Ska du ut i molnet och härja hade jag kört Ethermet -> TCP/IP -> TLS (med mutal authentication) -> valfritt protokoll som löser dina problem. (REST-API är ju poppis niförtiden) Men passar ju kanske inte så bra för strömmande data..

[DanielM]

Kan jag ha vias på paddarna?

Nej, inte bra.
Dock, om du handlöder funkar det, men skall det automonteras och ugnslödas, så är det ingen jättebra ide.

Din fråga om vad som som rekommenderas, tja, det är som att fråga hur långt ett snöre är.
Det bertor helt och hållet på vad du vill uppnå, vilken miljö du skall jobba i osv.
I vissa lägen är MODBUS-RTU perfekt, i vissa lägen är MODBUS/TCP att föredra, i vissa lägen är BACNet att föredra.
Dock är det ju så att MODBUS-RTU bara fungerar på en RS485-lina och MODBUS/TCP bara på ethernet.
För BACNet gäller samma, men jag gissar iofs att BACNet kanske är lite fr komplicerat för dig.
Så kör MODBUS, enkelt och effektivt, lätt att implementera, dock somm allt så har det sina begränsningar.
Framförakllt är det så att använder man register längre än 16 bitar, så finns ointe det med i standarden, utan realiseras på olika sätt av olika tillverkare.
En del kör med heltal, en del med flyttal osv, en del kör BE på word-nivå och en del LE, så det är lite stökigt.

Jag handlöder. Men jag valde nu att inte ha en via på padden.

Låt mig see. Jag har en Spring Boot server. Om du inte vet vad det är så är det värdens bästa mjukvara för att bygga webbapplikationer. Man gör det i Java.
Man behöver inte ens installera det, utan tanka ned det här och kör programmet: https://start.spring.io/ Detta är alltså en projektuppstartare.

Spring Boot har möjligheten till Reset och det kanske är något för mig?

TCP/IP har inget med hur de skickas på de fysiska lagret att göra, visst finns det timing i TCP/IP men det handlar mer om omsändning av hela paket, och precis som ThomasL säger långt ifrån strikt..
Det är ju Ethernet eller vilket media/standard man nu väljer köra TCP/IP över som bestämmer den riktiga lågnivå timingen och signalnivåer och dylikt...

Vad rekommenderar du mig då?

Ska du ut i molnet och härja hade jag kört Ethermet -> TCP/IP -> TLS (med mutal authentication) -> valfritt protokoll som löser dina problem. (REST-API är ju poppis niförtiden) Men passar ju kanske inte så bra för strömmande data..

Ja. Rest kanske är något. Men jag vill kunna styra min STM32 via nätet också. Det blir lokalt nätverk.

Hur som helst! Nu är det klart för att granskas. Inga DRC felmeddelanden eller liknande. Jag har valt vias 0.6 mm utvändigt och 0.3 invändigt. Precis som JLPCB klarar utav. https://jlcpcb.com/capabilities/Capabilities

Jag har inte stichat än med vias. Det ska göras direkt innan jag skickar iväg den på tillverkning. Draget helt själv! Inget autorouting här!
Granska mig gärna.

[Klas-Kenny]

Som sagt, de snabba signalerna, särskilt då kring Ethernet i ditt fall, bör hanteras varsamt. De ska gå så rakt som möjligt, med så få vior och omvägar som möjligt. Rita dem före att du ritar in alla konfigurationsmotstånd och liknande okritiskt jox.
Och diff-paren ut från PHY måste hanteras som just diffpar (ritas parallellt i hela sin längd), även de så rakt som möjligt med så få vior och annat som möjligt.

Jag sträckte ju ut hakan och påstod att de klarar sig utan impedansanpassning, och det står jag kvar vid. Men det innebär inte att det kan göras precis hur som helst med dem och få ett gott resultat.

Här är ett exempel från en liknande layout som jag gjort;

eth.png

Här hade jag förvisso "lyxen" med fyrlagerskort och dubbelsidig montering. Men även utan det går det att förbättra de där ledarna ordentligt jämfört med hur du har gjort det nu, bara genom att applicera lite grundläggande principer.

[TomasL]

Det är absolut enklare att köra med 4-lagerskort.
Då använder du stackupen, uppifrån och ned
Signal
Vss
Vdd
Signal

Du lägger heltäckande koppar på Vdd och Vss-lagren, dessa är de huvudsakliga jordplanen
Läg även koppar på signallagren och sy ihop dessa med Vss.

Börja sedan med matningarna och avkopplingskondingarna då dessa skall ligga kså nära som möjligt, jag lägger ferriter i serie med Vdd till varje pinne innan kondingarna.
Därefter kristallen, då den också skall ligga så nära som möjligt.
Därefter differentiella signaler, använd programvarans funktion för att få samma ledarlängd, och routa dem parallellt, om möjligt gör en enkel impedansmatchning på dessa. (är det riktigt snabba signaler så måste kretskortstillverkaren göra impedansanpassningen), då din programvara alltid räknar fel.
Ju snabbare signaler, desto viktigare är detta.
Därefter andra viktiga och snabba signaler.
till sisst allt övrigt.

[Rick81]

Jag sträckte ju ut hakan och påstod att de klarar sig utan impedansanpassning, och det står jag kvar vid. 

Jag förstår fortfarande inte varför man inte ska impedansanpassa... är ju inte så svårt att välja rätt bredd på ledare.
Bara onödigt dumt med tanke på ev. Problem det kan innebära. Har sett USB som funkar skakigt pga ingen impedansanpassning. Krävdes omkonatruktion för få det funka

[Klas-Kenny]

För att det kostar pengar?

Visst kan man själv räkna och gissa lite var impedansen skulle kunna landa, men utan dialog med mönsterkortstillverkaren är det meningslöst då man inte vet alls var det landar.

USB (Hi-speed) så pratar vi tiodubbla klockfrekvensen av RMII, det är en helt annan femma. Där är det enklare att komma upp i så långa ledarlängder att det blir ett problem. Lägg sen till att man kanske samtidigt gjorde dålig design av de differentiella signalerna?

[Rick81]

Alla seriösa kretstillverkare ger ut en layerstack som man kan räkna efter.

Visst, ska kretskorttillverkare göra impedansanpassning så kostar det extra, men det behövs oftast inte. Jag har självt designat flera kretskort med känsliga signaler på 1-2 GHz och bara räknat ut impedans och det har funkat bra.

I första revision gjorde jag en "Klas-kenny" och då funkade katastrofalt dåligt...

I nämnda fallet hade kretskorttillverkare ändrat layerstacken vilket sabbade impedansen.

[DanielM]

Tackar för svar. Detta påminner mig väldigt mycket till mitt förra kort.
Men som jag har sagt innan, så har jag dragit de viktigaste linjerna först, avlastningskondensatorerna är väldigt när. Det handlar om millimeter här.
Dessutom ethernet, så är det väldigt korta avstånd.

Så jag vet inte hur jag ska tolka era inlägg. Menar ni att mitt kort fungerar inte? Vem säger det?

Så ni tycker att jag borde köra 4-plan istället för 2-plan här?
Visst, det kan gå. Blir enklare också att dra.

Så mitt kort ser ut som ett haveri?

[Rick81]

Det ser inte ut som haveri.

Troligen kommer Ethernet fungera. Men 4 lagers kort med jordplan är att rekommendera.