Van egy olyan gyanúm, hogy itt valami kontakthiba/elkötés lesz. JTAG engedélyezve van alapból az arra képes chipeken.(tapasztalat) Én is M16-t használok és még nem volt ilyen gondom. Kedvedért fogom magam és átnézem én is, hogy mi hova van kötve.

Köszi kontakthiba nem hiszem. Minden kábelt bekötéskor szálfolytonosság mérővel ellenőrzök bekötött állapotban is. A szalagkábelt is kimértem már 100%-os. Hacsak én valamit rosszul kötök de ezt nem tudom elég sokszor átnéztem stb újra összeraktam.

Szia!
Rájöttem, hogy mi a is a gondod
Miért kevered ide a MOSI/MISO lábakat??? A JTAG-nak megvannak a specifikus lábai, mégpedig a C porton !!!! Nézd meg az adatlapon, hogy melyik micsoda és hogy hol helyezkedik el.
Te a JTAG-t az SPI portra kötötted rá, aminek NINCS ÉRTELME!!!
A videón ezért volt furcsa, hogy a M16 DIP tokozásának a C portja (24-27 PIN-ig) üres!!! Oda kell kötni a megfelelő lábakat.
Amit TE nézel rajzot, azon azért van a JTAG az SPI-re kötve, mert ő egy PROGRAMOZÓ lesz!
Nézd a rajzot.

Nah ezt nem tudtam. Semennyit sem értek ehhez
Máris meglesem akkor hová kell kötnöm.
Jah és köszi!

Király, működik is! Örök hála!

Mint már irtam van a szerkezeten 6 nyomogomb. Az egésznek 2 alapfunkcioja van. Az 1.
gombbal szeretném megválasztani az üzemmodot A és B között.
Már benne van az 1-s gomb kodjában az üzemmod kapcsolo a 6. gomb benyomása anulálja az üzemmodot. Az egész egy irq hurokban van, ahonnan a gombok benyomása alapján ugrok a megfelelö szubrutinba.
Mi lenne a legjobb megoldás erre az üzemmod választásra?

Szerintem te nagyon nem vagy tisztában a megszakítás lekezeléssel!
Istvanpisti tanácsai is lepattantak rólad, pedig jó irányba próbált terelgetni.

Szóval ilyesmit, hogy: Megszakításból kiugrok elvégezni a feladatott másképpen kell megoldani.

Ennek a témának nézzél kicsit jobban utána!
PL.: AVR-Tutorial: Interrupts
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Interrupts

Lehet, hogy csak nem tudom magam jol kifejezni ( nem vagyok SW guru, lehet, hogy azt kellett volna irnom, hogy a megszakitásokba beugrok leolvasni a gombokat. ).
És valoban küzdök a megszakitásokkal, de az a kettö, amit már sikerült összehozni, egész jol müködik.
A progiban csináltam egy háttér rutint, ami a megszakitásokat kezeli - egyelöre a gombokat meg a displayt, még egy harmadik dolog is lesz.
Szoval igyekszem követni Pisti ( meg egy sereg irodalom, ill. tanárom) tanácsait, csak még nem mindent értek egészen és ez okozza a legtöbb bajt.
Egyik legtöbb fejtörést okozo kérdés, hogy az a háttér rutin rendszeresen hivatott lekérdezni a nyomogombok állását, ill a displayt frissiteni ( más más sebességgel), ugyanakkor a föprogramban levö flag állására is hivatott reagálni ( legalábbis az én értelmezésem szerint, és itt vesztem el mindig a fonalat. ).
Az irq-ben ugy van ahogy mondjátok, csak néhány változo változik, amik a programban vannak feldolgozva. Nincs benne sem delay sem egyébb idötrablo feladat.
Na mindegy, megyek biteket varázsolni hátha rajövök a kérdés nyitjára. Marhára bosszant, hogy ezzel ennyit küzdök. Megirtam a komplett display vezérlést, az eeprom is azt csinálja amit akarok, az idözitések is már mennek, de ezzel vacak interrupttal szenvedek.

Szia!
Leírod pár sorban, hogy program mit csinál, mit kellene csinálnia (mér valamit...)? Milyen LCD-t frissítesz 20Hz-cel, mit kell megjeleníteni? A gombokat miért kell 200Hz-cel olvasni (5ms)?
Ha többet lehetne tudni, talán több segítséget is tudnánk adni.
Annak idején, amikor én birkózni kezdtem a megszakításokkal, akkor nagyon sok kódot nézegettem és abból próbáltam kihámozni a logikát. Sajnos csak a C-t ismerem úgy, ahogy önszorgalomból megtanultam, a gépi kód kimaradt az életemből. A program felépítésének logikája a fontos, nem annyira a megoldás eszköze, bár gépi kódban lehet hatékonyabb programot írni.

Kösz Pisti a türelmed.

Az egész szerkezet 2 léptetömotort hajt meg, amiket alapbol kell programozni, több szempont szerint.
A programozás eredményét a 4x20s LCD jelzem ki. Az 1. meg a 3. sorban csak a fejléc van, alatta meg az odavágo változok. (Idö, lépés, irány, ism.) Mindezt 2x.
Az A (F gomb) üzemmodban a 6 gombbal a változok értékei változtatom karakterenkét. <> lépteti kurzort a megfelelö helyre, ^v gombok meg növelik csökkentik az értéket (szinte mindegyiket más modon és tartományban).
Az ENTER gombbal meg elmentem az EEPROMba. Ez már mind megy!!!
(mintegy 80 oldal ASM Listing formában). A nyomogombok lekérdezét azért gondoltam felgyorsitani, mert azokat az ember gyorsabban képes nyomogatni, és rossz, az, ha nem reagál (vagy nem látod). Nem biztos, hogy a 200Hz lesz a végleges, de mindenképpen >20Hz, ami a displayt frissiti, azon amugy sem látszik.

Most jön a következö feladat a B üzemmod.

Ilyenkor a motorokat a nyilakkal megfelelö állapotba kell mozditani (az egyik motor fel/le a másik jobbra/balra).
Azaz fizikailag be kell állitani az kiindulási pontot. Ha ez megvan, akkor az ENTER gombbal a displayen beállitott adatok szerint kell a motoroknak automatikusan mozogni.

Az a feladat, ennyi kodot nem hiszem, hogy ide be lehet rakni, meg ki a fene fog az én balhémmal szorakozni.... (elég ez nekem is).

Szoval az egész szerkezet hasonlit egy CNC vezérléshez, de PC nélkül, és mindez elemröl megy egészen más idötartományban.
Sajnos én is gyakran a program logikájában veszek el.

Abban reménykedtem, hogy a listing ugy nyomtatja ki a programot, ahogy az valoban fut (soronként egymás után), de sajnos nem ez a helyzet. (vagy nem tudom hogyan lehetne azt beállitani).

Bocs, de 2 sorban nem sikerült, attol ez joval bonyolultabb.

Na most már kezdem érteni, miért szeretnéd a nyomógombokat gyorsan kezelni (legalábbis úgy gondolom) Tehát én úgy értem, hogy tág határok között kell léptetni változók értékét, emiatt kell sűrűn leolvasni a nyomógombok állapotát, hogy ne kelljen percekig nyomogatni a kívánt érték eléréséig. Nem tudom gondoltál-e, vagy teszel-e valamit a nyomógombot pergésének kiküszöbölése ellen. A pergés 100-200ms ideig is eltarthat és, ha közben többször leolvasod az állapotát, akkor azt fogod detektálni, hogy valaki gyorsan nyomkodta a gombot és gyors - esetleg nem szándékolt - lépkedés lesz a végeredmény. Azt értem, hogy most ezzel nem lehet teljes mélységében foglalkozni, de leírok egy-két lehetőséget arra, hogy a pergést is kiküszöböld és a sebesség se szenvedjen kárt.
1. Ne csak 6 gombot használj, hanem még 10-et 0..9 (számokat) és akkor nem kell gyorsan léptetni, hanem elegendő az érték beírása. Nyilván ez hardver változtatással jár, de nem túl vészesen bonyolult, mátrixba kötve (16 gomb) 4+4 portláb elegendő.
2. Marad 6 gomb, de a lenyomása detektálása után - pergés leteltét megvárva - a lenyomás hosszától függően gyorsul a változó léptetése. pl 1 mp-ig történő lenyomására csak minden 10. lekérdezésre növeled/csökkented az értéket, a 2. mp-től már minden 5. lekérdezésre....
A pergést úgy lehet kiküszöbölni, hogy az első lenyomáskor beállítasz egy változót (lenyomva), majd, ha 100-200 ms időn belül felengedték akkor törlöd, ha nem történt felengedés, akkor egy változóban visszaadod a lenyomott gomb kódját. A főprogramban figyeled a lenyomva és a gomb változó értékét is. Lehet azt is, hogy a gomb változóba csak akkor kerül érték, ha letelt a 100-200 ms idő - és közben nem engedték el - csak utána, így nem a lenyomást, hanem az elengedést detektálod. Ez utóbbi módszer nem jó gyors leolvasásra.

Az LCD frissítésének nagy gyakorisága számomra még nem érthető. A leírtakat úgy értem, hogy az LCD-n csak akkor változik az érték, ha a nyomógombokon akció van. Nem elegendő ilyenkor frissíteni a kiírást? Tehát az a rutin ami feldolgozza a megszakításban érzékelt gomb nyomást a főprogramban, az lépteti a változók értékeit és utána meghívja a kiíró rutint. Ha lassú az LCD kezelés, akkor a nyomógombok leolvasása a megszakításban meg fog történni, de onnan visszatérve a vezérlés, oda megy vissza, ahol előtte abbahagyta, az előző LCD kijelzés hívásba, ami befejezi az előző kijelzést. Tehát, ha az LCD kijelzés idő szükséglete összemérhető a gomb lekérdezési időkkel, akkor nem várt hatások jönnek majd elő. Ez is a gyors billentyű lekérdezés ellen szól.
Írod még, hogy telepről fog üzemelni, ez előrevetíti egy újabb kihívásokkal teli ismeretlen terület felfedezésének szükségességét a nem túl távoli jövőben, amit egyszerűen csak sleep üzemmódoknak lehetne nevezni. Ezek az üzemmódok nagyon hatékonyan képesek csökkenteni a uC teljesítmény felvételét, de használatuk körültekintést igényel. Előbb utóbb úgyis el fogsz ide majd jutni, bár most még nem ez a problémáid súlypontja, de érdemes fejben tartani.

Kösz a segitséged.

A pergés meg lett oldva egy rutinnal (ezt már régebben megirtam és eddig más programokban teljesen bevált, és aránylag könnyü optimalizálni)

Sajnos nincs annyi helyem és lehetöségem, hogy számokkal adjam be az értékeket, de mint mondtam ez a része a programnak már müködik.
Az LCD-vel pontosan az a gondom amit te is leirtál, csak nem tudom magam mindig érthetöen kifejezni.... .
Van egy lcdupd flagom, ami akkor jelenik meg, ha változás van (azaz, ha a gombbal változattam az értéket), csak itt kerülök még néha konfliktusba a gondolataimmal. Elöször azt gondoltam, hogy elég lesz soronként az LCD frissitése, de sajnos az nem jött össze, mert az egyes karakterek egyenként változtatom, és csak akkor irom az EEPROMBa, amikor ezt a munkát elvégeztem, viszont az LCD-n minden karakter változást egyenként kell látni, igy most egyszerre frissitem, akkor amikor a gomb megváltoztatja az értéket. Egy irq-ben csak eggyel változhat, ami nem is baj, hiszen maximum 10 lépés egy-egy karakter (a többség még annyi sem, az ora csak 59 percig megy, azaz 6 ill 10 érték, a lépések százas értéke meg mindössze 3 -0,1,2).
Azaz, a a gomb lenyomását érzékeli az irq, elvégzi a pergéstelenitést (most 4x egymás után ugyanannak az értéknek kell megjelennie), gyorsan eldönti, hogy melyik gomb lett a 6-bol lenyomva, ennek megfelelöen állit egy változot, ami a föprogramban elvégzi a megfelelö feladatot, frissiti az LCD-t majd vár az ujabb gombnyomásra.
Igen a SLEEP modokkal számolok a motormeghajtásban is van extra bemenet a SLEEP modra.

Az LCD automatikus frissitésére majd a B üzemmodban lesz szükség (maximum másodpercenként egyszer), amikor az orajel kezeli a displayt (számol vissza) és jelzi ki az LCD-re az adott lépést/állapotot.

Jo, hogy igy eldumálgatok a feladatrol, mert közben eszembe jutnak ötletek, hogy hogyan is kellene most továbblépni. Majd mindjárt nekifogok a kodnak.

HW-SW kérdés:

készítettem egy egyszerű kapcsolást attiny 2313 -vel, mellyel a mellékelt ábra Switch drive és Swith Input jeleit olvasnám. Úgy tűnik minden jól müködött teszt körülmények között,de ha az eredeti CPU panel működött rögtön zavar volt, az input portok zavarták a rendes működését a CPUnak.
Mi lehet a gond? tegyek diódákat a uC és a switch csatlakozók közé , jelenleg a csak szalagkábeles összeköttetés van a input felhúzóellenállások bekapcsolva vannak.

Sziasztok!
Sikeresen bekapcsoltam egy attiny45-ben a DWEN-t... S csak utólag néztem meg, hogy az mi...
Tudtok nekem ajánlani egy működő fusebit dokit?

Nagyon megköszönném...

Köszönettel,
Dani.

Tegnap megprobáltam rendbe tenni az IRQ-t meg egyébb dolgokat, és sajnos megint megjelent ugyanaz a baj, amit már ismerek korábbról. Ha léptetem a programot hibátlanul müködik, ha betöltöm a chipbe akkor némelyik gombtól megzavarodik. A displayen rossz helyen rossz karakterek jelennek meg, holott a RAM-ban (amit elmentek az EEPROMba az értékek rendben vannak, azaz ha ujra inditom, és kiolvasom az EEPROMot akkor megint jo lesz a kép a displayen beleértve azt a változot is, ami korábban kiváltotta a hibás display kijelzést.
A C képen a 122-es értéket változtatom 132-re. Az LCD-n a D ábra (vagy hasonlo) jelenik meg, a RAM-ba ill. az EEPROMba a helyes érték kerül (ujra kiolvasva B kép).
Tegnap a orajel lassub sebességével majdnem tökéletes volt (csak 1-2 aprobb hibát csinált). Amiota ujra rámoltam a rutinokat, azota megint ezt csinálja. Pedig tegnap teljesen szétválasztottam az LCD kezelését a nyomogomboktól.(most az orajel csak lelassitja a folyamatot, de a hiba megmarad)

Találkoztatok ilyesmivel? Miután léptetve hibátlanul megy a program (akkor is ha pl. csak 1-2 megállot/break berakok a futtatásba), képtelen vagyok megtalálni az okot.

Csak nem flipper?

Pontosan hova kototted az ATtiny-t?

Úgy tűnik, hogy a kijelzést zavarja meg a nyomógomb kezelése. Tegnap írtam, előfordulhat olyan eset, hogy az LCD-re író rutin még nem végzett és ha közben közben jön a megszakítás az esetleg gondot okozhat. Ahhoz, hogy a hibát be lehessen határolni, próbáld meg az LCD rutin előtt tiltani, utána pedig engedélyezni a megszakítást. Ha ettől jó lenne, akkor az LCD rutin környékén kellene majd szétnézni.

Kösz du. kiprobálom.

Sziasztok.
Az EXTREME BURNER programot szeretném használni, az égetőm usbasp v2.0-ás. A problémám az ott van,hogy a programba a FLESH-be behívom a hex-et szépen betöltődk. Az epp-ét behívom az EPROM-ba " pedig az eprom van kijelölve" a programban visszaugrik a FLESH-re, oda tölti az eprom állományt.
Kérem aki tud segítsen megoldani ezt a problémám.
T: István

De bizony....
a csatlakozó lábakra tettem rá J8, J10 az inputokat, ami elvileg szintén felhúzó ellenállásokra van téve.
Az output pedig egy sparkfun mp3 trigger (saját hang))

Hát sajnos semmi javulás, de nem adom fel....

Megépítettem a sematikus kapcsolást amikor a uC-t ráteszem az eredeti panelra összezavarodik az optocsatolás ellenére és nem működik helyesen félre vagy nem jelzi a kapcsolók zárását.
Szerintetek mi a hiba oka?

Szerintem kevés a belső felhúzó ellenállás a bemeneteken.
(Bekapcsoltad őket?)
Oda kellenének külső 10K felhúzók.
Bővebben: Link

A gond nem az AVR-nél van, hanem ha a flipper panelre rácsatlakoztatom akkor a flipper jeleit zavarja valamiért, azt gondoltam, hogy az optocsatolás kizárja az esetleges adat zavarokat, de sajnos nem és ezért nem működik a flipper.

Tudnad egyertelmusiteni, hogy az eredeti flipper rajzon melyik csatlakozo melyik? En egyszeruen nem latom, hogy melyik a J10 es melyik a J8.

Ok, kozben megneztem egy Williams rajzon. A J8 a bal oldali meghajto, a J10 a visszajovo. Te mindent csak figyelni akarsz? Az optokhoz mekkora ellenallasokat tettel?

Kérdés.
Az 1 ábrán nincsenek Tápfesz szűrés alkatrészek feltüntetve?
A valóságban azért azok a kondik ott vannak?
A Mega minden GND, VCC lába be van kötve?

Még lehet zárlatos is valahol az áramköröd?

1kohm ellenállásokat tettem, a prg olvassa strobe jelet és amikor strobe és a switch input egyezik tehát a mátrix meghatározott kapcsolója zárt akkor PD0-PD3 output indítja az MP3 trigger meghatározott hangját mp3 trigger.

tápfeszt nem szűrtem a regulált 5v-ot direktbe kötöttem az AVR-re. Az AVR müködik logikai ceruzával teszteltem a portokat.

Na, igen!

Tipikus hiba, hogy kihagyják a 100n kerámia kondikat a közvetlenül az IC GND – VCC lábainál.
Aztán nem értjük, mért nem működik a mestermű?
Mikor berakjuk valami elektro szmogos környezetbe.