Attiny 25 - GPS -Empfang

woher sollen wir wissen was du für ein gps modul hast?

Als GPS-Modul nutze ich ein NAVILOCK NL-203P (siehe Anhang)

Das Vieh hat eine serielle Schnittstelle 4800 8N1. Um davon Daten zu 
empfangen musst du ein passendes Programm schreiben und in den AVR 
laden.

http://www.mikrocontroller.net/articles/AVR-Tutorial
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Irgendwie klingt das für mich nach "Ich weiß nichts, erklärt mir alles!"
Die Schnittstelle ist bereits definiert, das brauchst du nicht zu tun. 
Du musst dich nur darum kümmern, das Protokoll zu implementieren. Dazu 
sollte sich aber mit ein paar Schlagwörtern genug Material im Internet 
finden lassen.

eventuell braucht du noch ein pegelwandler.

Klaus Dieter schrieb:
> Die Schnittstelle ist bereits definiert, das brauchst du nicht zu tun.


Also ziehe ich mein Datensignal auf den SDA des Controllers und kann 
direkt die Daten über das USIDR auslesen?

Mike schrieb:
> Also ziehe ich mein Datensignal auf den SDA des Controllers und kann
> direkt die Daten über das USIDR auslesen?

ja wenn die pegel passen.

Muß sowas in die Codesammlung?
Ich sehe hier keinen...

Admin: Bitte verschieben

Mike schrieb:
> Also ziehe ich mein Datensignal auf den SDA des Controllers und kann
> direkt die Daten über das USIDR auslesen?

Naja, SDA bezeichnet die Datenleitung von I²C/TWI. Der Empfänger 
kommuniziert normalerweise mit einer UART (Dier dert ATTiny25 glaub ich 
nicht hat), bedeutet: Die UART müsstest du in Software nachbauen. Pegel 
müssen sicherlich angepasst werden, das müsste man aber nachmessen.

Nochmal zum Verständnis:
Das hier kann ich mir sparen?

void USI_Init( void )
{
  USIDR = 0xFF;
  USICR = 0x22;
  USISR = 0xF0;
}

und kann ohne vorher irgendwas initialisiert zu haben trotzdem direkt 
folgendes machen?

  gps_Zeichen[j] = USIDR;



das klingt für mich irgendwie komisch.
Liegt vielleicht dadran, dass das mein erster Atmel-Controller ist, 
nachdem ich bisher nur mit NXP zu tun hatte.

Hi

>und kann ohne vorher irgendwas initialisiert zu haben trotzdem direkt
>folgendes machen?

>  gps_Zeichen[j] = USIDR;

Nein. Nochmal: Der ATTiny25 hat keine UART. Wie die USI als UART zu 
benutzen ist findest du hier:

http://www.atmel.com/Images/doc4300.pdf
http://www.atmel.com/Images/AVR307.zip

MfG Spess

Mike, an dem GPS-Daten aus einem Navilock-Empfänger auszulesen bin ich 
vor einiger Zeit gescheitert.
Wenn du es hinbekommst, dann wäre es nett, wenn du deinen Code hier 
veröffentlichen würdest.


Schon mal vorab, Danke
Ralf

Vielen Dank schonmal für die Antworten.

Gibt es da nicht eine einfacherere Lösung als mir softwaremäßig aus 
einer Usi eine Uart zu machen? - z.B. MOSI ?

Ich will ja einfach nur, dass mein tiny die empfangenen Zeichen in 
irgendein arry speichert, damit ich information herausfiltern kann.

Mike schrieb:
> Gibt es da nicht eine einfacherere Lösung als mir softwaremäßig aus
> einer Usi eine Uart zu machen? - z.B. MOSI ?

Nein, gibt es nicht.

Andi D. schrieb:
> Doch! Er nimmt einfach einen anderen AVR COntroller, der eine UART
> besitzt... zB Attiny2313 etc..

Dadurch macht er aber nicht aus einer USI einen UART.
Natürlich hast du recht, der Umstieg auf einen anderen Controller wäre 
die sinnvollste Variante.
Man kann natürlich auch eine I²C/SPI to UART bridge nehmen, Sinn macht 
das allerdings auch keinen. Aber da er die Software ja schon quasi 
"vorgekaut" serviert bekommen hat (die Links von Spess), sollte der Rest 
ja auch kein Problem sein wenn man beim ATTiny25 bleiben möchte.

moin,

habe vor bald sowas ähnliches zu basteln.

Klaus Dieter schrieb:
> Aber da er die Software ja schon quasi
> "vorgekaut" serviert bekommen hat (die Links von Spess), sollte der Rest
> ja auch kein Problem sein wenn man beim ATTiny25 bleiben möchte.

habe mir die c-dateien noch nicht zu 100% angeschaut, ist ja auch schon 
ziemlich spät ;) aber du sagst also, dass man das ganze geschreibsel aus 
der datei einfach in die bestehende datei reinkopieren kann und dan 
damit im prinzip nur noch drauf wartet, dass die gpsmaus mir daten 
liefert und ich sonst nix mehr machen muss?

andere frage. ist der tiny25 überhaupt in der lage so eine "große" 
datenmenge an quellcode + datenmenge an gpssignal zu verarbeiten?

Hi

>andere frage. ist der tiny25 überhaupt in der lage so eine "große"
>datenmenge an quellcode + datenmenge an gpssignal zu verarbeiten?

Was verstehst du unter verarbeiten? Es kommt darauf an was er mit den 
verbleibenden 4 PINs machen soll.

MfG Spess

Was sollen diese Tinies? Die machen erst bei hohen Stueckzahlen Sinn. 
Was spricht gegen einen normalen Mega? Und auch nicht den 8er, der ist 
zu klein.

Klaus Dieter schrieb:
> Aber da er die Software ja schon quasi "vorgekaut" serviert bekommen hat >(die 
Links von Spess), sollte der Rest ja auch kein Problem sein wenn man
> beim ATTiny25 bleiben möchte.


Naja, vorgekaut ist das nicht gerade. Höchstens erwärmt, da hier die 
halbe libary verändert werden muss, um sie verwenden zu können. Gibt es 
denn nicht eine komplett fertige libary, die nach dem copy-paste 
verfahren direkt auf dem tiny genutzt werden kann? es kann doch nicht 
sein, dass es sowas nicht gibt.

welchen anderen uC würdet ihr empfehlen, mit dem ich direkt eine 
Datenübertragung durchführen kann, ohne mir vorher softwaremäßig 
Schnittstellen definieren muss.

Das die Tinys nur bei hohen Stückzahlen Sinn machen, sehe ich jetzt so 
auch nicht. Aber zum Basteln / Üben auf dem Steckbrett sehe ich in der 
Tat einen größeren Controller (z.B. ATMega32) als Sinnvoll an. Zum Einen 
hat man da eine Menge an Peripherie und muss sich (gerade als Anfänger) 
nicht mit dingen wie Soft-Uart/PWM oder was auch immer herumschlagen. 
Auch neigen Anfänger dazu, nicht gerade optimalen Code zu produzieren. 
Klar, ein größerer Flash ist kein Freischein für Spaghetticode, aber um 
die Anfangsfrustration so klein wie möglich zu halten, ist es glaube ich 
gar nicht mal schlecht, wenn der Code in den Controller passt und auch 
erstmal irgendwie funktioniert. Der geborene Bastler fängt dan von ganz 
alleine an, Dinge zu optimieren und zu verschönern (das hoffe ich 
zumindest) :-D
Um noch einmal auf das ursprüngliche Thema zu kommen: Ich habe mir jetzt 
nicht die Mühe gemacht, die AVR307 mal zu kompilieren (hab auch leider 
gerade keine IDE/Compiler zur Hand), aber ich denke, ein bisschen Luft 
wird da noch sein. Die Frage ist ja, was man mit den erhaltenen Daten 
anstellen möchte. Vielleicht wird sich der TE ja dazu mal äußern.

Wieso muss die ganze Library verändert werden? Sie liefert dir die 
Daten, die von deinem GPS Empfänger kommen. Das ist doch das was du 
wolltest, oder nicht?

Habe gerade gesehen, dass das für den IAR Compiler geschrieben ist, 
trotzdem ist das eine ganz brauchbare Basis.

Ich will damit die Geschwindigkeit ermitteln. Das ist auch kein Problem. 
Das Problem ist halt wie erwähnt, dass ich die Daten die mir der 
Empfänger liefert halt brauche, aber sie nicht auf den uC bekomme.

Nein, sie liefert mir keine Daten,da niemals ein interrupt ausgelöst 
wird. (habe das auch shcon auf meinen Compiler angepasst)

Dann hast du sicherlich irgendwo noch einen Fehler drin. Guck dir mal 
folgendes an:
Beitrag "Re: IAR vs. GCC"

Hi

>> Ich will damit die Geschwindigkeit ermitteln.

>Das heißt, dein eigentlicher Anwendungscode wird
>a) die empfangenen GPS-Daten zwischenspeichern müssen (zumindest einige
>Wegpunkte) und
>b) auch einiges an numerischer Rechnerei enthalten.

Nicht unbedingt. Im RMC-Datensatz ist 'Speed Over Ground' enthalten. Und 
VTG enthält die horizontale Geschwindigkeit in Knoten und km/h.
Wenn das reicht, braucht man nicht viel rechnen.

MfG Spess

>Milchbube schrieb:
> Was sollen diese Tinies? Die machen erst bei hohen Stueckzahlen Sinn.
> Was spricht gegen einen normalen Mega? Und auch nicht den 8er, der ist
> zu klein.

Cyblord...
So ein quatsch. Der Vorteil eines Tiny ist seine gringe Größe. Bei mir
gings um eine Modellfluganwendung, da kommts auf Größe und Gewicht an.
Nicht jeder bastelt nur fürs Steckbrett du Checker..

Naja, wenn Groesse ein Thema ist, das gibt's ja neben dem TQFP auch noch 
die MLF44 Gehaeuse. Dort ist ein Mega324 auch nur noch 7x7mm

Hi

>Naja, wenn Groesse ein Thema ist, das gibt's ja neben dem TQFP auch noch
>die MLF44 Gehaeuse. Dort ist ein Mega324 auch nur noch 7x7mm

Deswegen ist und bleibt die Aussage von Milchbube trotzdem Unsinn. 
Außerdem hat jemand, der einen ATMega32 vorschlägt entweder seit Jahren 
nichts mit AVRs gemacht oder hat sich nicht getraut neuere AVRs 
anzufassen weil es dafür keine Tutorials gibt. Die aktuellen ATTinys 
haben außerdem einige Features, die ATMegas nicht haben.

MfG Spess

spess53 schrieb:
> Nicht unbedingt. Im RMC-Datensatz ist 'Speed Over Ground' enthalten. Und
> VTG enthält die horizontale Geschwindigkeit in Knoten und km/h.
> Wenn das reicht, braucht man nicht viel rechnen.

Ja, genauso habe ich es realisiert. Habe mir vorher auf dem Papier die 
kmh in kts umgerechnet und dann die kts-Werte zur realiserung genutzt, 
da es nur 6 verschiedene Werte sind, bei denen etwas passieren soll.



Des Weiteren habe ich den Interrupt von Extern zu PinChange gemacht, da 
mein Gps-Signal auf Pin 0 angeschlossen ist und dort nur der PCINT0 zur 
Verfügung steht. Mein Problem ist allerdings, dass trotz Änderung des 
Pin 0 in der main nie ein interrupt ausgelöst wird. Was mache ich 
falsch?


void ssio_init(void)
{
  DDRB = (0<<PB0) | (1<<PB3);   // PB0: Input -> GPS-Daten , PB3: Output 
-> Schaltsignal

  PCMSK |= (1<<PCINT0);     //PC Int0 aktiv
  GIFR|=(1<<PCIF);      //PC Int aktiv
  GIMSK |= (1<<PCIE);       //PC Int aktiv

  /* Rx-Timer */
  TCCR0A = 
(0<<COM0A1)|(0<<COM0A0)|(0<<COM0B1)|(0<<COM0B0)|(1<<WGM01)|(0<<WGM00); 
// Timer zurücksetzen nach Vergleich
  OCR0A = 33;   /*208,3µs = 4800 Baud >> 32,5 * 6,4 µs @ 10MHZ mit 
Prescaler = 64*/
  TIMSK |= (1<<OCIE0A); //Timer Interrupt aktiv

}


ISR(INT0_vect)
{
    x = 1;
}

Hi

>Was mache ich falsch?

>ISR(INT0_vect)
>{
>    x = 1;
>}

Du willst nicht INT0. Du willst PCINT0! Also nimm auch den passenden 
Interrupt.

MfG Spess

Danke, manchmal sieht man den Wald vor lauter Bäumen nicht!

Trotzalle dem geht dieser Interrupt immer noch nicht, obwohl ich wie 
erwähnt den Pin seinen Zustand wechseln lasse.Weder bei In-, noch bei 
Output funktioniert das ganze.

Stimmen die Signalpegel?

Hi

>Trotzalle dem geht dieser Interrupt immer noch nicht,

Hast du die Interrupts auch global freigeschaltet?

MfG Spess

spess53 schrieb:
> Hi
>
>>Trotzalle dem geht dieser Interrupt immer noch nicht,
>
> Hast du die Interrupts auch global freigeschaltet?
>
> MfG Spess


Ja habe ich. Das komische ist aber, dass des I-FLag im Sreg manchmal 
durch die funktion "sei()" gesetzt wird und manchmal nicht.