visualizzatore seriale su lcd

[MSchiepp]

Originalmente inviato da davidea

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

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

[protomax]

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.

[aduri]

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.

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 .
Nel terminale a PC se trasmetto 3 caratteri li visualizza perfettamente se ne trasmetto di piu' li tronca al terzo carattere.
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(PORT ' 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.

[davidea]

Originalmente inviato da MSchiepp

Certo che ci sono,
.
.
.

Michele

Originalmente inviato da davidea

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....

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!

[protomax]

Originalmente inviato da davidea

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 .

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

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 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.

[MSchiepp]

Originalmente inviato da protomax

X aduri
putroppo penso di aver centrato il problema...

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

[davidea]

Originalmente inviato da MSchiepp

@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.

ok, fin qui' ci sono!

Originalmente inviato da MSchiepp

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

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!

[rivp6]

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...
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.

bye

[protomax]

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

Originalmente inviato da rivp6

Sono in disaccordo con protomax: i processori sono come l'u......o non conta quanto è grande ma come lo usi...

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

Originalmente inviato da rivp6

Puoi avere anche un ATMEL a 200MHz, ma se il programma non è concepito bene, un PICcino a 4MHz funziona meglio...

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 bho forse avevo scritto troppo in torinese stretto neee

Originalmente inviato da rivp6

E i samples della microchip sono gli unici che mi arrivano regolarmente, dunque scelta naturale. (Ma l'atmel ha l'USB? )

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.

Originalmente inviato da rivp6

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.
bye

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

[MSchiepp]

Originalmente inviato da davidea

mi aspettavo di trovare

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

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