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
Helyesbítenék: PinD a D port bemeneti regisztere, a PortD a D port kimeneti regisztere.
Tehát: in r16, PinD ; r16 -ba beolvassa a port állapotát out PortD, r16 ; r16 tartalmát kiküldi a portra sbi PortD, 0 ; a D port 0 című bitjébe ír 1-et (set) cbi PortD, 3 ; a D port 3 című bitjébe ír 0-t (clear) Stack: javíts ki, ha valamit rosszul tudok! - Az SP minden push utasítás után csökken 1-gyel, azaz a nagyobb RAM címtől a kisebb felé halad - Beállítom a stack méretét, pl 63 bájtot lefoglalok, arra a címre beállítom az SP-t, és onnantól a kisebb címek felé a stack, a nagyobb címek felé a RAM-ban tárolt adatok, adatblokkok Egészen kis kontrollernél alkalmaztam, hogy kézben tartható legyen a stack által igénybevehető RAM terület, ne csúszhasson össze más adatokkal. Azután így maradtam a mostani programjaimban is... Egyébként igazad van, egyszerűbb amit javasolsz, megváltoztatom. A programomban konkrét értéke lesz a TCNT2-nek, a teszthez a legnagyobb értéket adtam meg. Késleltetés a megszak rutinban: csak a szkóppal való megjeleníthetőség miatt növeltem meg a rutin futásidejét. Enélkül a szópomon nem lenne látható a túl rövid tüske.
Hi Mesterek!
Szereztem egy mk2 programozót. Ehhez milyen szoftvert használtok IC égetésére. Ugy értem mint a pic-nél használatos PICkit 2 programmer szoftver. Azért kell mert egyenlőre a flow-ot használom, s a legenerált hex-et át kellene juttatni az epromba. Válaszokat előre is köszönöm.
Az mk2 az nem programozó, hanem valaminek a 2. verziója... Gondolom egy AVRISP mkII-t szereztél.
Programozni az Atmel Studio-val lehet, amit itt találsz meg: Atmel Studio 7 A program nem az EEPROM-ba kerül, hanem a flash-be. A hozzászólás módosítva: Márc 13, 2018
Parancssoros "égető" szoftver az Avrdude. Létezik hozzá grafikus felület is: AVRDUDESS – A GUI for AVRDUDE
Sziasztok!
SPI kérdés. 9 bites adatsort be lehet írni az SPDR regiszterbe? Ill. a 16 bitet gondolom kétszer 8 bitként kell átküldeni, de kell-e a két 8 bites sor közé a while-os várakozás? Köszönöm! Nevezetesen egy Si4703-as IC-t próbálok működésre bírni, csatolom a vezérlő adatsor felépítését.
Ez nem "igazi" SPI. Ott külön van a MOSI és a MISO. Itt pedig egy IO vezeték van. Lásd itt is.
Lásd még a Wikipediat: "Three-wire serial buses As mentioned, one variant of SPI uses single bidirectional data line (slave out/slave in, called SISO) instead of two unidirectional ones (MOSI and MISO). This variant is restricted to a half duplex mode. It tends to be used for lower performance parts, such as small EEPROMs used only during system startup and certain sensors, and Microwire. Few SPI master controllers support this mode; although it can often be easily bit-banged in software." Nem írtad, hogy pontosan melyik AVR-t használod. Úgy könnyebb lenne segíteni. De valószínűleg szoftveresen kell megoldanod. A 9 bites SPI sem biztos, hogy támogatott, akkor azt is szoftveresen kell megoldanod.
Köszi a válaszokat! Mega 328p-t használok a teszteléshez, de majd egy nagyobbal lesz működtetve. Az Arduino Libbel próbáltam ki a kínai modult hogy egyáltalán működik-e. Az I2C-n kommunikál, nekem meg van még két SPI-os eszköz a projektemben és egységesíteni akarom.
Kell a while. Ez egy MAX7219 vezérlés, nézz rá a SPI_Write függvényre, hogy megy ki 16 bit.
Bővebben: Link
Köszi!
Akkor szerintem úgy fogom csinálni, hogy a 9 bitből egyet SPI mód nélkül manuálisan küldök át, a többit pedig hardveresen. De ha nem tudom feléleszteni, akkor az Ardus IIC alapján megpróbálkozom úgy vezérelni.
Egy különös dologra keresek magyarázatot.
Adott egy AVR-es forráskód. Hozzá egy Makefile és az avr-gcc 5.4.0 Linuxra. Ez egy csomag, a forrás együtt a fordítóval, hogy biztosan mindenütt ugyanaz legyen az eredmény. De nem lesz ugyanaz. Van három különböző Linuxos gép, és három Windowsos, ez utóbbiakon a Windows Subsystem for Linux bash alól történik a fordítás. Mind a hat gépen ugyanaz a csomag van forrással és fordítóval. Az összes hex egyforma méretű lesz. A három Windowsos gépen készült hex teljesen egyforma. A három Linuxos hex egymástól és a Windwsosaktól is különbözik tartalmában. A Windowsos és az egyik Linuxos hex működik (pedig eltérő a tartalmuk!), a másik két hex is csinál valamit, mert elindul a program, működik a soros kommunikáció, de a mért / számolt / küldött adatok rosszak. Mi okozhatja ezt, és hogyan lehet elkerülni?
A Linux-os csomagban benne van a gcc mellett az összes többi dolog is? Leginkább a libek, amiket hozzalinkel a lefordított kódhoz. Meg persze az assembler, linker, stb? Fordítás után az objdump nevű programmal meg tudod nézni, hogy mit fordított.
A hozzászólás módosítva: Márc 22, 2018
Igen, az avr libc és minden lib is a csomag része.
A hex állomány tulajdonképen egy szöveg állomány. Linux/Unix rendszerekben a sorvég LF (0x0A), a Windows -on CR LF (0x0D 0x0A). Ettől a windows-os mérete eltér a Linuxostól még akkor is ha ugyan az az adat van benne.
Ezt írtam:
"Windowsos, ez utóbbiakon a Windows Subsystem for Linux bash alól történik a fordítás" Tehát ez egy Linux környezet, csak NT kernel van alatta. Tehát nem számít. Linux binárisok, nem win32 binárisok. Nem cygwin, nem mingw. Ezt is írtam: "Az összes hex egyforma méretű lesz."
Akkor passz. Environment változók? Bár nem rémlik, hogy a gcc foglalkozna velük.
Ez nem jelent semmit, de speciel nálam Linux alatt CR LF van a hex es srec file-okban. Így generálja az objcopy.
Láthatnánk két példát,, egy windows -osat és egy Linux -osat?
Majd megpróbálok összerakni valami tesztet, amit meg tudok mutatni.
Az állományra gondoltam. Feltöltenél belőlük?
Én is erre gondoltam. Megpróbálom reprodukálni a hibát egy blinky projekttel. Egy munkához kapcsolódik az, ahol a hibával találkoztam, nem tölthetem fel a hexeket.
"Adott egy AVR-es forráskód. Hozzá egy Makefile és az avr-gcc 5.4.0 Linuxra. Ez egy csomag, a forrás együtt a fordítóval, hogy biztosan mindenütt ugyanaz legyen az eredmény."
Tippre arra gondolnék, hogy ez lehetett a cél, de nem ez lett az eredmény. Azt kellene megnézned, hogy a Makefile a mellé rakott avr-gcc-t használja-e vagy a gépen lévőt. Elképzelhető, hogy akkor kapsz egyforma eredményt, ha linux/windows gépen nincs avr-gcc. Amelyiken viszont van és a Makefile azt használja a mellé rakott avr-gcc helyett, az adhat más eredményt. Én első körben a Makefile-t nézném meg.
Kösz. Benne van a Makefile-ben a toolcahin realatív elérése.
Sziasztok!
Hogyan csinálnátok meg a következő feladatot? Van két nyomógomb, felhúzókkal. Ha az első gombot megnyomom, belép egy programba. Ebből akkor lép ki ha a kettes gomb le van nyomva (while és delay nélkül) Ha a kettes gombot nyomom le, akkor belép az ő programjába és az egyes kapcsolja ki. Nem sikerült úgy megcsinálnom, hogy a funkció kikapcsolásakor ne induljon el a másik... Remélem érthető így a dolog. Köszönöm szépen!
A lerajzolt változat: addig marad a saját programjában, amíg a másik nincs indítva.
Másik lehetséges változat: ha a P1 és a P2 is csak egyszer futhat le, akkor P1 végén, illetve P2 végén a főprogramra kell visszaugrani...
Remélem tudod, hogy a programozók lusta komák!
Szóval, ha ide másolod a próbálkozásod, szívesen kijavítjuk! 
Amikor az valamelyik funkcio visszater, akkor esetleg meg lehet varni, hogy mindket gombot elengedjek. A gyakorlati megvalositasban lehetnek problemak, ha a nyomogomb mechanikus es prellezik.
Nem javitast kert, hanem megoldasi otletet.
|
Bejelentkezés
Hirdetés |
