Förslag på PWM, ADC, I/O och DAC IC kretsar med SPI?

[TomasL]

Tja, jag och rätt många andra har lärt oss via databladen, Har nog aldrig någonsin sett en utubevideo, eftersom de är meningslösa.

[DanielM]

Ja, men du TomasL är speciell

[TomasL]

Inte speciellt.
Gissar att de flesta här har lärt sig från databladen.
Utom du, och du har inte lärt dig speciellt mycket de senaste åren.
Hade du bemödat dig att studera databladen istället hade du lärt dig bra mycket mer, och snabbare.

[DanielM]

Jo. Ditt beteende är unikt. Du är en sådan där sterotyp som är väldigt klipsk på ett företag och får jobba med dom svåra uppgifterna, men något envis och ibland tjurig.

Jag har lärt mig annat också, som inte direkt har med uC att göra

Det största problemen jag har med datablad är att veta vart man ska leta.

[hummel]

För att veta var i databladet du ska leta, så börja med innehållsförteckningen!

[DanielM]

Självklart. Men det var inte det jag menade.
Tänk dig att du söker information om avlastningskondensatorer eller rekommendationer.
Detta är inte samma sak som absolut fakta. Att hitta absolut fakta så är det bara kolla i innehållsförteckningen "Hmm..få ser här...I/O pinnar...maximal ström".

Notera att detta är absolut första gången jag bygger en uC från grunden. Jag har aldrig gjort sådant förut.

[TomasL]

väldigt klipsk på ett företag och får jobba med dom svåra uppgifterna, men något envis och ibland tjurig.

Naturligtvis är det så, och kanske därför som företaget jag startade för 12 år sedan är börsnoterat i dag, eller?

Vad du måste lära dig, är att för att lyckas måste du lära du´lära dig från grunden, det finns helt enkelt inga genvägar.

[DanielM]

Sjävklart är grunderna viktiga. Anser du att HAL eller CubeMX är genvägar? STM hävdar att de rekommenderar sina användare att börja med CubeMX, dvs maskingenererad kod. Själv tycker jag att det låter helt underbart med maskingenererad kod. Orsaken har med att man bygger upp en standard så alla gör på samma sätt. Likadant sker i Spring Security. Där finns det bara ETT sätt att koppla användarnamn mot databas. Helt underbart och genomtänkt enligt mig. Bara ETT sätt.

[TomasL]

Ja, det är en genväg, vilket lurar dig.
HAL är jättebra, när man har 100% förståelse om hur processorn funkar, intill dess, är en HAL en väldigt dålig lösning.
Samma gäller alla genvägar, de är jättebra när man har 100% kunskap och förståelse, intill dess, är de av ondo, typ.

[Klas-Kenny]

HAL är jättebra,

Är du säker på det?
Jag vill nämligen hävda motsatsen..

Jag tycker att det är "måttligt" bra. Det är oerhört ineffektivt, i ett projekt jag jobbar med där vi kör STM32 med HAL så har jag tvingats byta ut flera av HAL-funktionerna till egenskrivna funktioner, då de ineffektiva rutinerna helt sabbade realtidsegenskaperna som krävs i det projektet.

Tycker heller inte det är särskilt smidigt att göra tex initiering av viss hårdvara med, åtminstone inte om man ska göra lite klurigare saker. Har hänt att jag tvingats kolla i databladet för att se vad jag ska göra, sen kolla i HAL-koden vad den egentligen gör, för att lyckas klura ut hur man gör vad jag vill med HAL..

Även hopplöst med CubeMX att man tvingas ha en massa genererade kommentarer i koden. Och har man råkat lägga till kod på fel ställe i en fil så skriver CubeMX rått över det vid en uppdatering. Exempelvis Microchip's "Harmony" (som dock också har mycket att önska) är mycket bättre, då det gör en diff mellan koden verktyget vill generera och den befintliga koden, och låter en välja hur man vill lösa konflikterna.



Vissa saker är naturligtvis bra. Exempelvis USB-biblioteket har jag använt en del. Det sparar ju väldigt mycket tid att slippa implementera allt själv.
Men att läsa/skriva utgångar eller köra en SPI, nä, det är minst lika smidigt (och mycket effektivare) att göra direkt emot hårdvara.

[DanielM]

Ja, det är en genväg, vilket lurar dig.
HAL är jättebra, när man har 100% förståelse om hur processorn funkar, intill dess, är en HAL en väldigt dålig lösning.
Samma gäller alla genvägar, de är jättebra när man har 100% kunskap och förståelse, intill dess, är de av ondo, typ.

HAL är jättebra,

Är du säker på det?
Jag vill nämligen hävda motsatsen..

Jag tycker att det är "måttligt" bra. Det är oerhört ineffektivt, i ett projekt jag jobbar med där vi kör STM32 med HAL så har jag tvingats byta ut flera av HAL-funktionerna till egenskrivna funktioner, då de ineffektiva rutinerna helt sabbade realtidsegenskaperna som krävs i det projektet.

Tycker heller inte det är särskilt smidigt att göra tex initiering av viss hårdvara med, åtminstone inte om man ska göra lite klurigare saker. Har hänt att jag tvingats kolla i databladet för att se vad jag ska göra, sen kolla i HAL-koden vad den egentligen gör, för att lyckas klura ut hur man gör vad jag vill med HAL..

Även hopplöst med CubeMX att man tvingas ha en massa genererade kommentarer i koden. Och har man råkat lägga till kod på fel ställe i en fil så skriver CubeMX rått över det vid en uppdatering. Exempelvis Microchip's "Harmony" (som dock också har mycket att önska) är mycket bättre, då det gör en diff mellan koden verktyget vill generera och den befintliga koden, och låter en välja hur man vill lösa konflikterna.



Vissa saker är naturligtvis bra. Exempelvis USB-biblioteket har jag använt en del. Det sparar ju väldigt mycket tid att slippa implementera allt själv.
Men att läsa/skriva utgångar eller köra en SPI, nä, det är minst lika smidigt (och mycket effektivare) att göra direkt emot hårdvara.

Här svarar jag er båda. Jag har jobbat med projekt på olika företag och jag väljer alltid standardlösningar, vilket ingår inom 5S, än att hitta på egna.

Så i detta fall så anser jag att HAL är ett standardsätt, för programmerar man med HAL, eller maskingenererad kod, så kommer exakt alla jobba på samma sätt.
Vi kan ta t.ex. Spring Boot där det finns bara ett sätt att programmera vissa funktionaliteter och detta fungerar riktigt bra. Med CubeMX så vet exakt ALLA vart SPI deklerationerna finns. Alla vet hur USART deklareras. Alla vet exakt allt.

Att hitta på egna funktioner och sedan lämna över koden till någon annan så kommer det bli riktigt många olika frågetecken innan användaren begriper.
Visst kan man skriva egna HAL-funktioner igenom att lusläsa datablad och liknande och sedan känna sig stolt och smart över att man har utnyttjat sin kunskap till 100% för att lösa ett problem. Men enligt STMicroeletronics så rekommenderar de att sina användare skall använda CubeMX och detta är av en ren strategi att det ska vara enklare att överlämna arbete till någon annan.

Jag väljer hellre att använda maskingenererad kod och det får kosta lite extra minne, än att ha det superoptimalt med egenskriven kod och sedan ska alla andra förstå vad jag har gjort. Sådant köper INTE dagens moderna chefer. Dagens chefer på industrin vill att alla följer samma sätt att arbeta och alla jobbar på samma nivå i form av kunskap. Detta är av en liten utopi, men jag har sett företag som lyckas med det igenom att använda verktyg som får sina anställda att, i praktiken utföra samma arbete.

Notera!
Det är alltid häftigt att lösa enkla problem på den svåra och kunskapskrävande vägen, men vem imponerar man på egentligen? Sig själv eller andra?

[JimmyAndersson]

Det handlar inte om att imponera överhuvudtaget.
Det är istället kunskapen som räknas.
Eller rättare sagt: Intresset av kunskap och att kunna tänka på ett annat sätt!

[DanielM]

Tänka på annat sätt igenom att frångå standardverktyg och metoder?

[Castor]

Dagens moderna chefer är oftast ekonomer som ser till pengar i första hand. Att bara använda standardverktyg gör att den som har förmågan och viljan att tänka utanför givna ramar inte premieras. Jag tror att detta synsätt ger färre unika lösningar, färre patent och mindre kunskaper hos de som gör jobbet. Man löser problemen på ekonomiska villkor i första hand, inte tekniska.

[TomasL]

Dessutom, standardverktyg/lösningar är inte nödvändigtvis felfria, samt att man också måste ta ansvar för kod som någon annan skrivit, och ofta är källkoden inte tillgänglig, utan ingår i förkompilerade libbar som man inte har kontroll över.