www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik atmega - Daten in SRAM speichern und wieder ausgeben


Autor: sharth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich empfange über die USART-Schnittstelle Daten und möchte diese als 
Übung im SRAM speichern und danach wieder ausgeben. Falls ein Byte über 
die USART-Schnittstelle ankommt, wird ein Interrupt ausgelöst. Danach 
wird folgender Code ausgeführt, der auch soweit funktioniert:
uart:

 in  temp, sreg          
 in   data, UDR    ;empfangenes Byte aus UDR lesen
 st  y+, data      ;Byte im SRAM speichern und Zeiger erhöhen
 cpi  data, 0xD    ;wird letztes Byte empfangen(0xD),erfolgt Ausgabe
 breq  sram_out  
 out  sreg, temp
 reti

Zum einlesen der Daten nutze ich einen Barcode Scanner der das Ende 
eines Datenstroms stets mit einem Carriage Return absclhießt, den ich 
auch abfrage (0xD). Danach erfolgt die Ausgabe durch Sprung zu 
"sram_out". Bis hierher läuft alles problemlos.

Nun möchte ich aber auch Daten einlesen können die nicht mit einem 
Carriage Return abgeschlossen werden, sondern ein beliebiges Zeichen am 
Ende haben. Hier war meine Idee das RXC0-Bit abzufragen.
uart:    

 in  temp, sreg          
 in   data,UDR             
 st  y+, data
 in  temp2, UCSR0A
 andi  temp2, 0b10000000          
 breq  sram_out
 out  sreg, temp
 reti

Der Sprung zu "sram_out" erfolgt wunschgemäß, aber bei der Ausgabe 
erscheint nur Datenmüll(0x0,0x40) in einer Endlosschleife. Ich habe auch 
schon mehrere Varianten ausprobiert, die alle nicht funktionieren. Hat 
jemand eine Idee, Tipp oder Anregung wo der Fehler liegen könnte. Bin 
ziemlich ratlos, da ich noch wenig Erfahrung mit der Materie habe.

Danke schon mal für Eure Hilfe und sorry für die lange Ausführung!

Gruß

sharth

Autor: mizch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du sicherst zwar sreg in temp, aber sonst nichts.  Nicht einmal temp. 
Du kannst also davon ausgehen, dass im restlichen Programm der Inhalt 
aller Register, die Du in diesem Interrupt verwendest, unzuverlässig ist 
und zu annähernd beliebigen Zeiten sich ändern kann.

Zur Ausgabe und wie die zustande kommt, kann Dir keiner was sagen, da 
der Code fehlt.  Etwas merkwürdig finde ich allerdings, dass Du direkt 
aus dem Empfangsinterrupt in die Senderoutine springst.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sharth schrieb:

> Nun möchte ich aber auch Daten einlesen können die nicht mit einem
> Carriage Return abgeschlossen werden, sondern ein beliebiges Zeichen am
> Ende haben. Hier war meine Idee das RXC0-Bit abzufragen.

Ich raffs nicht.
Was haben das RXC0 Flag im UCSR0A und die Tatsache, dass du das 
Ende-of-data Byte anders haben willst, miteinander zu tun?

Das RXC Bit zeigt an, dass ein Zeichen komplett empfangen wurde. Das 
weißt du aber sowieso, denn genau aus diesem Grunde befindet sich das 
Programm momentan in der ISR. Wäre das RXC0 nicht gesetzt gewesen, wärst 
du gar nicht an dieser Stelle im Programm.


PS: Du achtest hoffentlch peinlich genau darauf, dass dein sram_out das 
sreg aus temp wiederherstellt und danach einen reti macht. Insgesamt ist 
dieser branch dorthin eine Stolperfalle ersten Grades und keine so 
wahnsinnig gute Idee

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie gesagt, ich stehe noch am Anfang meiner Assembler-Karriere. Aber 
jetzt zum Thema:

Karl heinz Buchegger schrieb:

> Ich raffs nicht.
> Was haben das RXC0 Flag im UCSR0A und die Tatsache, dass du das
> Ende-of-data Byte anders haben willst, miteinander zu tun?

Ich möchte nicht das End-of-data-Byte anders haben, sondern ich möchte 
das mein Programm erkennt, wenn das Ende einer Datenübertragung erreicht 
ist, unabhängig davon, wie das letzte Byte aussieht.
Und weil das RXC0 Flag nicht mehr gesetzt wird, wenn keine weiteren 
Bytes ankommen, dachte ich, dieses benutzen zu können. Aber scheinbar 
ist das wohl nicht so sinnvoll? Kann mir jemand sagen warum?

> PS: Du achtest hoffentlch peinlich genau darauf, dass dein sram_out das
> sreg aus temp wiederherstellt und danach einen reti macht. Insgesamt ist
> dieser branch dorthin eine Stolperfalle ersten Grades und keine so
> wahnsinnig gute Idee

Ja, ich habe das sreg wieder hergestellt. Allerdings weiß ich nicht wie 
ich diese Stolperfalle mit dem sram_out Aufruf umgehen kann und warum es 
überhaupt eine Stolperfalle ist. Sollte die Ausgabe von der 
Hauptschleife aufgerufen werden?

mizch schrieb:
> Du sicherst zwar sreg in temp, aber sonst nichts.

Ob ich alle Register gesichert habe werde ich nochmal überprüfen.

Danke für eure Hilfe

sharth

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tschuldigung für den Doppelpost aber "Bearbeiten" hat nicht 
funktioniert.

mizch schrieb:
> Du sicherst zwar sreg in temp, aber sonst nichts.
> Du kannst also davon ausgehen, dass im restlichen Programm der Inhalt
> aller Register, die Du in diesem Interrupt verwendest, unzuverlässig ist
> und zu annähernd beliebigen Zeiten sich ändern kann.

Das ist ein Punkt den ich noch nicht verstanden habe. Wozu muss ich ein 
Register sichern, wenn ich es im folgenden sowieso überschreibe, bevor 
ich es wieder benutze. Ich hoffe es ist klar was gemeint ist.


Danke für eure Hilfe

sharth

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris p. Chicken schrieb:

>> Ich raffs nicht.
>> Was haben das RXC0 Flag im UCSR0A und die Tatsache, dass du das
>> Ende-of-data Byte anders haben willst, miteinander zu tun?
>
> Ich möchte nicht das End-of-data-Byte anders haben, sondern ich möchte
> das mein Programm erkennt, wenn das Ende einer Datenübertragung erreicht
> ist, unabhängig davon, wie das letzte Byte aussieht.

Wie soll das gehen?

Ich bin Sender, du bist Empfänger
Ich sende dir mal was

 01237885531241243       // ich mach mal eine kurze Pause, ist
                         // das jetzt schon das Ende?

                         // Nein, natürlich nicht, da kommt noch was

 87963451764787687347    // was jetzt, jetzt schon zu Ende?

                         // Nö

  36257453124548734

und so können wir das Spielchen immer weiter treiben. Solange wir nicht 
vereinbaren, wann die Übertragung zu Ende ist, kannst du nicht 
feststellen ob ich schon fertig bin oder nicht.
Und wenn du das nicht kannst, dann kann es dein µC auch nicht. Der ist 
ja kein Hellseher.

Und das RXC Flag hat absolut nichts damit zu tun. Das zeigt nur ein, 
dass 1 Zeichen komplett empfangen wurde. Nicht mehr.
Alles darüberhinausgehende musst du per Vereinbarung regeln!

> Ja, ich habe das sreg wieder hergestellt. Allerdings weiß ich nicht wie
> ich diese Stolperfalle mit dem sram_out Aufruf umgehen kann und warum es
> überhaupt eine Stolperfalle ist.

Die Stolperfalle besteht darin, dass du plötzlich eine Abhängigkeit 
hast. Verbrauchst du in der ISR ein Register mehr, dann darfst du nicht 
vergessen, in sram_out dieses Register wiederherzustellen. Was aber, 
wenn sram_out gar nicht von der ISR aufgerufen wird, sondern von ganz 
woanders?

> Sollte die Ausgabe von der
> Hauptschleife aufgerufen werden?

zumindest sollte es ein call sein, damit sram_out wieder dorthin 
zurückkehrt, von wo es hergekommen ist. Und der Aufrufer, in diesem 
Falle die ISR räumt ihren Dreck selber weg und restauriert wieder alles 
was sie angetascht hat.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris p. Chicken schrieb:

> mizch schrieb:
>> Du sicherst zwar sreg in temp, aber sonst nichts.
>> Du kannst also davon ausgehen, dass im restlichen Programm der Inhalt
>> aller Register, die Du in diesem Interrupt verwendest, unzuverlässig ist
>> und zu annähernd beliebigen Zeiten sich ändern kann.
>
> Das ist ein Punkt den ich noch nicht verstanden habe. Wozu muss ich ein
> Register sichern, wenn ich es im folgenden sowieso überschreibe, bevor
> ich es wieder benutze. Ich hoffe es ist klar was gemeint ist.

Der Schlüsselbegriff ist "im restlichen Programm", sprich: außerhalb des 
Interrupts.  Da ein Interrupt an jeder Stelle unterbrechen kann, ist 
danach jedes Register "kaputt", das der Interrupt verändert.

Zu RXC: das ist gesetzt, sobald ein neues Zeichen verfügbar ist und zwar 
nur solange, bis es von der CPU abgeholt wird.  Auch bei 
ununterbrochener Sendung auf der asynchronen Leitung dauert aber das 
Eintrudeln eines Zeichens aus CPU-Sicht annähernd Ewigkeiten.  In denen 
ist das RXC vom letzten Zeichen längst gelöscht (du holst ja im 
Interrupt ab, also praktisch sofort) und das nächste Zeichen noch lange 
nicht komplett.

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl heinz,

Karl heinz Buchegger schrieb:
> Wie soll das gehen?
>
> Ich bin Sender, du bist Empfänger
> Ich sende dir mal was
>
>  01237885531241243       // ich mach mal eine kurze Pause, ist
>                          // das jetzt schon das Ende?
>
>                          // Nein, natürlich nicht, da kommt noch was
>
>  87963451764787687347    // was jetzt, jetzt schon zu Ende?
>
>                          // Nö
>
>   36257453124548734
>
> und so können wir das Spielchen immer weiter treiben. Solange wir nicht
> vereinbaren, wann die Übertragung zu Ende ist, kannst du nicht
> feststellen ob ich schon fertig bin oder nicht.


Im Grunde verstehe ich was du meinst.
Aber richtig ist doch auch, das ich mittels RXC-Bit testen kann ob im 
UDR daten vorhanden sind. Wenn ich mittels JTAG debugge, kann ich 
erkennen, dass das RXC-Bit solange gesetzt bleibt, bis ich das letzte 
empfangene Byte aus dem UDR gelesen habe. Danach wird RXC 0.
Jetzt weiß ich natürlich nicht ob der Sender mir noch mehr Daten senden 
möchte. Das heißt aber auch, das der Sender mir ein eindeutiges Zeichen 
geben muss, wann ein Datenstrom abgeschlossen ist.
Da ich aber erreichen wollte, das bei einer Übertragungs-Pause die 
Ausgabe erfolgt habe ich das RXC-Bit verwendet.
In meinem Beispiel wusste ich ja, dass immer nur 8 Bytes reinkommen und 
darauf eine Pause eintritt.


Mal ein anderer Ansatz

ich weiß nicht wieviele Bytes reinkommen, und auch nicht wie das letzte 
Byte aussieht. Lässt sich das dann besser zeitlich regeln.
Z.B. wenn nach einer Wartezeit von 50ms kein weiteres Byte anliegt nehme 
ich an, dass die aktuelle Übertragung abgeschlossen ist?

Ich hoffe es ist einigermaßen klar worauf ich hinaus will!

Viele Grüße,

sharth

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hc Zimmerer schrieb:
> Der Schlüsselbegriff ist "im restlichen Programm", sprich: außerhalb des
> Interrupts.  Da ein Interrupt an jeder Stelle unterbrechen kann, ist
> danach jedes Register "kaputt", das der Interrupt verändert.
>
> Zu RXC: das ist gesetzt, sobald ein neues Zeichen verfügbar ist und zwar
> nur solange, bis es von der CPU abgeholt wird.  Auch bei
> ununterbrochener Sendung auf der asynchronen Leitung dauert aber das
> Eintrudeln eines Zeichens aus CPU-Sicht annähernd Ewigkeiten.  In denen
> ist das RXC vom letzten Zeichen längst gelöscht (du holst ja im
> Interrupt ab, also praktisch sofort) und das nächste Zeichen noch lange
> nicht komplett.

Okay, das ist jetzt klar geworden. Ich werde versuchen mein Programm 
entsprechend zu ändern.

Danke für eure schnelle Hilfe

sharth

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris p. Chicken schrieb:

> Im Grunde verstehe ich was du meinst.
> Aber richtig ist doch auch, das ich mittels RXC-Bit testen kann ob im
> UDR daten vorhanden sind. Wenn ich mittels JTAG debugge, kann ich
> erkennen, dass das RXC-Bit solange gesetzt bleibt, bis ich das letzte
> empfangene Byte aus dem UDR gelesen habe.

Ja.
Aus Sicht deines Programms passiert dieses RXC ist gesetzt nur alle 
heiligen Zeiten!
Ich schick dir am Vormittag was, dann 3 Stunden später, dann 2.5 Stunden 
später. Die ganze Nacht über nichts, mogen am Vormittag 3 Zeichen usw.

> Jetzt weiß ich natürlich nicht ob der Sender mir noch mehr Daten senden
> möchte. Das heißt aber auch, das der Sender mir ein eindeutiges Zeichen
> geben muss, wann ein Datenstrom abgeschlossen ist.

Ganz genau

> Da ich aber erreichen wollte, das bei einer Übertragungs-Pause die
> Ausgabe erfolgt habe ich das RXC-Bit verwendet.

Das hilft dir aber nicht viel
Du bist im Interrupt, eben weil jetzt gerade ein Zeichen vollständig da 
ist. Selbst wenn die Übertragung ununterbrochen läuft, könntest du an 
dieser Stelle nicht feststellen, ob noch was kommt oder nicht. Du siehst 
ganz einfach viel zu früh nach!

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Z.B. wenn nach einer Wartezeit von 50ms kein weiteres Byte anliegt nehme
>ich an, dass die aktuelle Übertragung abgeschlossen ist?
"nehme ich an" ist mist. weißt Du aber, das der Sender, wenn 50ms nichts 
kam auch eine große Pause macht, dann ist es gut.

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

leider habe ich mein Problem noch immer nicht so richtig lösen können.
Programmablauf:

Ich möchte eine undefinierte Anzahl an Bytes von einem Sender empfangen 
und im SRAM speichern. Wenn der Sender eine gewisse Zeitspanne nichts 
gesendet hat
möchte ich die Daten über die USART Schnittstelle wieder ausgeben.
Bei der Ausgabe erhalte ich jedoch nur Datenmüll in einer 
Endlosschleife.
Folgendermaßen sieht mein Code bisher aus:


.include "m162def.inc" 

.def temp = r16        
.def data = r18

.equ TAKT     = 7370000                           
.equ BAUD     = 9600                              
.equ UBRR_VAL   = ((TAKT+BAUD*8)/(BAUD*16)-1)      
.equ BAUD_REAL  = (TAKT/(16*(UBRR_VAL+1)))           
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000)    

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))          
  .error
.endif

.CSEG                  
.org 0x00       rjmp init
.org OVF0addr  rjmp timer0_overflow  
.org URXC0addr  rjmp uart          


init:  //-->STACK
  ldi     temp, LOW(RAMEND)
  out     SPL, temp
  ldi     temp, HIGH(RAMEND)
  out     SPH, temp


  //->USART
  ldi     temp, HIGH(UBRR_VAL)
  out     UBRR0H, temp
  ldi     temp, LOW(UBRR_VAL)
  out     UBRR0L, temp

  ldi     zh,high(poll*2);
  ldi     zl,low(poll*2);                

  ldi     temp, (1<<URSEL0)|(3<<UCSZ00) ;9Bit-Übertragung
  out     UCSR0C,temp    

  ldi     temp, (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0) |(1<<UCSZ02) 
  out     UCSR0B,temp

  //SRAM
  ldi     YH,HIGH(sdata)
  ldi     YL,LOW(sdata)  
        
  //Timer
  ldi     temp, (1<<TOIE0)           
  out     TIMSK, temp
    
  sei              
  clr     temp
    
main:
    
  rjmp    main

timer0_overflow:

   push   temp            
   in     temp, sreg
   push   temp

   rcall  sram_out          
   pop    temp
   out    sreg, temp        
   pop    temp        

uart:

    push  temp
    in    temp, sreg        
    push  temp
    ldi   temp, (1<<CS02)               
    out   TCCR0, temp        ;Timer starten

    in    data, UDR                                 
    st    y+, data  
    pop   temp
    out   sreg, temp
    pop   temp
    reti

sram_out:

    ldi    YL,LOW(sdata)                    
    ldi    YH,HIGH(sdata)
 
serout:    
    sbis   UCSR0A,UDRE0     ;warten UDR bereit ist  
    rjmp   serout
    ld     data, y+           
    out    UDR, data           
    cpi    data, 0xD
    brne   serout
    
    ldi    YL,LOW(sdata)                  
    ldi    YH,HIGH(sdata)
    ret


;ab hier include-Dateien
.include "uart_funktionen.asm"

.DSEG
sdata: .BYTE 10




Nun ist wieder das Problem, dass in der Interrupt Routine ein "call" 
ausgeführt wird. Ich weiß das, das vermieden werden sollte. Aber bin 
noch blutiger Anfänger und weiß nicht, wie ich das sonst umsetzen soll. 
Für einige Tipps wäre ich sehr dankbar.

Viele Grüße,

sharth

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris p. Chicken schrieb:

> Nun ist wieder das Problem, dass in der Interrupt Routine ein "call"
> ausgeführt wird. Ich weiß das, das vermieden werden sollte.

Das ist hier gar nicht sooo schlimm.
Schalte aber wenigstens den Timer ab. Der tickt während der ganzen ISR 
weiter und wenn die ISR zu lange braucht, kommt schon der nächste 
Overflow und die ganze Ausgabe beginnt wieder von vorne.

    ldi   temp, (1<<CS02)
    out   TCCR0, temp        ;Timer starten

Hier musst du den Timer im TCNT0 wieder auf 0 zurücksetzen. Du willst ja 
haben, dass eine längere Pause, NACHDEM ein paar Zeichen eingetrudelt 
sind, die Ausgabe triggert. Bei jedem Zeichen, welches reinkommt, muss 
daher die 'Stoppuhr' erneut bei 0 anfangen zu laufen.


    cpi    data, 0xD
    brne   serout

Das würde ich nicht machen.
Du hast keine Garantie, dass ein 0x0D im Speicher abgelegt wurde. Alles 
was du weißt ist, wo die abgelegten Daten enden (durch den Wert im 
Y-Pointer bei betreten der Routine). An diesen Wert würde ich mich 
halten.

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist hier gar nicht sooo schlimm.

Das heißt aber wohl auch, das es keine besonders elegante Lösung ist.
Gibt es eine gute Alternative, die auf mein Problem anwendbar ist?

> Schalte aber wenigstens den Timer ab.

Okay,habe den Timer jetzt während des Timer_Interrupt gestoppt.


> Hier musst du den Timer im TCNT0 wieder auf 0 zurücksetzen.

Danke und nochmals danke! Genau da lag der Fehler. Hatte nämlich gerade 
getestet ab welcher Byte-Anzahl der Fehler auftritt. Immer ab ca. 10 
übertragenen Bytes kam eine Endlosschleife an Bytes.

> Du hast keine Garantie, dass ein 0x0D im Speicher abgelegt wurde. Alles
> was du weißt ist, wo die abgelegten Daten enden (durch den Wert im
> Y-Pointer bei betreten der Routine). An diesen Wert würde ich mich
> halten.

Das hab ich noch nicht ganz verstanden. Bei betrteten der "sram_out" 
Routine die Adresse auf die der y-Zeiger gerichtet ist auslesen? Da 
sollte ja dann der letzte eingelesene Wert drinstehen. So Richtig?


Danke für deine schnelle Hilfe
Gruß,
sharth

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
timer0_overflow:

   push   temp
   in     temp, sreg
   push   temp

   rcall  sram_out
   pop    temp
   out    sreg, temp
   pop    temp

Da fehlt doch ein reti am Ende?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris p. Chicken schrieb:
>> Das ist hier gar nicht sooo schlimm.
>
> Das heißt aber wohl auch, das es keine besonders elegante Lösung ist.
> Gibt es eine gute Alternative, die auf mein Problem anwendbar ist?

Die allgemeine Empfehlung lautet:
In einer ISR nur das absolut notwendige tun, und dann so schnell wie 
möglich wieder aus der ISR raus.

Nur: Wei bei jeder Regel, ist das eine Faustregel. Im Einzelfall kann 
man die auch schon mal links liegen lassen.

Die elegantere, allerdings aufwändigere Lösung, sieht so aus: Das 
Auslesen in die Hauptschleife verfrachten und in der ISR nur ein Flag 
setzen, andem die Hautpschleife den 'Arbeitsauftrag' erkennt.
Bei dir, in diesem konkreten Beispiel, ist das aber ein nicht 
unbeträchtlicher Aufwand. Du musst dich dann plötzlich um Race 
Conditions kümmern, etc (Das musst du sowieso irgendwann tun, denn was 
soll passieren wenn während der Ausgabe der Sender wieder zu senden 
anfängt)

Aber hier ging es um ein anderes Problem, drum wollte ich nicht zuviele 
Änderungen auf einmal anregen.

>> Du hast keine Garantie, dass ein 0x0D im Speicher abgelegt wurde. Alles
>> was du weißt ist, wo die abgelegten Daten enden (durch den Wert im
>> Y-Pointer bei betreten der Routine). An diesen Wert würde ich mich
>> halten.
>
> Das hab ich noch nicht ganz verstanden. Bei betrteten der "sram_out"
> Routine die Adresse auf die der y-Zeiger gerichtet ist auslesen?

Nö.
Den Y-Zeiger selber merken  ->  Endwert

Und dann in der Schleife nur solange ausgeben, bis Y wieder den vorher 
gemerkten Endwert erreicht hat.
Damit gibst du dann nur das aus, was auch vorher in den SRAM 
hineingeschrieben wurde.

Je mehr Annahmen du darüber triffst, was in den Daten überhaupt drinnen 
steht, desto mehr bindest du die Funktion an diesen einen speziellen 
Fall. Im Idealfall ist es egal, was du empfangen hast. Du gibst nur das 
aus was du auch empfangen hast. Damit können es aber nicht die 
empfangenen Datenbytes, bzw deren Werte, sein, die die Ausgabe steuern.

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Da fehlt doch ein reti am Ende?

Das ist beim kopieren abhanden gekommen. Hatte ein bisschen mit der 
Formatierung hier zu kämpfen. Habe vorher alle Kommentare rausgenommen, 
weil sonst die Zeilen zu lang waren. Dabei ist das "reti" wohl auch 
verloren gegangen.
Würde es gerne oben noch ändern, aber das ist scheinbar nicht mehr 
möglich.

Trotzdem, danke!

sharth

Autor: Chris p. Chicken (sharth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Du musst dich dann plötzlich um Race
> Conditions kümmern, etc (Das musst du sowieso irgendwann tun, denn was
> soll passieren wenn während der Ausgabe der Sender wieder zu senden
> anfängt)

Das hatte ich mich auch schon gefragt. Wenn es soweit ist, melde ich 
mich bestimmt wieder;-) Oder weißt du eine gute Quelle, oder 'nen 
anderen Thread, wo man sich soetwas nachlesen kann?

Karl heinz Buchegger schrieb:
> Nö.
> Den Y-Zeiger selber merken  ->  Endwert

Ja, das ist wohl etwas sinnvoller, weil allgemeiner. Aber ich war
nah dran:-)

Gruß,

sharth

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris p. Chicken schrieb:
> Karl heinz Buchegger schrieb:
>> Du musst dich dann plötzlich um Race
>> Conditions kümmern, etc (Das musst du sowieso irgendwann tun, denn was
>> soll passieren wenn während der Ausgabe der Sender wieder zu senden
>> anfängt)
>
> Das hatte ich mich auch schon gefragt. Wenn es soweit ist, melde ich
> mich bestimmt wieder;-) Oder weißt du eine gute Quelle, oder 'nen
> anderen Thread, wo man sich soetwas nachlesen kann?

Was würdest du im realen Leben machen?

Folgende Situation:
Dein Kumpel schreibt dir Dinge auf einen Zettel auf.
Wenn eine gewisse kritische Masse beisammen ist (oder er 10 Sekunden 
nichts aufschreibt), nimmst du den Zettel, gehst nach hinten ins Lager 
und holst die Teile die er aufgeschrieben hat.

In der Zeit, in der du im Lager bist, kann dein Kumpel klarerweise 
nichts auf den Zettel, den du ja mit hast, aufschreiben.

Ihm fallen aber noch mehr Dinge ein, die er braucht. Und ermuss die 
niederschreiben.


Wie würdest du dieses Problem im realen Leben lösen?
Wenn du dafür eine Lösung hast, dann kannst du diese Lösung, der Idee 
nach, so ziemlich 1:1 auch in deinen Programmcode übernehmen :-)

Erstaunlich viele Programmierprobleme haben Entsprechungen in unserem 
realen Leben, wo wir diese Probleme mit links lösen. Und diese 
Lösungsideen wiederrum sind oft gut in Programme übernehmbar

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.