Icecap, du använde ju själv Basic i ETT PAR ÅR.
Vem vet var du hade jobbat med nu om du hade börjat på något med mycket högre inlärningströskel.
Hur många procent av dom nybörjare som följer forumets standardråd A1, wisp-pic-assembler, kommer längre än "blinka lysdiod"?
Programmera 8048 med JAL
Mitt första PIC bygge som fick mig att bli riktigt intresserad var när jag kopplade en display som skrev ut vilken av dom 4 dioderna som var tända:)
Den skrev ut : YELLOW LIGHT och då lös dioden som var gul:)
Så kunde jag byta vilken som skulle vara tänd med nåra få knappar
Fast jag kör med basic fortfarande,men inne på mitt halvår med pic proccesorer så:)
Den skrev ut : YELLOW LIGHT och då lös dioden som var gul:)
Så kunde jag byta vilken som skulle vara tänd med nåra få knappar
Fast jag kör med basic fortfarande,men inne på mitt halvår med pic proccesorer så:)
Var ju illa tvungen, det var ju allt som fanns på den tiden. Jag vet att jag inom ca: 2 år var så utled på BASIC att jag investerade ca: 68k i ett expansionskit + Pascal som medgav att jag kunde köra CP/M80 2,2 och kompilera i Pascal.
Och jag hade diskdriver, 5,25" floppy!!!! Minsann! 2 STYCKEN OCKSÅ!!!
Efter den tid var jag vaccinerat mot BASIC, den hade visat alla sina begränsningar och problem, med ett strukturerat språk som Pascal var det plötsligt möjligt att få jobbet gjort igen.
Att jag inte har "gått vidare" är för att jag är mycket bra på det jag gör och jag tycker att det är kul som fan.
Och jag hade diskdriver, 5,25" floppy!!!! Minsann! 2 STYCKEN OCKSÅ!!!
Efter den tid var jag vaccinerat mot BASIC, den hade visat alla sina begränsningar och problem, med ett strukturerat språk som Pascal var det plötsligt möjligt att få jobbet gjort igen.
Att jag inte har "gått vidare" är för att jag är mycket bra på det jag gör och jag tycker att det är kul som fan.
Problemet är väl att man utgår från sina egna upplevelse lite väl hårt, under tidiga 80 talet så satt jag och harvade med assemble när man sen gick över till C i mitten av 80talet fick man ju gjort något också!
Nu sitter jag med C++ från tidiga 90talet vilket är en dröm mot vad assembler var på sin tid!
Mikrochips är nu en annan sak då det enl. mitt tycke inte finns tillräckliga bra verktyg utan man är tvingad att uppfinna hjulet på nytt (assembler) försökte mig på MikroC men där är alldeles för många buggar för att jag skall kunna (vilja) använda det, så en är hänvisad till att uppfinna hjulet igen, vill säja assembler!
Beroende av förkunskap så träder man ju in i denna värld med olika förutsättningar Basic passar en del, C andra samt eliten tar assembler, när man är nere i lågnivå språket så bör man också ha en bra kännedom om hårdvaran vilket inte alla har som vill prova på denna värld, ett högnivå språk hjälper till att komma in i denna värld. Om man skall svara så bör svaret hjälpa frågeställaren, sen skall man givetvis också tipsa om vad man själv tycker är lämpligt men inte tvinga på olika lösningar utan sakligt tipsa om lämpliga metoder.
.
Nu sitter jag med C++ från tidiga 90talet vilket är en dröm mot vad assembler var på sin tid!
Mikrochips är nu en annan sak då det enl. mitt tycke inte finns tillräckliga bra verktyg utan man är tvingad att uppfinna hjulet på nytt (assembler) försökte mig på MikroC men där är alldeles för många buggar för att jag skall kunna (vilja) använda det, så en är hänvisad till att uppfinna hjulet igen, vill säja assembler!
Beroende av förkunskap så träder man ju in i denna värld med olika förutsättningar Basic passar en del, C andra samt eliten tar assembler, när man är nere i lågnivå språket så bör man också ha en bra kännedom om hårdvaran vilket inte alla har som vill prova på denna värld, ett högnivå språk hjälper till att komma in i denna värld. Om man skall svara så bör svaret hjälpa frågeställaren, sen skall man givetvis också tipsa om vad man själv tycker är lämpligt men inte tvinga på olika lösningar utan sakligt tipsa om lämpliga metoder.
.
Vet inte om jag kan bidra så mycket, men 8048 (och 8049) och dess epromvarianter 8748/8749 är verkligen en gammal processorfamilj med många begränsningar. Dom fanns ju för fasen innan 1985 när jag började med mitt första jobb!
Assembler lär man sig med att spendera mycket tid och hårt arbete och många misslyckande och ett jäkla bläddrande i manualen i början. Manualer med söderfallande rygg och uramlade sidor är standardskicket på litteraturen när man håller på med assembler ett tag
mao. mycket tid att spendera för att lära sig väl - och bortslösad tid om man börjar flytta till andra processorfamiljer av kapacitetskäl och måste börja studera in deras assemblemiljöer på nytt där också. Det är en av orsaker som gör att gamla assemblerrävar benhårt vägrar byta processorfamilj trots att plattformen sedan länge är otillräklig... Sedan når asseblerfolket en nivå förr eller senare när man inte klarar att ha benhård kontroll på allting i sin allt mer växande assemblerbiblotek med allokerade variabler mm. som man redan sko-hornat med vaselin 4 gånger för att få plats i 8 k minne sedan 3 år tillbaka etc. och då börjar dom riktigt farliga buggarna komma och programerarna plötsligt ger upp totalt en dag när dom inser att oavsett hur mycket tid de lägger ned så kan de inte hålla efter koden längre... (har sett denna 'krasch' på nära håll i ett litet företag - ganska katatsrofalt för företaget när det sker ...)
Själv anser jag att man skall jobb med assembler så lite som möjligt då olika processorfamiljer har sin egna varianter och hoppa upp till någon C-version så fort som möjligt och programera för plattformsoberoende så mycket som möjligt. Det räcker med bläddrandet i assembler-manualen just när man skall fixa några primitiver i startupsekvensen för C-koden och kanske någon optimering i någon tidsskritisk del om inte utvecklingspaketet har fixat allt innan redan.
Trots allt så är ju 'C' en slags plattformsoberoende generisk 'macroassembler' om man vill hårddra det, det är också därför den är så populär inom microkontrollervärlden då det går att programera ganska 'assemblerlikt' om man ger sig fasen på detta eller av nöden tvungen som tex. 8 level stack och 32 byte ram och 2 kbyte prom att leka med totalt - ingen OO-språk kan ta sådana trånga miljöer - medan C med lite assembler som hjälp så kan man faktiskt klara detta.
kebabpizza:
Om du vill börja med microkontroller mer seriöst så anser jag i allafall att du bör hoppa till 'C' så fort som möjligt, gärna på mer vettig microkontrollerfamilj som andra redan har tjatat om, när du är mogen för detta och känner att du börja få något alls att att fungera med JAL och 8748, och kanske redan stött på några av begränsningarna....
Oavsett om det är JAL, C eller annat språk så kräver programspråk instudering och expriment med många misslyckande under ganska många timmar, och själv skulle jag satsa dessa timmar på att lära C från början, trots att det till en början upplevs krångligare, då C-kunnandet är kommersiellt mer gångbar kompetens i arbetslivet. Ingen har hört talas om JAL där - jag lovar.
Assembler lär man sig med att spendera mycket tid och hårt arbete och många misslyckande och ett jäkla bläddrande i manualen i början. Manualer med söderfallande rygg och uramlade sidor är standardskicket på litteraturen när man håller på med assembler ett tag
mao. mycket tid att spendera för att lära sig väl - och bortslösad tid om man börjar flytta till andra processorfamiljer av kapacitetskäl och måste börja studera in deras assemblemiljöer på nytt där också. Det är en av orsaker som gör att gamla assemblerrävar benhårt vägrar byta processorfamilj trots att plattformen sedan länge är otillräklig... Sedan når asseblerfolket en nivå förr eller senare när man inte klarar att ha benhård kontroll på allting i sin allt mer växande assemblerbiblotek med allokerade variabler mm. som man redan sko-hornat med vaselin 4 gånger för att få plats i 8 k minne sedan 3 år tillbaka etc. och då börjar dom riktigt farliga buggarna komma och programerarna plötsligt ger upp totalt en dag när dom inser att oavsett hur mycket tid de lägger ned så kan de inte hålla efter koden längre... (har sett denna 'krasch' på nära håll i ett litet företag - ganska katatsrofalt för företaget när det sker ...)
Själv anser jag att man skall jobb med assembler så lite som möjligt då olika processorfamiljer har sin egna varianter och hoppa upp till någon C-version så fort som möjligt och programera för plattformsoberoende så mycket som möjligt. Det räcker med bläddrandet i assembler-manualen just när man skall fixa några primitiver i startupsekvensen för C-koden och kanske någon optimering i någon tidsskritisk del om inte utvecklingspaketet har fixat allt innan redan.
Trots allt så är ju 'C' en slags plattformsoberoende generisk 'macroassembler' om man vill hårddra det, det är också därför den är så populär inom microkontrollervärlden då det går att programera ganska 'assemblerlikt' om man ger sig fasen på detta eller av nöden tvungen som tex. 8 level stack och 32 byte ram och 2 kbyte prom att leka med totalt - ingen OO-språk kan ta sådana trånga miljöer - medan C med lite assembler som hjälp så kan man faktiskt klara detta.
kebabpizza:
Om du vill börja med microkontroller mer seriöst så anser jag i allafall att du bör hoppa till 'C' så fort som möjligt, gärna på mer vettig microkontrollerfamilj som andra redan har tjatat om, när du är mogen för detta och känner att du börja få något alls att att fungera med JAL och 8748, och kanske redan stött på några av begränsningarna....
Oavsett om det är JAL, C eller annat språk så kräver programspråk instudering och expriment med många misslyckande under ganska många timmar, och själv skulle jag satsa dessa timmar på att lära C från början, trots att det till en början upplevs krångligare, då C-kunnandet är kommersiellt mer gångbar kompetens i arbetslivet. Ingen har hört talas om JAL där - jag lovar.
>Trots allt så är ju 'C' en slags plattformsoberoende generisk 'macroassembler' om man vill hårddra det.
Är väl som att lära grisen flyga
Men trots att C är väldigt hårvaru nära vilket borde vara det naturliga språket att lära sig, tyvärr så har inte utvecklingen än kommit ditt hän att man kan använda det på Microchips (PIC) enl. mitt tycke.
Är väl som att lära grisen flyga
Men trots att C är väldigt hårvaru nära vilket borde vara det naturliga språket att lära sig, tyvärr så har inte utvecklingen än kommit ditt hän att man kan använda det på Microchips (PIC) enl. mitt tycke.
Det är inte santatt man måste lära om assembler för varje processor. Grunderna i hur man programmerar är alltid desamma och väldigt många instruktioner finns på alla processorer och utför ungefär detsamma.
Det som skiljer är vilka opkoder som används, samt allt runt omkring. Det håller jag med om kan vara jobbigt när man skall byta mellan olika processorer, men det går att hantera.
Även stora program går att skriva i assembler, har en hel del erfarenhet av detta... Har skrivit en sak med över 1MB källkod och drygt 100K exekverbar fil. 100% assembler för att köras under DOS. Där var aldrig några problem med detta. Allt hänger på att organisera upp det väl.
Assembler är faktiskt ofta det enklaste alternativet när det gäller att hantera saker på bitnivå. Hur gör man en sådan enkel sak som shift eller aritmetik som spänner över flera bytes i C? Givetvis som sträcker sig bortom de fördefinierade variablernas storlek. Eller om man t.ex. vill skifta in några bits åt gången för att sätta samman en byte att skriva till en port.
Det som skiljer är vilka opkoder som används, samt allt runt omkring. Det håller jag med om kan vara jobbigt när man skall byta mellan olika processorer, men det går att hantera.
Även stora program går att skriva i assembler, har en hel del erfarenhet av detta... Har skrivit en sak med över 1MB källkod och drygt 100K exekverbar fil. 100% assembler för att köras under DOS. Där var aldrig några problem med detta. Allt hänger på att organisera upp det väl.
Assembler är faktiskt ofta det enklaste alternativet när det gäller att hantera saker på bitnivå. Hur gör man en sådan enkel sak som shift eller aritmetik som spänner över flera bytes i C? Givetvis som sträcker sig bortom de fördefinierade variablernas storlek. Eller om man t.ex. vill skifta in några bits åt gången för att sätta samman en byte att skriva till en port.
C fungerar alldeles utmärkt till PIC-projekt men självklart: är man på kanten med programminnesstorleken och behöver "tweaka" de sista orden är assembler enda vägen, alla högre nivå språk har ett visst overhead som tar extra plats.
Å andra sidan kan man komma långt med att veta hur man kan minska overheaden.
Å andra sidan kan man komma långt med att veta hur man kan minska overheaden.
Jag tycker iofs idén med JAL var bra. Ett högnivå BASIC-liknande språk optimerat för microcontrollers. Jag hade själv tänkt testat det vid något tillfälle, men kör mest asm nu iomed att jag mest pysslat med enklare project.
Som sagt verkar då version 2 (JALv2) fortfarande "leva" efetrsom det finns några beta-liknande uppdateringar från i år. Det är lite synd det inte har ett större stöd.
Som sagt verkar då version 2 (JALv2) fortfarande "leva" efetrsom det finns några beta-liknande uppdateringar från i år. Det är lite synd det inte har ett större stöd.
-
kebabpizza
- Inlägg: 34
- Blev medlem: 6 maj 2008, 11:25:52
- Ort: Strömstad
Fantastiskt att denna tråd fortfarande lever kvar. Jag har kommit en bit på väg i min programmering, och på uppmaning från flera i denna tråd (samt att jag inte fick det att fungera) har jag gått ifrån JAL. Skriver nu i assembler, och börjar förstå hur det funkar. Kanske blir att jag går över till C eller Pascal senare när komplexiteten växer i mitt projekt, men än så länge har min assemblering funkat. (6 LED och 4 SW med blinkningar i olika form 
)
Skall snart försöka mig på HD44780 (LED/LCD-display), så får vi se hur det går. Programmeraren K8048 har fungerat bra hittills, och jag är nöjd, men upptäckte att den inte klarar så många typer av PIC:s.
Fråga: Om jag skall (i assembler) lagra information i PICens minne, var allokerar jag då detta? Använder 16F627 alt. 16F628 (http://www.kjell.com/filarkiv/SUPPORTPD ... /90574.pdf)
)Skall snart försöka mig på HD44780 (LED/LCD-display), så får vi se hur det går. Programmeraren K8048 har fungerat bra hittills, och jag är nöjd, men upptäckte att den inte klarar så många typer av PIC:s.
Fråga: Om jag skall (i assembler) lagra information i PICens minne, var allokerar jag då detta? Använder 16F627 alt. 16F628 (http://www.kjell.com/filarkiv/SUPPORTPD ... /90574.pdf)
