STM32 har allt - Utom trådlöshet

[DanielM]

Man använder den teknik som passar och löser problemet!

Det är sällan man behöver göra allt från grunden, men en förstålse från grunden är oftast bra och underlättar felsökning...

Jo. Så är det. Men om jag vill lägga till en kamera på min F207 så måste jag leta efter ett bibliotek.
Tar jag upp databladet på en ov2640 så är det massivt med text och man står bara och fundera på vart man ska börja.

Jasså? Det är sällan? Du menar att de som jobbar som hårdvaruprogrammerare, har grunden färdig för sig?

Jag läser databladen och kodar i C. Sedan tester och justeringar.
Databladen är nästan alltid välskrivna och fullständiga.
Har aldrig använt YT eller google i utvecklingssammanhang.

Så om tittar på ov2640 och bestämmer hur du ska tala med den och få den att skicka data.
Det första jag skulle titta på, är inkopplingen.
Sedan skulle jag kolla klocksignalerna om de ska börja högt eller lågt.
Där efter så ska jag förklara för mitt utvecklingsverktyg att "si och så" ska den göra. Men redan där har jag stött på problem.
Nästa problem är att vilka register ska jag skriva till. Det finns inte bar 10 register, snarare 200 register!

[AndLi]

Jag jobbar inte alls som ffredrik.. särskilt inte när det kommer till c# hack, google är din vän.. finns nästan alltid ett exempel på vad man vill göra.

För hårdvaruprojekt är det oftare mer unika förutsättningar och mängden info på internet är väldigt mycket mindre.. Men visst hade jag tittat lite efter exempel för att få lite bekräftelse på att jag är på rätt väg. Men det kräver ju kunskap så man inser om lösningen är en bra eller dålig design...

Men de 200 registrena är väl förklarade i databladet? Och någonstans står väl hur man får den att skicka data? Det är ju sannolint att du inte behöver ändra alla register.. utan bara några få för att liv i den..

[DanielM]

För hårdvaruprojekt är det oftare mer unika förutsättningar och mängden info på internet är väldigt mycket mindre

Ja.
Detta har jag varit med om. Skulle utveckla en CAN-bus styrning med en hårdvara som var så unik, att det fanns inga exemplarer på internet, information eller liknande. Mystisk hårdvara.
Som tur programmerade man detta inbyggda system med Codesys 2.3 så programmeringen var inte så svår. Men att förstå vad man ska göra, är helt annolunda.

Nu jobbar jag inte som hårdvaruprogrammerare, men det händer att jag får en sådan uppgift och då får jag släppa det jag normalt brukar hålla på med.

Om tar ett exempel.
Låt oss säga att jag vill återgå till det där ethernet-chippet jag pratade om.
https://www.ti.com/lit/ds/symlink/dp838 ... 1408386971

Utan att förstå hur chippet fungerar, så börjar jag alltid med inkopplingen. Men det kanske är här jag styper. Jag vet inte hur chippet fungerar, och därmed kan jag inte använda det?

[AndLi]

Det låter svårt att koppla in något man inte förstår, iof gör elektriker det varje dag. Men de har ju schema eller listor att följa... ska du designa själv behöver du förståelse för vad signalerna/ pinnarna gör och om de behövs ... så börja läsa databladet, sen rita schema , sen koda... eller acceptera att hw utveckling inte är för alla...

[DanielM]

Jag tror att hw utveckling passar mig bra, för jag har alltid lyckats att lösa problemet med hw utveckling. Men mycket bygger på att det finns manualer till hands.
Bland annat skrev jag ett bibliotek helt själv för en CAN-bus motor. Där hade jag bara datablad att läsa. Men sådana är unika fall då jag inte har någon annan väg att gå.
Jag har tänkt länge att jag ska börja mer med datablad. Men det är så enkelt att titta på vad andra gör. Men så länge jag gör detta, så är jag kvar på låg nivå.

Så därför tror jag att jag måste börja med att läsa mer datablad och verkligen undvika internet.

[Klas-Kenny]

En nyfiken fråga! När ni jobbar som systemutvecklare, använder ni er av GitHub, Youtube, Google eller färdiga exemplarer?
Eller tittar ni direkt i datablandet och sedan knackar C kod som det vore bara ettor och nollor?

Jag måste alltid titta på vad andra gör, sedan modifiera efter mina behov.
Jag skulle aldrig kunna utveckla något eget från grunden.

GitHub: Det förekommer.
Youtube: I princip aldrig.
Google: Ständigt
Färdiga exempel: Ibland (Exempelvis kan man ju hitta sådant på Github)
Datablad och knacka kod: I princip alltid. Även om man hittar ett lib, så behöver man i regel dubbelkolla saker i databladet osv.

Det beror helt på vad som finns, man väljer ju den mest passande vägen för att lösa varje problem.
Om man hittar något färdigt mjukvarubibliotek som löser uppgiften, och passar bra i övrigt, är det såklart lämpligt att använda det. Men de flesta gånger är inte detta fallet. Antingen finns inget bibliotek, eller så är det stort och klumpigt, eller så fungerar det dåligt eller passar dåligt in i mitt projekt, eller något helt annat.
Då är databladet i regel den huvudsakliga källan till information, så skriver man sin egen kod för att styra hårdvaran till det man vill.

Sen tenderar man springa på allehanda problem på vägen, då blir det i princip alltid Google. Men man hittar ju inga fullständiga systemlösningar på Google, utan bara (ofta) lösningar på väldigt specifika problem som kan finnas i många tillämpningar.

Låt oss säga att jag vill återgå till det där ethernet-chippet jag pratade om.

Utan att förstå hur chippet fungerar, så börjar jag alltid med inkopplingen. Men det kanske är här jag styper. Jag vet inte hur chippet fungerar, och därmed kan jag inte använda det?

Förstå hur det fungerar kan ju ha väldigt olika innebörd.
Man får ju ta ett problem i taget. Till att börja med måste man förstå övergripande vad komponenten gör för någonting, för att ha en aning om vad man gör. Sen måste man förstå de *interface* som komponenten tillhandahåller. Till att börja med då rent elektriskt.
Och om sådant finns, kan man kolla på lite exempelapplikationer. Dels i komponentens dokumentation, och dels i processorns dokumentation. Så kan man oftast få ihop det mesta. De detaljer som är otydliga eller kanske skiljer mellan processor och PHY i detta fall, får man förkovra sig lite i för att förstå och bestämma vilket som fungerar bäst i just ditt fall.

När man fått ihop hårdvaran kommer nästa del att förstå, det är mjukvaran.
Då får man antingen hitta ett färdigt lib som gör en stor del av uppgiften, då kanske det räcker att kolla vissa småsaker i databladet för att göra eventuella justeringar i libbet eller hur man initierar libbet. Eller så får man djupdyka i dokumentation och skriva allt ifrån grunden (eller en kombination av de båda).
Man måste ju alltid ha 100% koll på hur varje detalj fungerar, men lite övergripande koll på de olika interfacen är viktigt. Och än mindre behöver man veta hur sakerna fungerar *innan* man börjar jobba med dem. Det man inte vet får man ta reda på när det behövs.

[DanielM]

Glädjer mig att ni verkligen vill hålla konversationen med mig, än fast jag kanske uppfattas som rätt dryg...eller dum ibland när det kommer om kunskap om just hårdvaruprogrammering.

Jag svarar på ditt inlägg senare, Klas. Jag tänker göra ett liten skiss på mitt system och sedan så ska jag introducera det här. Då tänker jag berätta vilka vägar jag har gått för att fått ihop detta. Jag ska försöka hålla mig till datablad så mycket som det går.

[TomasL]

När det gäller "embedded"
Git, i princip aldrig.
Google, ofta.
utuben aldrig någonsin.
Databladen, alltid, och alltid extremt djupt, så man har hundra koll på hur de olika delarna fungerar.
TIllverkarnas exempelkod, använder jag ofta som referens, men aldrig rakt av.

Börjar alltid med en kravbeskrivning, vilket allt eftersom blir mer och mer detaljerad.
Skapar ett kalkylark med pinnarna på de olika kretsarna, döper pinnarna i kalkylarket till samma som schemanäten, med beskrivande namn. Detta för att kunna utnyttja kretsarna maximalt, och få de olika signalerna på närliggande pinnar, i möjligaste mån.
Dessa namn använder jag också i koden, dvs #define "pinne" "pinnamn"
På det sättet kan jag skriva koden utan att ha kortena färdiga.

Kontrollerar vilka bibliotek jag har, saknas något, så skriver jag det, använder väldigt sällan färdiga bibliotek, förutom de för processorn i fråga, även dessa skrivs om vid behov.
Använder i princip aldrig bibliotek nedladdade från nätet, då dessa för det mesta är extremt dåligt dokumenterade.

[DanielM]

Jo. Men du kanske har gjort samma sak om och om igen? Varje komponent jag tar i verkar vara helt ny för mig.

Här är ett klassiskt problem som jag ej kan söka på internet. Jag stöter på detta ofta.
Jag har valt DP83848 som Ethernet PHY. Bara för att den fanns i Kicad och på Mouser.

Enligt databladet så ska jag koppla den så här. Det rekommenderas att jag följer antingen H1102, H2019, J0011D21 eller J0011D21B.

screenshot.jpg

screenshot_1.jpg

Men låt oss säga att jag har inte en H1102 i min Kicad. Jag har dock importerat en, men det blev inget vidare. Saknar dessutom 3D-modell. Så jag väljer att använda en 7499010121A som har absolut allt inbyggt.

screenshot_2.jpg

Men då måste jag t.ex jämföra 7499010121A mot H1102.

screenshot_3.jpg

screenshot_4.jpg

Insertion loss

• Insertion loss 7499010121A 1-100Mhz: -1.0 dB
• Insertion loss H1102 100kHz-100MHz: -1.1 dB

Return loss

• Return loss 7499010121A 1-30MHz @ 100Ohm: -18 dB
• Return loss 7499010121A 30-45MHz @ 100Ohm: -16 dB
• Return loss 7499010121A 45-60MHz @ 100Ohm: -12 dB
• Return loss 7499010121A 60-80MHz @ 100Ohm: -10 dB
• Return loss H1102 0.1-30MHz: -16 dB
• Return loss H1102 30-60MHz: -10 + 20*log10(Frekvens i MHz/60) = -16 till -10 dB
• Return loss H1102 60-80MHz: -10 dB

Induktans

• Induktans 7499010121A: 350 uH tol +-2%
• Induktans H1102: 350 uH tol +-3%

Ratio

• Ratio 7499010121A: 1:1
• Ratio H1102: 1:1

Crosstalk

• Crosstalk 7499010121A 1-100MHz: -30 dB
• Crosstalk H1102 1/30/60/100: -35/-35/-30/-30 dB

Common mode rejection

• Common mode rejection 7499010121A 1-100MHz: -30 dB
• Common mode rejection H1102 30/60/100: -42/-37/-30 dB

Då är frågan! Enligt databladet så kräver den följande:

screenshot_5.jpg

Ingen av dessa följer kraven. Alltså borde det vara OK att använda en 7499010121A med tanke på att den följer rätt bra på kraven?
Detta är ju inget man kan avgöra igenom att kolla på datablad. Detta bygger på erfarenhet.

Datablad:
https://www.we-online.com/catalog/datas ... 10121A.pdf
https://www.mouser.se/datasheet/2/336/-515479.pdf

[TomasL]

Jo. Men du kanske har gjort samma sak om och om igen? Varje komponent jag tar i verkar vara helt ny för mig.

Visst är det så, men jag var också nybörjare en gång i tiden, men jag har i princip jobbat på detta sätt sedan dag 1.

[DanielM]

Nu när vi diskuterar ethernet.
En stark fördel är att man kan ha webbapplikationer på det inbyggda systemet.

Alltså grafisk kontrollpanel om så önskas.
Borde inte webbapplikationer vara allt mer uppskattat än tjocka LCD skärmar då?

Jag börjar allt mer se produkter där köparen är tvungen att ladda ned en applikation för att ansluta sitt inbyggda system. Oftast Blåtand. Men även webbapplikationer är mycket vanliga hos routers.

När jag tittar på LCD skärmar på internet så verkar dessa vara enormt dyra också. Tror ni att webbapplikationer kommer allt mer bli mer populärt nu när 5G ska in samt allt ska uppkopplas?

Man slipper betala liksom 1000 kr för en Kina LCD av bra kvalité. Eller vad tror ni?

De enda inbyggda systemen som har någon form av LCD är telefoner, mobila och fasta. Även vissa typer av loggutrustningar har LCD, men det är mer vanligt att man ser externa grafiska PC program som anslut till loggutrustningen via USB.

[Klas-Kenny]

Är det inte redan väldigt vanligt att man går ifrån inbyggda displayer i produkter?
Allt mer är antingen uppkopplat direkt via någon molntjänst, eller så har produkten exempelvis Bluetooth där du laddar ner en app och sen ansluter till produkten.

Där emot en webbserver direkt i produkten är sällan särskilt användarvänligt, åtminstone bland konsumentprodukter. Då måste man känna till produktens IP-adress och knappa in den i webbläsaren, och då fungerar det bara om man är ansluten till samma LAN som produkten. Knappast trivialt för Svensson.

[DanielM]

Jag har ingen aning hur LCD behandlas idag.

Jo. Det är detta jag menar. Varför implementera en LCD när man kan använda telefonen eller internet?

[TomasL]

Professionellt har man ju ofta ett övergripande system som hämtar data från produkterna, vanligtvis MODBUS, M-BUS eller BAC-Net, ÖSen sköter allt displayande gentemot operatörerna, så man behöver för det mesta inte några avancerade GUIer.

Jag har ingen aning hur LCD behandlas idag.

Jo. Det är detta jag menar. Varför implementera en LCD när man kan använda telefonen eller internet?

Därför att internet för det mesta inte är tillgängligt och att du inte alltid har tillgång till alla appar som behövs, problemet är ju att du tillslut sitter med flera hundra appar din fån.

Dessutom så tenderar uppkopplingarna att fungera halvknackigt, samt att det tar betydligt längre tid att använda fånen, jämfört med den lokala displayen.

Det där med blåtandsuppkoppling och liknande tror jag kommer att försvinna, i dag är det nyhetens behag, i morgon är det ett enormt säkerhetshål.

[DanielM]

Du menar "Ditt fån"?

Jag uppfattar att internet är ofta tillgängligt och mer kommer det bli också, oavsett om vi vill det eller inte.

Jag vet inte angående om blåtand. Men med blåtand så krävs det att man har en applikation och sådant är rätt dyr att utveckla, jämfört med webbapplikation.

Jag har både utvecklat webbapplikationer och mobila applikationer för både Iphone i Java och Android i Java(GluonHQ).
Det jag märkte är att mobila applikationer är väldigt krävande och underhållet kring en mobil appklikation är krävande. Min mobila applikation fungerar mycket bra på min telefon. Men på någon annans telefon så ser det bara konstigt ut.

Så där blir det inte med en webbapplikation. Webbapplikationen ser likadant ut för exakt alla och man behöver väldigt lite underhåll.