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

[roboterheld]

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

[stefan_Z]

Schau hier mal:
https://www.roboternetz.de/phpBB2/vi...b62e1dc205a9f0

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

[roboterheld]

das ist ein tsop1736,daran liegt es nicht.

[-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...

[for_ro]

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

[roboterheld]

welche aufgabe hat in dem code diese routine : $lib "mcsbyte.lbx" ?

danke.

mfg

[-tomas-]

@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)