Sida 1 av 1

Högupplöst pulsgivare till Pic krets

Postat: 13 mars 2007, 16:29:43
av JohanDcos
[Såg att jag råkade posta mitt meddelande i fel tråd, så här kommer det där det borde vara]


Hejsan!

Jag har en industri pulsgivare, 2048 PPR med TTL logik, med följande kanaler: A, A/, B, B/, Z, Z/

Maximal kan jag få ut 8192 pulser/varv från denna givare om jag triggar på både positiv och negativ flank (både A och B kanalen). Men i första skedet vill jag bara trigga på positiv flank på kanal A, vilket innebär 2048 pulser/varv. Den skall kunna användas upp till 1000 rpm, vilket innebär relativt snabba förlopp. Pulståget kommer skifta var 30 uS vid max hastighet.

Jag skulle vilja använda denna pulsgivare till en PIC krets, funktionen är helt enkelt att räkna pulserna från A kanalen i en variabel i PIC'en, Samma variabel skall också nollas när Z pulsen kommer in en gång per varv.
Om allt fungerar som det skall kommer Z pulsen att nolla min variabel när den räknat upp till 2048.


Jag har testat lite smått med en PIC16F628 med en 20Mhz kristall, satt kanal A till RB4 och Z pulsen till RB5, jag får den att räkna pulser men det verkar som den missar en del pulser och verkar inte stabil.

Så nu undrar jag följande:
Klarar en standard PIC krets dessa snabba skiftningar?
Räcker klockfrekvensen på PIC'en till?
Behövs det externa filter osv, för att slippa störningar?

Någon som har gjort något likannde eller har några tips på hur man löser detta på bästa sätt?


Tack för mig.

Postat: 13 mars 2007, 16:30:34
av sodjan
Har du räknat maskincykler i din kod ?
Antingen går det (med den kod du använder) eller så går det inte... :-)

30 us är ca 150 maskincyckler vid 20 Mhz.
Så om det du måste göra hinns med på 150 cykler, så...

> Så nu undrar jag följande:
> Klarar en standard PIC krets dessa snabba skiftningar?

I princip, ja. Det beror som sagt helt på vad din kod gör !

> Räcker klockfrekvensen på PIC'en till?

Samma svar...

> Behövs det externa filter osv, för att slippa störningar?

Det kan bara du veta (som kan *se* signalerna).
Men inte helt osannolikt...

> några tips på hur man löser detta på bästa sätt?

Kör in A till timer1 (satt som counter).
Kör en PIC18 i 40 Mhz (dubbelt så många cykler och effektivare kod).

Får du absolut inte missa någon puls ?

Postat: 13 mars 2007, 16:41:11
av maxxflow
Om du postar i fel forum, skapa då inte en ny tråd i ett annat forum, utan be en moderator att flytta tråden. Annars blir det så jobbigt om folk börjar svara i båda trådarna.

Postat: 13 mars 2007, 17:14:04
av JohanDcos
Ursäka för mitt misstag att posta i fel tråd skall inte upprepas :)


tack för svaret.

En sak som kanske kan spela in är att programmeringen är gjort i MBasic Pro (Basic Micro). alltså inte assambler kod, påverkar detta exekveringstiden eller hur räknas maskincyklerna här?


Pulsgivaren i fråga är följande om det kan hjälpa, här finns infromation om signalnivåer: http://www.leinelinde.se/contents/produ ... ds_eng.pdf

De diffrentiella signalerna tas emot i en CMOS RS-422/423-mottagare
Fabr ST Microelectronics, artikel nr elfa, 73-217-89. Dessa utgångarna från denna kopplas rätt in på RB4 för kanal A och RB5 för kanal Z.


Jag har testat att änvända ett interupt som heter RBINT dock utan framgång.

Postat: 13 mars 2007, 17:26:39
av Icecap
Högnivåspråk gör alltid fler assembler-instruktioner än ren assembler! Detta påverkar såklart exekveringstiden, har du tiden "tight" är det ren assembler som gäller.

Postat: 13 mars 2007, 18:57:40
av sodjan
Med 30 us mellan pulserna, så ser jag inte hur du skulle kunna köra
något annat än assembler *om* du vill ha 100% kontroll över cyklerna.

Detta är ett typiskt fall där kalkylering med instruktionscykler är helt
nödvändigt. Problem med (t.ex) Basic är att det är väldigt svårt att
beräkna cyklerna, man får försöka läsa assembler koden som kompilatorn
skapar och utgå från det. Om det ligger "on the edge", så är det inte alltid
så självklart *vad* man ska ändra i Basic-koden för att spara in ett par
cykler.

Alla högnivåspråk (*speciellt* Basic varianter) blir ett chanstagande
i detta fall...

Som sagt, vid 20 Mhz har du max 150 instruktioner på dig för varje
puls. Alla hopp (goto, call, return, retfie) tar det dubbla (d.v.s 2 cyckler).

Det är lättare på en PIC18 eftersom den dels kan köras i 40 Mhz, dels
har effektivare (assembler-) instruktioner (= kompaktare kod).

Postat: 13 mars 2007, 20:05:16
av JohanDcos
Tack för tipsen, det känns som assembler + PIC18 blir det alternativ jag måste gå på. Koden bör bli ganska liten så det känns som det skulle fungera utan probelm.

Är det någon som kan ge tips på om lösningen funkar rent hårdvarumässigt? Pulsgivare till RS422 krets verkar funka bra och tåla yttre störningar som förväntat. Och eftersom RS422 mottagaren har pull-up + pull-down motstånd inbyggt på utgången borde det väl fungera att koppla rakt in på PIC I/O?

Postat: 13 mars 2007, 20:45:44
av sodjan
Notera att jag inte har sagt att det *kommer* att fungera med en PIC18,
bara att du kommer att ha dubbelt så mycket cykler tillgängliga. Jag har
naturligtsvis inte en aning om det räcker till din kod. Men det kanske
är uppenbart. Bara så att du inte skaffar prylar och sedan (när det inte
fungerar) börjar "peka finger"... :-)

> Och eftersom RS422 mottagaren har pull-up + pull-down motstånd inbyggt på utgången...

*Ingångarna* ska det nog vara.

> borde det väl fungera att koppla rakt in på PIC I/O?

Ser ut så...

Postat: 13 mars 2007, 20:58:03
av JohanDcos
Jag lovar att jag inte skall komma tillbaka och gnälla om det inte går men det känns ganska positivt!

Jag menade faktiskt utgången. Kretsen tar emot differentiella signaler och om jag fattat rätt sitter motstånden på utgången för att stabilisera signalen.

Postat: 13 mars 2007, 21:00:46
av Henrik
En idé jag fick är att låta några traditionella logikkretsar agera räknare och generera det du kallar Z. Så kan du polla och göra annat med din pic i lugn och ro.

(lösryckt kan man misstolka sista meningen va :) )

Postat: 13 mars 2007, 21:14:27
av JohanDcos
Det är en idé, men nästa steg för denna applikation är att koppla in ytterligare en givare och latcha det aktuella räknarvärdet på positiv och negativ flank. Detta skulle nog bli lite rörigt med vanliga logikkretsar men troligtvis möjligt. För svårt för mig tror jag...

Postat: 13 mars 2007, 21:50:54
av John
Varför har det inte pratats mer om Sodjans förslag att använda Timer1 som räknare? Jag tycker det verkar mycket enklare än både externa logikkretsar eller att byta processor.
Om man dessutom kopplar Z till en interruptingång så borde väl processorn bara behöva engagera sig i pulsgivaren en gång per varv. Vips har man fått ca 300 000 instruktioner på sig att göra andra viktiga saker. Eller har jag missat nåt viktigt som omöjliggör den lösningen?

Postat: 13 mars 2007, 22:02:43
av JohanDcos
Jag skulle jubla en kort beskriving av Timer1 funktionen? Jag känner inte till hur den fungerar och hur man kan använda den?

Postat: 13 mars 2007, 22:13:20
av sodjan
Den bästa beskrivnihgen finns i kapitlet som
heter "Timer 1" i databladet. Läs först, fråga
sedan om det som är oklart.