Fórum témák

» Több friss téma
Fórum » AVR - Miértek hogyanok
 
Témaindító: pakibec, idő: Márc 11, 2006
Témakörök:
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
Lapozás: OK   644 / 837
(#) holex válasza zsozsoX hozzászólására (») Jan 30, 2015 /
 
Az eleje es vege változókat 8 bitesnek deklarálod aztán:
eleje=eredeti>>8;
vege=eredeti;
(#) Massawa hozzászólása Jan 30, 2015 /
 
Eljutottam a programozáshoz. Az egyik állitolag tesztelt gyári modult nem ismeri fel a programozo , szerencsére van egy másik, azt felismeri, de már nagyon régen nem programoztam ISP-n igy nem tudom pontosan mi is a teendö. ( az utobbi 2 évben JTAGon prigramoztam).
Betöltottem a HEX-t a Flashbe, de kiirta, hogy
Flash byte at 0x0020 is 0x00 ( should be 0x41).

Mi ilyenkor a teendö?

Kösz
(#) zsozsoX válasza gabi20 hozzászólására (») Jan 30, 2015 /
 
Atmega 644 eepromjába akarnék írni olvasni. De a ahogy néztem 2 byte-onként lehet írni olvasni. Bár az még nem sikerült. eeprom_write_word (uint16_t *addr , uint16_t value)
(#) kapu48 válasza zsozsoX hozzászólására (») Jan 30, 2015 / 1
 
Adatlap 26. oldal:
C Code Example(1)
  1. void EEPROM_write(unsigned int uiAddress, unsigned char ucData)
  2. {
  3. /* Wait for completion of previous write */
  4. while(EECR & (1<<EEPE))
  5. ;
  6. /* Set up address and Data Registers */
  7. EEAR = uiAddress;
  8. EEDR = ucData;
  9. /* Write logical one to EEMPE */
  10. EECR |= (1<<EEMPE);
  11. /* Start eeprom write by setting EEPE */
  12. EECR |= (1<<EEPE);
  13. }
  14.  
  15. unsigned char EEPROM_read(unsigned int uiAddress)
  16. {
  17. /* Wait for completion of previous write */
  18. while(EECR & (1<<EEPE))
  19. ;
  20. /* Set up address register */
  21. EEAR = uiAddress;
  22. /* Start eeprom read by writing EERE */
  23. EECR |= (1<<EERE);
  24. /* Return data from Data Register */
  25. return EEDR;
  26. }
(#) zombee válasza zsozsoX hozzászólására (») Jan 31, 2015 / 1
 
Ez egy 100-as értéket ír a 0. BÁJTBA:
  1. eeprom_write_byte ((uint16_t *)0 , 100)
(#) csabeszq válasza (Felhasználó 15355) hozzászólására (») Jan 31, 2015 /
 
Vásároltam egy 1N5908-as tranziens szupresszor diódát.

Fogtam 12V-ot rákötöttem egy 2k-s ellenállást és a tranziens szupresszor diódát. A diódán 6.43V-esett.

Úgy gondolod, hogy egy 1N5908 képes egy AVR-t megvédeni? A speckó 5.5V-ot ír, amit a dióda 1V-tal simán átlép.
(#) zombee válasza csabeszq hozzászólására (») Jan 31, 2015 / 1
 
6.43V-on egy AVR nem fog leégni, csak szólok. Esélyes hogy RESET-be megy, de tönkre nem megy.
Programoztam és teszteltem RC távirányítót aminél (sleep módban) kb. 7V-ot mértem
a VCC és GND között. Azt hittem hibás, de amikor a gyártósorról csak ilyenek jöttek le
és mind tökéletesen működött. Üzem közben (lenyomott gombbal) kb. 4.3V-on járt mind.
A hozzászólás módosítva: Jan 31, 2015
(#) killbill válasza zombee hozzászólására (») Jan 31, 2015 / 1
 
A tudatlansag es a szerencsefaktor a legnagyobb ellensege a terverzesnek. Ha az adatlap azt irja, hogy Absolute Maximum Rating 6.0V es melle azt irja, hogy ezeket tullepve az alkatresz tonkremehet, akkor tok mindegy, hogy te lattal-e olyan alkatreszt, ami kibirt 7V-ot vagy nem. Attol, hogy valamit sorozatban gyartanak, legyen az RC taviranyito, az meg lehet rosszul tervezve.
A hozzászólás módosítva: Jan 31, 2015
(#) csabeszq válasza killbill hozzászólására (») Jan 31, 2015 /
 
Kérdés az, hogy érdemes-e hozzáadni egy diódányi nyitófeszültséget a transilhez.

A step-down kimenetére kötöm a transil diódát, utána rakok ez mezei 1A-s diódát, ezt pedig rákötöm a feedback lábra.

A kimenet továbbra is 5V lesz, a dióda előtti rész 5.7V, ahová a transilt rakom. Ez után a kimenet garantáltan nem lépi túl a 6V-ot, viszont a diódán folyamatos áram lesz, mert 5.7V-on már nyit.
(#) killbill válasza csabeszq hozzászólására (») Jan 31, 2015 / 1
 
Elobb nezd meg, hogy a suppressoron tobb ampernel mekkora feszultseg esik, mert te 3mA-rel merted. Amikor amperek folynak rajta, akkor az szerintem feljebb megy. Adatlap. Szerintem a crowbar-nal biztosabb es jobb megoldas nem lesz. Az a baj, hogy 5V a tap kimenete, de az AVR-nek szerinted 5.5V (egy ATMega8A adatlap szerint 6V) a maximum. Nem nagyon ismerek olyan passziv alkatreszt, ami ezen a fel volton belul nyit ki meredeken. A zener talan, de azt valogatni kell, mert nem eleg pontosak.
(#) kovacsj hozzászólása Jan 31, 2015 /
 
Sziasztok!
Ismét hozzátok fordulok, mert valami triviális dolgot nem jól csinálok, és erre csak hétvégén van időm. Van ez az ltc1864-es, 16-bites ADC. Ennek a mintavételezési sebessége max. 250 kHz. A kontrolleremet egy 7372800-ás külső kristály hajtja. Úgy gondolom, hogy ezért az SPI órajelhez a 7372800-át legalább 32-vel kell osztani (így 230400 lesz), mert ha 16-tal osztom, akkor akkor túllépem a max. 250 kHz-et. (460800).
Ha 16-tal osztom, akkor olvasok randomszerűen számokat, míg ha 32-vel, akkor mindig nulla az eredmény. A konverzióhoz szükséges idő legfeljebb 4 us. Ez körülbelül 30 órajelet jelent. (0.000004/(1/7372800)). A 16 adat kinyeréséhez 16 SPI órajel kell, ami 32-vel szorozva 512 rendes órajelnek felel meg. Az adatok mégsem jönnek. Pedig az analóg in+ bemeneten 2,3V-ot mérek, és a referencia feszültség 5V.

Mennyit kellene mérnem? (30146-ot számolok. Természetesen átveszem a két bájtot, és egy 16-bites változóban egyesítem.)
Mit csinálok rosszul?

Minden segítséget előre is nagyon köszönök!

LTC1864
Atmega2561
A hozzászólás módosítva: Jan 31, 2015
(#) killbill válasza kovacsj hozzászólására (») Jan 31, 2015 / 1
 
A mintavetelezes sebessege egesz mas dolog, mint az SPI orajel. Az lehet sokkal tobb, valami 20MHz, ahogy emlekszem. Az adatlapon ott van szepen, hogy mikor veszi a mintat az A/D, es hogy mikor lehet kiolvasni a konvertalas eredmenyet. Es az is, hogy a kiolvasaskor az SPI-n az IC-be beirt bitek mit jelentenek.
(#) kovacsj válasza killbill hozzászólására (») Jan 31, 2015 /
 
Igazad van, elnéztem. Nagyon köszönöm! A Clock frequency lehet 20 MHz is. Rögtön vissza is állítom az osztót. Ekkor azonban 256 rendes órajel jelent 16 SPI órajelet. Ehhez jön a konverzióhoz szükséges idő. Ami változatlanul 30 órajel körüli. A Timer3 OCR3B = 30 és OCR3A = 286 megszakítása (CTC Output Compare) billegtetné a CONV lábat. Sajnos, random értékeket olvasok. Gyakran fordul elő 257, ami ugye a két bájt alsó értéke.

Még mindig az időzítés lehet a rossz?

Vagy az is lehet, hogy itt nem jó valami?

  1. ISR(SPI_STC_vect) {
  2.  
  3. atmenet =  SPDR;
  4. if (jelzo ==0) {
  5. eredmeny = (uint16_t) (atmenet<<8);
  6. jelzo = 1;
  7. SPDR = 0xFF;
  8. }
  9.  
  10. else {
  11. eredmeny |= (uint16_t) atmenet;
  12. jelzo = 0;
  13. }
  14. }


Ha az OCR3B-t 30-ra és az OCR3A-t 286-ra állítom, akkor 0-kat kapok.
Ha ugyanezeket felemelem 225 és 450-re, akkor viszont számokat.
Nem jó számokat ugyan, de számokat.

Valószínűleg nem jól számolok valamit. Ez az első SPI kísérletem. Eddig mindig soros portot használtam. Több-kevesebb sikerrel.
A hozzászólás módosítva: Jan 31, 2015
(#) Droot válasza kovacsj hozzászólására (») Jan 31, 2015 / 1
 
Itt van egy kód hozzá, az oldalon középtájt. Nem próbáltam ki hogy működik-e, de azt írják igen, tehát nagy valószínűséggel jó.
Ne másold be, hanem nézd meg hogy mi a különbség aközött és a te kódod között és gondolkozz hogy abban miért más. Csak így tanul az ember!
+1: Ha új eszközzel akarsz kommunikálni ne legyen más kód, csak a kommunikáció és ami ahhoz kell, ha már működik belerakhatod a többit. Én új eszközök élesztésénél mindig RS232-USB konverterrek küldöm ki a laptopomnak, vagy ha van rajta LCD akkor esetleg azt bennehagyom.
(#) kovacsj válasza Droot hozzászólására (») Jan 31, 2015 /
 
Köszönöm szépen! Ezt már láttam, de nekem mivel pontos időzítésre lenne szükségem, muszáj az órával ütemeznem. Ebből adódóan a megszakításokkal kell lekezelnem. Vagyis hát kellene. A lényeges különbség ebben és az én kódomban az, hogy miközben nekem a CPOL be van állítva, itt nincs. De nem ugyanaz a módszer.

Nincs más kód benne, csak az USART, meg ez. Valahogy látnom kell, hogy mit nem csinálok jól.
A hozzászólás módosítva: Jan 31, 2015
(#) kovacsj válasza Droot hozzászólására (») Jan 31, 2015 /
 
Idézet:
„I wrote library and i havent any response from LT1864. Where is mistake?
.h”


Azt írják, nem jó. És nekem sem működik. 0 eredmények jönnek vissza. De azért köszönöm szépen, hogy segíteni próbáltál. Megpróbálom megszakítások és óra nélkül. Talán úgy hamarabb eredményre jutok.
A hozzászólás módosítva: Jan 31, 2015
(#) kovacsj válasza Droot hozzászólására (») Jan 31, 2015 /
 
Azért adtál egy jó ötletet. Hátha így egyszerűbb lesz.
(#) kovacsj válasza kovacsj hozzászólására (») Jan 31, 2015 /
 
Na, ezt találja ki valaki, hogy mitől lehet!
Néhány x beírása után meg kellene hívódnia ennek a függvénynek:

  1. void result_write() {
  2.         kimenet = ltcRead();
  3.         sprintf(buffer, "%d\n\r", kimenet);
  4.         USART1_String(buffer);
  5.         received[0] = '0';
  6. }


Az ltcRead az előző példából van kimásolva.

  1. uint16_t  ltcRead(void)
  2. {
  3.         uint16_t tempRead = 0;
  4.         uint8_t valRead = 0 ;
  5.        
  6.        
  7.        
  8.         PORTG &= ~(1<<PG0);
  9.        
  10.         SPDR = 0x01;   
  11.         while(!(SPSR & (1<<SPIF)));
  12.         valRead = SPDR;
  13.         tempRead = valRead ;
  14.         tempRead = (tempRead<<8) ;
  15.        
  16.        
  17.         SPDR = 0x01;   
  18.         while(!(SPSR & (1<<SPIF)));
  19.        
  20.         valRead = SPDR;
  21.         tempRead |= valRead;
  22.        
  23.        
  24.        
  25.         PORTG |= (1<<PG0);
  26.        
  27.        
  28.         return tempRead;
  29. }


A bármilyen eredmény helyett a bluetooth inicializálást kapom vissza.

  1. void Bluetooth_init(void) {
  2.        
  3.         USART1_String("ATZ\n\r");
  4.         _delay_ms(100);
  5.         USART1_String("AT\n\r");
  6.         _delay_ms(100);
  7.         USART1_String("AT+UARTCONFIG,9600,N,1,0\n\r");
  8.         _delay_ms(100);
  9.         USART1_String("AT+BTNAME=Eszkoz1\n\r");
  10.         _delay_ms(100);
  11.        
  12.         USART1_String("AT+BTKEY=2314\n\r");
  13.         _delay_ms(100);
  14.         USART1_String("AT+BTSCAN\n\r");
  15.         _delay_ms(100);
  16.        
  17. }


Ennek a szövege jön, minden meghívásra.
Csak nem értem.
A hozzászólás módosítva: Jan 31, 2015
(#) kovacsj válasza kovacsj hozzászólására (») Jan 31, 2015 /
 
Ez megoldódott. Az interrupt-ot ki kellett kapcsolni.

A helyzet azonban nem lett jobb.
Így is csak nullák jönnek.
A hozzászólás módosítva: Jan 31, 2015
(#) Kovidivi hozzászólása Jan 31, 2015 /
 
Sziasztok!
Timer1-et inicializáltam. Két interrupt-om van, egyik, amikor OCR1A-val megegyezik a TCNT1-gyel, a másik pedig amikor túlcsordul a TCNT1. A gond, hogy le lesz nullázva a számláló, ha az OCR1A interrupt lefut. Most úgy oldottam meg, hogy az OCR1A interruptjában adtam eggyel nagyobb értéket a TCNT1-nek, mint ami előtte volt, így tovább számolt a timer. Így működőképes. A kérdésem, hogy ezt így szokták csinálni? Szoftveres pwm-et állítok elő. Köszönöm!
(#) kapu48 válasza kovacsj hozzászólására (») Jan 31, 2015 / 1
 
Az ltcInit()-et meghívod valahol?
A set-SS bitet ne használd, mert szétkapcsol a 2 Byte között.
(#) kovacsj válasza kapu48 hozzászólására (») Jan 31, 2015 /
 
Igen, meghívom, csak az nálam korábban is spi_init() volt. Most a nullákkal küzdök. Az interruptos megodásban legalább számokat is láttam, de azt az időzítést nehezebb volt tartani.
Így könnyebb lenne, de így meg mindig 0 az eredmény.
(#) kapu48 válasza kovacsj hozzászólására (») Jan 31, 2015 / 1
 
Adatlap 6. oldalon írja, hogy várni kel a konverzióra:
Setup Time CONV- Before First SCK↑ Max 60 ns, Typ 30 ns.

Gondolom attól függ menyi bitet használsz?
A hozzászólás módosítva: Jan 31, 2015
(#) kovacsj válasza kapu48 hozzászólására (») Jan 31, 2015 /
 
Lehet, hogy ezt sem jól csinálom. De próbáltam már nagy időt is adni neki. Végül is, jöttek számok, de nem volt benne következetesség. Most azonban csak nullák. Megpróbálom az általad javasolt időzítést. Köszönöm a segítséget!
(#) kovacsj válasza kapu48 hozzászólására (») Jan 31, 2015 /
 
Vannak már számok is, csak nagyon különbözőek, és egyik értéke sem haladja meg a 8 bitet.
A probléma az volt, hogy elfelejtettem, hogy a CONV láb akkor megy le, ha a PG0 fel.
A 16 bit azonban még mindig várat magára. Szerintetek mi lehet itt a rossz? (A kód nagy része még mindig másolt.)

  1. uint8_t  ltcRead(void)
  2. {
  3.         uint8_t valRead;
  4.         uint16_t tempRead;
  5.        
  6.         PORTG |= (1<<PG0);
  7.        
  8.                        
  9.         SPDR = 0x01;   
  10.         while(!(SPSR & (1<<SPIF)));
  11.         valRead = SPDR;
  12.         tempRead =  valRead ;
  13.         tempRead =  (tempRead<<8);
  14.        
  15.         SPDR = 0x01;
  16.         while(!(SPSR & (1<<SPIF)));
  17.         valRead = SPDR;
  18.         tempRead |=  valRead;
  19.        
  20.        
  21.         PORTG &= ~(1<<PG0);
  22.         return tempRead;
  23.        
  24. }
(#) kapu48 válasza kovacsj hozzászólására (») Jan 31, 2015 /
 
  1. uint8_t  ltcRead(void)
  2. {
  3.         uint8_t valRead;
  4.         uint16_t tempRead;
  5.        
  6.         PORTG |= (1<<PG0);
  7.        vait(30ns);  <<<<< ?
  8.                        
  9.         SPDR = 0x01;
(#) kovacsj válasza kapu48 hozzászólására (») Jan 31, 2015 / 1
 
Betettem. Először 30-at, utána 60-at. Mégis 8 bit az eredmény.

  1. PORTG |= (1<<PG0);
  2.         _delay_us(0.06);


Pedig már éppen Istennek akartalak szólítani. De ami késik, nem múlik.
A hozzászólás módosítva: Jan 31, 2015
(#) kapu48 válasza kovacsj hozzászólására (») Jan 31, 2015 / 1
 
?
  1. 18.   tempRead +=  valRead;
(#) kovacsj válasza kapu48 hozzászólására (») Jan 31, 2015 /
 
Sajnos, még mindig 8 bit. Pedig a bitműveletet a másiknál is kikapcsoltam. Valahol eltűnik az első bájt.
A tempRead = tempRead<<8 sincs már benne. Mégis hasonló eredmények jönnek.
(#) kapu48 válasza kovacsj hozzászólására (») Jan 31, 2015 / 1
 
Ezen ne csodálkoz!!!:
"A tempRead = tempRead<<8 sincs már benne. Mégis hasonló eredmények jönnek."
Következő: »»   644 / 837
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem