Positions-Display för svarv (AVR)
Mycket informativt dokument!
Det verifierar att man ska ha ett motstånd med hög resistans mellan bas och emitter för att förbättra bandbredden.
Man ska även kunna förbättra bandbredden till makalösa 30Mhz genom att använda fototransistorn som en fotodiod, man använder alltså bara collectorn och basen konstigt nog.
Detta gör dock att CTR blir väldigt låg men det kan absolut vara användbart.
Det måste jag testa någon gång.
Det verifierar att man ska ha ett motstånd med hög resistans mellan bas och emitter för att förbättra bandbredden.
Man ska även kunna förbättra bandbredden till makalösa 30Mhz genom att använda fototransistorn som en fotodiod, man använder alltså bara collectorn och basen konstigt nog.
Detta gör dock att CTR blir väldigt låg men det kan absolut vara användbart.
Det måste jag testa någon gång.
En liten update så ni inte tror att jag latar mig.
Nu fungerar PS2-kommunikationen, Displayen visar den data som t-bordet skickar.
AA = Hej jag är ett tanjentbord som fungerar, prata med mig.
FA = Acknowledge, svaret efter att jag skickat F4(Enable) till t-bordet.
E05A = Någon klåfingring jävel har tryckt ned knappen ENTER.
E0F05A = knappen ENTER släpps.
Jag tycker tanjent-koderna är lite onödigt långa men så ser standarden ut.
Det här t-bordet gick inte att konfigurera så att man slipper repetitionen av knappar som hålls nedtryckta.
Nya tanjentbord stödjer ofta bara den del av standarden som är absolut nödvändig, allt lull-lull struntar dom i.
Nu fungerar PS2-kommunikationen, Displayen visar den data som t-bordet skickar.
AA = Hej jag är ett tanjentbord som fungerar, prata med mig.
FA = Acknowledge, svaret efter att jag skickat F4(Enable) till t-bordet.
E05A = Någon klåfingring jävel har tryckt ned knappen ENTER.
E0F05A = knappen ENTER släpps.
Jag tycker tanjent-koderna är lite onödigt långa men så ser standarden ut.
Det här t-bordet gick inte att konfigurera så att man slipper repetitionen av knappar som hålls nedtryckta.
Nya tanjentbord stödjer ofta bara den del av standarden som är absolut nödvändig, allt lull-lull struntar dom i.
Det fungerar som följer:
Ett pin-change-interrupt hanterar PS2-interfacet och lagrar datan i en cirkulär buffer på 64byte.
Huvudloopen anropar en rutin som läser från denna buffer och avkodar och filtrerar bort tanjent-tryckningar som är repeterande.
Knapp-tryckningarna lagras i en cirkulär buffer där det älsta värdet plockas ut och returneras när rutinen avslutas.
Nu till ett konstigt fel som visserligen inte är något problem längre men det är lite intressant iaf.
Med Avr kan man toggla en bit i en port genom att sätta biten för läsregistret, väldigt ologiskt men användbart om man vill toggla en eller flera pinnar.
ex. SBI PINB,7
Med Pic finns det en speciell instruktion för det: BTG.
Det har jag använt mig av i debug-sammanhang för att på ett enkelt sätt se om en viss rutin exekveras eller inte, om den exekveras kommer lysdioden blinka eller som i mitt fall, backlighten blinkar.
Så nu när jag var klar med allt som hanterar T-bordet provade jag att anropa rutinen från huvudloopen för att få tanjent-tryckningar returnerade.
Jag gjorde så att backlighten skulle toggla varje gång man trycker på en tanjent.
Men när jag tryckte så stannade allt och displayen förblev oförändrad, backlighten blev bara togglad första gången jag tryckte.
Jag misstänkte genast någon register-krock men efter 1 timmes felsökning så tog jag bort raden SBI PINB,7 och då fungerade det.
Jag får bara problemet när jag anropar T-bords-rutinen och rutinen som skriver ut ett tal på displayen och togglar backlighten i huvudloopen.
Om man tar bort en av dessa 3 så får man inget fel.
Rutinen för att skriva ut ett HEX-värde på displayen kan användas utan att det blir fel.
Om jag togglar pinnen med SBI PORTB,7 och CBI PORTB,7 får jag inget fel.
Jag testade även att öka farten ordentligt på blinkandet så att backlighten lyser svagt hela tiden utan att det blev fel.
Jag testade att toggla en annan pinne som ej är ansluten med SBI PINB,6 utan fel.
Det verkar som om SBI PINB,7 skapar ovillkorlig krasch i vissa specifika fall, det kan ha något med lasten(Gate på en FET) att göra men jag får ju inget fel om jag togglar på vanligt sätt.
Som vanligt är jag en "error-magnet".
Innan man påstår att det är ett design-fel av Atmel borde man försöka banta ner koden för att hitta vad som orsakar det och kanske prova med en ny krets oxå men jag får design-fel-vibbar.
Vad tror ni?
Grattis! Du har nu läst hela inlägget!
Ett pin-change-interrupt hanterar PS2-interfacet och lagrar datan i en cirkulär buffer på 64byte.
Huvudloopen anropar en rutin som läser från denna buffer och avkodar och filtrerar bort tanjent-tryckningar som är repeterande.
Knapp-tryckningarna lagras i en cirkulär buffer där det älsta värdet plockas ut och returneras när rutinen avslutas.
Nu till ett konstigt fel som visserligen inte är något problem längre men det är lite intressant iaf.
Med Avr kan man toggla en bit i en port genom att sätta biten för läsregistret, väldigt ologiskt men användbart om man vill toggla en eller flera pinnar.
ex. SBI PINB,7
Med Pic finns det en speciell instruktion för det: BTG.
Det har jag använt mig av i debug-sammanhang för att på ett enkelt sätt se om en viss rutin exekveras eller inte, om den exekveras kommer lysdioden blinka eller som i mitt fall, backlighten blinkar.
Så nu när jag var klar med allt som hanterar T-bordet provade jag att anropa rutinen från huvudloopen för att få tanjent-tryckningar returnerade.
Jag gjorde så att backlighten skulle toggla varje gång man trycker på en tanjent.
Men när jag tryckte så stannade allt och displayen förblev oförändrad, backlighten blev bara togglad första gången jag tryckte.
Jag misstänkte genast någon register-krock men efter 1 timmes felsökning så tog jag bort raden SBI PINB,7 och då fungerade det.
Jag får bara problemet när jag anropar T-bords-rutinen och rutinen som skriver ut ett tal på displayen och togglar backlighten i huvudloopen.
Om man tar bort en av dessa 3 så får man inget fel.
Rutinen för att skriva ut ett HEX-värde på displayen kan användas utan att det blir fel.
Om jag togglar pinnen med SBI PORTB,7 och CBI PORTB,7 får jag inget fel.
Jag testade även att öka farten ordentligt på blinkandet så att backlighten lyser svagt hela tiden utan att det blev fel.
Jag testade att toggla en annan pinne som ej är ansluten med SBI PINB,6 utan fel.
Det verkar som om SBI PINB,7 skapar ovillkorlig krasch i vissa specifika fall, det kan ha något med lasten(Gate på en FET) att göra men jag får ju inget fel om jag togglar på vanligt sätt.
Som vanligt är jag en "error-magnet".
Innan man påstår att det är ett design-fel av Atmel borde man försöka banta ner koden för att hitta vad som orsakar det och kanske prova med en ny krets oxå men jag får design-fel-vibbar.
Vad tror ni?
Grattis! Du har nu läst hela inlägget!
-
JimmyAndersson
- Inlägg: 26532
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Mitt i städandet upptäckte jag en elakartad bug som tog många timmar att hitta.
Problemt var att jag hade reserverat 2st register till quadrature-interruptet och råkat använda dessa på ett annat ställe.
Kod till PS2-interfacet
Jag har använt ett ganska trevligt sätt att definiera pinnarna, ni kan se i koden hur definitionerna ser ut.
Läsa av en pinne: sbic R+PS2Data
Göra pinnen hög: sbi W+PS2Data
Ändra pinnen till utgång: sbi D+PS2Data
Eftersom T-bordet har så få knappar struntade jag i att göra en tabell för tangent-koderna, jag gjorde en ful villkors-lista istället.
Den nödvändiga tidsfördröjningen på i mitt fall 1000 klockcycler när man ska skicka PS2-data gjorde jag genom att polla en timer.
Det skulle varit snyggare med ett interrupt men i mitt fall har det ingen betydelse.
Jag fuskar lite, jag struntar i paritetsbiten när T-bordet skickar data.
Det värsta som kan hända är ju att ett paket blir felaktigt.
Problemt var att jag hade reserverat 2st register till quadrature-interruptet och råkat använda dessa på ett annat ställe.
Kod till PS2-interfacet
Jag har använt ett ganska trevligt sätt att definiera pinnarna, ni kan se i koden hur definitionerna ser ut.
Läsa av en pinne: sbic R+PS2Data
Göra pinnen hög: sbi W+PS2Data
Ändra pinnen till utgång: sbi D+PS2Data
Eftersom T-bordet har så få knappar struntade jag i att göra en tabell för tangent-koderna, jag gjorde en ful villkors-lista istället.
Den nödvändiga tidsfördröjningen på i mitt fall 1000 klockcycler när man ska skicka PS2-data gjorde jag genom att polla en timer.
Det skulle varit snyggare med ett interrupt men i mitt fall har det ingen betydelse.
Jag fuskar lite, jag struntar i paritetsbiten när T-bordet skickar data.
Det värsta som kan hända är ju att ett paket blir felaktigt.
> Problemt var att jag hade reserverat 2st register till
> quadrature-interruptet och råkat använda dessa på ett annat ställe.
Bara nyfiken...
Du menar definierade/reserverade via .equ ?
Och du hade inte ordning på vilka adresser du redan hade använt ?
Ska inte .dseg/.DB ta hand om det ?
Och varför blanda .equ definitioner av variabler
med .dseg/.DB definitioner i samma kod ? Gör de
inte samma sak, men det senare på ett bättre sätt ?
Eller också har jag missförstått någonting...
> quadrature-interruptet och råkat använda dessa på ett annat ställe.
Bara nyfiken...
Du menar definierade/reserverade via .equ ?
Och du hade inte ordning på vilka adresser du redan hade använt ?
Ska inte .dseg/.DB ta hand om det ?
Och varför blanda .equ definitioner av variabler
med .dseg/.DB definitioner i samma kod ? Gör de
inte samma sak, men det senare på ett bättre sätt ?
Eller också har jag missförstått någonting...
-
JimmyAndersson
- Inlägg: 26532
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Du har missförstått det hela lite.
Jag hade definierat ett register med .def namn=Rxx.
.def används bara för att definiera register och kan inte användas till att reservera minne.
Man kan heller inte reservera register med .dseg/.DB.
Jag hade definierat R26 som även används till register X och fick därför en varning men eftersom man bara får veta att R26 redan är definierad så måste man räkna ut själv vem/vad som redan använder R26.
Jag trodde(eller visste fast det var ju fel) att det var register Z av någon anledning och lät varningen vara.
Det jag borde ha gjort är att lägga in en .undef för ZL och ZH för då skulle jag ha fattat att jag hade gjort fel.
Det var ganska klantigt av mig men det positiva är att jag "aldrig" kommer göra just det misstaget igen.
När det gäller .equ PS2Buffer=$200 så skrev jag koden så att den låga byten måste vara 0, därför använder jag .equ men det kanske finns något annat sätt.
Jag hade definierat ett register med .def namn=Rxx.
.def används bara för att definiera register och kan inte användas till att reservera minne.
Man kan heller inte reservera register med .dseg/.DB.
Jag hade definierat R26 som även används till register X och fick därför en varning men eftersom man bara får veta att R26 redan är definierad så måste man räkna ut själv vem/vad som redan använder R26.
Jag trodde(eller visste fast det var ju fel) att det var register Z av någon anledning och lät varningen vara.
Det jag borde ha gjort är att lägga in en .undef för ZL och ZH för då skulle jag ha fattat att jag hade gjort fel.
Det var ganska klantigt av mig men det positiva är att jag "aldrig" kommer göra just det misstaget igen.
När det gäller .equ PS2Buffer=$200 så skrev jag koden så att den låga byten måste vara 0, därför använder jag .equ men det kanske finns något annat sätt.
Nu är koden klar för denna gång.
Det blev inget offset-register men jag gjorde en kul special-funktion iaf.
Jag ska försöka visa med en film senare, problemet nu är att svarven gick sönder innan jag hann testa displayen på riktigt.
Angående den mystiska buggen, jag citerar mig själv:
"Det verkar som om SBI PINB,7 skapar ovillkorlig krasch i vissa specifika fall, det kan ha något med lasten(Gate på en FET) att göra men jag får ju inget fel om jag togglar på vanligt sätt."
Efter många timmars programmering fick jag ovillkorlig krasch när jag släcker backlighten på vanligt sätt oxå, alltså med CBI PORTB,7.
Jag löste problemet genom att ha ett motstånd mellan pinnen och gate.
Kan kapacitansen i gaten orsaka detta problem
Det blev inget offset-register men jag gjorde en kul special-funktion iaf.
Jag ska försöka visa med en film senare, problemet nu är att svarven gick sönder innan jag hann testa displayen på riktigt.
Angående den mystiska buggen, jag citerar mig själv:
"Det verkar som om SBI PINB,7 skapar ovillkorlig krasch i vissa specifika fall, det kan ha något med lasten(Gate på en FET) att göra men jag får ju inget fel om jag togglar på vanligt sätt."
Efter många timmars programmering fick jag ovillkorlig krasch när jag släcker backlighten på vanligt sätt oxå, alltså med CBI PORTB,7.
Jag löste problemet genom att ha ett motstånd mellan pinnen och gate.
Kan kapacitansen i gaten orsaka detta problem
Kul projekt. Jag har också nyligen skrivit kod för att ta emot och skicka data till ett vanligt ps2-tangenbord. Använder en Atmega88. Jag använder USARTen för att ta emot data. Funkar alldeles perfekt, en interruptrutin körs när jag tagit emot en byte. Skriver visserligen i C men om du vill så kan jag ju göra ett urklipp ur listfilen om du är intresserad. Även jag använder en cirkulär buffert.
Angående motståndet till gaten. Det är klart vettigt att använda ett motstånd som strömbegränsning eftersom kapacitansen kan dra en hög momentan ström vid uppladdningen (liknande för urladdning).
Angående motståndet till gaten. Det är klart vettigt att använda ett motstånd som strömbegränsning eftersom kapacitansen kan dra en hög momentan ström vid uppladdningen (liknande för urladdning).
Hmm... Kan USARTen hantera data med totalt 11bitar/paket som i detta fallet?
Jag har inte läst om USARTen på AVR men när jag läste om det på PIC så fattade jag iaf inte hur man får så många bitar.
Jag vill gärna titta på din kod.
Jag skulle oxå ha använt en ATmega88 men Elfa skickade en 48 i påsen med texten ATmega88.
Jag kom på det först när den var på plats.
Den är nästan fylld så om jag fortsätter med projektet måste jag kanske byta ut den för att få plats.
Jag har inte läst om USARTen på AVR men när jag läste om det på PIC så fattade jag iaf inte hur man får så många bitar.
Jag vill gärna titta på din kod.
Jag skulle oxå ha använt en ATmega88 men Elfa skickade en 48 i påsen med texten ATmega88.
Jag kom på det först när den var på plats.
Den är nästan fylld så om jag fortsätter med projektet måste jag kanske byta ut den för att få plats.
