Természetesen.
Csupán követtem Gery hozzászólásait és úgy tűnt, hogy gyakran nagyon mellé nyúl. Gondoltam figyelmeztetem, hogy megspóroljam neki a kiégett IC cseréjét. Így felsorakoztattam a laikusan hangzó érveimet, hogy véletlen se kösse rá direktbe.

Amennyiben eszébe sem jutott, akkor elnézést kérek tőle, hogy feltételeztem róla.

Helyesen tetted, en nem tudom levetkozni a naivsagomat ezen a teren. Legalabb figyel valaki helyettem is.

Azt hiszem, hogy értem. Nekem az jutott eszembe, hogy mind kettőre csinálnék IT-t és amelyik előbb érkezik be az tiltja a másikat... szerintetek melyik lenne a könnyebb? (Egy rövid kis indoklással)

Nem, a motor hardvere rendben van, ennyit még én is tudok. Viszont ami érdekes, hogy most szkóppal mérem a lábakat, és ha gpio_set_gpio_pin(AVR32_PIN_PA07)-et beírom neki nem történik semmi. Ennek a parancsnak a a gpio.c szerint :

void gpio_set_gpio_pin(unsigned int pin)
{
volatile avr32_gpio_port_t *gpio_port = &GPIO.port[pin >> 5];

gpio_port->ovrs = 1 << (pin & 0x1F); // Value to be driven on the I/O line: 1.
gpio_port->oders = 1 << (pin & 0x1F); // The GPIO output driver is enabled for that pin.
gpio_port->gpers = 1 << (pin & 0x1F); // The GPIO module controls that pin.
}

magas szintűre kéne emelnie a lábat bárminemű extra beállítás igénye nélkül, nem?
Vagy valamit kifelejtek, esetleg a hardverre lenne probléma?>

Nos a panelon lesz valami elkötve mert egy másik mikrokontrolleren működik a gpio parancs legalábbis.

Úgy néz ki, hogy megy a szekér...
viszont lenne egy olyan kérdésem, hogy beérkezik az INT4 megszakítás, rutin lefut, eddig jó. Miért ugrik újra a vektor tábla következő sorára és nem vissza a main függvénybe?

Az aktuális megszakítás reti-vel van lezárva?
Nálam akkor csinált ilyet, ha csak ret-et tettem, vagy elhagytam a lezárást.

Amúgy meg szerintem ez a cikk határozottan sokat fog segíteni:Inkrementális szögadó illesztése mikrokontrollerhez

köszi a cikket, tényleg jó. A lezárás RETI-s.
arra gondoltam hogy a main túl rövid, hogy nincs benne semmi, és igen... pár NOP-pal el is tünt a jelenség.

Üdv
Lenne egy lehetőség smd Pic és Atmega kontroller programozó adapterek legyártására egy nyákgyártó cégnél. Egy kedves ismerősöm már megtervezte a nyákokat. Mivel főleg Pic-el dolgozunk,így legtöbb ezekhez a típusokhoz van, kb. 11db. Egy Atmega8 van csak. Mellékletben ennek a nyákterve,amit szeretnénk ha valaki hozzáértő átnézne,nehogy hibásan gyártassuk le.
Viszont Ha lenne más tipusra is igény, és valaki megcsinálja a nyáktervet, azt hozzá tesszük a többihez. Vasárnapig kellene, mert hétfőn már gyártás.
Előre is köszi

Szia! Lenne egy olyan kérdésem, hogy amikor a megszakítás érkezik mondjuk felfutó élre, abban az időpillanatban a port állapotát, hogyan mintavételezhetem?

Az interrupt az élváltozás után már jó pár órajel ciklusnyi idővel később érkezik be, tehát ott a hagyományos PINx olvasással már beolvashatod a portot.

Ha rotary A-n van az interrupt, akkor beeséskor megnézed hogy a B magas vagy alacsony. Ennek megfelelően tudod hogy előre / hátra tekerték el.

Azzal a furcsa jelenséggel álok szemben, hogyha az encoder-t eltekerem (egy kattanás) akkor ha a programot F11-gyel léptetem, akkor egy lépés után a PINE regiszterben egyből megjelenik a két bit változás (4,5). Nagy ritkán van az, hogy csak külön külön. Valahogy ezt folyamatosan kéne figyelni... De hogyan???

Mekkora az enkódered felbontása? Az egy "kattanás" biztos, hogy csak 1 csatorna megváltozását okozza? Azt sem tartom kizártnak, hogy ha egy "kattanásnyit" forgatod, addigra többször is állapotot vált az enkóder mindkét csatornája, ezért van hogy mindkét bit jelzi az interruptot.Ha F11-el léptetsz, akkor sehogy nem tudod így figyelni, megírod mindkét interruptot és mindkettőbe raksz egy egy nop ot, breakpointtal, ahol először áll meg az hajtódik először végre mozgáskor ha reti után ugrik a másik megszakításra, enélkül, hogy mozdítottál volna az enkóderen, biztos lehetsz abban, hogy mindkét csatorna okozott interruptot.
Kiborg

Az enkóder kettő "kattanásra" produkál egy teljes periódust és a két csatorna is párhuzamosan fut 90° eltolással.

Sziasztok!

Nincs valakinek ötlete, hogy a kódrészlet ellenére miért kerül bele az OK az rx_bufferbe?



És elvileg a NO CARRIER-t is így kellene látnom: N CARRIER.
Köszönöm előre is!

Bool algebra alapok.

Negáltak vagy-olása, és és-elése probléma. Avagy negáltak összeadása ellenben a negáltak szorzásával.

data != O ÉS data != K.

Bővebben: Link

De a data minden megszakításkor változik. Vagy nem?

Igazából az SMS beolvasásával nem boldogulok.
Az AT+CMGR=X -re visszajön a +CMGR: "REC READ","+36703146459","","2011/11/11 16:10:09+04"

de a tartalom nem, vagy nem mindig látszik az rx_bufferben.
Ezzel töltöm a tömböt:


Előre is nagyon köszönöm, ha valaki megvilágosít!

Hmm.. Gondold végig lassan

Beérkezik az 'O', azaz data = 'O'.
Elágazásod:
if(('O'!='O') || ('O' != 'K')) -> Ez esetben az IF igaz lesz az O != K miatt.

Beérkezik a 'K', azaz a data = 'K'
Elágazásod:
if(('K' != 'O') || ('K' != 'K')) -> Ez esetben az IF ismét igaz lesz, de most a K != O miatt.

Tényleg! Fáradt vagyok, éjszakás voltam.
Nagyon szépen köszönöm!

A legnagyobb problémám azonban a következő:
Az aláhúzással elválasztott karakterek a buffer első négy eleme.
Csillaggal van lezárva.


És amint látszik, az SMS tartalma az 1234 helyett üres,\n(vagy \r?),üres,üres,4 lett.
Ez vajon mitől lehet?
A kód amivel töltöm, lejjebb található. A feltételt már kijavítottam.

Előre is nagyon szépen köszönöm!

Szerintem az SMS végére is kellene egy '\0', de azt nem tudom, hogyan illesszem oda. Kibővítettem a kiírást egy karakterrel és az látszik, hogy innen már jó is lenne.



A space a _ a newline pedig az új sor.
Ha jól látom, az első elem sortörés lehet. De vajon mitől?
+CMGR: "REC UNREAD","+36703146459","","2011/11/11 19:32:47+04" Ez után van egy 0x0A karakter, az a '\n', és erre én egy '\0'-t íratok be. Az meg ott is van a második sor első elemében, ugye? a __4_5* előtt. Nekem tehát vagy nem a '\n'-re kellene nulláznom, vagy pedig ezzel az egy esettel (SMS) kellene kivételt tennem. Jól gondolom?

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

Megoldódni látszik ez a probléma is, egy feltétel beillesztésével, ami azt mondja, hogy csak akkor cserélje le a '\n'-t '\0'-ra, ha a számláló kisebb mint 50.



60 fölött kezdődik ugyanis az SMS tartalma.

Lehet, hogy nem tökéletes, mert csak egy SMS-t kezel jól. Utána újra kell indítani.
Szerintem nincs az SMS végén '\0'. Honnan lehetne ezekről többet tudni?


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

Lehet, hogy nem valami elegáns megoldás, de úgy működik, ha egy *-ot írok a végére, majd ennek hatására is beteszem a '\0'-t.


Ez megoldotta, nem kell újraindítgatni. Tákolmány?

Alapvetően az a baj, hogy a buffer kérdezgetésekor nem tudod, hogy az egész sms már megérkezett és ott van a bufferedben vagy még fognak jönni karakterek.
Én ezt úgy oldom meg, hogy egy timer interruptot is használok erre a feladatra. A dolog úgy működik, hogy az uart vevő rutin az érkező karaktert beírja a bufferbe ÉS egy számlálót beállít úgy 10 msec körüli értékre. Aztán az IT-nek ezzel vége is, mást nem is csinál.
Viszont a timer IT - ha úgy találja, hogy ez a számláló nem nulla - akkor elkezdi csökkenteni. Ha közben újabb karakter érkezett az uart-ba, akkor az uart rutin számlálót megint beállítja a 10 msec körüli értékre, hiába csökkentette a timer.
Ha viszont nem érkezik 10 msec alatt újabb karakter, akkor a számláló le tud nullázódni. Mikor a nullázódás megtörténik, a vevőbufferbe írok egy stringzáró nullát és egy jelzőbiten jelzem a főprogramnak, hogy a bufferben érvényes tartalom van.
A mechanizmus azért elegáns, mert a két interrupt elintéz mindent, a főprogram akárhol is bóklászhat közben, majd a jelzőflag értesíti róla, hogy teendője van. A jelzőflag lekérdezését meg ráérek akár másodpercenként is elvégezni.

A kód abból a szempontból nagyon csúnya, hogy írásakor még nem ismertem a konvenciókat, tehát ezt a stílust ne kövesd. C-ben a változókat csupa kis betűvel illik írnia, a konstansokat meg csupa nagy betűvel.
A timer it végén direkt benne hagytam négy másik számláló kezelését, hogy látsszon, hogy ugyanaz az it kezeli a program több, avételtől független számlálóját is.

Köszönöm szépen! De ha én megmondom az SMS-sel, hogy hol a vége (*) akkor az is jó, nem? Végül is működik. És legalább tudom, hogy a GSM modulnak küldöm, nem a feleségemnek. (De szép is lenne az asszonyt is így irányítani! Valaki erre nem tud megoldást? )

Sziasztok!

Azt szeretném kérdezni, hogy van arra mód, hogy prioritást módosítsak az megszakítások között?

(mondjuk két egyenlőt csinálhassak?)

Annak mi értelme?

Persze, hogy jó lehet, de honnan tudod meg, hogy vége az modem által küldött üzenetnek? Ha szerencsétlen pillanatban kezded el vizsgálni a buffert, azt látod, hogy bejött a fejrész, pl. az, hogy +CMGR: "REC UNREAD", stb.stb és még öt karakter, ami a tulajdonképpeni özenet. Honnan tudod, hogy nem hat, tíz vagy további negyvenhét karakter következik még? Mi biztosítja, hogy az olvasásod nem egy elkapkodott beleolvasás egy még be nem fejezett üzenet elejébe?
Nálam a program csak akkor foglalkozik a program a bufferrel, ha 10 ms várakozás után sem jön újabb karakter. Ekkor garantáltan vége az üzenetnek, lehet olvasni.