@dannyboy1994
Das sind nur Grundlagen zum anfangen und dient nur zur Zusammenfassung ob alle nötigen Kommandos vorhanden sind. Damit man sie mal alle durch den Simulator schicken kann. Da ist noch keine Feinarbeit gemacht. Obs in die INIT gehört hängt davon ab was man will vllt interessierts ja einen was vllt mal nach nem Kaltstart in der Kiste drin steht
Die Unterroutinen sind so aufgebaut das R17=Temp1=MSB und R16=temp0=LSB ist und auch so nutzbar sind, um darin direkt die Nutzdaten zum RFM zu schicken. Aber effektiver wäre es die Daten in dem SRAM abzulegen und mit dem Pointer rauszuholen das ganze in einer Schleife verpackt.
Zum Verständniss ist es besser alles aufzuführen. Das ist so nicht ganz richtig aber korrigiere mich falls ich mit der Vermutung (Aufgrund fehlender Hardware RFM) falsch liege.
Das load_TM_Reg_write_cmd dient ja zum umschalten in den TX-MODE und das muss 16bit breit geschickt werden.
Jetzt ist die Frage wie verarbeitet der RFM dieses CMD, nur als 16bit? Heißt wenn man das UmschaltCMD und Daten gleichzeitig schickt werden die dann auch so erkannt? Wenn nicht dann musst du ein Datendummy mitschicken in diesem Falle $x0. Klar ich hätte die Datenbits nicht deklarieren müssen, dass ist wohl wahr, dient aber der Veranschaulichung wo die Bits sitzen.
Sollte er aber nur 8bit brauchen dann brauchst du nur das load_TM_Reg_write_cmd mit dem MSB losschicken, eine kurze Pause vllt von 3nop's und kannst dann mit dem reinen Datentransfer beginnen. Aber ich sehe gerade das mit dem
Configuration Control Command bit et=1 die Sache parallel (die 2x8bit Schiftregister) geschaltet wird somit kannst du dann wieder ein Doppelbyte rüberschicken. Somit wäre es geklärt, das man vorher, also um in den TX-Mode zu kommen, MSB:LSB komplett rüberschicken muss.
Die Präambel ist ja ne Kann-Bestimmung und hängt ja davon ab was die Anfordrungen sind.
Warum ? o.0 guck ins Datenblatt dort steht es 1 zu 1 so drinne ause bei meinen Dekalrationen denn der AVR hat auch r0-r8 deshalb mal andere Schreibweisen bzw Doppelbenutzungen
Jetzt muss ich mal fragen: du schickst jedes mal das TM_Reg_write_cmd = ($C8) mit, ich verstehe das eher so das du diese CMD nur zu Beginn der Übertragung sendest plus EL-Bit =1 und dann kann man die Nutzdaten direkt im Anschluss schicken ? Oder dient das nur um TX/RX im Datenfluss zu synchrionisieren?
@LotadaC
Na was heißt gibs nicht ? SDO = SERIELL DATA OUT
Wenn dem so ist das die Pegel fest sind, im 3WireMode dann ist es doch ok nur ich wollte darauf aufmerksam machen, das man hier 3 Schnittstellen mit einem Interface implementieren kann. Nicht gleichzeitig versteht sich.
Wie gesagt ich hab mich jetzt nur am Rande mit der USI beschäftigt da sie bei anderen AVR's ausgelagert sind bzw beim ATM8 gar nicht vorhanden ist wohl der Anzahl der Pins geschuldet....
Zu der Taktfrequenz: ja für den RFM ist es nicht ausgereizt, der Controller schafft das auch, wenn er kann. Wenn jmd zum Beispiel auf nem Steckboard mit 10Mhz SCK arbeiten will aber weite Leitungen hat, Freiluftverdrahtung, und die Software i.O. ist sucht sich dennoch nen Wolf warum das Ding nicht macht was es soll obwohl alles passt. Die Freiverdrahtung wirkt wie Antennen. Man muss immer von den schlechtesten Bedingungen ausgehen.
Ich denke du meinst den Timer0 den man ja auch laut Tabelle nutzen kann. Timer0=SCK da sie auf dem gleichen Pin liegen
Schleifenprogrammierung sollte man versuchen zu erreichen Kopf/Fussgesteuert das muss man halt der Aufgabe anpassen. So wie es im DB als erstes drinen steht für die USI find ich es angenehemer.
Zur RS232 wenn man nicht die Geschwindigkeit während des Betriebs ändern muss brauch man es nur 1 mal initen.
0.o Tabelle 15-2 sagt was anderes 3te Zeile siehe Bild das ist die Verbindung mit dem Timer0 deshalb meine Irritiertheit das man dort den Takt zu Fuss, obwohl HW vorhanden ist, erzeugen muss/kann.
Naja 7 deshalb da man hier bei 0 anfängt zu zählen, 0-7 sind 8 Takte.
entweder wählt man einen Takt der einem genügens Zeit lässt Daten nach zu holen oder wie du schon schreibst man stoppt die Kiste. Da bräuchte man nur TCCR0B CS2:0 auf 0 setzen sind gerade mal 3Takte der CPU-Frequenz sollte machbar sein.
Jepp genauso dacht ich
guck mal Seite 15 ganz oben
Bits 9-8(d1 to d0): VDI (valid data indicator) signal response time setting:
Verhalten bei gültigen Daten das er Meldung macht bei Gültigkeit schau dir Seite 15 an das Blockschaltbild
puuuuhhhhh immer soviel zu schreiben ich vermiss das irgendwie Leute ein Gegenüber zu sitzen zu haben das erklärt sich 1000 mal besser....
Das sind nur Grundlagen zum anfangen und dient nur zur Zusammenfassung ob alle nötigen Kommandos vorhanden sind. Damit man sie mal alle durch den Simulator schicken kann. Da ist noch keine Feinarbeit gemacht. Obs in die INIT gehört hängt davon ab was man will vllt interessierts ja einen was vllt mal nach nem Kaltstart in der Kiste drin steht
umstricken das sie msb und lsb jeweils in einem register(bei mir heißen sie auch so) erwartet
Die Unterroutinen sind so aufgebaut das R17=Temp1=MSB und R16=temp0=LSB ist und auch so nutzbar sind, um darin direkt die Nutzdaten zum RFM zu schicken. Aber effektiver wäre es die Daten in dem SRAM abzulegen und mit dem Pointer rauszuholen das ganze in einer Schleife verpackt.
Bei
load_TM_Reg_write_cmd
muss ich dir allerdings widersprechen. hier macht es keinen sinn das LSB zu verändern den das sind ja die daten die gesendet werden sollen.
Zum Verständniss ist es besser alles aufzuführen. Das ist so nicht ganz richtig aber korrigiere mich falls ich mit der Vermutung (Aufgrund fehlender Hardware RFM) falsch liege.
Das load_TM_Reg_write_cmd dient ja zum umschalten in den TX-MODE und das muss 16bit breit geschickt werden.
Jetzt ist die Frage wie verarbeitet der RFM dieses CMD, nur als 16bit? Heißt wenn man das UmschaltCMD und Daten gleichzeitig schickt werden die dann auch so erkannt? Wenn nicht dann musst du ein Datendummy mitschicken in diesem Falle $x0. Klar ich hätte die Datenbits nicht deklarieren müssen, dass ist wohl wahr, dient aber der Veranschaulichung wo die Bits sitzen.
Sollte er aber nur 8bit brauchen dann brauchst du nur das load_TM_Reg_write_cmd mit dem MSB losschicken, eine kurze Pause vllt von 3nop's und kannst dann mit dem reinen Datentransfer beginnen. Aber ich sehe gerade das mit dem
Configuration Control Command bit et=1 die Sache parallel (die 2x8bit Schiftregister) geschaltet wird somit kannst du dann wieder ein Doppelbyte rüberschicken. Somit wäre es geklärt, das man vorher, also um in den TX-Mode zu kommen, MSB:LSB komplett rüberschicken muss.
Die Präambel ist ja ne Kann-Bestimmung und hängt ja davon ab was die Anfordrungen sind.
Auch muss ich mich erst einmal durch deinen bezeichnugen kämpfen. Aber die grundsätzliche Struktur des ganzen finde ich gerade wirklich faszinierend.
Warum ? o.0 guck ins Datenblatt dort steht es 1 zu 1 so drinne ause bei meinen Dekalrationen denn der AVR hat auch r0-r8 deshalb mal andere Schreibweisen bzw Doppelbenutzungen
Jetzt muss ich mal fragen: du schickst jedes mal das TM_Reg_write_cmd = ($C8) mit, ich verstehe das eher so das du diese CMD nur zu Beginn der Übertragung sendest plus EL-Bit =1 und dann kann man die Nutzdaten direkt im Anschluss schicken ? Oder dient das nur um TX/RX im Datenfluss zu synchrionisieren?
@LotadaC
Na was heißt gibs nicht ? SDO = SERIELL DATA OUT
Wenn dem so ist das die Pegel fest sind, im 3WireMode dann ist es doch ok nur ich wollte darauf aufmerksam machen, das man hier 3 Schnittstellen mit einem Interface implementieren kann. Nicht gleichzeitig versteht sich.
Wie gesagt ich hab mich jetzt nur am Rande mit der USI beschäftigt da sie bei anderen AVR's ausgelagert sind bzw beim ATM8 gar nicht vorhanden ist wohl der Anzahl der Pins geschuldet....
Zu der Taktfrequenz: ja für den RFM ist es nicht ausgereizt, der Controller schafft das auch, wenn er kann. Wenn jmd zum Beispiel auf nem Steckboard mit 10Mhz SCK arbeiten will aber weite Leitungen hat, Freiluftverdrahtung, und die Software i.O. ist sucht sich dennoch nen Wolf warum das Ding nicht macht was es soll obwohl alles passt. Die Freiverdrahtung wirkt wie Antennen. Man muss immer von den schlechtesten Bedingungen ausgehen.
LotadaC schrieb:Du kannst, statt der sechzehn abwechselnden USICLK und USICLK+USITC Strobes auch einfach den Zähler/das Schieberegister auf den eigenen USCK koppeln, und den so Takten, als wenn es extern wäre.
also sechzehnmal
Ich denke du meinst den Timer0 den man ja auch laut Tabelle nutzen kann. Timer0=SCK da sie auf dem gleichen Pin liegen
Schleifenprogrammierung sollte man versuchen zu erreichen Kopf/Fussgesteuert das muss man halt der Aufgabe anpassen. So wie es im DB als erstes drinen steht für die USI find ich es angenehemer.
Zur RS232 wenn man nicht die Geschwindigkeit während des Betriebs ändern muss brauch man es nur 1 mal initen.
LotadaC schrieb:aber USI besitzt keinerlei Anbindung an den Systemtakt.
0.o Tabelle 15-2 sagt was anderes 3te Zeile siehe Bild das ist die Verbindung mit dem Timer0 deshalb meine Irritiertheit das man dort den Takt zu Fuss, obwohl HW vorhanden ist, erzeugen muss/kann.
Naja 7 deshalb da man hier bei 0 anfängt zu zählen, 0-7 sind 8 Takte.
entweder wählt man einen Takt der einem genügens Zeit lässt Daten nach zu holen oder wie du schon schreibst man stoppt die Kiste. Da bräuchte man nur TCCR0B CS2:0 auf 0 setzen sind gerade mal 3Takte der CPU-Frequenz sollte machbar sein.
Jepp genauso dacht ich
LotadaC schrieb:Bei Tinies mit gepuffertem USIDR (betrifft nur den Empfang), kanns Du nach einem komplett(!) übertragenem Byte das nächste übertragen lassen, und währenddessen das empfangene Byte aus dem Bufferregister laden (bevor das nächste komplett durch ist, klar).
Sagt mal weis nun einer für was der VDI pin gut is wenn man ihn als solchen konfiguriert?
guck mal Seite 15 ganz oben
Bits 9-8(d1 to d0): VDI (valid data indicator) signal response time setting:
Verhalten bei gültigen Daten das er Meldung macht bei Gültigkeit schau dir Seite 15 an das Blockschaltbild
puuuuhhhhh immer soviel zu schreiben ich vermiss das irgendwie Leute ein Gegenüber zu sitzen zu haben das erklärt sich 1000 mal besser....
Anhänge
Zuletzt bearbeitet: