Fórum témák
» Több friss téma |
Üdv, mindenkinek !
Egy kis kedvcsináló ! Ajánlom a STM32F4xx elsajátitani és felhasználni. Üdv, Árpád
Csinos lett!
 A discovery-re pakoltad még rá a 74-eseket? Milyen bemeneti fokozatot használsz? A hozzászólás módosítva: Nov 8, 2012
Nagyon klassz!
Miért írtad a képre hogy FPGA SPARTAN nélkül?
A discovery az maradt mint F4discovery , a 74-esek a maketen vannak, a bemenet AD8056-n van
nem a legjobb mert csak kb.10-12Mohm a bemenetre ideálisabb az AD8065
Szia sargarigo
A soros átvitellel kapcsolatban, ha jó pár oldallal vissza lapozol ott találsz a bbatka és köztem elhangzott levélváltást. Ebben leírtam, hogy egy PIC-el, vélhetően egy mega8-al sem lehet többet átvinni, mint 9600bit/s. Ha a mega8-at kiegészíted egy FTDI USB csatolóval, amelyet az atmega8 SPI buszáról vezérelsz a 10-20 Megabit/s sebesség is elérhető (az SPI busz sebessége szabja meg). üdv. jano36
Én piccel már sokkal gyorsabban is kommunikáltam soros porton mint 9600bit/s.
Elvileg 115200 a felső határ. Legalább is a 18F-es családban általában. Én 19600-on próbálgattam/használtam, stabil volt.
Gondolom 19200-at akartál írni. Az írásom lényege az volt, hogy nem kilóbájtos sebességeket lehet elérni, hanem megabájtost.
Köszönöm a segítséget, de más volt a baj. A fejlesztőkörnyezet (c#) nem tudott átvenni nagyobb sebességet, mert széthullott a vétel. A pc programozásába nem akarok mélyebben belemenni, csak amennyire feltétlenül szükséges, ezért más úton indulok el újra. Van egy szép nagy lcd-m, azon fogom megjeleníteni az adatokat, aztán majd amikor sikerül működésre bírnom az sd-kártyát (ami fogalmam sincs hogy miért nem megy a www.roland-riegel.de-féle megoldással), akkor majd sd-re mentem az adatokat, és onnan többet is át tudok tenni a gépre vizsgálat céljából.
Milyen kábelt használtál, és milyen hosszan a soros adat továbbításához? Pic és rs232-es rész között milyen hardver volt?
Bizton állíthatom, hogy a c# jól kezeli a soros portot, persze ha jó a program. És a nagyobb sebesség sem okoz neki problémát.
Leírtam anno is, meg most is leírom: hardware flowcontrolt kell használni, és akkor nem fog elveszni egy byte sem. Ha pedig megfelelő pufferelést használtok, akkor még 115200-nál többet is össze lehet hozni.
A hozzászólás módosítva: Nov 12, 2012
Egy gyári telefonos adatkábelt használtam, kb 60 centi hosszan (az rs232 csatlakozóban benne van a gyári szintillesztő). Szkóppal már néztem, a jelalak jó.
Biztos vagyok benne hogy a "ha jó a program" a szűk keresztmetszet. Valahol a csatlakozó, és a programom között esett szét a dolog. Volt hogy átvett egy nagyobb mennyiségű adatot, aztán semmit, meg olyan is, hogy csak egy részét vette át, aztán semmit. Ebből gondoltam hogy a rendszer mélyebb bugyraiban vesztek el az adataim. Miután széttúrtam a netet a megoldás után, azt kellett találjam, hogy a legbiztosabb mód ha minden adatot soremeléssel zárok, és a vételi bufferből soremelésenként veszem ki őket szövegesen (azt már nem is mondom, hogy csak hét bites vételt tudtam kicsikarni belőle, mert a nyolcadik bit mindig elment valahova). Ez már atomstabil lett, csak lassú. Nyilván van valami sokkal jobb megoldás erre, de nem találtam normális példát arra, hogyan lehet 64k adatot egy blokkban átvenni (lehetőleg nyolc bites bináris módban). Minden példa csak egysoros szöveges parancsokat küldött, vett a terminálról. _vl_ kollégának igaza van abban, hogy a fizikai átvitelt törhetetlenné teszi a flow-control. Jelen pillanatban ez olyan opcióvá avanzsálódott vissza, hogy nagyon örülnék ha működne, de nem ettől teszem függővé a rendszert.
Kicsit jobban utánanéztem, és érdekes dolgokat találtam. A programodban hogyan oldottad meg az adatok vételét?
A hozzászólás módosítva: Nov 12, 2012
Én így oldottam meg a dolgot, ez az aktuális befagyasztott állapot. 800 adatot olvas be, sortörésekkel zárva, és az adatfolyam végét OK jelzi. Get_Data egy változó, amit az adatbeolvasó button állít be igazra. A try-catch párossal már nem is foglalkoztam, nem szabadna hogy szükség legyen rájuk.
A program optimális működéséhet kívánatos lenne, hogy 64k adatot is záros határidővel be tudjon olvasni. Te mit találtál, mit volt az az "érdekes" ? Ez itt már kezd off lenni, lehet hogy máshol kellene folytanunk.
A neten talált fórumtémákban sok helyen panaszkodtak ugyanarra mint te. Nekik is magasabb sebességen gondjuk volt a fogadással. De szinte minden esetben megoldódott a probléma.
A megoldást legtöbb esetben az jelentette, hogy az adatok vételét egy külön szálon kellett futtatni. Bővebben: Link Az oldalon alul van példa. A hozzászólás módosítva: Nov 12, 2012
A számítógép hardverkezelőjében a kommunikációs portnál a port beállítások között milyen a legnagyobb sebességérték?
Ez a forráskód használhatónak tűnik: Bővebben: Link
Használt már valamelyikőtök usb-t? Nem tudom mennyire lesz ez itt off, de találtam egy ilyen oldalt, ami úgy tűnik nagyon kulcsrakész megoldást kínál a megbízható adatátvitelre. Tapasztalat esetleg?
Csak mert lenne kérdés
Szia sárgarigo Szia sirály12
sirály12 látom nagy híve vagy a soros adatátvitelnek, de lásd be a klasszikus soros adatátvitel történelmileg a párhuzamos adatátvitelt váltotta le, noha a párhuzamos gyorsabb átvitelű volt, de csak rövid vezetékhosszon volt használható. Nem vitatom, hogy elérhető a 115kbit/s sebesség, de az már nem megbizható. A PIC ICD1 19200-as sebességgel működött (PIC16F876), bbatka a PIC18F240 ? el sem ment e fölé. Emlékeztetnélek a korszerű számítógépeknél nem véletlenül szüntették meg a soros portot. sárgarigo az általad kérdezett AVR-es USB port, tulajdonképpen egy RS232_USB átalakító. Ezt az átalakítót arra találták ki, hogy a hagyományos soros portos eszközöket és a csak USB porttal rendelkező eszközöket össze lehessen kapcsolni. Az átviteli sebességet a soros port határozza meg (nem érvényesül az USB sebessége). Noha ezt már korábban leírtam, de megismétlem. Egy 16MHzes AVR-t figyelembe véve, az AVR SPI buszát használva 16/4 4Mbit/s-os sebesség érhető el, ez a 115kbit/s-hoz képest ~35ször nagyobb sebességű átvitelt eredményez.
Sziasztok!
"Egy 16MHzes AVR-t figyelembe véve, az AVR SPI buszát használva 16/4 4Mbit/s-os sebesség érhető el, ez a 115kbit/s-hoz képest ~35ször nagyobb sebességű átvitelt eredményez." És persze a fejlesztőkörnyezet is támogatja. Sajnos nem szokta. Általában a 115200baud szabványos mind PIC és PC oldalról, ezért használom én is ezt az új projektemnél. USB-UART átalakítónak MCP2200-at használok.
Namost amit én linkeltem, az pont arról szól, hogy HID módban dolgozik a drága, tehát nem soros portként. Pont a soros portot akarom kiküszöbölni, mert fentebb látszik, hogy jópár évet öregedtem már miatta, konkrét eredmény nélkül, megbízhatatlan lett. Tudom hogy van usb-soros átalakító megoldás is, de akkor egy ftdi chipet használnék és kész.
Nekem pont az kellene, hogy natívan át tudjak tolni 64k-t a pc-re, ami azt stabilan meg is fogja, és usb-n megy, hogy a mostani gépekkel használható legyen. A linken szereplő projekt ezt megcsinálja, és látszik, hogy páran már csináltak sok jó dolgot belőle. Sajnos pont a digiszkóp firmware-e elavult linken van, de ennek majd nekifutok mégegyszer. Ha, és csakis akkor ha ezt sikerül tető alá hozni, akkor újra előkeresem a már eddig megvalósított részeket (amit dühömben egy atlétát megszégyenítő lendülettel vágtam be a sarokba). A hozzászólás módosítva: Dec 10, 2012
Konkrétan ezt szeretném mintának használni. Ha erre jók a beállítások, akkor az enyémhez is jók lesznek remélem. Csak az a fránya url ha működne..
Vagy tud valaki másik működő dolgot amiből ki lehetne indulni? A hozzászólás módosítva: Dec 10, 2012
Megfordult nekem is a fejemben hogy HID módban PIC-et használok. Egyelőre úgy döntöttem hogy átírom a programomat VB.NET-re. Ha gondok lesznek továbbra is akkor nekem sem lesz más választásom mint mélyen bele ásni magam az USB-be. Maradok a PIC-ek világában.
A példák amiket belinkeltél PC oldalról , jól jöhetnek nekem is. Megjegyzem az USB-UART átalakítókkal súlyos problémáim van XP alatt. Minden rádugáskor új számozású eszközként jelennek meg. Kilőni a nem lezártakat lehetetlen. Egyetlen megoldás a gép újraindítása. A hozzászólás módosítva: Dec 10, 2012
Megnyugtat a dolog, hogy nem csak nekem vannak ezzel problémáim. Kicsit olyan érzésem van ezzel kapcsolatban, mintha ceruzával akarnék fogat piszkálni. Végülis lehet.., de azért valahogy nem az igazi. Egyébként a HID megismerése már önmagában sem egy rossz dolog, csak annyira szerteágazó, hogy fogalmam sincs merről kezdjek neki. Valami magyar leírás jól jönne, mert az angolom.. khm.. szóval nem éppen több száz oldalas doksikra van teremtve.
Érdemes Watt oldalán körbe nézni és a cikkek között. Emlékszem Gory-nak is jó a cikke.
lásd. Ez a PIC-es vonal. A hozzászólás módosítva: Dec 10, 2012
Igen, ezt olvastam, és tetszett is!
De egy ismeretlen rendszert átportolni egy ismeretlen vezérlőről... Ha már vannak készen is, akkor inkább az elméletével ismerkednék meg, nem akarom újra feltalálni a spanyol viaszt.
Szia sargarigo
Ha a mellékelt ábra szerinti kapcsolásra gondolsz, az engem igazol, mivel az USB D+-D- a Tiny ISP portjára csatlakozik. Nem a soros portra. Szia bbatka Szenvedj az RS232vel. A jelen az USB. Emlékeztetlek, vannak USB portos PICek pl. PIC32, PIC18F4550. Igaz szerinted a PIC32 nem egy gyors IC. KillBill szerint is nagyon gyors.
Szia!
Tegyük helyre a dolgokat. Nem RS232-öt használok hanem MCP2200 USB-UART illesztőt VCP módban. A VB-nek a soros komponense ezt tudja kezelni. Tudtommal a HID kapcsolatot nem. Az MCP2200 -ra visszatérve akár HID módban is használható csak a driverét VB-ből valahogy kezelni kell. Az is lehet hogy létezik hozzá HID komponens, de ilyennel még nem találkoztam. Jelenleg a VB.NET-el még csak ismerkedek. Nem egyszerű. Ezen belül is a DirectX9 grafikus kártya programozás példáit bújom és a grafikus programozás matek részével kapcsolatos anyagokat tanulmányozgatok. Ez jelenleg épp eléggé leköt. A HID most egyelőre nem hiányzik. A PIC32 sebességét nem kell túlbecsülni. A leggyorsabbaké 80MIPS átlagosan 32bites adatokkal. Ez nagyban attól függ hogy épp melyik utasítást hajtja végre. Az I/O lábkezelési sebessége a 40MIPS sebességű dsPIC-el van egy szinten. RAM címzésre, A/D órajel előállításra lassú. A beépített hardverek sebessége természetesen ettől független. (USB) Egyébként a rengeteg előre össze vásárolt PIC-em között van 3db.18F4550 2db.18F2550 és egyéb USB-t kezelő dsPIC, PIC32-öm, de mindig csak akkora fába vágom a fejszém amivel úgy gondolom el is bírok.  De most tanulmányozgatom a DirectX programozási példákat tovább.
Nem értem, hogy miben kellene igazolást nyerni azáltal, hogy melyik kivezetésre van kötve a D+-. A PIC-el ellentétben az avr-es usb-t szoftveresen csinálják (tisztelet a kivételnek), tehát édes mindegy hogy melyik kivezetésre van kötve. Az tény, hogy lehetséges USB-s UART-ot is csinálni, és ezt lehet a V-USB -vel is. De ez nem jelenti azt, hogy csak így lehet, és hogy a HID ki van zárva.
Egyébként minek bbatkával is kekeckedni? Megoldást szeretnénk találni egy problémára, nem pedig hitvitába bonyolódni arról, hogy melyik a jobb vezérlő, vagy melyik a jobb csatolási forma. A maga helyén mindegyik jó! |
Bejelentkezés
Hirdetés |
