- LiFePO4 Speicher Test         
Seite 2 von 7 ErsteErste 1234 ... LetzteLetzte
Ergebnis 11 bis 20 von 66

Thema: Programm_Anpassungen

  1. #11
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Anzeige

    Powerstation Test
    Hört sich gut an.
    Ich habe immer Probleme, wenn es um 'call bei reference' und 'call by value' geht (bekomme ich nur durch try and error raus). Bei dem einen ändert die aufgerufene Funktion, und der Aufrufer muss leiden, oder freut sich halt über den geänderten Wert. Hier würde ich als Aufrufer die Krise kriegen.
    Lieber Asuro programieren als arbeiten gehen.

  2. #12
    Erfahrener Benutzer Roboter Genie Avatar von m.a.r.v.i.n
    Registriert seit
    24.07.2005
    Ort
    Berlin
    Beiträge
    1.247
    Hi,
    #define SerPrint(data) SerWrite(unsigned char *data, 0);
    Oder muss das "data" bei einem define auch mit Typeangabe, *-chen oder sonstigem sein?
    Stimmt natürlich einmal unsigned char * ist genug.

    Was die Warteschleife am Ende der SerWrite Funktion betrifft: Mir war so, als ob es dann mit anschließendem Aufruf von SerRead Probleme gab, wenn man die Warteschleife weg ließ. Hier im Forum gab es auch mal einen Thread dazu, ich finde den bloß nicht mehr.

  3. #13
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    37
    Beiträge
    4.062
    doch, da kann ich mich auch drann erinnern.

    im atmega ist nur ein einziges register (USD) vorhanden, welches die daten hält die gesendet oder empfangen wurden.

    wenn man mit serwrite was senden will, muss man nur den wert in das register schieben, und es wird gesendet. da jedoch 2400 baud sehr langsam ist im vergleich zum systemtakt des asuro mit 8000000 hz, passiert es wenn man serread aufruft, dass man versucht, das register USD, in das man gerade geschrieben hat und dessen daten noch nicht abgeschickt wurden, wieder auszulesen. dadurch wird erstens ein frame error ausgelöst, was eine unterbrechung des sendens des aktuellen zeichens zur folge hat, und zweitens werden die daten im USD zerstört.

    die warteschleife ist also nur dazu da, um sicherzustellen, dass das USD wieder leer ist, bzw das der letzte sendevorgang sicher beendet ist.

    edit: das lässt sich übrigens viel eleganter lösen: es gibt im UART-STATUS-register (UST?? weiss nimmer) ein bit das anzeigtz ob das datenregister leer ist...
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  4. #14
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    @m.a.r.v.i.n & @damaltor
    hmmm, ist ja interessant, das ihr auch schon Thread's vermisst. Ich habe zu Anfang meiner Besuche im Forum so alle Beiträge per Bockmark im Browser festgehalten. Es gibt da mindestens einen, den es definitiv nicht mehr gibt. Der Titel war "Was macht Ihr eigentlich beruflich, was studiert Ihr ?" und war unter Beitragsnummer 12654 zu finden.

    Zur Warteschleife:
    damaltor führt an, dass man ja auch über ein Register prüfen kann, ob das zu sendende Byte schon weg ist.
    Aber genau das wird ja noch VOR der merkwürdigen doppelten for()-Loop gemacht. (Ist im Register UCSRA das Bit 6: TXC 'USART Transmit Complete')
    Code:
      while (!(UCSRA & 0x40))               // abwarten, bis das letzte Zeichen
        ;                                   // uebertragen wurde.        
    
      for (i = 0; i < 0xFE; i++)            // warten auf irgendwas; keiner weiss
        for (length = 0; length < 0xFE; length++);  // wofuer
    Das UDR-Register ist im AVR doppelt angelegt. Es hat nur auf der Sende- und Empfangsseite den gleichen Namen, sogar intern die gleiche Adresse. Das wird im ATmega8-Handbuch auf Seite 150 recht gut erklärt.
    Das zu sendende Byte kann somit nicht von einem empfangenen Byte übermangelt werden. Sonst könnte ein "Full Duplex Operation (Independent Serial Receive and Transmit Registers)" nicht funktionieren (Seite 130 im Handbuch auf der Asuro-CD)

    Tut mir Leid, aber im Moment stehe ich noch auf meiner Vermutung, mit den Synchronisationsproblemen.
    Lieber Asuro programieren als arbeiten gehen.

  5. #15
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    37
    Beiträge
    4.062
    das bit meinte ich eigentlich nicht... es gibt ein bit welches einfach nur anzeigt ob udr empty ist.

    ich habe nicht im datenbaltt nachgesehen, sondern nur in diesem Buch nachgesehen:
    http://www.amazon.de/Mikrocomputerte...5779381&sr=8-1
    ich war recht überzeugt davon dass sowas da drin stand, dass sich ein schreib- und ein innerhalb der sendezeit liegender lesevorgang gegenseitig behindern. egal, werde nochmal nachsehen, das full-duplex ist ein sehr gutes argument =) allerdings denke ich es wäre doch vernünftiger, wenn man das register, da es ohnehin doppelt vorhanden ist, auch einzeln ansprechen kann... so könnte man evtl noch einen wert zurücklesen und schnell korrigieren. (sofern TXE noch abgeschaltet ist)

    was machst du eigentlich un diese zeit schon im netz?? =)
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  6. #16
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Heute bin ich mal dran mit einem freundlichen
    hnngggrrr
    Der Dachdecker hatte sich für 07:30 angekündigt. Und was macht man im Urlaub, wenn man schon den ersten Kaffee auf hat?

    Also mal ein einmaliges: 'Guten Morgen' von mir.

    Jetzt bin ich aber gespannt, ob du in dem Buch noch genau Infos zu dem UDR und 'Beiwerk' findest. Wäre bestimmt erhellend, wenn man dann die blöde for()-Konstruktion mal richtig verstehen könnte. (Oder doch löschen?)
    Lieber Asuro programieren als arbeiten gehen.

  7. #17
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Und endlich wieder meine Zeit.

    @m.a.r.v.i.n & @damaltor
    Da habe ich doch den 'verlorenen Sohn' wiedergefunden.
    Arexx-Henk hat im Beitrag Asuros SerWrite(..) - Verständnisproblem berichtet, was da fehlschlägt, wenn man, wie m.a.r.v.i.n schon sagte, nach dem Senden gleich Empfangen möchte.

    Es bleibt also tatsächlich die Suche nach dem von damaltor vermissten Bit im AVR. Aber da hat Arexx-Henk in seinem Beitrag auch schon eine Lösung mitgeliefert.
    Lieber Asuro programieren als arbeiten gehen.

  8. #18
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    37
    Beiträge
    4.062
    so, gefunden:

    auf seite 154 im datenblatt wird beschrieben, dass im register UCSRA (Usart Control ans Status) das bit 5 (UDRE, Usart Data Register Empty) immer dann eine eins gibt, wenn das datenregister leer ist UND der empfänger bereit zum empfang neuer daten ist. könnte man damit nicht etwas machen?
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  9. #19
    Benutzer Stammmitglied
    Registriert seit
    09.07.2007
    Beiträge
    42
    Hallo zusammen!

    Arexx-Henk meinte in " Asuros SerWrite(..) - Verständnisproblem":
    ....
    Vorbild:

    - die Asuro sendet einige Daten mittels den

    SerWrite() Funktion

    - die Asuro schaltet direkt um nach empfangen mittels den

    SerRead() Funktion

    ohne diesen Warteschleiffe in die SerWrite() Funktion werden
    die letzten drei Karakter vom transmitter nicht mehr
    ausgestrahlt.

    Warum nicht?

    Guck mal in die SerRead() Funktion.

    Dort steht u.a.

    UCSRB = 0x10; //enable receiver

    Mit diesen Kode wird die receiver eingeschaltet ABER
    damit wird auch die transmitter direkt AUSgeschaltet.
    ....
    Leider hat Henk _nicht_überall_ Recht! (Mit den 3 letzten Sätzen schon!) )

    Da könnte man (_etwas_besser_!) ) schreiben: "UCSRB |= 0x10; //enable receiver"
    ... und zum Ausschalten: "UCSRB &= ~0x10; //disable receiver"

    Prog.-Teil aus "SerWrite()":
    Code:
    ....
      }
      while (!(UCSRA & 0x40))   // abwarten, bis das _letzte_Zeichen_
        ;                                   // uebertragen wurde.
                                            // Wait for transmit complete flag (TXC)
    // Bis hierher wurde ALLES uebertragen!     *************************************
    //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
      for (i = 0; i < 0xFE; i++)            // warten auf irgendwas; keiner weiss
        for (length = 0; length < 0xFE; length++);  // wofuer 
    }
    .....
    Was soll da bitte noch übertragen werden, wenn's schon fertig ist??

    Und
    " if (UCSRA & 0x20) // wait for empty transmit buffer "
    ===>> "0x20" ist "bit 5"!

    cu Helmut

  10. #20
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo zusammen
    genau so wie Arexx-Henk in seinem Beitrag schreibt, sollte man es machen.
    Leider würde es nicht ausreichen nur auf das UDRE-Bit zu schauen, da das Senden im URART 2-Stufig erfolgt.
    1 UDR füllen vom Programm
    2 AVR kopiert UDR in internes Schieberegister --> UDR ist wieder leer
    3 UDR füllen vom Programm
    4 AVR kopiert NICHT
    5 AVR baut Transport-Frame um interne Schieberegisterdaten
    6 AVR sendet Frame
    7 Und weiter bei 2

    Wenn also 2 Byte zu senden sind, dann kann man die im Grunde direkt hintereinander in das UDR-Register schreiben. (Natürlich sollte man das nicht so machen)
    ABER, das UDR-Register ist immer viel schneller leer als man so denkt.
    Genau dies hatte Arexx-Henk beschrieben.

    Hier noch der Code (als Ausschnitt) von ihm:
    Code:
    // warte bis UDR und Schieberegister leer sind
    while ( ! ( UCSRA | (1<<TXC)))
       ;
    // reset handmassig den TXC bit durch schreiben einen '1' !
    UCSRA |= (1<<TXC);
    Aber eigendlich ist bis auf das zurücksetzen des TXC-Bits (auf 1 setzen=reset) schon alles in der LIB. Und trotzdem kommt die for()-Schleife noch hinterher.
    In der LIB wird das "while ( ! ( UCSRA | (1<<TXC)))" nur mit 0x40 anstatt TXC abgefragt.
    Was also ist mit der for()-Schleife?

    Wegen der Bits im USART-Register hier mal eine Zusammenfassung:
    Bit 7: RXC: USART Receive Complete
    Bit 6: TXC: USART Transmit Complete
    Bit 5: UDRE: USART Data Register Empty
    Bit 4: FE: Frame Error
    Bit 3: DOR: Data Overrun
    Bit 2: PE: Parity Error
    Bit 1: U2X: Double the USART transmition speed
    Bit 0: MPCM: Multi-Processor Communication Mode

    Zu Bit 6: TXC steht folgendes auf Seite 151:
    This Flag ist set when the entire Frame in the Transmit Shift Register has been shifted out and there are no new data ... in the .. UDR. The TXC-Bit is automaticlly cleared when a transmit complete interrupt is executed, or it can be cleared by writing a one to the bit.

    Somit scheint also tatsächlich nur das von Arexx-Henk angegebene clear-Bit (setzen auf 1) zu fehlen, so dass die Abfrage mit dem "while ( ! ( UCSRA | (1<<TXC)))" überhaupt erst funktionieren kann im nächsten Durchlauf.
    Man sollte somit überlegen, ob man diese Abfrage nicht in die SerWRITE-Funktion verlegt VOR dem Umschalten auf Sendebetrieb.
    Lieber Asuro programieren als arbeiten gehen.

Seite 2 von 7 ErsteErste 1234 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus