OK Mégsem
Fórum témák

» Több friss téma
Fórum » GPS házilag
GPS házilag
 
Témaindító: pakibec, idő: Júl 24, 2006
Témakörök:
Lapozás: OK   5 / 15
(#) proci válasza bladika hozzászólására (») Jún 23, 2009 /
 
Kösz a tippet akkor valószínű így lesz a dolog...
De sajnos az UART még mindig nem működik, rádugtam a Pickit2-re logiaki analizátor módban a Pic-et és a 38400baud-on az első sor megérkezék és utána a következő sorokoból már csak töredékek, néhány mp után pedig az egész adat összevissza karakterekből áll... Ez lehet az miatt mert ilyen nagy sebességhez már külső precíz órajel kell?
(#) bladika válasza proci hozzászólására (») Jún 23, 2009 /
 
Kétlem! Ott valami más gond lesz!
(#) SASA11 válasza pakibec hozzászólására (») Jún 23, 2009 /
 
Szia .
Itt találsz komplett leírást a megépítésre!
http://www.astlab.hu/gn200/gn200main.html
(#) bladika válasza SASA11 hozzászólására (») Jún 23, 2009 /
 
Válaszoltál egy 2006os kérdésre! Velem is előfordult már, hogy elkezdtem olvasni és gondolkodni, hogy mi lehet a megoldás és csak utána vettem észre, hogy a dolog 35oldallal tovább haladt már!
(#) pici válasza proci hozzászólására (») Jún 23, 2009 /
 
Nekem is volt már ilyen gondom, megjött az NMEA sor és elkezdtem feldolgozni, de nem végzett mire jött a következő.
A $GPGSV az 3 sor és egyszerre jön le...
Nincs idő az 1. és 2. sor között fel is dolgozni PIC-el.
(#) bladika válasza pici hozzászólására (») Jún 24, 2009 /
 
Mert nem is kell rögtön feldogozni! Én azt csináltam, hogy miközben jött a NEMA mondat, az elején beazonosítottam, hogy melyik az pl "$PGRMV,x,x,x*hh"
A $-ből tudom, hogy új mondat
Az első vesszőig tudom, hogy a mondat azonosító
Utána számolom a vesszőket és rögtön írom memóriába a szükséges adat előtti vessző után mindent a következő vesszőig.
-ből tudom, hogy vége a mondatnak.

Miután megérkezett az utolsó mondat záró karaktere tiltom az adat fogadást és feldolgozom az előtte memóriába mentett adatokat.

Nálam állítható volt a NEMA mondat csoportok küldése közt eltelt idő. Assszem én felemeltem pár másodpercre.
(#) bladika válasza pici hozzászólására (») Jún 24, 2009 /
 
De egyébként ő nem azt mondja, hogy meg sem érkeznek neki a karakterek helyesen egy idő után? Csinál ő már egyáltalán bármi feldolgozást?
(#) bladika válasza pici hozzászólására (») Jún 24, 2009 /
 
Bocsánat igazad van! Nem volt ma még erőm, hogy átbogarásszam a forráskódját mit is csinál!
(#) proci válasza bladika hozzászólására (») Jún 24, 2009 /
 
Hmm.. lehet kicsit pontatlan voltam...
rádugtam a pickit2-t logikai analizátor módban a GPS-re => működött, adta az NMEA mondatokat
összekapcsolva a fogadó PIC-el => nem működött
ekkor jött az ötlet, hogy felprogramozok egy másik f690-est, szimulálva a GPS-t, hogy adjon ő is egy NMEA mondatot 38400baud-al
A kódja így nézett ki:
  1. char uart_rd[] = "$GPGGA,152859.898,4040.5060,N,01040.7080,E,1,05,2.3,100.0,M,41.4,M,,0000*25\r\n";
  2. int i=0;
  3. void main() {
  4.   ANSEL  = 0;                     // Configure AN pins as digital
  5.   ANSELH = 0;
  6.   C1ON_bit = 0;                   // Disable comparators
  7.   C2ON_bit = 0;
  8.  
  9.   UART1_Init(38400);               // Initialize UART module at 38400 bps
  10.   Delay_ms(100);                  // Wait for UART module to stabilize
  11.   while (1) {                     // Endless loop
  12.     {     // If data is received,
  13.       UART1_Write_Text(uart_rd);       //   and send data via UART
  14.       Delay_ms(100);
  15.     }
  16.   }
  17. }

ezt rákötöttem megintcsak a pickit2-re és első sor megjött, a többi meg folyamatosan 'pusztult' le, a végén már az egész adat összevisszaság lett
Ebből arra következtetek, hogy
1) vagy a mikroC PRO for PIC compiler UART kezelője rossz, így ha nem képes normálisan átküldeni, akkor fogadni sem képes a GPS szabványosan megérkező adatait
2) vagy én írtam hülyén a programot
3) vagy valami más...
(#) pici válasza proci hozzászólására (») Jún 24, 2009 /
 
A kvarc freki se mindegy.
Én uartos fejledztéseknél mindig baudos kvarcot használok, ugyan annyiért lehet kapni.
11.059.200
14.745.600
18.432.000
22.118.400
...
Ezek pont baudos kvarcok, a hibaszázalék 0!
(#) proba válasza proci hozzászólására (») Jún 24, 2009 /
 
Számítógépes kommonikációnál azt is jártam már meg ,hogy a pic amikor nem adott elengedte a lábait .A vevő ezzel nem tudott mit kezdeni így a kommunikáció káoszba fulladt.
(#) proci válasza pici hozzászólására (») Jún 24, 2009 /
 
Hát igen, csak a PICkit2-be is egy sima JWT20.000 Mhz kvarc van.
(#) proci válasza proci hozzászólására (») Jún 24, 2009 /
 
Az nem lehet, hogy mivel egyszerre 5sort küld a GPS felülírja a pufferbe az adatokat mielőtt feldolgoznám?
(#) pici válasza proci hozzászólására (») Jún 24, 2009 /
 
olvasd el a #460131-es beirást
Ha jól van beállítva, akkor max 3 sor, de a leghosszabbak.
(#) proci válasza pici hozzászólására (») Jún 24, 2009 /
 
Amit bemásoltam kód egy weboldalról lett lementve ahol a csávónak működött a GPS-el, nekem viszont az első néhány karaktert sem hajlandó beolvasni, a kód végére én még odatettem annyit, hogy az RX beérkező adatot tegye át egyből a tx-re oda rákötöttem logikai anaizátor és teljesen jó volt mind az 5sort láttam az UART toolba, viszont az LCD kijelzőn csak összeveissza karakterek láthatók, nemhiszem hogy ennyire különbözne egymástol egy pic16f690 és egy pic18f4550, mindekttőnek ugyanazt a kódot kéne végrehajtania... Mindegy....
(#) bladika válasza proci hozzászólására (») Jún 24, 2009 /
 
Na viszont innentől nem mindegy az az órajel! Kérdés ahonnan szedted a forrást ott mekkora órajelen ment a PIC! Ugyanis ha jól tudom a tied max 20Mhz-ről mehet (de te 8Mhz-en járatod most!) ellenben egy 18f4550 akár 48Mhz-ről is mehet! Nem kis különbség!

Mi az a link egyébként ahonnan szedted?
(#) proci válasza bladika hozzászólására (») Jún 24, 2009 /
 
8Mhz-ről ment mindkét projektben...

a forrás:
Bővebben: Link
ez sem megy
és ez sem:
Bővebben: Link

azt hiszem repül a kukába a 690-es egyik sem megy rajta íg valszeg nem képes ennek a gps dolognak a meghajtására... tudtok ajánlani vmi jobb 20lábú pic-et erre a dologra? (a helytakarékosság miatt kellene 20lábú )

Hivatkozásokat légy szíves a "LINK" gombot használva beszúrni, a másolgatást senki sem szereti. Javítottam.
-- kobold
(#) potyo válasza proci hozzászólására (») Jún 24, 2009 /
 
8MHz-en ne lenne képes feldolgozni egy 38400bps-en bejövő jelet egy kontroller? Na ne szórakozz már... Inkább a hibát kellene megtalálni! A hiba lehet a fordító beépített rutinjában is!
(#) proba válasza proci hozzászólására (») Jún 24, 2009 /
 
Ha a bemenetet visszafordítva a kimenetre mindent jól látsz akkor az adatfeldolgozásban keresd a hibát szerintem.(a koordinátákat az enyém 4800 bauddal küldi ,csak ha extrákat akarsz akkor kell a nagyobb sebességű módba kapcsolnod,a 4800 baudot meg aztán végképp tudnia kell.)
(#) proci válasza proba hozzászólására (») Jún 25, 2009 /
 
A modul alapól 38400-on ad, biztos van valami input message amivel fékezni lehet, ha végképp nem működik akkor lelassítom ...

potyo:
az egyik .c fájlt a mikroC 8.0.0.0-val a másikat a mikroC for PIC 2009-el fordítottam, és a vicc az, hogy a szimulátorban (Proteus) működik, szóval a kód szerintem 99.9%-ban jó. És lehet hogy a fordítóban van a hiba, történetesen a 690-eseket nem komálja. Megpróbálom egy 877-esel, bár az erre a célra pazarlás... és ha azzal sem megy akkor én vagyok a lúzer....

Ja, bocs a linkért...
(#) proci válasza proci hozzászólására (») Jún 26, 2009 /
 
Nos ez történik ha a sorvége karakterig beolvastatom az RX vonalon az adatot és kiratom az LCD-re. De ha viszont az RX-ről a TX-re irányítom akkor tökéletesen átküldi, nem tudom mi lehet a probléma, szóval ha tudtok valami működő forráskódot mikroC 8.0 vagy CCS C-ben at nagyon megköszönném Neten már mindehol körbenéztem de mindegyik a "nagy" (877, 18F4550 stb.) PIC-ekre van.

GPGGA.jpg		    
(#) potyo válasza proci hozzászólására (») Jún 26, 2009 /
 
Ez nekem eléggé memóriaszemétnek tűnik. Talán nemjó memóriabank kerül kiválasztásra olvasáskor illetve íráskor? A 877-es forráskódja nem jó a 690-hez? Nem ugyanolyan az UART moduljuk?
(#) kobold válasza proci hozzászólására (») Jún 26, 2009 /
 
876-ra van itt valami, hátha segít...
(#) pici válasza proci hozzászólására (») Jún 27, 2009 /
 
Egyszerű a dolog.
Az LCD-re kiküldött adat ideje nagyon hosszú.
Az RX 1 byteja kiküldve a TX-re ugyan annyi idő és nincs szünet, csak 1 byte késleltetés.
Amíg az LCD-re küldesz, addig áll a forgalom...
Megszakításból csinálod? Azzal kellene...
(#) proci válasza pici hozzászólására (») Jún 27, 2009 /
 
Na, átírtam megszakításosra íme:
  1. char NMEA[80];
  2. char *string;
  3. int i;
  4. unsigned short ready;
  5.  
  6. sbit LCD_RS at RC2_bit;
  7. sbit LCD_EN at RC3_bit;
  8. sbit LCD_D4 at RC4_bit;
  9. sbit LCD_D5 at RC5_bit;
  10. sbit LCD_D6 at RC6_bit;
  11. sbit LCD_D7 at RC7_bit;
  12.  
  13. sbit LCD_RS_Direction at TRISC2_bit;
  14. sbit LCD_EN_Direction at TRISC3_bit;
  15. sbit LCD_D4_Direction at TRISC4_bit;
  16. sbit LCD_D5_Direction at TRISC5_bit;
  17. sbit LCD_D6_Direction at TRISC6_bit;
  18. sbit LCD_D7_Direction at TRISC7_bit;
  19.  
  20. void interrupt() {
  21.   if (PIR1.F0 == 1) {        //if interrupt is generated by TMR1IF
  22.  
  23.     T1CON.F0 = 0;                    //leállítja a timer1-et
  24.     ready = 1;                       //set data ready
  25.     i = 0;                           //reset array counter
  26.     PIR1.F0 = 0;                     //Set TMR1IF to 0
  27.   }
  28.   if (PIR1.F5 == 1) {        //az EUSART modulban keletkezett megszakítás (receive interrupt flag [RCIF])
  29.     NMEA[i] = UART1_Read();
  30.     i++;
  31.     if (NMEA[i-1] == 0) i = 0;
  32.     if (i == 76) i = 0;
  33.     //Stop Timer 1:
  34.     T1CON.F0 = 0;                    //Set TMR1ON to 0
  35.     //Timer1 starts counting from 15536:
  36.     TMR1L = 0x00;
  37.     TMR1H = 0x00;
  38.     //Start Timer 1:
  39.     T1CON.F0 = 1;                   //Set TMR1ON to 1
  40.     PIR1.F5 = 0;                     //Set RCIF to 0
  41.   }
  42. }
  43.  
  44. void Show_NMEA()
  45. {
  46.    int j=0;
  47.      //for(j=0;j<15;j++)
  48.      //LCD_Chr(1,j+1,NMEA[j]);
  49.      LCD_Chr(1,1,NMEA[7]);           //
  50.      LCD_Chr(1,2,NMEA[8]);
  51.      LCD_Chr(1,4,NMEA[9]);
  52.      LCD_Chr(1,5,NMEA[10]);
  53.      LCD_Chr(1,7,NMEA[12]);
  54.      LCD_Chr(1,8,NMEA[13]);
  55.      LCD_Chr(1,9,NMEA[14]);
  56.      LCD_Chr(1,10,NMEA[15]);
  57.      LCD_Chr(1,11,NMEA[17]);
  58.      
  59.      LCD_Chr(2,1,NMEA[19]);           //
  60.      LCD_Chr(2,2,NMEA[20]);
  61.      LCD_Chr(2,3,NMEA[21]);
  62.      LCD_Chr(2,5,NMEA[22]);
  63.      LCD_Chr(2,6,NMEA[23]);
  64.      LCD_Chr(2,8,NMEA[25]);
  65.      LCD_Chr(2,9,NMEA[26]);
  66.      LCD_Chr(2,10,NMEA[27]);
  67.      LCD_Chr(2,11,NMEA[28]);
  68.      LCD_Chr(2,12,NMEA[30]);
  69. }
  70.  
  71. void main() {
  72.     TRISC=0x00;
  73.     ANSEL  = 0;     // Configure AN pins as digital I/O
  74.     ANSELH = 0;
  75.     C1ON_bit = 0;   // Disable comparators
  76.     C2ON_bit = 0;
  77.  
  78.     LCD_Init();
  79.     Lcd_Cmd(_LCD_CLEAR);
  80.     Lcd_Cmd(_LCD_UNDERLINE_ON);
  81.  
  82.     Delay_ms(100);
  83.    
  84.     LCD_Chr(1,3,0xDF);         //° karakter
  85.     LCD_Chr(2,4,0xDF);         //° karakter
  86.     LCD_Chr(1,6,'.');          //' karakter
  87.     LCD_Chr(2,7,'.');          //' karakter
  88.     ready = 0;
  89.    
  90.     //Set Timer1 Prescaler to 1:8
  91.     T1CON.F5 = 1;                    //Set TCKPS1 to 1
  92.     T1CON.F4 = 1;                    //Set TCKPS0 to 1
  93.     //Enable Timer1 interrupt:
  94.     PIE1.F0 = 1;                     //Set TMR1IE to 1
  95.     //Timer1 starts counting from 15536:
  96.     TMR1L = 0xB0;
  97.     TMR1H = 0x3C;
  98.     //Clear Timer1 interrupt flag:
  99.     PIR1.F0 = 0;                     //Set TMR1IF to 0
  100.     //Note: Timer1 is set to generate interrupt on 50ms interval
  101.  
  102.     UART1_Init(38400);
  103.     Delay_ms(100);
  104.     //Enable Usart Receiver interrupt:
  105.     PIE1.F5 = 1;                     //Set RCIE to 1
  106.     //Enable Global interrupt and Peripheral interrupt:
  107.     INTCON.F7 = 1;                   //Set GIE to 1
  108.     INTCON.F6 = 1;                   //Set PEIE to 1
  109.    
  110.     //Start Timer 1:
  111.     T1CON.F0 = 1;                    //Set TMR1ON to 1
  112.     while(1)
  113.     {
  114.       RCSTA.F1 = 0;                  //Set OERR to 0 (nincs overrun error)
  115.       RCSTA.F2 = 0;                  //Set FERR to 0 (nincs framing error)
  116.        Show_NMEA();
  117.       if(ready == 1) { //if the data in NMEA array is ready do:
  118.         ready = 0;
  119.         string = strstr(NMEA,"$GPGLL");
  120.         if(string != 0) {          //If txt array contains "$GPGLL" string we proceed...
  121.           if(string[7] != ',') {   //if "$GPGLL" NMEA message have ',' sign in the 8-th
  122.                                    //position it means that tha GPS receiver does not have FIXed position!
  123.              //Show_NMEA();
  124.           }
  125.         }
  126.       }
  127.     }
  128. }

és ez történt, beraktam egy másik 690-est gondolván arra hogy lehet vmi az USART-al de az eredmény nem valami bíztató

GPGGA_uj.jpg		    
(#) pici válasza proci hozzászólására (») Jún 27, 2009 /
 
Ha az LCD-n ennyire hülyeség jelenik me, akkor az LCD kommunikációval van baj...
Pl nem bírja a tempót.
Ezért nem programozok C-ben, mert nem tudom mit fordít ASMre és mennyi a veszteség.
Az XMega prociknál akadtam ki, PORTF_OUT=$55 utasítást 4 ASM utasításra kódolta, amíg 1 max 2 ASM kézzel...
Na meg a LCD_Chr(1,1,NMEA[7]); utasítások sora.. mindig pozicionál is biztos.. nem csak kiszórja a karaktereket egymás után, hanem elötte koordinálja is...
(#) proci válasza pici hozzászólására (») Jún 28, 2009 /
 
Hmm... tegyük fel hogy azzal van a gond, történetesen hogy olyan gyorsan kapja az adatokat (ha jól tudom 270kHz-es az órajele), hogy nem képes feldolgozni és ezért firkálja tele a sorokat a saját memóriaszemetével. Akkor pl egy ilyen dolog szerintetek megoldaná? /hogy például csak 1mp-nként írnék a kijelzőre/
  1. .
  2. .
  3. .
  4. int timer=0;
  5. while(1)
  6. {
  7.    if(timer++>5000)
  8.    {
  9.         LCD_kiir();
  10.         timer=0;
  11.    }
  12.     .
  13.     .
  14.     .
  15. }
  16. .
  17. .
  18. .
(#) pici válasza proci hozzászólására (») Jún 28, 2009 /
 
Miért kérdezed, próbáld ki.
És ne a GPS legyen asoros bemenet, hanem a PC és teszteld mennyi karaktert bír
(#) proci válasza pici hozzászólására (») Júl 4, 2009 /
 
Pici!

Néhány kommentel ezelőtt írtad, hogy USB-ről kaphatná a tápot. Az USB 5V-jából hogyan lehetne a GPS-hez 3-3.3V-ot csinálni?
Üdv.
(#) pici válasza proci hozzászólására (») Júl 4, 2009 /
 
Én nem használok soros portot RS232-t és max232, elavult már szerintem.
Inkább USB-ről FT232. Ezen van táp is: 5V vagy 3.3V választási lehetőség (jumper)
A sebessége is sokkal nagyobb, és sok laptopon csak ez van.
RX TX és a többi ki van vezetve, és még plusz IO-k.
Csinálsz egy ilyet egy csatival és az összes fejlesztésed a PC-hez tudod kötni és ad tápot is.
Ezekre szükség lehet! - HESTORE.HU

FT232BL
PIC18F4550-I/P
PIC16F690 I/SO
MAX232AESE
RS232-TTL-M
Következő: »»   5 / 15
Bejelentkezés

Belépés
Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem