- fchao-Sinus-Wechselrichter AliExpress         
Ergebnis 1 bis 7 von 7

Thema: Getrc5(address , Command) bei bascom zu anfällig

  1. #1
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    29.07.2007
    Beiträge
    386

    Getrc5(address , Command) bei bascom zu anfällig

    Anzeige

    LiFePo4 Akku selber bauen - Video
    hallo, ich Suche eine ersatzroutine für Bascom die zu fuss erstellt werden kann für das einlesen der rc5-daten.

    bei der routine von Bascom treten störungen durch neonlampen auf.

    wer kann einen ansatz dafür geben?



    mfg

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2007
    Beiträge
    594
    Schau hier mal:
    https://www.roboternetz.de/phpBB2/vi...b62e1dc205a9f0

    Ansonsten versuch mal nen anderen Empfänger, das kann auch der Grund sein!

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    29.07.2007
    Beiträge
    386
    das ist ein tsop1736,daran liegt es nicht.

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    28.03.2004
    Beiträge
    185
    Dieser GETRC5 ist eine üble Gurke da er auf der ersten Flanke hängt!
    Sieh Dir mal den Bascom-ISR-Code an
    https://www.roboternetz.de/phpBB2/ze...ag.php?t=20209
    der läuft im Hintergrund...

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Zitat Zitat von -tomas-
    Dieser GETRC5 ist eine üble Gurke da er auf der ersten Flanke hängt!
    Sieh Dir mal den Bascom-ISR-Code an
    https://www.roboternetz.de/phpBB2/ze...ag.php?t=20209
    der läuft im Hintergrund...
    Mir ist jetzt nicht so wirklich klar, was du damit meinst, das etwas auf einem µC "im Hintergrund läuft".

    Grundsätzlich denke ich aber, dass deine Vorgehensweise nicht richtig ist. Du baust dir eine sehr große ISR für den Timer auf, die durch ihre Ausführungszeit einen wesentlichen Einfluss auf den Rest des Programms hat. Der Code wird ja nicht aus Selbstzweck empfangen, mit dem soll ja noch was gesteuert werden.

    Daher habe ich in der ISR so wenig wie möglich an Befehlen, der Rest wird in der Main Loop bearbeitet, dann wenn Zeit dazu ist.
    Außerdem liegt der Fokus hier darauf, mehrere Codes zu verarbeiten. Da macht es wenig Sinn, sofort anzufangen, die einzelnen Impulse auszuwerten. Das Programm würde schön unübersichtlich. Deswegen werden alle Zeiten erst einmal zwischengespeichert und nach dem kompletten Empfang in Ruhe verarbeitet.

    Gruß

    Rolf

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    29.07.2007
    Beiträge
    386
    welche aufgabe hat in dem code diese routine : $lib "mcsbyte.lbx" ?

    danke.

    mfg

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    28.03.2004
    Beiträge
    185
    @roboterheld
    mcsbyte.lbx verkürzt den Code bei Byte-Operationen (Details im Handbuch)
    numeric<>string conversion routines only for bytes
    Störungen durch Neonlampen
    Tja, ich weiß nicht, wie Du GETRC5 aufrufst (Ständige Abfrage oder LEVEL-ISR). Jedoch führt ein falscher Lichtimpuls zu bis zu 130ms timeout (Blockade des µC) und genau dass konnte ich damals nicht gebrauchen.

    @for_ro
    Es war nur ein Hinweis, da ich mich damals sehr intensiv mit dem Thema beschäftigt habe.
    Vorgehensweise nicht richtig ist. Du baust dir eine sehr große ISR
    siehe dazu im Text:
    "ISR dauert nur ca. 8µs alle 178µs bei 8Mhz Clock, d.h. ISR 5% µC-Last"
    Der Vorteil ist, diese ISR hängt nicht und ist mit 8µs wenn kein Ereigniss auftritt auch nicht auffällig lang. Ich kenne Dein Projekt nicht, wenn Du diese 8µs nicht entbehren kannst, dann ist es für Dich nicht geeignet (zB Soft-UART etc).
    Mit einer NOSAVE ISR wäre da noch einiges zu optimieren. Diese Registersicherungsorgie dauert alleine 52 Takte = 6,5uS!!

    Habe mir mal Dein umfangreiches Projekt unter https://www.roboternetz.de/phpBB2/ze...ag.php?t=34497 angesehen.
    Respekt. Wir sind im Lösungsansatz gar nicht soweit auseinander, da der Timer ISR bei Dir auch als Hintergrundlast läuft und zusätzlich eine Level-ISR angestoßen wird. Für mich war die Auswertung in der ISR günstiger, da ich wegen umfangreicher LCD-Ausgaben in der Main-Loop nicht garantieren konnte, dass er immer zwischen zwei Flanken genügend Zeit hat. Solange man in der ISR keine Prints/LCD-Ausgaben etc. durchführt, sind ein paar Zeilen Code eher unkritisch. (hängt vom Projekt ab)

Berechtigungen

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

LiFePO4 Speicher Test