Software Serial für mega644

Gerald O. schrieb:
> Wenn die Capturefunktion für den Softuart genutzt wird muss natürlich
> auch ein CaptureEingang verwendet werden. Was ist den das Ziel? Einfach
> nur zum lernen? Oder wird ein 3.Uart benötigt? Der 644 hat ja zwei
> Hardware-Uarts...

No, hat nur einen.

John Doe schrieb:
> No, hat nur einen.

Es ist vom ATmega644 die Rede, ohne P und ohne A.

Ist doch egal Leute. Ich will einfach einen seriellen Software-UART an 
einem (bel.) Pin realisieren. Wie ist mir egal. Die Frage ist, wie ich 
beispielsweise den o. g. Code passend für PCINT8 anpassen kann.

An einem beliebigen Pin wird nicht gehen, weil du für den Empfang 
Interrupts brauchst. Nur-Senden würde gehen.

Stefan ⛄ F. schrieb:
> John Doe schrieb:
>> No, hat nur einen.

Der gute Stefan wieder: Einfach sinnlos drauflosposten, ohne vorher 
gelesen zu haben. Alles wie gehabt.
Schön, dass es Dir gut geht!

Juno schrieb:
> Ich will einfach ... passend für PCINT8 anpassen
Wie sieht denn Ihr Versuch mit PCINT8 aus, und was geht schief?

Stefan ⛄ F. schrieb:
> An einem beliebigen Pin wird nicht gehen, weil du für den Empfang
> Interrupts brauchst.

PCINT8 ist doch ein Interrupt oder?

Ich weiß halt nicht, wie man die auswertet und dann den Timer 1 passend 
konfiguriert bzw. steuert.

PS:
Wie offenbar richtig erkannt wurde, wird es ohne Input-Capture ziemlich 
ungenau, daraus folgt eine gewisse Einschränkung, was die Baudrate, in 
Bezug auf den Systemtakt (sowie eventuell vorhandene andere, sperrende 
Interrupts), betrifft.

> Ich weiß halt nicht, wie man die auswertet
Direkt zu Beginn der PCINT-ISR TCNT statt ICR lesen - aber siehe oben.

John Doe schrieb:
> Der gute Stefan wieder: Einfach sinnlos drauflosposten, ohne vorher
> gelesen zu haben. Alles wie gehabt.

HTML Fragender schrieb im Beitrag #6622828:
> Kennt man doch, laberrhababer

Erstens habe ich hier lediglich ein Datenblatt zitiert, das auflistet, 
welche Varianten zwei UART haben. Ich habe ganz bewusst darauf geachtet, 
dass die Titelzeile gut sichtbar ist.

Zweitens wisst ihr genau so wenig wie ich, welche Variante des ATmega644 
der TO vorliegen hat.

Drittens hat der TO längst geantwortet, dass es ihm nicht um die UART 
Schnittstellen geht. Was soll also dieses unnötige Nachtreten?

Juno schrieb:
> PCINT8 ist doch ein Interrupt oder?

Ja schon, aber du hast doch zwischenzeitlich deine Anforderung so 
ergänzt:

Juno schrieb:
> Ich will einfach einen seriellen Software-UART an
> einem (bel.) Pin realisieren.

Stefan ⛄ F. schrieb:
> John Doe schrieb:
>> Der gute Stefan wieder: Einfach sinnlos drauflosposten, ohne vorher
>> gelesen zu haben. Alles wie gehabt.
>
> HTML Fragender schrieb im Beitrag #6622828:
>> Kennt man doch, laberrhababer
>
> Erstens habe ich hier lediglich ein Datenblatt zitiert, das auflistet,
> welche Varianten zwei UART haben. Ich habe ganz bewusst darauf geachtet,
> dass die Titelzeile gut sichtbar ist.

Bleib bitte bei der Wahrheit: Du hast mein - korrektes - Posting zitiert 
und dann Bilder von einem anderen Controller hinzugefügt. Insofern ist 
Deine damit bezweckte Aussage schon eindeutig.

> Zweitens wisst ihr genau so wenig wie ich, welche Variante des ATmega644
> der TO vorliegen hat.

Es gibt nur einen ATmega644. Punkt. Von etwas anderem hat der TO nicht 
geschrieben. Ich poste jetzt auch nicht Bilder vom Datenblatt eines 
STM32H7, nur weil der Poster ja einen Fehler gemacht haben könnte und 
den gemeint haben könnte.
Das Forum wäre sinnlos, wenn jetzt jeder anzweifelt, dass ein TO nicht 
dazu in der Lage ist, eine vernünftige Frage zu stellen und daher 
irgendwas da reininterpretiert.

> Drittens hat der TO längst geantwortet, dass es ihm nicht um die UART
> Schnittstellen geht. Was soll also dieses unnötige Nachtreten?

1. Es ist kein Nachtreten
2. Es ist nicht unnötig. Du unterstellst mir - siehe oben - dass ich was 
Falsches geschrieben hätte. Wollte ich nur klarstellen.

Frank M. schrieb:
> Du findest fast an allen Pins die Bezeichnung "PCINTxx"

Stimmt, was für ein Luxus!

> ohne Input-Capture ziemlich ungenau
Also wenn man weiß, wieviel Zeit vergeht vom Interrupt bis zum Lesen von 
TCNT, dann kann man das ja herausrechnen (ist wohl abhängig von der 
Compiler-Einstellung für Optimierung). Dann bleibt nur noch die 
(eventuelle) Unwägbarkeit anderer ISRs sowie von Programmteilen mit 
gesperrtem Interrupt.

Juno schrieb:

> Ist doch egal Leute. Ich will einfach einen seriellen Software-UART an
> einem (bel.) Pin realisieren.

Der Ansatz ist Mist. Software-UART für Empfang ist arg limitiert, wenn 
man nicht wenigstens andere Hardware-Features wie etwa ICP als Krücke 
verwendet.

> Wie ist mir egal. Die Frage ist, wie ich
> beispielsweise den o. g. Code passend für PCINT8 anpassen kann.

Am besten: Garnicht. Die UART wird nichtmal annähernd so gut 
funktionieren wie die Vorlage. Es sei denn, der für PCINT8 zuständige 
Interrupt wäre der einzige erlaubte Interrupt im System, dann 
funktioniert das recht fluffig. Den durchlaufenden Timer zur Zeitmessung 
brauchst du aber trotzdem.

Wenn also der eigentliche Plan war, den Timer frei zu bekommen: kannste 
vergessen.

Frank M. schrieb:

> Ich habe aber auf einem ATMega mit 16MHz schon mal acht
> Software-UARTs mit 9600 Bd realisiert - zugegebenermaßen nur für RX.
> Dabei wurde auf einen PCINT verzichtet und lediglich der 8-Bit-Port
> 28800 mal pro Sekunde über eine Timer-ISR gepollt - also mit der
> dreifachen Datenrate.

Schon das ist nicht sehr zuverlässig. Sobald ein oder sogar mehrere 
konkurrierende Interrupts im System sind, ist recht schnell Ende 
Gelände, selbst bei nur 9,6kbps...

Frank M. schrieb:
> - also mit der dreifachen Datenrate.

Whow, das ist vom Timing her ja optimal!

Wenn im Takt 1 von 3 das Start, dann Samplen bei 2 und restart im Stopp 
bei 3.

Damit bist Du ja auf 1/6 bitzeiten am Optimum! Respekt!! Ich glaube, da 
wäre ich nicht drauf gekommen.

Danke.

c-hater schrieb:
> Sobald ein oder sogar mehrere konkurrierende Interrupts im System sind,
> ist recht schnell Ende Gelände, selbst bei nur 9,6kbps...
Klar. Aber wenn das Dingen high prio hat, dann ist das eine Zeile C-Code 
mit höchster Priorität, immer an:

a[idx++]=Port;

Das geht sogar vielleicht per DMA.

Und die Auswertung hat dann bis zu 255 Samples Zeit.