És a referencia pontot, hogyan keresed meg?
Kézzel, opto kapuval, mágneses Red relével, mikrokapcsolóval?

Optokapura vagy REED-re gondoltam, azaz induláskor a motorra addig küldök impulzusokat, amig meg nem szolal a referencia érzékelö, és ez lesz a kiindulo állapot. Nem optimális a megoldás, de talán elfogadhato lesz.
(Egy régebbi rendszeren csak a következö állásig kellett a motornak elfordulnia, de az egészen más alapokon müködött, ezt léptetömotorral csak ugy tudnám megcsinálni, ha beletúrnák a belsö áttételbe.)

A legtökéletesebb lenne 1 optikai érzékelő, amit felé helyezel és látja hol áll a rendszer.
Ezt elkészíteni lenne az igazi kihívás

Illetve mindjárt 2 a térlátás kedvéért!

Pontosan ez hajt, hogy ezt kiküszöböljem. Ez volt már a korábbi szerkezetben is, mert teljesen lehetetlenség beépiteni 24 (vagy több) biztonságosan müködö, karbantartást nem igénylö és pontos pozicionálo érzékelöt. (Ezt teszik a kommercionális berendezésekben, és sajnos egyik megbizhatatlanabb, mint a másik).+
A másik baj meg az optokapuval van. Miután elég komoly felbontás kell (pontosság) az optovillába benyulo kulissza nem jo, mert nyilvánvaloan másképp reagál ha balrol zár, meg amikor jobbrol. Ha meg nagyon vékony, akkor meg nem reagál a kapu. Ezért most olyanon dolgozok, hogy a kulisszába egy 1 mm-es lyukat furok, és az opto arra fog majd reagálni, ha megszünik a fény majd ujra megjelenik (mert akkor lesz a LED meg az érzékelö között pontosan a kulissza lyuka).

Hall ic? Kis mágnes meg egy CD meghajtó fejéből.

Elvileg bármi lehet, csak egyformán kellene reagálnia bármelyik irányból és ezt a többség sajnos nem tudja mert mindennek véges méretei vannak.

De azt csak tudod, hogy merre forogsz, ész a két pont között mekkora a különbség?
Ebből már számolhatsz pontos középértéket.
Amit még hozzáadsz a mozgáshoz.

Az elvben tudom, de ez eléggé bonyolitja a dolgot, és azt sem akarom, hogy a motor tulforduljon, majd meg vissza, hogy meglegyen a középérték. Van még néhány ötletem - pl. egy kis laserpointer fényét egy vékony csövön át vezetném a fotodiodára, igy már a pontosság talán egy lépés alá kerülne.

Laserpointer?
Drága és rövid élettartamú!

Hol drága a piacokon majdnem hozzádvágják.

Az esetemben is naponta talán csak 20-30 másodpercig kell mennie ( amig meg nem találja a referencia pontot). Lehet, hogy egy LED is megtenné a csöben.

Na és ha kosz kerül abba a pici résbe?

Az majdnem kizárt, mert a csö vizszintesen lesz és az egész cucc egy helységben lesz. Ha meg mégis akkor ki kell porszivozni.
De még mindig a legjobbnak a kulisszába furt lyuk tünik, az el sem dugulhat, és könnyü kezelni.

Sziasztok!
Atmega128-ból léteznek használhatatlan utángyártott darabok? Ez például nekem túl olcsónak tűnik ahhoz hogy működjön is, ráadásul egyenesen kínából jön...

A parhuzamos ellenallasnak impedancia illesztes szerepe van. A soros ellenallas nem okozhat kart, sot csokkenti a trace Q-jat, es kissebb lesz az impulzusra adott valaszaban a tranziens jel amplitudoja.

Szerintem rá hibáztál!

Jól látszik, hogy lecsiszolták a felületet és újra címkézték.
Az AU –után is hiányzik a sebesség kód!

Hasonlítsad csak össze 1 hivatalos eladó fényképével!

Ilyesmivel még nem futottam össze, ( néha még ennél olcsobb procik is elöfordulnak). Nemrég egy barátom vett 100 darab 644-t egy 100€-ért ( nekem is jutott belöle), igaz itt Europában és valoszinüleg valamilyen raktárlomtalanitás volt.
Én elég rendszeresen veszek ezt azt Kinábol, és eddig semmi gondom nem volt, söt a minap amikor egy vacak (de használhato) cuccot reklamáltam, hogy rossz a minöség , minden szo nélkül visszautalták a pénzt.

Az A végű chipeknél nincsen 8 és 16 MHz-s. Ezért nem írnak rá sebességet....
Bővebben: Link
372.oldal

Pár napja én megszenvedtem az "óccó" kínai Tiny2313-al. 10db-ból egyet sem ismert fel egyik programozóm sem. Végül is mind jónak bizonyult. Külső órajelet kellett adni nekik, ezután nem volt semmi gond...

Ilyen gondjaim nekem is voltak, söt sokkal raffináltabbak. A profi development boardon felismerte a Dragon a procit (jtag) a dugaszolos fehér lapon csak akkor, ha simogattam ( hozzáértem a chip házához) a legyártott NYÁKon meg sehogy sem akarja felismerni, igy kénytelen vagyok a protoboardon programozni majd átdugni a végleges NYÁK-ba. A müködésben eddig nem tapasztaltam semmi hibát. A procikat eredetileg az Atmeltöl rendelték.
Ha valaki meg tudja mondani ennek az okát egy karton sört kap ajándékba.......

( nyilvánvalo, hogy azonos a környezet mind a 3 helyen)

Hát? Akkor csak azért csiszolták le a tok felületét, hogy több férjen bele a dobozba!?

Jobb esetben visszamaradt ICk valami titkos projectből?

Lehet, hogy ez is a mai technologia része. Valamikor igy készültek a RAMok, megcsinálták az eredetit feliratozva mindennel, aztán a teszten kiderült, hogy nincs meg a kivánt kapacitás ( a fele nem szokott müködni), igy mehetett a csiszoloba meg a a paphoz (keresztelöre) és onnan a világ egyik legsikeresebb számitogépébe a Sinclair ZX Spectrum-ba.
Aztán mindenki csak csodálkozott, hogy olyan memoriák semilyen cég kinálatában nem voltak (még jo, hogy a nagyobbak, amik elkerülték a csiszolást, minden gond nélkül müködtek....).
Szoval nem kell mindjárt gyanakodni meg negativan nézni a dolgokat.

OK … OK!
Elnézést!

Vetessük meg a sráccal!
Legfeljebb meg tudjuk más kárán az igazat!
És jót röhögünk a végén, vagy meglepődünk?

Azért már másfél dollárnál nagyságrenddel drágább cuccot is dobtunk ugy el, hogy meg voltunk gyözödve, hogy jot vettünk......Szoval nem nagy a riziko, csak nyerhet rajta....

A Commodore 64 floppy-járól mindenki tudja, hogy mennyire csiga volt az adatátvitele.

Még a VIC-20-as időkben a Commodore ráeszmélt, hogy a VIA soros shift regisztere minden 1 milliomodik bitet elveszített egy hardver hiba miatt. A chip már le lett gyártva, ezért ahelyett, hogy újraindították volna a gyártósort, szoftveresen oldották meg a problémát, hardver shift regiszter használata helyett.

Jó, a VIC-20-at eltolták, de hogy jön ide a C64? C64-ben már javították a hardverproblémát, de a VIC-20 floppy kompatibilitása miatt továbbra is szoftverből kezeltek mindent. Minthogy a video chip időnként feltartotta a processzort, ezért még egy kicsit lassítottak a szoftveren a VIC-20-hoz képest is, hogy megbízható legyen.

Nehéz überelni. A kretén magazinban jó sztori lenne, de sajnos felhasználók milliói szívtak emiatt, mert vagy háromszorosára nőtt a fájlok betöltési ideje.

Ezt a gépet én kihagytam, elég volt a zenész bajtársakkal veszödni, akik egyik Commodoret a másik után hozták. Szerencsére hamar leváltotta öket az Amiga....

Egy érdekes feladat (2 napomba telt a megfejtése, később leírhatom a választ, ha senki sem jön rá, hogy mi a hiba). Hogyan lehetséges, hogy az eltelt_ido változó negatívba forduljon (ez elég sűrűn megtörtént)?

Mondjuk a 32 bites millis-t az ISR valtoztatja, mikozben a get_millis() felszedi az erteket. Felszedi az also 8 vagy 16 bitet, bejon az ISR, megvaltoztatja az egesz szamot, visszater, aztan a get_millis() felszedi a maradekat a 32 bitnek, ami kozben megvaltozott.


ISR elott:
00 00 ff ff - get_millis() felveszi a felso 16 bitet (0)
ISR utan
00 01 00 00 - get millis() felveszi a also 16 bitet (0)

igy az eredmeny most nulla, pedig elozoleg 0xffff volt.

Megoldas, hogy a get_millis() tiltja az interruptot:

Látom, tapasztalt AVR programozó vagy. Nekem nem volt ennyire triviális kitalálni.

Az én megoldásom kicsit más lett:



Azért ezt a megoldást választottam, mert fontos, hogy az időzítések minél pontosabbak legyenek. Ott, ahol lehet elkerülöm a CLI használatát. Megnézem, hogy a két egymás után kiolvasott érték megegyezik-e, ezzel nem tartom fel az interruptot sem.

Inkabb csak tapasztalt programozo. Ezt mar megtanultam '87-ben, z80-on. A megoldasod viszont ravasz.
Egyebkent a felvetett dolog maskor is okozhat problemat. Peldaul egy megszakitasi rutin valtoztat egy port bitet. Ugyanezen portot mas is valtoztatja egy nem RMW utasitassal. Az programozoi alapelv, hogy nem tudhatjuk, hogy a C fordito egy PORTA |= (1<<2) utasitast mire fordit, tehat lehet, hogy harom assembly utasitasbol oldja meg.
Szoval a dolgok menete:
foprogram felolvassa PORTA erteket egy regiszterbe, az ertek legyen 0x55
kozben interrupt bejon, es PORTA-t megvaltoztatja 0xd5-re (legfelso bitet 1-be allitotta)
foprogram folytatja a munkat, 0x55-bol 0x59-et csinal a regiszterben
foprogram visszairja PORTA -ra az uj erteket, a 0x59-et.
Es ezzel elvesz a 7-es bit, amit a megszakitas beallitott.

Az AVR-nel jellemzoen RMW utasitassal allitodik be egy port bit, de azert erdemes erre mas esetekben odafigyelni.

Sziasztok!

Mit jelent a 3. megjegyzés pontosan az ATmega16 doksijába?
Azt tudom hogy ezen a mikrovezérlőn nincs INT2-es bemenet csak 1 és 0.

Külső kavicsról megy az órajel, minden alvó módból fel tudom ébreszteni külső megszakítássa?