ASM kode til PIC

KS skrev:

Mangler du ikke en

return

i din DisplayOut routine ?

/carsten

"Carsten Holck" skrev i en meddelelse news:41ee8ad5$0$176$ snipped-for-privacy@dtext01.news.tele.dk...

Nej DET tror jeg ikke !

retlw - returnerer og lægger samtidig "literalen" i w

(Det mener jeg også at have set i simuleringen)

Er't ikk' rigti' ?

Det er sagt via mail til mig, at jeg bruger for lang tid i interruptet - men hvad er "for lang tid" - er det her "hovedregningerne" omkring tiderne i forbindelse med at den skal tælle induktive pulser fra et gearhjul i en gearkasse - hjulet kører max 5000 RPM og har 80 tænder altså max 40.000 pulser pr. min - jeg har jo slet ikke brugt disse infos noget sted i koden endnu. (Ups, prescalleren står på 2 - så max 20.000 pulser pr. min.)

Mvh KS

"KS" skrev i en meddelelse news:41ee910d$0$200$ snipped-for-privacy@dread11.news.tele.dk...

Ups - BANK-fejl i SetupTMR0Int fundet, men det hjalp nu ikke.

Tak for det !

Mvh KS

Hej KS

selv om jeg har skrevet en del i asm til 16c84, er det ikke nemt at se hvad der er galt med din kode men for at tage en ting af gangen, lysintensiteten kan som jeg ser det øges på to måder, #1 ved at vise hvert display længere tid, #2 ved at opdatere displayene oftere, men bække forslag vil reducere den tid du har til at tælle tænder !

/Carsten

"Carsten" skrev i en meddelelse news:41ee9e3e$0$48325$ snipped-for-privacy@news.sunsite.dk...

Hej Carsten og tak for din tid !

Gør man det ved bare at indsætte Delay som jeg har gjort ?

#2 ved at opdatere displayene oftere,

Hovedprogrammet er vel et loop som udelukkende (undtagen test for nulstilling) op daterer.

Kan du sige noget om "beregningerne" omkring tid ?

Mvh KS

Jep bare indsæt delay

instruct time i ns = (1000000000 / (Clock_Freq i Hz / 4 ))

du skal dog være opmærksom på at nogle instruktioner tager dobbelt så lang tid /Carsten

"Carsten" skrev i en meddelelse news:41eead78$0$48329$ snipped-for-privacy@news.sunsite.dk...

Det er jeg med på, men det jeg tænkte på var, at når jeg kritiseres for at bruge "for meget tid" i interruptet, hvordan kan jeg så beregne HVOR lang tid jeg må bruge - det må vel max være tiden MELLEM de pulser interruptet skal tælle - eller hva' ?

Jeg kan jo "måle" i MPLAB, hvor lang tid der bruges i interruptet, og den målte tid her, skal så vel bare være mindre end tiden mellem pulserne, der skal tæller - eller hva' ?

Mvh KS

Hej jeg har kikket lidt på AN-557 og der bruger de interrupt til at opdatere displayet hver 5ms, det giver 5ms til at tælle pulser i. Jeg kan ikke lige overskue hvad du laver ! men har jeg ikke ret når jeg antager at du har fat i displayet både under interrupt og uden for interruptet ? /Carsten

"Carsten" skrev i en meddelelse news:41eec987$0$48328$ snipped-for-privacy@news.sunsite.dk...

Det eneste jeg sådan set har "taget" fra AN-557 er blot den måde at bruge porte til både ind- og udgange - altså det fysiske med modstandene/trykknapper, driverne til de enkelte cifre og så selvfølgelig nogle ideer fra koden.

MIT interrupt kommer fra TMR0 og denne tæller de indkommende pulser på RA4 - så det eneste mit interrupt laver er optælling af de 4 variable (som holder værdierne til de enkelte cifre på displayet) - dog tælles der kun hvis frysknappen IKKE er aktiveret. Derudover er der så noget housekeeping omkring interruptet.

Interruptet opdaterer IKKE displayet !

Opdateringen af LED-displayet sker alene i loop'et i hovedprogrammet og der er også test på om displayet skal NULSTILLES - hvis der trykkes på knappen hertil..

Der der for MIG har været udfordringen i dette projekt er dette at anvende portene (specielt PORTB.5+2 og 4+3) til UDGANGE når displayet skal opdateres og INDGANGE når der skal testes for FRYS eller NULSTIL display - det er sgu' smart synes jeg (jeg har jo til nu kun leget med blinkende LEDs, hvor sådan noget slet ikke anvendes). Det giver dog noget kode til omdefinering af portene undervejs.

Mvh KS

jeg var af den opfatelse at det var en omdrejnings tæller du var ved at lave siden du ville tælle tænder på et tandhjul /Carsten

"Carsten" skrev i en meddelelse news:41eed3f4$0$48321$ snipped-for-privacy@news.sunsite.dk...

lave

Det skal blive til er en omdrejningstæller, ja, så hvorfor si'r du det ?

Mvh KS

"Carsten Holck" skrev i en meddelelse news:41ee8ad5$0$176$ snipped-for-privacy@dtext01.news.tele.dk...

Jeg kom til at tænke på hvad der vil ske, hvis W (fejlagtigt) indeholder en værdi STØRRE end det antal retlw'er der findes ....

Det bør jeg vel sikre mig - eller hva' ?

Mvh KS

"KS" skrev i en meddelelse news:41eeb600$0$183$ snipped-for-privacy@dread11.news.tele.dk...

lang

Er det en rigtig opfattelse ?

Mvh KS

Ja hvis du ikke vil glippe en puls /Carsten

fordi du er ude på et galt spor ! /carsten

Omdrejnings tæller = et antal pulser på afmålt tid og det betyder i realiteten at du skal foretage dig to ting på en gang du skal tælle pulser, men samtidig skal du have styr på tiden, dvs. at du skal bruge TMR0 som timer, til at styre hvornår du er ferdig med at tælle

/Carsten

"Carsten" skrev i en meddelelse news:41ef761a$0$48327$ snipped-for-privacy@news.sunsite.dk...

med

Ja, det ved jeg godt - jeg skriver jo også i indledningen til programmet, at KUN tællerdelen er implementeret til nu. Jeg synes liiiige jeg ville have styr på de problemer jeg er stødt ind i først !

MEN nu vi er ved det..... kan man på nogen måde bruge programtælleren PC til at måle tiden ?

Jeg tænker som så - afhængig af clockfrekvensen tager hvert trin jo et vel afmålt stykke tid, så hvis man kunne så på PC på to forskellige tidspunkter, ville man også have et udtryk for den forgangne tid mellem disse to tidspunkter.

Men hvis PC blot er ADRESSEN for den næste instruktion

- ja, så duer denne metode jo ikke.

mvh KS

"Carsten" skrev i en meddelelse news:41ef7271$0$48329$ snipped-for-privacy@news.sunsite.dk...

Det vil jeg jo selvfølgelig ikke.

Mvh KS

den metode duer ikke, PC er ADRESSEN for den næste instruktion jeg tro at du skal prøve som jeg foreskrev i indlæg da TMR0 er knyttet til clockfrekvens en, når den sættes op som trimmer i stedet for som tæller /Carsten