12MHz. wobei der teil vom code nicht von mir ist, sondern von andreas weber; will sagen, ich hab keine ahnung, ob das "nop" zur sicherheit drin ist oder weil es nötig ist.
ciao,
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
** http://www.vibe.at/ ** http://quintessenz.org/ ** sig@foo.woas.net
Those silly RFCs are all that separate us from the animals!
-- Kevin Rodgers in a.r.e
Das weiss ich doch alles. Glaubst du es hat mir Spass gemacht persoenlich mit den Portpins rumzuwackeln? Aber ich musste halt nehmen was im Palmpilot noch uebrig war.
Das ist ja schoen. Aber erstmal musst du doch wohl ueberhaubt die Sache ans laufen bekommen, danachst kannst du es dir doch dann umstricken wie du es haben willst.
Dann ist deine Schaltung schlecht? Sonst bleibt doch da nicht viel wenn es sonst ueberrall laeuft.
Nein, auch das habe ich noch nicht probiert. Falls die Variante mit dem verlängerten Statusread auch nichts wird, werde ich als nächstes das versuchen. Würde mir aber nicht wirklich gefallen, denn das kostet ein Portpin. Die gegenwärtige vollständige Anschlußvariante ist ja nur zum Testen vorgesehen, in der Endanwendung sollen natürlich so wenig wie möglich Pins für die Anbindung genutzt werden.
Das ist nicht völlig auszuschließen, halte ich aber angesichts der Tatsache, daß die sonstige Kommunikation problemlos funktionert und ich Pegel und Flanken mit einem Oszi überprüft und für gut befunden habe, für ziemlich unwahrscheinlich.
Es läuft eben nicht sonst überall. Es gibt mehrere Threads bei Microcontroller.net, die exakt das bei mir aufgetretenen Phänomen beschreiben und allesamt ohne Lösung im Sande verlaufen.
Hm..ich hatte obigen Satz eigentlich ironisch gemeint da man bei den paar Leitungen fuer den SPI-Bus nicht viel Falsch machen kann. Besonders dann wenn die Kommunikation ansich ja schon laeuft.
Mir ist uebrigens gerade wieder eingefallen warum ich erst ein Problem hatte. Ich habe es bei mir ja im Palmpiloten eingebaut und musste nehmen was an Ports da war. Da war auch eine Leitung die eigentlich mal als DTR fuer die RS232 gedacht war und da hing noch ein ein Widerstand dran den ich uebersehen hatte der eine Flanke etwas traege gemacht hat. Und ich weiss noch das ich auch erst das Problem hatte das ich die Register problemlos schreiben konnte, also z.B die Clock einstellen konnte. Bloss echte Daten habe ich so nicht richtig rausbekommen.
Ich hab mir dazu folgendes notiert:
/* PM7 Ist der GPI2 Eingang des Palms am Craddle 330R */
/* Dateneingang vom RFM12 Modul */ int RF12_DATA_in(void) { return( read_PM7() ); };
Soll heissen der Palm hatte da noch 330R in Serie an seinem Porteingang. Das war bereits soviel das die Flanke am SPI Dateinangang, also dem Ausgang des RF12 nicht mehr ausreichend war. Fand ich eigentlich erstaunlich da 330R ja noch nicht so die Welt sind. Schau dir also diese Leitung nochmal ganz genau an. Eventuell bau mal ein Gatter dazwischen.
bist du sicher das du Denn SPI richtig eingestellt hast? IMHO hat der AVR mindestens 4 Spielarten für SPI in Hardware Implementiert. Ist leider Schon etwas her aber vielleicht Triggerst du einfach die Flasche Flanke oder sowas. Denn leider ist bei genauen hinsehen das SPI nicht so deutlich Definiert wie man es gerne hätte.
Du willst nicht sagen, dass Du davon ausgehst, dass amerikanische Firmen auf Anfragen aus Deutschland anworten würden? Ich hab da andere Erfahrungen gemacht. Ich wollte sogar richtig was kaufen, und sie haben mir nicht geantwortet.
Als ich noch in Deutschland war, bekam ich aus USA eigentlich immer Antwort. Allerdings hat der Service in letzter Zeit enorm nachgelassen. TI ist z.B. derzeit die schlimmste Firma bei mir. Ueber einen Monat warte ich auf eine Antwort auf eine technische Frage. Habe das dem lokalen FAE gegeben, und selbst der hat bisher nichts rausbekommen. Na ja, die haben dieses Design-In jetzt genauso verloren wie Infineon. Hab's fuer den Kunden wie ueblich in diskreter Schaltung erledigt, sollen sie ihre Chips wem anders verticken.
Wie auch immer, man kann es ja zumindest versuchen.
Noch nicht im Thread erwähnt wurden die Syncronisation der Chips. Falls zwischen den Flanken zuviel Verzug liegt, klappt das nicht immer. Steigende und fallende Flanke sind in Datenblättern gelegentlich mal verwechselt worden.("Yes, we know about typos in the data sheet and will correct this soon"; war schon ein Jahr später korrigiert:-(( )
Ja. Aber anhand der bekannten und wohl fast überall funktionierenden Bitbanging-Routinen war es leicht, herauszufinden, welche der vier Varianten ich verwenden muß, nämlich die mit CPHA=0 und CPOL=0.
Da es aber mit minimalsten Änderungen am Code leicht realisierbar ist, habe ich eben noch mal schnell auch die anderen drei Varianten ausprobiert. Mit zwei davon geht garnix (es läßt sich also z.B. nicht mal ein Wakeup generierieren) und mit der dritten versteht der RFM12 zwar meine Kommandos (z.B. Wakeup-Interrupt wird nach zwei Sekunden wie angewiesen ausgelöst) aber die gelesenen Daten beim Statusread-Kommando enthalten dann Müll. Die ursprünglich gewählte Variante dürfte also tatsächlich die richtige sein.
Beim herumspielen wegen des SPI habe ich dann bemerkt, daß das entsprechende Bit in den Interruptflags nicht gesetzt wird, wenn der Wakeup-Interrupt ausgelöst wurde. Das betrifft genauso den über nINT auszulösenden externen Interrupt, der wird zwar ordentlich über nIRQ zurückgegeben, aber das entsprechende Bit in den Statusflags ist dann nicht gesetzt.
Das war SEHR interessant. Nach ein wenig rumprobieren habe ich dann noch festgestellt, daß sämtliche Interruptflags, die eigentlich erst durch Statusread zurückgesetzt werden sollten (also eigentlich alle außer RGIT/FFIT), niemals gesetzt erscheinen, auch wenn sie es müßten, mit Ausnahme des POR-Bits. Das wiederum verhält sich wie erwartet.
Z.B.: RGUR/FFOV. RGUR müßte ja irgendwann kommen, wenn man den Sender laufen läßt, aber die TX-Register nicht weiter mit Daten füttert. Passiert aber niemals. Wenn man auf den RGIT-Interrupt nicht damit reagiert, das nächste Byte zu schreiben, hängt sich der Kram stattdessen lieber auf und ist nur dadurch wieder zum Leben zu erwecken, daß man entweder kurz das Senderegister per SetConfig-Kommando ab- und wieder anschaltet oder gleich per nRES einen Reset auslöst. Prinzipell dasselbe auch im Empfangsbetrieb: Wenn man dort aufhört, auf FFIT damit zu reagieren, ein Byte vom FIFO zu lesen, sollte irgendwann FFOV kommen. Tut aber nicht. Statt dessen friert die Sache ebenfalls ein und ist adäquat zum Schreiben nur durch nRES oder eben durch Ab- und Anschalten diesmal des FIFO wiederzubeleben. In diesem "eingefrorenen" Zustand (egal ob Unterlassung beim Senden oder Empfangen die Ursache war), funktionieren übrigens weder Wakeup noch externer Interrupt. Ich muß mal messen, was eigentlich der nIRQ-Pin in diesem Zustand für einen Pegel hat, vermutlich Dauer-Low. Statuslesen in diesem Zustand liefert nur konstant gesetztes RGIT/FFIT, auch die Statusbits des Empfängers wackeln dann nicht mehr wie sonst, sondern sind konstant.
Nach diesen ganzen Befunden fiel mir mit Schrecken ein, daß das Modul überhaupt erst zu halbwegs normaler Arbeit zu überreden war, nachdem ich dessen "sensitive reset" abgeschaltet hatte. Ich werde also mal die Stromversorgung des RFM12 von der meines Controllers HF-mäßig besser trennen. Vielleicht kommen darüber irgendwelche Glitches, die das Modul zu seinem unsinnigen Verhalten treiben und die mit meinem lendenlahmen Oszi nicht mehr erfaßbar sind.
Wenn's das wirklich ist, dann fresse ich einen Besen. Mit Stiel!
Ich kann bestätigen, dass sowohl RGUR als auch FFOV bei meinen Modulen in den entsprechenden Situationen ausgelöst werden. Ein Aufhängen habe ich nie beobachtet. Das spricht dafür, dass Du entweder tatsächlich defekte Module hast oder
- wie Du vermutest - etwas mit dem Aufbau nicht stimmt.
Danke, das ist eine Information, die für mich überaus wichtig ist.
Wenn es nicht zuviel verlangt ist: Könntest du auch mal den externen Interrupt bei dir diesbezüglich testen? Wäre sehr nett, wenn du das machen könntest.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.