Första exempelkoden...

[sodjan]

Jag hittade ett datablad för DMC20434 och även om det inte finns några
exempel, så står det vid pin-beskrivningen att både 8 och 4 bitars
mode fungerar. Så det borde gå att använda vilken HD44780 instruktion
som helst.

[JimmyAndersson]

Snyggt!

Bra kommenteringar. Jag skulle iofs ha velat ha några fler rader med ***** eller mellanrum så att man hittar de olika 'delarna' ännu lättare. Såg först inte var lcd_toggle_E börjar vid en snabb koll, men sånt kosmetiskt kanske är en smaksak iofs.

Gillade bakgrunden och typsnittet. Mycket snällt för ögonen.

[Landrash]

Tar tillbaka mitt om att det behövs ännu enklare kod nu när jag tog mig tid att läsa allt så kan jag bara sägza att det var alldelles perfekt

[sodjan]

Nej, jag är inte heller helt nöjd med *ordningen* på de olika "subbarna".
De skulle legat mer logiskt och bättre separerat. Jag var också på gång
med att lägga alla LCD_* subbar i en separat fil, men å andra sidan så
tänker jag göra ett separat exempel för hur man skrivar kod som ligger
i flera ASM filer, så det fick vara. Men det hade blivit snyggare...

[Bosen]

>men å andra sidan så
tänker jag göra ett separat exempel för hur man skrivar kod som ligger
i flera ASM filer

Det låter som en jättebra idé... för jag har lite funderingar på hur det fungerar...

[Johan.o]

Är det bara jag som kör 'absolute code' nu för tiden?

'Relocatable code' är dock väl värt att lära sig,
där har du föresten något att skriva en liten uppsats om

[sodjan]

Jo, tanken är att visa "samma" kod i båda formaten "side-by-side" så
att skillnaderna tydligt syns. Men tillsvidare har jag följande lilla beskrivning:
http://www.jescab.se/Rellocmode.html
Inte helt bra och tydlig, men den ger kanske en liten ide...

[sodjan]

Se : http://www.jescab.se/abs_reloc.html

Säg gärna till om någon blev otydligt !

Och som jag skriver på sidan, det är svårt att visa alla
fördelarna med en så pass kort kod. *Skillnaderna*
hoppas jag dock framgår...

[Bosen]

skitbra...
...men just själva .lnk-filen... Den behöver man editera själv eller???
eller sköter den sig helt själv???

EDIT:
Vid närmare eftertanke så hadde du ju skrivit:"Dessa LNK filer ligger i installationskatalogen för MPLAB."
Det betyder väl antagligen att man behöver inte röra den lnk-filen utan den är specifik för varje PIC... Är jag på rätt väg?

[sodjan]

Helt rätt.

(Jag ser att jag har kallat LKR för LNK igen... Shit. Det är rättat på sidan nu...)

LKR filen innehåller information om hur minnet "ser ut" för varje individuell PIC.

D.v.s t.ex hur mycket Flash det finns och hur mycket RAM (och hur det
är organiserat).

Så när man säger att man vill ha ett par variabler i "unbanked memory"
(genom att ange UDATA_SHR), så kommer länkaren att leta i LKR filen
efter "SHAREBANK" för att se vilka adresser det är i just den processorn.

Om man vill placera variabler i "banked memory" så kör man med "UDATA",
men får då inte glömma BANKSEL innan man använder dom. Länkaren
kommer då att leta efter en "DATABANK" där det finns plats över/ledigt.
(OBS inte en "DATABANK" som är "PROTECTED" !!)

Man kan även styra variabler till en viss bank genom att skriva t.ex
"gpr0 UDATA", då kommer länkaren att lägga dessa "gpr0". Se LKR
filen nedan var gpr0 finns med !

För större projekt är det inte helt ovanligt att man gör en projekt specifik
LKR fil där man t.ex lägger in egna kod och data segment för placerng av
tabeller i flashminnet eller RAM-segment för att lägga större
varabelstrukturer ("arrayer"). Om man sedan vill flyta koden till en annan
processor så kan det gå genom att bara göra en ny LKR för den processorn
utan att ändra källkoden (allt för mycket).

Hur som helt, manualen för MPLINK (samma som för MPASM) har
alla detaljer...

Här en LKR'en för 628A som referens...

Kod: Markera allt

// Sample linker command file for 16F628
// $Id: 16f628.lkr,v 1.4 2006/02/04 00:06:40 nairnj Exp $

LIBPATH  .

CODEPAGE   NAME=vectors   START=0x0      END=0x4      PROTECTED
CODEPAGE   NAME=page      START=0x5      END=0x7FF
CODEPAGE   NAME=.idlocs   START=0x2000   END=0x2003   PROTECTED
CODEPAGE   NAME=.config   START=0x2007   END=0x2007   PROTECTED
CODEPAGE   NAME=eedata    START=0x2100   END=0x217F   PROTECTED

DATABANK   NAME=sfr0      START=0x0      END=0x1F     PROTECTED
DATABANK   NAME=sfr1      START=0x80     END=0x9F     PROTECTED
DATABANK   NAME=sfr2      START=0x100    END=0x11F    PROTECTED
DATABANK   NAME=sfr3      START=0x180    END=0x19F    PROTECTED

DATABANK   NAME=gpr0      START=0x20     END=0x6F
DATABANK   NAME=gpr1      START=0xA0     END=0xEF
DATABANK   NAME=gpr2      START=0x120    END=0x14F

SHAREBANK  NAME=gprnobnk  START=0x70     END=0x7F
SHAREBANK  NAME=gprnobnk  START=0xF0     END=0xFF
SHAREBANK  NAME=gprnobnk  START=0x170    END=0x17F
SHAREBANK  NAME=gprnobnk  START=0x1F0    END=0x1FF

SECTION    NAME=STARTUP  ROM=vectors     // Reset and interrupt vectors
SECTION    NAME=PROG     ROM=page        // ROM code space
SECTION    NAME=IDLOCS   ROM=.idlocs     // ID locations
SECTION    NAME=DEEPROM  ROM=eedata      // Data EEPROM

[Landrash]

Intressant och otroligtn lätt läst.

[sodjan]

Justerat lite och lagt til MAP filen...

[Greve Hamilton]

Kul initiativ! Välkommenterat och fint, det gör att jag nästan vill snöa ner mig i assembler och lära mig det "på riktigt".

[nole]

Bra initiativ och mycket god läsning...


Men jag tycker att kalla Unix och C för garageprodukter ( eller ens linux ) var felaktigt och om nu Unix och C blev utvecklade i ett garage vill jag gärna se de källor detta påstående baseras på.

[Micke_s]

offtopic:
http://en.wikipedia.org/wiki/C_(programming_language)


edit: verkar inte svälja länken i huvudtaget