Pic e GSM

[faustog_2]

.... sono andato a leggere il datasheet

allora
Fosc=16.000.000
baud Rate = 115.00 = _______________
16( X +1)

per cui



1 16 * X + 16
__________ =__________________
115.200 16.000.000


16.000.000
__________ - 16 = 16 * X
115.200
16.000.000
_____________ - 16
115.200
HBRG X= ___________________ = 7.68
16


ma deve essere un numero intero quindi 8

però in realtà se facciamo gli stessi calcoli usando 4.000.000 e un baud rate di 9600

X = 25,04 che arrotondato con 25 rappresenta un dato quasi esatto, con una differenza meno di 0.06 in questo caso invece abbiamo uno scarto di
0.32 , ben più grande... forse e ripeto fors,e potrebbe essere meglio usare un 20 Mhz magari otteniamo un' arrotondamento meno aggressivo?

faccio una prova...

Originalmente inviato da ElNonino

Basta usare la formula appropiata per settare il registro del divisore SPBRG, avendo cura di settare anche il birt BRGH.

la formula è: Baud Rate = FOSC/(16 (X + 1))

risolta per X: X=((FOSC/Baud Rate)/16) - 1

nel caso di FOSC = 16MHz e Baud rate = 115.200 avrai SPBRG = 8 ( errore di br accettabile, divisore teorico sarebbe 7,68)

Se hai FOSC = 4 MHz non puoi usare i 115.200 Baud.

[ElNonino]

Più è alta la frequenza del quarzo minore è l'errore percentuale del generatore di baud-rate.

La massima precisione però non è strettamente necessaria, la USART hw dei PIC, se non ricordo male, fa 3 (5?) campionamenti per ogni bit quindi il rischio di perdita dati è decisamente ridotto.

Come standard io tendo ad usare la massima frequenza di funzionamento dei PIC, usando oscillatori esterni ed il PLL interno, l'uso di un oscillatore esterno garantisce una migliore precisione di frequenza, anche con variazioni di temperatura, inoltre libera un piedino del micro che io in genere dedico per il debug.

[faustog_2]

ok allora vado a prendere adesso un quarzo da 20 Mhz poi faccio il calcolo per ottenere il HBRG corretto per avere i 115200 baud.. che dici.. ogni sera per un motivo o l'altro sto scendendo a catania centro... è un casino ogni volta!

a dopo
fausto

Originalmente inviato da ElNonino

Più è alta la frequenza del quarzo minore è l'errore percentuale del generatore di baud-rate.

La massima precisione però non è strettamente necessaria, la USART hw dei PIC, se non ricordo male, fa 3 (5?) campionamenti per ogni bit quindi il rischio di perdita dati è decisamente ridotto.

Come standard io tendo ad usare la massima frequenza di funzionamento dei PIC, usando oscillatori esterni ed il PLL interno, l'uso di un oscillatore esterno garantisce una migliore precisione di frequenza, anche con variazioni di temperatura, inoltre libera un piedino del micro che io in genere dedico per il debug.

[faustog_2]

ho comprato due quarzi uno da 20 e l'altro da 16 Mhz, il risultato è che funzionano solo nelle velocità indicate nel datasheet, per cui la mia considerazione iniziale era corretta, per avere USaRT hardware da 115200 occorre passare al 18F2320 e quarzo da 40 Mhz a pagina 200 trovi la soluzione.

quindi non mi resta che passare alla UART software se voglio rimanere con 16F876. Ho com test solo la TX.. perchè a me interessa in futuro inviare SMS..

quindi quei calcoli vanno bene ma solo nell'ambito delle velocità prestabilite.

a dopo

Originalmente inviato da ElNonino

Più è alta la frequenza del quarzo minore è l'errore percentuale del generatore di baud-rate.

La massima precisione però non è strettamente necessaria, la USART hw dei PIC, se non ricordo male, fa 3 (5?) campionamenti per ogni bit quindi il rischio di perdita dati è decisamente ridotto.

Come standard io tendo ad usare la massima frequenza di funzionamento dei PIC, usando oscillatori esterni ed il PLL interno, l'uso di un oscillatore esterno garantisce una migliore precisione di frequenza, anche con variazioni di temperatura, inoltre libera un piedino del micro che io in genere dedico per il debug.

[faustog_2]

allora ci siamo

questo primo ste è superato, il pic 16F876 con quarzo da 16 Mhz trasmette ee riceve a 115200 quindi conpatibile con l' FBUS dei cellulari.

ti chiedo scusa, , la mia "supposta" era errata, per scrupolo ho rifatto la prova ci siamo funziona con un applicazione in JAva che legge e scrive su seriale.. devo vedere forse nel'Hyper terminal avevo qualche impostazione errata. Adesso ho sonno vado a dormire.. il set delle variabili eccolo:

MOVLW 8
MOVWF SPBRG

MOLW b'00100100'
MOVWF TXSTA

MOVLW b'1001000'
MOVWF RCSTA

insomma nel registro TXSTA il bit BRGH=1 8 in SPBRG come da calcolo, daltronte 57600 x 2 = 115200 era quasi scontato che da 16 si passi a 8 !!!

Ho già realizzato la sagoma in plexiglas per connettermi al cellulare, dovrei usare un alcatel.. ha i pinout fuori dalla sim.. per cui lunediì ci rimettero mani, girando per i negozi stasera ho notato che tutti i nuovi Nokia hanno i pin sotto la sim... insomma strateggico, per non farsi fregare.. ...bha , ...adesso mi riposo per qualche giorno.

ti ringrazio, se non avessi avuto il tuo sprono mi sarei rassegnato, su quello che leggevo nel datasheet... invece un tarlo in testa mi diceva, "prova figliuolo, prova, chi sa se quel buonomo nel forum di barone rosso la racconta giusta... abbi fiducia figliuolo ..prova" e così provo pure in java e scopro che ok,

ok a dopo
fausto

Originalmente inviato da faustog_2

ho comprato due quarzi uno da 20 e l'altro da 16 Mhz, il risultato è che funzionano solo nelle velocità indicate nel datasheet, per cui la mia considerazione iniziale era corretta, per avere USaRT hardware da 115200 occorre passare al 18F2320 e quarzo da 40 Mhz a pagina 200 trovi la soluzione.

quindi non mi resta che passare alla UART software se voglio rimanere con 16F876. Ho com test solo la TX.. perchè a me interessa in futuro inviare SMS..

quindi quei calcoli vanno bene ma solo nell'ambito delle velocità prestabilite.

a dopo

[MSchiepp]

Visto che hai i due quarzi, ti conviene usare quello da 20 Mhz, dato che con 20Mhz e 0x0A come divisore ottieni 113.636 con un errore pari a 1,37%, mentre con 16Mhz e 0x08 come divisore ottieni 111,111 con il 3.6% di errore.

Michele

[faustog_2]

si ok già fatto!

Originalmente inviato da MSchiepp

Visto che hai i due quarzi, ti conviene usare quello da 20 Mhz, dato che con 20Mhz e 0x0A come divisore ottieni 113.636 con un errore pari a 1,37%, mentre con 16Mhz e 0x08 come divisore ottieni 111,111 con il 3.6% di errore.

Michele

[faustog_2]

il primo ostacolo è superato..

ma il secondo NOO!! se qualcuno ha spunti?
allora sono riuscito a portare i pin del Nokia 1616 fuori dal cellulare, ho testato un nokia 1616 nuovo usando il tester.. per cui metto un puntale su GND e uno su TX, e ppoi su RX rilevo, i dati OK, poi faccio lo stesso sul Nokia modificato attraverso i pim esterni, ok gli stessi valori del primo. LA soluzione è stata la vernice elettroconduttrice, solo che anzichè saldarla con i cavetti esterni , li ho connessi con l'attack, nella guaina, mentre il contatto con una seconda "colata" di vernice che unisce le piste disegnate con i cavetti. Sono contento del risultato, sembra piuttosto solido.
Adesso ho appena realizzato un semplice circuito, il classico con Max232 e i 5 condensatori, testato con il Pic funziona, funziona anche con i 115.200 bps.

Ok quindi collego direttamente gli ingressi del circuito al Nokia 1616, su Hyper terminal scrivo AT [invio] ,niente elettroencefalogramma piatto! nessuna risposta... io mi aspettavo un OK come da manuale...

dove sbaglio?
per come avevo capito io il cellulare attraverso TX e RX FBUS comunica con il protocollo seriale asincrono con 115.200 bps e che fosse stato sufficiente Hyper terminal poter controllare, ovviamente avendo cura di convertire i segnali EIA in TTL..

a dopo
fausto

[faustog_2]

leggo adesso il tuo consiglio, ringrazio vivamente, magari provo un software diverso dell'Hyper terminal.. chissa se c'azzecco!

grazie

Originalmente inviato da marcosinatti

Con questo puoi provare i comandi AT, dopo basta ripeterli sul pic Alberto Alessi - Home Page

[faustog_2]

ho trovato questo schema

www.pacca.it - Cavetto FBUS per cellulari Nokia

vi antrebbe di analizzarloa assieme?

Originalmente inviato da faustog_2

leggo adesso il tuo consiglio, ringrazio vivamente, magari provo un software diverso dell'Hyper terminal.. chissa se c'azzecco!

grazie