Fórum témák
» Több friss téma |
Ezek a fájlok, nem tudom melyikben kellene nézni.
Köszönöm a segítséget.
A Firmware.mcp -ben: C18 fordító.
Idézet: „De akkor a terminál programban miért nincs ott a STOP bit?” A STOP bit természetesen ott van (különben nem működne a vétel), csak nincs extra szünet, mert nyilván hatékonyabb a kiküldés módja. De ha - képletesen szólva - "fél óra" szünet van a két karakter között, akkor is működnie kellene. Szerintem nem ez a hiba oka.
Mindkét képen ott van a stop bit. Annyi a különbség hogy az első esetben (a) a két byte között nincs szünet, míg a másodiknál (b) 1 bit szünet van.
a: --S00101010PS10110000P-- b: --S00101010P-S10110000P-- Az feltűnt neked hogy a szkópon az első esetben 20us az osztás, míg a másodikban 200us? (...vagyis a két adatsebesség nagyon nem egyezik.)
Ha látod akkor mi a probléma? A PIC hány MHz-en jár? Egyáltalán képes ezt a sebességet kis hibaszázalékkal előállítani? Kösd össze a PIC-et a PC-vel és kisebb sebességen (9600) próbáld meg elküldeni az adatot.
Idézet: „Az feltűnt neked hogy a szkópon az első esetben 20us az osztás, míg a másodikban 200us?” Az egyik helyzet a trigger állapotot mutatja a Pic-el, mert folyamatos a küldés, a másik pedig a terminál programot, amit egyszer küldök, tehát Single Seq módban van a szkóp. Az osztás különbség miatt csak növekszik a kijelzés mérete/felbontása...
Na, ezt most nem értem.
Én azt veszem ki a képekből, hogy az elsőnél kb. 115200 Baud a kommunikáció sebessége, míg a másodiknál kb. 14400 Baud. A hozzászólás módosítva: Feb 12, 2016
Szia
Gyorsan átfutva a dolgot, nekem a következő tűnik fel: (ha rosszul számoltam előre is elnézést  115 kbps sebességet állítottál be, ez 8 microsec körüli bitidőt ad A stop bit közepén vált vissza a TRMT flag, azaz a stop bit végéig 4 microsec marad A chip ezalatt 1-16 utasítást hajt végre, órajelfüggően. Nem lehet, hogy a 2. bit egyszerűen a processzor programideje? Próbának állíts lassabb baud rate-t, ha akkor kezd "helyre jönni" akkor ez az oka. Az oszcilloszkóp képén ugyan valami teljesen más látszik, úgyhogy valami nem teljesen kerek. A hozzászólás módosítva: Feb 12, 2016
Én zárójelben még azt is furcsállom, hogy a 2. byte 0x0B, mindkét esetben, az első "T" betű, az oké (bár ezek szerint ez nem releváns).
Egyébként ahogy már a többiek is írták, a PC baudja a szkóp ábra szerint 14400bps körül van? Mekkora kaviccsal ketyeg a PIC? Illetve szerintem először azt kéne megcsinálni, hogy ugyanolyan baud legyen a PIC mint a PC. A két byte közötti +1 bit a PC-nél kerül be, ez esetben ahogy már írták, nem kéne hogy hibát okozzon a hiánya, hacsak nem páros paritás van beállítva, vagy hasonló huncutság. Én arra tippelnék, hogy túl nagy a PIC baud és/vagy nem elég pontos.
Szia
a programodban nem 115200 baudot állítottál? Legalábbis fent ezt látom. Ez meg 8 MHz-s órajellel eleve nem menne A plusz egy high biten persze nem múlhat az átvitel Én egyébként a b képeden kb 3200 baudot olvastam le, ha a 200 uSec a képernyőn a vízszintes tengelyen két marker távolságának értendő. A hozzászólás módosítva: Feb 13, 2016
A belső oszci pontossága elég rossz, ráaádásul a 8MHz sem kedvez a baudrate-nak. Mindenképpen külső kvarcot használj, 9.216MHz vagy 11.0592MHz-et!
Tegnap már nagyon este volt, elnéztem, valóban a PC-ESP között van a 115200... Nade. Ha a fent használt kvarcok valamelyikét használod, akkor beállíthatod a baudot a PIC-en 115200-ra, mert ezeknél a frekiknél 0%-ra jön ki a bauderror, azaz szinte csak a kvarc pontosságától függ a baudrate pontossága. Szerintem először ezt kéne meglépni. A hozzászólás módosítva: Feb 13, 2016
A belső oszcillátort nem kellene kritizálni. Egy órához valóban nem elég, de egy soros kapcsolathoz még 115kBd sebességhez is elegendő. Egy eset lehetséges, ha az OSCCAL össze van firkálva, akkor tényleg durva lesz a helyzet.
Ha mégis azzal lesz a gebasz, jösz egy sörrel!
 Bár szerintem se azzal lesz, de azért lehetőleg zárjunk ki minden hibalehetőséget..
Amikor a hozzászólást írtam, még a MÁV is szóbakerült. Mindenesetre egy ilyen durva hiba, hogy semmilyen reakciót nem vált ki a kliensből, tényleg csak elbarmolt beállításnál lehetséges.
Komoly dolgokkal nem viccelünk. Ha egyszer összefutunk, lehet szó egy sörről, de nem mint fogadás tárgya.
Szia
nedudgi-nak igaza van, a belső osci 48 MHz-en tudna talán kellő pontosságot adni, de ezt meg a c linkeden lévő UART_Init nem kezeli jól. (x-re 5-öt számol, amit aztán hagy LowBaudRate-ként kezelni, pedig itt hellene High BaudRate-re váltani csak igazán)
Abszolút komolyan írtam. A MÁV-ot azért szedtem ki, mert nem akartam senki lelkébe belegyalogolni, csak 7 év bejárásból egy jó néhány órát/napot eltöltöttem várakozással...
A PC és az PIC között 9600-as sebességen jó lett az adatátvitel? Mert ha igen akkor egyszerűen állítsd be az ESP8266-on az átviteli sebességet 9600-ra, és küldheted neki az adatokat.
10Mhz-es kvarcom van azzal estére ki tudom próbálni. Beszámolok majd az eredményről. Addig is köszönöm mindenkinek az eddigi segítségeket!
Ha ez lehetséges (még nem találkoztam ezzel az AT paranccsal), nekifutok ennek is. Köszönöm!
Szia
10 MHz nem lesz jó, szerintem 150kbps körüli értéket fog adni. 11.0592 azért ilyen fura, mert egész számokkal osztogatva pont kijön a 115200 bps. 48 MHz is jó. A PIC adattábláján meg lehet nézni, milyen oszillátorfrekvencia milyen beállítások mellett mekkora bps-értéket produkál és az mekkora hibát jelent.
Azt sajnos már csak jövő héten tudom beszerezni...
 Arra a táblázatra nem emlékszem, pedig párszor már átnyálaztam az adatlapot, de mindenképpen utánanézek. Újdonság nekem ez a UART kommunikáció, a pic többi funkcióját már 1000x használtam, de ez kimaradt. Köszi
Ellenőriznéd a PIC-ESP kommunikáció sebességét, mert szerintem 8-ad része az előírtnak? Talán a programodban hibásan van megadva az oszcillátorsebesség és a fordító abból számol BAUD-ot - hibásan. Az ESP8266 doksijában 115200-at adnak meg, tehát attól nem kellene eltérni.
Nálam az Espressif firmware-nál "AT+UART=9600,8,1,0,0" paranccsal tudtam beállítani a sebességet.
Így van megadva a programban az oszcillátor sebessége:
Frissítettem a firmware-t Topi cikke alapján (az ott megadott bin fájlal), és ez már gyárilag 9600-ra van állítva. A PICel még sajnos nem tudtam ellenőrizni a kommunikációt, de USB-vel már 9600-on megy.
A hozzászólás módosítva: Feb 13, 2016
CONFIG1H regiszter?
Egyébként ajánlott minél magasabb frekvenciát használni. Használd a PLL módot! Először azt érd el, hogy a PIC tényleg az általad kívánt frekvencián menjen! Minden további beállítás csak ezután jöhet. A hozzászólás módosítva: Feb 13, 2016
Segítene valaki?
Nem tudok 761 oldalt végignézni. Egy legegyszerűbb, programozót PIC 12F508/509 és 12F675 kellene összebarkácsolnom. Mindegy, hogy RS-232 vagy LPT portra csak ismerjék a free programozó programok. IC nélküli kellene, néhány BC212-esem van itthon csak. A kismillió kapcsolás között a neten találok invertálót meg sima 1:1-es bekötésűt - nem tudom miért és melyiknek higgyek. Egy link is elég lenne. +5 és +12 van a PC-ben, tehát ha tápos az sem baj. Csak minél kevesebb alkatrészt kelljen forrasztgatni.
Nem kell elkapkodni
Egyébként a Microchip PIC18(L)F1XK22 adatlap 188. oldalán vannak a baud rate beállítás infói. Ha az ESP8266-en lejjebb tudsz menni, akkor könnyen találsz meglevő belső órajelhez passzoló sebességet. A BRGH értékét a te általad a "c" hivatkozásban szereplő rutin szerintem pont rosszul állítja, de ezt felül is írhatod. Ha lassabban jól megy, lehet gyorsítani. Addigra már annyi tudásod lesz, hogy ez gyerekjáték. Egyébként tényleg az UART_Init(115200) utasítással állítod 115 k-ra az átvitelt? Az amit a szkópon láttam köszönőviszonyban nincs ezzel. A hozzászólás módosítva: Feb 13, 2016
|
Bejelentkezés
Hirdetés |
