visualizzatore seriale su lcd
 

Spero di non essero OT eventualmente chiedo scusa.

Ho trovato questo compilatore basic interessante (Mikrobasic) ed ho provato a tirare giu un terminale seriale su lcd.

Il problema e' questo:
ho preso gli esempi dell'help che riguardano la ricezione e la trasmissione della usart con pic16f628a + max232 ed e' andato tutto a buon fine;
ho preso poi l'esempio della visualizzazione su lcd anche questo OK.

Ho provato a metterli insieme per fare un terminalino seriale su lcd allego dunque il mikrolistato:

program lcd_serial
main:

dim received_byte as byte
Lcd_Init(PORTB) ' initialize LCD connected to portb
lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
lcd_cmd( LCD_CURSOR_OFF) ' send command cursor off
lcd_out(1,1,"data") ' print txt to LCD, 1nd row, 1st column
Usart_Init(4800) ' Initialize USART module
while true
if Usart_Data_Ready = 1 then ' If data is received
received_byte = Usart_Read ' Read received data
' Usart_Write(received_byte) ' Send data via USART
lcd_out(2,1,Usart_Read) ' print gps data to LCD, 2nd row, 1st column
end if
wend

end.

A questi punti mi appare "data" sulla prima riga fin qua tutto ok ma quando mando una stringa dal tool usart terminal di mikrobasic mi scrive un serie di caratteri strani sulla prima riga (anziche' la seconda) subito dopo la scritta data.
Cortesemente qualcuno mi puo' dire dove sbaglio
E' la prima volta che programmo con questo SW ma gari e' una banalita'.

P.S. Ho provato anche a sostituire la variabile Usart_Read con received_byte (per essere sicuri del contenuto del buffer seriale) ma ottengo una sfilza di caratteri indecifrabili e partono sempre dalla riga 1.
Ho notato che se mando un solo carattere qualsiasi in un punto dell'LCD appare se ne metto 2 no.

partiamo dal concetto che non conosco quel linguaggio, ma ti dico cio' che penso possa essere che non va!, potrei anche dire delle fesserie, quindi prendimi con le pinze!

intanto la routine (tranne che non incrementi in automatico la posizione, dovrebbe scrivere sempre sullo stesso punto 2,1

assumendo che tu hai settato la seriale a 4800, (bit di parita?, quanti bit invia?) e che e' settata correttamente,
il dato che hai in ingresso, e' dello stesso tipo di quello in uscita? ossia, ricevi un char, e mandi un char? o ricevi un dato magari in due byte, e lo mandi come unico byte e quindi la routine impazzisce?
perche' non provi a fare un ciclo if, che scriva sull' lcd una stringa nota "carattere ricevuto correttamente" quando riceve un carattere scelto da te?

qualcosa di simile ad

if received_byte = "C" then lcd_out(2,1,"carattere C ricevuto")

in modo da esser sicuro che il carattere venga ricevuto correttamente!
se lo ricevi correttamente, poi puoi provare

if received_byte = "C" then lcd_out(2,1,received_byte)

io non userei la funzione Usart_Read , perche' non so' se e' un buffer, che una volta letto, non contiene piu' niente!

Innanzitutto grazie della risposta.
La prima routine della lettura della seriale l'ho adattata dall'esempio
presente nei samples del compilatore esso trasmetteva al pic una stringa e non un carattere da un terminale tipo hyperterminal di windows ed il pic ritrasmetteva il contenuto del buffer trasferito nella nuova variabile received_byte (cosicche' il rischio di avere il buffer vuoto e' scongiurato)
e tutto funzionava.
Io ho modificato il programma non ritrasmettendo la stringa dal pic al pc
perche' il pin tx usart e' occupato per la gestione dell'lcd e d'altronde mi sembrava inutile.

ciao' volevo informarti che in rete tale progetto e' gia' vechio di anni, sia con connessione seriale che parallela, e funzia volendo pure su un LCD 16x2.

Tra l'altro il basic o simili nn sono proprio gli ideali x questi scopi.

Ah, un ultima cosa (giusto x le persone che come me non usano sistemi operativi Microsoft): funziona su quasi tutti i sistemi operativi

penso che allora il problema sia li!!!

tu prima scrivi sul display, e la routine di inizializzazione del display va' a buon fine,
poi inizializzi la seriale, e allora il pin che prima usavi per il display viene rimappato alla seriale, e da allora in poi son dolori!!!

per provare, inverti le due righe,
prima inizializza la seriale e poi scrivi data
se e' come penso, non dovresti veder spuntare piu' neanche quello!!

a proposito, visto che stai usando il 16f628, fai programmazione in circuit o ogni volta lo levi e lo metti nel programmatore?
se fai incircuit, che programmatore usi?

Niente da fare ho provato a fare come hai detto tu ed anche a customizzare i pins per liberare rb2(tx usart) ma fa lo stesso errore.
Nella terminal del pc (che riceve anche lui il dato) tronca la stringa alla terza lettera.

Io uso il programmatore di NE e sposto il pic pero' per non rovinare i piedini
lo piazzo su uno zoccolo cosi' eventualmente si rovinano i terminali dello zoccolo.

Per rispondere all'altro amico io sto esercitandomi per cui cerco di non copiare per quanto possibile ma di prendere spunti.
Comunque non mi dispiacerebbe se mi mandaste qualche link in c o basic.

Allego il file modificato:



program lcd_serial
dim received_byte as byte
main:
' Lcd_Init(PORTB) ' initialize LCD connected to portb
Lcd_Config(PORTB,0,3,0,7,6,5,4) ' pins custom
lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
lcd_cmd( LCD_CURSOR_OFF) ' send command cursor off
lcd_out(1,1,"GPS data") ' print txt to LCD, 1nd row, 1st column
Usart_Init(4800) ' Initialize USART module
while true
if Usart_Data_Ready = 1 then ' If data is received
received_byte = Usart_Read ' Read received data
Usart_Write(received_byte) ' Send data via USART
lcd_out(2,1,"data:") ' print gps data to LCD, 2nd row, 1st column
lcd_out(2,7,received_byte) ' print gps data to LCD, 2nd row, 1st column
end if
wend
end.

ceh vuol dire nella terminal del pc??

il dato (da cio' che ho capito proviene da un gps), viene mandato contemporaneamente sia al pic che al pc?
se si' e' strano che ti venga troncata la stringa al 3 carattere, da cio' che ricordo io il gps da' delle stringhe belle linghe!

spiacente, sto tentando di iniziare pure io, in c!

ti ricordo che non conosco il linguaggio:

prima inizializzi l' lcd e poi configuri i pin? non dovrebbe essere al contrario?
nella configurazione ripeti 2 volte il valore 0....

io ho scaricato e installato picclite della hitech, e ho dato una lettura al manuale (350 pagine)
ma ancora non ho iniziato a provare niente, anche perche' dai comandi che ho visto nel manuale, ci sono solo funzioni matematiche.... non ho trovato niente per la lettura delle porte, continuero' a cercare....
sono ancora fortemente tentato di abbandonare i pic per passare ad atmega...

MICHELE??? ci sei , se ci sei batti un colpo!!!!!

C'e' l'apice prima dell'inizializzazione quindi quella riga e' diventata un commento pero' mi sono accorto di una bestialita'.
Mi ha portato fuori strada il fatto che il terminale su pc visualizzava una stringa
ma sul lcd devo creare un buffer ad es. con un ciclo for/next perche' la seriale trasmette carattere per carattere cosi' ho fatto questo nuovo listato ma accetta solo 3 caratteri che vengono visualizzati in successione appena dopo il data (nella posiz 7 della seconda riga) e il cursore si posiziona dopo il "data" continuo a non capire.
allego il listato:
program lcd_serial

dim received_byte as byte
dim i as byte

main:

' Lcd_Init(PORTB) ' initialize LCD connected to portb
Lcd_Config(PORTB,0,3,1,7,6,5,4) ' pins custom
lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
' lcd_cmd( LCD_CURSOR_OFF) ' send command cursor off
lcd_out(1,1,"GPS data") ' print txt to LCD, 1nd row, 1st column

Usart_Init(4800) ' Initialize USART module
while true

if Usart_Data_Ready = 1 then ' If data is received
received_byte = Usart_Read ' Read received data

Usart_Write(received_byte) ' Send data via USART

lcd_out(2,1,"data:") ' print gps data to LCD, 2nd row, 1st column

for i=0 to 10 'buffer
lcd_out(2,(7+i),received_byte) ' print gps data to LCD, 2nd row, 1st column
' lcd_cmd(LCD_CURSOR_ON) ' send command cursor on
Lcd_Cmd(Lcd_Move_Cursor_Right)
i=i+1
next i
end if
wend

end.


Se vuoi un bel tutorial c per pic vai sul sito di Fiser (http://www.jofi.it/fiser/page1.html

Penso che il problema della perdita di caratteri sia dovuto al fatto che la lettura seriale (e' lenta) rispetto all'arrivo dei caratteri sulla stessa.

come vedo dal listato la lettura della seriale e' un "polling" sul byte che scarica un carattere dalla seriale, ora bisogna vedere se il compilatore e la routine che la gestisce fa' buffering sulla rs232, la soluzione piu' giusta sarebbe usare un'interrupt o meglio vedere se per ogni byte rx sulla seriale si ha a disposizione un evento (inserendo il codice all'interno di quell'evento e' possibile far si che non si abbia piu' la perdita di caratteri)

Altra soluzione e' quella di evitare di scrivere i caratteri mentre arrivano ma di incamerarli in un vettore e poi mandarli in stampa sul display tutti in una volta.
Nos so che tipo di gps sia ma in genere le stringhe che inviano possono essere lunghe una 30ina di caratteri e + oltretutto arrivano a raffica almeno 1 al secondo per la stringa di localizzazione :wink:

Quindi il pic deve far veloce a leggere e scrivere sul display:wink:

Certo che ci sono, ma non è possibile esprimere un parere senza sapere come sono fatte le funzioni di interfacciamento con il display e con la seriale; credo che il problema sia quello descritto da Potomax e probabilmente bisogna fare qualcosa di un po' più mirato per gestire le due cose contemporaneamente. Cambiare micro non serve, basta riorganizzare il codice e vedrai che tutto si mette a funzionare.
Consiglieri vivamente di passare al C della Hitech che è disponibile gratis in versione demo: su quello posso garantire assistenza e qualche consiglio! In più considera che il C è abbastanza universale e se domani decidi di cambiare micro, non ti devi imparare tutto da capo!

Intanto suggerisco questa prova: invece del GPS collega all'ingresso del PIC il PC e all'uscita il display; con Hyperterminal settato alla giusta velocità, 8 bit, 1 stop, no parity e handshake=nessuno prova ad inviare caratteri da tastiera che dovresti vedere sul display (non sul monitor perchè non c'è l'eco automatico); questo dovrebbe farti capire se il sistema si blocca quando i caratteri arrivano troppo velocemente.

Scoperto questo vediamo come proseguire...

Michele

Direi che la cosa piu' bella sarebbe avere a disposizione la seriale TX RX per il pc e il display diretto attaccato al Pic.

No ho ben presente l'architettura, ma forse varrebbe la spesa oltre che a passare al C (piu' duttile ma soprattutto piu' usato ) in modo da avere un parco librerie piu' ampio.

Per quello che riguarda il c della Hitech lo uso da tempo ma ho fatto cose semplici anche perche' la mia conoscenza del c e' scarsa.
Ho gestito l'LCD guardando le routine del sito di Fiser per la gestione della seriale ma gli esempi sulla seriale che ho visto utilizzano gli ingressi a/d (invece della USART) di pic di classe superiore che sinceramente per questo tipo di applicazioni non vorrei scomodare .
Se trovassi qualcosa da cui partire sulla usart in c mi farebbe piacere ma non ho trovato nulla o di molto complesso.:(
Inizialmente cercavo qualcosa per il 16f84a ma avrei dovuto addirittura simulare la usart.:o:

Tornando al Mikrobasic innanzitutto grazie dei consigli ho letto il manuale (forse avrei dovuto farlo prima) ed effettivamente ho fatto un passo avanti.:)
Adesso funziona perfettamente con un solo carattere ed il cursore si posiziona subito dopo, se ne spedisco 2 mi si visualizza il secondo se 3 il terzo col 4 mi rimane il terzo:blink: .
Nel terminale a PC se trasmetto 3 caratteri li visualizza perfettamente se ne trasmetto di piu' li tronca al terzo carattere.:angry:
Il mio obbiettivo e' quello di ricevere il segnale dal gps riconoscere i caratteri della stringa che mi interessa e fare la codifica del protocollo.
Pero' ci vorrei arrivare un poco alla volta cercando di capire.
Addesso sto testando il tutto senza gps ma spedendo e ricevendo col pc.
Allego il listato se potete darmi ancora un aiuto:
program lcd_serial
dim received_byte as byte
main:
' Lcd_Init(PORTB) ' initialize LCD connected to portb
Lcd_Config(PORTB,0,3,1,7,6,5,4) ' pins custom
lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
' lcd_cmd( LCD_CURSOR_OFF) ' send command cursor off
lcd_out(1,1,"GPS data") ' print txt to LCD, 1nd row, 1st column
Usart_Init(4800) ' Initialize USART module
while true
if Usart_Data_Ready = 1 then ' If data is received
received_byte = Usart_Read ' Read received data
Usart_Write(received_byte) ' Send data via USART
lcd_out(2,1,"data:") ' print gps data to LCD, 2nd row, 1st column

'lcd_out(2,(7+i),received_byte) ' print gps data to LCD, 2nd row, 1st column
Lcd_Chr_cp(received_byte)
end if
wend
end.

mi confermi che sto prendendo una cantonata???(solo funzioni matematiche?)
inoltre la versione demo del compilatore non prevede il 16f628 ma il 16f627, saro' limitato a 1024 byte di programma??
visto che la demo e' limitata a 2 banchi ram, saro limitato a 112 byte di ram?
routine d' accesso alla eeprom?
routine per usare il comaratore come adc?
per programmare incircuit che consigli?
scusami per la valanga di domande, ma in questo periodo , tornando la sera a casa sono stanco e... fare le ricerche e capire cio' che si legge non e' sempre facile!:(

x davidea
Lo so sono troppo di parte ma perche' vi complicate la vita quando c'e' un prodotto totalmente free con cui potete fare un numero sufficiente di cose senza dover ammattire :wacko: .

Passate ad Atmel li c'e' il GCC free potete riempire 128Kbyte di micro con due seriali, in circuit programming tutto libero!!!!!
Oppure se volete un prodotto performate a + basso costo ATmega32 con una seriale ho messo la board monofaccia il programmatore via pp e' semplice :wink:

X aduri

putroppo penso di aver centrato il problema, il compilatore basic no fa buffering di piu' byte e la routin di scrittura su LCD e' molto pesante cosi' capita che il pic si perde i byte RX prova a fare cosi':

if Usart_Data_Ready = 1 then ' If data is received
received_byte = Usart_Read ' Read received data
Usart_Write(received_byte) ' Send data via USART
end if

se cosi' no perdi dati allora fai cosi'

if Usart_Data_Ready = 1 then ' If data is received
i= i+1 ;
received_byte (i) = Usart_Read ' Read received data buffer

if i = 10 then
for i= 1 to 10
lcd_out(2,i,received_byte) ' print gps data to LCD, 2nd row, 1st column
next i
i = 0 ;
end if

qui fa buffering di 10 caratteri vedi come fare per dichiarare un array no so se il tuo basic lo consente.
Lui stampa dopo 10 caratteri quindi se non gli arrivano non stampa

Ora per far si che le stringhe siano stampate quando finiscono inserisci un controllo di RX per il >CR< o >LF< sul carattere appena arriva manda in stampa :wink: invece che aspettare il riempimento del vettore di 10char se hai stringhe lunghe prova a aumentare il numero di caratteri di buffer limitatamente a quello che puoi fare con il basic e con le risorse del tuo pic.:wink:

Può essere, ma questo non dovrebbe succedere inviando i caratteri da PC uno per volta; ho visto il codice ASM generato dal compilatore: le librerie del display non verificano che l'operazione sul display sia conclusa, ed alcune operazioni possono richiedere anche 1-1.5 mS; nella gestione del display non viene utilizzato il pin 'W' e quindi non è possibile leggere lo stato dopo ogni operazione.
Puoi fare questa prova:

program Test_Display
dim i as byte
Lcd_Config(PORTB,0,3,0,7,6,5,4) ' pins custom
lcd_cmd(LCD_CLEAR) ' send command to LCD "clear display"
lcd_chr(1,1,0x20)
for i=1 to 20
Lcd_Chr_cp(63+i)
' Delay_us(50)
next i
Delay_ms(1500)
lcd_chr(2,1,0x20)
for i=1 to 20
Lcd_Chr_cp(95+i)
' Delay_us(50)
next i
end.

che dovrebbe riempire la prima riga del display, aspettare 1,5 sec e riempire la seconda riga; se funziona cercheremo il problema nella gestione combinata della UART, se no togli i commenti sui due Delay_us ed eventualmente prova ad alzare i valori.

Per quanto riguarda Atmel e altri micro, in questa fascia non ci sono grosse differenze; i Microchip sono più diffusi soprattutto a livello industriale perchè godono fama migliore dei concorrenti, mentre gli Atmel hanno avuto il loro momento di gloria nel campo della telefonia mobile, ma adesso sembrano essere un po' in declino.
Se la scelta è fatta su 'feeling' personale o disponibilità di tools gratuiti allora i criteri di scelta cambiano...

@DAVIDEA
Non è questione di 'cantonate', ma di differenza tra linguaggio e librerie; il C è un linguaggio e ti mette a disposizione una serie di funzioni, operatori e strutture dati che ti permettono di scrivere del codice in accordo con determinate 'regole'; l'insieme di tutte queste cose è codificato e definito in modo universale indipendente da chi produce il compilatore od il micro e si chiama 'Ansi C'; quando i compilatori hanno dei comportamenti differenti dallo standard vengono specificate quali sono le differenze rispetto allo standard.
Le librerie sono un insieme di funzioni complesse create per risolvere problemi ricorrenti e possono essere quindi adattate e personalizzate perchè non fanno parte di uno standard.
Spesso (vedi questo topic) le librerie fornite sono solo degli esempi e non è sempre possibile integrarle in modo immediato.
Esempio: la libreria del display LCD impiega circa 40 istruzioni a scrivere un dato, perchè, per mantenere la flessibilità di assegnare liberamente i pin di interfaccia, esegue otto operazioni separate di test del dato e set/reset dei bit corrispondenti; per contro vincola ad usare una sola porta per il display obbligando a rinunciare ad altre funzioni che hanno dei pin dedicati.
Morale: in un paio d'ore posso scrivermi la mia libreria in C che gestisce il display in modo più mirato e più efficiente e che posso integrare facilmente con dell'altro codice.

Il resto alla prossima puntata...

Michele

ok, fin qui' ci sono!

e fin qui' sono in parte daccordo con te!!!!

se debbo scrivermi da me le librerie, allora la programmazione in c si limita alla sola struttura del sw, mentre le funzioni me le devo scrivere.

essendo che l' hitech diceva di non dare i sorgenti delle librerie nel demo, pensavo che vi erano le varie funzioni , ma che non potevo modificarle, mancando il sorgente, ma da cio' che vedo, non vi sono! o sbaglio???

non vi sono, nel senso che oltre a trovarmi la
sin(x)
cos(x)
etc,

mi aspettavo di trovare

read_adc()
write_internal_eeprom(byte,loc)
set(port,bit)
read(port,bit)

ed un' altra sfilza di istruzioni gia' pronte, che nella versione demo, se mi sta bene uso, se no' riscrivo, ma nella versione commerciale puoi adattare alle tue esigenze!

utopistico??

forse e' la troppa inesperienza a portarmi a commettere degli errori concettuali dei quali non mi accorgo!

@protomax

per ora ho questo dentro, e siccome come puoi vedere ho le idee mooolto confuse, inizio con questo, e poi quando padroneggio un po' meglio le problematiche avro' la possibilita' di capire cio' che mi serve realmente!

Sarò banale, ma invia il messaggio al PC/LCD quando è completo.
Ovvero il protocollo MNEA invia una stringa di dati terminata da un CR/LF.
Memorizza in un array il pacchetto ricevuto e spediscilo al PC quanto ricevuto completo.
Nota che a 9600 hai 1 mS per gestire un singolo carattere, mentre tra un messaggio e il successivo di un GPS hai circa 500mS.

Sono in disaccordo con protomax: i processori sono come l'u......o non conta quanto è grande ma come lo usi...:rolleyes:
Puoi avere anche un ATMEL a 200MHz, ma se il programma non è concepito bene, un PICcino a 4MHz funziona meglio...
NB: per vari motivi, uso Z80, ST7 e PIC. E i samples della microchip sono gli unici che mi arrivano regolarmente, dunque scelta naturale. (Ma l'atmel ha l'USB?<_< )

Per quanto riguarda il compilatore, si tratta di comodità. Per lavoro uso il C++, per i processori il basic o il C. Purtroppo, i compilatori per i uPC costano un pacco, e dipende anche cosa trovi sul muletto. Non tutti possono permettersi il Proton o l'Hitek.:fiu:

bye

Premetto che non voglio per nulla essere polemico e se sforo in OT perdonatemi :mellow:

vabbe che un forum di modellismo dove si parla di macchine volanti ma scomodare anche la Fauna Con le ali :icon_rofl

Sono d'accordo ma il riferimento ad adottare Atmega di qualche messaggio piu' in su era per il fatto che c'e' difficolta a reperire librerie e compilatori in c free per PIC, allora suggerivo il passaggio ad At perche' li per scelta politico/commerciale della casa madre e di sviluppatori indipendenti si e' intrapreso il porting di Gcc per uC
No volevo dire che il software sviluppato era inadeguato :huh: bho forse avevo scritto troppo in torinese stretto neee :D

L'atmega ha la possibilita' di gestire in hardware tramite interrupt le comunicazioni USB 1.0 per la serie Mega32--128 i nuovi 325 ecc anche usb 2.0 sempre tramite gcc e librerie free.Ci sono le APnote anche del driver usb Windows per gestire le comunicazioni Usb con ATMEGA.

E' stato proprio uno dei fattori dominanti che mi hanno fatto decidere per il uC Atmega. Compilatore Gcc free e buona reperibilita' di librerie in C.
Non pensare che sia cosi' ottuso da non controllare anche i PIC :wink:

La funzione di lettura/scrittura della EEProm c'è, mentre per le altre non c'è n'è sempre bisogno: per settare o azzerare un bit basta definire un variabile specificando la porta ed il bit e poi assegnare 0 o 1 alla variabile... (es. #define LED RB01 e quindi LED = 1 o LED = 0); lo stesso per leggere ADC o UART: basta aspettare che il flag di segnalazione sia attivo e leggere nella propria variabile un registro.
Il discorso è ovviamente diverso per librerie più complesse come quelle grafiche o quelle usate per inerfacciare dispositivi particolari, ma in genere sono fornite da chi vende il dispositivo; sui siti dei costruttori di micro o dei fornitori di compilatori si trovano comunque tanti esempi ed applicazioni; in questo caso lavorare in C ti permette più facilmente di adattare codice di un altro micro o di un altro processore.
Della stessa famiglia del Mikrobasic esiste anche il MikroC http://www.mikroelektronika.co.yu/ con le stesse librerie ed esempi!

Ciao,

Michele

Grazie a tutti mi siete stati molto utili.
Sono riuscito a mandare con successo la mia prima stringa da terminale
creando (come da voi consigliato) un vettore inviato poi in un secondo tempo all'lcd.
Effettivamente nel sito del compilatore c'e' molto materiale.

Per quello che riguarda Picclite ne ho sentito parlare molto bene anche della versione free e fino ad ora quello che ho fatto mi e' andato a buon fine.
Per usare il 16f628 con picclite in un forum ho visto questo messaggio:

All you need to do is to copy the 627 info in the pic.ini file into a new
section then change just the header to 628. Then you will be able to
select and program.

Questo ti permette di creare un finto 628 che avrà le stesse limitazioni del 627 con l'unico vantaggio di poterlo dichiarare come un 628...

Se vuoi provare il PicLite ti passo il file di configurazione del 628... vero!!

Ciao,

Michele

Per la mia esperienza il miglior compilatore è il Picbasicpro PBP, unico difetto è il costo elevato.
Se sei interessato ai GPS ti consiglio un ottimo simulatore, Nema Talker

http://www.sailsoft.nl/

Praticamente trasmette le stringhe Nmea che vuoi ed è totalmente configurabile.

Ciao,
Sub53

Bene cosi'! Procedere piccoli passi ma continui testando i vari moduli senza mettere troppo e tutto insieme e' utile per capire e modificare il codice a seconda delle esigenze e dei problemi che ci si pongono di fronte

:wink: Ottimo lavoro

Qualcuno sa' come utilizzare il debugger di Mikrobasic per dare a USART_DATA_ready =1 (attiva) in quanto anche selezionando add all non appare tra le variabili (sempre che sia considerata tale). :)
x MSchiepp se mi mandi il file del 628a per picclite mi fai una cortesia.:P
Io il gps ce l'ho gia e l'ho comprato in una fiera ma non ha visualizzatore
ed ha solo la seriale per poter essere collegato ad un portatile.
E' per questo motivo che volevo fare un visualizzatore lcd per l'ora UTC e latitudine + longitudine

Devi aggiungere nella finestra di watch il registro PIR1 e quindi assegnargli il valore 0x20 per settare il bit RCIF e simulare l'arrivo di un carattere; per simulare anche la ricezione devi caricare nel registro RCREG il valore del carattere del quale vuoi simulare la lettura.
Se mi mandi il tuo indirizzo e-mail ti mando i file per il compilatore C.

Ciao,
Michele

Ti ringrazio stasera provero'.
Il mio indirizzo e' antonio.durighello£fastwebnet.it
sostituisci la £ con la chiocciola

Ho fatto la simulazione e purtroppo ho notato dove e' l'arcano ma non riesco a risolverlo.
Il codice come e' adesso funziona se simulo via seriale solo una delle 6
stringhe che il mio gps spedisce e piu' precisamente la stringa $GPGGA, ora UTC, latitudine, N/S, longitudine , E/W , ......
Quindi funziona la prima parte dove avviene il riconoscimento della virgola (separatore campi) e dopo non funziona la parte di riconoscimento della stringa $GPGGA quindi lui legge qualunque stringa sbagliando la decodifica.

Qualcuno piu' esperto di me mi puo' dare una mano.

Ho commentato per quanto e' possibile il codice.

Nella prima parte ho customizzato i pins dell'lcd per liberare i pins della usart del pic.

Allego il listato:

program GPS
dim rxIndex as byte
dim rxDone as byte
dim rxGPSData as byte
dim rxDataGarbage as byte
dim conta as byte
dim GP as char[10]
dim sincro as char[7]
dim UTC as char[10]
dim Latitudine as char[10]
dim Longitudine as char[10]
'dim Altitudine as char[4]
dim NS as char[1]
dim EW as char[1]
'dim SatNum as char[4]
dim Ora as char[10]
dim NSLatitudine as char[11]
dim EWLongitudine as char[12]

'Questa e' la successione di stringhe del mio GPS
'$GPGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0*00
'$GPGSV,3,1,09,01,30,312,00,02,24,112,00,04,28,063 ,00,05,77,128,00*73
'$GPGSV,3,2,09,06,15,209,00,14,38,269,00,20,10,000 ,00,25,13,309,00*77
'$GPGSV,3,3,09,30,58,254,00,,,,,,,,,,,,*4D
'$GPGGA,204620.999,4530.6671,N,00916.9484,E,0,00,5 0.0,101.9,M,,,,0000*32
'$GPRMC,204620.999,V,4530.6671,N,00916.9484,E,0.0, 0.0,250805,0.0,W*63

'Io analizzo solo la stringa
'$GPGGA,204620.999,4530.6671,N,00916.9484,E,0,00,5 0.0,101.9,M,,,,0000*32
' ora UTC lat N/S long E/W


main:
Lcd_Config(PORTB,0,3,1,7,6,5,4) ' pins custom
lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
' lcd_cmd( LCD_CURSOR_OFF) ' send command cursor off
lcd_out(1,1,"GPS data") ' print txt to LCD, 1nd row, 1st column
'VRCON = 7 ' I need to do that because I'm using the PORTA for lcd output
'CMCON = 7 ' same as above
USART_init(4800)
'Lcd_Config(PORTA,2,3,0,7,6,1,4)
Lcd_Cmd(LCD_CLEAR)
Lcd_Cmd(LCD_CURSOR_OFF)
lcd_out (1,1,"Attesa...")
inizio:
Ora = " "
GP = " "
sincro = " "
rem NSLatitudine = " "
rem EWLongitudine = " "
rem Altitudine = " "
rem SatNum = " "

if USART_Data_Ready=1 then
rxDataGarbage = USART_Read
end if
rxDone = 0
rxIndex = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
GP[rxIndex] = rxGPSData ' Nmea 183 sentence $GPGGA
if (rxGPSData=44) then ',
if (GP[0]=36) and (GP[1]=71) then '$ and G
if (GP[2]=80) and (GP[3]=71) then 'P and G
if (GP[4]=71) and (GP[5]=65) then 'G and A
rxDone = 1
else
goto inizio
end if
end if
end if
end if
inc(rxIndex)
end if
wend

rxIndex = 0
rxdone = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
UTC[rxIndex] = rxGPSData ' UTC (ora)
if (rxGPSData=44) then
rxdone=1
end if
inc(rxIndex)
end if
wend
rxIndex = 0
rxdone = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
Latitudine[rxIndex] = rxGPSData ' Latitudine
if (rxGPSData=44) then
rxdone = 1
end if
inc(rxIndex)
end if
wend
rxIndex = 0
rxdone = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
NS[rxIndex] = rxGPSData ' Nord o Sud
if (rxGPSData=44) then
rxdone = 1
end if
inc(rxIndex)
end if
wend
rxIndex = 0
rxdone = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
Longitudine[rxIndex] = rxGPSData ' Longitudine
if (rxGPSData=44) then
rxdone = 1
end if
inc(rxIndex)
end if
wend
rxIndex = 0
rxdone = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
EW[rxIndex] = rxGPSData ' Est o Ovest
if (rxGPSData=44) then
rxdone = 1
end if
inc(rxIndex)
end if
wend
for conta = 1 to 2
rxIndex = 0
rxdone = 0
'while rxDone=0
'if USART_Data_Ready=1 then
' rxGPSData = USART_Read
' SatNum[rxIndex] = rxGPSData ' Numero di Satelliti
' if (rxGPSData=44) then
' rxdone = 1
' end if
' inc(rxIndex)
' end if
'wend
next conta
'esempio stringa
' $GPGGA,204620.999,4530.6671,N,00916.9484,E,0,00,50 .0,101.9,M,,,,0000*32
' Crea l'array ora
ora[0] = UTC[0] 'ore "20"
ora[1] = UTC[1]
ora[2] = ":"
ora[3] = UTC[2] 'minuti "46"
ora[4] = UTC[3]
ora[5] = ":"
ora[6] = UTC[4] 'secondi "20"
ora[7] = UTC[5]
' Crea l'array NSLatitudine
NSLatitudine[0] = Latitudine[0] ' gradi
NSLatitudine[1] = Latitudine[1] ' gradi
NSLatitudine[2] = "'" ' apice
NSLatitudine[3] = Latitudine[2] ' primi
NSLatitudine[4] = Latitudine[3] ' primi
NSLatitudine[5] = Latitudine[4] ' punto per decimali
NSLatitudine[6] = Latitudine[5] 'decimali
NSLatitudine[7] = Latitudine[6] 'decimali
NSLatitudine[8] = Latitudine[7] 'decimali
NSLatitudine[9] = Latitudine[8] 'decimali
NSLatitudine[10] = " "
NSLatitudine[11] = NS[0] 'nord/sud
' Crea l'array EWLongitudine
EWLongitudine[0] = Longitudine[0] ' gradi
EWLongitudine[1] = Longitudine[1]
EWLongitudine[2] = Longitudine[2]
EWLongitudine[3] = "'"
EWLongitudine[4] = Longitudine[3] ' primi
EWLongitudine[5] = Longitudine[4]
EWLongitudine[6] = Longitudine[5]
EWLongitudine[7] = Longitudine[6]
EWLongitudine[8] = Longitudine[7]
EWLongitudine[9] = Longitudine[8]
EWLongitudine[10] = Longitudine[9]
EWLongitudine[11] = " "
EWLongitudine[12] = EW[0]

lcd_out(1,1,"UTC: ")
lcd_out(1,6,ora)
delay_ms(3000)
lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
'delay_ms(1500)
'lcd_out(1,1,"Lat: ")
'delay_ms(3000)
lcd_out(1,6,NSLatitudine)
'delay_ms(3000)
lcd_out(1,18," ") '7 spazi vuoti x pulire
'delay_ms(3000)
lcd_out(2,1," ") '24 spazi vuoti x pulire
'delay_ms(4000)
'lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
'lcd_out(2,1,"Lon: ")
'delay_ms(3000)
lcd_out(1,1," ")
'delay_ms(3000)
lcd_out(1,1,"Lat: ")
'delay_ms(3000)
lcd_out(2,1,"Lon: ")
'delay_ms(3000)
lcd_out(2,6,EWLongitudine)
'delay_ms(3000)
lcd_out(2,19," ") ' spazi vuoti x pulire
'delay_ms(3000)
lcd_out(1,1," ")
'delay_ms(3000)
lcd_out(1,1,"Lat: ")
'delay_ms(5000)
'lcd_cmd( LCD_CLEAR) ' send command to LCD "clear display"
rem lcd_out(2,9,"Alt:")
rem lcd_out(2,14,Altitudine)
goto inizio
end.



Nell'ultima parte sono dovuto andare a tentativi per pulire il mio lcd (2x24)perche' rimanevano dei caratteri dove non doveva esserci nulla non sono riuscito a capire lo standar di Mikrobasic per gli lcd da quante righe e colonne e' e se si puo' settare in qualche modo.

Il problema e' qui! in pratica la stringa $GPGGA deve "cadere" proprio giusta nelle posizioni della variabile e cioe' il carattere $ al primo posto e gli altri di seguito..... fai invece cosi' cerca il solo carattere $ con lo stesso sistema e poi sai che di seguito avrai sempre GPxxx....... ecc.... il carattere dollaro $ e' fatto apposta per trovare il punto di partenza della stringa :wink: :wink: :wink:

A volte bisogna semplificarsi la vita :D

Da come ho capito tu mi consiglieresti di fare un check sul $ anziche' la virgola (divisore campi), creare il vettore e poi analizzarlo all'interno dei cicli (come sotto) o al di fuori?

Tipo.....


rxDone = 0
rxIndex = 0
while rxDone=0
if USART_Data_Ready=1 then
rxGPSData = USART_Read
GP[rxIndex] = rxGPSData ' Nmea 183 sentence $GPGGA
if (rxGPSData="$") then ',
if (GP[1]="G") and (GP[2]="P") then 'G and P
if (GP[3]="G") and (GP[4]="G") then 'G and G
if (GP[5]="A") and (GP[6]=",") then ' A and ,
rxDone = 1
else
goto inizio
end if
end if
end if
end if
inc(rxIndex)
end if
wend

Lo provero'