Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Szia, talán ez az ábra segít a helyes bekötésben.
Ezután az arduino IDE-vel usb-n keresztül már mennie kéne a programozásnak. Habár ez nem CH340G chippel van szerelve de ugye te sem azzal szereled.
Az RS232 egy szabvány, mindegy hogy mi állítja elő.
A reset gombot se kell nyomkodni neki? Lehet inkább várok amíg megjön, mert rendeltem ardurrantot.
Sziasztok!
Egy kis problémán támadt egy Arduino-ra +Windows-ra írt programmal. Ez egy kész mások által már megépített működő projekt nálam viszont nem működik. Konkrétan erről lenne szó Project Hogy kerek legyen a történet: Én nem Mega-t használtam hanem Nano-t, más típúsúak a szenzorok de ez nem hiszem hogy most problémát jelent hiszen ugyan azokra az analóg bemenetekre kötöttem őket. És akkor a problémám lényege..A Nano-ra simán fel tudom rakni a programot soros monitoron még kommunikálni is tudok. Viszont valamiért Visual Studioban elindítva a "fogadó programot" nem kapok tőle csak egy ilyen "TBS unit is plugged in before starting this application"üzenetet. Nem akartam oda a fórumra írogatni mert már egy másik srác is küzdött ott vele de nem oldódott meg. Ezt a részét próbáltam állítani én is if (portName.Length > 4) // skip COM5" sőt feljebb állítottam 15-re az eszközkezelőben a ch340 soros port számát de nem hozott eredményt. Lehet valami különbség a Nano és a Mega között soros kommunikáció terén hogy nem látja a program? Már az is segítség lenne ha kipróbálná valaki a programot egy Mega-val.. Köszönöm a segítséget! üdv.
Nem ismerem a program működését, de a kiírt üzenet azt mondja, hogy a TBS egységed be volt dugva, mielőtt elindítottad a programot. Próbáld meg esetleg fordított sorrendben. Elindítod a progit, majd csatlakozatod az eszkört.
A helyzet ugyanaz sajnos..
A hozzászólás módosítva: Ápr 27, 2016
Beleolvastam egy kicsit a programba. Próbáltad más bitrátával? Lehet, hogy a ch340-es illesztőnek sok a 19200. Próbáldd meg az alap 9600-al, hátha.
Igen úgy is próbáltam már de Arduino soros monitorán keresztül is tud 19200-al kommunikálni.
Ha viszont a gép tud kommunikálni az arduinoval, de a progi nem tud, akkor nem HW oldalon van a gond, hanem Windowséknál. A programot próbáltad rendszergazdiként futtatni?
Egyenlőre csak fejlesztőkörnyezetből indítottam el visual studion belül mert még nem tudom hogyan lehet egy önálloan működő programot csinálni belőle amit lehet hordozni akár pendrive-on..így nem látom értelmét hogy most rendszergazdaként futtatom vagy sem. A tűzfalon engedélyezve van a teljes kommunikációja a visual studionak.
Akkor nincs ötletem. Ha viszont a géppel kommunikál az arduino, akkor biztos, hogy a probláma nem HW szinten lesz.
BaudRate-t 19200, 16MHz = 0.16 %ERR
Állítsd inkább a BaudRate-t 31250-re, mindkét helyen! Mert 16MHz-en akkor 0.00 az %ERR hiba ráta. Hátha bejön!
Még lehett hiba a kódban:
Nem kell nyomkodni a reset gombot a programozásához! Azt csak akkor kell nyomkodni ha azt akarod hogy újrainduljon az arduino.
Üdv!
Végre működik a műszerem csak egy hibát vettem észre. Ha csatlakoztatva van a gépre usb-n keresztül akkor miért mutat más értéket mint amikor simán külső tápról járatom? Ha usb a gépen van akkor tök jó értéket mutat, de viszont ha leveszem a gépről akkor dupla annyit jelez ki ez normális?
a külső táp teljesen stabil feszültséget ad neki?
És működik!
Hálás köszönet, mindkettőtöknek még lehet hogy fogok írni mert az én szenzoraim eleve magasabb értéken indulnak és azt hiszem ez nyomás csökkenésre csökkenti a feszültséget az eredeti meg pont fordítva...megpróbálom megoldani ha nem sikerül kérdezek még...
Most viszont a következő a probléma a program is és a soros monitorból is indítva overrun-ra hibát ír ha mind a 4db bemenetet lehúzom testre akkor rendben tehát az én senzorom alap légnyomáson magasabb értéket adhat és ez nem tetszik neki de nem igazodom el az arduino kódban hogy hol mit kellene átírnom.
Sziasztok, így az őrület határán lenne egy kérdésem hozzátok. EPROM-ot olvasok ki, amíg kiíratom a bájtokat egyenként hexába semmi gond nincs. Megvan minden bájt 0-tól 0x1FFFF-ig. Amint hexa helyett ASCII-ben mentem a logot (binárist csinálnék) egy csomó bájt eltűnik. A képen bekereteztem a különbségeket a két log között. Eleinte semmi gond (egészen 0x8000 címig) amíg minden bájt 0xC3. Eddig teljesen egyforma a hex log és az ascii log. Amint bejönnek más hexa értékek is elkezd válogatós lenni, pl minden 0x55 hiányzik, minden 0x3C, 0x6E, 0x30, 0x32, 0x33, 0x4C, 0x6E... nemkerestem ki hogy mik nincsenek meg a 0x00-0xFF tartományból de elég sok minden. Az ascii filet ha megnyitom notepadben és megnézem hány karakter van benne (minden karakter 1 bájt ugye) akkor bizony 131071 (0x1FFFF) helyett csak 108759 (0x1A8D7) karakter van benne. Miért nem bírja elmenteni az összes karaktert? A könnyebb olvashatóság kedvéért a képen az ascii file-t is hexa nézetben mutatom.
Még annyi hogy ezek a logok PuTTy-al készültek de letöltöttem egy "Soros Port Monitor" nevű csilli villi progit de az is ugyan ezt csinálja. A hozzászólás módosítva: Ápr 28, 2016
A soros kommunikációt nem bináris adatok küldésére találták ki. Az átvitelhez valami olyan protokollt használj, ami csupán nyomtatható karaktereket küld! Pl. Intel HEX formátum, Kermit protocol, stb.
Érdekes, mert a hiányzó byte-ok között bőven van nyomtatható karakter, viszont átvitt nem nyomtathatókat is. A soros kommunikációval átvihető bináris adat (tulajdonképpen minden bináris eleve), pl, akár futtatható kód is, itt viszont tényleg fura a működés...
A 0xC3 az 0b11000011, ezt jól veszi (itt elég nehéz is kiesni szinkronból), utána a 0x55-ből az inverze, 0xAA lesz, ez binárisan 0b01010101 --> 0b10101010, mintha csúszna egy bitidőt, onnan szét is esik az egész. Nem biztos, hogy az ASCII lesz a gond, de a forrás nélkül csak ez a hiba tűnik fel. A kevesebb adat is azt támasztja alá, hogy a szinkron szétesik.
Konkrétan melyik laphoz?
Milyen célból? Mit szeretnél vele csinálni? Mono, vagy színes? Ha csak Menüvezérlést? Jók a SPI vezérlősek. Ha grafikai alkalmazás? Inkább 8 – 16 bites port vezérlés a gyorsabb.
Sziasztok továbbra sem tudom mi a fene történik viszont csináltam egy tesztet: lelassítottam az adatok kiírását annyira hogy szemmel követhető legyen, kb 1bájt/0.1sec és látható volt hogy a konzol visszaugrik a soron belül és felülírja amit addig kiírt, tehát mint ha feldolgozná a megjelenő adatot és nem csak kiírja/elmenti azt. Nagyon fura! Ráadásul nem csak a putty konzoljánál van ez így hanem a "Soros Port Monitor" program is ezt csinálja. Puttynál még azt is megfigyeltem hogy bizonyos karaktereknél a beépített hangszóró pittyen egyet, ez is csak azt erősíti meg bennem hogy a bejövő adatot a terminál értelmezi és hülyeségeket csinál miatta. Pl visszább megy a sorban, van hogy felfelé is is ugrik mint ha a felfele nyilat nyomkodnám... Nem értem de tényleg! Most azt fogom kipróbálni hogy csak egyetlen adatot olvasok ki, olyat amit eddig nem jelenített meg. Akkor nem tudja felülírni. Persze ha hexában íratom ki a bájtokat akkor semmi gond... Viszont én .bin fájlt akarok csinálni mint kimenet de lehet az lesz a vége hogy a hexával kell dolgoznom, írni rá egy progit ami átalakítja a logot binárissá. Azt jól gondolom hogy a .bin fájlban habár krix krax karakterek vannak de ott egy karakter egy bájtot reprezentál? Valami olyasmi kimenetet szeretnék amit egy gyári eeprom olvasó is produkál, illetve egy eeprom író fel tud nyalni.
Szia! Lehet, hogy érdemes lenne egy normálisabb programmal is kísérletezned.... Például A Hterm-el.
Elöször talán az alapokat kellene mgtanulnod!
Bővebben: Az ASCII kódtábla A hozzászólás módosítva: Ápr 29, 2016
Ehez hasonlo tipust keres:
Touch Screen Shield for Arduino UNO |
Bejelentkezés
Hirdetés |