Hmm.... UNDEF, det hade jag missat.
Man måste visserligen själv bestämma vilka register man vill använda men återanvändandet får man iaf kontroll på och man blir varnad om man gjort fel.
Det kanske är den kompletta lösningen för allt detta.
När man skriver ner sina problem kommer ofta lösningen av sig själv.
Men programmerings-tips mottages gärna.
Positions-Display för svarv (AVR)
Varför bara 16 register med vissa instruktioner? för att man inte alltid hade plats för 5-bitars (2^5 = 32) register-id i AVRs 16-bitars instruktionsformat. Tänk själv: du behöver 5 bitar för register och 8 bitar för konstanten, då blir det bara 3 bitar över för instruktionstyp (detta kan du lätt se i databladet!). Eftersom AVR är en RISC gör man inte gärna vissa instruktioner 2x16 bitar långa (det finns undantag dock).
Tycker du att 32 register är för få? x86 hade 8 register, ARM har 16 (inkl stack pekare och retur pekaren LR). 6502 som du hittar i bla C64 hade 3 register (om jag minns rätt). 68K som finns i Amigan hade 8 data register och 8 adress register. PDP-11 hade 8 (hej Sodjan!). Endast MIPS och AVR har 32 register.
Det finns ett bra skäl till det. När programmen blir större måste man överge register-tänket och använda minnet för å lagra data. Register använder man endast för beräkning. Ja, det kan bli en massa pushande och popande
, men det är precis så det ska vara i ett program som är större än, säg, 512 instruktioner...
Det är klart att det blir lite långsammare, men du kan fortfarande köra delar av din kod i register. jag brukar reservera 8-12 register för realtids grejer.
(och ingen tycker att PIC är skit. den börjar bara bli lite gammal för min smak)
/uc
Tycker du att 32 register är för få? x86 hade 8 register, ARM har 16 (inkl stack pekare och retur pekaren LR). 6502 som du hittar i bla C64 hade 3 register (om jag minns rätt). 68K som finns i Amigan hade 8 data register och 8 adress register. PDP-11 hade 8 (hej Sodjan!). Endast MIPS och AVR har 32 register.
Det finns ett bra skäl till det. När programmen blir större måste man överge register-tänket och använda minnet för å lagra data. Register använder man endast för beräkning. Ja, det kan bli en massa pushande och popande
, men det är precis så det ska vara i ett program som är större än, säg, 512 instruktioner...Det är klart att det blir lite långsammare, men du kan fortfarande köra delar av din kod i register. jag brukar reservera 8-12 register för realtids grejer.
(och ingen tycker att PIC är skit. den börjar bara bli lite gammal för min smak)
/uc
"Varför bara 16 register med vissa instruktioner? "
Du behöver inte förklara sånt för mig, jag är fullt medveten om att bitarna inte räcker annars.
Konfliken för mig är egentligen att antal register är för få för att använda dom till både beräkning och lagring men så pass många att man kan utnyttja dom till lagring i vissa fall för att vinna klockcykler.
Jag har alltid varit väldigt optimeringstokig och med den här arkitekturen har jag svårt att bestämma hur jag ska göra.
Om det bara fanns 8st register skulle vi inte haft den här dialogen.
C64 har mycket riktigt 3st register men dessa register fungerar inte som lagring iaf så man har inte samma dilemma där.
(Drömmer mig tillbaka till när allt började, jag köpte en bok som hette programmera 6502, det var tider det)
Undef var en bra pusselbit för temprär data men hur brukar ni göra med in och utdata från funktioner?
Brukar ni använda register eller minnet, pekare eller direkt adressering?
Jag börjar iaf få en bild av hur jag vill programmera assembler men nästa projekt blir nog i C tror jag.
Du behöver inte förklara sånt för mig, jag är fullt medveten om att bitarna inte räcker annars.
Konfliken för mig är egentligen att antal register är för få för att använda dom till både beräkning och lagring men så pass många att man kan utnyttja dom till lagring i vissa fall för att vinna klockcykler.
Jag har alltid varit väldigt optimeringstokig och med den här arkitekturen har jag svårt att bestämma hur jag ska göra.
Om det bara fanns 8st register skulle vi inte haft den här dialogen.
C64 har mycket riktigt 3st register men dessa register fungerar inte som lagring iaf så man har inte samma dilemma där.
(Drömmer mig tillbaka till när allt började, jag köpte en bok som hette programmera 6502, det var tider det)
Undef var en bra pusselbit för temprär data men hur brukar ni göra med in och utdata från funktioner?
Brukar ni använda register eller minnet, pekare eller direkt adressering?
Jag börjar iaf få en bild av hur jag vill programmera assembler men nästa projekt blir nog i C tror jag.
Jag misstog mig ang undef, man får inga varningar om subrutiner använder samma register, det fungerar bara på linjär kod.
Den enda fördelen med undef är att man slipper varningar för fungerande kod.
Så frågan kvarstår hur det är tänkt att man ska kunna hålla koll på alla temporära register när man har många funktioner som anropas?
Jag får väl i annat fall använda hjärncellen men det borde finnas bättre sätt.
Så här gör jag för att "allokera" ram-minne till mina variabler.
Finns det bättre sätt?
#define Variabel1 $100
#define Variabel2 $101
#define Variabel3 $102
Jag sitter inte bara och klagar, jag programmerar oxå
Så här ser det ut för tillfället, BCD-omvandlingen fungerar och jag kan skriva ut det på displayen.
Väldigt tråkig film
hmm.. kom på en sak, Minustecknet ska ju flyttas fram till siffrorna, det ser inte bra ut nu.
Den enda fördelen med undef är att man slipper varningar för fungerande kod.
Så frågan kvarstår hur det är tänkt att man ska kunna hålla koll på alla temporära register när man har många funktioner som anropas?
Jag får väl i annat fall använda hjärncellen men det borde finnas bättre sätt.
Så här gör jag för att "allokera" ram-minne till mina variabler.
Finns det bättre sätt?
#define Variabel1 $100
#define Variabel2 $101
#define Variabel3 $102
Jag sitter inte bara och klagar, jag programmerar oxå
Så här ser det ut för tillfället, BCD-omvandlingen fungerar och jag kan skriva ut det på displayen.
Väldigt tråkig film
hmm.. kom på en sak, Minustecknet ska ju flyttas fram till siffrorna, det ser inte bra ut nu.
Det mer "korekta" sättet är att använda RAMet är
Angånde hur man ska se 32register som workregisteret i picen.
Sedan angånde att and och or portar så är det snarare en fråga kommpremis, exempel sbi som sätter en bit i ett i/o på en klock cykel... troligt viss fick man inte plats med and och or direkt mot i/o :/
Hoppas att det svara några av dinna frågor ^^
Kod: Markera allt
.dseg
MinVariabel: BYTE 1 ;Reserverar en byte i minnet
.cseg
;exempel
lds r16 MinVariabel
Sedan angånde att and och or portar så är det snarare en fråga kommpremis, exempel sbi som sätter en bit i ett i/o på en klock cykel... troligt viss fick man inte plats med and och or direkt mot i/o :/
Hoppas att det svara några av dinna frågor ^^
Finns det några varianter av ".dseg" ?
T.ex för "overlayade" variabler (d.v.s att t.ex temp variabler
i olika subrutiner kan "dela" på samma adress) ? Alltså motsvarande
PIC-asm's UDATA, UDATA_SHR, UDATA_OVR och UDATA_ACS ?
.dseg allokerar alltså inte bland de 32 registren, utan i det övriga RAM-minnet ?
> och ingen tycker att PIC är skit. den börjar bara bli lite gammal för min smak
Dessutom ska man kanske titta lite mer på PIC18 när man jämför med de *större* AVR'erna.
Där har man t.ex tillgång till (ca) 128 register i access-banken, d.v.s alltid utan extra bank-switchning.
Resten av registrerna är också tillgängliga för *alla* instruktioner, men eventuellt efter att ha "satt" rätt bank.
I access-banken har man alltid tillgång till *alla* specialregister (inkl I/O-portar)
och ca 128 byte RAM för *alla* instruktioner (utan extra bankhantering).
Personligen tycer jag detta är en "renare" arkitektur än AVR'ens uppdelning på "register"
(som i sig är uppdelade i grupper med olika funktion/egenskaper) och "RAM"...
(Dessutom är W mappat som ett register WREG, så alla "file" instruktioner
kan även göras direkt mot W. Bit set/clear o.s.v... )
Det om det. Finns ingen anledning att diskutera detta mer här, och jag
skriver inget mer i denna tråd...
(Om det inte blir *alldeles* nödvändigt... )
T.ex för "overlayade" variabler (d.v.s att t.ex temp variabler
i olika subrutiner kan "dela" på samma adress) ? Alltså motsvarande
PIC-asm's UDATA, UDATA_SHR, UDATA_OVR och UDATA_ACS ?
.dseg allokerar alltså inte bland de 32 registren, utan i det övriga RAM-minnet ?
> och ingen tycker att PIC är skit. den börjar bara bli lite gammal för min smak
Dessutom ska man kanske titta lite mer på PIC18 när man jämför med de *större* AVR'erna.
Där har man t.ex tillgång till (ca) 128 register i access-banken, d.v.s alltid utan extra bank-switchning.
Resten av registrerna är också tillgängliga för *alla* instruktioner, men eventuellt efter att ha "satt" rätt bank.
I access-banken har man alltid tillgång till *alla* specialregister (inkl I/O-portar)
och ca 128 byte RAM för *alla* instruktioner (utan extra bankhantering).
Personligen tycer jag detta är en "renare" arkitektur än AVR'ens uppdelning på "register"
(som i sig är uppdelade i grupper med olika funktion/egenskaper) och "RAM"...
(Dessutom är W mappat som ett register WREG, så alla "file" instruktioner
kan även göras direkt mot W. Bit set/clear o.s.v...
)Det om det. Finns ingen anledning att diskutera detta mer här, och jag
skriver inget mer i denna tråd...
(Om det inte blir *alldeles* nödvändigt...
)>Finns det några varianter av ".dseg" ?
Nej, Det behövs inte efter som du har 32 st register som fungerar som "temp variabler", skulle man behöva en till så push man på stacken en som man för tillfället inte använder, Ungefär som en vanlig dator.
>Dessutom ska man kanske titta lite mer på PIC18 när man jämför med de *större* AVR'erna.
Nu tycker jag att en ATmega48 (den som används här) inte är speciellt stor, 27.20kr + moms på elfa vilket inte är så farligt. Den är ganska lite flash, 4kbyte (vilket motsvarar < 2k instruktioner ).
Eller en ATtiny25... Men visst jämförelsen med PIC18 bättre (lite nyare och upp snyggad)
>Det om det. Finns ingen anledning att diskutera detta mer här, och jag skriver inget mer i denna tråd...
Vilken tur, jag blev nästan lite orolig
>Det låter som att det ska komma en fortsättning på den meningen, tappade du tråden?
Tja, det försvann några ord där. Det snarare man ska se 32 registrena som "W". ^^
Nej, Det behövs inte efter som du har 32 st register som fungerar som "temp variabler", skulle man behöva en till så push man på stacken en som man för tillfället inte använder, Ungefär som en vanlig dator.
>Dessutom ska man kanske titta lite mer på PIC18 när man jämför med de *större* AVR'erna.
Nu tycker jag att en ATmega48 (den som används här) inte är speciellt stor, 27.20kr + moms på elfa vilket inte är så farligt. Den är ganska lite flash, 4kbyte (vilket motsvarar < 2k instruktioner ).
Eller en ATtiny25... Men visst jämförelsen med PIC18 bättre (lite nyare och upp snyggad)
>Det om det. Finns ingen anledning att diskutera detta mer här, och jag skriver inget mer i denna tråd...
Vilken tur, jag blev nästan lite orolig
>Det låter som att det ska komma en fortsättning på den meningen, tappade du tråden?
Tja, det försvann några ord där. Det snarare man ska se 32 registrena som "W". ^^
Nu har jag lyckats göra en interruptrutin som räknar quadrature.
Ganska tråkig film
Det funkar bra men jag har tydligen lite problem med stigtiden, om jag drar linjärskalan snabbt så falerar det.
Jag har tittat på spänningen på pinne 6(se bild) med oscilloscopet så jag ser att det är just stigtiden som är slö, falltiden är ok.
Jag använder denna optokopplare75-352-63mellan skalan och ATmegan.
Den ska vara tillräckligt snabb, jag har inte tittat så noga på scopet hur lång stigtiden är men den är säkert över 50µsek.
Kopplingen ser ut så här.
+12V in på höger sida och +5V(inverterat) ut på vänster sida.
Spänningen över motståndet R5 har snabb stigtid och falltid så problemet måste ligger på vänster sida.
Kan pinne7 ha något med saken att göra?
Ganska tråkig film
Det funkar bra men jag har tydligen lite problem med stigtiden, om jag drar linjärskalan snabbt så falerar det.
Jag har tittat på spänningen på pinne 6(se bild) med oscilloscopet så jag ser att det är just stigtiden som är slö, falltiden är ok.
Jag använder denna optokopplare75-352-63mellan skalan och ATmegan.
Den ska vara tillräckligt snabb, jag har inte tittat så noga på scopet hur lång stigtiden är men den är säkert över 50µsek.
Kopplingen ser ut så här.
+12V in på höger sida och +5V(inverterat) ut på vänster sida.
Spänningen över motståndet R5 har snabb stigtid och falltid så problemet måste ligger på vänster sida.
Kan pinne7 ha något med saken att göra?
Jag ska säga vad jag tror så är det att du kör för hög ström genom dioden som leder till att transistorn "saturation", så ändra R4 till ett lägre eller höj värdet på R5. Till pinne 7 har jag ingen aning hur du ska hantera, men jag skulle tro att hög ohmiskt motstånd mellan GND och pin7 skulle "kunna" ge mild ring av "saturation".
Du får nog experimentera lite gran. ^^
Du får nog experimentera lite gran. ^^
Stigtiden är när trissan går från on till off.
Jag tror att time/div är 20µsek, jag slarvade visst lite med dokumentationen.
Jag provade att ändra R5 till ett högre värde och då blev det bättre men det kan nog inte bli bra bara med den åtgärden.
Nu har jag petat fast ett motstånd på 220K mellan pinne7(bas) och jord (R4=10K och R5=2K) och nu funkar det efter förväntan.
I databladet finns faktiskt ett diagram för base-emitter resistance så det ska tydligen vara en resistans där.
För låga värden(provade bara med 10K) gör att signalen ut ligger hög hela tiden, i det fallet måste man nog öka värdet på pullup-motståndet.
Jag är iaf nöjd med resultatet i detta fall men nästa gång jag använder en optokopplare i en kritisk krets kommer jag ta reda på mer info om exakt vilka värden som är optimala.
Time/div är 10µsek
Om någon har lust att förklara varför man ska ha ett motstånd mellan bas-emitter och förklara skillnaden mellan en optokopplare utan bas och en som denna med bas så läser jag gärna, annars kommer jag själv ta reda på mer om det senare.
Tack för all hjälp!
Jag tror att time/div är 20µsek, jag slarvade visst lite med dokumentationen.
Jag provade att ändra R5 till ett högre värde och då blev det bättre men det kan nog inte bli bra bara med den åtgärden.
Nu har jag petat fast ett motstånd på 220K mellan pinne7(bas) och jord (R4=10K och R5=2K) och nu funkar det efter förväntan.
I databladet finns faktiskt ett diagram för base-emitter resistance så det ska tydligen vara en resistans där.
För låga värden(provade bara med 10K) gör att signalen ut ligger hög hela tiden, i det fallet måste man nog öka värdet på pullup-motståndet.
Jag är iaf nöjd med resultatet i detta fall men nästa gång jag använder en optokopplare i en kritisk krets kommer jag ta reda på mer info om exakt vilka värden som är optimala.
Time/div är 10µsek
Om någon har lust att förklara varför man ska ha ett motstånd mellan bas-emitter och förklara skillnaden mellan en optokopplare utan bas och en som denna med bas så läser jag gärna, annars kommer jag själv ta reda på mer om det senare.
Tack för all hjälp!
