Hallo lieber Microcontrollercontroller, Ich möchte mit einem AVR128DB48 eine RTC ansteuern. Um genau zu sein die RV-8063-C7 von Microcrystal. Mein Problem ist, dass diese RTC nur 3 Leitungen für SPI hat: SCL, SDIO und CE. Im Datenblatt vom AVR128DB ist auf Seite 407 Kapitel 28.1 (SPI - Features) zu lesen: "Three-Wire Synchronous Data Transfer". https://ww1.microchip.com/downloads/en/DeviceDoc/AVR128DB28-32-48-64-DataSheet-DS40002247A.pdf Weitere Hinweise zur Verwendung kann ich aber keine finden, weder wie ich es anzuschließen habe, noch irgend ein dafür zuständiges Register... Das Internet hat ein paar Bastellösungen mit einem Widerstand zwischen MISO und MOSI zu bieten, das kommt für meine Anwendung aber nicht in Frage. Ich habe auch noch das Beitrag "ATMega48 mit 3-wire SPI" gefunden, ist das alles, einfach MOSI vom AVR an SDIO der RTC ??? Werde es auf jeden Fall Morgen testen. Wenn es das ist, kann ich dann sowohl 3-Wire als auch 4-Wire SPI Geräte über den selben Bus ansprechen ? Sollte doch problemlos möglich sein oder ? Besten Dank Justus
Justus K. schrieb: > Weitere Hinweise zur Verwendung kann ich aber keine finden, weder wie > ich es anzuschließen habe, noch irgend ein dafür zuständiges Register... Ich schon: https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-8063-C7_App-Manual.pdf Das dürfe eigentlich alles erschlagen was man an Fragen hat.
Justus K. schrieb: > ist das alles, einfach MOSI vom AVR an SDIO der RTC ? Wenn's der Falk dir sagt, und ein fragender User das auch noch bestätigt, dann kann's ja nicht so falsch sein.
uff basse schrieb: > Ich schon: > > https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-8063-C7_App-Manual.pdf > > Das dürfe eigentlich alles erschlagen was man an Fragen hat. Naja das Datenblatt ist mir bekannt, wollte auch nichts zur RTC wissen sondern habe ehr nach sowas wie 3-Wire-Mode-Enable in einem Register vom AVR gesucht... Aber gut wenns der Falk sagt wird's wohl klappen... Danke
Du überträgst doch eh immer nur ein paar Bytes. Da kannst du dochh problemlos die RTC an drei GPIOs hängen und das ganze komplett in Software abhhandeln. Wie das geht, ist ja ausführlich dokumentiert. fchk
Justus K. schrieb: > Ich habe auch noch das Beitrag "ATMega48 mit 3-wire SPI" > gefunden, ist das alles, einfach MOSI vom AVR an SDIO der RTC ? Wenn du niemals Daten von der RTC lesen willst, ja, dann ist das so einfach. Wenn du MISO am AVR nicht beschaltest, wie sollten denn Daten zurück zum AVR kommen? > Das Internet hat ein paar Bastellösungen mit einem Widerstand zwischen > MISO und MOSI zu bieten, das kommt für meine Anwendung aber nicht in > Frage. Warum eigentlich nicht? Das wäre die einfachste Lösung. Alternativ, wie schon geschrieben wurde, alles in Software machen statt des Hardware-SPI.
Liest man tatsächlich viel mit dem 1K-Widerstand. Ich würde eher ne Schottky-Diode und einen Pull-Up nehmen.So hat man wenigstens "halbwegs ordentlichen" LOW_Pegel. Der MOSI lässt sich beim AVR ja nicht als Open-Drain-Output konfigurieren. Bei anderen Architekturen geht das ja.
Jörg W. schrieb: > Wenn du MISO am AVR nicht beschaltest, wie sollten denn Daten zurück zum > AVR kommen? Ja genau das frage ich mich auch! Grundsätzlich ist mein Problem nicht, dass ich diese RTC über irgendeinen Weg zum laufen bekommen muss... Ich kann auch einfach eine Anderen nehmen. Sowohl über Software als auch mit Widerstand läuft die RTC bei mir Problemlos. Ich frag mich viel eher wie es konkret mit 3-Wire-SPI gehen soll bzw. wie sich das die Hersteller vorstellen... Microcrystal hat es mir ähnlich erklärt wie hier zu lesen Beitrag "ATMega48 mit 3-wire SPI" (einfach nur MOSI anschließen) aber ich versehe einfach nicht wie das klappen soll... Geht das bei anderen Microcontrollern?? Also klar es wird welche geben die auch nur ein SDIO Anschluss haben aber ich mein bei andern mit 4-Wire-SPI. Meine auch mehr oder weniger elegante Lösung sieht wie folgt aus:
1 | PORTA.OUTSET = PIN7_bm; //CE HIGH |
2 | SPI0.DATA = DataSend; |
3 | while(!(SPI0.INTFLAGS & SPI_IF_bm)) //Warten bis Übertragung fertig |
4 | ;
|
5 | PORTA.DIRCLR = PIN4_bm; //MOSI auf Input setzen |
6 | SPI0.DATA = 0x00; //Dummy byte seden |
7 | while(!(SPI0.INTFLAGS & SPI_IF_bm)) |
8 | ;
|
9 | PORTA.OUTCLR = PIN7_bm; //CE LOW |
10 | PORTA.DIRSET = PIN4_bm; //MOSI zurück auf Output |
11 | DataReceive = SPI0.DATA; //Daten einlesen |
Also einfach MISO und MOSI zusammen an SDIO und vor dem Senden des Dummy Bytes MOSI Output verbieten. Klappt soweit gut. Aber das kann doch so nicht gedacht sein oder ????
:
Bearbeitet durch User
Justus K. schrieb: > Mein Problem ist, dass diese RTC nur 3 Leitungen für SPI hat: SCL, SDIO > und CE. Also eine bidirektionale Datenleitung (halbmutiplex), ansonsten alles das Übliche. > Im Datenblatt vom AVR128DB ist auf Seite 407 Kapitel 28.1 (SPI - > Features) zu lesen: "Three-Wire Synchronous Data Transfer". > https://ww1.microchip.com/downloads/en/DeviceDoc/AVR128DB28-32-48-64-DataSheet-DS40002247A.pdf Da ist CS (bzw. in deinem Fall CE) nicht eingerechnet. > Weitere Hinweise zur Verwendung kann ich aber keine finden, weder wie > ich es anzuschließen habe, noch irgend ein dafür zuständiges Register... Gibt's auch nicht. Halbmultiplex wird nicht unterstützt. > Das Internet hat ein paar Bastellösungen mit einem Widerstand zwischen > MISO und MOSI zu bieten, das kommt für meine Anwendung aber nicht in > Frage. Dann lass' den Widerstand einfach weg und verbinde MOSI und MISO direkt. Der Widerstand dazwischen dient nur zum Schutz gegen falsche Programmierung, elektrisch ist er nicht nötig. Solange du alles richtig machst, kannst du ihn also problemlos weglassen. > Wenn es das ist, kann ich dann sowohl 3-Wire als auch 4-Wire SPI Geräte > über den selben Bus ansprechen ? Sollte doch problemlos möglich sein > oder ? Nein. Dann wird der Widerstand doch wieder nötig. Oder eine andere externe Maßnahme, die denselben Zweck besser erfüllen kann, z.B. ein Multiplexer.
c-hater schrieb:
Verdammt, da hatte ich doch von Anfang an schon das Ende im Kopf und
deswegen einen falschen Begriff verwendet.
Also: überall, wo "halbmultiplex" steht, bitte gedanklich durch den
korrekten Begriff "halbduplex" ersetzen.
Justus K. schrieb: > Ich frag mich viel eher wie es konkret mit 3-Wire-SPI gehen soll bzw. > wie sich das die Hersteller vorstellen. "3-Wire-SPI" ist halt kein Standard.
Justus K. schrieb:1 | PORTA.DIRSET = PIN4_bm; //MOSI zurück auf Output |
2 | DataReceive = SPI0.DATA; //Daten einlesen |
> Aber das kann doch so nicht gedacht sein oder ????
Wenn Du MOSI, also "Master Out" des µCs auf Ausgang setzt, bevor der
Slave zu antworten beginnt, dann arbeiten beide gegeneinander, offenbar
gewinnt bei Dir die Treiberstufe des Slave.
Justus K. schrieb: > Weitere Hinweise zur Verwendung kann ich aber keine finden, weder wie > ich es anzuschließen habe, noch irgend ein dafür zuständiges Register... Komisch... Man kann doch USART als SPI benutzen. One-Wire Half Duplex Mode ist in Datasheet gut beschrieben.
:
Bearbeitet durch User
Maxim B. schrieb: > Man kann doch USART als SPI benutzen. Mit welcher Baudrate schafft man es, dass die Antwort 3,5 Jahre zur Übertragung braucht? ;-)
Justus K hat nicht geschrieben, daß eine Lösung gefunden wurde. Vielleicht hat er die Sache zur Seite gelegt, in der Hoffnung, daß irgendwann doch klappt? AVR128DB64 hat sechs USARTs, so kann man bestimmt eins für 3-wire SPI nehmen. Es gibt leider in Internet zu wenig von neuen AVR-Serien. Wenn man über "AVR128" sucht, bekommt man Links wie Regel nur für ATMega128. Und gerade mit Peripherie gibt es viele Unterschiede. Deshalb denke ich, jede Diskussion bzg. AVR-Serie hat Wert. Ich möchte gerade mit AVR128DB mehr machen. Deshalb suche ich alles mögliche darüber, ich habe sogar Datasheet 730 Seiten per Google auf Deutsch übersetzt, Seite zu Seite (bis Kapitel 39, dort kann man ja nichts verwechseln), um alles besser verstehen zu können, bis auf Wort...
:
Bearbeitet durch User
Maxim B. schrieb: > Datasheet 730 Seiten per Google auf Deutsch übersetzt, Seite zu Seite > (bis Kapitel 39, dort kann man ja nichts verwechseln), um alles besser > verstehen zu können Ich bezweifle ganz stark, dass man so eine automatische Übersetzung besser verstehen kann.
Jörg W. schrieb: > Ich bezweifle ganz stark, dass man so eine automatische Übersetzung > besser verstehen kann. Manchmal geht es um das Wort, um Logik richtig zu verstehen. Ich lebte zwar in Sachsen, aber Anglo-Sächsisch kann ich leider nicht ausreichend gut. Nur so ungefähr, was grobe Fehler möglich macht (nun lebe ich in Gebiet, wovon englische Könige stammen. Leider hilft das mir mit Englisch auch kaum). Ich kann auch sagen, daß das für Google spürbar besser klappt (wohl Dank Verwandschaft von Sprachen), als z.B. Englich -> Russisch. Schwierigkeit ist nur die einzige: Deutsch braucht (nicht zuletzt wegen Höfflichkeit der Sprache, die Englisch nicht kennt) mehr Worte für das Gleiche. Will man in PDF gleiche Seiten für Links beibehalten, so muß man dann viel formatieren. Aber stimmt: um Gedichte zu übersetzen, und dabei in Reim zu bleiben, dafür ist Google noch nicht reif.
:
Bearbeitet durch User
Maxim B. schrieb: > nicht zuletzt wegen Höfflichkeit der Sprache, die Englisch nicht kennt Oh, nur amerikanisches Englisch ist ungehobelt. :-) Britisches Englisch ist sehr höflich. ;-) https://englishwithatwist.com/wp-content/uploads/2015/07/How-to-be-polite.jpg
Maxim B. schrieb: > Und > gerade mit Peripherie gibt es viele Unterschiede. Ich denke mal, gerade das ist es, was viele abschreckt. Z.B. wurden die Timer völlig umgemodelt und in ihren Interruptquellen kastriert. Es ist irgendwie nicht erkennbar, wo die neuen Typen die Programmierarbeit erleichtern könnten. Mehr RAM, Timer, UARTs usw. hätte man auch kompatibel implementieren können. Die klassischen AT90, ATtiny, ATmega waren dagegen alle sehr ähnlich und dadurch leicht austauschbar. Und wenn man eh so viel neu lernen muß, dann kann man auch gleich zu STM32 oder LPC wechseln.
Dürfte sich im Wesentlichen um die XMega-Peripherie handeln. Einheitliche Registerblöcke haben auf jeden Fall schon mal was. Aber ja, der Unterschied zu ARMs ist nicht sehr groß (auch zu denen aus dem eigenen Hause).
Jörg W. schrieb: > Dürfte sich im Wesentlichen um die XMega-Peripherie handeln. Mit dem Unterschied, daß AVRxxxDB auch mit 5 Volt kann, d.h. MOSFET und blauen (und einige grünen) LEDs ohne zusätzlichen IC. Und noch mehr: PORTC kann andere Spannung haben. Z.B. alles von 3 Volt (SD-Card, FRAM usw.), aber MAX7219 (unter 4 Volt will nicht arbeiten) mit 5 Volt über PORTC. Oder umgekehrt, alles von 5 Volt (oder gar von 2 Volt! Oder unmittelbar von Li-OH) und FRAM mit SD-Card über PORTC. Dabei bleibt das alles bei AVR-Kern, man muß nicht umlernen, nur HW-Adressen ändern. Man kann sogar Assembler benutzen! Und Bonus: kostet nur 1/3 von ATMega1284 (auch 16k SRAM). Einziges, was mich bisher bremste, ist Pinraster 0,5 mm, aber ich habe das Problem gelöst.
:
Bearbeitet durch User
Es ging ja auch um die Architektur der Peripherals.
Beitrag #7795076 wurde vom Autor gelöscht.
Es gibt sehr interessante Sachen, wie schon erwähnte Modi bei USART. Endlich DAC, was immer bei Mega fehlte. ADC 12 bit statt 10, auch nicht schlecht... Und viele, viele andere Möglichkeiten... Adresszuordnung wurde vernünftiger: nun haben Ports und GPR Bitzugang, hier ist das wichtiger als bei verhältnismäßig seltener benutzten Register von Timer usw (dazu gab es wilde Mischung bei Register: einige haben Bitzugang, andere nicht. Nun ist alles demokratisch gelöst :) ). Vielleicht wäre es falsch, AVR-Serie als etwas Großes zu betrachten, dafür gibt es ATXMega und STM32 usw. Aber dort, wo man früher gerne ATMega328 oder ATMega1284 genommen hat, wird AVR128DB einige Verbesserungen bringen. Klar: 0,5 mm Pinraster ist etwas schwieriger zu löten als 0,8 mm. Aber Mikroskop und passende Flußmittel helfen damit.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
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.