Fórum témák

» Több friss téma
Fórum » AVR - Miértek hogyanok
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   632 / 632
(#) Massawa válasza kapu48 hozzászólására (») Csü, 12:59 /
 
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: Csü, 13:05
(#) kala1982a válasza Massawa hozzászólására (») Csü, 13:08 /
 
Hall ic? Kis mágnes meg egy CD meghajtó fejéből.
(#) Massawa válasza kala1982a hozzászólására (») Csü, 13:16 /
 
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: Csü, 13:23
(#) kapu48 válasza Massawa hozzászólására (») Csü, 13:20 /
 
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: Csü, 13:21
(#) Massawa válasza kapu48 hozzászólására (») Csü, 13:27 /
 
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: Csü, 13:29
(#) kapu48 válasza Massawa hozzászólására (») Csü, 13:45 /
 
Laserpointer?
Drága és rövid élettartamú!
(#) Massawa válasza kapu48 hozzászólására (») Csü, 13:57 /
 
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 Csü, 14:01 /
 
Na és ha kosz kerül abba a pici résbe?
(#) Massawa válasza kapu48 hozzászólására (») Csü, 15:33 /
 
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 Csü, 21:49 /
 
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 (») Csü, 21:52 /
 
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 (») Csü, 21:57 /
 
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 (») Csü, 22:09 /
 
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 (») Pé, 5:32 /
 
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: Pé, 19:30
(#) morgo válasza Massawa hozzászólására (») Pé, 7:06 /
 
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 (») Pé, 7:20 /
 
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 (») Pé, 11:50 /
 
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: Pé, 11:54
(#) Massawa válasza kapu48 hozzászólására (») Pé, 12:44 /
 
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 (») Pé, 13:56 /
 
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 (») Pé, 14:04 /
 
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: Pé, 14:04
(#) csabeszq válasza Massawa hozzászólására (») Pé, 16:10 /
 
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: Pé, 16:13
(#) Massawa válasza csabeszq hozzászólására (») Pé, 19:45 /
 
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 Kedd, 9:53 /
 
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: Kedd, 10:02
(#) killbill válasza csabeszq hozzászólására (») Kedd, 11:23 /
 
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 (») Kedd, 11:35 /
 
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 (») Kedd, 11:49 /
 
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 Kedd, 19:26 /
 
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?
(#) Suncorgo válasza Suncorgo hozzászólására (») Kedd, 20:31 /
 
Közben megleltem a választ és INT2 lábat is.

INT2 aszinkron külső megszakítás bemenet. Minden sleep módban az IOclock leáll így INT1 és INT0 nem kerül olvasásra. Viszont amit észrevettem és eddig megszakításoknál nem találkoztam ilyesmivel de, még csak az AVR doksijában sincs az az hogy ha ISR függvénye nincs megírva (akár üresen is) a programba akkor a proci INT2 megszakításra újraindul mint ha reset lett volna.
A hozzászólás módosítva: Kedd, 20:32
Következő: »»   632 / 632
Bejelentkezés

Belépés

Hirdetés
Frissek
2014. Nov, 26. Sze
13:32:37
Jelenleg 425 fő olvassa az oldalt
Online tagok:
Lapoda.hu     XDT.hu     HEStore.hu