Software Serial für mega644

[Juno (Gast)]

Ich nutze bisher das Beispiel von 
https://rn-wissen.de/wiki/index.php/Software-UART_mit_avr-gcc um Daten 
zu senden und zu empfangen. Beim Wechsel auf einen 644 stoße ich an 
meine Grenzen.
Senden klappt.
Beim Empfang ist RX an Pin PB0. Das ist jetzt aber nicht mehr der ICP 
(InputCapture-Eingang). Kann ich PCINT8 dazu nutzen? Und wenn: wie?

Danke

[Gerald O. (garry)]

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

[John Doe (Gast)]

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.

[Stefan F. (Gast)]

John Doe schrieb:
> No, hat nur einen.

[S. Landolt (Gast)]

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

[Juno (Gast)]

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.

[Stefan F. (Gast)]

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

[John Doe (Gast)]

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!

[S. Landolt (Gast)]

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

[Juno (Gast)]

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.

[S. Landolt (Gast)]

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.

[Stefan F. (Gast)]

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?

[Stefan F. (Gast)]

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.

[John Doe (Gast)]

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. (ukw) (Moderator)]

Stefan ⛄ F. schrieb:
> 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.

Die "moderneren" AVRs, welche PCINT-Interrupts zur Verfügung stellen, 
machen das dann auch in der Regel an fast jedem Pin. Schau Dir im 
Datenblatt vom ATMega644 das Pinout an: Du findest fast an allen Pins 
die Bezeichnung "PCINTxx", nämlich an allen GPIO-Pins.

[Stefan F. (Gast)]

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

Stimmt, was für ein Luxus!

[Frank M. (ukw) (Moderator)]

Juno schrieb:
> Die Frage ist, wie ich beispielsweise den o. g. Code passend für PCINT8
> anpassen kann.

Lies Dir einfach das Kapitel 11 im Datenblatt zum 644er durch, dort ist 
das erklärt.

Da gibt es für die PCINTs folgende Register:

PCICR – Pin Change Interrupt Control Register
PCIFR – Pin Change Interrupt Flag Register
PCMSK3 – Pin Change Mask Register 3
PCMSK2 – Pin Change Mask Register 2
PCMSK1 – Pin Change Mask Register 1
PCMSK0 – Pin Change Mask Register 0

Neben PCICR und PCIFR brauchst Du für PCINT8 noch PCMSK1.

Zitat:

" Bit 7:0 – PCINT15:8: Pin Change Enable Mask 15..8

Each PCINT15:8-bit selects whether pin change interrupt is enabled on 
the corresponding I/O pin. If PCINT15:8 is set and the PCIE1 bit in 
PCICR is set, pin change interrupt is enabled on the corresponding I/O 
pin. If PCINT15:8 is cleared, pin change interrupt on the corresponding 
I/O
pin is disabled."

Analog zu PCMSK3 - PCMSK0 gibt es auch die entsprechenden 
Interrupt-Vektoren PCINT3 - PCINT0. Für Deinen Wunsch, es mit dem Pin 
auf PCINT8 umzusetzen, brauchst Du eine Interrupt-Routine für den Vektor 
PCINT1 - analog zu PCMSK1.

Eigentlich nicht schwierig, oder?

[Pandur S. (jetztnicht)]

Man kann ja einen schnellen Timerinterrupt laufen lassen und zB mit 
4fachem Oversampling die Bits reinziehen.

Ich meine aber, der Aufwand fuer einen Software Uart ist die Muehe nicht 
wert. Wenn ich 2 Uarts haben will, verwende ich den 644, eigentlich ist 
das der Kleinste, welchen ich verwende. Und wenn ich mehr Uarts haben 
will, nehme ich den 2560. Die anderen machen wenig Sinn. Das erarbeiten 
eines Software Uarts kann einen Tag dauern. Das kostet soviel wie 
wieviele der groesseren Mega ? Um welche Serie geht es ?

[S. Landolt (Gast)]

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

[Frank M. (ukw) (Moderator)]

Stefan ⛄ F. schrieb:
> Stimmt, was für ein Luxus!

Ja, ist halt nur etwas komplexer zu konfigurieren als mit den 
klassischen Interrupt-Pins INT0, INT1 usw. Aber die PCINTs sind auch 
keine Raketenwissenschaft.

[c-hater (Gast)]

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. (ukw) (Moderator)]

c-hater schrieb:
> Wenn also der eigentliche Plan war, den Timer frei zu bekommen: kannste
> vergessen.

Eben, ohne Timer geht es nicht. Ich weiß nicht, welche Baudraten der TO 
verwenden will. 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.

[c-hater (Gast)]

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

[A. S. (Gast)]

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.

[A. S. (Gast)]

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.