Ezt keresem órák óta. Csakhogy az eepromot csak inicializáláskor olvassa a program, és felülíródnak az adatok.
Ezt pedig csak reszeteléskor tehetné meg. Viszont van benne egy biztonsági ciklus is. Bekapcsoláskor a RAM egy byteja az inicializálás legvégén értékkel töltődik fel. Ezt a byteot ellenőrzi, még mielőtt az eepromot olvasná. Ha az érték jó, átugorja a folytatást. Ergo, törlődik ez a byte is.

Egyre rejtélyesebbek ezek a hibák.
Bakman-nak igaza volt. Egy hibás relékontaktus okozott egy olyan erős tűimpulzust a tápon, hogy újraindult a PIC.
Mi ebben a rejtély? Az, hogy a rendszerben 2 PIC dolgozik, és csak az egyik indult újra. Mindig ugyan az.
De a következő hiba még rejtélyesebb.
Van egy encoder, aminek a jeleit számolja a PIC. Egy matematikai műveletsort végez, aminek az eredményét a kijelzőre írja. Ha az eredmény 0, le kell kapcsoljon egy kimenetet.
Az encoder legyen "A". Az egyik fix érték legyen "B", a másik "C", a harmadik "D"
A műveletek:
A*B=E
E/C=F
D-F=eredmény
Egy-egy alkalommal az eredmény 0. De olyan rövid időre jön a hibás eredmény, hogy a kijelzőn nem jelenik meg. Viszont a kimenetet kikapcsolja. Az encoder értéke nem lehet rossz egy pillanatra sem, mivel akkor nem javulna többé meg.
Hol lehet a hiba?

Szerintem a programban . Nem tudom van-e megszakítás pl., amiben módosulhat valamelyik regiszter (FSR ha használod), esetleg egy félreváltott bank ...

Pillanatnyilag megkerültem a hibát. Csak akkor fogadom el a nullát, ha ötször egymás után beadja. (Negatívba nem tud lemenni)

Na ez durva volt.
Egy hosszabb leírást írtam, hogy átláthatóbb legyen, és csak az eleje jelent meg.

Na akkor nekifutok még egyszer.

Az érdekelne, hogy van-e annak realitása, hogy a hardveres szorzó, ha túl sokat dolgoztatják, tévedjen.
Vagy esetleg az osztórutinban nem következik be egy biteltolás. Az alábbi programrészlet másodpercenként kb 900-1000 alkalommal fut le az osztórutinnal együtt.
A tévedés 0,5- 5 másodperc között következik be. Ha a linealizációt kiiktatom, és az encoder jeleit figyelem közvetlenül, akkor nem hibázik.

Kizárt, hacsak nem hibás a példányod.
Inkább az lehet a gond forrása, ha valamelyik megszakítási rutinod (esetleg mindegyik) is használja a PRODL : PRODH regisztereket és nincsenek mentve a megszakítási rutin(ok) elején és visszaállítva a vég(eike)n.

Bár a megszakítási rutinon belül nincs szorzás művelet, azért kipróbáltam. Sőt, adtál egy ötletet, hogy esetleg az kavar be, hogy miközben áttöltöm encoder értékét másik változóba, közben következik be megszakítás, és esetleg pont byteot vált a számláló. Úgyhogy a művelet közben letiltottam a megszakítást. De egyik megoldás sem segített.Úgyhogy végül a teljes linealizáció időtartamára tiltottam le a megszakítást, de a hiba változatlanul fennáll. Tehát valami más kavar be.
Várok minden ötletet. Mindet ki fogom próbálni. Az, hogy a többszörös vizsgálat révén működik az eszköz, nem jelenti azt, hogy jó.

Ha egy 3 byte-os számot szorzunk valamivel az nem biztos, hogy belefér 3 byte-ba. Erre figyeltél? (ez a szorzás-osztandó dolog nekem nem világos)

Jelenleg belefér. Az adott gép legnagyobb munkahossza és a mérőhossz szorzata nem haladja meg a 4 byteot.
A linealizáció alapképlete:
Xmax - Xmin = X eredő
Ymax - Ymi = Y eredő
Y = (X-Xmin) / (X eredő / Y eredő) + Ymin
Ha Xmin és Ymin egyaránt 0, (mint esetemben), akkor egyszerűsödik a képlet.
Y = X / (Xmax / Ymax)
A baj csak az, hogy Xmax / Ymax szinte mindig egy több tizedes jegyű szám, amivel igen macerás egy PIC-el számolni. Viszont a képletet meg is lehet fordítani.
Y = (X * Ymax) / Xmax. Ebben az esetben nincs tizedestört. Cserébe van egy szép nagy szorzatunk.

É nem szoktam letiltani a IT-t, mert akkor elveszhet mérés, egy egyszerű flaggel figyelem jött-e közben IT:

A szám negatívvá alakításánál 1-et hozzá kell adni:

Ha nem változóval kell szorozni/osztani ezt a generátort szoktam használni.

Sziasztok! Órák óta szívok egy léptetőmotoros vezérléssel, PIC16F629A-val. Step 1 vagy 2 bemenetre ha adok négyszögjelet a "saját" kimenetén az jelenik meg amit várok, de közben a másik kimenet fele frekvenciával is lépeget. Ha a nem vezérelt bemenetet lehúzom a földre akkor a hozzá tartozó kimenet leáll, ahogy kell. Megpróbáltam a nem vezérelt lábat fix tápra tenni (hátha zavar bejut) de az nem segített. Mini szkóppal is néztem a nem vezérelt lábat, de nem láttam rajta tüskét sem. A program MPLAB szimulátorával jónak látszik!
PORTA (bemenet) összes lába 4,7k-val tápra van kötve, a step és dir lábakat optócsatoló húzza le vezérléskor. PIC csere nem segített. (Nem látom a fától az erdőt?)

Nem teljesen világos a dolog. Egy léptetőmotor vezérlőnek akarsz jeleket küldeni, vagy magát a léptetőmotor vezérlőt akarod legyártani?

Nem biztos , hogy a pic meg tudja neked hajtani a léptető motorodat , ha ezt szeretnéd.
Sőt szerintem biztos hogy nem.

Lényegében léptetőmotor vezérlőt készítettem. Step és dir bemenetek felhasználásával unipoláris ( 4 tekercses ) léptetőmotor vezérlése a feladat. Teljesítményfokozat van utána.

Teljesítményt nem kell tudnia. Egyébként a motorok forognak viszik a szánokat, csak az a baj, hogy az is megy amelyiknek nem kellene.

Közben láttam , hogy irtad , hogy van teljesitmény fokozat utána.
A négytekercses , azt most nem értem , négy kivezetéses , akkor az két tekercses , ha 4 tekercses , akkor az nyolc kivezetéses .Egyébként milyen motor az típúsra ?

5 kivezetéses, 1 közös és 4 db 1-1 tekercskivezetésre. A motor 1:64-es fogaskerék-áttétellel rendelkezik, így 1 fordulatra 4096 lépés jut.

Akkor viszont lehet , hogy nem jól lett rákötve a vezérlő áramkörre, illetve van e annyi láb , és hozzá teljesítmény fokozat , hogy rendesen vezérelje a motort.
Nem tudom mi lesz ez , de ha leírnád lehet , hogy könnyebben tudnánk segíteni is .

A PIC PORTB alsó 4 bitje vezérli az egyik motor tekercseit, a fölső 4 bitje a másik motor tekercseit. Szimulátoron tökéletesen működik de a valóságban a nem vezérelt motor is megy!
Ez a problémám.
(egyébként egy 4 tengelyes habvágógépet építek)

És a két motor egy egy közös tekercs kivezetése azok hová vannak kötve ?Meg kellene nézni , hogy csak egy motor legyen bekötve , és akkor is megjelenik e a másik motor nem kivánt vezérlése .

Szia!
Mivel a táblázatod addwf PCL,f a programszámlálót lépteti, ezért ha a táblázat laphatárt lép át, (PCH +) rossz helyen fog a progi folytatódni. Ellenőrizd le, hogy egyik tábla se lépjen át laphatárt. illetve gondoskodni kell a PCH visszaállításáról.

PIC 4-4 kimenete 1-1 ULN2003-as meghajtóra megy. A motorok közös kivezetése megy a tápra. A tekercsek másik kivezetéseit az ULN 1-1 végtranzisztora húzza a földre.
Ezzel a résszel nincs probléma. A probléma a PIC elvi (szimulátoros) és valós működési közötti különbség.

Nem biztos , mert ha csak egy motorral nézed , és közben nézed a másik motorhoz menő kivezetéseket , és akkor nem fogsz látni ott vezérlést , akkor úgy müködik , ahogy kell .Viszont , ha látsz ott is vezérlést , akkor az program hiba lesz.

Ha nem tévedek nincs laphatár, mivel 2k az össz. programmemória. (a egész kb 500 byte).
Ha ilyen hiba lenne a szimulátoron is hibázna!?

LEDekkel is teszteltem az eredmény ugyanaz. (Meghajtók és motorok nélkül is - hátha van valami visszahatás!)

a PCH 256 byte-onként változik. Igen a szimulátor is hibázik.

Értem , akkor ott vezérlési hiba van , illetve program hiba .Neked egyidejűleg , csak egy motor vezérlésre van szükséged , ha jól olvastam.Ilyenkor a másik motorhoz tartozó program rész mit csinál , le van tiltva vagy ?

Az, hogy mikor melyik motornak kell mennie az a számítógépen futó programtól függ. Nekem az a problémám, hogy a NEM vezérelt motor is megy, bár fele sebességgel.

Értem , és a jelenlegi tesztelésed az hogy történik pc ről , vagy ?Fele sebesség is gyanús nekem , olyan mintha valahonnan máshonnan kapna az a motor vezérlést , és nem a pic felöl.