Krav på samma "target" i alla ingående filer på nyare MPLab

[vfr]

Jag körde tidigare med MPLab Ver 8.30. När jag bytte till 8.96 så fick jag problem. Och jo, jag vet att båda är "gamla" jämfört med MpLab X. Men Eclipse är ett jäkla härke och jag undviker det så länge jag kan.

På 8.96 så krävs det plötsligt att alla filer skall vara assemblerade och sedan sammanlänkade för samma processorvariant. Annars blir det klagomål. Att man måste ange en processormodell för assemblern kan ju vara förståligt, iaf processorfamilj så att assemblern vet hur den ska assemblera koden och vad den skall ge error för. Men att den måste kräva exakt samma processor känns som överkurs. Finns det egentligen någon anledning till det?

I mitt fall blir det lite jobbigt. Jag har en multitarget-miljö där samma kod används till flera olika "targets". 90% av kodmodulerna är kanske gemensamma, t.ex kommunikationsbibliotek och hantering av andra övergripande funktioner. Sedan finns det givetvis några moduler som är "target"-specifika. Dels några boardsupport-moduler med funktioner som har specifik implementation beroende på vilken typ av kort programvaran går på. Utöver det så finns det en del "target"-specifika moduler som bara länkas med till vissa target.

Allt detta sköts med ett make-skript som assemblerar allting och sedan länkar ihop olika targets av dom assemblerade filerna. Det funkar jättebra och har använts på detta sätt under en längre tid. Fördelen är givetvis att ha en gemensam bas med så lite underhåll av koden som det bara är möjligt. Man ska inte behöva bygga varje sak för sig i en massa olika varianter.

Hela hanteringen är möjlig tack vare att dom olika periferimodulerna i PIC:arna är gemsamma mellan många PIC-modeller i samma familj, UART och timrar t.ex.

Problemet kommer när det nu krävs att alla moduler skall vara både assemblerade och länkade för samma processormodell. Enda sättet att lösa det blir att "fuska" och sätta en gemensam PIC-modell på alla filer oavsett om det egentligen är rätt. Har man t.ex target med 16F877, 16F648, 16F873 så får alla dom 877 som processormodell. Men är det något som egentliga kan bli fel av det så länge det är samma processorfamilj? Isåfall vad?

[swesysmgr]

Visst är Eclipse ett härke men MPLAB X är Netbeans och mycket smidigare att använda.

Kan du inte köra ett "pre-build event" (eller vad det heter) som får device-namnet från miljön och assemblerar ihop rätt versioner? Eller missförstår jag problemet?

[vfr]

Jaha. Är X:en NetBeans? Jag fick för mig hade läst att det var Eclipse. Förr eller senare kommer det ju bli övergång på X, men inte just nu när jag har en fungerande (mer eller mindre iaf innan 8,92) miljö i gamla MPLab.

Var finns "pre-build event"? Är det i X eller gamla MPLab Jag hittar inte så mycket när jag söker på det...

[vfr]

Då fortsätter vi med det här problemet. Jag fick aldrig svar på frågan om "pre-build events". Vad är det och var finns det?

Sedan så kommer det naturligtvis att bli en övergång på MPLabX när allting i projektet är fungerande under X. Nästa fråga berör då det här med länkning av olika targets från samma objektfiler i MPLabX. Hur gör man det? Finns det något sätt att köra en "vanlig" makefil för att bygga ett projekt i MPLabX?

I tidigare MPLab var det inga problem. Iallafall inte förrän det började ställas krav på samma processordefinition i alla länkade filer. Det var bara att skapa en makefil där man kör MPAsm för att assemblera alla ingående filer och sedan länka dom olika "target":arna utifrånfrån objektfilerna. Men hur gör man i X? Går det att göra samma sak där?

[swesysmgr]

Det var "Project"->"Build options"->"Custom build" i gamla MPLab jag tänkte på. Jag fick ladda ner och installera det i en VM för att hitta det. Senaste versionen jag kunde hitta hos Microchip var 8.92. Jag bytte till MPLabX 2011 och har aldrig tittat bakåt

Du kan få hårdvarans namn med $(device) och borde kunna assemblera den enhetsspecifika koden först till ett fast namn som sedan länkas ihop med C-koden?

Det går att anropa en .bat fil (eller annat scriptspråk) och göra lite vad som helst med kommandoradsverktygen, jag tror det går att lösa.

[vfr]

Jag fortsätter i denna tråden då ämnet fortfarande är MPLab och Netbeans.

Hur gör man för att använda relativa sökvägar inom ett projekt?

Man har ett projekt som flera människor jobbar på och checkar in och ut filer efterhand som man jobbar med projektet. Men alla har kanske inte projektets rotmapp liggande på samma ställe. Många utvecklings-IDE använder då relative sökvägar från projektets grundmapp och neråt så är det inget problem. Men Netbeans verkar ha fasta sökvägar till alla projektets ingående filer och då skiter sig detta. Det går inte att bara checka ut ett projekt som någon skapat där projektmappen ligger någon annanstans.

Eclipse gör ju tyvärr samma sak. På alla andra verktyg som jag är van att jobba i så är sökvägen relativ ner till underliggande filer i ett projekt. Bara för att ta ett exempel så säger vi Borland Builder som jag använt jättemycket. Inga som helst problem att flytta hela projektet någon helt annanstans och kompilera det.

[janno]

Jag var tvungen o titta i mitt senaste MplabX projekt och det mesta/(allt?) verkar vara relativa sökvägar i projektet. Det som jag inte hade relativa sökvägar till var till compilern i "Makefile-local-default.mk', kommentaren i överst i filen så står det att checkar man in den filen så kan andra ha problem att bygga projektet.
Jag har inte gjort något speciellt när jag skapade projektet.

[vfr]

Okey. Då frågar jag dig som tittat, var hittar man dessa pathar någonstans efter att projekt är uppsatt? Någon konfigfil?


Edit: En annan fråga till dig. Har du provat att bara flytta projektet till en annan katalog och bygga det där? Det är i min värld en test på om det verkligen är relativa sökvägar överallt där det behövs i projektet.

[janno]

I foldern nbproject (ligger i ditt MplabX projekts folder) har du alla makefilerna (mk) och projektfilerna (xml). Jag har kopierat projekt mellan maskiner tidigare och kan inte minnas att jag haft något större problem. Jag tror att jag var tvungen att tala om vilken compiler den skulle använda, jag hade dock olika versioner av dem på de burkarna så det kändes "naturligt". Dessa projekt är relativt små då de endast är på hobbynivå.

[vfr]

Tack!

Jo, att flytta mellan maskiner kan ju vara ganska rakt på sak. Om det är samma användare, du, som gör det och inga andra faktorer inverkar så kanske man placerar det på samma plats på båda maskinerna. Och då är det ju inga problem. Frågan gällde om det fortfarande fungerar när man har olika rotkataloger för projektet, vilket ställer krav på relativa sökvägar.

[sodjan]

Jag undrar om det kan vara skillnad beroende på om man kör med den projektkatalog
som MPLABX tillhandahåller som default (med rellativa sökvägar?), så som janno verkar
köra, eller man (som jag gör och som det låter att vfr gör) vill skapa och använda projekt
helt utanför systemkatalogerna? Och att MPLABX *då* lägger in fulla sökvägar...

[vfr]

Det kan ju vara en bra tanke. Sedan tycker jag väl inte att det känns som en helt korrekt orsak till det ändå, även om det kan vara så. Projektet är i min värld sin egen lilla blobb som inte borde vara beroende av var projektets rotkatalog är placerad.

Jag får se om jag hittar några sökvägar i projektfilerna som sedan går att ändra.

[janno]

På ena maskinen som jag flyttat ifrån så var katalogerna default för MplabX. Den andra installationen har jag pekat ut foldrar på annan disk när jag installerade MplabX. Det är en flyttbar disk och den har bytt enhetsbokstav på disken en gång o då var jag tvungen o fixa om bokstäverna till original för att MplabX skulle kunna starta (eller MplabX startade om man körde exe filen direkt, med genvägen var ju så klart trasig) och projekten gick att öppna men sökvägarna till compilern var också trasiga.
Däremot ligger alla c/h filer relativt (under) till projektetets katalog.

[sodjan]

> ...på annan disk när jag installerade MplabX.

OK, men det var inte det jag talade om.
Utan var projektet hamnar när man skapar ett nytt projekt.
Inte var man väljer att installera MPLABX i sig...

[baron3d]

Skriver om .mcp:filen och ändrar filnamnen.
I projektmappen: "RegOut_task.c"
I mappen COMMON: "..\COMMON\MB_Out_task.c"