Ich möchte mehrere kleine Steuergeräte mit AVR-Controllern (ohne Quarz) verschiedener Generationen über eine 1-Draht-Leitung mit geringer Bitrate verbinden. Bin bei der Suche im Forum beim 124Bus von Peter Dannegger hängen geblieben, die Resourcen dafür wären vorhanden. Den Master müsste ich auf einen neueren AVR Tiny Serie 2 (Attiny1627) portieren. Der TCA wäre frei. Hat das vielleicht schon jemand gemacht und würde den Code teilen? Trotz Kommentaren im Code, so ganz selbsterklärend ist das Prinzip nicht: gibt es eine Erläuterung was da in welcher Reihenfolge gemacht wird? Also das Zusammenspiel der Timer und Interrupts beim Senden und Empfangen?
Warum fragst du nicht bei Peter direkt? Zumindest als Kontaktaufnahme. Ist als "peda" hier unterwegs. Die restlichen Infos könnt ihr ja dann hier posten, damit alle was davon haben. 🙂 PS. Vielleicht list Peter ja auch mit und antwortet direkt auf den Post.
:
Bearbeitet durch User
Mein Code verwendet 2 Compare-Interrupts. TCA hat 3, ist also geeignet. TCB hat keine, ist also nicht geeignet. TCD hat der 1627 nicht.
Ich gehe auch davon aus, das es mit dem TCA im Attiny1627 funktioniert. Meine Frage ging aber eher dahin, ob es eine Beschreibung des Übertragungskonzepts gibt. Beispielsweise wie die Synchronisierung genau funktioniert: was ist die Start- / Stopp- Bedingung, wie sieht die Trennung zwischen den Bits aus (also wie sieht z.B. ein 0xff auf der Leitung aus, gibt es Flanken, ist das ein einziger High-Pegel?). Wenn man den Timer0 des ATmega644 im Schlaf kennt, braucht man das natürlich nicht, dann erschließt sich einem der Code wie er knapp kommentiert ist. Ich wollte den aber direkt in einen Attiny1627 umsetzen und die neueren AVRs sind schon sehr viel anders aufgebaut. Ich nehme an, es wird ausschließlich mit der "Frequency (FRQ) Waveform Generation" funktionieren, nur die löscht den Counter beim Compare und toggelt einen Ausgangspin. Die ganzen PWM-Modes kann man wohl vergessen. Ist aber nur geraten, aus dem Vergleich mit dem Mega644-Datenblatt. Da fehlt mir jede Erfahrung mit dessen Zählern, so dass ich nicht beurteilen kann, ob mein Code das richtige tut. Einen Client habe ich nocht nicht aufgebaut. Das sollen ATtiny45 sein.
Wulf D. schrieb: > Meine Frage ging aber eher dahin, ob es eine Beschreibung des > Übertragungskonzepts gibt. Die Beschreibung 124Bus.txt und die Kommentare in der Senderoutine hast Du gelesen?
Ja, habe ich gelesen und mittlerweile auch verstanden. Wie auch den ganzen TCA. Der Master sendet wie er soll, werde jetzt einen Slave anpassen. Ist schon genau das was ich gesucht habe. Es gibt nach meinem Verständnis etwas missverändliche Formulierungen in dem Text, aber das ist Jammern auf hohem Niveau. Beispiel: Zitat: "Der Ruhezustand ist high (interner Pullup), daher muß eine gerade Anzahl an Pulsen übertragen werden. In meinem Beispiel erzeuge ich 2 Sync-Bits. Man könnte aber auch 15 Datenbits + 1 Sync senden." Beschreibt das wirlich den veröffentlichen Stand des Codes? Ich meine, dass im Beispiel zwei Bytes, also 16 Bit plus ein Synch-Bit gesendet werden. Es muss heissen, es muss eine un-gerade Anzahl an Pulsen gesendet werden. Die erste fallende Flanke ist das "Startsignal, jede weitere Flanke, egal in welche Richtung, ein Bit. Vielleicht ist es nur die Wortwahl, Pulse vs Flanke.
:
Bearbeitet durch User
Falls jemand den Bus auf einem tinyAVR® 2 family einsetzen will, habe den Master-Code angehängt. Der Slave läuft auf einem ATTiny 25/45/85. Da die neuen Tiny über einen Port-Multiplexer verfügen, hoffte ich auf eine flexible Zuordnung des Output Compare auf verschiedene mögliche i/o Pins. War aber nicht so, wie ich nach stundenlangem Studium der sehr komplizierten Konfiguration feststellen musste: nicht flexibler als beim alten Tiny85, auch hier bleiben zwei Alternativen. Klar, für den Preis von etwas mehr TX-Jitter könnte man auf CTC verzichten und den Timer per SW löschen. Verwendete Resourcen: - ATTiny 1627: TCA mit Compare CMP0 und CMP1, Portpin PB3 - ATTiny25: Timer1 mit OCR1A,B,C und Portpin PB4 Habe den Bus als Erweiterung in ein bestehendes Design eingebaut. Auf dem Tiny85 Timer0 läuft eine PWM im fast Mode und nun auch der Systemtimer, was sich gegenseitig nicht stört (war vorher auf Timer1). Kleinigkeiten sind gegenüber dem Original verändert: der Synch-Timer wird erst nach Empfang der ersten Startflanke aufgezogen, passt besser für mich. Auch die Warteschleife der Senderoutine (while( TCCR1 ); ) ist auskommentiert, die braucht man nur zu Demozwecken. In realer Anwendung macht man das anders. Fazit: sehr nützlich, resourcenschonend und betriebssicher.
Wulf D. schrieb: > Da die neuen Tiny über einen Port-Multiplexer verfügen, hoffte ich auf > eine flexible Zuordnung des Output Compare auf verschiedene mögliche i/o > Pins. > War aber nicht so, wie ich nach stundenlangem Studium der sehr > komplizierten Konfiguration feststellen musste: nicht flexibler als beim > alten Tiny85 Naja, du kanst für jeden der 6 möglichen Kanäle jeweils zwischen zwei Pins wählen. Das ist immerhin deutlich flexibler als bei den Classic-AVRs, wo du praktisch überhaupt keine Wahl hast. Und was die "Kompliziertheit" betrifft: Was, zum Teufel ist soll so kompliziert daran sein, 6 Bits in einem einzigen SFIOR entweder zu setzten oder nicht zu setzen?
Genau so dachte ich auch, als ich das Datenblatt quer las und anschießend ein Design auf eine kleine PCB packte. Kompliziert ist natürlich relativ: der Timer0 Abschnitt des Tiny85 ist 18 Seiten lang, der TCA0 des Tiny1627 48 Seiten. Aber die Länge wäre egal, wenn alles Wesentliche klar beschieben wäre. Leider muss man öfters zwischen den Zeilen lesen. Beispiele: für die Implementierung des 124Bus braucht man einen Zähler, der bei Erreichen eines gesetzten Wertes einen I/O toggelt. Das geht mit dem TCA0 im Frequency-Mode. Der TCA0 hat drei Compare-Register CMPn, n=0...2. Im Abschnitt "21.3.3.4.2 Frequency (FRQ) Waveform Generation" findet man an einer Stelle einen indirekten Hinweis, dass nur CMP0 zum Output Compare taugt. Ansonsten werden die CMPn in dem Abschnitt generisch beschrieben. Dann im Abschnitt "3. I/O Multiplexing and Considerations" mit der großen I/O Tabelle mit Zuordnungen zu den I/O-Pins: in der Spalte TCA0 stehen dort Dinge wie WO0, WO1, ... WO5. Wäre es nicht nützlich zu erwähnen, was "WO" heißt und wäre eine Zuordnung der WO zu irgendwelchen Ereignissen nicht sinnvoll? Mann muss raten bzw irgendwelche Foren durchstöbern. Soviel sei verraten, WO0 ist dem CMP0 zugeordnet. Letztes Beispiel, in "16.3.5 TCA Pin Positions" können im Register TCAROUTEA mit den Bits TCA05 ... TCA00 TCA0-Signale auf alternative Pins geschaltet werden, gemäß einer darunter abgebildeten Tabelle. Die ist aber genau gegenläufig sortiert, d.h. von 0,...,5. Welche TCA-Bit gehört nun wohin? Erklärt wird da nichts. Am Ende ist es genau so wie ich oben schon sagte, es bleiben genau zwei mögliche Pins für die Funktion, PB0 und PB3. Damit nicht mehr als beim Tiny85. Wegen des lausigen Datenblatts dauerte aber die Umsetzung viel länger.
Wulf D. schrieb: > Die ist > aber genau gegenläufig sortiert Ja, das ist mißverständlich. Wird WO0 nun über TCA00 oder TCA05 geschaltet? Wulf D. schrieb: > Im Abschnitt "21.3.3.4.2 Frequency (FRQ) Waveform Generation" findet man > an einer Stelle einen indirekten Hinweis, dass nur CMP0 zum Output > Compare taugt. Sehe ich nicht so. Alle 3 Compare können ihren Pin togglen: "The corresponding waveform generator output is toggled on each compare match between the TCAn.CNT and TCAn.CMPn registers." Comp0 bestimmt jedoch gleichzeitig die Periode: "For frequency generation, the period time (T) is controlled by the TCAn.CMP0 register instead of the Period (TCAn.PER) register." Und: "The TCAn.PER register contains the 16-bit TOP value in the timer/counter in all modes of operation, except Frequency Waveform Generation (FRQ)." Der Sinn dahinter erschließt sich mir nicht. Die Beschreibungen sind lange nicht mehr so ausführlich, wie von den alten Datenblättern gewohnt. Und Blockschaltbilder mit einer schwarzen Kiste "Control Logic" hätte man sich auch gleich schenken können (null Information).
Peter D. schrieb: > Wulf D. schrieb: >> Die ist >> aber genau gegenläufig sortiert > > Ja, das ist mißverständlich. Wird WO0 nun über TCA00 oder TCA05 > geschaltet? Bit 0 – TCA00: TCA0 Waveform output 0 Write this bit to '1' to select alternative output pin for TCA0 waveform output 0. Bit 5 – TCA05: TCA0 Waveform output 5 Write this bit to '1' to select alternative output pin for TCA0 waveform output 5 in split mode. Was sollte daran mißverständlich sein? Man muß bloß in der Lage sein, "waveform output 0" bzw. "waveform output 5" in die jeweiligen Acronyme "WO0" bzw. "WO5" zu übersetzen. Und natürlich einen einfachen englischen Satz verstehen können... > Wulf D. schrieb: >> Im Abschnitt "21.3.3.4.2 Frequency (FRQ) Waveform Generation" findet man >> an einer Stelle einen indirekten Hinweis, dass nur CMP0 zum Output >> Compare taugt. > > Sehe ich nicht so. > Alle 3 Compare können ihren Pin togglen: > "The corresponding waveform generator output is toggled on each compare > match between the TCAn.CNT and TCAn.CMPn registers." So ist es (zumindest lt. DB). Ich muss allerdings zugeben, dass ich das noch nie probiert habe. Wenn man mal annimmt, dass das DB Recht hat, wäre die Lage so: Die Frequenz kann für alle drei Kanäle (bzw. alle sechs im Split-Mode) nur gemeinsam konfiguriert werden. > Der Sinn dahinter erschließt sich mir nicht. Nun, man kann beliebig gegeneinander phasenverschobene Rechtecke mit einer gemeinsamen Frequenz auf bis zu sechs Kanälen ausgeben. Da würden mir schon diverse Anwendungen für einfallen... Aber ja: für die konkrete Anwendung 124Bus ist dieses Feature natürlich tatsächlich nicht sonderlich hilfreich. Höchstens eben dazu, den Kram auf einem von zwölf Pins ausgeben zu können, statt nur auf einem von zwei.
Ob S. schrieb: > Bit 5 – TCA05: TCA0 Waveform output 5 > Write this bit to '1' to select alternative output pin for TCA0 waveform > output 5 in split mode. > > Was sollte daran mißverständlich sein? Man muß bloß in der Lage sein,... Das stimmt, da hast du wohl ein besseres Datenblatt. Bei mir fehlt der Text. Mein Datenblatt war von 2020, mittlerweile gibts bei Microchip eines von 2021. In beiden fehlt der von dir zitierte Text. Peter D. schrieb: > Wulf D. schrieb: >> Im Abschnitt "21.3.3.4.2 Frequency (FRQ) Waveform Generation" findet man >> an einer Stelle einen indirekten Hinweis, dass nur CMP0 zum Output >> Compare taugt. > > Sehe ich nicht so. > Alle 3 Compare können ihren Pin togglen: > "The corresponding waveform generator output is toggled on each compare > match between the TCAn.CNT and TCAn.CMPn registers." Ich habe es ausprobiert, hatte ja in meiner PCB einen anderen Pin vorgesehen. Da ging aber nichts, CMP1 oder CMP2 bewegten im FRQ-Mode keine der ihnen zugeordneten Pins. Ich hatte allerdings kein PER (default 0) gesetzt, keine Ahnung ob das notwendig gewesen wäre. Eigentlich sollten es funktionieren, im gerade geladenen 2021er Datenblatt steht: "Use the TCAn.CMP1 and TCAn.CMP2 registers to get additional waveform outputs WOn. The waveforms WOn can either be identical or offset to WO0." Das neuere Datenblatt ist hier erheblich ausführlicher.
Ob S. schrieb: > Bit 0 – TCA00: TCA0 Waveform output 0 > Write this bit to '1' to select alternative output pin for TCA0 waveform > output 0. > > Bit 5 – TCA05: TCA0 Waveform output 5 > Write this bit to '1' to select alternative output pin for TCA0 waveform > output 5 in split mode. Wo hast Du das her? Ich hab mir gerade das DS40002234B, © 2021 Microchip Technology Inc. von Microchip geladen. Dieser Text ist dort nicht enthalten. Ob S. schrieb: > Nun, man kann beliebig gegeneinander phasenverschobene Rechtecke mit > einer gemeinsamen Frequenz auf bis zu sechs Kanälen ausgeben. Kann man doch auch, wenn PER nicht auf nutzlos umgeschaltet wird. Man verliert durch diese Deaktivierung des PER nur Möglichkeiten.
:
Bearbeitet durch User
Das ist von einem tinyAVR Series 1. Anscheinend hat die Qualität der Datenblätter in der Series 2 weiter nachgelassen.
Hallo, ich versuche mich gerade in den 124Bus Code einzuarbeiten, da ich auch einen ATTiny85 als Slave mit einem ATmega328P (Arduino) als Master verbinden will. Der Slave soll einfach nach seinen Möglichkeiten Analog- und Digitalwerte an den Master übertragen. Ich bin gelernter Elektroniker, habe aber 30 Jahre als Java-Entwickler gearbeitet. Habe ab und zu auch etwas mit Elektronik und auch Arduino als Hobby getüftelt. Aber c (c++) Code habe ich eher durch copy/paste und mit den üblichen Befehlen für mich angepasst. Womit ich aber keine großen Erfahrungen habe, sind die ganzen Unterschiede der einzelnen Typen und (wenn auch mal gelernt (Z80)) die ganzen Microcontroller Specials wie Interrupts etc.! Daher habe ich ein paar Fragen: 1) Kann ich den Code für den ATmega644 auch auf den ATmega328 benutzen? (Natürlich abgesehen vom Speicher den ich noch für den Rest brauche) 2) Muss ich irgendwelche anderen Dinge wie Fuses beachten (setzen)? 3) Ich schätze, ich kann die main Methode auch in eine andere Datei schreiben und den Rest als Library-Datei 'includen', oder? 4) Ich verstehe die Verwendung von der 124Bus.h von Wolf.D nicht. Wo wird sie eingebunden? Vielen Dank und Grüße Arvid
Arvid G. schrieb: Klar: Troll. Aber sei's drum. > 1) Kann ich den Code für den ATmega644 Welchen genau? > 2) Muss ich irgendwelche anderen Dinge wie Fuses beachten (setzen)? Kommt drauf an. > 3) Ich schätze, ich kann die main Methode auch in eine andere Datei > schreiben und den Rest als Library-Datei 'includen', oder? Nö. Libraries kann man nicht includen, nur linken. Allenfalls deren Header kann man includen. > 4) Ich verstehe die Verwendung von der 124Bus.h von Wolf.D nicht. > Wo wird sie eingebunden? Da, wo man sie braucht.
Arvid G. schrieb: > 1) Kann ich den Code für den ATmega644 auch auf den ATmega328 benutzen? > (Natürlich abgesehen vom Speicher den ich noch für den Rest brauche) Die Pinbelegung dürften abweichen. Auch hat Atmel gerne mal die Register- und Bitnamen zwischen den Derivaten geändert. Vergleiche mal mit dem Code für den ATmega48. Die Speicherbenutzung ist lächerlich gering, da gibt es keine Probleme:
1 | Program: 692 bytes (1.1% Full) |
2 | (.text + .data + .bootloader) |
3 | |
4 | Data: 4 bytes (0.1% Full) |
5 | (.data + .bss + .noinit) |
Grundlegende Kenntnisse der C Syntax sollte man aber schon haben. Die Fehlermeldungen des AVR-GCC sind auch in der Regel sehr ausssagekräftig. Man darf nur nicht so tun, als wären sie in Chinesisch.
@Peter: Danke für die Hilfe! ja, da muss ich mich in C noch einarbeiten. Dafür nutze ich ja Deinen Code ;) Ok, die Fragen 1 bis 3 lassen wir mal bei Seite! Das sind Einsteigerfragen, die ich selber herausfinden muss. Aber die 4. Frage ist schon begründet! Es ist nicht Dein Code, aber ich finde eben keinen Eintrag <c>#include "124Bus.h"</c> in Wolf D.'s Code (Deshalb habe ich meine Frage auch hier gepostet)! @Ob.S: Du scheinst, erstens nicht zu wissen was ein Troll ist, da Du selber einer bist! Definition (laut Internet):"Im Netzjargon wird eine Person als Troll bezeichnet, die durch störende, aggressive oder beleidigende Beiträge auf sozialen Netzwerken, Message-Boards oder Chat-Gruppen eine emotionale Reaktion bei anderen Community-Mitgliedern auslösen wollen. Dieses Vorgehen wird entsprechend als „Trollen“ bezeichnet." Ich kann auch trollen: Wahrscheinlich bist Du einer der vom Leben frustrierten! Ist Deine Frau weggelaufen, oder hattest Du nie eine?
Arvid G. schrieb: > Es ist nicht Dein Code, aber ich finde eben keinen Eintrag <c>#include > "124Bus.h"</c> in Wolf D.'s Code (Deshalb habe ich meine Frage auch hier > gepostet)! > Hallo Arvid, Du hast Recht, habe beim Abstrippen des Democodes aus meiner Anwendung die include fälschlicherweise rausgekürzt. Du musst also
1 | #include "124Bus.h" |
oben im Code ergänzen. Lass Dich nicht ärgern. Du bekommst neben nutzlosen Antworten hier auch (fast) immer sehr brauchbare. Gruß Wulf
Bitte 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.