Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   91 / 91
(#) cimopata hozzászólása Ápr 9, 2017 /
 
Üdv

Kicsit bajban vagyok mert találtam egy bug-ot a programomban és nem jövök rá miért.
Röviden PWM bemenet kitöltését szeretném mérni ami nagyjából megy is lefutóélre van beállítva tehát alapban magas a bemenet.

A baj ott kezdődik, hogy méri is a kitöltés de teljesen véletlenszerűen kihagy méréseket. Ezt abból veszem észre ha nincs eredmény mindkettő regiszterbe CCR1 (periódus), CCR2(impulzus szélesség) a program szerint meg kellene vizsgálnia, hogy a számlálóban van e overflow. Az else rész a programban véletlenszerűen végrehajtódik pedig nem szabadna mert a PWM jel a bemeneten nem szakad meg hanem folyamatos.

Valami baj van a kóddal?
  1. if( (TIM3->SR & (1<<1)) && (TIM3->SR & (1<<2))) //  CCR1 flag  és CCR2 flag ellenőrzése
  2.                                 {
  3.                                         TIM3->SR=0x0; // státusz regiszterek törlése
  4.                                         duty=TIM3->CCR2;                                               
  5.                                         freq=TIM3->CCR1;
  6.                                 }
  7.                        
  8.                                 else
  9.                                 {
  10.                                         if( (TIM3->SR & (1<<0)) && (TIM3->SR & (1<<2))) // UIF flag és CCR2 flag
  11.                                                 {
  12.                                                 duty=0x0;
  13.                                                 freq=0xFFFF;
  14.                                                 TIM3->SR=0x0; // státusz regiszterek törlése
  15.                                                 speed_potbuf=0;
  16.                                                 }
  17.                                 }
(#) csabeszq válasza killbill hozzászólására (») Ápr 9, 2017 /
 
A PC nem realtime.

Nincsenek garantált idők, annyit tehetsz, hogy nem csinálsz semmit, csak usb-t hallgatsz.

700 megát küldtem át, simán lehet, hogy van 100 mega puffere, amit 10 ms alatt ír lemezre. Itt pedig megszívtad.

Nincs semmi garantálva.
(#) killbill válasza csabeszq hozzászólására (») Ápr 10, 2017 /
 
A user program valoban nem garantal semmit, de az USB driver-nek muszaj garantalnia, kulonben semmi nem mukodne. Ami sokkal inkabb nem garantalt, az maga az USB sebessege. Az USB szabvany eleve olyan, hogy nem garantal neked semmit. Vagy adatvesztes fordulhat elo (isochronous), vagy a savszelesseg nem garantalt (bulk). Nem beszelve arrol, hogy a device-ok kozott megoszlik a savszelesseg. De csodak nincsenek, az Etherneten sincs garancia a teljes savszelesseg kihasznalhatosagara, ha tobben is hasznaljak a halozatot. En is csak azt mondom, hogy, ha ennyire fontos az 1 megabyte/s, akkor high-speed USB kell vagy mondjuk Ethernet. Ami azt illeti, az Ethernet sokkal normalisabb atviteli medium (pl. galvanikusan levalasztott), es a 100 megabit/s teljesen hetkoznapi dolog mikrokontrolleres kornyezetben is.
(#) csabeszq válasza killbill hozzászólására (») Ápr 10, 2017 /
 
Nem fontos az 1 MByte, csak játszom vele. Azzal szórakozok, hogy maxig kinyomom a projektjeimben a chip képességeit. Még sosem írtam USB-s kódot, így mindenképp jó szórakozás.

833 kHz-ig eljutottam, itt a téma lezárva. Logikai jelanalizátorral kimértem, a hub beküldi az IN PID-es kérést, amire DATA PID-del válaszolok. A maximális 64 bájt a csomagméret. Ez 833 kHz-ig működik, utána nem.

Nagyon szépen látni, hogy a hub kérdez ritkán, nem én válaszolok lassan. Ezzel a hubbal ennyit lehet elérni. 20-30 us késleltetésekkel kérdezett, amivel nem megyünk 1 mbyte fölé.

A rendszer a túloldalon vár...
A hozzászólás módosítva: Ápr 10, 2017
(#) kissi válasza csabeszq hozzászólására (») Ápr 10, 2017 /
 
Szia!
Milyen analizátorral nézed az USB forgalmat ?
(#) csabeszq válasza kissi hozzászólására (») Ápr 11, 2017 /
 
A kínai Saleae Logic klónnal nézegettem.

Ebay-en 2000 Ft-ért megvehető.

Ez 24 msps-sel mintavételez, az USB full speed 12 mbps-sel küld. Még éppen a határon van a használhatósággal, mert 1 jel 2 mintavételt jelent.

A csomagok 95%-át tudja dekódolni, de mivel más az órajel, előfordulhat, hogy annyira rosszul trafálja el, hogy a D+ éppen elcsúszik a D- hoz képest. Ilyenkor előfordul, hogy nem tudja a csomagot dekódolni. Ennek ellenére szerintem még használható.

A Saleae egyébként dekódolni is tudja az USB 1.1-et.
A hozzászólás módosítva: Ápr 11, 2017
(#) kissi válasza csabeszq hozzászólására (») Ápr 11, 2017 /
 
OK, akkor ennyiért megéri !
Köszi az infót!
(#) csabeszq hozzászólása Ápr 12, 2017 /
 
USB-vel kapcsolatban lenne további kérdésem. A scope vagy USB-ről megy, vagy power bankról. Attól függ, hogy letöltök-e, vagy mérek.

Amikor USB-ről megy, akkor kb. jónak mondható. Powerbanknál megpusztul, mert a D+ láb megasra van húzva, a D- láb viszont lebeg. A vezérlő élete azzal telik, hogy dobálja az ERR interruptokat, gondolom framing probléma. A mikrokontroller idő 90%-át a lebegő láb okozta hibakezelés tölti ki.

Ti mit szoktatok csinálni?
Megoldási javaslatok:
- nemes egyszerűséggel kikapcsolom az Suspend/Resume/Error/Missing Start Of Frame interruptokat, egy darab interrupt nem fog meghívódni, ha nincs hardver. Ezeket egyébként sem nagyon használom semmire.
- pull down ellenállás D- vonalra, 33k, 330k ment, bár nem láttam olyan kapcsolási rajzot, ahol a D- vonalat lekötötték volna a földre.
A hozzászólás módosítva: Ápr 12, 2017
(#) cross51 válasza csabeszq hozzászólására (») Ápr 14, 2017 /
 
Új vagyok még az ARM-os kontrollerek-nél, de ez csak 1 ellenállás próbáld meg mert tegnap pont olvastam egy szaklapban.
kép
(#) csatti2 válasza cross51 hozzászólására (») Ápr 14, 2017 /
 
Szerintem valamit félreértettél. Az az ellenállás DCP-nek (Dedicated Charging Port) jelöli meg az USB-n a tápforrást. Semmi értelme sincs a kliens oldalon, ahol a kollégának gondot jelent a lebegő D-.
(#) csatti2 válasza csabeszq hozzászólására (») Ápr 14, 2017 /
 
DCP-nél javasolt a D+ felhúzása 2MOhmal a VUSB-re, a D- lehúzása a GND-re és a D+, D- összekötése max. 200 Ohm-al. Ebből kiindulva (bár mint írtam ez a másik oldal) megpróbálhatod egy nagy értékű (2MOhm) ellenállással lehúzni, illetve felhúzni a vonalakat. Majd ezután ellenőrizni, hogy még mindig megbízható a kommunikáció.
A másik lehetőség, hogy az USB szabványban foglaltak szerint először végigjátszod az enumerating-ot (addig max. 100mA-t használhatsz a tápból). Ha az sikeres, akkor jobban "megszívhatod" az USB-ot. Ha nem sikeres, akkor valszeg töltőről vagy powerbankból jön a nafta és lekapcsolhatod az USB kommunikációt.
(#) csabeszq válasza csatti2 hozzászólására (») Ápr 14, 2017 /
 
Köszi, kicsit kisebbet, 66k-t tettem be, azzal egyelőre stabil. Ha gond lenne lecserélem 2 mohmra.

Lebegni nem lebeghet, mert iszonyú zajt és fogyasztást csinálhat.

A D- hoszt oldali 15k-ja így 12k-ra csökken. Megy és stabilnak tűnik, viszont a speckót nem tartom.
Következő: »»   91 / 91
Bejelentkezés

Belépés

Hirdetés
Frissek
2017. Ápr, 25. Kedd
14:30:44
Jelenleg 395 fő olvassa az oldalt
Online tagok:
Lapoda.hu     XDT.hu     HEStore.hu