Programmerar ett projekt. Det är ett äldre projekt som jag ska modernisera en del samt senare införa nya funktioner.
Det består av alla HAL-filer i ett gemensamt bibliotek då det i grunden finns 2-3 projekt som baseras på samma kretslopp med några få ändringar, typ 1 eller 2 ADC-kanaler osv.
Jag har fixat kommandotolken och jag sitter nu med ett problem som jag helt inte fattar.
I filen "STM32G0xx_HAL.h" används en typdef som är:
typedef enum
{
HAL_OK = 0x00U,
HAL_ERROR = 0x01U,
HAL_BUSY = 0x02U,
HAL_TIMEOUT = 0x03U
} HAL_StatusTypeDef;
Denna typdef finns i filen "STM32G0xx_HAL_DEF.h" som såklart inkluderas innan den används.
Jag har testat att lägga in en:
#pragma message "skriv något här"
Det visar att "STM32G0xx_HAL_DEF.h" inkluderas av "STM32G0xx_HAL.h"och används i sin helhet.
Problemet kommer när en funktion definieras:
HAL_StatusTypeDef HAL_Init(void); // Felar
HAL_StatusTypeDef HAL_DeInit(void); // Felar
void HAL_MspInit(void); // OK
void HAL_MspDeInit(void); // OK
HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority); // Felar
Felmeddelandet:
../Drivers/STM32G0xx_HAL_Driver/Inc/stm32g0xx_hal.h:735:1: error: unknown type name 'HAL_StatusTypeDef'
735 | HAL_StatusTypeDef HAL_Init(void);
Jag har uppgraderat min kompiler till nyaste version och jag fattar inte vad fan den gnäller för.
Min uppfattning är att "HAL_StatusTypeDef" inte uppfattas som en "verklig" variabel/funktion.
Problemet är så att det har fungerat tidigare - men inte nu.
Jag har stångad mig tokig på detta, det enda jag omedelbart kan komma på är att byta "HAL_StatusTypeDef" till t.ex. uint8_t och sedan se om det går bra.
Men jag är rimlig säker på att man har använd den typedef för att göra skrivningen enklare/tydligare.
"HAL_StatusTypeDef" används till många funktioner så det ville ju vara bäst att det blir en fix med "HAL_StatusTypeDef".
Så finns det några tips på en vettig lösning?
STM32CubeIDE knas *Löst*
STM32CubeIDE knas *Löst*
Senast redigerad av Icecap 15 november 2024, 14:57:58, redigerad totalt 1 gång.
Re: STM32CubeIDE knas
Har du möjlighet att prova med en äldre version av kompilatorn för att utesluta att den "förbättrats" på något sätt som ger detta problem?
Re: STM32CubeIDE knas
Det kan kanske bli möjligt - men det ändrar inte att om det inte fungerar efter en uppdatering, finns det ett problem med syntax så att låsa sig till en äldre version är ju fel.
Och då det är de normala HAL-filer till STM32 ska det väl fungera på något vis.
Mitt jobb är ju att få projektet up-to-date...
Och då det är de normala HAL-filer till STM32 ska det väl fungera på något vis.
Mitt jobb är ju att få projektet up-to-date...
Re: STM32CubeIDE knas
Jag fattar inte denna mening. Har du behållit biblioteksfiler från en gammal version av CubeIDE ?
Generellt är CubeIDE känslig för "Dubbla funktionsdefinitioner".
Det finns ett antal trådar på nätet kring det där flera pekar på problem med "HAL_StatusTypeDef"
Har du kollat denna tråd ex. https://electronics.stackexchange.com/q ... ized-in-ha
I grunden felet att man direkt inkluderar saker som redan är indirekt inkluderade.
Re: STM32CubeIDE knas
Jag har pillat en hel del med detta och har insett att det beror på ett grundläggande fel i uppbyggnaden av ett projekt och inkluderinger.
Jag har säkrat mig att projektet är 100% lokalt (hade Dropbox med i sökvägar förut) och identifierar de projektspecifika filer som anger funktioner.
Många av de funktioner finns med i andra projekt så jag ska fixa till C-filer så att inte-använda funktioner inte fyller något fastän filen inkluderas i projektet.
På det vis kan jag skapa ett projekt som delar funktioner med andra projekt men ändå bara inkluderar det som behövs.
Så jag närmar mig starkt - och har använd rådet i tråden jag fick serverat. Det har hjälpt - men då vissa filer finns i dublett i olika biblioteker ska jag säkra mig att jag tar bort rätt fil.
Det har tagit lite tid men jag blir nog klar måndag.
Sedan börjar det RIKTIGA jobb med projektet...
Jag har säkrat mig att projektet är 100% lokalt (hade Dropbox med i sökvägar förut) och identifierar de projektspecifika filer som anger funktioner.
Många av de funktioner finns med i andra projekt så jag ska fixa till C-filer så att inte-använda funktioner inte fyller något fastän filen inkluderas i projektet.
På det vis kan jag skapa ett projekt som delar funktioner med andra projekt men ändå bara inkluderar det som behövs.
Så jag närmar mig starkt - och har använd rådet i tråden jag fick serverat. Det har hjälpt - men då vissa filer finns i dublett i olika biblioteker ska jag säkra mig att jag tar bort rätt fil.
Det har tagit lite tid men jag blir nog klar måndag.
Sedan börjar det RIKTIGA jobb med projektet...
Re: STM32CubeIDE knas
Fler funderingar:
I det projekt jag primärt jobbar med, finns det 2 "delar" med det blåa IDE-ikon:
Embeddable128 och SharedSources. <Embeddable128> är ju de källkoder som skapar den exakta funktion som används i projektet.
Det finns <Core> med <Inc> och <Src>, där finns de exakta inställningar för vilken HW som används osv. samt <main.c> och <main.h>
Det finns <Drivers> inkl. underbibliotek som har med HAL och exakt processorfunktion att göra.
=============
SharedSources innehåller <Core> med <Inc>, <SharedFiles> och <Src>.
Våran (deras) tanke var att det rör sig i grunden om ett antal lite olika projekt som baseras på samma grundfunktion men har olika antal mätkanaler, ADC, DAC osv.
=============
Tyvärr har någon blandad ihop en hel del och jag ska städa.
Min tanke på lösning är:
* De specifika funktioner i projektet ska vara under "huvudprojektet", i detta fall "Embeddable128". Det betyder att alla typnummer osv. anges i main.h eller liknande och att main.c håller anrop till själva funktionerna som får allt att köra, alltså en "normal" mani-funktion.
* Då MÅÅANGA av dessa funktioner är gemensamma för dessa projekt (tänk beräkningar på insamlade data, kommunikation osv.) ska detta källkod-filer finnas i den gemensamma delen.
* Alla HAL-funktioner ska uteslutande finnas i den gemensamma delen.
- Detta betyder alltså att <drivers> ska tas bort ifrån <Embeddable128>.
Jag har hittat hur jag ställer in inkluderings-biblioteker osv., det jag eg. mest undrar är om är:
* Ska SharedSources uppträda som ett "projekt" ihop med Embeddable128?
- Jag tycker att det logiska ville vara att bara inkludera länk till de gemensamma bibliotek i "huvudprojektet" och därmed bara ha ett projekt i projektet.
* Är det typisk för STM32CUBE att skapa detta setup? Alltså med fler projekt i ett o samma projekt?
- Typ pissar jag mot vinden i detta?
* Har någon ett typisk bild på ett typisk projekt-setup i STM32CUBE IDE?
- Jag har ENBART våra projekt att utgå ifrån och de är helt klart störda på olika sätt.
Jag vet om att vid att inkludera en gemensam grupp filer kan det finnas filer med funktioner som inte används. Detta vill jag lösa vid att införa en:
#if <funktionsnyckel_till_denna_fils_funktioner>
...massor av källkod...
#endif
och sedan i varje projekts main.c/main.h ha en lista över dessa funktioner med ett värde angivet, då kan jag underhålla en enda version av funktionerna som sedan är gemensamma för alla projekt.
Detta betyder såklart att jag måste skapa några "exempel-filer" så att man enkelt kan starta upp ett nytt projekt - men det är nog otroligt mycket enklare än att ha detta trassel som har blivit skapat här.
I det projekt jag primärt jobbar med, finns det 2 "delar" med det blåa IDE-ikon:
Embeddable128 och SharedSources. <Embeddable128> är ju de källkoder som skapar den exakta funktion som används i projektet.
Det finns <Core> med <Inc> och <Src>, där finns de exakta inställningar för vilken HW som används osv. samt <main.c> och <main.h>
Det finns <Drivers> inkl. underbibliotek som har med HAL och exakt processorfunktion att göra.
=============
SharedSources innehåller <Core> med <Inc>, <SharedFiles> och <Src>.
Våran (deras) tanke var att det rör sig i grunden om ett antal lite olika projekt som baseras på samma grundfunktion men har olika antal mätkanaler, ADC, DAC osv.
=============
Tyvärr har någon blandad ihop en hel del och jag ska städa.
Min tanke på lösning är:
* De specifika funktioner i projektet ska vara under "huvudprojektet", i detta fall "Embeddable128". Det betyder att alla typnummer osv. anges i main.h eller liknande och att main.c håller anrop till själva funktionerna som får allt att köra, alltså en "normal" mani-funktion.
* Då MÅÅANGA av dessa funktioner är gemensamma för dessa projekt (tänk beräkningar på insamlade data, kommunikation osv.) ska detta källkod-filer finnas i den gemensamma delen.
* Alla HAL-funktioner ska uteslutande finnas i den gemensamma delen.
- Detta betyder alltså att <drivers> ska tas bort ifrån <Embeddable128>.
Jag har hittat hur jag ställer in inkluderings-biblioteker osv., det jag eg. mest undrar är om är:
* Ska SharedSources uppträda som ett "projekt" ihop med Embeddable128?
- Jag tycker att det logiska ville vara att bara inkludera länk till de gemensamma bibliotek i "huvudprojektet" och därmed bara ha ett projekt i projektet.
* Är det typisk för STM32CUBE att skapa detta setup? Alltså med fler projekt i ett o samma projekt?
- Typ pissar jag mot vinden i detta?
* Har någon ett typisk bild på ett typisk projekt-setup i STM32CUBE IDE?
- Jag har ENBART våra projekt att utgå ifrån och de är helt klart störda på olika sätt.
Jag vet om att vid att inkludera en gemensam grupp filer kan det finnas filer med funktioner som inte används. Detta vill jag lösa vid att införa en:
#if <funktionsnyckel_till_denna_fils_funktioner>
...massor av källkod...
#endif
och sedan i varje projekts main.c/main.h ha en lista över dessa funktioner med ett värde angivet, då kan jag underhålla en enda version av funktionerna som sedan är gemensamma för alla projekt.
Detta betyder såklart att jag måste skapa några "exempel-filer" så att man enkelt kan starta upp ett nytt projekt - men det är nog otroligt mycket enklare än att ha detta trassel som har blivit skapat här.
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: STM32CubeIDE knas
Nu tror jag att jag börjar få koll på läget.
Jag har tagit bort HAL-filerna från det direkte projekt-bibliotek, då används bara den gemensamma version i projektet.
Jag har tagit bort "tomma" filer - typ main.c osv. som inte används då den "riktiga" finns i projektet och de bara är tomma "maller".
Jag håller på att fixa sökvägar och biblioteksvägar så att projektet användar de rätta filer och att de gemensamma bara finns i original.
Nu ska jag se till att de nycklar som anger vilka HAL-funktioner som används blir tagit in i projektet i starten, sedan bör jag vara i mål.
Jag har tagit bort HAL-filerna från det direkte projekt-bibliotek, då används bara den gemensamma version i projektet.
Jag har tagit bort "tomma" filer - typ main.c osv. som inte används då den "riktiga" finns i projektet och de bara är tomma "maller".
Jag håller på att fixa sökvägar och biblioteksvägar så att projektet användar de rätta filer och att de gemensamma bara finns i original.
Nu ska jag se till att de nycklar som anger vilka HAL-funktioner som används blir tagit in i projektet i starten, sedan bör jag vara i mål.
Re: STM32CubeIDE knas
Tydligen finns det inte många som jobbar med STM32CubeIDE - men jag chanser:
Finns det något sätt att få kompileringen att ske i en (relativ) given sekvens?
Typ filerna i bibliotek x först, sedan "drivrutinerna".
Finns det något sätt att få kompileringen att ske i en (relativ) given sekvens?
Typ filerna i bibliotek x först, sedan "drivrutinerna".
-
kodar-holger
- EF Sponsor
- Inlägg: 962
- Blev medlem: 26 maj 2014, 12:54:35
- Ort: Karlskoga
Re: STM32CubeIDE knas
Ingen aning om svaret. Är nybörjare själv på den miljön själv och tycker kanske att den har en del förbättringspotential. Bygger dessutom allt jag gör i samma projekt så har inte ens funderat på problemet.
Det är ju eclipse som hanterar själva byggandet så det kanske går att googla på problemet från det hållet.
Sen har jag faktiskt ibland lyckats får ChatGPT att inte bara hallucinera. Kan vara värt att testa om du orkar skriva en bra fråga.
I Visual-studio som jag jobbar i dagarna i ända sätter man upp beroenden mellan projekten i en solution och sen räknar miljön själv ut vilken ordning det måste kompileras. Kanske finns något liknande för projekt i samma workspace i eclipse.
Det är ju eclipse som hanterar själva byggandet så det kanske går att googla på problemet från det hållet.
Sen har jag faktiskt ibland lyckats får ChatGPT att inte bara hallucinera. Kan vara värt att testa om du orkar skriva en bra fråga.
I Visual-studio som jag jobbar i dagarna i ända sätter man upp beroenden mellan projekten i en solution och sen räknar miljön själv ut vilken ordning det måste kompileras. Kanske finns något liknande för projekt i samma workspace i eclipse.
Re: STM32CubeIDE knas *Löst*
Nu har jag fått projektet att kompilera.
Jag testade med testutskrifter (#pragma message ("någon text")) och insåg att de funktioner som behövdes inte blev aktiverat då deras C-fil har en:
#if defined <någon flagga för om denna funktion behövs>
...en shitload C-kod för funktionen
#endif
Men flaggorna blev först definierad EFTER dessa filer blev kompilerat.
Jag inkluderade då en #include "stm32g0xx_hal_conf.h" i alla dessa filer och *POOOFFF* - allt kompilerade.
Resultatet (hex-filen) verkar vara av OK storlek så jag tycker att vi verkar vara i mål.
Jag har sedan moddad stm32g0xx_hal_conf.h en del vid att införa en lista med projekt-typer och sedan slå på de HAL-funktioner som varje projekt behöver och ha projekt-versionen definierat i main.h.
Då kommer en given projekt-typ att automagisk aktivera de HAL-funktioner som behövs.
Då kan stm32g0xx_hal_conf.h vara en gemensam fil för alla projekt och därför kan kan minska de projekt-specifika filer med iaf. 1 fil.
Nu börjar projektet att kunde få de nya funktioner som är orsaken till allt detta jobb.
Jag har redan benat ut kommando-tolk delen och tagit bort en hel del filer som var överflödiga eller dubletter.
Jag har redd ut vilka sökvägar som ska finnas i ett projekt, nästa del är att dokumentera detta i ett officiellt dokument för vidare framgång.
Mycket jobb - men känns ganska framtidssäkrat.
EDIT:
Att HEX-filen (eg. .ELF) är jag dock lite tveksam till. Originalen är runt 1.5MB och "min" ligger kring på 72.4kB.
Jag misstänker dock att denna skillnad beror på att jag har tagit bort alla printf.h funktioner, alla string.h funktioner, en större mängd upprepande texter och en del annat.
Dessa har jag sedan löst med egna rutiner som jag anser är mer effektiva.
Imorgon kommer att visa om jag har missat totalt eller förbättrat något.
En rolig grej var att den förre programmör hade gjort en rutin för att omvandla ett värde till en textsträng.
Hans version delade först värdet med 1000000000000000000 och använde resultatet som första siffra.
Sedan dela med <1 noll mindre> och upprepa.
Jag gick andra vägen:
Reservera en liten buffer med plats nog för alla de maximalt 21 tecken som kan bli (uint64_t) + EOL.
Peta in EOL på sista platsen, peka ett steg upp o peta in en '0'.
Sedan upprepa så länge värdet är >0:
* Ta värdet modolus 10.
* Lägg till '0' o peta in i buffern, samt räkna buffer-pekaren ner ett steg.
* Värdet = värdet / 10
När det är klart är det bara att skriva ut buffern från pekarplaceringen och saken är biff.
Min version räknar ut "ettorna" först och skapar strängen baklänges. Ganska säker på att "min" version är MINST lika snabb och använder mindre ROM.
Jag testade med testutskrifter (#pragma message ("någon text")) och insåg att de funktioner som behövdes inte blev aktiverat då deras C-fil har en:
#if defined <någon flagga för om denna funktion behövs>
...en shitload C-kod för funktionen
#endif
Men flaggorna blev först definierad EFTER dessa filer blev kompilerat.
Jag inkluderade då en #include "stm32g0xx_hal_conf.h" i alla dessa filer och *POOOFFF* - allt kompilerade.
Resultatet (hex-filen) verkar vara av OK storlek så jag tycker att vi verkar vara i mål.
Jag har sedan moddad stm32g0xx_hal_conf.h en del vid att införa en lista med projekt-typer och sedan slå på de HAL-funktioner som varje projekt behöver och ha projekt-versionen definierat i main.h.
Då kommer en given projekt-typ att automagisk aktivera de HAL-funktioner som behövs.
Då kan stm32g0xx_hal_conf.h vara en gemensam fil för alla projekt och därför kan kan minska de projekt-specifika filer med iaf. 1 fil.
Nu börjar projektet att kunde få de nya funktioner som är orsaken till allt detta jobb.
Jag har redan benat ut kommando-tolk delen och tagit bort en hel del filer som var överflödiga eller dubletter.
Jag har redd ut vilka sökvägar som ska finnas i ett projekt, nästa del är att dokumentera detta i ett officiellt dokument för vidare framgång.
Mycket jobb - men känns ganska framtidssäkrat.
EDIT:
Att HEX-filen (eg. .ELF) är jag dock lite tveksam till. Originalen är runt 1.5MB och "min" ligger kring på 72.4kB.
Jag misstänker dock att denna skillnad beror på att jag har tagit bort alla printf.h funktioner, alla string.h funktioner, en större mängd upprepande texter och en del annat.
Dessa har jag sedan löst med egna rutiner som jag anser är mer effektiva.
Imorgon kommer att visa om jag har missat totalt eller förbättrat något.
En rolig grej var att den förre programmör hade gjort en rutin för att omvandla ett värde till en textsträng.
Hans version delade först värdet med 1000000000000000000 och använde resultatet som första siffra.
Sedan dela med <1 noll mindre> och upprepa.
Jag gick andra vägen:
Reservera en liten buffer med plats nog för alla de maximalt 21 tecken som kan bli (uint64_t) + EOL.
Peta in EOL på sista platsen, peka ett steg upp o peta in en '0'.
Sedan upprepa så länge värdet är >0:
* Ta värdet modolus 10.
* Lägg till '0' o peta in i buffern, samt räkna buffer-pekaren ner ett steg.
* Värdet = värdet / 10
När det är klart är det bara att skriva ut buffern från pekarplaceringen och saken är biff.
Min version räknar ut "ettorna" först och skapar strängen baklänges. Ganska säker på att "min" version är MINST lika snabb och använder mindre ROM.
Re: STM32CubeIDE knas *Löst*
Jag har nu fått "hål" på projektet. Det har varit mycket stupiditet i filer, sökvägar, vad som är projekt-specifikt och vad som är gemensamt för många projekt.
Men jag är på plats och får nu respons på mina kommandon.
Jag har lagt om hur man definierar vilket projekt som kompileras, tidigare var det nog at köra en
#define <projektnamn>
Sedan sker det några val efter om ett givet projektnamn var definierat.
Men fler projekt kunde definieras samtidig vilket vill ge en hel del skit. Jag har därför ändrat till att varje projekt har ett värde och jag anger då projektets värde i ett specifikt flagga.
Då kan bara ETT projekt definieras.
Min kommandotolk fungerar perfekt från starten och sparar signifikant med ROM då varje kommando-ord är definierat en enda gång istället för att vara definierat för varje gång en kommandokombination använda det.
Jag har vänjat mig rimligt till debug-funktionen, den har varit en stor hjälp på vägen.
Men jag är på plats och får nu respons på mina kommandon.
Jag har lagt om hur man definierar vilket projekt som kompileras, tidigare var det nog at köra en
#define <projektnamn>
Sedan sker det några val efter om ett givet projektnamn var definierat.
Men fler projekt kunde definieras samtidig vilket vill ge en hel del skit. Jag har därför ändrat till att varje projekt har ett värde och jag anger då projektets värde i ett specifikt flagga.
Då kan bara ETT projekt definieras.
Min kommandotolk fungerar perfekt från starten och sparar signifikant med ROM då varje kommando-ord är definierat en enda gång istället för att vara definierat för varje gång en kommandokombination använda det.
Jag har vänjat mig rimligt till debug-funktionen, den har varit en stor hjälp på vägen.
