Fórum témák
» Több friss téma |
Igen. Módosítottam is egyből a kódot, hogy ilyen ne forduljon elő még egyszer.
Köszi az észrevételt.
Az STM32F103-assal kapcsolatban érdeklődnék. Az oszcilloszkóp projektben annál a résznél tartok, hogy át kellene varázsolni a mintavételezett adatokat a PC felé.
Több megoldáson is gondolkoztam, ebből a leglogikusabb implementálni egy USB CDC eszközt. Az UART-tal az volt a problémám, hogy eszméletlen lassú (max 2mbps azaz 200 kbyte/s), miközben USB CDC-ként az ST mintapéldáját átbuherálva első blikkre 800 kbyte/s-et nyomott. A mintapélda nem túl intelligensen lett megírva. A kérdésem is ezzel kapcsolatos: - van-e tapasztalatotok, meddig lehet eljutni a 12 mbps-es full USB-vel? Elérhető-e az 1 mbyte/s? - az USB-t zavarja-e hogy 72 MHz helyett 56 MHz-en megy a rendszer órajel? - mire érdemes figyelni? Eléggé kezdő vagyok USB-vel kapcsolatban, szóval érdekne ha van benne tapasztalatotok.
USB Bulk transzfer max 64 byte-os csomagból 19-et tud küldeni ms-onként, így elvileg elérhető 1,159 MB/s sebesség. De ez a sávszélesség és a késés nem garantált. Azaz ha más is használja a host-ot, akkor ez csökken.
Az USB-nek saját órajele van, nem zavarja a sysclk sebessége, de azért kell tartalék, hogy az adatfolyamot tudja kezelni.
Köszi a választ.
Nekem 1 MByte/s-re lenne szükségem, mert az 1 MSPS mintavételezés mellett az ADC-t 8 biten még éppen átviszi. Marad 56 órajel a puffer előállítására (56 MHz). Ha pedig késne az átvitel, akkor hibaüzenettel le kellene állni.
"az USB-t zavarja-e hogy 72 MHz helyett 56 MHz-en megy a rendszer órajel?"
"Az USB-nek saját órajele van, nem zavarja a sysclk sebessége" Az USB órajelét 1 vagy 1.5 osztóval állítja elő a SYSCLK-ből, tehát USB használatához 48 vagy 72 MHz SYSCLK kell. Lásd adatlap vagy Cube MX clock configuration.
Túl sok lehetőség nem maradt. Visszaállítom az órajelet 72MHz-re, amikor pedig 1 msps körül kellene mintavételezni, túlpörgetem az ADC-t 18 MHz-re. Láthatóan bírja, legalábbis első ránézésre simán tolta 18 MHz-en is 14 MHz helyett.
Attol, hogy adat jon ki belole, meg nem biztos, hogy pontos lesz. Ha meromuszert csinalsz, akkor erre kulonosen oda kellene figyelni, nem pedig szandekosan specifikacion kivul jaratni a meromuvet.
Igen gondolkoztam ezen, lehet, hogy maradok 56MHz-en.
Alapállapotban mérés közben értelemszerűen nincs USB. Nem kell nekem még egy cucc, ami belassít. A trigger jel keresés így is félig assembly-ben a határig van feltolva. Nincs lehetőség az USB jelekre válaszolgatni millisec-enként. Amikor menüből kiválasztom, hogy USB-n szeretnék adatot küldeni, olyankor lehet feltolni a frekvenciát 72 MHz-re. Ilyenkor kiadok a D+-on egy alacsony jelet, ami resetel mindent és újra enumerálja az eszközt. Miután felcsatolódik, akkor max 833 kHz-en lapátolhatom át az adatokat. Tehát tartom a speckót és megy az USB is. Amikor befejeztem az USB-t, visszaállítom a frekvenciát 56 MHz-re és leválasztom az eszközt a buszról. USB közben nincs trigger és egyéb baromság. Egy körkörös pufferbe DMA-val tolom az ADC-t, amit az USB pufferbe másolok, amikor kell.
Ha:
HSE = 8MHz * PLL 9 = SYSCLK 72MHz, APB1 Prescaler /2 = PCLK1 36MHz APB2 Prescaler /1 = PCLK2 72MHz ADC Prescaler /6 = ADC 12MHz Ez a beállítás nem jó neked? A hozzászólás módosítva: Ápr 5, 2017
Nem, mert nem képes 1 msps mellett mintavételezni, 833 kHz körül van a végsebessége.
A hozzászólás módosítva: Ápr 5, 2017
Az STM32 órajelével nem lehet sokat baromkodni, mert a buszon mindenki meghülyül, így az USB sem megy. Eléggé belezavar mindenbe ha össze-vissza ide-oda állítom az órajelet. Minden periéria a SYSCLK-n csücsül, mindenbe belezavar az állítgatás. Ez az út nem járható.
Viszont a másik út járható. - 72 MHz-en megy minden - amikor 1 msps-sel, vagy 1.2 msps-sel mintavételezek, akkor 18 MHz-re felemelem az ADC frekvenciát Lehet mondani, hogy illetlenség túlpörgetni az ADC-t, viszont megjegyezném, hogy még 36 MHz-en sem omlik össze a cucc, bár egy kicsit zajosabb. Ha 250%-os órajeltúltolást is túlél a cucc, akkor a 30%-kal túlpörgetés egyáltalán nem tűnik vészesnek. Pláne úgy, hogy csak akkor pörgetem túl, amikor a 833 kHz kevés. A hozzászólás módosítva: Ápr 6, 2017
Miért nem használsz gyorsabb chipet? Árban nincs említésre méltó különbség, sebességben annál inkább.
Ebayes kész breadboardba dugható panelekkel játszom.
Nem láttam, hogy gyártottak volna ilyet.
Olcsó, kínai STM32F407ZGT6 board.
Gyorsabb core, több USB prescaler, stb. De az ST árai teljesen rendben vannak itt Európában is. STM32F4 és F7 fejlesztőkészletek az rs olnline-on Én a legtöbb fejlesztésnek egy ilyennel állok neki: STM32F429 Discovery Nagyon jó az ára, főleg ha azt nézzük, hogy van rajta egy 180 MHz 144 lábú F4, 8MB DRAM, USB hoszt, giroszkóp, TFT + touch és debugger.
A kínai STM32407-es érdekes, a 17 dolcsi azért megfontolandó, mert jelenlegit 2 dolcsi alatt veszem. Könnyű szívvel vágom a kukába, ha valamit szétvágok rajta.
Az USB jelenleg már hellyel-közzel megy. Mondjuk eszméletlen jó debuggolni. Tuti, hogy minden millisec alatt jön valami, kész élmény a kommuniukációt követni. A kínai Saleae hellyel-közzel olvassa a 12 MHz-es jeleket, de néha a D+ és D- nem egyszerre vált és a frekvencia különbségek miatt pont elkaphatja a logikai jelanalizátor. Na ilyenkor értelmezhetetlen a csomag. Durván 5%-át a csomagoknak nem olvassa rendesen. Annyiból viszont tök jó, hogy a végére remélhetőleg képbe kerül az ember, hogy mi a halál történik egy USB buszon.
Ajánlom figyelmedbe az „ADC Modes> Dual_FastInterleaved” projectet!
STM32™’s ADC modes and their applications pdf: Bővebben: Link STM32F10x_AN3116_FW_V1.0.0: Bővebben: Link Valahól itt találtam: STM32 Standard Peripheral Libraries Expansions A hozzászólás módosítva: Ápr 7, 2017
Igen, ezt meg kellene valamikor lépni. Duplázni lehetne vele a frekvenciát.
Érdekes ez az USB, most jutottam el addig, hogy 833kHz-en már majdnem megbízhatóan megy. Durván 700 megabájtot átnyomtam hiba nélkül.
A probléma, hogy ekkora sebességnél PC oldalon le is kell szívni az adatokat. Milliszekundumonként 833 bájt ment át, a puffer 1600 bájtos volt. Ha egy szálon szívom az adatot és írom a fájlt, akkor a merevlemezeknél egy hard disk késleltetés kinyiffant mindent. Nem lehet az, hogy várjon az USB-s szál, mert nincs arra memória, hogy komolyabb kimaradást túléljen . Most 4096-os pufferrel próbálkozom, ez annyit tesz, hogy 4 ms-t él túl, ha az alkalmazás épp mással van elfoglalva. Ez sem túl bizalomgerjesztő, de meglátjuk mi lesz.
Ha ennyire fontos a sebesség, miért nem próbálkozol inkább a Cypress ez-usb cy7c68013a mikorovezérlővel/kártyával? Saleae logikai analizátor klónként milliszekundumonként 24 000 bájtot visz át a mostani 833 bájtod helyett.
Valamit nem ertek. PC-rol beszelsz, ahol a disk irasi sebessege 80..120 megabyte/s, a memoria mennyisege meg nagyjabol vegtelen. Ha problemat okoz < 1 megabyte/s atvetele, akkor ott valami nagyon nincs rendben.
Ü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?
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.
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.
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
Szia!
Milyen analizátorral nézed az USB forgalmat ?
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
OK, akkor ennyiért megéri !
Köszi az infót!
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
Ú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
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-.
|
Bejelentkezés
Hirdetés |