AVR kezdőnek

[Robert]

Trükk:
a 32.768kHz órajelkvarc az XTAL1/XTAL2 lábon.
Ekkor _nem_ órajel, hanem ha megnézed az adatlapot:
űhttp://www.atmel.com/images/atmel-8159-8-bit-a ... asheet.pdf
12. oldal:
XTAL1/TOSC1 XTAL2/TOSC2

A kis lábszámú chipeknél kombinált funkciók lehetnek. Pl. Mega328 esetén: A5/A4 láb, I2C busz és még I/O kivezetés is:)
A kvarc meg lehet XTAL - orajelforrás, vagy TOSC - TimerOsc.
Azaz a chip belső órajelről jár (pl. 8MHz RC Internal) és a Timer2 a TOSC1/2-re rakott kvarcról. Ekkor a Timer2 1 sec időalapot ad, azaz készen van a precíz óraművünk
Miért nem kell kondi?
"Note:  The Timer/Counter Oscillator uses the same type of crystal oscillator as Low-Frequency Oscillator and the internal capacitors have the same nominal value of 36pF."
50. oldal

[SanyiSay]

Jó pap is holtig...

[katonafull]

Juhúúúú, sikerült ID-t olvasni avrdude-val, úgy, hogy értem is mit csináltam. Jó, tudom, nem nagy dolog, de én azért örülök.
Első próbálkozás egy szűz ATtiny24A-val

avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e910b
avrdude: safemode: Fuses OK
avrdude done. Thank you.

Matisz nagypapát idézve: "Öhöm, bódottá..."
Köszönöm az eddigi segítséget!

Az ATmega88-al is sikerült.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e930a
avrdude: safemode: Fuses OK
avrdude done. Thank you.

Fellelkesedve ráindítottam az extreme burnert, merthogy azt nem nagy kunszt, akármilyen rossz is és ki tudtam menteni belőle a hex és eep fájlt is.
Aztán totalcommanderrel összehasonlítottam tartalomra az eredetiket, meg a most kimentettet, és hát nem ugyanazok.
Pedig korábban az eredetit töltöttem fel és gondolom, ha azt később kimentjük ugyanaz a hex és eep fájl kell, hogy legyen belőle.
És a hex fáj esetében kb.: 2% eltérés van, az eep-nél meg 300%-os.
Mi ebből a tanulság? Hogy ez az usbasp, amit korábban használtam tényleg egy sz@r. Jó, most is csak USBTinyISP van még, de ez legalább jónak tűnik.
A régi usbasp nem is olvassa ki az ID-t. Így most kiderült, hogy mi okozta a hibát. Nagyon örülök.
Na a következő lépés az lesz, hogy ugyanígy kiolvasom az ID-ket, meg a hex és eep-fájlt avrstudioval is.
Aztán meg ledezek.

[katonafull]

Bascom tankönyvben 06, AVR órajeleknél van ilyen hogy elhagyhatók a kondik. Még sosem próbáltam.

Tényleg már olvastam is, csak nem értettem pontosan, hogy mikor használunk ilyet. Meg csak átfutottam, mert még a lednél se tartok, de úgy látszik jobb először végigolvasni az egészet és úgy elkezdeni.

Az írásban megemlíti a szerző a CLKOPT fuse bitet is, de én ezzel még egyik chipnél se találkoztam, pedig megnéztem már párat a kalkulátorban..
Gondolom a CKOPT és CLKOPT ugyanaz. Na de ha magas külső kvarckristálynál érdemes bekapcsolni a CKOPT-t, ahogy a fuse bites leírásban van, azt hol találom meg?

És volt valami olyasmi kérdés is hogy kell e feltétlen külső órajel.
Hát led villogóhoz nem igen. Sok mindenre elég a belső. Szerintem.

Ok, eddig nem értettem minek tesznek külső kvarcot a mikrovezérlőre egy led blinkinghez, ha egyszer belső rezonátora is van, de akkor gondolom, hogy ezzel is gyakorolja az ember a fuse bitek állítását, meg a külső rezonátor alkalmazását.

[katonafull]

Trükk:
a 32.768kHz órajelkvarc az XTAL1/XTAL2 lábon.
Ekkor _nem_ órajel, hanem ha megnézed az adatlapot:...

Nagyon jó, már majdnem minden világos! Hálás köszönet a magyarázatért.
Majdnem megkérdeztem, hogy na de hol van a CKOPT fuse bit az Atmega88 esetében?
Aztán megnéztem az adatlapot.
Ott kicsit máshogy van, de a vége ugyanez lesz.

Azért nem valami egyszerű dolog ez az avr programozás. Nagyon képben kell lenni. Adatlappal kell kelni, feküdni...
Hát igen. Ez nem arduino
Még egyszer köszönöm a magyarázatot!

[Robert]

Quartz mérete:

quartz magassag.jpg

A quartz működése:
https://www.youtube.com/watch?v=dUZFxMTEss0
(angol ill fordított magyar felirat)

A bekötése:
A kvarccal soros ellenállás a könnyebb indulási berezgés miatt van (rontja a rezgőkör jóságát (~1Mohm)), ahogyan időnként ugyanígy az egyik kondival sorban is szokott lenni (100Ohm....10k).

quartz.jpg

[Robert]

Órajelgenerátorok:

http://www.tavir.hu/tipp-orajel

[katonafull]

Ugye ha feltöltök egy progit a chipbe, és a feltöltés végén a verifying is OK lesz, meg minden, akkor az elvileg azt jelenti, hogy minden rendben ment.
De utána, ha kiolvasom a feltöltött hex fájlt és elmentem és totalcommanderrel tartalomra (mert tud ilyet. fájl menü/összehasonlítás tartalomra) összehasonlítom az eredeti hex fájllal, amit feltöltöttem, akkor azoknak pontosan meg kell egyezniük?

Mert ha én ezt megcsinálom, nem egyeznek meg. Van valami minimális eltérés.
A feltöltés elvileg rendben van, minden ok, ellennőrzés, verifying is.
Mégsem egyeznek meg tartalomra 100%-ban. Ez hogy lehet?
Igaz más a fájl neve, meg ugye a létrehozás dátuma, de gondolom annak nem kellene ezt befolyásolnia. Bár nyilván a fájl tartalmazza a fájlnevet is...
Szóval ez normális, vagy nem?
Kipróbálni még nem tudom, mert nincs itthon egy nyamvadt LED-em és most nem tudom, hogy sírjak, vagy nevessek.

[Robert]

A megegyezés lehet eltérés is
Ennek az az oka, hogy a vége, ahol üres, ott van amelyik HEX úgy írja, hogy:

Kód: Egész kijelölése

:0E7EF00009F441DDCE010197F1F722DDD0CF7C
:087EFE0000E10000000000009B
:040000030000780081
:00000001FF

(Leonardo bootloader részlet)

A nem kiírt adatok mindenütt FF (üres utasítás/törölt rész).

De van amikor:

Kód: Egész kijelölése

:101FB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF31
:101FC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF21
:101FD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11
:101FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01
:101FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1
:00000001FF

Visszaolvasott ATMega8 (STK500 programozó kód)

Itt ki van írva az összes FF.

Bár nyilván a fájl tartalmazza a fájlnevet is

Nem. Mi köze hozzá?


Ha LED nincs:
- Hangszóró? (közvetlenül mehet a lábra)
- Arduino alappanel? (D13 láb a LED)
- Zümmer?
- Relé? (az meg kattan)

[katonafull]

Köszönöm a magyarázatot!

Bár nyilván a fájl tartalmazza a fájlnevet is

Nem. Mi köze hozzá?

Úgy értettem, hogy nyilván minden fájl köteles a saját nevét és rá vonatkozó egyéb információkat is tartalmazni (mert egyébként mi más hordozná a név infót), ahogy egyes fotók is tartalmaznak egy exif részt, ami az expozíciós információkat tartalmazza. Pedig ez a képen nem látszik.
És azt hittem, hogy a totalcommander összehasonlítója ezt talán nem tudja és azt a részt is össze akarja hasonlítani.
Oké, buta ötlet volt, de jobb nem jutott eszembe erre a látszólagos anomáliára.

Ááá, az arduino led igen, az jó lesz.

[Robert]

A kép az tartalmazza.
A text alapú HEX nem.

A TotalCommander belső file összehasonlítása helyett én amit használok:
- HexED
- Examdiff

[katonafull]

Hát most nem próbálom ki az arduino-s leddel sem.
Ugyanis jól megszívatott ez a biztosító bit kalkulátor oldal:
http://eleccelerator.com/fusecalc/fusec ... =attiny24a

Beállítottam az ATtinyA-t, és néztem a fuse biteket...
Alul, ahol a pipákat be lehet tenni van egy "Default" feliratú csík, aminek minden oszlopban a gyári beállításokat kellene mutatnia egy gomb formájában.
Alatta meg az épp aktuális beállításod van.
Ha a szürke, default sorban rákattintasz valamelyik értékre, akkor abban az oszlopban visszaállítja neked a gyári beállításokat.
Csakhogy az ATtiny24A esetében a Default sorban a LOW fuse biteknél nem a gyári beállítást mutatja.
http://eleccelerator.com/fusecalc/fusec ... LOCKBIT=FF
Ha a Default gombok alapján állítod be, az nem az eredeti állapot lesz, hanem egy külső rezonátoros verzió.
Föntebb, a legördülő menüben pedig jól van. Ott egy belső oszcillátoros verzió végére van írva, hogy Default value.

Persze én nem a legördülőből választottam ki, hanem a Default gomb megnyomásával állítottam vissza eredetire, amit korábban elállítgattam, hogy megnézzem mi micsoda...
És a legnagyobb nyugalommal állítottam be a fuse bteket a chipben. Megvan életem első kizárt Chipje.

Ellenben az általatok ajánlott oldalon
http://www.engbedded.com/fusecalc/
megegyeznek a Defaults gombbal beállított és legördülőből kiválasztott gyári beállítás értékek.

Oké, ha megnéztem volna, hogy hiába nyomom a default gombot, az a gyáritól eltérő értéket állít be, meg fülöl a legördülőben sem a gyárit dobja be, akkor nem jártam volna így. Utólag már az adatlapon is leellenőriztem.
Mi ebből a tanulság?
Ha nem nézed meg az adatlapot, és nem az AVR-es öreg rókák által ajánlott fuse bit kalkulátor oldalt használod, akkor mehetsz a bótba' kvarcot venni.
Tényleg, arduinoval is fel lehet éleszteni nem?
Csinálok órajel kimenetet és kész. Minek ehhez kristály?
4 MHz-re ez jó lesz?

Kód: Egész kijelölése

void setup()
{
  pinMode(13, OUTPUT);
}
void loop()
{
  digitalWrite(13, HIGH);
  delayMicroseconds(25);     
  digitalWrite(13, LOW);
  delayMicroseconds(25);      
}

[Robert]

Elméletileg jó. Gyakorlatilag nem.
Ez a kimenetre 150 kHz jelet hoz össze. Miért?

Részlet a kezelőprogramból (wiring_digital.c):

Kód: Egész kijelölése

void digitalWrite(uint8_t pin, uint8_t val)
{
	uint8_t timer = digitalPinToTimer(pin);
	uint8_t bit = digitalPinToBitMask(pin);
	uint8_t port = digitalPinToPort(pin);
	volatile uint8_t *out;

	if (port == NOT_A_PIN) return;

	// If the pin that support PWM output, we need to turn it off
	// before doing a digital write.
	if (timer != NOT_ON_TIMER) turnOffPWM(timer);
	out = portOutputRegister(port);
	uint8_t oldSREG = SREG;
	cli();
	if (val == LOW) {
		*out &= ~bit;
	} else {
		*out |= bit;
	}
	SREG = oldSREG;
}

Ezért jó ismerni a chip belsejét
Sok-sok utasítás van egy-egy lábállítás mögött...

A kódoddal 150 kHz a kimeneti frekvencia...

Erre való pl. a FastPin eljáráskönyvtár:
https://github.com/bitfasching/FastPin

Eredmény:

Kód: Egész kijelölése

Measurements on an ATmega328 running at 16 MHz, setting one pin high and low in an infinite loop:
•digitalWrite: 5.05 µs per write, 10.3 µs per cycle (0.097 MHz)
•FastPin: 0.32 µs per write, 0.76 µs per cycle (1.3 MHz)
•direct: 0.13 µs per write, 0.38 µs per cycle (2.6 MHz)
In this test, the time for a complete cycle includes the loop overhead.

[katonafull]

Hmm... nekem ezek a port manipuláló könyvtárak valmiért nem működnek arduinoban.
Többet is kipróbáltam, de mindig valami hibát írt.
Pedig volt köztük olyan is, amiben kész példa is volt, mégsem ment nálam.
Próbálkoztam még ilyennel is:

Kód: Egész kijelölése

void setup() {
}
void loop() {
  DDRD = 0b01000000;
  PORTD = 0b01000000;
  delayMicroseconds(1);
  PORTD = 0b00000000;
  delayMicroseconds(1);
}

Mert mintha azt olvastam volna, hogy a direkt portkapcsolás is elég gyors lehet. ezzel a 6-os kimenetet akartam kapcsolgatni.
Fel is ment az unora, de hiába, nem segített. Mondjuk ezt még annyira nem értem, nyilván nem véletlenül hoznak létre mások erre könyvtárat, csak nem ilyen egyszerű ez. De gondoltam hátha
Aztán megoldottam egy bár nem valami elegáns, de annál inkább működő huszárvágással a dolgot.
Két kanócot odanyomtam az uno lapon lévő kristály forrszemeihez és azt vezettem az épp halálközeli élményt átélő chip xtal lábaihoz.
Már működik.

Arra azért jó lenne rájönni, hogy miért nem jó nálam a FastPin könyvtár.
Az arduino IDE újratelepítésével is próbálkoztam, de semmi változás.
Más az is fura, hogy mikor a FastPin.h-állományra hivatkozok, nem sárgul be, ahogy másnál meg be szokott.
Na mindegy, az a lényeg, hogy sikerült.

[Robert]

Könyvtár:
libraries alatt könyvtár Fastpin (ahogy a *.h és a -.cpp írva van).
Utána keretrendszer restart.