Ez jó hír akkor ezek szerint elég pontos ahhoz, hogy az általam is elgondolt for ciklus+ wait utasítással meg lehessen oldani. (nagyon hozzászoktam már a windowshoz ahol minden idővel kapcsolatos dolog csak "talán annyit" ).

A T13 még olcsóbb is, mondjuk a lényeg nekem a tokozás, a 8 láb több, mint elég rá és így legalább kis helyen is elfér.

A hangmagasság-függő visszajelzés alatt mit értettél?

Ha a 22kHz-t megkozelited (az elejen ugyis a "behangolasnal" le kell menni hallhato taromanyba, vagy PC hangkartyaval es a WTUNE nevu programmal belovod), akkor jelezd, hogy az alsobb reszen vagy.
Macska, kutya es a gyermek ideges/zaklatott lesz hosszutavon....

Ja értem, valószínűleg PC hangkártyával lesz a hangolás letöltöttem jó kis program ez a WTUNE jó lesz zenélésre is.

Te, ha ez mukodik aruldd mar el hogyan kell a szunyogok tudtara adni, hogy a freki szamukra zavaro Mert en vettem egy ilyen keszuleket es meg egy bogar / legy / szunyog sem akart ettol a szobabol surgose tavozni vagy megmurdalodni, es ha tudnam mit kell csinalni hozza eskuszom lecserelnem az elektronikat benne - a fali csatlakozoja, meg a tapja es persze az ultrahangu hangszoro maradhat, a tobbi meg kuka

Legfeljebb kisse mas modulacio (22-30 kHz), és az jó galambokra. Nálam legalábbis bevált....

Ez bíztató.

Én egerekkel akarom kipróbálni, már fel is van állítva a csapda fogok párat és letesztelem mit csinálnak .


Mindenesetre bízom benne, hogy be fog válni.
Az eredeti plafon és az alatta 1-10cm-re lévő gipszkarton közé költözött be egy egér család és hát éjszaka a fiatalok disco-t rendeznek amihez a gipszkarton álmennyezet szolgáltatja a táncteret.

Atmega8 felprogramozása tökéletesen megy vissza olvasás is. De a fuse biteket nem tudom állítani. Mindig 0xC0 ráadásul ha jól tudom nem is factory default ez az érték. Ponyprog2000t használok.
Köszi!

Erase device után nézd meg.

Avr-gcc -nel hasznalhato ilyesmi?

Használható (legalábbis WinAVR alatt működik nekem...)

Korabban meg UHU 1.2 alatt 4.1.1 -verzioval probaltam es nem mukodott.
Most Ubuntu / avr-gcc-4.2.1 alatt mukodik. De jo :smoke:

Nincs meg valakinek esetleg a linkelt dokumentumhoz tartozó C-program ? Nem értem teljesen a leírásban vázolt dcf77 algoritmust

Kösz,megtaláltam...

Hogy lehet kiolvasni egy AVR kontrollert minden területét? (flash, config, eeprom, fuse) és lementeni egyben AVR Studio alatt? Úgy, ahogy a PIC-el egy hex fájlban van minden.

Készíts ELF fájlt. Arra való.

Sziasztok!

Sajnos még igen kezdő vagyok avr programozás terén ezért fordulok hozzátok.
Nekem egy olyan avr progira lenne szükségem ami a kimenetre kötött pieson 16kHz és 35kHz közötti véletlenszerű frekvenciájú hangot ad ki véletlenszerű időtartamig 1 perc és 3 perc között.
Elemről szeretném táplálni, szerintetek hány voltos elemmel bírná a legtovább, és kb meddig?

Előre is köszi a válaszokat.

Tamás

Erre már egyszer válaszoltam privátban is, mert ott írtál, amiért harapok. Ott leírtam hogy kell.

A random-ra kivancsi lennek en is.
Esetleg ha raersz ket sor erejeig :smoke:

Ez a 0-RAND_MAX között randomol pseudo-random számokat.
AVR-libc esetén a RAND_MAX így került a headerben definiálásra.

Használni kell a GCC stdio.h-ját, és esetlegesen a math.h-t.

Egyszer, volt egy applikációm, ahol nagyon kevés idő alatt, látszólag random számokat kellett előállítani, és az sem volt probléma, ha ismétlődik mindig indításnál.
Erre a legjobb és legegyszerűbb módszer egy pgmspace-re alapozott random. Lényegében ekkor semmit nem csináltam, mint szekvenciálisan olvastam ki a saját program memóriáját. Ez köztudottan elég jó "random" számokat ad 0-0xFF-ig.

Koszi !
Erre nem is gondoltam, azt hittem valami sajat trukkos, bonyolult megoldas lehetseges.
Szerk: Tenyleg jo otlet :smoke:

A privátban nem teljesen a kérdésre válaszoltál, és ott írtad, hogy itt ebben a topicban kérdezősködjek és olvasgassak. Én ezt megtettem.

Köszi

Tamás

Az ATTiny45-ösnél amint látom van Analóg bemenet amire mondjuk fényellenállást tudok kötni.
Jól értelmeztem, hogy két ilyen van rajta?

(Két fényellenállás különbségére van szükségem a programban azért lényeges).

Én 4 ADC bemenetet látok, a doksi is annyiról ír.

ADCre tudod kotni, ugy hogy csinalsz egy ellenallas fesz. osztot, also tagja lesz a fenyellenallasod, a masik erteket ugy valasztod meg hogy a max fesz. ne legyen nagyobb mint az ADCn megengedett normal bemeneti fesz. A fenyellenallas max ertekevel szamolod a max feszultseget.

van valakinek tapasztalata az usb-s doper programozóval linux alatt? mert tervezem hogy veszek egyet (nem akarok már szenvedni mindenféle házilag összedobott programozóval) és igazándiból linuxon lenne használva

Hello!
Igen van, igaz nem sok . Működik, én a Kontrollerlab és AVRDude párossal használtam, bár nem a Topi félét, de az is ugyan az.

Sziasztok,

AVRstudiot probalgatom, es abban is a szimulaciot tesztelgetem. Nekem nagyon lassunak tunik ez a szimulalgatas, MaSTeRFoXX cikkeben szereplo kis pelda program eseteben skerult a 2.2 mp varakozast 1.5 perc alatt leszimulalnia.

Mit csinalok rosszul? Vagy milyen szimulatorral lehet normalisan dolgozni? Linux alatti fejleszto rendszer beli otletek is johetnek, mivel a host operacios rendszer linux, a win csak virtualis bortonben van - meg 100 evig

szerk: most neztem a VMLAB-ot, abban mar ugy 10 mp alatt leszimulalja - meg mindig eszmeletlen lassu osszehasonlitva a PIC-es fejlesztoi kornyezettel, az MPLAB-al. Koszi elore is minden segitseget.

Szimulációban az időzítésekre én nem adnék egyáltalán. A szimuláció olyan mint a guminő.

Termeszetesen nem valos idoben szeretnem, ha leszimulalna a firmware-em Csupan, hogy egy-egy problemat kideritsek - pl neha nem is lehet maskepp leszimulalni egy jelenseget, csak ha van egy pontos digitalis rogzitese a bemenetnek aminel a hiba jelentkezik - ugye valos eletben egy 1us-os tusket (de meg par miliseceset is) sem lehet mar lepesenkenti vegrehajtassal lekovetni, hogy amiatt merre koszal el a firmware vagy mit szamol ki rosszul. A lggolasos technika pedig ugyszinten csodot mondhat, hiszen azokhoz meg plusz CPU ido es plusz memoria kellene. Nem beszelve a regresszios tesztekrol Tehat ha tudjuk mire kell tesztelni a firmware-t, akkor a teszteles automatizalhato szimulacioval, ami minden apro firmware modositas alkalmaval elvegezheto, tehat meg idejekoran kiderul ha valamit nagyon elfarag az ember

Írtam már egy két nagyon eldurvult firmware-t, ahol még a 128K-is éppen hogy elég lett. (Persze nem rosszul megírt kód miatt ekkora a firmware)
De ilyenkor, én mindig selftest-et írok. Már az első 10 sorában a programnak, már a kezdeteknél is van stimulus függvények.

Komolyabb firmwareket csak selftest és stimulus fgv-ekkel lehet rendesen tesztelni. Mert ugye még a JTAG-es debug vagy egyéb más is felejtős.