Problema Atmega128 - Usart impazzita?

[MarcoNiky]

Salve a tutti,

vi sottopongo un quesito inerente un Atmega128.

Utilizzo Bascom per la programmazione.

Mi servo del protocollo RS232 per collegarlo al mondo esterno e tutto funziona

perfettamente fino a che non vado ad utilizzare 115.200 baud.

(a 57.600 ed inferiori tutto ok).

Nel caso di 115.200 ricevo si dei dati ma sono errati.

Invece di chr(111) ricevo chr(47) oppure altri codici.

Con l'oscilloscopio ho verificato la bonta' dei segnali e appaiono belli squadrati e senza imperfezioni.

Ho utilizzato il clock interno da 8 Mhz. e dalle tabelle del manuale appare che per

57.600 baud e 115.200 l'errore e' minore del 10%,

quindi non dovrebbe essere questo il motivo.

Qualche suggerimento per capire da cosa potrebbe dipendere?

La dichiarativa e' la seguente:

Const Constbaud = 115200

$baud = Constbaud

Open "comd.1:115200,8,n,1" For Output As #1

Open "come.0:115200,8,n,1" For Input As #2

Print #1 , Chr(111);

Spero due cose:

La prima di avere azzeccato il forum corretto (... non sarebbe la prima volta che sbaglio...)

La seconda che qualcuno abbia qualche buon suggerimento da darmi!

Cordiali saluti e grazie 1000

Marco

[mf2hd]

Ciao, premetto che gli avr non li uso spesso.

Se non ho compreso male, mi e' capitato un problema simile al tuo mentre realizzavo un circuito che mi permettese di recuperare i micro "piantati" per fuses errati (croce di chi usa gli Atmel ).

La velocita' che ho utilizzato e' piu' bassa (9600) pero' non sempre il micro rispondeva correttamente.

Prova a dare un' occhiata all' manuale inglese del bascom (.) nella sezione realtiva alla comunicazione seriale (CONFIG SERIALIN).

C'e' un esempio dove e' mostrato l' utilizzo con/senza gestione dell' interrupt e buffer.

Nel commento alle righe di codice e' richiesto di fare una prova mettendo o no il REM (apostrofo) davanti a delle righe relative a quanto sopra, cosi' da vedere l' effetto in caso di velocita' "sostenute".

Ti riporto alcune delle note di commento, cosi' da individuare la parte di codice che cito:

'You will see that when you slowly enter characters in the terminal emulator

'they will be received/displayed.

'When you enter them fast you will see that you loose some chars

'NOW remove the remarks from line 11 and 18

'and compile and program and run again

'This time the chars are received by an interrupt routine and are

'stored in a buffer. This way you will not loose characters providing that

'you empty the buffer

[Nikiki]

Secondo me un errore del 10% non è trascurabile, io non ho mai avuto problemi con le comunicazioni seriali, ma sono sempre stato attento a scegliere quarzi "adatti" a mantenere l'errore a 0.

[accacca]

Ho usato poche volte atmel ho dato un'occhiata alla doc nelal tabella dei baudrate pag 196 dicono che con quarzo 8MHz se imposti U2X=1 l'errore è del 3.5% potresti provare così.

Mi chiedevo: far andare tutto a 115.200 significa avere un interrupt dalla seriale ogni 8.6 microsecondi. Riesci stargli dietro con il firmware ?

Se l'interrupt dura di più ti incarti con la ricezione.

In trasmissione è vero che invii i singoli bytes alla max velocità ma in realtà vai a un baudrate reale più basso determinato dalla durata del tuo interrupt.

Sarebbe opprtuno fare due conti e valutare se è il caso di far funzionare tutto così al limite.

[MarcoNiky]

Ciao a tutti,

Grazie x l'attenzione!

Rispondo per punti ai Vs. suggerimenti

(tenete conto che baso le mie risposte in 'virtu'' di quel che penso di aver capito:

non e' detto che siano corrette... ditemi la vostra senza problemi )

1) mf2hd: Non posso utilizzare la Serialin perche' sto sfruttando la usart 'software' e quindi gia' il compilatore

mi avvisa che non e' possibile.

2) Nikiki: Utilizzando la usart via 'software' l'errore e' indipendente dal quarzo usato, ma dipende dal clock generale (8 Mhz.)

3) accacca: U2X=1 l'errore è del 3.5% infatti ho visto questa impostazione (in Bascom non so come fare ad impostare questa variabile di registro UCSRA!!!)

Per il resto ti chiedo: ma l'interrupt non scatta solo al momento in cui il dato giunge al micro?

La gestione l'ho demandata al interrupt di ricezione cosi':

On Urxc Getbuf

Enable Urxc

In questo modo non ho un polling in ricezione, ma solo nel momento in cui c'e' davvero la chiamata allora eseguo la relativa routine di acquisizione.

quindi la velocita' in cui arrivano i dati e' servita all'interno della ISR, ma poi sono libero di fare tranquillamente il resto delle elaborazioni finche' non mi arrivano altri dati da host.

Ma forse non ho capito bene cosa intendi dire.

a 115.200 significa avere un interrupt dalla seriale ogni 8.6 microsecondi.

Come fai a calcolare questo timing?

Grazie di cuore a tutti per la cortesia

Saluti

P.S.

Nel frattempo ho provato ad utilizzare la UART 'Hardware' collegando i pin alla PORTE.0 e PORTE.1

Ho tolto le precedenti dichiarative di OPEN ed ho dichiarato la Serialin,

ma adesso, addirittura, non riesco mai a far leggere i dati dal micro: e' come se non ricevesse mai i dati e l'istruzione IsCharWaiting() e' sempre = 0.

Probabilmente devo cambiare hobby!

Il micro no, ne ho gia' provati due ...

Marco

[mf2hd]

Ho provato con un ATMEGA8 (non ho un 128 sottomano) usando l' USART.

Il convertitore di livelli e' il classico MAX232.

Testato sempre lo stesso programma, ma impostando clock diversi.

-----

$crystal = 20000000

$regfile = "m8def.dat"

$baud = 115200

$hwstack = 32

$swstack = 10

$framesize = 40

Waitms 500

Config Serialin = Buffered , Size = 200

Dim Na As String * 100

Enable Interrupts

Print "Start OK!!!"

Do

If Ischarwaiting() = 1 Then

Input Na

Print Na

End If

Wait 1

Loop

-----

L' unico che funziona bene e' 20MHz, con gli altri (4,8,10,12MHz) o perde pezzi per strada o non risponde proprio.

Rispetto all' esempio che c'e' nell' ., ho aumentato il buffer e provato a spedirgli un file di testo con una riga di 50 caratteri con hyperterminal.

Lo riceve e ritrasmette senza errori.

Mi sa che forse devi passare ad un clock piu' elevato.

Usa un quarzo "vero" non un risuonatore (provato anche con questi, ma non funziona).

Ho fatto tutto in fretta, su breadboard con connessioni volanti lunghe, forse su PCB risente meno di disturbi indotti e magari funziona con un quarzo di frequenza piu' bassa.

Perche', mica funziona sempre tutto al primo colpo,anzi...

Vedrai che se risolvi, la prossima volta che ti ricapita un problema simile lo sistemi in tempo zero.

Modificato: 15 maggio 2010 da mf2hd

[MarcoNiky]

Ciao Mf2hd,

ti ringrazio per tutte le preziose informazioni!

Seguiro' il tuo suggerimento di utilizzare un quarzo (adesso sono sul clock interno a 8Mhz)

Ciao a tutti e alla prossima domanda...