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
Valahogy a kimenő adatot is ketté osztani, és úgy meghajtani. Csak nem tudom hogy oldható meg.
Miből gondolod, hogy 2db 10 bites ADC-vel 16bites ADC-t tudsz csinálni? Ha normális minőséget szeretnél, léteznek direkt arra készült I2S buszos audio A/D és D/A átalakítók. Persze ehhez nem árt ha a mikrovezérlőn is van I2S lehetőség. Ilyet csak 16 vagy 32 bites vezérlőkben találsz, a 8bitesek teljesítménye nem is lenne elegendő ehhez (gondolom azért nincs egyikben sem).
Akkor marad a direkt digitális végfokokhoz tervezett IRS2092, köszönöm szépen a válaszokat.
Na épp ez a bajom, mert a 16 lábú CH340G pont nincs benne...
Ezt is csak egy kínai lapon. Inkább feltöltöm mert az URL-ben is kínai betűk vannak. Nem hiszem el hogy egy ilyen gyatra támogatottsággal rendelkező cuccost képesek az Arduino-ba beépíteni! A hozzászólás módosítva: Feb 14, 2015
A 16 bites ADC-ről. Vásároltam egy chipet, ami 13 bites ADC-re képes (MCP3302).
A chip működött is rendesen, hozta az ADC-t 9 bit pontossággal. Az AVR ADC-je kevésbé volt zavarérzékeny, ott azért 9.5 bitig el lehetett jutni breadboard-on. Ezzel kb. azt akartam mondani, hogy a 16 bites ADC-hez kell már egy kicsit edzeni zavarszűrés terén.
Meg egy atomstabil táp sem árt az A/D konverterhez. Zavarszűrő tekercs, stabilizátor, műverősítő, utóbbi körébe "lassító" kondi, a végén zavarszűrő kondi a táplábakon. Nem nagy cucc, de egy kis ingadozás tényleg hazavágja a 16 bitet.
A hozzászólás módosítva: Feb 14, 2015
Söt a 16 bites ADC-hez már az alkatrészeket is válogatni kell a minimális alapzajra. Utovégre 90 dB-s dinamika körül kell dolgozni.
Ingyen letölthető: A C++ Programozási nyelv.pdf
Bővebben: Link
Az USB RS232 átalakítókról kérdeznék. A problémám, hogy ezek az eszközök tesznek a szabványra és a [-15V - -3V, +3V - +15V ] helyett [0V, 5V]-ot adnak ki. A 0V pedig tiltott érték RS232 alatt. Bemértem multiméterrel és nincs negatív feszültség rajtuk.
A kérdés, hogy mondjuk ezek az eszközök képesek-e a MAX232-t fogadni, ami -9V +9V-ot tesz a buszra, vagy az ellenállás-zener kombót is kispórolták belőlük? (HL-340 átalakító, CH340G chip)
Sírjak vagy nevessek? Kedves URAM, Ön hol volt az utóbbi 2-3 évben? Tudja mit jelent a TTL?
Akkor az AVR-nek is +/- 15V-ot kéne kiadnia/fogadnia a TxD/RxD lábakon? Azért ez vicces lenne. Létezik olyan is hogy "USB to Serial" ami nem tévesztendő össze az RS-232 szabvánnyal! Az RS-232 (többek között) +/- 3 és 15V közötti feszültségszinteket definiál, ahol a -3V-nál kisebb feszültség a "logikai 1" illetve az "idle" állapotot jelentheti. A TTL esetében az 5V jelenti ugyanezt! A MAX232 pedig pont arra való, hogy az RS-232 és a TTL között átjárást biztosítson. Az "USB to Serial" IC-k szinte mindig TTL feszültségszinttel kommunikálnak(köztük az FT232 is!) ahogy az AVR is. A TTL azért van mert bármilyen irányban olcsó a kivitelezése, a kapcsolódó áramkörök, kapcsolók egyszerűek lehetnek, és nem igényel "szélsőséges" tápfeszültségeket. Az RS-232 a nagy feszültségszintjeivel azért létezik, mert eredetileg modemekhez tervezték hosszú kábelekkel ahol a 0-5V már elfogadhatatlan mértékű adatvesztést produkálna. Nem utolsósorban az analóg telefonvonalak feszültségszintje (a csengetést leszámítva) +/- 24V körüli. A hozzászólás módosítva: Feb 17, 2015
Fizikus írt erről egy cikket 5 éve. Ebben szépen le vannak írva a miértek és a hogyanok is:Bővebben: Link
A hozzászólás módosítva: Feb 17, 2015
átalakító itt
Úgy tudtam, hogy a DSUB9 nem TTL-lel megy, ennek ellenére 5V és 0V-ot ad ki a lábakon. A hozzászólás módosítva: Feb 17, 2015
Az hogy ki mit köt DSUB-9 csatira az magánügy, pl. az EGA monitorok is ilyet használtak TTL jelekkel.
De ha valamit "RS-232 compliant" - ként hirdetnek miközben TTL jeleket használ, az nem csak termékhamisítás, hanem az eszközök tönkremenetelét is okozhatja! Főleg az átalakítóét. Hol láttad hogy 5V? Esetleg vásároltál és kimérted? Az 5-ös és a 3-as tüske között kell mérni. Ezekben az átalakítókban még szokott lenni egy konverter IC, hasonló mint a MAX232 csak több csatornája van. És elnézést kérek a személyeskedőnek tűnő bekezdésért, nem volt szándékomban megsérteni. Csak olyan mértékben keveredtek a fogalmak mint Egely György irományaiban a Maxwell-egyenletek. A hozzászólás módosítva: Feb 17, 2015
Nono. Az RS-232 az a Recommended for Standard. Azaz közelítek a szabványhoz és nem mindenütt tartom be (de nem mondom meg, hogy hol nem).
Ha szabványos portot akarok, az az EIA-232! Ezen a feszszintek adáskor +/- oldalon 5...15V, vételkor 3...15V-ot ismer. Sebességek is a szabványban megadottak (1200, 300, 9600 stb). Meg az időzítések, felfutások, stb. Az RS-232ben eltérek. valamiben. Pl. ha PC compatible, akkor a szintek:-.15....+0.7V és +1.8V...+15V. Ezért egy régebbi PC-n sima TTL jelekkel (ha az invertálás megvolt) simán kommunikálom. Egy EIA-232-es eszköz esetén a tiltott tartományban vagyok, és minden lesz csak nem kommunikáció! Csakugye a szakmai szleng e két dolgot összemossa. Miközben nem kéne...
Csak egy mai cuccnak nem kéne (még invertálással sem) TTL jeleket kiadnia, ebben remélhetőleg egyetértünk.
TTL jelet adnak ki, kimértem, 0V és 5V van a vonalakon. Egy CH340G IC van benne és kész, nincs mellé MAX232, ami a vonali szintillesztést végezné.
Jóformán csak a PCI kártyákon van szintillesztés, mert a buszon ott eleve kinn van a +-12V szemben az USB-vel. Működni persze működik. Lehet, hogy nem kellene vele problémáznom, mert amíg megy, addig ne érdekeljenek a részletek. A hozzászólás módosítva: Feb 18, 2015
Idézet: „Jóformán csak a PCI kártyákon van szintillesztés” Ne ijesztegess!  Eddig minden USB illesztővel amivel dolgom volt abban volt valamilyen szintű illesztés, ha nem is +/-12V, de minimum +/-5V biztosan. És nem 0-5V, mert a -3V - +3V egy tiltott sáv. Most gyorsan elő is vettem a Quectel-es csomaghoz kapott noném kínai kábeleket, +/-6.5V megvolt rajtuk. A Te CH340G-s cuccod egyszerű hamisítvány, de mintha korábban Prolific-eset linkeltél volna be... Egyébként ezekben az USB-RS232 kábelekben (legtöbbször) olyan IC-ket alkalmaznak manapság amelyekben a szintillesztő is benne van, az egycsipes megoldás mégiscsak olcsóbb mint beépíteni egy összcsatornás MAX213 IC-t. Akárhogy is nézzük, a tiéd teljesen megerőszakolja a szabványt. A hozzászólás módosítva: Feb 18, 2015
Nézegettem a WS2812-es LED szalagokat, mert programoznék szórakozásból párat.
A speckó azt írja, hogy egy chip 0.3W-ot fogyaszt. Ha 5m-es szalagot veszek, akkor azon 150 chip lesz, azaz ha fehéren világítunk, akkor 45W-ot megeszik. Ezzel eddig nem is lenne baj, de mindezt 5V-on csinálja, így barátok között is 9A kell neki. Ez a 9A nekem kicsit keménynek tűnik. A szalagon végigvezetett táperek elbírnak ilyen mosógép nagyságú áramot vezetni? Idézet: Elvezetni elvezetik, csak jelentos feszultsegeses lesz rajta. Nem eppen uzemi allapot. Ami LED-szalag adatlapot olvastam, ott mindig megadtak a maximalis hosszt. Az 5m altalaban a 12V-os RGB szalagokra volt jellemzo, esetleg a surubb, de 24V-osokra. „Ez a 9A nekem kicsit keménynek tűnik. A szalagon végigvezetett táperek elbírnak ilyen mosógép nagyságú áramot vezetni?”
Végighúzol a szalag mellett mindkét oldalt 1-1 vezetéket, és néhol rá is forrasztod...
És mivel szeretnéd megoldani a kommunikációt? Pár száz ns-okat várakozni szerintem necces lehet, ezért én is elgondolkodtam rajta. Valami hardveres cuccot kellene az AVR-en munkára fogni, és valószínűleg az USART lesz erre a legalkalmasabb. Az egy bit átvitelére szolgáló időt 3 egyenlő részre kell osztani, 400ns szerintem jó lehet. Az első rész mindig HI, a harmadik mindig LO, és a középső az ami meghatározza hogy logikai 1 vagy 0 lesz a bit. USART-nál ha 20MHz-es az AVR, és aszinkron módot választunk akkor U2X=1 és UBRR=0 esetén a 2.5 MBaud szimbólumsebesség pontosan 400ns bitidőt jelent. Az AVR TxD vonalára egy invertert kell kötni(elég egy NPN tranzisztor felhúzóval), mivel a nyugalmi állapot itt a 0V, míg az USART-nál az 5V. Ezzel egy USART keretbe pontosan 3 bitnyi WS2812 információ fér bele az alábbi séma szerint:
- az adatbitek száma 7 bit, 1 stopbit, nincs paritás - a start bit a legelső alkalommal átküldött bit első harmadát jelenti(HI) - a 0. bit hordozza az információt(INFO1), az 1. bit mindig LO - a 2-4. bit a második információs bitet viszi át. 2.=HI; 3.=INFO2; 4.=LO - az 5. bit mindig HI, 6.bit=INFO3, utána jön a stop bit ami mindig LO. Ha az átküldés alatt már bemásoltad a következő 3 bitnyi információt az UDR-be akkor az átvitel folyamatos.
Bit-bang. Mialatt a ledeket frissítem, értelemszerűen semmi mást nem csinálok.
1.25 us jut egy bitre, 150 LED * 24 bit * 1.25 = 4.5 ms. Lehetne még PWM-mel is megoldani, az OCRB mozgatásával, de semmi értelme, mert azzal sem fogok semmit sem csinálni, magyarul a bit-bangnél semmivel nem jobb. Az UART-ról: nem gondoltam át, hogy valóban megy-e amit leírtál, elfogadom, hogy 3 bitet át lehetne küldeni. Ez 60 órajel. Az interrupt meghívása, egy JMP, RETI az lehet 10 órajel, az interrupt lekezelése meg 30, ha hiperokos vagyok. Hiába szórakozunk UART-tal, a mikrovezérlő akkor sem lesz képes érdemleges munkát végezni. Emellett semmiből nem áll egy másik mikrovezérlőt berakni, amelyik nem a LED szalag bizgetésével foglalkozik.
De mondjuk egy 72MHz-s arm cortex 1200 Ft az ebay-en, ami 32 bites és DMA-zni is tud. Képes hardverből tolni az egészet. Csak győzzem kitalálni, hogy hogyan...
A bitbang működőképességében nem lennék ennyire biztos. Egy _delay_us(1) az már majdnem egy komplett bitidő, assembler nélkül már elég problémás lenne. Az USART-ot nem azért hoztam fel hogy az átvitel ideje alatt érdemi munkát végezzen a processzor, hanem a pontos időzítés és az egyszerű(bb) programszervezés miatt. Míg az átvitel tart, lehet foglalkozni a következő elküldendő bithármas átkonvertálásán, majd várni míg az UDRE 1 lesz és ezt addig csinálni (egy ciklusban) amíg van átküldendő adat.
Ha mégis bitbang lenne akkor használnám valamelyik időzítőt CTC módban, melynek körbefordulási ideje 400ns lenne és akkor két beágyazott ciklussal megvalósítható az átvitel. Persze egy 20MHz-es kristály itt is jól jön. A kérdés mindig az, hogy mire szeretnéd használni, hány LED-et használnál egy sorban, milyen színmélységeket akarsz elérni. Én máris VGA megjelenítésben gondolkodom ahol az adatátvitelre (soronként) elég lenne egy AVR sebessége és memóriája. De ezt a memóriát nehézkes lenne feltölteni közvetlenül az A/D konverterről ami 40-120MHz is lehet. A hozzászólás módosítva: Feb 19, 2015
Bővebben: Link
A kód a Commodore-os időkből megszokott ciklusszámlálási módszerre épül. Bit-bang, pontosan órajelre szinkronizálva, assemblyben. A hozzászólás módosítva: Feb 20, 2015
Azok a "régi" szép idők amikor AVR-el hajtottam VGA monitort, és a teljes képidő minden órajelére le volt osztva hogy éppen mit csinál a cucc. Igen, ciklusokkal és elágazásokkal együtt. Tele volt a kód időkiegyenlítő szakaszokkal, be voltak számozva az utasítások. Mindezt assemblerrel, máskülönben szétesett volna a kép.
Szia!
Én az 5m-es szalagokat 5V/2.5A-es kis kapcsolóüzemű tápról hajtottam, tökéletesen ment. Mondjuk a programokban nem volt 100% fehér. Amiket én írtam, azokban 0xE0 volt a legnagyobb PWM érték, felette már nem láttam fényerőnövekedést csak fogyasztott. Egy pontról volt csak megtáplálva (bár mindkét végén ki van vezetve a táp is szerencsére) és nem tapasztaltam besárgulást. Az adatkivitelen én is agyaltam, de a bitbillegtetés lett a vége, mert nincs DMA az alkalmazott prociba és kevés a RAM is. Semmi gondom nem volt vele, bár 1 ember panaszkodott, hogy téved, de ott Ő bizergálta a uC belső oszcillátorát valamivel-valamikor, nekem belsővel is megy tökéletesen, na jó, illene a külső kvarc. A soros perifériák alkalmazásának csak akkor látom értelmét, ha van DMA vagy pl. beépített TFT vezérlő (ilyen megoldással is találkoztam). Különben olyan gyorsan megy ki a byte, hogy felesleges visszamenni a főprogramba, majd újra INT-push stb. JAni
Sziasztok
Hogyan oldható meg az hogy 8MHz-es belső órajelet leosszam legalább 2MHz -re az LCD kijelző számára? Sajnos ha eleve 2MHz-et állítok be akkor pedig fura pici sípoló hangot ad a venti(PWM). Előre is köszönöm a segítséget.
|
Bejelentkezés
Hirdetés |
