Assembler RFN12b an Tiny44 und Tiny2313 via USI

[dannyboy1994]

hallo dirk *wink*
ja SS ist vorher high und SCK low.
Leider will nun mein usart auf dem mega nicht. den Tiny hab ich geflasht mit der software lösung. leider kein wert der im statusregister stehen müsst(angeblich 0x4000 nach init). Das alles ist wirklich sehr seltsam und erschreckend ist das es zwar lösungen zum RFM12 im netz gibt aber, ich will ja kein fertiges produkt sondern bin eher auf der suche nach hinweisen oder hilfestellugen. Und die fertigen Programme wie z.B. hier https://www.mikrocontroller.net/attachment/201795/tn13rfm.asm
sind für mich leider sehr undurchsichtig. Lösungen in C sind hingegen ein schlag ins genick.:/ ich zweifel gerade an meinem verstand. Die MOdule können ja wohl kaum defekt sein... hoffe ich zumindest sehr..
kannst du aus dem oben genannten link etwas informatives gewinnen. Manchmal hab ich auch das gefühl dasi ich mich einfach doof anstell. Danke für all eure mühen.

 

[Dirk]

... kannst du aus dem oben genannten link etwas informatives gewinnen.

Hmmm, dafür ist es für mich jetzt leider schon zu spät. Es tut mir leid

Ich würde schauen, wie dort der RFM12 initialisiert wird, also welche Initialisierungswerte geschrieben werden. Diese auch mit deinen vergleichen.

 

[dannyboy1994]

Kein Problem dirk ich seh grad 22:30...ich muss um 5 wieder raus.. der schreiber des programms benutzt "ldiw" so ähnlich wie "load immidiate Word" was aber AVR Studio nicht kennt. soll angeblich auf nem tiny13 laufen...

 

[LotadaC]

"LDIW" kennt auch das Instruction Set nicht - kann natürlich auch ein eigenes Makro oderr so sein.
Deine beiden Tinies kennen "ADIW", welches eine Konstante (6Bit) auf eines der vier Doppelregister X, Y, Z oder R24:R25 addiert.

 

[Dirk]

"LDIW" kennt auch das Instruction Set nicht - kann natürlich auch ein eigenes Makro oderr so sein.

Genau,
so könnte das Macro aussehen ...


CodeBox Assembler

.macro    ldiw
;
; Writes a 16-bit immediate value to a 16-bit wxyzH/wxyzL register pair.
; Usage: ldiw W[or X, or Y, or Z],value.
; *** Note: WL/WH must be .def'd somewhere ***
;
   ldi    @0L,low(@1)
   ldi    @0H,high(@1)
.endm

 

[dannyboy1994]

Noch ein versuch... ich komme leider erst später zum testen



CodeBox Assembler

;*********************************************
;Daten in X Doppelregister
;Zu definieren sind nsel, spiport, sdi sdo sck, spipin, spiddr
;Register genutzt: XH, XL, counter
;genutzt wird delay routinen aus stddelay
;
;FUNKTIONEN: send_command=sendet ein Word aus dem Doppelregister X
;        RFM_init=initialisiert das RFM MOdul 868Mhz Version
;        readFIFO=liest den FIFO aus und speichert das Ergebniss im Doppelregister X
;**********************************************

readFIFO:

ldi temp1, 0xB0       ;Highbyte(befehl für lesen)
read:
cbi spiport, sck
cbi spiport, sdi
marker01:
cbi spiport, nsel   ;Nsel auf low
marker02:
sbis spiport, sdo   ;warten bis SDO high(RFM bereit)
rjmp marker02
ldi counter, 8       ;8

marker03:
cbi spiport, sdi
sbrc temp1, 7
sbi spiport, sdi
nop
sbi spiport, sck
rcall delay1ms
cbi spiport, sck
lsl temp1
dec counter
brne marker03
;;;DAS KOMMANDO(HIGHBYTE) WURDE ÜBERTRAGEN

daten0:
clr temp1
ldi counter, 8
daten1:
lsl temp1       ;datenregister schieben
sbic spipin, sdo   ; wenn sdo=0 weiter
sbr temp1, 0       ;wenn nicht bit 0 in register setzen
           ;SCK Impuls
sbi spiport, sck
rcall delay1ms
cbi spiport, sck

dec counter
brne daten1

;Datenbyte müsste nun in temp1 stehen

mov XL, temp1       ; nach XL kopieren
sbi spiport, nsel   ;nsel wieder auf high

;; NUN FIFO deaktivieren
push XL           ;daten sichern
ldi XL, 0x80
ldi XH, 0xCA
rcall send_command
pop XL
ret





send_command:
;;DAS KOMMANDO STEHT IM DOPPELREGISTER X
cbi spiport, nsel   ;Nsel auf low
nop nop nop       ;bissl warten
ldi counter, 16
marker0:

cbi spiport, sdi   ;Datenausgang auf HIGH
sbrc XH, 7       ;Wenn das erste bit= 0 überspringen
sbi spiport, sdi   ;Wenn nicht auf High setzen
rcall delay1ms       ;kleines delay
sbi spiport, sck   ;SCK auf high
rcall delay1ms       ;warten
cbi spiport, sck   ;SCK low

lsl XL
rol XH           ;Doppelregister links schieben

dec counter       ;counter 1 runter
brne marker0
rcall delay1ms       ;warten
sbi spiport, nsel   ;nsel auf high
ret


RFMinit:
sbi spiddr, sdi
sbi spiddr, sck
sbi spiddr, nsel
sbi spiport, nsel


ldi XH, 0x80
ldi XL, 0xE7
rcall send_command
ldi XH, 0x82
ldi XL, 0x80
rcall send_command
ldi XH, 0xA6
ldi XL, 0x40
rcall send_command
ldi XH, 0xC6
ldi XL, 0x47
rcall send_command
ldi XH, 0x95
ldi XL, 0x82
rcall send_command
ldi XH, 0xc2
ldi XL, 0xAC
rcall send_command
ldi XH, 0xCA
ldi XL, 0x83
rcall send_command
ldi XH, 0xc4
ldi XL, 0x83
rcall send_command
ldi XH, 0x98
ldi XL, 0x50
rcall send_command
ldi XH, 0xE0
ldi XL, 0x00
rcall send_command
ldi XH, 0xC8
ldi XL, 0x00
rcall send_command
ldi XH, 0xC0
ldi XL, 0x40
rcall send_command
ret


RFM_read_status:
;Datenbyte in XL
ldi temp1, 0x00
rcall read
ret

in einem weiterem testprogramm spuckt der avr
pinb;00000101 xl;00000000 xh;00000000 via USART aus
und obwohl pb 6 und 7 nie genutzt werden sind sie zwischnezeitlich sporadisch auf highlvl...

 

[addi]

Hmmmm...,
Koennte man nicht mal hier http://www.mikrocontroller-elektronik.de/funkmodul-programmierung-rfm12b-rn-mikrofunk/ das bascom prog kompilieren und sich das assembler listing anschauen?
Addi

 

[LotadaC]

Ja, aber in #41 wurde auch schon was in ASM erwähnt, das scheint auch gut dokumentiert zu sein.
Ich würde mich an eine Inklude setzen wollen (deswegen auch die Fragen bezüglich der Equations), aber das wird wohl noch'ne Weile dauern... Zeit halt...

 

[dannyboy1994]

Mit meiner aktuellen fassung FUNKTIONIERT das auslesen des statusregisters bis auf den fehler das nach dem reset 0x4000 geliefert werden soll und ich 0x2000 also um 1bit verschoben erhalte. Den fehler habe ich aber denke ich schon entdeckt und werde es später nocheinmal testen. Dann werde ich mich mal darran machen den empfänger soweit zu bekommen das er alle empfangenen daten per usart ausgibt und versuchen einen passenden sendebetrieb auf dem 44er zu erreichen.

 

[Dirk]

Hier hast du noch einen Fehler ...

Schau dir sbr und cbr an und überlege, welches Bit du hier setzt oder löscht.


CodeBox Assembler

einsinreg:
lsl temp2
sbr temp2, 0
ret

nullinreg:
lsl temp2
cbr temp2, 0
ret

Ich denke richtig wäre ...


CodeBox Assembler

sbr temp2, 1
cbr temp2, 1

 

[dannyboy1994]

Ich hoffe das ich bald etwas einwandfreies zusammen bekomme. Dar ich die obere Routine bei mir auf der PLatte zerschossen habe durch fehlersuche und korrekturen, und mir das ganze zu unsauber war habe ich noch einmal von grundauf angefangen. Getestet ist es noch nicht, dar ich gerade einfach nicht dazu komme (Weinachten steht vor der Tür..) aber falls jemand einen Ansatz braucht oder ähnliches :/ ich hoffe ich komme morgen zum testen.

kleine Frage nebenher und bitte lacht mich nicht aus:
Wenn ich her gehe und nehme einen tiny2313, initialisiere auf ihm den USART und lasse ihn auf 20 Mhz laufen ( oder vllt wenn er es mit macht bei 5,5V und 24Mhz)
lasse ihn den Portb scannen und schicke den Wert mit maximaler Baudrate an den PC, schreibe mir dann noch ein schickes programm in Python das mir das ganze grafisch auswertet, wäre doch ein kleiner binärer logicanalyzer das ergebniss ( leider nur TTL-Pegel und Rauschen wird auch nicht ersichtlich, aber mann könnte die Ports beobachten).... wobei bei 921600baud leider auch nicht die überzeugende abtastrate dabei rüberspringt.... dabei würden gerade mal 1 Mhz nutzdaten rausspringen bei 8 kanälen...wobei das warscheinlich für SPI geschichten und ähnliches reichen würde....
Ich schau immer wieder im internet aber finde einfach nichts überzeugendes zu einem angenehmen preis...Am liebsten wäre mir ein altes Klobiges 2 Kanal Oszi mit Röhre ...

 

[TommyB]

Kleiner Tipp meinerseits (ich hatte mich mal an einem Oszilloskop mit ATmega versucht): Baudraten über 115200 kannste komplett vergessen. Da ist es nur noch eine Frage des Glücks ob Daten fehlerfrei empfangen werden. Selbst bei 150000 hatte ich schon zig falsche Bytes mit drin. Obwohl die Geschwindigkeit angeblich unterstützt werden sollte. Naja… Einstellen konnte ich sie auch… Aber was nützt es mir wenn ich die Daten zig Mal wegen Fehlern neu übertragen muss?

Daher sind die Oszi's und Logic Analyzer auch relativ teuer, die machen alles in der Hardware und schicken nur die Ergebnisse (gefiltert) an den PC weiter. Zumindest wenn die Abtastrate zu hoch wird.

Wenn du kein sonderlich großes Augenmerk auf Genauigkeit legst und nur ein Signal sehen willst kannst du auch deine Soundkarte vom PC missbrauchen (für DC nicht geeignet). Höchste Abtastrate wäre meißt 96000 Samples/s bei 16 Bit (High End Karten können ggf. mehr), paar Dioden als Schutz (nie mehr als 1V übergeben!) und ein Poti als Spannungsteiler am Eingang. Zack, 2 Kanal Skop gebastelt. Hab ich früher selber genutzt für Audioanwendungen. Dafür gehts, aber Messen ist definitiv was anderes.

 

[LotadaC]

Das liegt nicht an den AVR, sondern höchstens am verwendeten Takt.
Manche Pegelwandler erreichen dieses Tempo auch nicht mehr (insbesondere Billig-USB-Dinger).
Ich hatte irgendwo mal was von Problemen einiger (alter) Mainboards mit untypischen Baudraten gelesen.
AVR als Oszi: der ADC braucht 13 Takte, die theoretisch erreichbare maximale(!) Samplefrequenz liegt unter 2MHz. Bei einem Kanal. Realistisch würde ich 10..100kHz schätzen - das Daten rauspumpen ist da das geringere Problem. Gabs natürlich bereits diverse Umsetzungen - bei mir ists dann irgendwann mit der PC-Software steckengeblieben.
AVR als LA: Hier halte ich max. 2..4MHz für handhabbar (Abs. max wären 10MHz - jedes Sample lesen und mit post-Inc ins SRAM, aber nicht wirklich handhabbar)
Hier wird also auch das Datenwegschaufeln zum Problem.
Üblicherweise schaufelt man nicht mehr jedes Sample raus, sondern nur noch Veränderungen mit 'nem Zeitstempel. Die 8 Kanäle wären ein Byte, als Kompromiß könnte man sich ein zweites Byte als Zeitstempel vorstellen, dessen Wert die ausgelassenen (konstanten) Samples representiert. Das 256ste konstante Sample wird trotzdem übertragen.

 

[TommyB]

Das liegt nicht an den AVR, sondern höchstens am verwendeten Takt.
Manche Pegelwandler erreichen dieses Tempo auch nicht mehr (insbesondere Billig-USB-Dinger).

Stimmt, aber nicht immer. Einer von meinen Konvertern soll bis 2MBaud können (laut Datenblatt), was auch angegeben war. Der Pegelwandler aber maximal 150kBaud. Soweit hast du Recht. Aber: Ich hab den Pegelwandler operativ entfernt und überbrückt. Ging trotzdem nicht mit Baudraten über 115.200 Baud. Also nicht fehlerfrei. Ein paar Bytes kamen fehlerfrei an, selbst bei 2MBaud. Aber was nützt es dann noch wenn man sich auf die Daten nicht verlassen kann… Ist bei mir bei jedem USB zu Seriell Adapter so gewesen (diverse Hersteller).

Theorie vs. Praxis. Praxis wins. Aber auf Theorie wird sich verlassen

 

[LotadaC]

Jain...
Du hast mich nicht ganz recht verstanden/interpretiert:
Der Hardware-UART arbeitet schon exakt mit seinen Timings, aber die sind eben an den Takt des Controllers gekoppelt. Folglich sind (I) nicht alle Baudraten sauber einstellbar bzw mit einem Fehler behaftet, und die Genauigkeit hängt von der des eingesetzten Taktgebers ab (II).

Solange Du den AVR nicht ausserhalb seiner Spezifikationen betreibst, werden die Bits sauber alle 16 Takte (+ UBRR) gesampled/rausgeschoben (bzw 8 Takte im doubeled Transmission Mode) - wenn schon die Takte nicht stimmen... (wie damals bei meinem Soft-UART(Rx) im Tiny10)

Wenn die übertaktet werden, arbeiten irgendwelche Module nicht mehr sauber - die Ports laufen noch recht lange korrekt. 125..150% Tempo könnte ich mir vorstellen...

 

[TommyB]

Ja ne, bei den AVRs selbst mach ich mir da auch keine Sorgen, wenn die untereinander so fix schnacken wollen. Ich meine die USB Ports am PC / USB Adapter.
Und da das Ganze mit Python Software laufen soll gehe ich vom PC Betrieb aus, weil ich kenne keinen Python Compiler für AVR

(btw. hatte ich für jede Frequenz die passende Clock gewählt dass der Fehler bei 0 lag, ohne Übertakten)

 

[dannyboy1994]

Python interpreter bitte . nun ja über die Feiertage denke ich wird eh nicht viel passieren. Mich macht nur langsam das "tolle" rfm12" etwas stinckig. Es gibt viele infos dazu das muss ich zu geben aber durchsichtig ist leider etwas anderes

 

[avr_racer]

Hallo Leute bin neu hier und wollt mal fragen kann jmd mal nen Update geben was jetzt funktioniert und was nicht ?

@dannyboy1994

Mach mal bitte einen Schaltplan fertig wie du was verdrahtet hast oder verdrahten möchtest.

Es wäre gut wenn du zu erstmal die serielle Schnittstelle in Angriff nehmen würdest.

 

[Dirk]

Hallo avr_racer,

Willkommen im Forum

Hallo Leute bin neu hier und wollt mal fragen kann jmd mal nen Update geben was jetzt funktioniert und was nicht ?

Soweit ich mitbekommen habe, funktioniert im Moment lediglich UART (Debugdaten ausgeben).

Bei den beiden tinyAVR wurde zunächst HardwareSPI für Kommunikation mit RFM12 verwendet, danach dann mal SoftwareSPI.

Es waren Fehler im Assembler Code vorhanden, so dass das Programm nicht richtig ablaufen konnte, die sind anscheinend behoben. Inzwischen ist die Software wieder überarbeitet, diese habe ich mir aber wegen wenig Zeit nicht näher angesehen.

Nach meinem "Gefühl" liegt es an der Initialisierung des RFM12. Mit dem RFM12 habe ich bisher noch nichts gemacht, verglichen habe ich mal die Initialisierung mit einer C Lösung von Adafruit für Arduino, da gab es schon einige Unterschiede. Ob es tatsächlich daran liegt, kann ich nicht genau sagen, ich müsste mich erst näher damit beschäftigen. (Über die Feiertage bin ich aber von meiner Familie "ausgebucht" )

Dirk

 

[LotadaC]

(Über die Feiertage bin ich aber von meiner Familie "ausgebucht" )

dito, ich lege auch noch "Arbeit" mit drauf...