Assembler RFN12b an Tiny44 und Tiny2313 via USI

[avr_racer]

@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

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.

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.

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

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....

 

[dannyboy1994]

Also so wie ich es jetzt im datenblatt gelesen habe kann man VDI wenn er als Ausgang konfiguriert ist an einen interrupteingang des AVR´s lesen und dann daten aus dem FIFO hohlen... Das interessante ist das man dabei anscheinend schnell genug agieren muss.. Sonst kommt es zu einem FIFO underrun... damit könnte man sich das ganze polling sparen....

 

[avr_racer]

Seite 19 steht noch recht interissantes VDI ist nur ein internes Signal

 

[dannyboy1994]

Seite 19 steht noch recht interissantes VDI ist nur ein internes Signal

Slow mode: The VDI signal will go high only if the DRSSI, DQD an
d the CR_LOCK (Clock Recovery Lo
cked) signals present at the sa
me
time. It stays high until any of the
abovementioned
signals present; it will go low when
all the three input signals are low.
Medium mode: The VDI signal will be active when the CR_LOCK sign
al and either the DRSSI or the DQD signal is high. The valid da
ta
indicator will go low when either the CR_LOCK gets in
active or both of the DRSSI or DQD signals go low.
Fast mode: The VDI signal follows the level of the DQD signal.
Always
mode: VDI is connected to logic high
permanently.
It stays always high independently of the receiving parameters.


AUF SEITE 18

 

[dannyboy1994]

Auch scheint es laut seite 28 des datenblatts klug zu sein nirq auszuwerten. nirq an ext.int pin des AVR´s.=> wenn interrupt dann status lesen=>prüfen ob FFIT gesetzt ist=> wenn ja fifo lesen

Desweiteren ist das TX register in Form von 2 8bit schieberegistern aufgebaut. Es wird immer das 2te byte im register gesendet. Also müsste man ein dummybyte nachschieben nach dem das datenbyte übergeben wurde...

 

[LotadaC]

Ich denke du meinst den Timer0 den man ja auch laut Tabelle nutzen kann...

Nein, der dort von mir angedeutete mögliche Weg (das ist dann letztlich auch der aus dem Datenblatt mit der Schleife) Durch USICS1=1 koppelst Du das USI-Schieberegister auf auf eine Flanke des USCK-Pins. Welche Flanke, bestimmt das USICS0-Bit. Im einem externen Modus (USICS1=1) ist das USICLK-Bit keine Strobe mehr, sondern legt fest, wodurch der 4bit-Zähler inkrementiert. Bei USICLK=1 wrd er mit jedem USITC-Strobe inkrementiert.
Jeder USITC-Strobe bewirkt automatisch ein toggeln des SCK-Pins, also einen Flankenwechsel, jeder zweite Flanenwechsel löst das Schieben des Schieberegisters aus. Nach sechzehn USITC-Strobes wäre dann das ganze Byte transferiert. (das ist genauso schnell wie der SPITransfer_Fast aus dem Datenblatt, nur daß jetzt jedesmal dasselbe Byte nach USICR geschrieben wird -> genau genommen reicht wie gesagt jedesmal das setzen des USITC aus, welches direkt angesprochen werden kann.
Außerdem inkrementiert jeder USITC-Strobe nebenbei den 4bit-Zähler, sodaß dieser bzw dessen Überlauf ausgewertet werden kann. wie Du halt auch meintest->

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.

Da muß man dann halt nur den Fehler mit dem doppelt genutzten Register korrigieren, auf das USIOIF direkt mit SBIS reagieren.


CodeBox Assembler

SPITransfer_loop:
 OUT USICR, R16 ;USITC-Strobe
 SBIS USISR, USIOIF
 RJMP SPITransfer_loop
...

Da das USICR auch direct bit accessible ist, geht auch:


CodeBox Assembler

SPITransfer_loop:
 SBI USICR, USITC
 SBIS USISR, USIOIF
RJMP SPITransfer_loop
...

, was das vorinitialisieren spart. Das vorherige löschen von USIOIF geht ja auch mit SBI ohne Umweg über ein Register. Es muß halt nur einmal (und zwar gleich am Anfang mit den Ports usw) der USI initialisiert werden (Wiremode, Clocksource, ...).

Ich denke du meinst den Timer0 den man ja auch laut Tabelle nutzen kann. Timer0=SCK da sie auf dem gleichen Pin liegen.

USCK ist derselbe Pin wie T0, was als Takteingang von Timer0 genutzt werden kann. Man könnte mit Timer0 also die SCK-Perioden zählen, aber dasselbe macht ja bereits der 4bit-Zähler im USISR. Und das erzeugt die Takte ja noch nicht. Es müssen trotzdem sechzehn USITC-Strobes erzeugt werden (ob nun einzeln oder in einer Schleife, ist erstmal egal).

Nein. Die Zeile mit USICS1..0=0b01 und dem Timer0Compare Match ist mir komplett unklar.Timer0 hat zwei Compare Units (nämlich A und B). Welches soll das jetzt sein? Vermutlich A, welches dann auch gleich den Überlaufpunkt, und somit die Frequenz festlegt, ABER dann würde jedes Match schieben (und nicht nur jedes zweite), das paßt irgendwie nicht. Das inkrementieren des 4bit-Counters toggelt ja nicht die SCK, man hätte mMn also nur die Möglichkeit 8 bits asynchron raustakten zu lassen.

Natürlich könnte man auch irgendwelche Timerinterrupts nutzen, und dort die TC-Strobes erzeugen, um geringere USCK-Frequenzen zu erhalten.

 

[avr_racer]

Also im Bild ist *VDI nochmal extra aufgenommen und als internal Signal gekennzeichnet. Bild Ubekannt

SCK ist derselbe Pin wie T0, was als Takteingang von Timer0 genutzt werden kann. Man könnte mit Timer0 also die SCK-Perioden zählen, aber dasselbe macht ja bereits der 4bit-Zähler im USISR. Und das erzeugt die Takte ja noch nicht. Es müssen trotzdem sechzehn USITC-Strobes erzeugt werden (ob nun einzeln oder in einer Schleife, ist erstmal egal).

Nein. Die Zeile mit USICS1..0=0b01 und dem Timer0Compare Match ist mir komplett unklar.Timer0 hat zwei Compare Units (nämlich A und B). Welches soll das jetzt sein? Vermutlich A, welches dann auch gleich den Überlaufpunkt, und somit die Frequenz festlegt, Das inkrementieren

Natürlich könnte man auch irgendwelche Timerinterrupts nutzen, und dort die TC-Strobes erzeugen, um geringere USCK-Frequenzen zu erhalten.

Die Timervariante:
Die Takte werden mit dem Comparematch erzeugt diesen werden im OCRA/B mit Anzahl der Bits festgelegt, gleichzeitig ist der 4bitzähler der USI draufgeschaltet und übernimmt die Zählung der 16Takte.

Deine Frage ist berechtigt und ganz ehrlich ich würde das einfach ausprobieren. Aber auch hier Vermute ich das die Jungs von Atmel beide zu nutzen zur Verfügung gestellt haben, sonst wenn dem nicht so ist tippe ich auf Compare UNIT A.

ABER dann würde jedes Match schieben (und nicht nur jedes zweite), das paßt irgendwie nicht.

Jedes Match schiebt bei fallender und steigender Flanke. 1Match = 2mal schieben.

des 4bit-Counters toggelt ja nicht die SCK, man hätte mMn also nur die Möglichkeit 8 bits asynchron raustakten zu lassen.

Umgekehrt der Ausgangspin ist auf den Eingang des 4bitCNT geschaltet toggelt diessen. Wenn man es händisch macht mit dem umschalten der Strobes in der USI kommt der TAKT aus der USI geht auf den SCK-Pin wird aber vorher wieder abgegriffen und wieder zurück auf die USI zum 4bitCNT geführt. JA ich weiß das steht da nirgends im DB des Tinys aber nur so könnte ich mir das vorstellen das man sich so diese Mutlifähigkeit erarbeitet bzw erhält. Sonst würde das keinen Sinn machen diese Möglichkeit aufzulisten das man mit Timer0 die Frequenz erzeugt. Oder aber die haben nen Copy/Pastefehler kommt vor. Zumindest glaube ich es nicht weil di AVR ein fach Multifunktional sind was das angeht....
http://www.atmel.com/Images/doc4300.pdf
USI Counter Seite 6 mal lesen auch als Bild im Anhang verfügbar Unbekannt2 und Unbekannt3 ist aus dem Datenblatt des TN85

http://www.mikrocontroller.net/topic/230124
Hier im Post gehts um den TN26 der es auf dem OVFL hat nur dort muss man den TCNTx dann vorladen für andere Frequenzen

 

[LotadaC]

Die Takte werden mit dem Comparematch erzeugt diesen werden im OCRA/B

Wie denn? B2 des Tiny85 kann folgende Funktionen haben:

• Clockeingang für das ISP
• USI-Clock (Eingang, mit USITC quasi auch Ausgang)
• ADC1-Eingang
• Takteingang von Timer0 (als Counter)
• externer IRQ 0
• PCINT 2

Timer0 kann B2 nicht beeinflussen. Natürlich kannst Du in Software USITC-Strobes und so generieren, gern auch interruptgekoppelt, aber eben nicht in Hardware.

Jedes Match schiebt bei fallender und steigender Flanke. 1Match = 2mal schieben.

Nein, sowohl das Schieben des USIDR, als auch das Inkrement des 4bit-Zählers wird immer (und nur) durch eine steigende Flanke ausgelöst.
Das CompareMatch/Overflow-Event des Timers ist ein Strobe mit beiden Flanken, ebenso die Strobes von USITC, USICLK -> lösen also jedesmal ein Schieben/Inkrement aus.
Die vom USCK her eingehenden Flanken hingegen sind einzelne Flanken, die (ggf negiert) direkt auf dem Schiebeeingang des USIDR landen (es löst also nur eine der Flanken das Schieben aus). Beim Counter ist hingegen ein Edge Detector dazwischengeschaltet, der aus jeder Flanke einen Strobe (mit zwei Flanken) generiert -> jede Flanke inkrementiert den Counter...

Umgekehrt der Ausgangspin ist auf den Eingang des 4bitCNT geschaltet toggelt diessen.

Sagte ich ja, die umgekehrte Richtung ist klar. Ein tatsächlicher Takt am USCK löst das Schieben/Inkrementieren aus; egal wodurch USCK toggelt. Für den Master suchen wir aber nach möglichst automatisierten Möglichkeiten, den USCK zu toggeln, und das geht eben nicht über die genannte Koppelung des CompareMatches auf den USI.
Hier mal das Block Diagramm des USI (Tiny85), und wie ich es interpretiere:

(I) ist der "USIDR-Schiebe-Multiplexer"
(II) ist der "4bit-Counter-Inkrement-Multiplexer"
(III) ist der Edge Detector, welcher nur tatsächliche Flanken am USCK erfaßt, und daraus komplette Strobes fürs Zähler-Inkrement generiert.

USICS1:0 legt den Signalverlauf über die Multiplexer fest:

• USICS1:0=0b00 - jeder USICLK-Strobe löst gleichzeitig einschieben des USIDR und ein Inkrement des Counters aus - Schwarz
• USICS1:0=0b01 - jedes "Tim0 Comp" (=Strobe) löst ein gleichzeitiges Schieben von USIDR/Inkrement des Counters aus - Grün (unklar, um welches Compare-Event es sich handelt. Bei Controllern ohne Timer0-Compare Units (zB Tn26) findet sich hier der eindeitige Timer0-Überlauf)
• USICS1:0=0b1x - jede steigende (x=0) oder(!) fallende (x=1) tatsächliche Flanke an USCK schiebt USIDR, USICLK wird zu einem dritten Konfigurationsbit welches den Multiplexer zwischen (II) und (III) beeinflußt (kein Strobe mehr)
  • USICS1:0:USICLK=0b1x0 - jede tatsächliche Flanke am USCK inkrementiert wegen (III) den Counter - Blau
  • USICS1:0:USICLK=0b1x1 - jeder USITC-Strobe inkrementiert den Counter (unabhängig vom tatsächlichen USCK-Verhalten) - Braun

Die einzige Möglichkeit, USCK aus dem USI heraus zu beeinflussen, sind die USITC-Strobes, die aber immer in Software erzeugt werden müssen - Rot. (Abgesehen vom Clock-Hold im 2wire-Mode).

USI Counter Seite 6 mal lesen auch als Bild im Anhang verfügbar

Natürlich können wir mit dem Counter Flanken zählen, oder auch compare Matches... wie in AVR307 wo damit ein UART realisiert wird. Das ist ja genau das, was ich vorher sagte:

Das inkrementieren des 4bit-Counters toggelt ja nicht die SCK, man hätte mMn also nur die Möglichkeit 8 bits asynchron raustakten zu lassen.

Asynchron, also ohne Synchronisierung über ein Clock-Signal.

Nachtrag: Mit Hilfe des Timers sehe ich nur eine Möglichkeit, die Clock zu automatisieren, und zwar indem der Timer extern eine PWM auf USCK legt. Der USI ist dann quasi als Slave einzustellen - der 4Bit-Counter-Überlauf-IRQ stoppt dann die PWM-Ausgabe (über den Compare Output Mode des verwendeten Kanals). Das kostet dann zusätzlich zum verwendeten USCK-Pin einen PWM-Pin, und schränkt die Möglichkeiten des zweiten PWM-Kanals ein, bzw die der Timerüberlaufsfrequenz (Zeitbasis, etc...)

 

[avr_racer]

Nein, sowohl das Schieben des USIDR, als auch das Inkrement des 4bit-Zählers wird immer (und nur) durch eine steigende Flanke ausgelöst.

Alles gut ich war auf dem falschen Trichter mit dem
Zitat DB TN85: DI is sampled at positive edges, and DO is changed (USIData Register is shifted by one) at negative edges.
Das war meine Annahme habe einen geistigen Verdrahtungsfehler gehabt somit hat sich der Rest erledigt... Hab halt mit der USI noch nie gearbeitet bzw nur mal drüber geschaut oder es in Soft gelöst.
Bei den Atmega's gibs halt die HW von TWI/I²C , UART sowie SPI als quasi extra Bausteine. Somit muss man sich kein Kopf machen um solche Sachen.

Das kostet dann zusätzlich zum verwendeten USCK-Pin einen PWM-Pin, und schränkt die Möglichkeiten des zweiten PWM-Kanals ein, bzw die der Timerüberlaufsfrequenz (Zeitbasis, etc...)

Sowas ähnliches gibs bei den beim tiny2313 da ist PD5 mit OCB0/T1 belegt so das Timer0 den Timer1 beeinflussen kann. Musste das schon mal nutzen. Na dann ist das Problem doch gelöst. ich würds so machen mit T1, denn dann hast du auch deine Synchronisation vom Takt, dem 4bitCounter sowie den Datenfluss.

Nachtrag manchmal steht man direkt vor der Lösung und sieht sie nicht.

 

[dannyboy1994]

Also das mit dem USI ist ja jetzt ganz schön ausgeartet Ergebniss=Takt von USI wird jetzt und in alle ewigkeit per software gelöst, wie ist jedem selbst überlassen. Ob mit 20 Out befehlen einer schleife oder einem <Timer interrupt um den Takt in die Knie zu zwingen . Dar das mit dem RFM doch sehr stressig ist hab ich mich heute nur mit meinem nebenprojekt beschäftigt. Ein Tiny13 SPI Slave (Software ohne SS und DO) steuert 6 74HC595 an an welchen 4 4-Fach 7Segment anzeigen über transistoren angeschlossen sind(Das Steckbrett sieht wider mal aus wie Dresden 1945 ).
Aber um einmal wieder auf das eigentlich Thema zurück zu kommen. Das ganze scheint nun einzig und allein an der initialisierung zu scheitern...

 

[LotadaC]

Bei den Atmega's gibs halt die HW von TWI/I²C , UART sowie SPI als quasi extra Bausteine.

Bei einigen Tinies gibt's dafür eben das Universelle Serielle Interface als Baustein, welches versucht(!!), die richtigen halbwegs nachzubilden.
Es gibt auch Tinies mit echter SPI, mit echtem U(S)ART (sogar mit mehreren). Nur beim TWI/I²C hab ich bisher nur welche mit Slave-TWI gefunden, und der hilft Dir gar nicht weiter, wenn Du'n Master implementieren willst/mußt. (Beim USI geht das ja mehr oder weniger, aber der Tiny441/841 hat eben keinen USI, sondern nur SPI, SlaveTWI und zwei USARTs...

Nachtrag manchmal steht man direkt vor der Lösung und sieht sie nicht.

Die hatte ich schon von Anfang an im Kopf, aber das kostet halt den Timercompare und insbesondere dessen Output-Pin zusätzlich zum USCK-Pin. Also zwei der 5 I/Os (wenn man den Reset läßt) für die serielle Clock.
Mit DI, DO, USCK, dem SlaveSelect (->nSEL) und dem PWM-Pin (der extern auf das USCK-Netz gelegt wird) sind ALLE I/Os nur für die Anbindung des RFM verbraucht. Dann kannste eigentlich nur noch den internen Temperatursensor messen/übertragen.

Ob mit 20 Out befehlen einer schleife oder einem <Timer interrupt um den Takt in die Knie zu zwingen .

Beim letzten Weg mit der externen Verdrahtung Timer-PWM-Out -> USCK-In übergibst Du das der (Timer-)Hardware. Bei den Software-Varianten sind halt sechzehn Software-Aktionen nötig (Zwei USITC pro Bit), bei der Hardware-Variante wird nach der Init nur der Timer gestartet (bzw der OutputCompareMode gesetzt), und nach dem kompletten Byte (ÜberlaufIRQ des 4bit-Counters) gestoppt.
Für die "20 Out befehle" mußt Du aber die auszugebenden Werte erstmal in ein Rechenregister laden, welches erstmal frei sein muß. Und das nur um eigentlich ein einziges Bit zu setzen (USITC). Genau das kannst Du sparen, wenn es den direkten zugriff als Bit erlaubt (also das entsprechende I/O-Register eine Adresse kleiner als 0x20 hat). Hatte ich ja bereits in #86 geschrieben.

Also das mit dem USI ist ja jetzt ganz schön ausgeartet

zumindest ich hab einiges dabei gelernt, avr_racer mMn auch...

Aber um einmal wieder auf das eigentlich Thema zurück zu kommen. Das ganze scheint nun einzig und allein an der initialisierung zu scheitern...

Denk ich auch, aber mangels Hardware kann ich da nicht wirklich helfen...

nebenprojekt ... Ein Tiny13 SPI Slave (Software ohne SS und DO) steuert 6 74HC595 an an welchen 4 4-Fach 7Segment anzeigen über transistoren angeschlossen sind

Ok, die 595er sind 8bit-Schieberegister, quasi mit internem Buffer und Output-Enable (bezieht sich auf den Buffer). Die eigentlichen Schieberegister sind kaskadierbar. Ein Bein für die zu schiebenden Bits, eins für die Schiebetakte, eins für das Latch auf den Buffer. Blieben zwei Beine frei für anderes..
Aber was meinst Du mit 4 4fach 7Segmenten sechzehn Siebensegmente, also 112 anzusteuernde Pins (ohne Dezimalpunkte)? Die 595er liefern zusammen 48 Pins - da müßte man multiplexen...
Hmm... gehen tut das natürlich, mit dem einen Timer...
64Bytes SRAM (und 64Bytes Eeprom) und 1kB Flash...
der Tiny13 kann intern mit 9,6MHz laufen...
Was willst Du denn darstellen lassen?

Achso (lichtaufgeh) - der Tiny soll auf zwei beinen im soft-SPI als Slave Bytes empfangen, und die (aufbereitet -> hex-Darstellung etc...) im soft-SPI als Master auf die Siebensegmente pumpen?!
geht natürlich auch...

 

[avr_racer]

Bei einigen Tinies gibt's dafür eben das Universelle Serielle Interface als Baustein, welches versucht(!!), die richtigen halbwegs nachzubilden.
Es gibt auch Tinies mit echter SPI, mit echtem U(S)ART (sogar mit mehreren). Nur beim TWI/I²C hab ich bisher nur welche mit Slave-TWI gefunden, und der hilft Dir gar nicht weiter, wenn Du'n Master implementieren willst/mußt. (Beim USI geht das ja mehr oder weniger, aber der Tiny441/841 hat eben keinen USI, sondern nur SPI, SlaveTWI und zwei USARTs...

Ich will damit sagen das es vllt besser wäre auf nen etwas größeren Vetreter umzusteigen. Bei dem ganzen Sackstand dem hiermit hat, eben weil die USI eine eierlegende Wollmilchsau ist. In solchen Projekt kommt bestimmt die ien oder andere Sache noch hinzu somit rentiert sich die größe an HW wieder.

Ergebniss=Takt von USI wird jetzt und in alle ewigkeit per software gelöst,

Na du willst bestiummt nur den Pin sparen weil der für was anderes gebraucht wird ?

Die hatte ich schon von Anfang an im Kopf, aber das kostet halt den Timercompare und insbesondere dessen Output-Pin zusätzlich zum USCK-Pin. Also zwei der 5 I/Os (wenn man den Reset läßt) für die serielle Clock.
Mit DI, DO, USCK, dem SlaveSelect (->nSEL) und dem PWM-Pin (der extern auf das USCK-Netz gelegt wird) sind ALLE I/Os nur für die Anbindung des RFM verbraucht. Dann kannste eigentlich nur noch den internen Temperatursensor messen/übertragen.

Schlußfolgerung vllt auf nen 2313 auch umzusteigen ? Oder mal nen Schaltplan machen, über alles, um zu sehen was wirklich alles benöigt wird. Denn so geheim ist das Projekt nun auch nicht, dass man selbst auf mehrfaches nachfragen und hinweisen, einen Schaltplan nachzureichen nicht drauf reagiert wurde. Nur so lässt das vernünftig abschätzen.
Frage was soll denn noch alles angeschloßen gesteuert/geregelt werden?
Falls nen Temperatursensor gebraucht wird, würde ich nen DS18S20 vorschlagen 1wire zum Datenaustausch.

zumindest ich hab einiges dabei gelernt, avr_racer mMn auch...

Hey neue HW und nur aus dem DB es nachzuvollziehn während English die Sprache ist, nicht unbedingt einfach innerhalb von 2Tagen so neben bei! Lernen tut man immer was egal wann egal wo!!

Zitat von dannyboy1994: ↑
Aber um einmal wieder auf das eigentlich Thema zurück zu kommen. Das ganze scheint nun einzig und allein an der initialisierung zu scheitern...
Denk ich auch, aber mangels Hardware kann ich da nicht wirklich helfen...

Danny hast du dir mal das Wiki https://www2.htw-dresden.de/~wiki_sn/index.php/RFM12 angeschaut wenn die INIT problematisch ist?

Ein Tiny13 SPI Slave (Software ohne SS und DO) steuert 6 74HC595 an an welchen 4 4-Fach 7Segment anzeigen über transistoren angeschlossen sind(Das Steckbrett sieht wider mal aus wie Dresden 1945 ).

Schaltplan ? Textbeschreibung ist wie ein Gesetz absolut dehnbar und interpretierbar!! Schaltplan ist eindeutig und es lässt sich besser erkennen wie man was vllt anders oder sinvoller umsetzen könnte.

Da würde vom Prinzip her 1x74HC595 und ein 1x74HC154(4 zu 16 Demultiplexer) reichen. Alle 4 4Fachsegmente parallel schalten und welches Segment du ansteuerst kannst du mit nem Zähler einfach hoch zählen lassen übern INT. Und das bleibt solange aktiviert bis der nächste INT kommt. Der 595 hat den Vorteil während das eine gespeichert ist kannst du das andere schon kurz vorher anlegen, kommt nun der INT um die Anzeige umzuschalten werden auch die Daten für die neue Anzeige in den Buffer geladen. Der 595 brauch 1xDI, 1xSCK, 1xCS, 1xCLKBUFFER und 1xOE sind 5 Leitungen und beim 154er wären das auch nochmal 5 Leitungen macht 10. Ist halt die Frage wieviel Pins du jetzt wirklich fürs RFM-Modul brauchst?

Aber wenn du sowas meinst ?

 

[dannyboy1994]

Ok, die 595er sind 8bit-Schieberegister, quasi mit internem Buffer und Output-Enable (bezieht sich auf den Buffer). Die eigentlichen Schieberegister sind kaskadierbar. Ein Bein für die zu schiebenden Bits, eins für die Schiebetakte, eins für das Latch auf den Buffer. Blieben zwei Beine frei für anderes..
Aber was meinst Du mit 4 4fach 7Segmenten sechzehn Siebensegmente, also 112 anzusteuernde Pins (ohne Dezimalpunkte)? Die 595er liefern zusammen 48 Pins - da müßte man multiplexen...
Hmm... gehen tut das natürlich, mit dem einen Timer...
64Bytes SRAM (und 64Bytes Eeprom) und 1kB Flash...
der Tiny13 kann intern mit 9,6MHz laufen...
Was willst Du denn darstellen lassen?

Achso (lichtaufgeh) - der Tiny soll auf zwei beinen im soft-SPI als Slave Bytes empfangen, und die (aufbereitet -> hex-Darstellung etc...) im soft-SPI als Master auf die Siebensegmente pumpen?!
geht natürlich auch...

Die 4fach 7segment anzeigen haben 12/Pins
4 gnds für die jeweilige Ziffer 1-4
7 Pins über 1k und transe an vcc für die Segmente A-G
1 via 1k und transe an vcc für dez. Punkt

12*4=48

Der Tony soll als SPI slave einen beliebigen empfangenen Wert als HEX ausgeben.
Er empfängt erstmal alles was er bekommt. Das sind immer 1byte für dez/hex/asci/raw wobei asci auf den anzeigen scheiße aussieht wegen z.b o und 0
Und dann dementsprechend folgend Datenbytes. Entweder 16Byte für 16 einfach zahlen von 1-0
Oder 8byte für hexwerte
Oder 16byte bei ASCII.
Die Anzeige beginnt immer mit dem linken Segment. Leider is das ganze a bissl a chaos auf dem steckbrett und ich seh jetzt schon das mir die 1kb flash eng werden aber es ist mehr eine nebenbei Beschäftigung zur Ablenkung und soll wenns fertig ist mal ein schickes kleines platinchen werden.
Tiny und 595er unter den anzeigen versteckt. R und transen SMD....

@avr_racer das ganze läuft unabhängig von einander und is nur ne Ablenkung für Zeiten in denen ich wie gestern. Da hatte ich einfach keinen Kopf dafür am RFM rumzubasteln.

Das ganze ist mit 6 74hc595 aufgebaut um eine möglichst hohe wider hohl Frequenz zu erreichen und jede Anzeige einzeln zu aktualisieren. Werte liegen im (eh schon knappen) SRAM.

Bei meiner RFM Geschichte geht es um folgendes.
Der tiny44 soll in den ausenfühler wander (Gehäuse welches vorgesehen ist ist sehr klein) am Ende soll er in regelmäßigen Abständen temp und feuchte und evtl noch die Helligkeit in Lux funken. Ich hab hier pt1000 pt10k einen DS18S20 für temp. Feuchte hab ich noch nix da und etliche LDR in verschiedenen werten. Analoge Sensoren gefallen mir nur besser als der DS18 dar sie über einen Spannungsteiler mit Poti als Serienwiderstand recht leicht zu kalibrieren sein dürften und der ADC ist etwas bekanntes, das 1Wire Protokoll noch vollkommen fremdes. Die Schaltung dazu kann ich mal aufzeichnen auch, wenn ich denke das es nicht zwingend notwendig ist rfm an usi Sensoren an ADC über spannungsteiler.

 

[LotadaC]

Ich will damit sagen das es vllt besser wäre auf nen etwas größeren Vetreter umzusteigen

willst bestiummt nur den Pin sparen weil der für was anderes gebraucht wird ?

Die Tinies sind halt (oh welch Überraschung)... klein, insbesondere in bastlerfreundlichen SOIC- und TSSOP-Packages - wenns also auf den Platz ankommt...
Und in ihrer Größe sind sie teilweise recht gut ausgestattet. Ok, der USI verfügt über keinen eigenen Hardware Clock Generator, aber dann muß man es eben entweder in Software, und/oder mit einem Timer (ggf in Hardware) lösen.

vllt auf nen 2313 auch umzusteigen

Warum das? Der hat doch auch nur USI. Warum (wenn man schon wechselt) nicht auf einen genauso kleinen Tiny mit echtem SPI?

würde vom Prinzip her 1x74HC595 und ein 1x74HC154(4 zu 16 Demultiplexer) reichen

Der 154er braucht allerdings vier Eingänge, ggfs zusätzlich noch einen Ausgang-Enable. Das kann man natürlich auch an einen 595er hängen, der dann mit dem anderen 595er kaskadiert werden kann.
Aber dann kann man auch gleich drei 595er kaskadieren - an zwei werden die sechzehn digit-Leitungen der vier Vierfachsegmente angeschlossen, an den dritten die Segmentleitungen aller Segmente (mit passenden Vorwiderständen).
Die grundsätzlichen Wege sind hier entweder seriell kaskadiert (wenig Pins, viele seriell auszugebenden Bits (Zeit)) oder parallel (viele Pins, weniger Zeit) - und natürlich Mischformen. Der gewählte Tiny13 hat fünf I/Os, zwei für den getakteten seriellen Empfang (ohne CS), drei für die getaktete serielle Ausgabe mit Output-Latch.

Mit den genannten 4fach-Segmenten muß zwingend gemultiplext werden, also müssen die Daten aller grad darzustellenden digits irgendwo im Speicher des Tiny liegen. Beschränken wir uns mal gedanklich auf die Hexadezimale Darstellung:
Ein Digit kann dann sechzehn verschiedene Zeichen darstellen, die man in Form einer Tabelle irgendwo ablegen muß (SRAM, Eeprom je 64 Byte, der Tn13 kann aber auch LPM-> Flash)
Welche Zeichen dargestellt werden sollen, muß in weiteren Bytes abgespeichert sein. Eben genau in den acht Bytes (16 Nibbles), die auch dargestellt werden sollen. Bei der binären Darstellung zweier(!) Bytes, reichen logischerweise zwei Bytes Speicher. Die dezimale Darstellung ist letztlich auch nur die hexadezimale - nur daß eben vorher das ankommende Byte(?) in drei Nibbels konvertiert wird. Du kannst also drei Bytes auf 15 der Siebensegmente als Dezimalzahl anzeigen lassen. Der Speicherbedarf wäre also auch hier bei einem Nibble pro Digit.
ASCIIs auf den Digits anzeigen zu lassen, halte ich für unrealistisch. Vom Speicher her brauchte man ein Byte pro digit, die Zeichentabelle müßte zwingend in den Flash.
Was meinst Du mit "RAW"? "a" ist das "1", "b" ist "2", "ab" ist "3",..., "dp" ist "128",..., "abcdefgdp" ist "255"?
Wären dann auch ein Byte pro digit, klar...

Also wäre es am sinnigsten, fürs Multiplexing ein Byte pro Digit zu wählen, welches entweder das darzustellende Zeichen aus der Zeichentabelle übernimmt, oder "RAW" verwendet wird. Dann kann man das ganze als Ringspeicher organisieren (simple Bitpopelei), sodaß ankommende neue Zeichen auf der Anzeige eins weiter rutschen...

 

[dannyboy1994]

Raw in Form von Rohdaten. Anzeige 1 segment bdeg

Ninja ich denke das das mit den 6 shiftregister eine für mich praktikable Lösung ist, weil ich davon mehr als genug hier habe. Ich kaufe viel bei pollin und schau immer wieder nach so angeboten wie gestern z.B.
5xtn2313 mit Sockel DIP für 4€abisslwas.
Auch denke ich das wenn der flash nicht reicht wirds ein tn85. 8beiner reichen ja
.

 

[avr_racer]

@avr_racer das ganze läuft unabhängig von einander und is nur ne Ablenkung für Zeiten in denen ich wie gestern. Da hatte ich einfach keinen Kopf dafür am RFM rumzubasteln.

Ahso naja denn is gut ich dachte das das im Zusammenhang mit dem RFM steht als Wireless Anzeige oder sowas

Das ganze ist mit 6 74hc595 aufgebaut um eine möglichst hohe wider hohl Frequenz zu erreichen und jede Anzeige einzeln zu aktualisieren. Werte liegen im (eh schon knappen) SRAM.

Die Zeit die für jede Anzeige bleibt hängt zuerstmal von der Anzahl der Anzeigen ab. Bei dir 16x 7Segmente nehem ich mal an das du mindestens mit 60Hz/Anzeige(16,667ms) arbeiten möchtest macht das bei 16*16.667ms = 266ms nach dem dann alle 16Zeichen aktualisiert sind was einer Frequenz von 3,75Hz entspricht das wird also bisschen flackern nein im Ernst jetzt damit es schon recht flackerfrei ist muss jede Anzeige 1ms lang an sein 16*1ms = 16ms = 62,5Hz. Aber nur wenn alle an sein sollen. hast du nun Zeichen dabei wie z.B. das Leerzeichen kann man die Anzeige löschen und brauch sie danach nicht mehr ansteuern. Wenn es so gewünscht ist.

Aber hier ist es auch nochmal erklärt http://www.mikrocontroller.net/articles/AVR-Tutorial:_7-Segment-Anzeige

Der tiny44 soll in den ausenfühler wander (Gehäuse welches vorgesehen ist ist sehr klein) am Ende soll er in regelmäßigen Abständen temp und feuchte und evtl noch die Helligkeit in Lux funken. Ich hab hier pt1000 pt10k einen DS18S20 für temp. Feuchte hab ich noch nix da und etliche LDR in verschiedenen werten. Analoge Sensoren gefallen mir nur besser als der DS18 dar sie über einen Spannungsteiler mit Poti als Serienwiderstand recht leicht zu kalibrieren sein dürften und der ADC ist etwas bekanntes, das 1Wire Protokoll noch vollkommen fremdes. Die Schaltung dazu kann ich mal aufzeichnen auch, wenn ich denke das es nicht zwingend notwendig ist rfm an usi Sensoren an ADC über spannungsteiler.

OHHH ha da unterschätzt du aber die analoge Technik und auf 0,5-1°C kommts bestimmt nicht drauf an. Zum Kalibrieren wenns ich es mal Haarscharf aus lege reicht nicht nur ein Spannungsteiler normalerweise nimmt dort Messbrücken + Verstärker das heißt hier wird der Aufwand auch noch mal größer. Aber hier kannst auch unter gucken und findest DS18S20 fertig zur Anzeige(PC) selbst mit -Werten...
www.roboternetz.de/community/threads/66089-Ds18s20-uart
Man kann auch mehrere DS an einem Bus betreiben, die Routine kann man auf 2 verschiedenen Wegen erreichen. Entweder man liest die ID seperat aus und speichert sie ab oder es gibt eine Leseroutine wo alle Sensoren am Bus sind und diese werden quasi nach dem Ausschlußverfahren ermittelt.
Die DS sind schon kalibriert und haben max 1°C Abweichung für unsere Sachen mahr als ausreichend.

Die Tinies sind halt (oh welch Überraschung)... klein, insbesondere in bastlerfreundlichen SOIC- und TSSOP-Packages - wenns also auf den Platz ankommt...
Und in ihrer Größe sind sie teilweise recht gut ausgestattet. Ok, der USI verfügt über keinen eigenen Hardware Clock Generator, aber dann muß man es eben entweder in Software, und/oder mit einem Timer (ggf in Hardware) lösen.

Selbst DIP reicht bei diesem Projekt vollkommen aus.

Warum das? Der hat doch auch nur USI. Warum (wenn man schon wechselt) nicht auf einen genauso kleinen Tiny mit echtem SPI?

Nicht nur USI, auch ne UART u TWI ist da mit an Board. Ich würds in Software lösen wenns um den Tiny85 geht da bleibt es denn fest bei 2 Pins + die Steuerpins halt aber muss jeder selbst entscheiden wie man es macht. Sind nur Anregungen!!!

Der 154er braucht allerdings vier Eingänge, ggfs zusätzlich noch einen Ausgang-Enable.

und beim 154er wären das auch nochmal 5 Leitungen macht

als wenn ich das nicht wüsste und so geschrieben hätte... Langsam wirds nervig das manauf das WAS man schon geschrieben hat immer und immer wieder hingewiesen wird.
Davon ab das es ne Bastelei so neben bei ist und GETRENNT von DEM RFM ist spart man sich halt 5/6 595er und das was der µC ein Touch teuerer ist hast aber deutlich mehr Möglichkeiten zumal man Pins durch das Enable halt auch doppelt nutzen kann somit bleiben von 10 dann nur 6-8 oder nur 5 Pins übrig wenn man es clever anstellt.

die man in Form einer Tabelle irgendwo ablegen muß

Na aber doch nur 1 mal. Und dann auch nur 16/21 Zeichen 0-9 , A-F bzw a-f das sind gerade mal 21 Bytes das ist ja nun wirklich nix dolles im Flash.

 

[Dirk]

Hallo zusammen,

wie ist denn jetzt der aktuelle Stand, was funktioniert und was funktioniert nicht?

Bitte eventuell neue Themen erstellen, wenn es zu sehr von Thema RFM12B an Tiny44 und Tiny2313 via USI abweicht, ich habe leider den Überblick verloren

Dirk

 

[LotadaC]

Nicht nur USI, auch ne UART u TWI

Das bezog sich auf das zu emulierende SPI. da bringt mich der vorhandene UART nicht weiter, aber ein echtes SPI würde es tun. Mag sein, daß ich jetzt von den Tinies nicht soooo die Ahnung habe, zeig mir doch mal bitte den TWI im ATtiny2313, oder meintest Du da was anderes?

wenn ich das nicht wüsste und so geschrieben hätte

Ja, das hast Du, ich bin darauf eingegangen, weil bei dem von dannyboy eingesetzten ATtiny13 diese 5 Pins gar nicht verfügbar sind. Mit dem seriellen Empfang und einem gelatchten Ausgangs-Schieberegister sind bereits alle Beine verbraucht. Wenn noch irgendwas anderes an den Tiny soll, muß es an den 595 kaskadiert werden. Dann kann man aber auch gleich die 16 Digits mit drei 595ern ansteuern. Warum/wie danny sechs nutzt, ist mir unklar. Offensichtlich will er das Multiplexing aber "andersrum" machen, über die Segment-Leitungen. wären dann acht pro "Bild".

Na aber doch nur 1 mal. Und dann auch nur 16/21 Zeichen 0-9 , A-F bzw a-f das sind gerade mal 21 Bytes das ist ja nun wirklich nix dolles im Flash.

Hab auch nichts anderes gesagt. Der Ringspeicher, der den anzuzeigenden Inhalt enthält, belegt sechzehn Byte SRAM. Die Muster für die sechzehn HEX-Ziffern würden mit weiteren sechzehn Bytes auch ins SRAM passen, oder ins Eeprom (in den Flash sowieso). 128/256 ASCII-Muster müßten in den Flash, aber die machen eh keinen Sinn...
Das mit den RAW schnall ich immer noch nicht...

was funktioniert und was funktioniert nicht?

Bitte eventuell neue Themen erstellen, wenn es zu sehr von Thema RFM12B an Tiny44 und Tiny2313 via USI abweicht, ich habe leider den Überblick verloren

Die Kommunikationsprobleme ATtiny <--USI--> RFM scheinen geklärt zu sein - offensichtlich lief der USI schon recht früh korrekt nur eben der Fauxpas mit der Masseverbindung. Aber der Empfänger scheint eben nicht die gesendeten Daten des Senders zu erhalten/liefern. Und mMn kann man auch nicht sicherstellen, daß der Sender überhaupt das gewünschte sendet. Deswegen hat dannyboy das ganze wohl erstmal beiseitegelegt (sorry, daß ich das mit dem USI weiter so breitgetreten hab), und sich dem anderen Projekt gewidmet. Das hat er hier eigentlich nur kurz erwähnt, 'ne diesbezügliche Diskussion hätte natürlich in ein anderes Topic gehört. Dort wurde eigentlich kein konkretes Problem erwähnt, außer daß die Verdrahtung auf dem Breadboard inzwischen aussieht wie Kraut und Rüben... kennen wir ja alle
Inzwischen ist das jetzt so durcheinander, daß man es nichtmal den Mods zumuten kann, das zu entdröseln...

 

[avr_racer]

Das bezog sich auf das zu emulierende SPI. da bringt mich der vorhandene UART nicht weiter, aber ein echtes SPI würde es tun. Mag sein, daß ich jetzt von den Tinies nicht soooo die Ahnung habe, zeig mir doch mal bitte den TWI im ATtiny2313, oder meintest Du da was anderes?

ARGGGGHHHHH mist bin gerade an meiner RGB-Säule/Flaschensockel dran und hab das falsche DB angeschuat war vom MEGA8. Natürlich hat der T2313 kein TWI.

Ja, das hast Du, ich bin darauf eingegangen, weil bei dem von dannyboy eingesetzten ATtiny13 diese 5 Pins gar nicht verfügbar sind. Mit dem seriellen Empfang und einem gelatchten Ausgangs-Schieberegister sind bereits alle Beine verbraucht. Wenn noch irgendwas anderes an den Tiny soll, muß es an den 595 kaskadiert werden. Dann kann man aber auch gleich die 16 Digits mit drei 595ern ansteuern. Warum/wie danny sechs nutzt, ist mir unklar. Offensichtlich will er das Multiplexing aber "andersrum" machen, über die Segment-Leitungen. wären dann acht pro "Bild".

Na Danny sagte doch schon das es 2 verschiedene Sachen sind und nichts miteinander zu tun hat. Da sind wir beide wohl in die flasche Richtung galoppiert


Stimmt wird sonst zu unübersichtlich. I bin raus. Guten Rutsch + Bits u Bytesbruch

 

[dannyboy1994]

@Dirk Also Per logicanalyzer funktioniert die ansteuerung per USI und das statusregister lässt sich auch auslesen. Sendenroutine läuft laut LA und Empfangsroutine auch, nur wird zwar gesendet aber beim anderen in 20 cm entfernung kommt nichts an...Also scheinen die initwerte nicht zu stimmen. Das ganze ist nun sehr in eine USI debatte entgleist. War aber sehr viel wissenswertes dabei Falls man mal das USI genaur unter die lupe nehmen will. Auch hat die erwähnung eines nebenprojekts bisschen reingefunkt. Also beim RFM steht bis jetzt keine funktionstüchtige verbindung.

@Dirk in 70 steht eine routine welche anzeichen eines erfolgs verspricht. Nud die init werte scheinen nicht zu stimmmen