SPI Verdrahtung zw. 2 ATMega8

Oder man zwingt den Master per Jumper während des flashens in Reset
Nein!
/Reset ist beim ISP quasi /CS.

Was es gibt, ist 'ne Application Note, nach der das Clock-Signal während des Flashens nur immer auf einen Teilnehmer im SPI-Bus geschaltet werden soll (also alle anderen via Jumper/Mäuseklavier getrennt. Idee dahinter wäre, daß alle Controller über ein und dieselbe ISP-Buchse geflasht werden können).
 
Genau das meinte ich ja. (AN) ;)
 
Hallo LotadaC, hallo TommyB

Vielen Dank für Eure Hilfe :)

Ich habe - wie von LotadaC vorgeschlagen - in die MISO/MOSI/SCK/SS Verbindungen jeweils einen 1kOhm Serienwiderstand reingebaut, SS mit 10kOhm an Vcc gehängt (gemäß TommyB) - und es funktioniert jetzt.
Ich kann den Master und den Slave (jeden einzeln natürlich) flashen OHNE die Verbindung MOSI/MISO/SCK/SS trennen zu müssen. Sehr schön!
So wie es aussieht, war der Hinweis von LotadaC (in die Leitungen einen Serienwiderstand von 470Ohm ... 1kOhm reinzuhängen) die Lösung.

Ich versteh' zwar nicht, warum dieser Serienwiderstand die Lösung ist, aber wenn's funktioniert ;) (Strom fließt ja auch durch krumme Drähte ;)).

Mich würde außerdem interessieren, warum es zu den Fehlermeldungen:
- "WARNING Flash byte adress 0x18D8 is 0x6C (should be 0xFF)" beim Slave beim Flashen kam (mit ISP).
- "Address 0x0001, expected 0xc034, received 0xc135" beim Master beim Flashen kam (mit mySmartUSB MK2).

mfg

Hero_123
 
Deine beiden Mega8 flashst Du üblicherweise über eine SPI-Verbindung. Der Programmiermodus wird dabei durch das Low-Halten der /Reset-Leitung ... eingeleitet (anschließend muß der Programmer (üblicherweise auch ein Mikrocontroller - könte aber auch BitBanging über eine PC-Schnittstelle sein) dann über die SPI eine bestimmte Sequenz senden und ein Programmierprotokoll abarbeiten).
Wenn der Controller also im Reset gehalten wird, wird er zum (adressierten) SPI-Slave (SCK und MOSI werden Eingang, wann MISO zum Ausgang wird, weiß ich nicht), und reagiert auf die Programmiersequenz am Bus. Programmerseitig sind MOSI und SCK Ausgänge, MISO ist Eingang.
Befindet sich jetzt ein (weiterer) Slave am Bus, wird der mangels Reset zwar nicht in irgendeinen Programmiermodus gezwungen, ist er aber aus irgendeinem Grund selektiert (fliegende CS-Leitung), wird sein MISO zum Ausgang, er quatscht dem zu flashenden Controller dazwischen. Beide Teilnehmer legen dann unter Umständen Kurzschlüsse auf die Leitung (was auf Dauer nicht gut für die Ausgangstreiber ist) - abgesehen davon empfängt der Master (also der Programmer dann irgendwelchen Mist.
Ein nicht selektierter SPI-Slave sollte sich aber am Bus passiv verhalten (deswegen der /CS-Pullup).
Thomas Display hatte wahrscheinlich gar keine MISO-Leitung, das Programmieren des Controllers war also kein Problem; aber das Display hat sich wegen der fliegenden /CS während des flashens adressiert gefühlt, und die Programmiersequenz irgendwie interpretieren können.
Einen anderen Master kannst Du nur über die SPI-Hardware nicht mal so eben in den Passivmodus zwingen. Natürlich gäbe es Software-Lösungsansätze, auf die der Master (die Master-Firmware) dann auf Passiv schalten könnte (/CS des Masters könnte Eingang mit Pullup sein - ein kurzer Low-Pegel würde den Master zum Slave machen, wenn CS danach High ist, ist der jetzige Slave nicht selektiert. Es ist natürlich Sache Deines Programmes, wann der Controller sich wieder zum Master zurücksetzen darf. - Oder der Master erkennt auf einem Anderen Bein den /Reset des anderen Controllers, und deaktiviert solange sein SPI, zieht die Füße vom Bus...)

Was machen jetzt die Serienwiderstände?
Ohne hast Du auf einigen Leitungen potentielle Kurzschlüsse, die (zumindest) die Kommunikation von Programmer und Target stören. Sperrst Du jetzt den Störer hinter den Serienwiderstand, fällt die Spannungsdifferenz am Widerstand ab - das targetseitige Signal bleibt sauber.

Und was bedeuten die Serienwiderstände für den "normalen Kommunikationsbetrieb"? Sie bilden zusammen mit der Leitungs- und Pin-Kapazität einen Tiefpaß. Das heißt, daß die maximal mögliche Kommunikationsgeschwindigkeit sinkt.
Die Kapazitäten sollten allerdings recht gering sein, und den Widerstand wählst Du so klein wie möglich.Aber auch so groß wie nötig. Mehr als 10mA "Kurz"Schlußstrom sollten nicht fließen. Bei 3,3V würden's auch 330 Ohm machen, bei 5V eben 470 Ohm. 1K sind sogar noch sicherer; den Bandbreitenverlust wirst Du beim AVR wahrscheinlich nicht bemerken.

Dino hätte das vielleicht blumiger formulieren können - ich hoffe zumindest halbwegs korrekt und verständlich geblieben zu sein.

LotadaC
 
Hallo LotadaC

Vielen Dank für Deine tolle und sehr ausführliche Erklärung!
Die Sache mit den Widerständen und den potentiellen Kurzschlüssen war mir völlig unklar und die Erklärung bezgl. Programmierung / Verhalten der Prozessoren beim Programmieren hat mir sehr geholfen, zumindest prinzipiell zu verstehen, was beim Flashen geschieht.

mfg

Hero_123
 
Seit Micromel ist die Dokumentensuche und die Performance der Webseite zwar irgendwie ... abartig (meine Subjektive Meinung), aber hier mal für Dich gesucht:
AVR042
 
Hallo LotadaC

Vielen Dank für den link :)!

Ich komme erst jetzt dazu, mich zu bedanken, da ich im Urlaub war.

Die Info in der Atmel Doku und Dein Beitrag #44 waren sehr hilfreich, jetzt habe ich wesentlich mehr Einblick/Verständnis von dem, was man mit ISP/SPI machen kann bzw was da beim Flashen und im "normalen" Betrieb zwischen den beiden ATMega8 passiert - ich könnte also auch - wenn ich die SCK-line mit einem Gate/DIP öffnen/schließen könnte, auch mit einer einzigen ISP Schnittstelle auskommen.

mfg

Hero_123
 
erst jetzt dazu, mich zu bedanken, da ich im Urlaub war
:good:
ich könnte also auch - wenn ich die SCK-line mit einem Gate/DIP öffnen/schließen könnte, auch mit einer einzigen
So stehts in der AppNote - meinem Verständnis nach sind dann doch aber trotzdem alle AVR über /Reset "aktive Slaves"; einer bekäme zwar keine Clock (würde also nicht mitschieben, nichts senden/empfangen), aber er legt doch trotzdem seinen MISO als Ausgang auf den Bus (weil er ja eigentlich nur noch auf Clock-Flanken wartet) - oder etwa nicht?
Oder aktivieren die Target (Slave)-AVR ihren MISO erst, nachdem die Programmiersequenz eingeleitet wurde? (Also Programmer erzwingt Reset, Programmer sendet 0x53 (AFAIR "Entering Programming Mode", erst hier geht der MISO auf Ausgang?)

Nachtrag: Im Datenblatt des Mega88 zB:
28.8.2 Serial programming algorithm

When writing serial data to the ATmega48/88/168, data is clocked on the rising edge of SCK. When reading data from the ATmega48/88/168, data is clocked on the falling edge of SCK. See Figure 28-9 on page 316 for timing details. To program and verify the ATmega48/88/168 in the serial programming mode, the following sequence is recommended (See Serial Programming Instruction set in Table 28-17 on page 314):

1. Power-up sequence: Apply power between VCC and GND while RESET and SCK are set to “0”. In some systems, the programmer can not ensure that SCK is held low during power-up. In this case, RESET must be given a positive pulse of at least two CPU clock cycles Duration after SCK has been set to “0”.
2. Wait for at least 20ms and enable serial programming by sending the Programming Enable serial instruction to pin MOSI.
3. The serial programming instructions will not work if the communication is out of synchronization. When in sync. the second byte (0x53), will echo back when issuing the third byte of the Programming Enable instruction. Whether the echo is correct or not, all four bytes of the instruction must be transmitted. If the 0x53 did not echo back, give RESET a positive pulse and issue a new Programming Enable command.
Die "Programming Enable Serial Instruction" wäre übrigens 0x AC 53 00 00... also hat mein Gedächtnis mich nicht vollständig getäuscht...

Aber (1) scheint entscheidend zu sein, also daß SCK während des PowerUp/Reset low sein muß. Wenn Du also mehrere AVR über einen SPI-Bus programmieren können willst (insbesondere über denselben ISP-Anschluß), und SCK über ein Mäuseklavier etc abtrennst, sollten die nicht verbundenen SCKs via externen Pullups auf high gehalten werden. Idealerweise mit einem Mäuseklavier als Umschalter (pro "Taste") - als mit mehreren (4) Beinen pro Taste. Die sind allerdings teurer, da unkonventionell...
 
Zuletzt bearbeitet:
Hallo LotadaC

Vielen Dank für Deine Hinweise (#48) :)

Ich hatte mir schon gedacht, dass es nicht ganz so einfach sein würde - macht aber im Moment nichts, da ich eine funktionierende Lösung (dank Dir & TommyB) habe.

Später mal (wenn ich etwas mehr Wissen über ATMegas bzw die kompletten Application Notes des ATMega8 durchgearbeitet und verstanden habe), werde ich probieren, ob ich es schaffe, mit einem ISP Programmer zwei oder mehr ATMegas zu flashen ;).

mfg

Hero_123
 
Mich nerft's immer, wenn ich da irgendwas nicht verstehe - vielleicht einfach mal ausprobieren...
  • AVR ohne Firmware
  • MISO mit je einer LED gegen Vcc und Gnd versehen (nebst passenden Rs natürlich - passend heißt, daß die nicht bereits nur durch die Reihenschaltung leuchten...)
  • (Reset sollte durch den internen Pullup high sein -> Default)
    • SCK High halten, Reset auf Gnd -> LEDs? (sollten beide aus sein)
    • SCK low halten, Reset auf Gnd -> LEDs?
 
Hallo LotadaC

Vielen Dank für den Tipp mit dem Testen -
Mich nerft's immer, wenn ich da irgendwas nicht verstehe
- das geht mir genauso ;).

Ich werde das mal ausprobieren - wird aber etwas dauern, denn ich muss mir erst die dafür nötigen Materialien besorgen (AVR, Widerstände, LEDs, Bastelplatine, Schalter etc - ich bin kein toller Bastler); sobald ich etwas herausgefunden habe, werde ich dies hier kundtun ;).

AVR ohne Firmware
da meinst Du doch einen AVR ohne Boot Loader (also einen "von der Stange"), oder?

mfg

Hero_123
 
AVR ohne Boot Loader (also einen "von der Stange"), oder?
eigentlich egal, es sollte nur keine Firmware drauf sein, die SCK oder MISO manipuliert (wollen wir ja tristate haben). Am besten also einen gelöschten AVR. Außerdem müssen die Fuses "normal" sein (also SPIEN muß aktiv sein, RSTDSBL darf nicht aktiv sein, es muß eine Taktquelle geben (zB interner Oszillator)).
Üblicherweise ist das der Default "von der Stange".

Die "Programming Enable Serial Instruction" wäre übrigens 0x AC 53 00 00
When in sync. the second byte (0x53), will echo back when issuing the third byte of the Programming Enable instruction.
SPI sind ja quasi zwei Schieberegister, die ihren Inhalt simultan je zum anderen rüberschieben (getaktet durch den Master über die SCK).
Der Master (=Programmer) soll also erstmal ein 0xAC (10101100) senden als zweites 0x53. Währenddessen scheint der AVR (Target) "nichts" zurückzusenden (zumindest nicht 0x00 0xAC). Erst, wenn der Master das dritte (dummy ? ) Byte 0x00 rüberschiebt, sendet das Target die erhaltene 0x53 zurück.
nun gibt's aber kein digitales "nichts" - das Target könnte entweder 0x00 oder 0xFF oder irgendwas "senden" - oder es ist bis dahin tatsächlich tristate (und der Master=Programmer empfängt irgendwas (Antenne) zurück und ignoriert das.

Wenn also bei beiden Teil-Experimenten aus #50 die Lichter ausbleiben, könnte man in einem weiteren Experiment das Programmieren durch einen zweiten AVR schrittweise simulieren.
Also Master und Slave sind 1:1 verbunden SCK und MOSI, der Master steuert außerdem Reset des Slaves an. MISO des Slaves wie in #50 an den beiden LEDs.

Außerdem am Master irgendwo ein Taster.

Die Masterfirmware legt erstmal SCK high und Reset low, und wartet auf den Taster wird der betätigt (einfache Software-Entprellung):
SCK low und warten...
Reset high und warten...
Reset low und warten...
Master macht SPI scharf und sendet 0xAC (und wartet...)
sendet 0x53 und wartet... (LEDs?)
sendet 0x00 (jetzt müßten die LEDs "blinken" (01010011), sehen könnte man das aber nur bei seehr geringer SPI-Frequenz), und wartet …
Master sendet das letzte 0x00, und setzt Reset wieder high (LEDs sollten aus sein/gehen)
(Master in Endlosschleife "stoppen")
 
Hallo LotadaC

Die in Deinen Beiträgen (#50 & #52) werde ich ausprobieren, sobald ich das dafür nötige Material (und Zeit ;)) habe - kann also etwas dauern ...
Wenn ich vorweisbare & aussagekräftige Ergebnisse habe, werde ich sie hier posten

mfg

Hero_123
 
Hallo

Ich habe ein Problem bei der Kommunikation der beiden ATMega8 per SPI:
Der Master sendet 3 Bytes alle 1 Sekunde (gepollt, im Hauptprogramm), der Slave empfängt diese 3 Bytes per Interrupt (Programme siehe Anlage).
Die Daten werden per USART & hterm am PC gecheckt und aufgezeichnet (siehe Anlage atmega8_06.txt)
Master sendet: Byte[0] konstant 13, Byte[1] != Byte[2], beide zählen bis 200, werden dann wieder zurück gesetzt (ok).
Slave empfängt: Byte[0] = Byte[1] = Byte[1] vom Master (Slave Empfangsbyte[0]sollte doch gleich Sendebyte[0] vom Master sein?)
Slave Empfangsbyte[2] = Master Sendebyte[2] (ok)
Slave Empfangsbyte[1] = Master Sendebyte[1] (ok)
Slave Empfangsbyte[0] = Slave Empfangsbyte[1] => falsch, warum?
Slave Empfangsbyte[0] sollte doch = Master Sendebyte[0] sein, oder?

Habe ich da einen Denkfehler?

mfg

Hero_123
 

Anhänge

  • slave_spi_int_04.c
    5,1 KB · Aufrufe: 3
  • atmega8_06.txt
    1,3 KB · Aufrufe: 2
  • master_spi_04.c
    4,1 KB · Aufrufe: 1
Kannst Du das den Transfer mit einem LogicAnalyzer mitloggen (und damit den Master ausschließen)?
Das muß sich natürlich ein C-Mensch ansehen - grundsätzlich sieht allerdings das hier ... komisch aus:


CodeBox C
/* SPI interrupt service routine  */
ISR(SPI_STC_vect) {
    volatile unsigned char data;
    while(i< ARRAY_LEN) {
        SPDR = 0;
        data=SPDR;
        rec_byte[i++]=data;
    /*    i++; */
        if(i >= ARRAY_LEN) empfang = 1;
        /*    __asm volatile("nop"); */
    }
}

Wie wirkt "rec_byte[i++]=data;"? Wird erst inkrementiert, oder erst zugewiesen?

Im Hauptprogramm initialisierst Du i mit 0, in der ISR begrenzt Du es dann auf 1 und 2.
Damit ist dann allerdings auch immer die While-Bedingung wahr.

Irgendwo "später" meine ich, noch ein weiteres "i" gesehen zu haben (diesmal nicht-global definiert) ??

Wozu der Zwischenschritt mit "data"?



CodeBox C
/* ISR fuer den Timer0 - zaehlen der Interrupts Timer 1ms...*/
ISR(TIMER0_OVF_vect) {
    TCNT0 = 198;                                /* vorladen auf 198 = 255-57 */
    zaehler1_t0++;                                /* Aufruf alle 1ms*/
    if(zaehler1_t0 > 254)zaehler1_t0 = 0;        /* reset zaehler1_t0 */
    TIFR |= (1 << TOV0);                        /* nicht zwingend noetig...*/
}
Das Zurücksetzen des Überlauf-Flags erfolgt automatisch beim Eintritt der Interruptbehandlung (salopp gesagt beim Eintritt in die ISR, genauer gesagt bereits beim Erreichen der IVT.
Die ISR schlägt (etwa) jede ms zu - statt Preload könntest Du eventuell einen CTC verwenden.
Warum darf der zaehler1_t0 nur von 0..254 laufen? Sonst könntest Du einfach ein Byte durchlaufen lassen.

Aber eigentlich hab ich von C keine Ahnung...

Nachtrag: Timer0 des Mega8 scheint nur den Normal Mode zu unterstützen -> kein CTC.
 
Zuletzt bearbeitet:
Ohne mehr als das Zitat von @LotadaC gelesen zu haben:

Die ISR wird für jedes empfangene Byte genau einmal aufgerufen.

Die while-Schleife liest das selbe Byte aus SPDR, solange i < ARRAY_LEN ist.

CodeBox C
        SPDR = 0
        data = SPDR;
        rec_byte[i++] = data;
macht das selbe, wie:

CodeBox C
        SPDR;              // SPDR lesen (= I-Flag löschen) und verwerfen
        rec_byte[i++] = 0;
Wie wirkt "rec_byte[i++]=data;"? Wird erst inkrementiert, oder erst zugewiesen?
Zuerst wird zugewiesen. Wer aber nicht ganz sicher ist, alle Seiteneffekte in C zu durchschauen, sollte besser schreiben:

CodeBox C
        rec_byte[i] = data;
        i++;
 
Hallo LodataC, hallo Mikro23

Vielen Dank für Eure Hilfe!

Leider habe ich keinen LogikAnalyzer :(.

Die while-Schleife in der ISR(SPI_STC_vect) wird solange durchlaufen, bis "i" die ARRAY_LEN erreicht hat, dann wird diese Schleife nicht mehr durchlaufen.

Es wird - wie Mirko23 schreibt - zuerst zugewiesen, dann inkrementiert (ich habe es aber zum besseren Verstehen wieder geändert, sodass die Inkrementierung besser ersichtlich wird).
@Mirko -


CodeBox C
/* SPI interrupt service routine  */
ISR(SPI_STC_vect) {
    volatile uint8_t data;
    while(i_spi< ARRAY_LEN) {
        SPDR = 0; /*Daten, die vom slave an den master transferiert werden */
        data=SPDR;
        rec_byte[i_spi]=data;
        i_spi++;
        if(i_spi >= ARRAY_LEN)empfang = 1;
        /*    __asm volatile("nop"); */
    }
}



Ich kann SPDR = 0 setzen und dann die Daten von SPDR dem data zuweisen - würde es nicht fkt, hätte ich keinen Datenempfang, und den habe ich ja, allerdings ist Byte[0] des Slave = Byte[1] des Slave und nicht Byte[0] des Master; sonst sind übertragenen Daten des Master = empfangene Daten des Slave - ich habe die Übertragung auf 5 Bytes geändert - alles bis auf Byte[0] des Slave ist ok....

mfg

Hero_123
 
Zuletzt bearbeitet:
Im Hauptprogramm initialisierst Du i mit 0, in der ISR begrenzt Du es dann auf 1 und 2.
Damit ist dann allerdings auch immer die While-Bedingung wahr.
Quark, "Empfang" wird auf "1" gesetzt, nicht "i"...

Die while-Schleife in der ISR(SPI_STC_vect) wird solange durchlaufen, bis "i" die ARRAY_LEN erreicht hat, dann wird diese Schleife nicht mehr durchlaufen.
Es wird also tatsächlich nach jedem empfangenen Byte mehrfach aus dem SPDR gelesen - dreimal, und je in rec_byte[0]..[2] geschrieben.

macht das selbe, wie:
sicher?
Das beschreiben von SPDR löst laut Datenblatt einen Transfer aus.
Writing to the register initiates data Transmission.
Das sollte allerdings nur bei gesetztem MSTR-Bit in SPCR gelten (Master-Mode). Genauer gesagt müßte bei einem Schreibzugriff also das Schieberegister beschrieben werden, bei gesetztem MSTR wird anschließend der Transfer gestartet. Während eines laufenden Transfers werden Schreibzugriffe grundsätzlich ignoriert.
Bei einem Lese-Zugriff wird hingegen aus dem Receive-Buffer gelesen
Reading the Register causes the Shift Register Receive buffer to be read.
Und der ist sogar doppelt gepuffert.
The system is single buffered in the transmit direction and double buffered in the receive direction.

SPDR; // SPDR lesen (= I-Flag löschen) und verwerfen
Was meinst Du mit I-Flag löschen?
Das "I" wird beim Eintritt in die ISR (genauer schon beim erreichen der IVT) gelöscht, und bei Return from Interrupt wieder gesetzt.
Das "SPIF" wird beim Eintritt in die ISR (genauer beim erreichen der IVT) automatisch zurückgesetzt.
Ohne IRQ kann das "SPIF" außerdem zurückgesetzt werden, indem bei gesetztem SPIF erst das SPSR gelesen wird, und danach auf SPDR "zugegriffen" wird (Lesezugriff? Schreibzugriff?)
Alternatively, the SPIF bit is cleared by first reading the SPI Status Register with SPIF set, then accessing the SPI Data Register (SPDR).
 
Nein, ich hab nicht ins Datenblatt geschaut. ;)
Das beschreiben von SPDR löst laut Datenblatt einen Transfer aus.
Wie kommt man dann auf die Idee, innerhalb der noch nicht beendeten Interruptroutine gleich mehrfach einen neuen Transfer auszulösen? (Der dann wiederum mehrfach einen Interrupt auslöst.)
Das "I" wird beim Eintritt in die ISR (genauer schon beim erreichen der IVT) gelöscht
Ich meinte das SPIF. Nicht bei jedem Peripheriegerät und nicht bei jedem Controller gleich, wird das jeweilige Interruptflag beim Eintritt in die ISR gelöscht. Bei manchen muß man das immer von Hand tun.
 
Wie kommt man dann auf die Idee, innerhalb der noch nicht beendeten Interruptroutine
Wie gesagt, der Transfer sollte dabei meiner Meinung nach(!) nur im Master-Mode triggern - im Slave-Mode dürfte dadurch nur der Wert in's Schieberegister geladen werden. Macht insofern (auch in einer ISR) Sinn, als das man eben nach einer empfangenen Instruktion 'ne Antwort vorbereiten kann. Mit dem Master muß dann allerdings trotzdem 'ne hinreichend lange Pause vereinbart werden.
Heros Code ist Slave-Code.

Innerhalb der ISR sind IRQs grundsätzlich über das I in SREG unterdrückt (kann man natürlich auch innerhalb der ISR freigeben, dann könnte ein IRQ sich selbst unterbrechen; bei geringem Flash haste da schnell 'n Stacküberlauf…).
Nicht bei jedem Peripheriegerät und nicht bei jedem Controller gleich, wird das jeweilige Interruptflag beim Eintritt in die ISR gelöscht.
Korrekt, wobei mir auf die Schnelle nur I²C/USI dazu einfällt, und die externen Level-IRQs natürlich, wo das nicht so ist. (Strenggenommen wird die ISR erst durch einen von der IVT ausgehenden Sprung erreicht. "I" und das IRQ-Flag werden bereits vor diesem Sprung manipuliert. Schlägt der IRQ während der Behandlung (bevor "I" wieder gesetzt wurde) bleibt das gesetzte IRQ-Flag stehen und wird nach dem setzen von "I" abgearbeitet (jaja, gilt zB bei den externen Level INTs nicht...)

SPIF wird hier jedenfalls durch "die Abarbeitung der ISR" automatisch zurückgesetzt, händisch müßte man erst SPSR mit gesetztem SPIF lesen (was man beim Polling ja eigentlich eh tut), und danach SPDR lesen... wobei...
SPSR hat beim Mega I/O-Adresse 0x0F, ist also direct bit accessible. Somit könnte man eigentlich SPIF pollen ohne SPSR richtig (im Sinne von "IN") zu lesen...

Grundsätzlich treffen meine Aussagen hier nur für die "konventionellen" 8-Bit-AVR zu, bei X-Core-Tinies und erst recht XMegas sieht das wahrscheinlich auch anders aus. Irgendwo wird nicht mal das "I" automatisch gelöscht, muß man sich selbst drum kümmern...

Aber zurück zum eigentlichen Problem: Die Empfangs-ISR paßt nicht. Statt bei jedem empfangenen Zeichen dreimal SPDR zu lesen und das "Telegramm-fertig-Flag" zu setzen darf jedesmal nur einmal SPDR gelesen, und wenn alle drei durch sind das Fertig-Flag gesetzt werden. IF statt WHILE...
(worauf @Mikro23 ja bereits in #56 hingewiesen hat...)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)