mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232 - > Buffer -> EEPROM


Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Cracks!

Habe eine Frage:

Ich möchte Daten (1000Byte)vom PC über den uC (ATmega8) in ein externes
EEPROM (AT25256) schreiben.

Das EEPROM unterstützt den 16 - Byte Page Write Modus.

Jetzt dachte ich mir:

- Der PC sendet kontinuirlich Daten per RS-232 an den uC
- Die uC empfangsroutine ist Interrupt gesteuert.
- Ein Array (Buffer) wird mit 64 Byte gefüllt
- sobald das Array voll ist, sollen die Daten vom Array ins EEPROM
geschaufelt werden!)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- der PC sendet aber munter weiter!


Gibt es da Datenverlust?


Ich möchte die RS-232 Schnittstelle mit 9600 Baud laufen lassen:
T1 = 1/9600 =  104us (länge des 2. Stopbits)

Die SPI Schnittstelle ist mit 2 MHz getaktet:
64Byte brauchen also: 1/2MHz * 64Byte = 32us! (uC abarbeitungszeit
vernachlässigt.)

Danach braucht das EEPROM 10ms Schreibezeit... während dieser Zeit wird
das Array erneut gefüllt:

Array Füllzeit: 1/9600 * 11Bit (start, daten, 2 stop) * 64Byte =
73.3ms!

nach meinen berechnungen sollte das funktionieren?
oder sieht ihr das anders?

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe dieses Problem gelöst, indem ich zwei Buffer benutzt habe.
Buffer1 wurde vom PC gefüllt, bis er voll war. Anschließend den Inhalt
in Buffer2, wo er dann fürs EEPROM weiterverarbeitet wurde. Der Buffer1
konnte währenddessen wieder beschrieben werden.
Allerdings hatte ich noch so nebenbei eine zweite Software-Uart am
Laufen...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Rechnung sieht richtig aus.

Ich würde Dir dafür einen Ringpuffer für den UART-Empfang empfehlen.
256 Byte geht besonders gut (nur das Low-Byte weiterzählen).

Dann kannst Du in aller Ruhe die letzen 64Byte in den EEPROM schreiben
und hast reichliche 192 Byte Reserve.


Peter

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter

Vielen Dank für die Antwort....

Ich sehe jedoch den Vorteil eines 256 Byte grossen Puffer nicht:

Denn die RS-232 Schnittstellenübertragung ist sehr viel langsamer! Wenn
1 Byte übertragen ist, sind schon sagen wir 10 SPI Byte ans EEPROM
übertragen worden... also gibt es gar nie ein überschneiden des
Puffers... so wie ich das sehe...

Fall X:
Meine frage ist jetzt nur was passiert, wenn während der SPI
übertragung ein RS-232 Empfangsinterrupt auftritt??? Dieses Problem
hätte ich ja genau auch, wenn ich mit dem 256Byte Puffer arbeite! Oder
nicht?


@thkais: Danke für den Hinweis... Aber der Fall X (siehe oben) kann
auch dann vorkommen.... oder verstehe ich da etwas nicht ganz richtig?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein einfacher 16-Byte-Buffer sollte genügen.
16 byte =160bit, bei 9600 macht das 16 ms. Die SPI-Transferzeit dürfte
kaum eine nennswerte Rolle spielen. Also, nach dem 16. byte
rauschaufeln, man hat dafür fast 2ms Zeit.

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber der uC kann doch nicht parallel den SPI Transfer und die Serielle
schnittstelle einlesen???

oder wie meinst du das mit den 2ms Zeit zum rausschaufeln?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum dennn nicht? Die haben doch miteinander nichts zu tun. Und wenn
die Schnittstellen im Interrupt laufen, kann dein Prozessor geschätzte
>99% der Zeit schlafen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich sehe jedoch den Vorteil eines 256 Byte grossen Puffer nicht:"


Der Mega8 hat ja einen riesigen RAM, die 256 Byte machen das Programm
nur einfacher.

Wenn Du den RAM aber anderweitig brauchst, dann kannst Du natürlich
weniger nehmen.
Minimal brauchst Du soviel, wie Du Bytes wärend der 10ms Schreibzeit
empfangen kannst, also etwa 10 Byte.


Peter

Autor: edi-edi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

warum den grossen plumpen leistungsstarken PC trotten lassen
und dem kleinen spielzeug fast den hals abdrehen?

'handshaking' koennte dem kleinen mehr puste uebrig lassen...
fuer andere kleinigkeiten.

edi

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo siehst du denn eine Belastung für den MC?
UART-Empfang mit 9600 ist Leerlauf...ISR aufrufen, diverse Sachen
sichen, Byte abholen, irgendwo zwischenspeicher, Zeiger/Zähler
aktualisieren, restore, Rücksprung - grosszügig geschätzt 100 Takte.
Bei 8MHz hat man ca. 8000 Takte zwischen zwei Bytes, die in die UART
reintröpfeln.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@edi,

Handshaking braucht man nur fürs Senden zum PC.

Empfangen können die MCs immer "full speed" (115200 Baud), da sie
sich nicht mit irgendwelche OS-Ballast rumplagen müssen.

Bei lahmen 9600 langweilen die sich schon mächtig.


Die 1000 Byte Daten könnte man aber auch voll im M8 puffern.
Wenns die Leitungslänge erlaubt, kann Fabian also auch 115200 Baud ohne
Handshake fahren.



Peter

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so! Geil, ich dachte immer der Interrupt wird aufgerufen, wenn eine
übertragung gestartet wird! -> Vielen Dank :-)


ich werde die Uart Geschw. demnach anpassen, damit sie genügend schnell
ist und ich zwischen zwei Bytes die 64Byte übertragung ins EEPROM
hinkriege...

Nochmals vielen Dank an alle!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"ich zwischen zwei Bytes die 64Byte übertragung ins EEPROM
hinkriege..."


Nein !

Die Interrupts laufen doch quasi parallel zum Hauptprogramm. D.h es
spielt keine Rolle, wie oft der Interrupt die Übertragung zum EEPROM
unterbricht.


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.