Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
A D9 FF (h/l) az Arduino nano beállítása, az Arduino UNO-é DE FF (h/l).
Bővebben: Link A különbség annyi, hogy a Bootloader Nano alatt 2k (7800-8000), UNO alatt 0.5k (7E00-8000). Nem tudom, hogy a TOPI féle égetőben van-e bootloader. Ha nincs, az sem baj, mert a 0xFF 0xFF utasításokat az AVR valahogy átugorja és eléri a 0x0000 címet. Ez tapasztalat. Baj csak akkor lehet, ha a HI/LO-t összekevered. Több TAB is van, valahol hex-ként is meg tudod adni (Fuse Hex Editor?). Itt írd be, hogy D9 FF (h/l). Arra ügyelj, hogy az SPIEN be legyen kapcsolva, a DWEN és a RSTDISBL pedig ki. A hozzászólás módosítva: Máj 14, 2015
SIKERÜLT!, köszönöm a segítséget!
Elsőre a 328p-be égettem, azzal is ment asszem, de megpróbáltam az összes régi 8-asokba, 88-asokba, amit össze tudtam szedni innen-onnan a régebbi projektekből. Volt közötte halott chip, amik még csak olvashatóak sem voltak és volt amelyiknek valamelyik portja régebbi zárlat miatt kiégtek, de sikerült csinálnom magamnak újra programozót! Köszönöm még egyszer!
Sziasztok kérlek segítsetek nekem, hogy az atmega 1284p re, hogy tudok feltenni egy programot? Kérlek titeket, hogy pontról pontra mondjátok el nekem . Mert lenne egy kapcsolási rajzom és ez az egy akadály van . Még soha nem csináltam ilyet
Milyen programozód van? A program HEX-ben van?
Sikerült Wifi-n keresztül Arduino-t programozni ESP8266-tal.
- az ESP8266-ot az eredeti firmware-rel felcsatlakoztattam az otthoni hálózatra - ezután feltöltöttem rá az ESP8266 transparent bridge firmware-t - a GPIO2 PIN-t összekötöttem az Arduino RESET-tel (AT+++ GPIO2 2 parancs resetel) A parancs, emit futtattam:
Ment, apróbb problémákkal, mert az ESP8266 meglehetősen agresszívan veszi fel az áramot és folyamatosan kiakadt kommunikáció közben. Az interneten nem írják, de a 3.3V-os feszültség-stabilizátor után még 1000 µF kapacitás kellett a táp szűréséhez. Idézet: Elé kéne az, nem? És ha úgy nem jó, akkor nagyobb áramú stabilizátor. Ekkora kapacitást nem szabadna tenni stabilizátor kimenetére. „Az interneten nem írják, de a 3.3V-os feszültség-stabilizátor után még 1000 µF kapacitás kellett a táp szűréséhez.”
semmilyen soha nem csináltam még ilyet. Kaptam egy kapcsolási rajzot a neve biprog de azt sem tudom hogy mire jó segítsen már nekem valaki , hogy megértsem.
Mutasd milyen kapcsolásba kell a 128p és milyen program van hozzá. A felprogramozáshoz kell egy PC-n futó programíró software, kell egy programozó hardware és ha a készülő kapcsoláson nincs ISP csatlakozó akkor még egy égető panel, de ez gyakorlatilag egy ic foglalat plusz egy tíz tűs csatlakozó.
Ha azt mondod, hogy előtte jobb lenne, még átrakhatom.
Most nézem, hogy stabil-e.
Úgy néz ki nekem nagyon bejön ez a cucc. Átírtam az Arduinoban néhány fájlt és most ESP8266-on keresztül a WIFI-n keresztül programozza fel a cuccot, autoresettel.
Az egyetlen kérdés a soros monitor volt, mert ugye az nem fog működni. Szimplán egy telnet ablakkal rácsatlakozom a portra és látom, hogy mit üzen az Arduino soros monitor nélkül is. A levegőben programozás azért volt fontos, mert ugye ha van külső feszültség, az USB-re nem szívesen dugdosok bármit is.
Üdv!
Mi a különbség az "alacsony" és a "magas" THT kvarc oszcillátorok között?
Az alacsonyak állítólag pontosabbak, kevésbé hő érzékenyek.
A feltüntetett ppm értékek nem a pontosságot jelzik?
Ez az érték a magasaknál jobb, mint az alacsonyaknál.
A magasabb kvarcok nehezebben rezegnek be. Ennek megfelelően kell a fuse bizteket beállítani hozzá. Asszem Tavir oldalán volt valahol egy cikk is róla.
De ha már a kvarcoknál tartunk, én is kérdeznék egyet. Újabban láttam pár helyen, hogy az xtal lábak közé bekerült egy 1-10Mohm ellenállás is kvarc meg kondik mellé. Ennek mi lenne a szerepe?
A helyzet az, hogy az anyámtól örökölt 1000 µF-os bumszli 30 éves elektrolit kondenzátorral az ESP8266 stabilan ment (elé kötve, 5V-ra). Viszont az új elektrolitekkel egyáltalán nem ment, még a 4700 µF-osnál is szétszállt a kommunikáció (breadboardon ha gyors szűrés kell, ezt használom).
Elolvastam az LD1117V33 adatlapját és azt írta, hogy elé 100 nF kell, mögé 10 uF. Ebben a felállásban legalább olyan stabilan ment, mint anyám 30 éves elkójával. 100 db avrdude firmware kiolvasást túlélt, összehasonlítással együtt. 
A Breadboard kábeleinek a csatlakozása, és maga a vezeték is szörnyűen viselkedik 100mA felett. Egyszer lemértem a legrövidebb kábel ellenállását, 0.1ohm körüli volt. A leghosszabb pedig ebből következően akár 0.4ohm is lehet. A csatlakozások ellenállását nem mértem le, de legyen elég annyi, hogy mozgatni kell nálam néha a kábelt, hogy érintkezzen... Jó a breadboard, de 100mA felett én nem használom!
A regulátorod egy LDO. Ezek sokkal érzékenyebbek a helyes kondikiválasztásra mint a hagyományosak (számít a kapacitás és az ESR is). Elektrolitból kb. a 3-5 szöröse kell a megadott értéknek (az inkább tantálra és kerámiára vonatkozik csak, kerámia is legalább X5R legyen).
Szűréshez inkább szerezz be pár teljesítmény induktort (tekercset, a teljesítmény verzióknak sokkal kisebb az ellenállása). Az LC szűrés sokkal hatékonyabb. A hozzászólás módosítva: Máj 18, 2015
Nem breadboard, próbapanelen van összeforrasztva.
Mindenesetre lehet, hogy panelhiba. Bedugom, el sem indul. Utána 3-4-szer összeomlik az UART, utána minden 20. esetben omlik össze, utána 100-ig elmegy gond nélkül. Szerintem a panel hőérzékeny.
Nézd át a forrasztásaid, lehet, hogy az egyik megtört (ahogy melegszik az alkatrész egyszercsak érintkezik).
Ez annyira sajnos nem egyszerű.
Az áramkört pontozott próbanyákon csináltam. A technológia úgy történt, hogy először minden lyukba ónt csöppentettem, utána meg összekötöttem a szomszédos lyukakat pákával. Vezeték nincs benne, kizárólag az ón vezeti az áramot mindenütt. A lyukak meglehetősen közel is vannak egymáshoz. Természetesen nagy esély van arra, hogy a próbanyák félresikerült, de minthogy breadboard-os korában hasonlóan viselkedett, gyanítható, hogy nem a próbanyák a vétkes. Ha az ESP8266-ban van a forrasztási hiba, akkor esélyem sincs javítani. Mikro vackok. - először kimérem logikai jelanalizátorral, mert a szoftver hiba sem kizárható, nem a standard firmware fut rajta - emellett rendeltem egy másik panelt is, más eladótól Meglátjuk, hogy mi sül ki belőle.
Ezért nem szabad ilyesmiből sosem csak egyet venni. Nekem van otthon 10 db ilyen panelem (azért nem mind ugyanolyan
).
Üdv!
Egy MCP 2200 UART-USB átalakító csak 12MHz-s oszcillátorral működik, vagy más frekvenciájúval is?
A specifikáció ennyit ír, tehát ha garantáltan működőképes változatot akarsz, ezt használd.
Nos a kapacitás nem osztott, nem szorzott a dologban. Kimértem, hogy mi történik amikor az avrdude szétszáll és az egésznek leginkább a WIFI hálózat terheltségéhez lehet köze. A két képet csatoltam (jó/rossz).
Könnyű volt a hibát reprodukálni: scp-vel másoltam egy 1.5 gigás fájlt WIFI-n keresztül. A két átvitel UART szempontjából ekvivalens, az avrdude mégis az egyiket átengedi, a másikon fennakad és bontja a kapcsolatot. A rossz kommunikációnál az avrdude mintha meg sem várná az előző választ és előre kérdezne. A tanulság fájdalmas: az UART nem TCP/IP hálózat, ahol csomagok elveszhetnek, újraküldődhetnek és tetszőleges időben megérkezhetnek. A rossznál gyönyörűen látni, hogy az időben teljesen máskor elküldött csomagok egymás után egyszerre beesnek és zűrzavart okoznak.
Te sem tudsz aludni?
Menyi órád ment el ezzel a hibakereséssel?  Idézet: A TCP-nek pont az a lenyege, hogy nem veszhetnek el adatok, nem is jonnek ujra, nem keverednek ossze. A TCP socket-en te mar stream-et kapsz, es a TCP layer garantalja, hogy amit az egyik oldalon elkuldtek, az a masikon megerkezik. Az UDP meg az IP az veszithet, duplazhat, felcserelhet, a TCP nem. Amugy meg a UART-on is elveszhetnek adatok, vagy legalabbis megserulhetnek. Es meg is serulnek. Viszont a WiFi az garantaltan vesziti a csomagokat. „A tanulság fájdalmas: az UART nem TCP/IP hálózat, ahol csomagok elveszhetnek, újraküldődhetnek és tetszőleges időben megérkezhetnek.”
Könnyedén fogalmaztam, igazad van.
Azt akartam leírni, hogy az UART-tal ellentétben nem azonnal jelenik meg a csomag, ami több problémához is vezethet. Például UART-on ha 50 ms-enként elküldesz egy bájtot és lassú a kiszolgáló, azért még fel fogja tudni dolgozni. Wifi-n keresztül előfordulhat, hogy a rengeteg 50ms-enként elküldött csomag egyszerre, egymás után érkezik meg és a lassú kiszolgáló nem lesz képes ilyen sebességben feldolgozni az adatokat.
Ami még érdekesség, hogy míg az ESP8266 57674 baud körül ment, az Arduino nano 58930 bauddal osztotta az adatokat. Ez nano-nál durván 2.1%-os eltérést jelent, ami semmiképpen sem nevezhető jónak. Kezdetben ezt gondoltam hibának, így az ESP-t felnyomtam 58900-ra.
A nano bootloadere nem használja a dupla sebességű UART-ot, ezért 57600-as bitrátánál 2.1%-os hibával dolgozik. Bővebben: Link. Dupla sebességnél 0.8%-ra lehetne nyomni, de valamiért nem teszi. |
Bejelentkezés
Hirdetés |
