Har alla uC pattformar Hardware Abstraction Layer (HAL) ?

[AndLi]

Självklart går det att skriva HALs som på ett snyggt och smidigt sätt separerar hårdvara och mjukvara, och som vid processorbyte/tillverkarbyte skapar minimalt arbete i mer än drivrutinerna.

MEN det har inte varit fokus för ST när de gjort sin CubeMX och HAL, det är bara att skapa ett projekt och titta i mainfilen, som är fullständigt nerkletad med Hårdvarunära kod (för att ställa in div klockor, initiera saker).
Det skulle det funnits en clockInit() funktion först, där sen koden ligger i därför avsedd c fil. OCh en fin main som kallar ens olika submoduler i nån slinga.

Många av ST HAL funktioner känns relativt högnivå, så de har en tendens att hamna relativt högt upp i kod-hirakin, där de egentligen inte har något att göra. Ska man byta uC får man då också implementera om mycket av den funktionalitet ST har lagt in i sin HAL.

Men visst funkar ST HAL, jag har i mitt hempulprojekt bytt µC tre gånger inom STM32F4 familjen, och det har bara varit att ange rätt startup fil och sätta #definen som specar vilken µC jag använder. (Och visst kasta om vilken pinne som används till vad eftersom jag också bytt utvecklingskort, men det kan man ju inte skylla ST för..)

[Al_Bundy]

Jag tycker att HAL är helt underbart! Jag har aldrig kommit igång så fort med riktig hårdvara. Synd bara att man inte kan köra Java på en STM32. STM gjorde ST-kort förut som man kunde köra Java på.

Men det blev nog inget gott resultat då korten blev dyra och ingen köpte. Så jag får fortsätta med Java när jag gör IoT-saker på enkortsdatorer

[Gimbal]

Det är snudd på sexistiskt att diskutera pattformar skulle jag vilja påstå.

[Klas-Kenny]

Det verkar ju i alla fall inte fungera så bra om man använder sig av CubeMX.... Då fylls main.c med en massa hårdvaruspecifik kryptisk goja.... som sedan trasslar sig in i det mesta man ska göra.... (jag hatar detta. Har inte vant mig vid 32-bitars MCU än )

Låt bli CubeMX då.

32bit är i princip inte svårare än 8bit. Läs datablad och referensmanual och prata direkt med hårdvaran istället för att använda HAL, så förstår du hur det fungerar och inser att det inte är någon större skillnad. Mer än att 32bittarna ofta har lite fler och mer avancerade periferier och således lite mer register, men inte farligt. Blir bara en väldigt lång referensmanual med alla olika periferier.

Gjorde samma misstag då jag började med 32bit ARM ifrån 8bit PIC, använde ST's HAL och förstod ingenting av vad jag gjorde. Sen jag insåg att det egentligen inte är någon skillnad, och all info finns i referensmanual, har det hela gått hur bra som helst.

[lillahuset]

Man skriver lämpligen ett HAL steg för steg när man behöver använda nya periferienheter eller funktioner. Då är det bra att samtidigt skriva lite testkod.

[AndLi]

Jag känner igen mig i Klas-Kennys beskrivning..
Brukar ibland titta i ST-HAL kod för att se vad jag missat ställa in när saker inte funkar, men oftast blir man bara mer förvirrad...
IAR exempelbibliotek är också ganska trevligt om man vill köra barebone (men de är ju inte gratis)

Energy Micros(numera silabs) HAL verkade lite trevlig, dock var deras utvecklingskort mer svårtillgängliga än ST, så det blir ju lätt att man tar första bästa kort om man vill göra någon prototyp, och de har ju en förmåga att bli kvar i slutprodukten.
Det är ju inte en slump att ST utvecklingskort är billiga..

lilahuset: men då måste man ju kunna koda....

[Al_Bundy]

Själv måste jag ha HAL, för jag förstår bara en processor lika mycket som jag förstår en PLC.

Jag programmerar mycket inom Codesys, TTcontrols produkter, IX-developer, Java och nu blir det STM32. Så jag har inte tid att lära mig hårdvaran på det svåra sättet. Jag håller ju på mycket med beräkningar via MATLAB också. Samt hemsidor gör jag också.

[lillahuset]

Tråkigt för dig Al. Du får väl dumpa något då, STM32 tex.

[Rick81]

Det finns även en LL (Low Layer) del i HAL som ger åtkomst på lägre nivå till hårdvara.

HAL är bra för att snabbt komma igång, men sen går det ju alltid anpassa eftersom man får all källkod och man kan ju gå ned i HAL för att se vilka register som sätts. Sen är ju alltid exempelkod bra och där tycker jag ST är ett föredöme

[Al_Bundy]

Tråkigt för dig Al. Du får väl dumpa något då, STM32 tex.

Eller så använder med ST's HAL? Fungerar utmärkt. Man behöver inte kunna allt.

När jag gick i på universitetet så var det bara teori teori teori teori och våra doktorer som lärare beskrev som att utan teorin så är man helt borta. När jag är ute på arbetslivet så vill företagen/kunderna bara att jobbet ska vara klart så fort som möjligt. De bryr sig inte om teori eller hur smart man är. Så länge pengar rullar in. Dessutom så får man använda verktyg också som gör det grova jobbet.

Det var verkligen ett stort kliv från teori till praktiken ska jag säga. Praktiken var betydligt mycket svårare än teorin för praktiken så var det mer "gör det bara!" och det ska gå snabbt.

[säter]

Tur att man inte är kund hos dig.

[Al_Bundy]

Så där ser det ut i hos de flesta företag ska du veta. Det har inget med hur ingenjörerna är, utan det sitter i styrelsen. Styrelsen finns det bara kaffedrickande ekonomer och utbildade projektledare som ska diskutera framtidens produkter.

[säter]

Jag tror att de flesta seriösa företag vill ha en fungerande produkt, även om det blir dyrt.

[Al_Bundy]

Visst bordet det vara så. Men i verkligheten så är det inte användarna som kollar på priset, det är dem som ska betala fakturan.

Jag brukar säga samma sak åt dem som säger "En PID duger". Finns ju en hel del på detta forum som håller PID:en nära kärt.
Jag brukar tolka detta som att dem kan inget mer än just vanlig enkel reglerteknik på grundnivå, om ens det.

De flesta kan inte ens redovisa teorin varför en PID regulator inte tål frekvenser.