Fórum témák

» Több friss téma
Fórum » AVR - Miértek hogyanok
 
Témaindító: pakibec, idő: Márc 11, 2006
Témakörök:
WinAVR / GCC alapszabályok:
1. Ha ISR-ben használsz globális változót, az legyen "volatile"
2. Soha ne érjen véget a main() függvény
3. UART/USART hibák 99,9% a rossz órajel miatt van
4. Kerüld el a -O0 optimalizációs beállítást minden áron
5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás
6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et
Bővebben: AVR-libc FAQ
Lapozás: OK   629 / 837
(#) kapu48 válasza Massawa hozzászólására (») Nov 20, 2014 /
 
És a referencia pontot, hogyan keresed meg?
Kézzel, opto kapuval, mágneses Red relével, mikrokapcsolóval?
(#) Massawa válasza kapu48 hozzászólására (») Nov 20, 2014 /
 
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.)
(#) kapu48 válasza Massawa hozzászólására (») Nov 20, 2014 /
 
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!
A hozzászólás módosítva: Nov 20, 2014
(#) Massawa válasza kapu48 hozzászólására (») Nov 20, 2014 /
 
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).
A hozzászólás módosítva: Nov 20, 2014
(#) kala1982a válasza Massawa hozzászólására (») Nov 20, 2014 /
 
Hall ic? Kis mágnes meg egy CD meghajtó fejéből.
(#) Massawa válasza kala1982a hozzászólására (») Nov 20, 2014 /
 
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.
A hozzászólás módosítva: Nov 20, 2014
(#) kapu48 válasza Massawa hozzászólására (») Nov 20, 2014 /
 
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.
A hozzászólás módosítva: Nov 20, 2014
(#) Massawa válasza kapu48 hozzászólására (») Nov 20, 2014 /
 
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.
A hozzászólás módosítva: Nov 20, 2014
(#) kapu48 válasza Massawa hozzászólására (») Nov 20, 2014 /
 
Laserpointer?
Drága és rövid élettartamú!
(#) Massawa válasza kapu48 hozzászólására (») Nov 20, 2014 /
 
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.
(#) kapu48 hozzászólása Nov 20, 2014 /
 
Na és ha kosz kerül abba a pici résbe?
(#) Massawa válasza kapu48 hozzászólására (») Nov 20, 2014 /
 
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.
(#) 06smici hozzászólása Nov 20, 2014 /
 
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...
(#) gtk válasza Suncorgo hozzászólására (») Nov 20, 2014 /
 
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.
(#) kapu48 válasza 06smici hozzászólására (») Nov 20, 2014 /
 
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!
(#) Massawa válasza 06smici hozzászólására (») Nov 20, 2014 /
 
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.
(#) TavIR-AVR válasza kapu48 hozzászólására (») Nov 21, 2014 /
 
Az A végű chipeknél nincsen 8 és 16 MHz-s. Ezért nem írnak rá sebességet....
Bővebben: Link
372.oldal
A hozzászólás módosítva: Nov 21, 2014
(#) morgo válasza Massawa hozzászólására (») Nov 21, 2014 /
 
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...
(#) Massawa válasza morgo hozzászólására (») Nov 21, 2014 /
 
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)
(#) kapu48 válasza TavIR-AVR hozzászólására (») Nov 21, 2014 /
 
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?
A hozzászólás módosítva: Nov 21, 2014
(#) Massawa válasza kapu48 hozzászólására (») Nov 21, 2014 /
 
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.


(#) kapu48 válasza Massawa hozzászólására (») Nov 21, 2014 /
 
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?
(#) Massawa válasza kapu48 hozzászólására (») Nov 21, 2014 /
 
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 hozzászólás módosítva: Nov 21, 2014
(#) csabeszq válasza Massawa hozzászólására (») Nov 21, 2014 /
 
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.
A hozzászólás módosítva: Nov 21, 2014
(#) Massawa válasza csabeszq hozzászólására (») Nov 21, 2014 /
 
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....
(#) csabeszq hozzászólása Nov 25, 2014 /
 
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)?

  1. volatile uint32_t millis = 0;
  2.  
  3. ISR(TIMER0_OVF_vect)
  4. {
  5.   millis++;
  6. }
  7.  
  8. uint32_t get_millis() { return millis; }
  9.  
  10. main()
  11. {
  12.   timer_init();
  13.   sei();
  14.   uint32_t last_millis = get_millis();
  15.  
  16.   while(1)
  17.   {
  18.      int32_t eltelt_ido = get_millis() - last_millis;
  19.      // itt időnként negatív értéket kapok
  20.      // és nem várok 49 napot, hogy az uint32_t túlcsorduljon
  21.  
  22.      if( eltelt_ido >= 1000 )
  23.      {
  24.        led_villantas();
  25.        last_millis += 1000;
  26.      }
  27.    }
  28. }
A hozzászólás módosítva: Nov 25, 2014
(#) killbill válasza csabeszq hozzászólására (») Nov 25, 2014 /
 
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:

  1. uint32_t get_millis(void)
  2. {
  3. uint32_t temp;
  4.  
  5.  DisableIRQ();
  6.  temp = millis;
  7.  EnableIRQ();
  8.  return temp;
  9. }
(#) csabeszq válasza killbill hozzászólására (») Nov 25, 2014 /
 
Látom, tapasztalt AVR programozó vagy. Nekem nem volt ennyire triviális kitalálni.

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

  1. uint32_t get_millis()
  2. {
  3.   uint32_t m1, m2;
  4.   do
  5.   {
  6.     m1 = millis;
  7.     m2 = millis;
  8.   }while( m1 != m2);
  9.   return m1;
  10. }


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.
(#) killbill válasza csabeszq hozzászólására (») Nov 25, 2014 /
 
Idézet:
„Látom, tapasztalt AVR programozó vagy. Nekem nem volt ennyire triviális kitalálni.”
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.
(#) Suncorgo hozzászólása Nov 25, 2014 /
 
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?
Következő: »»   629 / 837
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem