Hallo zusammen! benötige dringend eure Hilfe! Ich benutze einen Attiny 25 und würde gerne kontinuierlich GPS-Daten auslesen, um diese im tiny weiter zu verarbeiten. Allerdings verstehe ich leider nicht ganz wie ich Schnittstellen definieren muss, um mein GPS-Signal im Controller auswerten zu können. Ich hoffe, dass mir da jemand weiterhelfen kann. Gruß, Mike
:
Verschoben durch Moderator
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.
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.
Klaus Dieter schrieb: > 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. Doch! Er nimmt einfach einen anderen AVR COntroller, der eine UART besitzt... zB Attiny2313 etc..
Ralf schrieb: > an dem GPS-Daten aus einem Navilock-Empfänger auszulesen bin ich > vor einiger Zeit gescheitert. Was war denn das Problem? Im Normalfall sollte man bei aktiviertem NMEA-Modus "von Daten erschlagen" werden. Grüße Stefan
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
Also ich hab mit einem tiny45 schon erfolgreich ein serielles GPS Modul ausgelesen. Ein einfacher Software USART reicht, nur dann kann der tiny halt sonst nicht mehr viel machen. Auch wenn man mit Interrupts arbeitet. Bei meinem Modul konnte man die Pakete einstellen die man will und die anderen abschalten. So hält sich die Menge in Grenzen. Außerdem konnte man die Baudrate senken und auch die Frequenz mit der die Pakete kommen. Danach muss man halt jedes Paket parsen und sich die Infos rausholen die man will. Mit der string.h ausm win-avr Projekt geht das ohne Probleme. Nur ich denke dem TE fehlt hier einfach noch ein wenig Wissen und Programmiererfahrung, das hört man nunmal deutlich aus den Fragestellungen raus. Und für eine Anfänger ist sowas eher nicht geeignet. Also klein Anfangen und erstmal die Grundlagen, inkl. der seriellen Schnittstelle an sich, verstehen. Auch ein wenig tieferes C-Wissen, also eben das ganze Pointer Zeug, Structs usw. wird hier gebraucht. Also Mike, wenn du nicht Fit mit der Hardware und in C bist, dann lass es erstmal! gruß cyblord
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.
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. 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.. gruß cyblord
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)
Mike schrieb: > 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. Dann solltest du ernsthaft überlegen, einen größeren AVR zu verwendet, der genügend RAM und Flash hat. (Und auch einen UART.) (Tipp: Einfach mal überschlägig ausrechnen, wie viele Bytes RAM allein die FIFOs für den UART und die Buffer für die Empfangsdaten belegen. Du wirst dich wundern.) Es ist wesentlich angenehmer, wenn man keine Klimmzüge machen muss, um das letzte Byte des Programms oder der Daten auch noch unterzubekommen. Grüße Stefan
Dann hast du sicherlich irgendwo noch einen Fehler drin. Guck dir mal folgendes an: Beitrag "Re: IAR vs. GCC"
software-uart sind doch nur ein paar zeilen code, und bei der langsamen datenrate auch kein problem, er muss ja auch nur rx umsetzen, tx braucht er nicht, das ding sendet ja von alleine hier mal ein bsp mit 57600Baud
1 | u8 sio_rx_state; |
2 | u8 sio_rx_byte; |
3 | |
4 | void ssio_init(void) |
5 | {
|
6 | DDRB &= ~(1<<2); /*interrupt*/ |
7 | MCUCR |= ((1<<ISC01)|(0<<ISC00)) /*fallende flanke*/; |
8 | GIFR|=(1<<INTF0); |
9 | GIMSK |= (1<<INT0); |
10 | /* Rx-Timer */
|
11 | TCCR0A = (0<<COM0A1)|(0<<COM0A0)|(0<<COM0B1)|(0<<COM0B0)|(1<<WGM01)|(0<<WGM00); |
12 | OCR0A = 139; /*17,361µs = 57600 Baud >> 138,8 * 0,125µs @ 8MHZ*/ |
13 | TIMSK |= (1<<OCIE0A); |
14 | }
|
15 | |
16 | |
17 | ISR(INT0_vect) /* StartBit - Fallende Flanke*/ |
18 | {
|
19 | GIMSK &= ~(1<<INT0); /*interupt ausschalten und Timer starten nach dem 10. Bit wird der Int wieder eingeschaltet */ |
20 | TCNT0 = 0; |
21 | sio_rx_state=0; |
22 | TCCR0B = (0<<FOC0A)|(0<<FOC0B)|(0<<WGM02)|(0<<CS02)|(0<<CS01)|(1<<CS00); /* Timer starten - kein vorteiler */ |
23 | }
|
24 | |
25 | /* Rx - Timer */
|
26 | ISR(TIMER0_COMPA_vect) |
27 | {
|
28 | if(sio_rx_state<8) |
29 | {
|
30 | sio_rx_state++; |
31 | sio_rx_byte>>=1; |
32 | if(PINB & (1<<2)) sio_rx_byte |= 0x80; |
33 | }
|
34 | else
|
35 | {
|
36 | TCCR0B = 0; /*timer stoppen*/ |
37 | GIFR |=(1<<INTF0); /*interrupt wieder an*/ |
38 | GIMSK |= (1<<INT0); |
39 | if(PINB & (1<<2)) /* stop-bit = 1*/ |
40 | {
|
41 | /*
|
42 | hier wurde das byte empfangen und liegt in "sio_rx_byte"
|
43 | */
|
44 | }
|
45 | }
|
46 | }
|
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
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. Stimmt. Da ich das bislang nie brauchte, hatte ich das nicht mehr in Erinnerung. (Meine GPS-Empfänger stehen fix, ich brauche nur das 1PPS-Signal, die exakte Zeit und den Ort.) Grüße Stefan
>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.
Hi
>Trotzalle dem geht dieser Interrupt immer noch nicht,
Hast du die Interrupts auch global freigeschaltet?
MfG Spess
Morz Kerl schrieb: > 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 Ja na und? Haben wir übers Gehäuse geredet? Ich verwende auch einen tiny45 im SO8 Gehäuse. MLF44 zu löten ist nochmal ne andere Baustelle. Und da ist nunmal ein tiny in SO8 ein guter Kompromiss. Aber darum gings doch gar nicht. Was soll das denn? Immer diese pauschalen Null-Aussagen. Da Atmel Tinys produziert wird es auch Abnehmer geben. Also haben sie wohl auch ihre Berechtigung. Oder sind die alle doof und nur ihr wisst Bescheid? Die neuen Tinys sind wirklich Klasse von der Ausstattung her. Aber Spess hat schon recht, wer einen Tiny45 mit einem Mega32 ersetzen würde, der hat sowieso keine Ahnung mehr was um ihn rum so passiert. gruß cyblord
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.