8 bitesen nincs.

Nagyon kínkeservesen meg tudod csinálni, ha az interruptokon belül oda-vissza maszkolgatod az interruptokat, de ez nagyon ingoványos talaj és nagyon tudnod kell, mit csinálsz.
Egy bizonyos interruptot ki tudsz úgy emelni, hogy nagyobb prioritása legyen, mint a többinek. Ezt úgy teheted meg, hogy a többi interruptban rögtön engedélyezed a további megszakítást - a nagyobb prioritásúban meg nem csinálsz ilyet, ott majd csak a reti engedélyez.
Ezzel semmi illegális dolgot nem csinálsz, hiszen ha minden IT rendesen le van kezelve és ment mindent, akkor a megszakítás akár másik megszakítást is felfüggeszthet, csak a stack használat lesz intenzívebb.
Ezt akár assemblyben, akár C-ben is el lehet játszani.

Köszönöm ismét! Arra gondoltam - lehet, hogy hibásan - hogy a 9600 b/s és a 7372800 Hz között elég nagy a különbség ahhoz, hogy többször is meg tudjam vizsgálni. De majd megpróbálom az általad leírt módon inkább.

A baj ott van, hogy véletlenszerű olvasással nem tudod garantálni, hogy nem egy félig beérkezett üzenetbe kapkodsz bele...

Ez nálam nem véletlenszerű. Úgy néz ki, hogy if (rx_buffer[64] == 'X' && rx_buffer[65] == 'Y'') { történjen valami. }
És mivel a főciklusom sokkal gyorsabb mint az USART 9600 b/s. így ezt pontosan tudom ellenőrizni. (Legalábbis remélem!) A te megoldásod biztosan sokkal jobb, de egyelőre ez is működni látszik. És nekem (most még) kicsik az igényeim.

Hát amit erénynek gondolsz, ez a baj.
Mert ha azt tapasztalod, hogy teljesül a két feltétel, akkor azt hiszed, hogy itt az üzenet. Pedig dehogy. Mivel egy sms 140 karakter hasznos információt hordozhat és egy karakter 9600Bd esetén durván 0.1msec alatt érkezik be, a Te vizsgálatod meg a 65. karakter után már készre jelenti a buffert, a hátralevő 140-65 = 75 karakterszer x 0.1ms = 7.5 ms-ig még özönlik a modemből a karaktersorozat, Te meg közben nekiállsz feldolgozni azt az üzenetet, aminek a fele még meg sem jött a modemből.

Még el is csesztem a számítást, a helyzet sokkal rosszabb. 9600Bd esetén ugyanis egy bit ideje 0.1 msec, egy byte - figyelembe véve a start-stop jeleket is - tízszer ennyi. A Modemből még 75 msec ideig jön az adat, amit nem dolgozol fel.

Sziasztok!
Egy egyszerű frekvenciagenerátorral vagyok elakadva.
Bővebben: Link - itt találtam.
Az a gondom, hogy közel sem azokat a frekiket adja, mint kéne, a kvarc semmit nem befolyásol, akár ki is vehetem. Az a gyanúm, hogy belső oszcillátorról fut. Az AVR-t viszont nem tudom újra programozni, mert a programozóm már nem látja. Szerintem a fusebiteket állítottam be hibásan, ezért próbáltam külső órajelről, de arra sem reagál.
Van valami ötletetek?

Ebben teljesen igazad van. De nekem csak annyira van szükségem, hogy egy ledet be- és kikapcsoljak. A sokkal nagyobb probléma azonban most jelentkezik. Most a modulnak kellene SMS-t küldenie felém, és ha így hívom meg, működik is.


A baj az, hogy amíg az rx_buffer-ben ezek az adatok vannak, addig küldi is szorgalmasan. Csak túl sokat. Viszont ha átírom, vagyis úgy kezdem a függvényt, hogy rx_buffer[64] =' '; akkor nem küld egyet sem.
Az sms küldő függvény tartalma:



Vajon miért kell ezt többször is meghívni amíg elküldi?

Köszönöm előre is!

if (rx_buffer[64] =='f' && rx_buffer[65] =='0' && rx_buffer[66] =='0') {
//rontsd el a vevőbuffert a küldés előtt, pl így:
rx_buffer[64] = '0';
send_analog_sms();

}

Úgy is próbáltam, de úgy sem küldi. Ha viszont nem rontom el, küld vagy 10-et mire leállítom. Olyan, mintha többször is meg kellene hívni mielőtt egyszer elküldi.
Mennyit kell várni? Elég a _delay_ms(1000)?

Ha a program fut rajta, de programozni nem tudod, akkor elég jó eséllyel a RSTDBL vagyis reset disable fuse-t programoztad be. Ez arra való, hogy tudod általános célra használni a reset lábat is.

Megoldás:

-Szerzel egy STK500 panelt (nem a klónt, hanem a marha drága igazit)

-Szerzel egy Avrdragont

-Megépíted az un. fusebit doctort

Mindhárommal lehet programozni a reset disable -s AVR-eket is. Tehát van lehetőséged arra, hogy a fuseokat rendbe tedd,

-További lehetőség: Ha ez egy JTAG képes AVR, akkor megpróbálkozhatsz JTAG-es programozóval rendbe rakni.

Én csak annyit szeretnék, hogy ez az eszköz is tudjon küldeni nekem egy SMS-t, lehetőleg valami mért vagy vett belső adattal.

Az elküldés módja a következő lenne:
Teljesül a feltétel.
Megszüntetem a feltételt;
Meghívom az SMS-küldő függvényt.
Visszamegyek a főciklusba.

Az SMS-küldő függvény USART1-en küldi az AT-parancsot a kontroller felé. De nem múködik és nem jövök rá, hogy miért.

Vagyis működik, ha nem rontom el az rx_buffer[64]-et. De akkor küldi ám folyamatosan.
Az időzítéssel lehet a baj. Vagy nem jól csinálom? De hiszen az előbb kaptam vagy 6-ot ismét.

Egy régebbi post-ban már írtam - lehet, hogy nem Neked - hogy a modem OK válasza nem jelenti azt, hogy a parancsot végre is hajtotta. Az OK csak annyit jelent, hogy "értettem". A parancs végrehajtásának időigénye attól függ, mi volt a parancs.
Még tiszta viszonyok között is ügyelni kell erre, de ezek egyáltalán nem tiszta viszonyok, ahogy próbálkozol. Valószínűleg a rendesen le sem kezelt üzenet miatt bolondul meg a modem, pláne ha orrba-szájba zúdítod rá a parancsokat.
A feladat egyszerűsége nem jelenti azt, hogy ezeket felületesen lehet kezelni. Tudnod kell, hol tart a modem, nincs-e még közlendője, a küldési parancsot nyugtázta-e, tudja-e teljesíteni, nem küldhetsz találomra parancsokat. Amíg nem teremtesz korrekt viszonyokat, addig minden véletlenszerűen fog működni

Szia,

Nos a probléma az volt, hogy a panelen volt egy rövidzárlat és rengeteg lábat földre húzott. Amint ez megszünt azonnal műkködött a rendszer, szóval a probléma ott volt.
Azota felmerült egy új kérdés bennem. Sajnos most nincs lehetőségem szkóphoz jutni, de szeretném tudni a pwm frekveniáját. Szóval a programban megadom a cprd értékét. Ebből a periódusidőt az adatlapon látható
(2 × X × CPRD)/CLK_PWM képletből számolandó ahol, ha cpre=0b0000, akkor x=1. Jól gondolom?

Szerintem az egy rendesen lekezelt üzenet. Tudom, hogy mit küldök és tudom azt is, hogy erre mit kellene csinálni. Én a 3-4 elküldött karakterem után nem várok további 140-et, hanem ott a vége és kész. Erre kellene reagálnia az eszköznek. És amíg a ledeket pontosan kapcsolgatja, addig az SMS-t nem küldi el, csak ha a ciklus milliószor lefut közben. Ez itt a nagy baj.

Sziasztok!

Olyan gondom lenne, hogy atmel atmega8-as avr mikrovezérlőhöz kellene csatlakoztatni rf segítségével két hőmérőt, és egy vérnyomsámérőt.
Körülnéztem de nem nagyon találtam semmit...

Teljesen új vagyok ebben a témában, ezért kérem a segítségetek!

Előre is köszönöm!

Akkor jól van. Nem fogom ismételgetni, amit már leírtam. :yes:

A különbség az, hoigy amíg te timeout-tal teszel 0-t a végére, én tudom, hogy az enyémnek hol a vége. Én meg akkor teszek. És mivel én küldöm az SMS-t, jól tudom, hogy fejeztem be. Ebből a szempontból nincs sok különbség a két eljárás között. Majd kitalálok valami mást, ami nem SMS-re küld SMS-t, hanem más feltétel teljesülése esetén. Csak arra kell vigyáznom, hogy az a feltétel egyszer következzen be. vagy legalábbis ritkán. Megszakításra gondoltam, lefutó élre. Szerinted egy megszakítás rutinba illik tenni SMS-küldő függvényt? Valami azt súgja, hogy nem tanácsos, de inkább megkérdezek tőlem sokkal nagyobb tudásúakat, pl. téged.

100%, hogy neked van igazad. 7-es interruptra (lefutó él) küldi.

Interruptba nagyon nem illik ilyen hosszadalmas procedurát tenni.
Nem az a lényeg, hogy mikor történik a vételi puffer lezárása, hanem hogy elegendő időt kivársz-e, miután vettél valamit, ha válaszolni akarsz, nézed-e hogy lenyugtázta-e a modem a parancsot, ha nem nyugtázta le a küldési parancsot, milyen hibakódot ad vissza, vársz-e eleget, míg megpróbálkozol újra küldeni. Ez nem úgy működik, hogy ó, én egyelőre csak a szomszéd faluba szeretnék repülni, de majd utána megtanulom rendesen a repülővezetést. Ha nem hibátlanul repülsz, lezuhansz. Nem számít hogy öt vagy ötezer kilométert akartál repülni, ha nem a nagykönyv szerint csinálod, az öt kilométer sem fog menni.
Ha nem ment el az sms, akkor hiába próbálod újra és újra erőszakolni, ha nem figyelsz a modemre, hogy vette-e a parancsot, csak azt éred el, hogy kiakad és zavaros válaszokat ad, esetleg csak resetre vagy tápfesz kikapcsolásra tér magához.
Soha nem kell ismételni az sms küldést, ha nem bolondítottad meg a modemet. De hát úgy tűnik, hogy semmit nem ellenőrzöl, csak szólongatod a modemet, az meg hiába panaszkodik, nem figyelsz rá. Én meg hiába koptatom a számat.

Már RF terén nem találtál semmit, vagy elképzelésben?

Megcsinálom a te eljárásod szerint inkább.

Üdv mindenkinek!
Építettem egy USBASP programozót és a benne lévő Atmega48 felprogramozásához szeretnék segítséget kérni.
A programot egy Willem 5 égetővel írnám be. A konfig beállítása lenne a kérdés, hogy mit mire állítsak.
Az ITT található oldalon az usbasp.2006-12-29.tar.gz mappába lévő atmega 48 forrást szeretném beírni. A szerkezet 12MHz es kvarcról jár. Mellékelem az égető beállítást.
Mit mire állítsak?

Attol fugg, ha kozepre igazitott, akkor igen, ha nem kozepre igazitott, akkor 2xCPRD/CLK_PWM.
A 32 bites AVR-nel nagy elony, hogy a PWM alap orajele joval nagyobb lehet a CPU orajelenel, igy eleg nagy frekvenciaju jelet elo lehet allitani.

* LFUSE=lfuse:w:0xff:m*
* HFUSE=hfuse:w:0xdd:m*
* EFUSE=efuse:w:0xff:m*

Nagyon köszönöm UbiLinuxnak a privátban nyújtott segítséget mind a jelenre, mind a jövőre vonatkozólag!

Nincs mit. Csak szólj magánban, hátha még hozzá tudok szólni!

1. szerzel egy programozót, egy atmega8-as fejlesztő boardot/próbapanelt atmega8-cal.

2. megvillogtatsz pár ledet, ahogyan illik, megbarátkozol az adatlappal.

3. Szerzel egy hőmérőt, vérnyomásmérőt(?), és működteted őket a villogó led mellett.

4. megnézed milyen rf lehetőségek vannak, választasz egyet.

5. megpróbálod összehozni az egészet egyben.