Hallo, Ich möchte an dem ATtiny1626 im SSOP-20 an USART0 zwei RS485-ähnliche Treiber anschließen. Da sie nicht gleichzeitig benutzt werden sollen, und ich einen Multiplexer einsparen möchte, sind sie an verschiedene Pins des ATtiny angeschlossen. Die jeweils zu benutzenden Pins werden über das PORTMUX Register USARTROUTEA eingestellt. Die zweite USART (1) wird zum ansteuern verwendet. Solange ich die Standardpins (PB0-PB3) benutze funktioniert alles. Sobald ich aber die anderen (PA1-PA4) verwende geht zwar TXD, aber an XDIR kommt immer 0 raus. Die USART0 wird immer gleich initialisiert, der einzige Unterschied ist nur der Inhalt des USARTROUTEA Register. Da es die gleiche Software ist, kann es eigentlich kein SW-Fehler mehr sein. Die Pinkonfiguration der XDIR Pins (PB0/PA4) ist laut Datenblatt egal, aber der Vollständigkeit halber: Sie werden beide als Ausgang mit dem Wert 0 initialisiert. Die Hardware kann es auch nicht sein, da PA4 funktioniert wenn ich ihn über VPORTA.OUT setze. Trotz gesetztem RS485 Bit in USART0.CTRLA kann ich den Pin PA4 über VPORTA.OUT setzen und löschen. Das sollte eigentlich nicht so sein. In den Errata des ATtiny steht darüber nichts. Habe ich da jetzt doch noch irgendwo ein Problem, oder ist das jetzt ein Fehler vom ATtiny? Da ich wirklich nicht mehr weiter weiss, vielleicht hat jemand einen Tipp wo ich noch suchen kann. PS. Ich hätte auch die USART1 umschalten können, aber vom Layout war es so einfacher. Ob es mit der USART1 funktioniert, weiß ich also im Moment nicht. Morgen probiere ich das Mal. VG Georg
Naja, der ist ja aus der tinyAVR® 2 family (was auch immer das bedeuten mag), also recht neu. Da sind Bugs denkbar, neue ICs werden ja gerne als grüne Bananen auf den Markt geworfen. Ist ja schon die 3. tiny-Familie innerhalb kurzer Zeit.
Hallo, wenn alle Stricke reißen sollten frage einmal Spence. Ich lese zumindestens bei ihm keine Einschränkungen. https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/Ref_Serial.md
Georg P. schrieb: > Die zweite USART (1) > wird zum ansteuern verwendet ??? vs. Georg P. schrieb: > Sobald ich aber die anderen (PA1-PA4) verwende geht zwar TXD, aber an > XDIR kommt immer 0 raus. an PA1-PA4 ist doch aber USART1? Peter D. schrieb: > Da sind Bugs denkbar Die sind in der Regel dokumentiert. Zwar sind in den Errata zwei Fehler zum USART aufgeführt, scheinen aber hier keine Rolle zu spielen... https://onlinedocs.microchip.com/pr/GUID-CB68AD87-CF90-4076-861C-33A2E4841D9C-en-US-13/index.html?generated-topic-000006
:
Bearbeitet durch User
Hallo, ich vermute, wenn ich den TO richtig verstehe, dass er nicht 2 USARTs initialisieren möchte, sondern nur mit einer USART zwischen den Pins umschalten möchte, mittels Portmux. Ob das sinnvoll ist weiß ich nicht Zufällig ist USART0 Portmux = USART1. Danke Gerhard. Ich vermute ein "Problem" im Code. Nach Portmux Änderung muss bestimmt die USART neu initialisiert werden. Nur Portmux umschalten dürfte nicht ausreichen. Ich weiß nicht was der TO mittels Portmux genau bezwecken möchte. Scheinbar werden ja immer beide USARTs benötigt. Deswegen würde ich mit der mangelnden Info davon ausgehen das er wohl besser USART0 und USART1 zur Verfügung haben sollte. Falls er mit RS485 Full-Duplex machen möchte wäre das einfacher. Ansonsten sollte der TO nochmal sein Anliegen beschreiben. Ohne Info, ohne Code wird der Thread sonst zur Ratestunde.
Veit D. schrieb: > Hallo, > > ich vermute, wenn ich den TO richtig verstehe, dass er nicht 2 USARTs > initialisieren möchte, sondern nur mit einer USART zwischen den Pins > umschalten möchte, mittels Portmux. Ob das sinnvoll ist weiß ich nicht > Zufällig ist USART0 Portmux = USART1. Danke Gerhard. Aus meiner Beschreibung sollte eigentlich hervorgehen, dass die andere USART auch benutzt wird. Somit bräuchte ich 3 USARTs, da aber zwei davon nie gleichzeitig benutzt werden, wollte ich USART0 über den PORTMUX umschalten. Die andere (USART1) braucht kein XDIR und ist fest auf PC1 und PC2 gelegt. > Ich vermute ein "Problem" im Code. Nach Portmux Änderung muss bestimmt > die USART neu initialisiert werden. Nur Portmux umschalten dürfte nicht > ausreichen. Ich glaube nicht dass es das Problem ist, da ich im zum testen noch gar nicht im Betrieb umschalte, sondern nur die Konfiguration nach dem Start ändere. Hier wird zuerst USARTROUTEA beschrieben und erst dann die USART0 initialisiert. Aber es könnte im laufenden Betrieb natürlich notwendig sein. > Ich weiß nicht was der TO mittels Portmux genau bezwecken möchte. > Scheinbar werden ja immer beide USARTs benötigt. Deswegen würde ich mit > der mangelnden Info davon ausgehen das er wohl besser USART0 und USART1 > zur Verfügung haben sollte. Falls er mit RS485 Full-Duplex machen möchte > wäre das einfacher. Ansonsten sollte der TO nochmal sein Anliegen > beschreiben. Ohne Info, ohne Code wird der Thread sonst zur Ratestunde. Ich dachte ich hätte ausreichend Info geliefert. Also nochmal dasselbe mit anderen Worten. An USART0 sind 2 physikalisch verschiedene Treiber angeschlossen, beide benutzen nach außen hin nur eine Leitung (wie RS485, nur nicht differentiell), deshalb wird für beide XDIR benötigt. Es kann aber nur ein Gerät angeschlossen werden, dieses legt dann fest, welcher Treiber benutzt wird. Der XDIR von USART0 an PA4 liefert immer 0. Wenn ich ihn als Port Pin verwende geht er aber, also die HW ist i.O. Ich glaube nicht, dass der Code weiter hilft, aber wer ihn sehen möchte: Die main:
1 | int main(void) { |
2 | |
3 | initClock(); |
4 | |
5 | pinINIT_PIN_CTRL(); |
6 | pinINIT_PORTS(); |
7 | pinUSE_SL_IF(); |
8 | |
9 | initUpUsart(); |
10 | initDnUsart(); |
11 | initTCB0(); |
12 | initInterrupts(); |
13 | |
14 | for(;;) { |
15 | stateMachine(); |
16 | }
|
17 | }
|
USARTROUTEA wird mit dem Macro pinUSE_SL_IF() gesetzt. Für die andere Option gibt es das Macro pinUSE_OF_IF(). Zum Test habe ich hier einfach das andere Macro verwendet. Die Initialisierung der USART0 erfolgt in initDnUSART() (DN_USART == USART0):
1 | void initDnUsart(void) { |
2 | DN_USART.BAUD = (uint16_t)USART_BAUD_RATE(lnkBAUD_RATE); |
3 | DN_USART.CTRLC = USART_SBMODE_2BIT_gc | USART_PMODE_EVEN_gc | |
4 | USART_CMODE_IRCOM_gc | USART_CHSIZE_9BITH_gc; |
5 | DN_USART.CTRLA = (1<<USART_RS485_bp); |
6 | DN_USART.CTRLB = (1<<USART_TXEN_bp); |
7 | DN_USART.DBGCTRL = 1<<USART_DBGRUN_bp; |
8 | }
|
Das laufende Programm schaltet die Ports von USART0 noch nicht! Den IRCOM Mode habe ich schon Mal auf Standard asynchron geändert. Hat nichts gebracht.
Georg P. schrieb: > Solange ich die Standardpins (PB0-PB3) benutze funktioniert alles. > Sobald ich aber die anderen (PA1-PA4) verwende geht zwar TXD, aber an > XDIR kommt immer 0 raus. PA1-PA4 sind aber die default-Verbindungen für UART1. Ist der auf die alternativen Verbindungen umgeschaltet?
:
Bearbeitet durch User
Ich habe gerade die USARTs vertauscht. Hier ist es dasselbe Problem, mit den Standardpins geht es (XDIR auf PA4), aber mit der Alternative 1 bleibt XDIR, jetzt auf Pin PC3, immer 0. Wenn ich den Pin mit VPORTC.OUT ansteuere geht PC3, also die HW ist es nicht. Ich habe den Pin jetzt vor dem Senden auf 1 gesetzt. Sobald aber in das Senderegister der USART geschrieben wird, geht er wieder auf 0 (Bit RS485=1). Wenn ich das Bit RS485 auf 0 setze kann ich den Pin normal benutzen. Mit USART0 ist mir das nicht aufgefallen, aber da wollte ich ja nur probieren, ob der Ausgang funktioniert. Also wohl doch ein Fehler beim PORTMUX oder was? Ich werde jetzt den RS485 Mode nicht mehr benutzen und den XDIR Pin als normalen Ausgang verwenden. Das selbe Timing bekommt man damit vermutlich nicht hin, aber ich glaube das ist nicht so kritisch,
Georg P. schrieb: > Die zweite USART (1) > wird zum ansteuern verwendet. Wenn die mal testweise nicht verwendet wird, funktioniert die Umschaltung der USART0 zwischen Default- und Alternativpositionen vielleicht dann vollständig?
Klaus S. schrieb: > PA1-PA4 sind aber die default-Verbindungen für UART1. Ist der auf die > alternativen Verbindungen umgeschaltet? Ja, USART1 ist auf Port C gelegt und funktioniert.
Gerhard H. schrieb: > Georg P. schrieb: >> Die zweite USART (1) >> wird zum ansteuern verwendet. > > Wenn die mal testweise nicht verwendet wird, funktioniert die > Umschaltung der USART0 zwischen Default- und Alternativpositionen > vielleicht dann vollständig? Hab ich gerade probiert, funktioniert aber auch nicht.
Georg P. schrieb: > Hab ich gerade probiert, funktioniert aber auch nicht. Summa summarum läuft die Diagnose also drauf hinaus daß die Alternativpositionen nicht exakt so wie die Defaultpositionen funktionieren. Ein Fall für den technischen Microchip-Support, so nicht doch noch eine wesentliche Info unterm Tisch verblieben ist...
Gerhard H. schrieb: > Summa summarum läuft die Diagnose also drauf hinaus daß die > Alternativpositionen nicht exakt so wie die Defaultpositionen > funktionieren. Ein Fall für den technischen Microchip-Support, so nicht > doch noch eine wesentliche Info unterm Tisch verblieben ist... Ja, so sieht es aus. Ich wüsste nicht welche Info noch fehlt. Ich habe das RS485 Bit jetzt aus und benutze die Pins als normale Portpins. Damit funktioniert es. Da der Microchip-Support mir auf meine letzten Anfragen nicht einmal mehr geantwortet hat darf das gerne jemand anders machen. Eventuell stolpert ja Mal eine Firma mit großen Stückzahlen darüber. Ich mache das nur noch zum Zeitvertreib und bin froh dass es jetzt irgendwie geht. Danke an alle Beteiligten. Georg
Vorweg: wirklich helfen kann ich nicht, mangels eines Controllers aus der 'tinyAVR® 2 Family'. Jedoch möchte ich zu bedenken geben: > Da der Microchip-Support mir auf meine letzten Anfragen > nicht einmal mehr geantwortet hat ... Dies erscheint mir durchaus verständlich, und da sind wir im Forum in einer ähnlichen Lage wie der Support: eine Fehlerbeschreibung über, in der Summe, mehrere Seiten hinweg, und auf die Nachfrage nach dem Programm werden einzelne Stücke ohne größere Aussagekraft präsentiert. Was Sie uns da schildern, ist (natürlich) das, wovon Sie überzeugt sind, es programmiert zu haben - das ist aber nicht zwingend das, was auch wirklich programmiert wurde. Ein auf das Mindestmaß reduziertes Programm, das den (vermeintlichen) Fehler aufzeigt, ist die Voraussetzung für eine gedeihliche Kommunikation, sowohl hier im Forum als auch mit dem Microchip-Support.
An S.L. Damals ging es nicht um ein Problem mit einem AVR sondern um ein Problem mit MPLABX. Und ja, damals habe ich das Problem auf das Essentielle verkürzt und auch mit Bildern beschrieben. Und hier konnte es nicht am Programm liegen, da es ja funktioniert wenn man das Standardport verwendet. Sobald man auf Alt1 umschaltet geht XDIR nicht mehr, aber die andern seriellen Pins schon. Der einzige Unterschied im Programm ist die Initialisierung des PORTMUX. Laut Datenblatt ist es egal, wie der XDIR Pin initialisiert ist, da er für diese Funktion automatisch auf Ausgang gesetzt wird. Außerdem funktioniert der Pin wenn ich ihn als normalen Ausgang betreibe. Also kein HW-Problem. Was glauben Sie was hier geschrieben worden wäre, wenn ich als Fehlerbeschreibung nur geschrieben hätte "XDIR von USART0 geht auf dem alternativen Port nicht, sondern bleibt immer 0"? Das wäre eine endlose Orgie von Fragen und Antworten geworden. Also habe ich genau beschrieben, was ich schon geprüft und ausgeschlossen habe. Offensichtlich haben das einige nur zum Teil gelesen und/oder nicht verstanden. Mal ganz abgesehen von den ganzen Fragen nach dem Sinn dessen was ich hier tue. Hat das irgendwas mit dem Problem zu tun? Georg
Als Mitarbeiter im Support würde ich diesen Satz > "XDIR von USART0 geht auf dem alternativen > Port nicht, sondern bleibt immer 0" in Kombination mit einem, sagen wir zwanzigzeiligen, Programm vorziehen vor dem wortreichen > habe ich genau beschrieben, was ich schon geprüft > und ausgeschlossen habe Denn als Supporter kann ich die Qualifikation des Gegenübers nur ungefähr beurteilen, mit einem Programm hingegen sehe ich den Fehler sofort vor mir. Dies nur als gutgemeinter Rat an Sie; kommt offenbar nicht an - also belassen wir es dabei, nichts für ungut. PS: > Hat das irgendwas mit dem Problem zu tun? Insofern, als es auch hier zu keiner Lösung kam, ich sehe nur Rückfragen und Mutmaßungen.
:
Bearbeitet durch User
S. L. schrieb: > Rückfragen > und Mutmaßungen wären bei undokumentierten Fehlern nichts ungewöhnliches. Ich ermutige mit dem Microchip-Support Kontakt aufzunehmen. Dafür ist er da und es kostet auch nichts.
S. L. schrieb: > Denn als Supporter kann ich die Qualifikation des Gegenübers nur > ungefähr beurteilen, mit einem Programm hingegen sehe ich den Fehler > sofort vor mir. 100% Zustimmung. Bisher ist das Ganze nur eine Vermutung. Erst wenn ein leicht zu verstehendes Minimalprogramm den Fehler auch auf einem zweiten und dritten Gerät zeigt, kann man den Verdacht auf einen Designfehler als ernsthaft begründet ansehen. Bis dahin gilt die Grundregel, daß die meisten Fehler nicht da liegen, wo man sie vermutet. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Bisher ist das Ganze nur eine Vermutung. Meine Vermutung: Du hast den Sachverhalt nicht verstanden! Zwar ist nicht auszuschließen daß dem TO noch ein Fehler passiert ist- wenn sich aber WDIR im RS485 Modus an Default- und Alternativpin wie beschrieben unterschiedlich verhält, aber in der Ansteuerung sonst alles gleich bleibt ist definitiv was faul im Staate Dänemark.
:
Bearbeitet durch User
Gerhard H. schrieb: > Meine Vermutung: Du hast den Sachverhalt nicht verstanden! > Zwar ist nicht auszuschließen daß dem TO noch ein Fehler passiert ist- Ja, so ist das. Immer dann, wenn andere Fehler nicht ausgeschlossen werden können, nenne ich den behaupteten Fehler eine Vermutung. Wahrscheinlich bin ich einfach arrogant. > wenn sich aber WDIR im RS485 Modus an Default- und Alternativpin wie > beschrieben unterschiedlich verhält, aber in der Ansteuerung sonst alles > gleich bleibt ist definitiv was faul im Staate Dänemark. Da sind wir uns 100%ig einig. Hätte ich mir sonst das Vergnügen geleistet, aufmerksam das Datenblatt eines Controllers zu studieren, den ich gar nicht besitze? Bei Microchip sitzen aber keine Freiwilligen mit Helfersyndrom, sondern bezahlte Leute. Und ich bin mir relativ sicher, daß die von ihrem Chef die Ohren langgezogen bekommen, wenn sie sich mit einer solchen Beschreibung, wie sie hier vorliegt, mehr als 5 Minuten beschäftigen. Gruß Klaus (der soundsoviele) P.S. Dann kann ich auch gleich meine zweite Grundregel zur Fehlersuche nachliefern: Nie jemandem glauben, am Wenigsten sich selbst.
Klaus S. schrieb: > nenne ich den behaupteten Fehler eine Vermutung. XDIR bleibt am Alternativpin Null. Das wurde offensichtlich gemessen und nicht nur behauptet oder gar vermutet. Insofern ist bereits die Überschrift eindeutig. > wenn sie sich mit einer solchen Beschreibung, wie sie hier vorliegt ... an der DIR nun genau WAS fehlte? > Nie jemandem glauben, am Wenigsten sich selbst Tja Klaus seinen Sinnen sollte man bei allem gesunden Misstrauen schon noch trauen dürfen. Insofern hättest Du ja auf Deine Wortmeldung verzichten können wenn Du nicht mal Dir selber glaubst :)
:
Bearbeitet durch User
Es sollte wirklich kein Problem darstellen, ein minimales Codebeispiel zusammenzustellen, das: - die benötigte Peripherie initialisiert - nacheinander folgende Schritte durchführt -- Variante A initialisiert -- einen simplen Text über die serielle Schnittstelle ausgibt -- eine gewisse Zeit auf etwaige zu empfangende Zeichen wartet -- Variante B initialisiert -- einen simplen Text über die serielle Schnittstelle ausgibt -- eine gewisse Zeit auf etwaige zu empfangende Zeichen wartet - und dann mit dem 2. Schritt von oben weitermacht Dieses minimalistische Beispiel könnte der geneigte Helfende bei Microchip oder sonstwo auf einem Controller flashen und laufen lassen; mit einem Oszilloskop müsste er nur vier Signale beobachten, nämlich jeweils die Tx- und die Dir-Leitung in beiden Konfigurationen. Zu beobachten sein sollte Aktivität auf beiden Tx-Leitungen und zeitgleich Aktivität auf den jeweiligen Dir-Leitungen, und das jeweils im Wechsel.
Harald K. schrieb: > Es sollte wirklich kein Problem darstellen, ein minimales Codebeispiel > zusammenzustellen Der TO wollte sich sicher nur umhören ob das Problem bekannt ist, eine schnelle praktische Lösung finden und hier kein großes Faß aufmachen. Du kannst das Phänomen ja mal untersuchen wenn es "wirklich kein Problem" darstellt. Mir fehlt leider das Interesse an den ganzen Zusatz-Mätzchen die dem seriellen Port beim AVR aufgepfropft wurden, für die dafür abgestellten Transistoren hätte man sicher sinnvollere Aufgaben finden können statt Peripherie immer komplizierter konfigurierbar zu machen. Umso interessanter aber wäre wie Microchip mit solchen Fehlermeldungen umgeht. Meine eigenen Erfahrungen reichen da von 'Ignorieren' über 'jahrelang verschleppen', 'beschönigen' bis 'definitiv falsche Rückmeldungen'. Was soll man von Microchip-Seite auch anders machen wenn die Ressourcen offensichtlich nicht in akzeptabler Zeit zur gründlichen Fehlerkorrektur von Hardware und Dokumentation reichen.
:
Bearbeitet durch User
Gerhard H. schrieb: > Du kannst das Phänomen ja mal untersuchen wenn es "wirklich > kein Problem" ist. Mir ging es darum, das ganze so aufzubereiten, daß man das dem dafür zuständigen Support von Microchip präsentieren könnte. Ich selbst nutze diesen µC überhaupt nicht (täte ich's, hätte ich interessehalber versucht, das Phänomen nachzustellen, davon kannst Du ausgehen), aber ich habe wegen komplett anderer Probleme schon Kontakt mit dem Microchip-Support gehabt und jeweils eine hilfreiche Reaktion erhalten. > Mir fehlt leider das Interesse an den ganzen Zusatz-Mätzchen die > dem seriellen Port beim AVR aufgepfropft wurden Ich fände eine zeitgemäße UART wichtig, und die altbekannte AVR-Uart ist vieles, aber nicht zeitgemäß. > Meine eigenen Erfahrungen reichen da von 'Ignorieren' über > 'jahrelang verschleppen' bis 'definitiv falsche Rückmeldungen'. Ich denke, daß das auch mit der Qualität der Anfragen zu tun hat. Je mehr Prosa, durch die sich irgendwer durchkämpfen muss, je weniger knappen und eindeutigen Code, mit dem das Problem in unter 5 Minuten auf dem Schreibtisch reproduzierbar ist, desto geringer werden die Erfolgschancen sein.
Harald K. schrieb: > Je > mehr Prosa, durch die sich irgendwer durchkämpfen muss, je weniger > knappen und eindeutigen Code, mit dem das Problem in unter 5 Minuten auf > dem Schreibtisch reproduzierbar ist, desto geringer werden die > Erfolgschancen sein. Ein Problem lässt sich durchaus auch ohne Code benennen. Und wenn Erfolgschancen ohne Fehlermeldung in Perfektion nicht gegeben wären könnte man sich wohl gleich einen Großteil der Meldungen sparen. Sind doch alles (nur/flexible) Menschen: Der Meldende mit seiner möglicherweise unperfekten Meldung und der Microchip-Profi, der unter anderem deshalb Profi ist, weil er auch unperfekte Meldungen sicher einzuordnen und zu beantworten weiß. > Ich fände eine zeitgemäße UART wichtig, und die altbekannte AVR-Uart ist > vieles, aber nicht zeitgemäß. Und ich fände wichtig sich aufs Wesentliche zu konzentrieren, das aber bitteschön möglichst fehlerfrei. Die Ansprüche sind halt verschieden... 'Zeitgemäß' ist ein äußerst strapazierbarer Begriff. Es soll Leute geben die serielle UART-Kommunikation als solche nicht mehr für zeitgemäß halten und dann jene, die weiter Wert auf möglichst einfache Methoden und Abläufe legen :)
:
Bearbeitet durch User
> ATtiny1626 XDIR bleibt immer 0
ATtiny824 auch.
1 | |
2 | USART0 RS-485 Mode Test |
3 | ATtiny824 |
4 | |
5 | VDD 1|‾‾‾‾‾‾‾|14 GND |
6 | (USART0 XDIR) ---- PA4 2| |13 PA3 |
7 | PA5 3| |12 PA2 |
8 | PA6 4| |11 PA1 ---- (USART0 TxD) |
9 | PA7 5| |10 UPDI |
10 | PB3 6| | 9 PB0 ----- USART0 XDIR |
11 | USART0 TxD ----- PB2 7|_______| 8 PB1 |
12 |
1 | PORTB.DIRSET = PIN2_bm; // USART0 TxD output (test result: OK) |
2 | PORTB.DIRSET = PIN0_bm; // USART0 XDIR output (test result: OK) |
1 | PORTMUX.USARTROUTEA = PORTMUX_USART0_ALT1_gc; // Alternative pin location |
2 | PORTA.DIRSET = PIN1_bm; // USART0 TxD alt. output (test result: OK) |
3 | PORTA.DIRSET = PIN4_bm; // USART0 XDIR alt. output (test result: no signal) |
Hallo, ich bin der festen Meinung das muss funktionieren. Der megaTinyCore kann das. https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/cores/megatinycore/UART.cpp "RS485 mode in combination with RX_ONLY will simply set the pin to an output, but never use it, because the TX module isn't enabled." Vorsschlag. Nehmt erstmal den Core, wenn das funktioniert könnt ihr immer noch bare metal programmieren.
Gerhard H. schrieb: > Und ich fände wichtig sich aufs Wesentliche zu konzentrieren, das aber > bitteschön möglichst fehlerfrei. Ach, Moby.
Georg M. schrieb: > ATtiny824 auch. Namens-Vettern halten zusammen :) Prima. Was gibts Besseres als einen Vergleichstest durch jemand anders. Am besten stets und aufs Minimum reduziert Veit D. schrieb: > bare metal !!! > "RS485 mode in combination with RX_ONLY will simply set the pin to an > output, but never use it, because the TX module isn't enabled." Was hat das mit dem Unterschied zwischen Default- und Alternativpin zu tun?
:
Bearbeitet durch User
Gerhard H. schrieb: > Veit D. schrieb: >> bare metal > > !!! > >> "RS485 mode in combination with RX_ONLY will simply set the pin to an >> output, but never use it, because the TX module isn't enabled." > > Was hat das mit dem Unterschied zwischen Default- und Alternativpin zu > tun? Hallo, ich habe zum 2.Mal den Hinweis gegeben wo man nachlesen kann wie es andere machen. Der andere zitierte Hinweis könnte ein Denkanstoß sein. Wenn man sich aber nur darauf konzentriert und nur meckern möchte, tja dann wird das eben nichts. Gebratene Enten fliegen noch nicht rum. Ich investiere keine weitere Zeit in diesen Thread.
Veit D. schrieb: > ich habe zum 2.Mal den Hinweis gegeben wo man nachlesen kann wie es > andere machen Ja, aber nach (nicht nur) meinem Eindruck trifft dieser Hinweis in diesem Fall nicht zu, da der TO zumindet in dem mir zugänglichen Text nirgendwo den RXONLY-Mode setzt. Und UART.CPP durchzuackern... dazu bin ich zu faul. Den von Dir zitierten Text hat eine Textsuche jedenfalls nicht darin gefunden. Der TO hat bisher nur ein paar Prozedurnamen und eine einzige von ihm verwendete Prozedur veröffentlich. Das reicht für gläubige Menschen wie Gerhard H., aber nicht für mich und vermutlich auch nicht für den Support von Microchip, um Abhängigkeiten zu anderen Programmteilen zu checken. Und solange der TO mit seiner Umgehungsstrategie zufrieden ist, können wir nur in Theorien und Sottisen schwelgen und drauf warten, daß irgendwer mal so ein Teil auftreibt und den Test (wie von Harald ja sehr richtig beschrieben) einfach macht. Gruß Klaus (der soundsovielte)
Hallo, ach Leute, ach Klaus. Ihr schenkt dem einen Satz viel zu viel Bedeutung, der war eher unwichtig, und nun versteifst du dich auch noch darauf. Viel viel wichtiger war der Link. Wer nicht gewillt ist das durchzugehen, der hat eine Lösung auch nicht verdient. So sehe ich das hier mittlerweile. Es wird immer nur nach Ausreden gesucht. Der TO ist schon lange weg, der hat auch keine Lösung verdient. Außerdem, was ist so schwer daran zum Test die Arduino IDE zu nehmen, den Core zu installieren, den RS485 Mode zu testen und wenn das klappt in bare metal nachzuprogrammieren? Hatte ich alles zur Lösungssuche vorgeschlagen. Manchmal frage ich mich schon ..., aber wenn ihr/du nicht wollt, mein Problem ist das nicht.
Veit D. schrieb: > ach Leute, ach Klaus. Ihr schenkt dem einen Satz viel zu viel Bedeutung, > der war eher unwichtig, und nun versteifst du dich auch noch darauf. Ja, mein Fehler. Wird so schnell nicht wieder vorkommen, versprochen! > Der TO ist > schon lange weg, der hat auch keine Lösung verdient. Der hat seine Lösung doch gefunden. Er macht das, was seit 40 Jahren Stand der Technik ist und ignoriert den neumodischen Tüdelkram. Gruß Klaus (der soundsovielte)
Veit D. schrieb: > Außerdem, was ist so schwer daran zum Test die Arduino IDE zu nehmen, > den Core zu installieren, den RS485 Mode zu testen und wenn das klappt > in bare metal nachzuprogrammieren? Du meinst, daß der Microchip-Support nur auf eine Anleitung dafür wartet?
Klaus S. schrieb: > Das reicht für gläubige Menschen Nun ja, Glauben ist zwar nicht Wissen aber nachdem das von zweiter Seite bestätigt wurde und Du keinen begründeten Anhaltspunkt dagegen anführen kannst... Veit D. schrieb: > Wer nicht gewillt ist das durchzugehen, der hat eine Lösung auch nicht > verdient. Man muß nicht unbedingt zum Schluß kommen daß sich das lohnen könnte.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.