Frågor om gpasm och andra program.

[BJ]

Jag tänkte prova assembler-programmering med pic-processorer i linux lite.
Jag hittade gpasm. Den verkar inte klara allt som mpasm kan?

Om det står så här på en rad i assembler-filen:

Kod: Markera allt

    LCD_data               equ PORTB    ; LCD data      = port B.

aå skriver den "Error [103] syntax error".
Använder inte gpasm samma direktiv och kommandon som mpasm?
Finns det nåt annat program som man kan använda i så fall?
(Ja, man kan ju köra windows och mplab, men det var inte det jag tänkte på. )

[bearing]

Det måste väl finnas en manual?

EDIT: här http://gputils.sourceforge.net/gputils.pdf

Kanske är den "case sensisitive". Prova

Kod: Markera allt

LCD_data               EQU PORTB

[BJ]

Tack för manualen. Den ska tydligen klara det.

Det gick inget bättre med stora bokstäver...

[Kaggen]

Tror variabler måste stå längs till vänster på raden, annars tolkas det som en assembler instruktion. Inge tab eller mellanslag före LCD_data alltså.

[BJ]

Tack. Då fungerar det.

[vfr]

Det låter ju vettigt. MPASM gör inte så. Där kan en label stå var som helst på raden. Det får till följd att stavar man fel på en instruktion, så får man bara en varning om "label ej på kolumn 1" eller nåt sånt. Då bryter inte en make när det egentligen är ett grundläggande fel i koden, utan den assemblerar glatt men hoppar över instruktionen eftersom det är en label.

[sodjan]

> Det låter ju vettigt. MPASM gör inte så. Där kan en label stå var som helst på raden....

Det är ju inget jätteproblem (i vilket fall det sannolikt hade varit åtgärdat).
I dokumentation och exemplen för EQU så är labeln alltid i pos 1.

> Använder inte gpasm samma direktiv och kommandon som mpasm?

Frågan är lite ointressant eftersom du ju i alla fall inte hade kollat upp
syntaxen i MPASM dokumentationen. I så fall hade du väl bara rättat koden.

[vfr]

Använder man makefiler för att bygga koden och därmed använder resultatkoden från programmet så blir det definitivt problem. Jag vet inte hur MPLAB:s interna projekthantering löser det.

[bos]

utan den assemblerar glatt men hoppar över instruktionen eftersom det är en label.

Om det är mnemonics utan argument, ja. Skriver du t.ex "movvlw .42" så får du ett skrikande fel eftersom ".42" inte är en mnemonic.

(Ah, här kom den där label-tråden igen...)

Du är för övrigt den enda jag hört som någonsin haft problem med det där. Hur många gånger har det hänt? En gång, men det tog så mycket tid till felsökning att du tvärsågar hela grejen? Jag har inga problem med att låta labels starta var som helst, även om det innerst inne känns lite inkonsekvent att starta i kolumn icke-1.

Jag vet inte hur du programmerar, om du enbart tittar på tangentbord eller på skärmen, men MPLAB fetmarkerar ju opcodes. Om det jag själv skriver inte blir fett så ser jag det med en gång och kan redan då korrigera det om det skulle behövas. Anstränger man sig bara för att inte felstava mnemonics så blir det inga bekymmer.

[bos]

Förresten, varför använder du make om du använder MPLAB?

Och OM du nu inte använder MPLAB, varför redirectar du inte varningar och fel till en loggfil som du i slutet av make-regeln greppar efter just detta problem?

[vfr]

Du är för övrigt den enda jag hört som någonsin haft problem med det där. Hur många gånger har det hänt? En gång, men det tog så mycket tid till felsökning att du tvärsågar hela grejen?

Japp. Jag har inte sett ett enda argument för att ha det på det sättet. Och antagligen inte så många andra heller eftersom jag inte sett det på någon assembler utom i just MPLAB.

Dessutom anser jag att det är ett så grundläggande fel att det inte skall få finnas minsta möjlighet till att det slipper igenom.

Jag vet inte hur du programmerar, om du enbart tittar på tangentbord eller på skärmen, men MPLAB fetmarkerar ju opcodes.

Opcodes, ja. Men inte makron. Och har man t.ex ett makro där man missat att inkludera definitionen av det makrot så blir det skit iallafall.

Anstränger man sig bara för att inte felstava mnemonics så blir det inga bekymmer

Det var, ärligt talat, ett jävla dumt argument. Även om jag anser mig vara noggrann, så kan det självklart bli fel någon enstaka gång.

[bos]

> så kan det självklart bli fel någon enstaka gång.

Givetvis. Ett tips är därför att läsa varningar. De finns där av en anledning.

[vfr]

Visst är det så. Men min poäng är att ett så kritiskt fel skall ge ett fel och inte en varning. Genom att definiera labels att börja var som helst på raden, så har man omöjliggjort att få ett riktigt felmeddelande på det här. Och just när man kör en make som inte stannar, så kan det bli mycket text som scrollar förbi.

Även om du kan tala om att den skall stanna även på varningar, så är det så att den kanske stannar även när du egentligen har gjort något som är helt ok i det här sammanhanget.

Om vi vänder på frågan. Vad är den stora fördelen med att kunna skriva labels långt in på raden då?

Det blir ju naturligtvis en fråga om prioriteringar. Vad är viktigast, att kunna skriva labels långt in på raderna eller att minimera risken för att fel slinker igenom obemärkt?

[bos]

Jag ser ingen fördel med att ha labels i kolumn icke-ett, men samtidigt har jag aldrig upplevt något krångel med det och därför ser jag det inte som ett problem med att ha det så. Förr i tiden hade MPASM krav på att ha labels i kolumn ett, men jag vet inte varför de släppte efter. Jag läser rätt mycket på EF, PIClist och MC-forumen, och du är som sagt den enda jag sett som haft problem med detta. Själv hade jag ingen aning om det förrän jag läste om det problem du skrev om i en tråd för länge sen. De få gånger jag fått den varningen har jag korrigerat det med en gång och aldrig mer tänkt på det.

Har du kontaktat Microchip och presenterat problemet? Det är ju inte säkert det händer något, men på så vis har du iallafall skickat det till rätt instans. De kanske inte vet om det.