A blink programot írdd át, ahol a millis helyett Miliseconds() van.
Kész.

U.i.: Az arduinonak nincs FET kimenete.

A zárójelbe, mondj egy számot légyszives.

Valamelyik PWM kimenetre FETet tettem egy IRLZ44 et. Most már csak megkéne szaggatni 20-25 KHz között.

Pi.

A programban:

ujra:
be
vár x usec
ki
vár xmicrosec
ujra

Ha a frekvencia 20 kHz, akkor x mennyi?

Hali mindenki!

Van nekem egy ATtiny45-tel egy elemes táplálású (3V) készülékem, ami jelen pillanatban úgy kapcsolódik be, hogy megnyomok egy nyomógombot amitől egy tranzisztoros kapcsolás öntartásba kerül, és tápot ad az avr-nek. A kikapcsolást avr csinálja időzítve, kikapcsolja az öntartást.
Ezt szeretném "modernizálni", milyen lehetőségek vannak erre?? (sleep mód?)

Szia!

Sikerült az attiny2313-akat felprogramozni. Igaz csak az STK200-as párhuzamos portos égetővel (az usb-el még küzdők, de egyelőre félretettem). A megoldás az volt, hogy a reset és a VCC közé beraktam egy 10kohmos ellenállást, persze a tápfeszültségre ment a 100nF-os kondi is. Viszont két példány sikeresen tetszhalott lett . Kicsit gyorsabban járt a kezem mint kellett volna és felpogramozása helyett a konfig biteket írattam bele, miután már nem volt elérhető a chip.

Avr-ek terén nem vagyok igazán otthon, az adatlapból sem sikerül semmi értelmeset kisilabizálnia, vagy csak nem jól keresem. De akitől az avr-eket meg a beleírandó progit kaptam, azt mondja külső kvarcra állítja be a belső oszci helyett így a konfig bitek írása után ezért nem érem el. A két tetszhalott chipet van esély életre kelteni, hogy a megfelelő kristályt és a hozzá való kondenzátorokat a helyére bekötöm?
Bari

Először is, próbáld ki terheletlenül a kimeneteket mérni. Ha úgy sincs jelszint, akkor kisebb az esélye, hogy 10uH a gond.
Próbáld meg, egy működő prociból vagy függvénygenerátorból származó órajellel közvetlen megtáplálni az XTAL input-ot. Ezzel kizárhatod az órajel problémát.

Minden próbát, egyszerű üres IO vagy LED ki-be kapcsolással teszteld. Utána jelentkezz az eredményekkel, és ha még mindig kérdéses, akkor boncoljuk tovább

Sziasztok!

Nekem is van egy USBASP programozóm, azzal tudok debugolni? Vagy inkább nem is érdemes szenvedni vele? Egyenlőre még driverem sincs hozzá.

Hány programozót nyúztál már el?

Az USBASP biztosan nem jó debuggolásra, arra minimum egy JTAG ICE kell.

A kettő amit tőled vettem teszi szépen a dolgát, az egyik nálam, másik nagybáttyámnál. Az ASP-t nagybáttyám rendelte ebayről amit nem tudott használni, és ezért vett végülis ő is tőled. Szóval kíméletes vagyok velük

Akkor nem fogok debuggolni most az egyszer jól jött volna.

USBASP nagyjából semmire nem jó, csak vésztartaléknak. Inkább egy STK500.
Debugra meg:
- AVRDragon,
- JTAGICE,
- JTAGICE MKII.

Külső órajel (1...10 MHz) az XTAL1 vagy XTAL2 lábra.


Mi mit jelent -> AVR Fuse bit calculator (1. vagy 2. találat a google-ban)

Sziasztok!
Köszönöm az ötleteket, bocsánat, tegnap vendégek voltak, ma meg munka. Most este kivettem az induktivitást és egy natúr dróttal átkötöttem, és láss csodát, működik a C port (led+ellenállást dugtam az lcd-hez csatlakozó hüvelysorba az lcd helyett. Hát szóval ilyet még nem láttam... Jól működik 20 MHz-ről is. Szóval veszek a héten máshol és mindkét panelban kicserélem.

De mégegyszer mondom, ilyet még nem láttam :O

http://www.engbedded.com/fusecalc

Szia

Elnézést a késői válaszért. Köszönöm az infót. Amint lesz kis időm eljátszom majd a két tetszhalott példánnyal. Mióta decemberben megszületett Babóca csak ilyenkor éjjel jutok kicsit a géphez.

Bari

Ismerős a szitu. Én is vettem egy profi gépet, aminek eszméletlen sebessége van, 4 proci, a kedvenc játékaim max felbontás mellett is hasítanak.

A végeredmény az, hogy az idő 99%-ában Miki egeret és Hupikék törpikéket néznek a 4 processzoron, számomra meg megmaradt a magasabb villanyszámla kifizetése.

FUrcsa. Az AVCC-n van kondi a föld fele? Ha Ohm-merovel megmered a kiszedett induktivitast, mennyit mutat?

Túl nagy lehet az ellenállása az induktivitásodnak, és a PI szűrő proci felőli puffer kondenzátora túl alacsony kapacitású (azaz a kör nem bírta az impulzus áramokat)

Kedves Fórumtársak!

Most kivételesen én kérdeznék egy fogósat.
Sokadjára találkozom azzal a jelenséggel, hogy FT232-es alapú eszköz adott számítógépeken furcsán működnek.
Adott egy hardver, amin FT232RL típusú illesztő van. De nem csak az a hardver, bármelyik FT232 alapú eszközt csatlakoztathatok a számítógéphez, ugyan ez a jelenség.

Windows 7 - 64bit minden vizsgált számítógép. Amikor küldök egy bájtot számítógépről, akkor az FT232 kimenetén összesen egy start-bit jön ki, utána vissza megy magas logikai szintre.
Ha TTL soros jelet vezetek be az FT232-be ami amúgy óramű pontos, akkor is a PC-n 0 bájtok jönnek.
Ugyan ez a hardver egy másik Windows 7 - 64 biten tökéletesen működik. Közös ismertető jele, hogy az ilyen 0-át küldő és 0-át fogadó hardverek mindegyike működik XP-n.
AVR fogadja a jelet, és az is küldi ki. Hiba nincs az AVR oldalon természetesen, és az FT232 RXD-TXD lábait közvetlen összekötve sem megy az echo amikor ilyen hiba lép fel.

Az FT232 gyártási kódja 1029-B, azaz 2010. 29. hét Revision B.
Több ilyen áramköröm van, amin (mivel nagytételben vásárolt FT-kről van szó) ugyan ez a széria szám. De vannak olyanok amik működnek és vannak olyanok amik nem.

Megfigyelésem tehát:
- Legfrissebb driver sem megoldás. Ugyan azon gép, ugyan azon win konfig esetén előfordult hogy 2008-as driverrel működik, legfrissebbel nem.
- Az is előfordul, hogy csak a legfrissebbel működik, régivel nem.
- A mostani próba alany számítógépen semmilyen FT driverrel nem működik a kommunikáció, mindig 0-ák érkeznek.
- Arra gyanakszom, hogy mivel egyes gépeken driver downgrade-el a problémák megoldódtak, így driver gond lesz. Ezt az támasztja alá, hogy mindegy milyen hardverről van szó, linux alatt tökéletesen működik. Legyen szó Win-en rossz, vagy Win-en jó típusról.

FT bekötése: Belső RC-ről, USB táplálással, Megfelelő szűrésekkel (kristály tiszta tápok), Handshake lábak szabadon (csak TXD-RXD használva). Handshake-et én kizártam, ugyanis oda-vissza mennek az adatok csak mindig 0.

Találkozott már ilyennel valaki?

Szerk: Nem friss tapasztalat, évekkel ezelőtt is előfordult már. Csak volt hogy driver cserével elhárult a probléma. Azért jött most elő újra, mert most felbosszantott

Gratulálok. Te is beletenyereltél a hamisított FT232RL chipbe.


Egy nyomozás története, ahol egy Arduino nano volt az áldozat (ATMega328+FT232RL).
http://tavir.hu/cikk-hamis-a-baba


Röviden: Adott az FTDI FT232RL chip lábkiosztása és ára: 2...4$. Jött egy chipgyártó, aki alternatívát ad: chip ára 0.5...1$ körül, azonos a lábkiosztás, és "véletlen" a driver sem kell hogy eltérő legyen. Igaz eredetileg az USB chipazonosításra szolgáló VID/PID páros is különböző volt.
Aztán jött aki meglátta a lehetőséget: Az 1$-os chipen cseréljük le a feliratot a 4$-éra. És a VID/PID azonosítóval is hasalja be, hogy ő biza 4$-os.
Minden ment is szépen, amíg csak 32bites rendszerrel tesztelsz. Amint 64bites a rendszer, a fenti hiba következik be - majdnem függetlenül a driververziótól (ha jól emlékszem a ....24-ig ment a x64-esen is, amíg nem frissített a netről újabbra. Ott valamit az újabb átír, így a downgrade sem jó már utána.
Az FTDI a driverébe tette a védelmet. Ha a PL2313 chipet látja, a kimeneten csak egy logikai ugrás van....


Valamint az FT232RL esetén érzékeny az USB oldali tápzavarra. Sokan eltervezik:
- kimarad a sorosferritgyöngy/szűrő,
- hiányzik az USB D+/D- ágból a soros ellenállás.
A bizonytalanság driverfüggő is. Az USB3.0 portban az eszköz mintha érzékenyeebb lenne, mintha a 2.0-ba dugom be. Megoldás lehet hogy a chip átállításra kerül USB1.1 kompatibilisre.

A megoldás?
1, ha a PL2313 hamis szitás chiped van: chipcsere.
2, ha a tervezési hibád van, akkor USB1.1, vagy az USB kábel is cserélendő (vastagabb vezetékek, ferritgyűrű, rövidebb kábel.

+1 ok hogy a munkahelyi tesztáramköröket inkább soros portra tervezzem. Aztán ha elfogynak
a portok akkor valami márkás USB-RS232 kábelt teszek bele. Azt lehet cserélni, az IC-t nehezebb...

Ha hivatalos disztributori helyről szerzi be az ember a chipet - nem fut bele ilyenbe...

Miben jobb az FTDI egy tetszőleges USB-s mikrokontrollernél?

amiben jobb: nem kell a szoftverben vesződni az USB kezelése miatt, elég a soros portot figyelni.
amiben rosszabb: korlátozott a felhasználás(csak egyfajta BAUD rate lehet, nincs "natív USB)"
na meg persze több alkatrész a panelen...

USB CDC bármely kontrollerre létezik, a PC-s oldalon csak a soros portra kell figyelni. A kontrolleres oldalon a forrás is a fejlesztő kezében van. Gondolok itt arra, hogy hány darab egyforma (egyező VID és PID) illesztőt tud egyidőben kezelni a PC. A forrás birtokában az esetleges eltérések (USB3, stb) kezelése is kézben tartható.

A kontrolleres CDC forrásának birtokában a Baud rate állítás nem lehet gond. Az alkatrészek számával sem állunk rosszul (ugyan PIC, de a 16F1455 quartz és feszültség szabályzó nélkül, egy-két kondenzátorral képes a Full Speed USB-re), sőt soros EEProm sem kell hozzá, a VID, PID és sorozatszám tárolható a program memóriában. Mindez egy 5V -os DIP14 vagy SOIC14 tokban. (510 ill. 420 Forintért (bruttó) azaz 2.2$ ill. 1.88$)

Üdv!

Nagy zűrzavarba kerültem 2 AVR fuse bitei beállításai során.
Mindkét vezérlő egy azon típusú: ATtiny2313-20PU.

Próbának előtte megnéztem, hogy a programozóm látja e, minden rendben volt.

Szóval megnéztem ezen az oldalon, hogy mi is a kívánt hex kód. 8MHz+ 14CK+ 4,1ms ; SPIEN ennyi kell.

avrdude -c SAJAT -p t2313 -P COM1 -U lfuse:w:0xEF:m -U hfuse:w:0xDF:m

Sajnos ezután már a programozó nem látta.

Az elsőnél, még véletlenül beraktam a debugWiret is ami ha jól értettem felülírta a RESET láb funkcióját, vagy tévedek?

Másodiknál már jobban figyeltem, az avrdude is visszaigazolta, hogy milyen bitek lettek beállítva.
Sajnos a következő beolvasás ennél sem jött össze.

Nem tudom mi lehet a baj?
Mellékeltem az avrdude cmd paneljét.

SB

Köszönöm a felvilágosítást, de itt egyáltalán nem a CDC-ről van szó. A "tetszőleges USB-s
mikrokontroller" nekem azt jelenti hogy az USB rész hardveresen benne van az uC-ben.
Például egy AT90USB162 egy USB-s mikrokontroller, az ATMega8 már nem.

Az "USB CDC bármely kontrollerre létezik" - ezt úgy hívják hogy szoftveres USB emuláció.
Komoly hátránya hogy a mikrokontroller processzoridejének jelentős részét felemészti,
lassú átvitel, hosszú várakozási idő, korlátozott programozási lehetőség.
A CDC driver kompatíbilitása egyes rendszereknél komoly problémát jelent(pl. Win7).
Lásd: AVR-Doper (CDC) vagy USBASP(HID).

A hardveres USB-vel rendelkező mikrokontrollereknél(pl. AT90USB162, ATMega8U2) az USB-vel
foglalkozó programrész viszonylag nagy(3-4kB), és a programozásnál figyelni kell arra is
hogy az USB-t kezelő taszk bizonyos gyakorisággal meg legyen hívva(lásd: LUFA projekt).

Akár CDC, akár hardveresen emulált az USB, komoly előnyt jelent az "egycsipes" kivitel,
de ma még a legtöbb fejlesztésnél nem ez az egyetlen szempont. Például a gyári AVRISP-mkII
belsejében különálló USB emulátor IC (és egy ATMega128) figyel, a klónokban már
jellemzően egyazon IC látja el a vezérlés és a (hardveres) USB emulációt.

Nem úgy néz ki hogy megölted volna, nekem erre azt adja az AVR Studio hogy "csak"
külső nagyfrekis(>8MHz) kristályra állítottad át, az SPIEN és DWEN a helyén maradt.
Ha nincs bekötve a kristály akkor nem látja a programozó...

Van kristály is(8Mhz), 22pF os kondikkal a földre kötve.
VCC és GND között is van egy 10uFos és egy 100nF kondi.

Elnézést, én hibáztam.

A 22pFos kondik közé keveredett pár 220nFos, amiket 22pFosnak véltem és az XTAL1/2-re kötöttem.

Most már működik, legalábbis az egyik.