Electrokit Buggfix Plus
Aktuellt datum och tid: 13.26 2019-08-20

Alla tidsangivelser är UTC + 1 timme




Svara på tråd  [ 29 inlägg ]  Gå till sida 1, 2  Nästa
Författare Meddelande
InläggPostat: 16.45 2019-01-02 
Användarvisningsbild

Blev medlem: 22.59 2012-09-11
Inlägg: 2889
Ort: The U.S - Chicago
STM32 är den plattform jag använder. Jag har gått från Arduino till SM32 av just pris och snabbhet. Det jag tycker är perfekt med STM32 är just deras Hardware Abstraction Layer (HAL) där man kan enkelt använda färdiga funktioner för att styra GPIO pinnar. Man behöver inte vara någon C-expert eller ens hålla på med bitoperationer med STM32. Undantag kanske finns t.ex. SPI, I2C osv när man behöver ange hex eller binärt för att tala med någon extern enhet.

Men har PIC, AVR 8080 osv Hardware Abstraction Layer ? Eller gäller det att dyka sig ned i databalet och hitta de 1:or och 0:or som man behöver för att tända en lampa?


Upp
 Profil  
 
InläggPostat: 16.49 2019-01-02 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 37755
Ort: Söderköping
HAL är programvara, det är inget som är inbyggt i, eller kommer med, hårdvaran.
Man kan så klart skriva en HAL till vilken hårdvara som helst, om det är motiverat...


Upp
 Profil  
 
InläggPostat: 17.01 2019-01-02 
Användarvisningsbild

Blev medlem: 22.59 2012-09-11
Inlägg: 2889
Ort: The U.S - Chicago
Blir enklare. Man slipper hålla på med krångel. :)


Upp
 Profil  
 
InläggPostat: 17.01 2019-01-02 
Användarvisningsbild

Blev medlem: 18.17 2004-02-11
Inlägg: 9246
Ort: Knivsta
Du får det att låta som att det krävs något stöd i hårdvaran, det är ju bara frågan om någon tyckt att det varit lönt att skriva ett bibliotek för att hantera hårdvarufunktionerna.
Eftersom det kostar massor av klockcykler är det ovanligare på mindre system, där man helt enkelt inte har råd att förenkla för högnivåprogrammerare.

AVR har ju arduino som ju kan ses som samma sak...

STM32 HAL är såklart tillgänglig som källkod, det tar inte mycket genombläddring innan man inser hur otroligt mycket extra kod som exekveras för att göra det möjligt att supporta många av de mode som hårdvaran klarar.
Men har man råd att slänga i mer kisel för att kompensera för sin högnivåkodningsstil så är det ju trevligt..
Sen är ju frågan hur vältestat HAL:en är i just ditt användarfall, tidigare versioner har jag hittat buggar i bara genom att köra UARTEN i standardmode.

Leverantören vill ju också binda fast din kod hårdare mot deras µC, och på så sätt öka kostnaderna för att välja någon annans cortex uC.

Jag föredrar att skriva min HAL funktioner själv för att veta vad de faktisk manipulerar för register, kräver mer läsning av datablad, men också en större förståelse när saker inte funkar....


Upp
 Profil  
 
InläggPostat: 17.11 2019-01-02 
Användarvisningsbild

Blev medlem: 22.59 2012-09-11
Inlägg: 2889
Ort: The U.S - Chicago
Tack! Det var bra förklarat. Så om man väljer STM's HAL så blir man låst till STM produkter och skulle man vilja köra andras plattformar så är man på noll igen?


Upp
 Profil  
 
InläggPostat: 17.26 2019-01-02 
Användarvisningsbild

Blev medlem: 18.17 2004-02-11
Inlägg: 9246
Ort: Knivsta
Va fan Bundy, blev du träffad av en raket vid nyår, säg inte att du faktisk läste någon annans inlägg 8)


Upp
 Profil  
 
InläggPostat: 17.27 2019-01-02 
Användarvisningsbild

Blev medlem: 22.59 2012-09-11
Inlägg: 2889
Ort: The U.S - Chicago
Kæften ;)
Ni övriga är så blinda och tror att man kan svara på allt. Bortskämdhet :P


Upp
 Profil  
 
InläggPostat: 17.39 2019-01-02 
Användarvisningsbild

Blev medlem: 18.06 2010-05-17
Inlägg: 8922
Ort: Växjö/Alvesta
Al_Bundy skrev:
Tack! Det var bra förklarat. Så om man väljer STM's HAL så blir man låst till STM produkter och skulle man vilja köra andras plattformar så är man på noll igen?


Tillbaka på noll, knappast.
I de flesta program så är ju bara en bråkdel av koden på något sätt hårdvaruberoende. Att porta ett välskrivet program till en annan plattform är ofta inget större problem, får bara göra om några få funktioner (de som styr hårdvara).


Upp
 Profil  
 
InläggPostat: 17.59 2019-01-02 
Användarvisningsbild

Blev medlem: 22.59 2012-09-11
Inlägg: 2889
Ort: The U.S - Chicago
Kanske när det gäller mig. Jag är egentligen inte hårdvaruprogrammerare över huvud taget. Jag läste mer matematik än programmering.


Upp
 Profil  
 
InläggPostat: 18.13 2019-01-02 

Blev medlem: 21.06 2011-01-29
Inlägg: 863
Låst blir man inte. Däremot kanske du någon gång skulle vilja uppgradera processorn. Då blir det mindre jobb att gå från ST till ST än från ST till någon annan tillverkare. Det finns även en viss övertro hos vissa att bara för att koden kommer direkt från ST skulle den vara bättre än något man kan göra själv.
Detta kanske gör att nästa processor också blir en ST även om det finns billigare eller bättre alternativ. Det är detta man kallar inlåsningseffekt.


Upp
 Profil  
 
InläggPostat: 19.04 2019-01-02 
EF Sponsor
Användarvisningsbild

Blev medlem: 22.54 2006-09-23
Inlägg: 31866
Ort: Borås
Du måste alltid i alla lägen ha någon variant av HAL, eftersom du på ett eller annat sätt måste beskriva den fysiska layouten för programmet.
Om man sedan kallar det för HAL eller nåttt annat är rätt ointressant.
HALen kan vara allt från nån enstaka #define till mer avancerade konstruktioner.


Upp
 Profil  
 
InläggPostat: 19.13 2019-01-02 
Användarvisningsbild

Blev medlem: 11.03 2007-09-10
Inlägg: 9159
Ort: Alingsås
Klas-Kenny skrev:
Al_Bundy skrev:
Tack! Det var bra förklarat. Så om man väljer STM's HAL så blir man låst till STM produkter och skulle man vilja köra andras plattformar så är man på noll igen?


Tillbaka på noll, knappast.
I de flesta program så är ju bara en bråkdel av koden på något sätt hårdvaruberoende. Att porta ett välskrivet program till en annan plattform är ofta inget större problem, får bara göra om några få funktioner (de som styr hårdvara).

Vet inte om jag håller med om det där. Mina försök att programmera 32-bitars MCU via "HAL" brukar sluta med 10k-rader med obegriplig kod som hanterar en väldigt unik HAL samt 1k.rader som utför själva funktionen. Jag kan alltså återanvända max 10% av koden. Resten får jag göra om beroende vilken µ-controler jag ska använda.


Upp
 Profil  
 
InläggPostat: 19.33 2019-01-02 
Användarvisningsbild

Blev medlem: 18.06 2010-05-17
Inlägg: 8922
Ort: Växjö/Alvesta
Jesse: Jag använder i princip aldrig tillverkarens rutiner utan skriver mina egna.

Ska man då använda tex. SPI, så landar det hela till slut i typ en funktion "uint8_t spiWriteByte(uint8_t sendData)", vilket är det enda som behöver skrivas om ifall man byter uC, plus några rader initiering då. Och ett interrupt kanske, men samma sak där, interruptet kan vara i princip likadant oavsett hårdvara.

Eller sätta någon GPIO, så blir det bara en enkel funktion (eller oftast ett macro) för att sätta värdet på den specifika pinnen (setRedLedHigh() eller något). Bara den funktionen som behöver ändras.

Osv osv osv,

Själva "hjärtat" i programmet, som faktiskt gör det jag önskar, kan vara så gott som intakt.


Upp
 Profil  
 
InläggPostat: 19.35 2019-01-02 
Användarvisningsbild

Blev medlem: 14.52 2005-01-10
Inlägg: 23962
Ort: Aabenraa, Danmark
Oftast är det bara hårdvaran som ska "ställas om" vid byte, källkoden som sådan kan fortsatt fungera utmärkt.

Alltså ska man dela upp sin kod i hårdvaru-delen - som oftast gör att man ska läsa - och förstå - datablad.

Jag har gjort en styrning där det blev gjort två versioner hårdvara, den ena med en Fujitsu µC och den andra med en Renesas M16C.

Vid kompileringen användes samma källkod till allt med styrningen och hårdvaru-delen sköttes med et direktiv om vilken kompiler som kördes. Fungerade perfekt.


Upp
 Profil  
 
InläggPostat: 20.04 2019-01-02 
Användarvisningsbild

Blev medlem: 11.03 2007-09-10
Inlägg: 9159
Ort: Alingsås
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 :( )


Upp
 Profil  
 
Visa inlägg nyare än:  Sortera efter  
Svara på tråd  [ 29 inlägg ]  Gå till sida 1, 2  Nästa

Alla tidsangivelser är UTC + 1 timme


Vilka är online

Användare som besöker denna kategori: arvidb, jclr och 2 gäster


Du kan inte skapa nya trådar i denna kategori
Du kan inte svara på trådar i denna kategori
Du kan inte redigera dina inlägg i denna kategori
Du kan inte ta bort dina inlägg i denna kategori
Du kan inte bifoga filer i denna kategori

Sök efter:
Hoppa till:  
    Electrokit
Drivs av phpBB® Forum Software © phpBB Group
Swedish translation by Peetra & phpBB Sweden © 2006-2010