Hallo, ich habe ein Problem bei meiner SPI Übertragung. Wenn ich die Daten per Logic Analyser am Ausgang des uC anschaue, bekomme ich nie die Daten die ich in den Datenpuffer geschrieben habe. Meiner Meinung nach werden die Daten nicht richtig in den Puffer übernommen. Im Anhang ist ein Screenshot vom Logic Analyser, nach dem Senden von 0x00. Was auf dem Bild zu sehen ist, entspricht jedoch 0xEF und nicht 0x00!! Einen Fehler in der SPI Initialisierung kann ich ausschließen. Kann es sein dass die Daten nicht stimmen da die SPI Schnittstelle unbeschaltet ist? Greife die Daten (MOSI - Leitung) über einen Serienwiderstand ( 470 Ohm ) direkt am uC ab. Mfg, Mathias
Angehängte Dateien:
-
spi.JPG
68 KB
muss der Datenbuffer ausgelesen werden, bevor man neue Daten hineinschreiben kann?
NEIN ich kenne deinen Code nicht, ich denke auch nicht das es daran liegt, aber man darf nix in das register reinschreiben solange noch rausgetaktet wird....
Kann es sein, dass das SPI Probleme mit der Verwendung des internen Quarzes hat (7.3728Mhz) => LPC936
"keiner eine ahnung was das sein kann?" Naja, den LPC936 benutzen (hier) wohl nicht sehr viele. Außerdem reichlich spät, daß Du damit rausrückst. Mit fehlenden fundamental wichtigen Angaben kann man schnell jemanden vergnatzen. Peter
"Kann es sein, dass das SPI Probleme mit der Verwendung des internen Quarzes hat" Kein MC hat Probleme mit den internen Quarz, da keiner einen internen Quarz hat ! Wäre ja viel zu teuer sowas. Guck Dir mal die Preise von RTC-Bausteinen mit internem Quarz an. Der interne RC-Oszillator macht nur Probleme bei UART oder RTC-Anwendungen. Peter
lpc901 hat einen internen 7.3728Mhz Quartz und kostet bei größeren stückzahlen um die 80Cent!! genau genommen hat die ganze lpc900 serie einen internen quarz! Das problem hab ich übrigens gelöst. lag daran, dass ich ein übersprechen der leitung am logicanalyser hatte.... somit hatte ich bei jeder pos. flanke von clk bzw. cs einen kurzen impuls auf mosi!
da frage ich mich, was der Unterschied zwischen einem RC- und einem Quarz-Oszilator ist. In diesem Dokument steht nur was von RC-Oszillator: http://www.semiconductors.philips.com/acrobat/datasheets/P89LPC901_902_903-02.pdf
auf jeden fall habe ich schon mehrere projekte mit einem lpc931 realisiert und dabei den internen quartz verwendet! sehr genau ist das ganze natürlich nicht, aber zuwas auch. wenn ich damit eine uhr machen will verwende ich ja so und so einen externen takt wie zb. den ds32khz oder überhaupt einen rtc mit integriertem, temperaturstabilem quartz
"und dabei den internen quartz verwendet!" Dann verrate mal, wie Du etwas verwendest, das gar nicht existiert ! Im Datenblatt steht nämlich nur: "On-Chip RC oscillator Option" "sehr genau ist das ganze natürlich nicht" Weil es eben kein Quarz ist ! Peter
Vielleicht hat da jemand Probleme, den Unterschied zwischen Quarz und Oszillator zu verstehen...
Angehängte Dateien:
-
rcoszi.jpg
48 KB
lol @ peter nur kann ich das ganze programm mit dem rc ocsillator laufen lassen ( mehrere LPC931 Projekte von mir funktionieren so ohne Probs.) und sogar die oszillator pins alls i/o pins verwenden kannst es ja selber probieren, wenn du lust und laune dazu hast.. einfach in der startup datei bzw. in der configuration den int. rc oszillator auswählen und laufen lassen im anhang noch eine art "beweis", dass man keinen ext. quarzt benötigt
1. hat der LPC eine internen RC-Oszillator (deiner Meinung nach war der interne Quarz kaputt o.ä) 2. Bei SPI ist die Übertragungsgeschwindigkeit ziemlich egal, da es sich um eine synchrone Datenübertragung handelt; der Takt wird also auf einer separaten Leitung übertragen, und muß nicht wie bei asynchroner Übertragung durch den Empfänger erzeugt werden. 3. Was ist das den fürn Beweis? Zeigt nur, was ich in 1.) schon geschrieben habe.
k @ peter ich habe keinen internen quarzt sondern den int. rc oszillator verwendet. wollte eben nur wissen ob der rc oszillator mit spi probleme hat... hat er jedoch nicht.. ob es probleme mit dem uart gibt wage ich zu bezweifeln, da man ja auf den int. baudragengenerator zurückgreifen kann, welcher sich vom rc oszillator ableitet. Dass man auf eine begrentzte anzahl von baudraten beschränkt ist ( genau genommen 9), muss man halt dann in kauf nehmen. bei den 9 baudraten ist jedoch gewährleistet dass die toleranz in einer gew. grenze gehalten wird, damit der empf. noch richtig abtasten kann
@ rahul: 1: jupp habe den oszillator mit dem quartz verwechselt => sry 2. eigentlich logisch 3. stimmt wohl :-) => dann noch ein schönes we
Hallo @ all Ich möchte 2 Bytes über die SPI-Schnittstelle übertragen. Jedoch wenn ich die SPI-Clock-Leitung messe, dann sind 10 Takte zwischen der Übertragung des 1. Bytes und der Übertragung des 2. Bytes pause. // 1. Byte übertragen SPDR = 0x01; //warten bis das 1. Byte übertragen ist while(!(SPSR & 0x80)); Hier zwichen ist eine lange Pause. Ich denke mal das der Whilevergleich einfach zu lange dauert. Gibt es da keine bessere Alternative die nicht so lange dauert? // 2. Byte übertragen SPDR = 0x01; // warten bis 2. Byte übertragen wude while(!(SPSR & 0x80));
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.