Tiltás a COM12-re biztos kell.

Az én AVRISP-m sem megy Win7 x64 alól. Nincs hozzá driver. VMware virtuális gépre telepített Win7 32 bites rendszer felismeri, driver telepítve, de az atmel studió mégis hibát ír rá. Majd megpróbálom az XP-t is virtuálisan.

Sziasztok egy kérdésem lenne de most égetővel kapcsolatban:
Bővebben: Link

Kinek mi a véleménye erről? USBASP ISP programozom volt csak tönkrement :/ sajna.

Szia!

Igaz kicsit drágább, de szerintem vedd meg EZT. Én évek óta használom, semmi gond vele, és találsz egy csomó segítséget hozzá...

Erről lebeszélnélek, ez a típus egy gyalázat! Ha az USBASP trabant, akkor ez egy Patentwagen.
Érveim: kell még 3 programot telepíteni/futtatni és kézzel portokat állítani hogy használni tudd.
Már ha egyáltalán lehet használni, nekem azóta sem sikerült az első ilyet felélesztenem...

Egy valamire való STK500-at ajánlanék, lehetőleg hardveres USB emulátorral(tehát nem Doper).

Sziasztok!

Távol áll tőlem a ilyesmi, de most nagyon szeretném tudni a választ a kérdésemre.
Valaki tudna ebben segíteni: Bővebben: Link

én USBASP használtam és semmibaj nem volt vele tény hogy külsö program kellet hogy menjen (de ha command line al megcsináltad) akkor a program is tudta égetni a dolgot igaz hogy nem STK stb. De használható bár debug télleg jol jönne néha főleg a fényérzékelés beállításánál.

Az x értékét nullázod? Pontosan minek is kell történnie hogy az x-et megnövelje?
Sikertelen konverziónak? Valami nagyon el van szúrva, ha 11000 konverzió után sikerül egyszer!
A sebesség függ a proci sebességétől(számítási kapacitás), de tudtommal az 1-Wire esetén
az időzítés majdnem fix, tehát a konverzió és a lekérdezés 1 és 8MHz mellett is ugyanaddig tart.
A számolós részeknél lehet időeltérés, pl. CRC számítás meg szorzás-osztás.
A dolgon timerrel segíthetsz ami persze szintén függ a CPU órajeltől, ezért ésszel bánj vele!

Elhiszem hogy működik az USBASP, és biztos vagyok benne hogy nem azért romlott el mert
ócska lenne a programozó. Ettől függetlenül egy normális STK500 klónnal jobban járnál.
Pár oldallal vissza(AVR égetők topikban) közzétettem NYÁK tervet és HEX fájlokat, használd
egészséggel! Cikkezni nincs időm, aki eddig megépítette annak működött.

A ther_read_bit() így fest:


A x értékét mindig nullázom a while előtt.
Nem használom a 1-Wire módot. Egy szezort használok.

Ezek nagyon is fix időzítések, de az (is) kell hogy az F_CPU értékét beállítod a procinak megfelelően.
Azért még mindig fúrja az oldalam hogy több ezer sikertelen lekérdezés után lesz csak jó.
Egy szenzornál is 1-Wire-t használsz, csak "SKIP ADRESS" módban. Legjobb tudomásom szerint.

F_CPU beállítva. Jó tudod SKIP ADRESS kell.

Nem tudom miért, de eddig számol el. max 750ms alatt kell, hogy válaszoljon. Tehát azért eltarthat egy darabig míg megjön a válasz. De nem tudom összegyeztetni a 750ms-t és az x értékét.

11000/750 = ?

kb. 14,6. De ez most mit jelent? Nem értlek.

Attól tartok hogy azt sem érted amit kérdezel. Vagy nagyon rosszul teszed fel a kérdést. Gyártasz itt különféle változókat, de megkérdezed hogy miért annyi. Ember legyen a talpán aki korrektül válaszol neked! Előbb gondold át mit akarsz, mi nem tudjuk azt kitalálni!

Kezdő vagyok van igazság abban amit írsz. Elnézést.
A kérdésem lényege:
Adott egy AVR 16MHz órajellel.
Adott egy while ciklus benne egy változó aminek az értékét folyamatosan növelem.
Ha ennek a változónak az értéke pl. 11000 akkor ez hány ms-nek felel meg?
Ez a kérdésem lényege. Ne vegyünk most bele semmi egyéb feladatot. Csak pörög a while.

Hogy pontos légy, ahhoz ezt le kell mérned. Komolyan!
A while(1) rész minimum 6 órajel, de ha nagyon jó az optimalizálás akkor csak 2.
Az "x", ha 16 bites annak megnövelése 1-el legalább 6 órajel jó optimalizálással.
Ha rossz akkor 10-12. Tehát kb. 16 órajel egy ciklus, de ebből még nem lépsz ki, örökké megy.
Ha 11000-szer fut le, az annyit tesz hogy 11000*16/(16000000 Hz) = 11ms.
Namost, te még ellenőrzöd is hogy elérte-e a 11-et. Ezzel együtt kb. 20 órajel, tehát 13.75ms.
És igen, ezek a részek nagyon is függenek a processzor sebességétől!

Csak sejtem mit akarsz ezzel. Azt, hogy a 750ms alatt valami hasznosat csináljon az AVR. De ehhez nem szokás számlálókat növelni, hanem timert kell használni. Tudom hogy a timer az AVR legösszetettebb része, de ha nem használod, egy apró módosítás is tönkrevágja az időzítésed!

Köszönöm! Így már kezdem kapizsgálni.
Igaz most jött 100+ másik kérdés, de elgondolkodom. Nehezen megy a fejembe ez az egy szálon futó megoldás és az idővel való versenyfutás, ha pontos és precíz szeretnék lenni.

Akkor még nem programoztál DOS alól. A Pentium II idején volt egy ilyen: "Runtime Error 200",
"Division by zero". Pedig szó se volt semmilyen nullával osztással! A dolog háttere kissé bonyolult,
annyit elárulok hogy ez is szoftveres időzítéshez kapcsolódik.
Azért nem OFF, mert hasonló hibát készülsz elkövetni, pedig már lassan 20 éve abszolválták...

PC oldalon jelenleg PureBasic-ben írok Win alá programokat, rengeteg eszköz nagyon egyszerűen
érhető el vele, az egyszerű sztringkezeléstől a grafikai programozásig mindent lehet vele.
Bár lehetne vele több szálon is programozni, a 2000 soros tesztgép-kezelő progim is egyszálú.

Idézet:
„Akkor még nem programoztál DOS alól”

1998-2004 között fejlesztettem szoftvereket Clipper-ben. Nem kicsiket. Egy országos cég használta 3 megyében és a mai napig használják egy részét mert nem tudtak jobb alternatívát. Sosem volt túlcsordulási és időzítési gond. Igaz védekeztem is ez ellen.
Most amit nem tudok felfogni:
Legyen 3db érzékelőm amik 750ms alatt válaszolnak.
Legyen egy LCD kijelzőm.
Legyen egy Timer IC-m amit 'néha' kérdezgetnem kell
Ezek alapján legyen legalább 3 folyamat amit vezérelnem kell.
És mindezt pontosan tehát lehetőleg 1s pontossággal. 3x750ms+LCD+Timer IC ez már több mint egy 1s. És akkor még nem kapcsoltam egy relét sem és nem használtam UART-ot.
Ezt próbálom most a fejembe gyűrni. Ezért próbálom megérteni, hogy órajel "F_CPU" függvényében hogyan változnak a folyamatok időzítései.

A timer az nem egy IC (bár lehetne az is), hanem benne van az AVR-ben. Csak használni kell...
A másik kérdésre is egyszerű a válasz. Mennyi idő alatt kérdezel le? Pár ms? Eközben nem
"ketyeghet" a másik kettő szenzoron a 750ms? Tehát 3 szenzor esetén is csak 750ms lesz,
ehhez elég ha megtanulsz nemlineárisan gondolkozni. A program így is lehet egyszálú.

3 szenzor esetén akkor ugye 250ms-enként indítod el őket, majd lekérdezés után újra elindítod.
A 250ms-t pedig timerrel fogod kivárni. Ha az 1-es timert használod, akkor 16MHz-es procival
az előosztót 256-ra állítod(TCCR1B regiszterrel), a komparátor regisztert(OCR1A) pedig 15624-re.
Ezért: (16000000/256/4)-1 = 15624. Ez egy 4Hz-es(250ms-es) időzítő lesz.
Az időzítőt CTC módba állítva(TCCR1A,TCCR1B) csak az OCF1A flaget (TIFR regiszterben)
kell figyelned. Ha rám hallgatsz, csak akkor indítasz(TCCR1B) amikor a szenzoron is indul a 750ms,
és indítás előtt a TCNT1 regisztert lenullázod, illetve törlöd az OCF1A flaget is.
Bocs, de nálam csak ennyi a timer gyorstalpaló...

A Timer Ic alatt nem az AVR TIMER-t értettem. Megint rosszul fogalmaztam. Hanem egy RTC IC-t Pl DS1307. Amit ugye már a TIMER-el kérdezel le.
Kicsit még elgondolkodom és próbálok felhagyni ezzel a 'lineáris' gondolkodással.
De akkor is zavar a dolog. A TIMER is, ha sokszor 'megszólal' megakasztja a programfutást.

DS18xx eseten trukk:
1. kiolvasod a hofokokat,
2. utan inditod a merest!

Hatrany: elozo hofokadatod van meg.
Elony: azonnal ott az eredmeny!

Egyeb tipp:
750 ms: parazita mod, 12 bit eseten.
200ms: 5V tapot is kap, 12bit
93ms: 9bites felbontas, 5V taplalas

Sziasztok!

Eddig Programmer's Notepad-ot használtam kódolásra, de nagyon hiányzott a debug funkció.
Feltelepítettem az Atmel Studio 6.1-t.
Szimulátort használva mindjárt falba ütköztem. A Teszt programba tettem egy _delay_ms(1000); várakozást. Na most a szimulációt teljesen megakasztja. Hosszú percekig csak vár.

De az LCD programban is van pl. egy ilyen pl.:

Ennél is "örökké futó" lesz a szimulátor.

Hogyan kell helyesen beállítani, hogy az ilyenek ne akasszák meg?

Én poénból készítettem egy ütemezőt AVR alá, ami akár 4 szálat is elkezel, de bevallom őszintén, még sehol sem volt rá szükségem.

Én kíváncsi lennék rá. Megosztod velem a kódot?

Inkább ne stresszeld magad vele, félő hogy a kód láttán több kérdésed lesz, mint amennyit
az megválaszolt. Én is készítettem egy ütemezőt, a Knight Rider villogómhoz kellett, hogy a
számolós és a kijelzős rész ne zavarják egymást. És igen: nincs ütemező timer+interrupt nélkül.

Sziasztok!
Még régebben foglalkoztam egy AVRes mérőműszer fejlesztésével a labortápomhoz. Azóta nem találtam időt erre a projektre, viszont most akad egy kevés.
Tehát megalkottam egy kapcsolási rajzot, amit majd igyekszek nyákra vetni. Egyenlőre csak itt:
Bővebben: Link
Megfelelő ez a kapcsolás? Esetleg lemaradt valami, ami elkerülte volna a figyelmem?
Köszönöm a válaszaitokat.

Csatoltam a kódot, remélem boldogulsz vele, mert Linuxos makefile-ok vannak benne, gcc-vel meg avr-gcc-vel megy.

A kód három részből áll:
- microthreads implementáció
- PC megvalósítás (azon teszteltem, mindenféle kriksz-krakszot ír ki), ez HUP signalok küldözgetésével szimulálja az interruptot. Kezdőnek komplex és érthetetlen kód, legjobb, ha hagyod a fenébe
- Arduino megvalósítás (Atmega328P), generál egy hex fájlt, remélem fel tudod használni. A két szál ugyanazt a PIN13-as LED-et villogtatja, az egyik gyorsan és ritkán villog, a másik lassan és mindig. Ha a kódot kipróbálod, a _delay_ms(1000) pontosan két másodpercig vár a két szál miatt. Vicces.

Hogyan kezeld:
microthreads_init() - ezzel indulsz
uint8_t id = microthreads_startThread( &my_func ) - ezzel indítasz szálat
microthreads_scheduleNext() - ha semmi dolgod, átadod vele a vezérlést
uint8_t id = microthreads_getCurrentThread() - megmondja, hogy te melyik szál vagy
microthreads_killThread(id) - kinyírod a szálat (a főszálat nem tudod)

Emellett: definiálsz valami timer interruptot, ami a microthreads_scheduleNext() -et hívogatja. A sei()-t és a TIFR0 törlését ne hagyd ki. Érdekessége a kódnak, hogy már az interruptban engedélyezi az interruptot és nem várja meg a RETI-t.

Ha kicsi lenne a stack (64 byte), a STACK_SIZE állításával növelheted, a threadek számát pedig a MAX_THREADS állításával csökkentheted / növelheted.

Az implementáció setjmp / longjmp függvényeken alapszik.

Sziasztok!
Megépítettem ezt a fordulatszámmérőt: Bővebben: Link
Működik, de két problémám van vele. Az első, hogy az oldalon található és a letölthető állományban szereplő "RPMMeter.c" és a csatolt fájlokat hiába próbálom lefordítani az AVR Studió-ban, egy csomó hibát dob ki, és nem jön létre a hex fájl. Lehet én bénázok, de gyanús a történet. Ha sikerülne lefordítani, akkor jönne a második probléma. Jó lenne a felbontást növelni, ugyanis az RPS értéke 1 alá nem megy. (RPS=1 RPM=60) Na de ha én pl. RPM=30 fordulatot akarok mérni, ahhoz módosítani kéne a szoftvert. Megoldható ez viszonylag egyszerűen, vagy törődjek bele, hogy ez ilyen?
Hozzá kell tennem, hogy eléggé magas nekem a programírás, így 50 fölött már nem igazán ragad rám más, csak a kosz. Tehát nagyon szájbarágósan kéne elmagyarázni...