Har tidigare byggt en drivare för stegmotorer som jag styrde direkt över parallellporten, det var ganska enkelt för här bestämde programmet hastigheten på step pulserna.
Tänkte nu försöka sätta in en PIC-krets till stegmotordrivern och skicka pulserna via parallellporten till kretsen.
Blir det programmet som bestämmer tiden på step pulserna eller kan man ha någon form av handskakning.
Handskakning parallellport-PICkrets
Om du ändå skall sätta in en mikrokontroller mellan PCn och stegmotorn, varför inte göra det ordentligt och låta mikrokontrollern ta hand om motor
styrningen helt och hållet ?
PC'n behöver bara sända "20 steg fram" eller "100 steg bakåt" eller
något liknande. PIC'en tar hand om detaljerna.
Varför skall du annars sätta in en PIC mellan PC'n och motorerna ??
Om den bara skall skicka pulserna vidare ?
Sen verkar det mycket enklare att sätta mikrokontrollern på en
serieport. Programmet i PIC'en blir enklare.
Slutligen så används begreppen "programmet" och "mjukvaran"
utan att det framgår om det är PCn eller PIC'en som avses...
styrningen helt och hållet ?
PC'n behöver bara sända "20 steg fram" eller "100 steg bakåt" eller
något liknande. PIC'en tar hand om detaljerna.
Varför skall du annars sätta in en PIC mellan PC'n och motorerna ??
Om den bara skall skicka pulserna vidare ?
Sen verkar det mycket enklare att sätta mikrokontrollern på en
serieport. Programmet i PIC'en blir enklare.
Slutligen så används begreppen "programmet" och "mjukvaran"
utan att det framgår om det är PCn eller PIC'en som avses...
"Om du ändå skall sätta in en mikrokontroller mellan PCn och stegmotorn, varför inte göra det ordentligt och låta mikrokontrollern ta hand om motor
styrningen helt och hållet ? "
Har vi diskuterat något annat.
"PC'n behöver bara sända "20 steg fram" eller "100 steg bakåt" eller
något liknande. PIC'en tar hand om detaljerna. "
Jaust det Sodjan, det var det som vi dikuterade.
"Varför skall du annars sätta in en PIC mellan PC'n och motorerna ??
Om den bara skall skicka pulserna vidare ?"
Vem påstod det.
"Sen verkar det mycket enklare att sätta mikrokontrollern på en
serieport. Programmet i PIC'en blir enklare. "
Möjligt med det var inte relevant i detta fall
"Slutligen så används begreppen "programmet" och "mjukvaran"
utan att det framgår om det är PCn eller PIC'en som avses..."
Sunt furnuft så förstår man.
styrningen helt och hållet ? "
Har vi diskuterat något annat.
"PC'n behöver bara sända "20 steg fram" eller "100 steg bakåt" eller
något liknande. PIC'en tar hand om detaljerna. "
Jaust det Sodjan, det var det som vi dikuterade.
"Varför skall du annars sätta in en PIC mellan PC'n och motorerna ??
Om den bara skall skicka pulserna vidare ?"
Vem påstod det.
"Sen verkar det mycket enklare att sätta mikrokontrollern på en
serieport. Programmet i PIC'en blir enklare. "
Möjligt med det var inte relevant i detta fall
"Slutligen så används begreppen "programmet" och "mjukvaran"
utan att det framgår om det är PCn eller PIC'en som avses..."
Sunt furnuft så förstår man.
Såja, lugna nu...
Det ÄR en i det närmaste obegriplig och virrig fråga så jag håller delvis med Sodjan... Bra är kanske att kalla PCns program för software/mjukvara och mikrokontrollens för "firmware"...
Antar att du undrar hur PICen skall veta att PCn skickar data till den och när det är ett nytt "ord" som kommer.
I så fall är svaret att man använder en STROBE-signal som PCn styr. (pin 1 i PCns parallellport) PCn lägger ut ett ord (8 bitar) på datapinnarna. Sedan ändrar den strobe-signalen från 1 till 0 och sedan tillbaka till 1 igen. Mikrokontrollern ligger och lyssnar på strobe och när den upptäcker att strobe är 0 så läser den av datapinnarna. På PICen kan strobe vara valfri pinne men det är bra att ta interruptpinnen eller en annan pinne som klarar av "interrupt on change"
Gör du så kan du skicka kommandon till kontrollern med ett enkelt doskommando typ: echo "100 steg fram" >lpt1:
//B1n4ry
Det ÄR en i det närmaste obegriplig och virrig fråga så jag håller delvis med Sodjan... Bra är kanske att kalla PCns program för software/mjukvara och mikrokontrollens för "firmware"...
Antar att du undrar hur PICen skall veta att PCn skickar data till den och när det är ett nytt "ord" som kommer.
I så fall är svaret att man använder en STROBE-signal som PCn styr. (pin 1 i PCns parallellport) PCn lägger ut ett ord (8 bitar) på datapinnarna. Sedan ändrar den strobe-signalen från 1 till 0 och sedan tillbaka till 1 igen. Mikrokontrollern ligger och lyssnar på strobe och när den upptäcker att strobe är 0 så läser den av datapinnarna. På PICen kan strobe vara valfri pinne men det är bra att ta interruptpinnen eller en annan pinne som klarar av "interrupt on change"
Gör du så kan du skicka kommandon till kontrollern med ett enkelt doskommando typ: echo "100 steg fram" >lpt1:
//B1n4ry
PIC:en hinner säkert hantera det, men skickar du t.ex "step 100" eller nåt sånt så måste du (PC:n alltså) veta när den utfört detta och är klar för nästa kommando. En liten buffert för kommandon kan man också ha men likväl så måste PC:n veta när bufferten är full. Det är där "ack" eller "busy" kommer in i bilden.
Jösses tusse !! 
Du behöver inte spåra ur helt bara för att du inte lyckades beskriva
problemet riktigt bra från början. Varför tror du att jag försökte få
lite klarhet i vad du menade ? Bara för att det är kul ?
Från ditt första inägg :
> Har tidigare byggt en drivare för stegmotorer som jag styrde direkt
> över parallellporten, det var ganska enkelt för här bestämde
> programmet hastigheten på step pulserna.
OK, så här är alltså "pulserna" de pulser som driver stegmotorn, eller hur ? Drivningen sker ju "direkt".
Sedan nästa mening i samma inlägg :
> Tänkte nu försöka sätta in en PIC-krets till stegmotordrivern och skicka
> pulserna via parallellporten till kretsen.
År inte dessa pulser samma pulser som i meningen ovanför ? Eller är detta någon annan slags "pulser" ??
Det står ingenting om att detta skulle vara "100 steg framåt" eller något liknande.
Sedan tredje och sista meningen i samma inlägg :
> Blir det programmet som bestämmer tiden på step pulserna eller kan man ha någon form av handskakning.
Här är det fullständigt oklart vad som avses med "programmet" !!
Till sist, där du "svarar" på mina olika frågor och förslag, är du bara larvig...
Du påstår att vissa saker har diskuterats när det uppenbarligen inte har det.
Du skriver att "Sunt furnuft så förstår man.". Så är det naturligtsivs inte.
Det man behöver veta är vad du *igentligen* tänkte när du skrev ditt
något oklara första inlägg. Det var bara det som jag försökte ta reda på.
> "Bra är kanske att kalla PCns program för software/mjukvara och mikrokontrollens för "firmware"..."
Antingen det, eller helt enkelt "PC programmet" / "PIC programmet", solklart då vad man menar.
Förrutom ack/busy, så skulle jag fundera på att ha en funktion för PIC
programmet att kunna skicka "data" (felkoder, larm eller liknande)
tillbaka till PC programmet.
Du behöver inte spåra ur helt bara för att du inte lyckades beskriva
problemet riktigt bra från början. Varför tror du att jag försökte få
lite klarhet i vad du menade ? Bara för att det är kul ?
Från ditt första inägg :
> Har tidigare byggt en drivare för stegmotorer som jag styrde direkt
> över parallellporten, det var ganska enkelt för här bestämde
> programmet hastigheten på step pulserna.
OK, så här är alltså "pulserna" de pulser som driver stegmotorn, eller hur ? Drivningen sker ju "direkt".
Sedan nästa mening i samma inlägg :
> Tänkte nu försöka sätta in en PIC-krets till stegmotordrivern och skicka
> pulserna via parallellporten till kretsen.
År inte dessa pulser samma pulser som i meningen ovanför ? Eller är detta någon annan slags "pulser" ??
Det står ingenting om att detta skulle vara "100 steg framåt" eller något liknande.
Sedan tredje och sista meningen i samma inlägg :
> Blir det programmet som bestämmer tiden på step pulserna eller kan man ha någon form av handskakning.
Här är det fullständigt oklart vad som avses med "programmet" !!
Till sist, där du "svarar" på mina olika frågor och förslag, är du bara larvig...
Du påstår att vissa saker har diskuterats när det uppenbarligen inte har det.
Du skriver att "Sunt furnuft så förstår man.". Så är det naturligtsivs inte.
Det man behöver veta är vad du *igentligen* tänkte när du skrev ditt
något oklara första inlägg. Det var bara det som jag försökte ta reda på.
> "Bra är kanske att kalla PCns program för software/mjukvara och mikrokontrollens för "firmware"..."
Antingen det, eller helt enkelt "PC programmet" / "PIC programmet", solklart då vad man menar.
Förrutom ack/busy, så skulle jag fundera på att ha en funktion för PIC
programmet att kunna skicka "data" (felkoder, larm eller liknande)
tillbaka till PC programmet.
Jag överreagerade på grund av att ofta dyker sodjans kommentarer upp även om det går att förstå vad personen skriver.
Dom andra har förstått vad jag menade utan att nedvärdera mitt inlägg, det är möjligt att jag inte använder mig av en del fina engelska ord på grund av att den engelskan jag lärt mig skedde ett tag före att en del av er föddes.
Danei förstod vad jag menade med program och jag förstod vad han menar med mjukvara och danei gav mig ett svar som kan stämma.
Nu har jag inte labbat med någon stegmotorkort som det går att skicka X-antal steg (100 steg framåt) direkt till och ingen programvara i PC som arbetar på samma sätt. Att det finns finner jag troligt men då blir det hela ord som jag skickar till kretsen.
å stegmotorkorten som jag labbat med så finns det ingångar för riktning och steg där varje puls utgör ett steg och frågan var om det går att få en bekräftelse på att denna puls är behandlad (stegmotorn har fått uppgiften att ta ett steg i bestämd riktning) och att detta går att skicka tillbaka som en bekräftelse på att datorprogrammet kan skicka en ny puls.
Kretsen är en PIC 16F628
Ett litet tillägg: danei du hade rätt, det blir mjukvaran som styr det.
Dom andra har förstått vad jag menade utan att nedvärdera mitt inlägg, det är möjligt att jag inte använder mig av en del fina engelska ord på grund av att den engelskan jag lärt mig skedde ett tag före att en del av er föddes.
Danei förstod vad jag menade med program och jag förstod vad han menar med mjukvara och danei gav mig ett svar som kan stämma.
Nu har jag inte labbat med någon stegmotorkort som det går att skicka X-antal steg (100 steg framåt) direkt till och ingen programvara i PC som arbetar på samma sätt. Att det finns finner jag troligt men då blir det hela ord som jag skickar till kretsen.
å stegmotorkorten som jag labbat med så finns det ingångar för riktning och steg där varje puls utgör ett steg och frågan var om det går att få en bekräftelse på att denna puls är behandlad (stegmotorn har fått uppgiften att ta ett steg i bestämd riktning) och att detta går att skicka tillbaka som en bekräftelse på att datorprogrammet kan skicka en ny puls.
Kretsen är en PIC 16F628
Ett litet tillägg: danei du hade rätt, det blir mjukvaran som styr det.
Inga problem, det är Jul och vi ska vara snälla mot varandra...
> Dom andra har förstått vad jag menade...
Jag är inte helt övertygad om, men det får dom andra uttala sig om...
Om du hade nämnt ditt "stegmotorkort" redan från början
så hade mycket tjafs undvikits. Åtminstånde jag (rätt eller fel) fick intryck
av att du i princip genererade drivningen för de olika motorlindningarna
direkt från parr-porten (via något drivsteg, så klart).
Nu är det alltså en 16F628 (16F628A ?) som skall driva
stegmotorkortet, fortfarande med en puls per "steg", eller hur ?
Hur som helst, dina frågor verkar vara mer kring hur stegmotorkortet
i sig fungerar (återkoppling när ett "steg" är utfört). Vad säger
dokumentationen till kortet ? Har du någon länk till kortet och/eller
dokumentation till det ?
Vad är orsaken till att du vill behålla parr-porten som interface
från PC'n ?
Slutligen, om du ändå skall stoppa in en PIC mellan PCn och stegmotorkortet
så borde man se till att PC programmet inte skall behöva generera
varenda "puls" till kortet. Eller har du en PC programvara som du inte
kan påverka funktionen på ?
GOD JUL !!
> Dom andra har förstått vad jag menade...
Jag är inte helt övertygad om, men det får dom andra uttala sig om...
Om du hade nämnt ditt "stegmotorkort" redan från början
så hade mycket tjafs undvikits. Åtminstånde jag (rätt eller fel) fick intryck
av att du i princip genererade drivningen för de olika motorlindningarna
direkt från parr-porten (via något drivsteg, så klart).
Nu är det alltså en 16F628 (16F628A ?) som skall driva
stegmotorkortet, fortfarande med en puls per "steg", eller hur ?
Hur som helst, dina frågor verkar vara mer kring hur stegmotorkortet
i sig fungerar (återkoppling när ett "steg" är utfört). Vad säger
dokumentationen till kortet ? Har du någon länk till kortet och/eller
dokumentation till det ?
Vad är orsaken till att du vill behålla parr-porten som interface
från PC'n ?
Slutligen, om du ändå skall stoppa in en PIC mellan PCn och stegmotorkortet
så borde man se till att PC programmet inte skall behöva generera
varenda "puls" till kortet. Eller har du en PC programvara som du inte
kan påverka funktionen på ?
GOD JUL !!
