Szia. Köszi a tippet. A takarítás nehézkes, mert pókháló a szerelés, nagyon kis helyre bezsúfolva. Először kipróbálom a kódot másik AVR-en, nehogy a kód legyen rossz. Utána egyesével leszedem a lábakról a vezetékeket, hátha ott lesz gond. Ha mindet leszedtem, és még mindig sok a felvett áram, akkor pedig jön az IC csere...
De lehetséges egyáltalán, hogy a hősokktól egy periféria zárlatos lesz? Úgy már jártam, hogy egy 100nF smd kondi zárlatos lett, úgyhogy el tudom képzelni... Ma este úgyis kiderül

Próbáltad már ArduinoISP-vel felrakni csak simán a .hex-et bootloader nélkül? Minek kell a bootloader, ha van kész .hex-ed?

Igen próbáltam, de úgy se megy. Azt olvastam így kell beállítani 8Mhz-re.

És ezt a tanácsot megfogadtat?: „You’ll need the Arduino software (version 1.0.1 or 0022). Installation”

Sziasztok, lenne egy bugyuta kérdésem. Építettem egy hajót aminek a motorját pwm-mel vezérlem N-channel fet + AVR. A biztonság kedvéért tettem be diódát, hogy megvédjem az áramkört, viszont a 0.7V fesz esés észrevehető a motoron (kicsit lassabb). Szóval a kérdés: ha párhuzamosan rakok több diódát azzal csökkenthetek a feszültség esésen? Vagy csak az áramkört hagyjam a dióda mögött, de a motor tápot vegyem a dióda elől, közvetlenül az akkuról?

Vagy a diódát cseréld ki FET-re, ami csak akkor vezet, ha jó a polaritás. Akkor minimálos lesz a fesz. esés. Bővebben: Link

Köszi a gyors választ!

Minden lehetséges.
Vagy a hősokktól (egy alkatrészt sem forrasztunk 15 percig) vagy pedig a "pókhálótól" nőtt meg az áramfogyasztás.
Feleslegesen próbálod ki másik avr-el, nem fog többet fogyasztani szerintem.
Azt próbáld meg inkább hogy pl a proci hex fájl nélkül mennyit fogyaszt, egy portlábat billegtetve mennyit fogyaszt.

Megtörtént a csere, mert az alvó program volt az IC-ben, minde lába szabad volt, kivéve a tápláb, és 10mA-t vett fel. Nem gond, mert így sokkal szebb lett a pókháló V2 Egyszerűbben javítható, átlátható. A másik IC pedig jó lesz olyan tesztekre, mint LED-et hajtani nagyon rövid impulzusokkal, előtét ellenállás nélkül, két kimeneti láb rövidzárlata, stb. Most is volt érdekes: sleep módban minden PORT kimenet, méghozzá magas szinten, kapcsoló pedig GND-re húzta le (normál esetben a belső felhúzó ellenállást), néztem is, hogy miért folyt 40mA mikor nyomom a gombot... Annak a kimenetnek persze semmi baja nem lett Jó strapabíró ez az Atmega328!

Sziasztok!

Az alábbi kód: Pergésmentesítés 4x4-es gombmátrixra. Csakhogy a kikommentált sorok nem működnek. A pergésmentesítést az oszlopokra szánnám mégis csak a 4. sorban levő (* 0 # D) elemekre működik. Van valakinek ötlete miért nem funkcionál a pergésmentesítés a többi nyomógomba?

Bővebben: Link

Ez a sor várja meg, hogy felenged a billentyűt: while(!(PINC&(1<<OSZLOP2)));

Viszont ha „//” jeleket raksz eléje, akkor a fordító csak megjegyzésnek értelmezi!
És nem kerül bele a kódba: //while(!(PINC&(1<<OSZLOP1))); // ??????????????

Ezek így vannak tervezve. Én UART-nál rendre felcserélem, hogy melyik az RX, melyik a TX, mégsem mennek tönkre. A logikai jeleket általában tetszőlegesen be lehet kötni, legfeljebb sokat fogyasztanak.

Idáig logikai jelek félrekötése miatt nem ment nálam tönkre semilyen hardver.

Mondjuk pergésmentesítést while ciklussal ebben a formában nem lehet csinálni.

Én azt szoktam csinálni:
- ha le van nyomva, akkor tovább küldöm, hogy 1
- ha nincs lenyomva, de az elmúlt 30ms alatt le volt nyomva legalább egyszer, akkor 1
- ha nincs lenyomva és a megelőző 30ms alatt sem volt lenyomva, akkor 0

Ebben a formában a lenyomást azonnal érzékeli, a felengedést 30 ms múlva. Persze fordítani is lehet.

Ezt mért nekem íród?

A fenti program részletet nem én írtam!
Csak észrevételeztem, hogy mért mükszik az 0, 10, 11 és 15-ös gombnál, többinél meg nem!

Imádom, hogy minden HSZ-embe bele kötsz! Tán nem tetszik, hogy én is létezem?

Nem akartam kötekedni, csak leírtam, hogy nem fog működni. Rólad tudom, hogy képes vagy működőképes pergésmentesítő algoritmust írni.

Igazából nem neked szólt a hozzászólás. Arról szól, hogy ebben a formában while ciklussal nem hiszem, hogy menne, semmi értelme sincs.

Az előtte meghívót, rutint nem közölték: keypad=keypad_beolvas(); ???

Ha az jól van, megírva még működhet is!(A kérdező állítása szerint is működik a fele billentyűzet)

Azt pontosan tudom, de azért kommenteltem ki, mert azokra nem erényesül a pergésmentesítés. Ellenben azokra, amiket bent hagytam (komment nélkül) érvényesül a pergésmentesítés.
Tehát a *#0D-re működik. A kérdésem: Miért nem működik a pergésmentesítés a többi nyomógombra, ha nincsenek kikommentelve a hozzájuk tartozó while(!PINC&(1<<OSZLOPx)));?

A kerdes jo. Lehet, hogy nem megfelelo bitet vizsgalsz azokon a helyeken, ahol nem mukodik. Nem latjuk a keypad_beolvas() fuggvenyt.

De ettol fuggetlenul ezt az egeszet nem igy kellene megcsnalni. Miert kell 15 helyen elvegezni pontosan ugyanazt a feladatot? Ha mar mindenkeppen ugy akarsz pergesmentesiteni, hogy egy lenyomast kovetoen megvarod, amig felengedik es utana meg meg is allitod a processzort, akkor azt csinald meg egy helyen:

Rendben, köszönöm. A keypad_beolvas() tartalma:

Üdv, vettem egy RTC modult, de egyszerűen nem tudom működésre bírni. Nemtudom hogy hol lehet a probléma. Atmega8-at használok a beépített 1MHz-s órajellel. Az i2c jeleket 1,5kOhm-os ellenállásokkal húzom fel, és az i2c órajel 100MHz-s (elméletileg), mellékelem a kódot hátha meglátjátok hogy mi a gond. Per pillanat arra szeretném használni, hogy 1Hz-s órajelet adjon, és ezzel okoz interruptot az int0 bemeneten. Lehetséges, hogy a hiba az i2c protkolban van, mert az én próbáltam megírni.
Amikor kiszámolja a TWBR értékét a "((F_CPU/F_SCL)-16)/2" képlettel, akkor negatív szám jön ki, ami unsignedbe 250 körüli szám, amit visszaírva a képletbe mint pozitív akkor nem jön ki az 100kHz, akkor mégis hogyan kéne számolni ?

main.c:

és itt a i2c master header fájl:



ui. ha van valakinek egy működő i2c könyvtára az elfogadnám

Üdv,
Máté

1 MHz orajellel sosem lesz 100kHz SCL, mivel a legkisebb osztas, amit el lehet erni az adatlap szerint az 16+2*10 = 36. A TWBR nem lehet 10-nel kevesebb. Igy aztan javaslom, hogy allitsd TWBR-t 10-re, es akkor kapsz egy szep 27.7 Khz-ces SCL-t. A tobbi reszet nem neztem a kodnak.

sajna még mindig nem jó, a cím küldés még elméletileg működik, de amikor adatot akarok küldeni, akkor a függvény már hibát ad vissza.

Itt nem alkalmazhatunk „==” egyenlő e?: return ( TW_STATUS == 0x08 );
Helyesen „=” legyen egyenlő: return ( TW_STATUS = 0x08 );
És ez több helyen is előfordul a programodban!

Hogy segítsek is!
Itt a fórúmon találsz témába illőt:
HMC6352 iránytűmodul - I2C (TWI) használata AVR-rel

Egészen jól körbejárja a témát.

köszönöm átnyálazom az írást.
==-re azért gondoltam hogy megvizsgálja hogy a TWI_STATUS egyenlő-e 0x08, és ha egyelő akkor logikai igazra értékelődik ki és az adódik vissza, ha nem egyenlő akkor meg hamis.

Es az ugy is van helyesen! Ez 'C' nyelv, nem bézik!

Nem egyertelmu, amit irtam, csak mar nem tudom szerkeszteni. Szoval, igenis hasznalhatunk ilyet egy C programban, hogy return TWI_STATUS == 0x08;
Ez teljesen elfogadott es ez is ramutat a C nyelv lehetosegeire. mpetrooo magyarazatahoz csak annyi, hogy az == es a tobbi relacios operator valamint a ! nem logikai igaz vagy hamis, hanem 1 vagy 0 erteku int tipusu eredmenyt ad vissza. Akar azt is le lehet irni, hogy

a = b + (c < 20);

Ha 'c' kisebb, mint húsz, akkor b + 1, egyebkent meg b + 0 megy az 'a'-ba.

köszönöm a segítséget. Rájöttem hogy mi a gond Enyhén szólva buta vagyok a DS1307 0x00-s regiszterének MSB-je 0-ra aktiválja oszcillátort, nem 1-re
köszönöm mindenki segítségét

Elnézni az adatlapot az semmiképpen nem butasag.

Egy kérdés:

Az ATmega328 procin a PD5=OC1A.
Az adott progiban használom az OC1A-t a megszakitásra, befolyásolhatja ez a PD5 müködését? ( a program kezeli a PD5 portot, de a kimenet folyton high szintü). Ha megallitom a progit, akkor a port simán billenthetö az egérrel.