Har suttit o pillat på ett kort jag inte kan andvända, det fanns för få pinnar för kommunikation men jag gjorde färdigt det ändå.
Sålänge man kan göra ett program som klarar att enbart skicka data genom en pinne så skulle det gå att få den att styra 8 spolar.
Skulle dock gärna se bättre prestanda på komunikationen än bara en pinne, måste designa om alltihop med färre kretsar.
Men är det någon som kan tänka sig ha nytta av kortet eller bara vill diskutera det så finns det på:
http://ottd.dyndns.org/1/nano/PCB/Sinus ... 008-05-10/
Gjorde ett nytt drivkort med en baksida :(
Ja det är ju sant, men blir det inte rätt dålig prestanda med bara en pinne?
Säg att man kör på maxfart, säg 3000 pps * 16 med mikrosteg, blir ju då 48000 pps och 8 kretsar ger 384000 värden per sekund som ska in.
Och eftersom 40MHz egentligen blir 10MHz på microchips kontrollers så blir det bara 26 klockcykler per värde att fördela på både kommunikation och output till drivkretsarna.
Finns säkert bättre sätt än det jag tänkt ut att feeda allt till kontrollern.
Kanske ge orders i stil med "gå till X med Y hastighet"
Fast det kan nog ändå bli lite issues när det händer mycket på samma gång antar jag eftersom överföringen blir så slö.
Kanske klarnar när jag sovit, klockan är 04:52 och är helt seg i skallen efter en hel natts designande.
Säg att man kör på maxfart, säg 3000 pps * 16 med mikrosteg, blir ju då 48000 pps och 8 kretsar ger 384000 värden per sekund som ska in.
Och eftersom 40MHz egentligen blir 10MHz på microchips kontrollers så blir det bara 26 klockcykler per värde att fördela på både kommunikation och output till drivkretsarna.
Finns säkert bättre sätt än det jag tänkt ut att feeda allt till kontrollern.
Kanske ge orders i stil med "gå till X med Y hastighet"
Fast det kan nog ändå bli lite issues när det händer mycket på samma gång antar jag eftersom överföringen blir så slö.
Kanske klarnar när jag sovit, klockan är 04:52 och är helt seg i skallen efter en hel natts designande.
Klart du skickar instruktion till MCUn att "gå till X med hastighet Y". Något annat blir bara krångligt. Det minskar behovet av snabb kommunikation också.
Dessutom är reläer inte den snabbaste komponenten under solen..
En fördel med kommando baserad kommunikation är också möjligheten till kontrollsummor o.dyl.
Dessutom är reläer inte den snabbaste komponenten under solen..
En fördel med kommando baserad kommunikation är också möjligheten till kontrollsummor o.dyl.
Hur bör man gå till väga med kommunikationen?
Man vet ju inte när man skickar om datan har mottagits.
Blir det att skicka data på måfå o hoppas att det funkar?
Motoruppdatering kommer ju att vara prio 1 och får aldrig rubbas, kommunikation kommer i sista hand.
Får nog bli en timer som får dra igång motoruppdatering även om det skulle innebära missad kommunikation.
Och ju mindre detaljer man jobbar på ju mer kommandon kommer ju att krävas.
När jag tänker efter så finns det nog tillfällen då detta skulle fungera men knappast för en fräs eller?
Man vet ju inte när man skickar om datan har mottagits.
Blir det att skicka data på måfå o hoppas att det funkar?
Motoruppdatering kommer ju att vara prio 1 och får aldrig rubbas, kommunikation kommer i sista hand.
Får nog bli en timer som får dra igång motoruppdatering även om det skulle innebära missad kommunikation.
Och ju mindre detaljer man jobbar på ju mer kommandon kommer ju att krävas.
När jag tänker efter så finns det nog tillfällen då detta skulle fungera men knappast för en fräs eller?
