mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik mit Bascom über rs232 Frequenz aus einen Frequenzzählermodul auslesen.


Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Ich bin mit meinen geringen Programmierkenntnisse wieder völlig am 
verzweifeln.

Es geht um folgendes Problem.

Ich besitze ein Frequenzzählermodul vom Michael Novak

Den kann man über RS323 vollständig konfigurieren aber auch auslesen.
Ein Atmega 8 soll jetzt mehrere Aufgaben erfüllen.

1. Die Strichbreite der vom Novakmodul ausgegebene Marken via RS232 mit 
Hilfe einer Gleichspannung einstellen. Also Gleichapnnung AD-wandeln und 
als RS232 an den Zähler ausgeben.

Das funktioniert auch einwandfrei.

2. Der Atmega hat 2 Interupteingänge. Je nach dem ob an Eingang1 oder 
Eingang2 ein Triggerimpuls anliegt, liefert der Atmega 8 in beiden 
Fällen erst einen Triggerimpuls an den Zähler. Der Triggerimpuls wird 
auch ausgegeben.

Danach wird via RS232 die Frequenz des Zählers empfangen und in die 
entsprechende Zeile des Displays geschrieben.

Der Zähler soll dann via RS232 die Frequenz zurückliefern und in Zeile 1 
bzw Zeile 2 des OLED Displays schreiben.

Das funktioniert leider nicht ordnungsgemäß.


Wenn ich einen PC an den Zähler anschließe dann bekomme ich auf einen 
Terminalprogramm z.B. folgendes zurück
24,52653 MHz

Und zwar genau 1 mal nach dem der Zähler den Triggerimpuls bekommen hat.

Schließe ich das Atmega8-Modul an, so erscheint einfach nur eine 24 
darauf.

und zwar in beiden Zeilen.

Im Anhang ist das komplette Basicprogramm , was mehrere Funktionen 
abdeckt.

Was nicht funktioniert ist

Dauerlauf abfragen

Interupt von Marke1

Interupt von Marke 2

Bitte jetzt nicht so Sprüche wie Google kaputt? wie kann man nur in 
Basic programmieren , kannst du nicht lesen? usw.

Viel mehr bitte ich darum das sich einer von euch, welcher schon mal 
erfolgreich, das empfangen von einen RS232 String in Bascom auf einen 
Atmega8, implentiert hat, sich mal mein Basicprogramm anzuschauen, und 
mir hilft den Fehler zu finden.

Eventuell könnten wir auch direkt in Kontakt treten.

Ich bin zu erreichen unter r-berres et arcor.de oder unter 065144016

Besten Dank

Ralph Berres

: Bearbeitet durch User
Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
scheint sich wohl keiner damit auszukennen

Ralph Berres

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BASKOM ist BAH! Für die Spezies hier. Lese mal die Anleitug sorgfälltig 
durch und/oder gehe in eines der speziellen BASKOM Foren.

Autor: P.Loetmichel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutlich weil da ein "," als Trenner in der Frequenz ist,
und kein ".".

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du liest wahrscheinlich schneller als daß das Modul liefert:
> Serialchar = Inkey()
Inkey gibt 0 zurück, wenn gerade nichts in UDR wartet, probier's mit 
Waitkey().
Ansonsten halte ich wenig davon auf einen String mit exakt x Zeichen in 
einer ISR zu warten, das kann Dir die ganze Kiste blockieren.
Gibt's da kein CR/LF, das man auswerten könnte?

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.Loetmichel schrieb:
> Vermutlich weil da ein "," als Trenner in der Frequenz ist,
> und kein ".".

werde ich nachher mal schauen. Wenn das die Ursache wäre, dann wäre mein 
Tag gerettet. Allerdings ist das , vom Frequenzzählermodul vorgegeben. 
Ich muss es als Gott gegeben hinnehmen. Da es sich aber um ein 
Asciistring handelt sollte das aber eigentlich nicht zu Problemen 
führen.

Aber ich werde mal statt 24MHz 1240MHz ausfeben. Dann sehe ich ja ob es 
am Komma liegt.

MWS schrieb:
> Ansonsten halte ich wenig davon auf einen String mit exakt x Zeichen in
> einer ISR zu warten, das kann Dir die ganze Kiste blockieren.
> Gibt's da kein CR/LF, das man auswerten könnte?

Mittlerweise habe ich erfahren das es tatsächlich ein CR/LF gibt.

MWS schrieb:
> Du liest wahrscheinlich schneller als daß das Modul liefert:
>> Serialchar = Inkey()

Das vermute ich auch.

MWS schrieb:
> probier's mit
> Waitkey().

werde ich mir mal anschauen.

Ralph Berres

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> MWS schrieb:
>> Du liest wahrscheinlich schneller als daß das Modul liefert:
>>> Serialchar = Inkey()
>
> Das vermute ich auch.

Das "wahrscheinlich" hätte ich mir schenken können, Du liest verbindlich 
schneller aus, als dass das UART liefern kann. Lass die Zykluszeit 
zwischen 10 und 20 Prozessortakten betragen, dann sind das ca. 1,36µs. 
Ein Zeichen dauert bei 9600 Baud = 1,04ms. D.h. die ersten zwei Zeichen 
erwischt Du, weil wohl eines im UDR hängt und das zweite gerade 
empfangen wird, danach liest Inkey() 10 mal nichts, also Null. Null ist 
das Stringendezeichen und so ist der Rest des Strings eben leer.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Das "wahrscheinlich" hätte ich mir schenken können, Du liest verbindlich
> schneller aus, als dass das UART liefern kann. Lass die Zykluszeit
> zwischen 10 und 20 Prozessortakten betragen, dann sind das ca. 1,36µs.
> Ein Zeichen dauert bei 9600 Baud = 1,04ms.

Ich hatte ursprünglich 115Kbaud eingestellt. Da war exakt das selbe 
Verhalten.

In Programmieren tue ich mich unglaublich schwer.

Trotz stundenlanger Suche in diversen Foren und Google habe ich bis 
heute nicht begriffen, wie man es anstellt, das der String in einen 
Rutsch in einen
Puffer eingelesen wird, den man dann in Ruhe auslesen kann.

Irgendwie bin ich als reiner Hardwaremensch zu blöde dazu.

Was ich will ist den kompletten String welches ich über RS232 bekomme so 
wie er ist ins Display übertragen.

Was ich so erlesen habe kommt es mir vor das in dem Puffer immer nur ein 
Zeichen des Strings zwischengespeichert wird. Dann wäre klar warum das 
nicht geht.

Vieleicht kann mir jemand mal erklären wie genau Ascom mit dem String 
umgeht, nzw wie ich es genau anstellen muss das erst der gesamte String 
in einen Rutsch in ein Buffer geschrieben wird, damit die Baudrate 
keinen Einfluss mehr hat.

Vielleicht kann mir auch jemand mal erklären, wie ich das LF/CR Zeichen 
auswerte. Idealerweise vielleicht mal den Code in Interupt Marke1 
korrigiert.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Ich hatte ursprünglich 115Kbaud eingestellt. Da war exakt das selbe
> Verhalten.

Selbstverständlich war es das selbe Verhalten, bei 115k benötigt ein 
Zeichen 86,8µs, währen Inkey() für eine Runde 1,36µs benötigt, für 10 
Zeichen also 13,60µs, dann ist die Schleife fertig. Da kann nichts mehr 
kommen.

> Trotz stundenlanger Suche in diversen Foren und Google habe ich bis
> heute nicht begriffen, wie man es anstellt, das der String in einen
> Rutsch in einen
> Puffer eingelesen wird, den man dann in Ruhe auslesen kann.

Das würde "vorgefertigt" mit "Input" gehen. Damit Input weis, wann die 
Daten zu Ende sind, musst Du mit "Config Input" das Format des Endes 
mitteilen, d.h. CR, CRLF, etc., welches mit dem übereinstimmen muss, was 
das Zählermodul schickt.

So einfach das in diesem Fall läuft, könntest Du auf den (wie im Code im 
Ansatz erkennbar) seriellen Puffer verzichten. Was ich reinsetzen würde 
ist $TIMEOUT, damit Input bei Fehlern abbricht. Sonst hängt's im 
Interrupt fest.

Ohne Input geht's auch, aber entweder muss IsCharWaiting() mit InKey() 
kombiniert werden, oder man muss WaitKey() verwenden. Nur einmal 
IsCharWaiting() am Anfang klappt so nicht.

> in einen Rutsch in ein Buffer geschrieben wird, damit die Baudrate

Wie schon geschrieben puffern über:
>  ' Config Serialin = Buffered , Size = 20

Leseaktionen gehen dann über den Puffer, während im Hintergrund über 
Interrupt die Zeichen fleißig vom UART geholt werden.

Das befreit Dich jedoch nicht davon eine Fehlerlogik einzubauen und vor 
allem: wenn Du wie gezeigt über InKey() gnadenlos zu schnell liest, dann 
hilft Dir der Puffer auch nur begrenzt.

> Vielleicht kann mir auch jemand mal erklären, wie ich das LF/CR Zeichen

Wenn Du das selbst machen willst, also nicht über Input mit Config 
Input, dann merkst Du Dir jeweils das vorhergehend Zeichen oder Du 
schaust das letzte Zeichen des zusammengebauten Strings an. Wenn dieses 
ein LF (&h0A) war und das gerade eingetroffene ein CR (&h0D), dann ist 
das Datenende erreicht.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simpelbeispiel:
' ...
$TIMEOUT = 1000000   ' verschiedene Werte selber testen
Config Input = LFCR   ' Sicher dass vom Modul nicht CRLF kommt?
ECHO OFF   ' mit Echo würden über Input empfangene Daten zurückgegeben und das Modul sich verschlucken
' ...
 Marke1:
' ...
'*************** Characters über UART empfangen ****************************
   Input Serialstring_m1

                  'in Zeile 1 anzeigen
      Oled_col = 1                      'Zeile = 1
' ...

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ein kleines Beispiel zum testen mit Terminalausgabe.

Dim Sx As String * 25                                     'Stringlänge 
gesamt + Endzeichen
Dim B(24) As Byte At Sx Overlay                           'Feld mit 24 
Byte anlegen
Dim N As Byte

Enable Urxc                                              'Uart Rx 
aktivieren
Enable Interrupts
On Urxc Onrxd                                            'ISR festlegen

  Do
      Wait 1                                                'für Test
    If N > 11 Then
      'Hinweis: N sollte immer 1Byte kleiner sein als die min. Anzahl
      'der Sendebyte. Für Test auch N > 0 möglich.
        Print "String =  " ; Sx                             'für Test
        Print "N = " ; N                                    'für Test
      N = 0                                             'Zähler 
zurücksetzen
   End If
     'Dein Programm
       Print "mache meine eigentliche Arbeit"               'für Test
       Print "Blablabla"                                    'für Test
       Print "..............."                              'für Test
 Loop

'hier wird in Uart geschaut ob neue Byts gesendet wurden
  Onrxd:
   Incr N                                                   'Byte von 
UDR hochzählen
     B(n) = Udr
  Return

Natürlich gibt es noch andere Möglichkeiten aber diese sollte für deine 
Zwecke reichen.
Wenn nicht dann melde ich mich per PN.

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Simpelbeispiel:' ...
> $TIMEOUT = 1000000   ' verschiedene Werte selber testen
> Config Input = LFCR   ' Sicher dass vom Modul nicht CRLF kommt?
> ECHO OFF   ' mit Echo würden über Input empfangene Daten zurückgegeben
> und das Modul sich verschlucken
> ' ...
>  Marke1:
> ' ...
> '*************** Characters über UART empfangen
> ****************************
>    Input Serialstring_m1
>
>                   'in Zeile 1 anzeigen
>       Oled_col = 1                      'Zeile = 1

Was für bein Quatsch!

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred R. schrieb:
> Onrxd:
>    Incr N                                                   'Byte von
> UDR hochzählen
>      B(n) = Udr
>   Return

Ohne Begrenzung für N in der ISR sind prima Speicherüberläufe 
vorprogrammiert, sollte die Hauptschleife nicht gleich reagieren.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian schrieb:
> Was für bein Quatsch!

Ein Einsteinscher Qualitätsbeitrag LOL

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Ohne Begrenzung für N in der ISR sind prima Speicherüberläufe
> vorprogrammiert, sollte die Hauptschleife nicht gleich reagieren.

Speicherüberläufe wie? Und wenn ein Programm im ISR hängen bleibt ist 
doch grundsätzlich was falsch. Oder kommt es bei Dir öfter vor das die 
Hauptschleife nicht gleich reagiert?
Ist mir in den letzten 20 Jahren nur einmal passiert da hat aber der 
Controller ein Rauchzeichen gegeben.

Mit freundlichen Grüßen

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
momentan läuft das auslesen mit viel Trixerei

Es funktioniert nur wenn nach dem Triggerimpuls eine Wartezeit von genau 
1ms eingestellt ist.

 Marke1:
    Portd.6 = 0
   Pulseout Portd , 6 , 6000            'Triggerimpuls 150µs
    Waitms 1
         '*************** Characters über UART empfangen 
****************************

      If Ischarwaiting() = 1 Then

     Input Serialstring_m1


          End If
          Waitms 1
    '  Clear Serialin

               'in Zeile 1 anzeigen
      Oled_col = 1                      'Zeile = 1
      Oled_row = 1                      'Position = 1
      Gosub Oled_position
      Datensatz1 = Blank16              'Zeile Löschen
      Call Oled_zeile1


      Oled_col = 1                      'Zeile = 1
      Oled_row = 1                      'Position = 1
      Gosub Oled_position
      Datensatz1 = Blank2 + Serialstring_m1 + Blank2
      Call Oled_zeile1

        Return

 '******************* Interrupt von Marke2 
***********************************
 Marke2:
    Portd.6 = 0
   Pulseout Portd , 6 , 6000            'Triggerimpuls 150µs
    Waitms 1
 '*************** Characters über UART empfangen 
****************************


      If Ischarwaiting() = 1 Then

      Input Serialstring_m2

        End If
        Waitms 1

     ' Clear Serialin
              'in Zeile 2 anzeigen
      Oled_col = 2                      'Zeile = 2
      Oled_row = 1                      'Position = 1
      Gosub Oled_position
      Datensatz2 = Blank16              'Zeile Löschen
      Call Oled_zeile1


      Oled_col = 2                      'Zeile = 2
      Oled_row = 1                      'Position = 1
      Gosub Oled_position
      Datensatz2 = Blank2 + Serialstring_m2 + Blank2
      Call Oled_zeile1

         Return

allerdings das mit dem Pufferspeicher
Config Serialin = Buffered , Size = 20 funktioniert es überhaupt nicht.

Jetzt habe ich noch das Problem das in beiden Zeilen die Frequenz an der 
ersten Marke angezeigt wird, obwohl der Frequenzzähler nacheinander an 
beiden Marken verschiedene Frequenzen misst.

Irgendwie habe ich das Gefühl das der zweite String vom Zähler ignoriert 
wird.

Hat da einer eine Idee?

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred R. schrieb:
> Speicherüberläufe wie?

Wenn weiter Zeichen empfangen werden während z.B. die Hauptschleife mit 
etwas anderem beschäftigt ist, dann wird N bis 255 erhöht, um dann auf 0 
überzulaufen, was  noch nicht das eigentliche Problem ist. Das Problem 
ist B(n) = Udr, bei N = 26 wird die nachfolgend dimensionierte Variable 
überschrieben. Der Controller nimmt keine Bereichsprüfung vor, das musst 
Du selbst machen.

> Und wenn ein Programm im ISR hängen bleibt ist
> doch grundsätzlich was falsch.

Über in der ISR hängenbleiben sprach niemand, ein Blockieren innerhalb 
der ISR hätte auch nicht den Effekt des Hochzählens von N.

Fred R. schrieb:
> Oder kommt es bei Dir öfter vor das die
> Hauptschleife nicht gleich reagiert?

Aber sicher kommt das vor, bei Deinem Code kommt das hier vor:
Print "mache meine eigentliche Arbeit"               'für Test
Print "Blablabla"                                    'für Test
Print "..............."                              'für Test
denn während der Controller fast 60 Zeichen ausgibt, können gleichfalls 
entsprechend so viele Zeichen eintreffen und dann ist Dein String/Array 
längst übergelaufen. Deswegen begrenzt man N in diesem Fall in der ISR 
und nicht im Hauptprogramm und ich verstehe nicht warum ich das 
überhaupt diskutieren muss, denn sowas ist selbstverständlich.

> Ist mir in den letzten 20 Jahren nur einmal passiert
Das ist nun immerhin verwunderlich.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> If Ischarwaiting() = 1 Then

Das ist in meinem Beispiel nicht drin und gehört da auch nicht rein. 
Außerdem war die gezeigte Verwendung bereits vorher Unsinn und ist es 
jetzt nicht weniger.

Input wartet von selbst solange auf Zeichen bis die Stringendebedingung 
LFCR (oder wie auch immer eingestellt) eingetreten ist. Oder bis 
TIMEOUT, falls konfiguriert, erreicht ist. Bei Input hast Du eher das 
Problem, dass ohne Timeout und ohne Stringende bis auf St.Nimmerlein 
gewartet wird. Wenn das in einem Interrupt passiert, ist dann eben Ende.

Ralph B. schrieb:
> Config Serialin = Buffered , Size = 20 funktioniert es überhaupt nicht.

Man muss dabei aufpassen, dass im Puffer nichts übrig gebliebenes drin 
hängt, also den Puffer unmittelbar vorher löschen.

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> denn während der Controller fast 60 Zeichen ausgibt, können gleichfalls
> entsprechend so viele Zeichen eintreffen und dann ist Dein String/Array
> längst übergelaufen. Deswegen begrenzt man N in diesem Fall in der ISR
> und nicht im Hauptprogramm und ich verstehe nicht warum ich das
> überhaupt diskutieren muss, denn sowas ist selbstverständlich.
>
>> Ist mir in den letzten 20 Jahren nur einmal passiert
> Das ist nun immerhin verwunderlich.

Musst nicht mit mir diskutieren. Einfach(einfach) helfen.
Deine Hilfe für mich habe ich aber nicht geschnallt. Bin der Meinung ein 
Interrupt stoppt das „Hauptprogramm“ unverzüglich und gehrt genau an 
diese Stelle zurück um weiter zu machen und somit sollte im ISR keine 
„Bremse“ eingebaut werden. Ob ich im HP 1 Zeichen oder 100 printe hat 
doch nichts mit Empfangszeit zu tun.

MWS schrieb:
> Bei Input hast Du eher das
> Problem, dass ohne Timeout und ohne Stringende bis auf St.Nimmerlein
> gewartet wird. Wenn das in einem Interrupt passiert, ist dann eben Ende.
Brauch doch nur in Config Serialin ein Endzeichen mit angeben.

Aber lassen wir es.
MfG

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Damit Input weis, wann die
> Daten zu Ende sind, musst Du mit "Config Input" das Format des Endes
> mitteilen, d.h. CR, CRLF, etc., welches mit dem übereinstimmen muss, was
> das Zählermodul schickt.

wenn ich das eintippe

$hwstack = 64
$swstack = 64
$framesize = 60
'$baud = 115200
 $baud = 9600

'Config Serialin = Buffered , Size = 20
Config Input = Cr

Dim Char_buffer1(16) As String * 1
Dim Char_buffer2(16) As String * 1
Dim Contrast_wert As Byte

bekomme ich beim compilieren eine Fehlermeldung

Error : 103   Line :   16    = expected  , in File : 
C:\Users\Berres\Desktop\swob5\Strichbreite3.bas

Ich komme nicht dahinter warum er diesen Befehl nicht nimmt.

Ralph

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Config Serialin = Buffered , Size = 20 , Bytematch = 13 ‘ist CR
……
...

Sub Serial1charmatch()
  Pushall
  Input, xyz Noecho
  Popall
End Sub

So nun kann dein HP machen was es will nur wenn Chr(13) kommt wird 
delesen.
 Gruß
Fred

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred R. schrieb:
> Musst nicht mit mir diskutieren. Einfach(einfach) helfen.
Tja, was nu?

> Deine Hilfe für mich habe ich aber nicht geschnallt. Bin der Meinung ein
> Interrupt stoppt das „Hauptprogramm“ unverzüglich und gehrt genau an
> diese Stelle zurück um weiter zu machen und somit sollte im ISR keine
> „Bremse“ eingebaut werden. Ob ich im HP 1 Zeichen oder 100 printe hat
> doch nichts mit Empfangszeit zu tun.

Doch, weil der im Hintergrund über den URXC-Interrupt empfängt und erst 
wieder nach der Zeit in denen er die 60 Zeichen ausgegeben hat, plus im 
Fall des von Dir gezeigten Codes plus 1 Sekunde wieder an die Stelle 
zurückkommt, an der N vor Überlauf geschützt werden soll:

> Wait 1
> If N > 11 Then

Im Interrupt kann N dagegen bis 255 hochlaufen und den Speicher 
überschreiben. Eine Prüfung auf N im Interrupt hat zudem nichts mit 
bremsen zu tun, sondern das ist regulärer und sinnvoller Code.

Fred R. schrieb:
> Aber lassen wir es.

Dein Wunsch sei mir Befehl, denn Du bist entweder ein Schwerkapierer 
oder ein Sehrschwerkapierer und wenn das Gezeigte der Wissenstand nach 
20 Jahren ist:

Fred R. schrieb:
> Ist mir in den letzten 20 Jahren nur einmal passiert

dann gute Nacht.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Ich komme nicht dahinter warum er diesen Befehl nicht nimmt.

Echo ist kein optionaler Parameter, das muss mit dazu geschrieben 
werden, hab' ich auch übersehen. So compiliert's:

> Config Input = CR , Echo = CR

Wenn Du verhindern willst, dass vom Modul ausgegebene Daten wieder an 
dieses zurückgeschickt werden, dann schalte wie schon geschrieben ECHO 
ab. Und aufpassen, wenn das Modul ein CRLF sendet, Input aber nur die 
Daten samt dem CR holt, dann bleibt ein LF im UART zurück, welches beim 
nächsten Input stören kann.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so das Problem ist momentan mal in sofern gelöst,

das ich die beiden Markenfrequenzen jetzt vollständig in der rifhtigen 
Zeile stehen hab.

Ich weis das es nicht professionell gelöst ist, aber immerhin 
funktioniert es zunächst mal.

Jetzt werde ich mich als nächstes an die Rutine Dauerlauf zuwenden.

Der Fehler warum in béiden Zeilen das selbe stand war trivial.

Man muss natürlich auch im Display angeben wohin man schreiben will.

Ralph B. schrieb:
> ' Clear Serialin
>               'in Zeile 2 anzeigen
>       Oled_col = 2                      'Zeile = 2
>       Oled_row = 1                      'Position = 1
>       Gosub Oled_position
>       Datensatz2 = Blank16              'Zeile Löschen
>       Call Oled_zeile1
>
>       Oled_col = 2                      'Zeile = 2
>       Oled_row = 1                      'Position = 1
>       Gosub Oled_position
>       Datensatz2 = Blank2 + Serialstring_m2 + Blank2
>       Call Oled_zeile1

hier war der Fehler es musste natürlich call oled_zeile2 heisen.

Besten Dank an alle die mir versucht haben zu helfen.

Ralph Berres

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Fred R. schrieb:
>> Aber lassen wir es.
>
> Dein Wunsch sei mir Befehl, denn Du bist entweder ein Schwerkapierer
> oder ein Sehrschwerkapierer und wenn das Gezeigte der Wissenstand nach
> 20 Jahren ist:
>
> Fred R. schrieb:
>> Ist mir in den letzten 20 Jahren nur einmal passiert
>
> dann gute Nacht.

Na dann sage ich auch gute Nacht.
Mit freundlichen Grüßen der Sehrschwerkapierter

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Besten Dank an alle die mir versucht haben zu helfen.

Nun, der Versuch war offenbar erfolgreich.

> so das Problem ist momentan mal in sofern gelöst,

Möchtest Du vielleicht für die Nachwelt hinterlassen, wie Du es gelöst 
hast? Sonst geht das eigentlich Spannende ab.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe genau die Rutine verwendet die ich um 12:42 gepostet habe.

Du hattest mir dann geschrieben, das man es genau so nicht machen soll.

Lediglich die Einträge im Display waren im nachhinein falsch.
siehe 16:16

es funktioniert auch nur mit 9k6 ist somit also unsauber programmiert.

Ich kann es leider nicht besser.

Ralph Berres

Autor: Blindfisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:

> Möchtest Du vielleicht für die Nachwelt hinterlassen, wie Du es gelöst
> hast? Sonst geht das eigentlich Spannende ab.

Versuch's mal mit dem Lesen des letzten Beitrages vom TO. Da könnte man 
drauf kommen, wenn man nicht die Brille vom Nachbarn auf hat.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> ich habe genau die Rutine verwendet die ich um 12:42 gepostet habe.
>
> Du hattest mir dann geschrieben, das man es genau so nicht machen soll.

Ja, weil:

> If Ischarwaiting() = 1 Then

a) in diesem Fall überflüssig ist, da das vom Input erledigt wird und
b) wenn zum Zeitpunkt des Aufrufs von Ischarwaiting() noch kein Zeichen 
wartet, der ganze Empfangsblock ausfällt.

Für b) hattest Du ein Waitms drin, was aber nicht notwendig ist, wenn 
das Ischarwaiting() weg kommt:

Ralph B. schrieb:
> Es funktioniert nur wenn nach dem Triggerimpuls eine Wartezeit von genau
> 1ms eingestellt ist.

Und ja, man machte es einfach genau so nicht wie im Eingangs gezeigten 
Code, dass man einmal auf ein eingetroffenes Zeichen wartet und dann 
ohne Prüfung ob weitere vorhanden sind, versucht stur welche zu lesen.

> es funktioniert auch nur mit 9k6 ist somit also unsauber programmiert.

Wie kannst Du das Modul senderseitig umstellen?

> Ich kann es leider nicht besser.

Ich verzeihe Dir ;-D

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> a) in diesem Fall überflüssig ist, da das vom Input erledigt wird und
> b) wenn zum Zeitpunkt des Aufrufs von Ischarwaiting() noch kein Zeichen
> wartet, der ganze Empfangsblock ausfällt.
>
> Für b) hattest Du ein Waitms drin, was aber nicht notwendig ist, wenn
> das Ischarwaiting() weg kommt:

nur mit dem Input Befehl hat es aber nicht funktioniert.

MWS schrieb:
> Wie kannst Du das Modul senderseitig umstellen?

Man kann das Frequenzzählermodul zwischen 9600Baud und 256Kbaud 
einstellen.

MWS schrieb:
> Und ja, man machte es einfach genau so nicht wie im Eingangs gezeigten
> Code, dass man einmal auf ein eingetroffenes Zeichen wartet und dann
> ohne Prüfung ob weitere vorhanden sind, versucht stur welche zu lesen.

Leider habe ich es nicht besser hinbekommen.

Ich hätte aber nichts dagegen wenn du das Programm von mir entsprechend 
modifizierst, und mir als BAS zurückschickst. ( du müsstest aber die 
Endung in BAX umbenennen, weil mein Emailserver es sonst ablehnt ).

Es sind ja drei Programmteile die von betroffen sind.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> nur mit dem Input Befehl hat es aber nicht funktioniert.

Was passierte dann genau?

Input arbeite so, dass es Schleifchen dreht bis es Daten in's UDR 
bekommt und beendet wenn es die Endbedingung sieht.

Wie sieht es denn aus, wenn IsCharwaiting() weggelassen und ein kleines 
Delay vorher eingefügt, bzw. beibehalten wird? Man könnte vermuten, dass 
sich Reste im UDR befinden.

Was auch zu probieren wäre, ist ein Dummy-Read des UDR gleich zu Beginn 
des Interrupts, damit sichergestellt ist, dass nichts im UDR wartet.
Also:
tmp = UDR

> Ich hätte aber nichts dagegen wenn du das Programm von mir entsprechend
> modifizierst

Das würde mir wohl mit Dir zu anstrengend ;D

Deine Reaktion hat, wie soll ich es freundlich sagen, zuviel Trägheit. 
Z.B. habe ich jetzt ein wenig gegoogelt, um Details zum Modul von 
Michael Novak zu finden. Und siehe da, man findet es und zwar hier:

Beitrag "Re: DIY Frequency Counter mit 10 bis 12 Digits?"

Da steht z.B. dass das Modul mit CRLF antwortet. Eine wichtige 
Information, denn wenn Du Input nur mit CR beendest, dann bleibt ein LF 
im UART hängen, was zu Problemen führen kann.

Das bekomme ich von Dir aber nicht freiwillig geliefert, sondern ich 
muss danach suchen. Und das ist ermüdend. Genauso wie Du jeweils den 
kompletten neuen Code als Anhang anhängen und nicht in Fetzerl in 
Prosa beschreiben solltest. Ein Schaltbild als .sch, statt als Pdf, 
sowas macht keinen Spaß.

Genauso wenig amüsierlich ist es, wenn ich hier jemand im Thread 
erklären muss, dass er unmittelbar im Codeteil an dem eine 
Datenkorruption durch Überschreiben stattfinden kann, eine Sicherung 
dafür vorsehen muss. Und er's immer noch nicht versteht und rumzankt.

Soviel Selbstkasteiung reicht mir für einen Tag in die Haut nei, da muss 
ich mir nicht Deinen Code auch noch geben, noch dazu das genau Timing 
Deiner Hardware unbekannt ist.

> Leider habe ich es nicht besser hinbekommen.

Wenn's das tut was es soll, passt's doch.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Was passierte dann genau?
>
> Input arbeite so, dass es Schleifchen dreht bis es Daten in's UDR
> bekommt und beendet wenn es die Endbedingung sieht.
>
> Wie sieht es denn aus, wenn IsCharwaiting() weggelassen und ein kleines
> Delay vorher eingefügt, bzw. beibehalten wird? Man könnte vermuten, dass
> sich Reste im UDR befinden.
>
> Was auch zu probieren wäre, ist ein Dummy-Read des UDR gleich zu Beginn
> des Interrupts, damit sichergestellt ist, dass nichts im UDR wartet.
> Also:
> tmp = UDR

das Problem ist das ich mangels ausreichender Programmierkenntnisse und 
Erfahrungen selbst schlecht abschätzen kann, was im Programm genau 
passiert.

Aber wo du mir jetzt die konkreten Fragen stellst werde ich das 
natürlich morgen ausprobieren und berichten.

MWS schrieb:
> Deine Reaktion hat, wie soll ich es freundlich sagen, zuviel Trägheit.

Kommt vielleicht daher das es für mich schwierig ist die einzelne 
Ratschläge zeitnah umzusetzen.

Beispielsweide bekomme ich bei dem Eintrag config serialinput immer 
Fehlermeldungen beim Copmpilieren bei der ich nicht rausgefunden was ihm 
dabei nicht gefällt.

MWS schrieb:
> Da steht z.B. dass das Modul mit CRLF antwortet. Eine wichtige
> Information, denn wenn Du Input nur mit CR beendest, dann bleibt ein LF
> im UART hängen, was zu Problemen führen kann.

Ich wusste das zunächst auch nicht. Bisher glaubte ich das eben kein cr 
und LF hinten dranhängt.

MWS schrieb:
> Genauso wie Du jeweils den
> kompletten neuen Code als Anhang anhängen und nicht in Fetzerl in
> Prosa beschreiben solltest.

OK den ursprünglichen Code hatte ich am Eingang gepostet. Sorry das ich 
ab dann nur die Änderungen gepostet habe. Werde ich aber morgen 
nachholen.

MWS schrieb:
> Ein Schaltbild als .sch, statt als Pdf,
> sowas macht keinen Spaß.

Es war offenbar ein Irrtum von mir das nicht jeder Eagle wenigsten zum 
Lesen der Datei hat. Ich werde das Schaltbild also ausdrucken und 
einscannen.

MWS schrieb:
> Genauso wenig amüsierlich ist es, wenn ich hier jemand im Thread
> erklären muss, dass er unmittelbar im Codeteil an dem eine
> Datenkorruption durch Überschreiben stattfinden kann, eine Sicherung
> dafür vorsehen muss. Und er's immer noch nicht versteht und rumzankt

Bin ich damit gemeint? Ich habe dieses Streitgespräch interlektuell 
nicht vollständig nachverfolgen können.

Ich kenne mich mit Programmierung nur rudimär aus. Mein Hauptgebiet ist 
mehr die HF Technik.

Sorry wenn ich dich verärgert habe.

Ich habe jetzt fast 2 Wochen Urlaub verbracht um das Programm zum laufen 
zu bekommen, und bin immer noch Fehler am suchen.

Ich wünsche dir noch einen schönen Abend.


Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Sorry wenn ich dich verärgert habe.

Du hast mich sicher nicht verärgert, ich hab' nur für mehr keinen Nerv.

> Bin ich damit gemeint? Ich habe dieses Streitgespräch interlektuell
> nicht vollständig nachverfolgen können.

Nein, Du warst nicht gemeint. Da hab' ich auf eine offensichtliche 
Schwachstelle hingewiesen und mir schlug Unverständnis entgegen.

Ralph B. schrieb:
> Beispielsweide bekomme ich bei dem Eintrag config serialinput immer
> Fehlermeldungen beim Copmpilieren bei der ich nicht rausgefunden was ihm
> dabei nicht gefällt.

Da musst Du eben genau beschreiben was nicht geht.
Wenn Du allerdings tatsächlich "config serialinput" schreibst, musst Du 
Dich nicht wundern, denn es muss "Config Serialin" lauten.

Autor: Wolfgang S. (wsm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interrupt und andere Echtzeitanwendungen (Serielle Datenübertragung) 
dürfen nicht gemeinsam ohne Kontrolle laufen.

Ist den sichergestellt, dass die Interrupte währende der 
Datenübertragung ausgeschaltet sind?

Dann empfehle ich noch die Stackwerte zu vergrößern.

W.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Es war offenbar ein Irrtum von mir das nicht jeder Eagle wenigsten zum
> Lesen der Datei hat. Ich werde das Schaltbild also ausdrucken und
> einscannen.

wie versprochen hier das Schaltbild samt Layout im Anhang

Leider sehr groß geworden. Doch ich weis nicht wie man die Datei 
verkleinert.


Rest erfolgt später von dem anderen Rechner.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Wie sieht es denn aus, wenn IsCharwaiting() weggelassen und ein kleines
> Delay vorher eingefügt, bzw. beibehalten wird?

Du hast recht

Es funktioniert auch sogar ohne die Verzögerungen

MWS schrieb:
> Was auch zu probieren wäre, ist ein Dummy-Read des UDR gleich zu Beginn
> des Interrupts, damit sichergestellt ist, dass nichts im UDR wartet.
> Also:
> tmp = UDR

was bewirkt das? wird der Inhalt des Registers in die Variable Temp 
übertragen?

an welcher Stelle muss ich das einfügen?

muss ich es nicht hinterher wieder löschen? und wie macht man das?


Ralph

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Dich nicht wundern, denn es muss "Config Serialin" lauten.

offenbar wird der Interupt0 und Interupt1 blockiert.

es steht jetzt die Frequenz des Interupt0 in der ersten Zeile.

Interupt1 wird garnicht mehr ausgelöst.


kann es sein das man nach dem Interupt auslösen mit Clear serialin das 
Register erst wieder löschen muss?

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> was bewirkt das? wird der Inhalt des Registers in die Variable Temp
> übertragen?
Das bewirkt, dass das 'U'art 'D'ata 'R'egister als gelesen betrachtet 
wird.

> an welcher Stelle muss ich das einfügen?
Unmittelbar am Anfang der ISR.

Das benötigst Du jedoch nicht, wenn Du:
Config Input = CRLF , Echo = CRLF
schreibst. Dann wird das LF mit abgeholt.

Dass es CRLF ist, ist dem von Dir verlinkten Pdf zu entnehmen, Zitat:
> Ein Beispiel für die Abfrage eines eingestellten Wertes
> (Meßzeit F2):.B Antwort: B666 <CR><LF> für 0,666 Sekunden

Wenn Du das LF nicht liest, dann meldet das UART weiterhin, dass Daten 
bereitstehen. Rufst Du dann Input auf, wird das LF als erstes Zeichen in 
den Eingabestring übernommen und danach der Rest der Antwort vom 
Zählermodul. Das CR am Ende wird von Input entfernt, trotzdem ist das LF 
am Anfang störend, Dein Display könnte davon irritiert sein. Und Du hast 
wieder ein neues LF im Uart hängen.

Ralph B. schrieb:
> offenbar wird der Interupt0 und Interupt1 blockiert.

Denk daran beim Versuch einen gepufferten Empfang zu basteln (Config 
Serialin), dass Dein momentaner Empfang in einem Interrupt abläuft. 
Jeder hier wird Dir zwar sagen, dass das nicht der Hit ist, aber die 
schreiben Dir auch keinen neuen Code.

Innerhalb eines Interrupts sind weitere Interrupts gesperrt, ein 
gepufferter UART-Empfang funktioniert jedoch nur über Interrupt. Was 
bedeutet, dass der gepufferte Empfang innerhalb des externen Interrupts 
Marke1/2 unterbrochen ist. Da der gepufferte Empfang intern andere 
Routinen verwendet, funktioniert bei ausgeschalteten Interrupts auch der 
normale ungepufferte Empfang über die Bascom-eigenen Routinen nicht 
mehr.

Für einen gepufferten Empfang musst Dein Code völlig umgestrickt werden, 
überleg' Dir ob Du das willst.

Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Dass es CRLF ist, ist dem von Dir verlinkten Pdf zu entnehmen, Zitat:
>> Ein Beispiel für die Abfrage eines eingestellten Wertes
>> (Meßzeit F2):.B Antwort: B666 <CR><LF> für 0,666 Sekunden

Diese Angabe war nicht korrekt und ist korrigiert.
Als Abschluß werden 0x0A 0x0D ausgegeben, auch wenn sich als Begriff für 
einen Stringabschluß CR/LF 'eingebürgert' hat.

Normalerweise ist das völlig egal, da typischerweise CR als Abschluß 
erwartet wird. Andere Steuerzeichen von 0x00 - 0x1F werden in der Regel 
beim Empfang ausgefiltert. Auch ein LF als 'Geisterzeichen' nach einem 
CR will niemand (mehr) haben.

Wer einen Centronics 737 Drucker verwendet kennt das Problem: Ein 
linefeed (0x0A) direkt am Anfang einer Zeile bewirkt keinen 
Zeilenvorschub sondern wird ignoriert ;-)

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Diese Angabe war nicht korrekt und ist korrigiert.

Wer hat wie-wo-was korrigiert? Quelle?

> Als Abschluß werden 0x0A 0x0D ausgegeben, auch wenn sich als Begriff für
> einen Stringabschluß CR/LF 'eingebürgert' hat.

0x0A 0x0D entspricht LFCR und "eingebürgert hat sich da gar nichts, wenn 
da also CRLF steht, dann sind auch genau diese zwei Zeichen in dieser 
Reihenfolge zu erwarten.

Glaubst Du, dass der Prozessor 'ne "eingebürgert"-Funktion besitzt, in 
der er verkehrt herum Ankommendes uminterpretiert?

> Normalerweise ist das völlig egal, da typischerweise CR als Abschluß
> erwartet wird. Andere Steuerzeichen von 0x00 - 0x1F werden in der Regel
> beim Empfang ausgefiltert. Auch ein LF als 'Geisterzeichen' nach einem
> CR will niemand (mehr) haben.

Wir sind hier nicht beim "normalerweise", wir sind hier beim 
Mikroprozessor und selbst wenn wir die mit zu 30% Rechtschreibfehlern 
durchwirkten Threadtitel dieses Forums noch verstehen, so würde das ein 
Mikroprozessor schon lange nicht mehr.

Ergo: Sag dem Ding, was es erwarten kann und dann funktioniert das auch, 
dafür gibt es dann Config Input = LFCR, ...

Sollte Dein Post von wegen "werden 0x0A 0x0D ausgegeben" tatsächlich 
Gehalt haben, dann hat der Autor des Zählermoduls etwas anders gemacht. 
Ohne weiteren Beleg halte ich das aber erst einmal für das übliche 
Forumsrauschen.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heute Mittag treffe ich mich mal mit jemanden der auch versucht mit dem 
Bascom was zu machen. Er hat schon in C RS232 Schnittstellen auf dem 
Atmega programmiert, und ist eigentlich in Delphi zu Hause.

Ich habe zwar das Programm prinziepiell irgendwie ans laufen bekommen ( 
so wie man es nicht machen sollte ), aber vielleicht kann ich heute 
Mittag was lernen , wie man es richtig macht.

Zur Zeit kämpfe ich damit das beim Neutstart trotz Resetkondensator das 
Programm nur widerwillig starten will.

Komischerweise auch noch in Abhängigkeit ob der Programmieradapter dran 
hängt oder nicht.

Aber ehe ich dazu näheres äusere will ich erst mal versuchen zu 
ergründen, was da genau abgeht. Feststeht, wenn ich von Hand den 
Reseteingang gegen Masse lege startet er wenigstens, aber das Logo wird 
mehrmals durchlaufen mit viel zu kurzer Verweilzeit. Als ob der 
Hardwareinterupt dazwischenfunken würde.

Wie gesagt das mus ich morgen mal genauer ergründen was da los ist.



Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Diese Angabe war nicht korrekt und ist korrigiert.
Sag' halt deutlich, wer Du bist.
http://mino-elektronik.de/
Dein Username, Vorname Mi und Nachname No deutet darauf hin.
Solltest Du den Zähler programmiert haben, dann solltest Du in der Tat 
wissen wie.

Wobei man dann trotzdem nicht so einen Quark erwarten würde:
Mi N. schrieb:
> Als Abschluß werden 0x0A 0x0D ausgegeben, auch wenn sich als Begriff für
> einen Stringabschluß CR/LF 'eingebürgert' hat.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Innerhalb eines Interrupts sind weitere Interrupts gesperrt, ein
> gepufferter UART-Empfang funktioniert jedoch nur über Interrupt. Was
> bedeutet, dass der gepufferte Empfang innerhalb des externen Interrupts
> Marke1/2 unterbrochen ist. Da der gepufferte Empfang intern andere
> Routinen verwendet, funktioniert bei ausgeschalteten Interrupts auch der
> normale ungepufferte Empfang über die Bascom-eigenen Routinen nicht
> mehr.

ich beginne allmählich zu ahnen, warum das mit dem config serialin nicht 
funktioniert.

Kann es sein das es sich wohl schlicht mit der Tatsache, das ich ja 
einen Hardwareinterupt schon ausgelöst habe, beißt?

Ralph Berres

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> MWS schrieb:
>> Innerhalb eines Interrupts sind weitere Interrupts gesperrt, ein
>> gepufferter UART-Empfang funktioniert jedoch nur über Interrupt. Was
>> bedeutet, dass der gepufferte Empfang innerhalb des externen Interrupts
>> Marke1/2 unterbrochen ist. Da der gepufferte Empfang intern andere
>> Routinen verwendet, funktioniert bei ausgeschalteten Interrupts auch der
>> normale ungepufferte Empfang über die Bascom-eigenen Routinen nicht
>> mehr.
>
> ich beginne allmählich zu ahnen, warum das mit dem config serialin nicht
> funktioniert.
>
> Kann es sein das es sich wohl schlicht mit der Tatsache, das ich ja
> einen Hardwareinterupt schon ausgelöst habe, beißt?
>
> Ralph Berres

Hallo Ralph,

Ich sah gerade diesen Thread. In solche Fällen hilft es oft einen HEX 
Terminal Daten Sniffer an der Serial Leitung dranzuhängen der alle 
Zeichenwerte anzeigen kann oder ein DSO mit RS232/SPI/I2C 
Zeichendekodierung. Viele moderne DSOs haben diese Feature.

Beim Debuggen des Programms hilft das ungemein da man dann die 
aktuellen, faktuale Informationen fangen kann und was da über die 
Leitungen geht. Das kann viel Zeit ersparen weil die ganze "Guess Work" 
wegfällt. Da sieht man dann auch nicht-ASCII Zeichen wie CR/LF und 
irgendwelche nicht ASCII darstellbare Steuerzeichen wie z.B bei 
MODBUS-RTU Protokol

Als Serial Sniffer eignen sich einige Terminal Programme (Real 
Terminal?) mit HEX Zeichen Ausgabe. Ein USB->RS232 Adapter wo dann der 
RX Eingang am Sendeteil mitangeschlossen wird. Dann kannst Du in einen 
Fenster alle gesendete Zeichen mitschneiden. Wenn Du ein zweites Fenster 
mit Serial Adapter an die andere Datenleitung anschliesst kannst Du 
Sende und Empfangsdaten komplett auzeichnen.

Bei Half-Duplex RS485 geht das noch besser weil man dann beide Seiten 
mit einer Schnittstellen Verbindung aufzeichnen kann.

Genau wie bei HF braucht man auch beim Programm Schmieden "Messgeräte". 
Sonst verschwendet man zu viel Zeit mit Vermutungen.

Viel Erfolg!


Gerhard

P.S.

Ist das der Zähler?

http://www.mino-elektronik.de/

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Heute Mittag treffe ich mich mal mit jemanden der auch versucht mit dem
> Bascom was zu machen. Er hat schon in C RS232 Schnittstellen auf dem
> Atmega programmiert, und ist eigentlich in Delphi zu Hause.

Wenn der Post des Users Mi N. (msx) zutrifft, dann sendet er LFCR. Dein 
letzter Code hatte Config Input auskommentiert, dann ist CR Standard.
Damit hast Du das LF im Empfangsstring mit drin und schickst es dann zum 
Display. Kann aber sein, dass es dort nicht schadet.

Wenn Du wissen willst wie etwas kommuniziert, brauchst Du doch bloß 
HTerm nehmen und im Empfangsfenster "Hex" zur Anzeige zuschalten. Dann 
siehst Du in welcher Reihenfolge CR und LF kommt.

> Zur Zeit kämpfe ich damit das beim Neutstart trotz Resetkondensator das
> Programm nur widerwillig starten will.

Abblockkondensator 100nF am Prozessor dran?
Versorgungsspannung sauber?
Massepotential einheitlich?

> aber das Logo wird
> mehrmals durchlaufen mit viel zu kurzer Verweilzeit.

Hört sich nach Reset an, wenn die Hardware ok ist, dann die Stacks 
vergrößern. Auch würde ich dazu raten, bei den externen Int0 und Int1 
die Pullups zu aktivieren

Beiläufig, hier verschwendest Du 32 Bytes SRam:
Dim Char_buffer1(16) As String * 1
Dim Char_buffer2(16) As String * 1
Ein String mit Länge 1 benötigt 2 Bytes, den Charakter selbst und das 
Stringendezeichen. Das geht genauso mit einem Bytearray.

> Heute Mittag treffe ich mich mal mit jemanden der auch versucht mit dem
> Bascom was zu machen.

"Versucht was zu machen" hört sich jetzt nicht so vertrauenerweckend an, 
"kennt sich aus" wäre besser.

Ralph B. schrieb:
> Kann es sein das es sich wohl schlicht mit der Tatsache, das ich ja
> einen Hardwareinterupt schon ausgelöst habe, beißt?

So ist es. Im Interrupt sind alle Interrupts, auch der des gepufferten 
UARTs gesperrt, es wird dabei das I-Flag im Statusregister SREG des 
Prozessors gelöscht und nach Abarbeiten des Interrupts wieder gesetzt.

Um also das gepufferte UART nutzen zu können, könntest Du:

a) in der ISR Interrupts wieder freigeben.
Brandgefährlich, weil dann alle Interrupts dazwischenfunken können. Da 
für einen Interrupt Register auf dem Stack gesichert werden, können 
diese sehr einfach überlaufen.

b) Alles in der Mainloop erledigen, viieeel besser normalerweise. 
Voraussetzung ist aber zu wissen wofür Int0/1 verwendet werden, d.h. 
muss da zeitkritisch darauf reagiert werden?

Wenn dort nur Taster für die Bedienung dran hängen ist es unkritisch, 
dann geht das locker. Ist die zeitnahe Rückmeldung und Auslösung des 
Messvorgangs erforderlich, dann müsste die Hauptschleife so gestaltet 
werden, dass dort nirgends rumgetrödelt wird. Gegen die unmittelbar 
nötige Reaktion steht, dass eigentlich nur etwas am Display angezeigt 
werden soll.

Ist Dir bekannt, dass man den externen Interrupteingang auch ohne 
Interrupt nutzen kann? Man verwendet dann nur das Interruptflag im GIFR.

Sollte es Dir also reichen, auf eine steigende Flanke am Int-Pin mit ein 
wenig Zeitverzögerung zu reagieren, dann könnte man das so machen:
GIFR.INTF0 = 1
Do
If GIFR.INTF0 = 1 Then
  Portd.6 = 0
    Pulseout Portd , 6 , 6000            'Triggerimpuls 150µs
      Input Serialstring_m1
' ...
  GIFR.INTF0 = 1
End If
' ...
Loop
Im Vergleich zum Pollen des betreffenden Pins merkt sich der Prozessor 
über das Flag, ob eine Flankenwechsel statt fand.

Autor: Mi N. (msx)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Als Serial Sniffer eignen sich einige Terminal Programme (Real
> Terminal?) mit HEX Zeichen Ausgabe.

Darauf verlassen kann man sich aber auch nur bedingt.
Hier findet sich ein .log-File der Datenausgabe: 
Beitrag "Re: DIY Frequency Counter mit 10 bis 12 Digits?"
Empfangen wurde mit "Terminal v1.9b by Br@y++".
Mit UltraEdit im hex-Modus angesehen steht dort als Abschluß die 
Zeichenfolge 0x0D 0x0A. Gesendet wurde definitiv anders herum ;-)

Was lernt man daraus? Einfach alle Steuerzeichen außer CR ignorieren!
Im Anhang ein ungeprüftes Beispiel, wie ich den 'Salat' einlesen würde.

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Was lernt man daraus? Einfach alle Steuerzeichen außer CR ignorieren!
> Im Anhang ein ungeprüftes Beispiel, wie ich den 'Salat' einlesen würde.

 Und was lernt man aus deinem Beispiel ?
 Genau - so soll man es nicht machen...

 Empfangsroutine ohne Längenprüfung ist was ?
 Genau - Mist...

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Darauf verlassen kann man sich aber auch nur bedingt.
> Hier findet sich ein .log-File der Datenausgabe:
> Beitrag "Re: DIY Frequency Counter mit 10 bis 12 Digits?"
> Empfangen wurde mit "Terminal v1.9b by Br@y++".
> Mit UltraEdit im hex-Modus angesehen steht dort als Abschluß die
> Zeichenfolge 0x0D 0x0A. Gesendet wurde definitiv anders herum ;-)

 LOL.

MWS schrieb:
> Wenn Du wissen willst wie etwas kommuniziert, brauchst Du doch bloß
> HTerm nehmen und im Empfangsfenster "Hex" zur Anzeige zuschalten. Dann
> siehst Du in welcher Reihenfolge CR und LF kommt.

 Genau.

 P.S.
 Etwa so wie in beiliegenden Screenshots.

: Bearbeitet durch User
Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Empfangsroutine ohne Längenprüfung ist was ?
> Genau - Mist...

Von Dir finde ich hier genau garnichts. Woran liegt das wohl?
Genau - nur dicke Backe.

Marc V. schrieb:
> Etwa so wie in beiliegenden Screenshots.

Was hat denn das mit dem Problem von Ralph zu tun?
Kommt gleich noch ein Foto von den Alpen?

Wird Zeit, daß wieder etwas Abkühlung kommt ;-)

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so ein Zwischenbericht

Ich war heute bei einen befreundeten Funkamateur der zumindest weit mehr 
Ahnung von Programmieren hat als ich.

Wir haben und Stück für Stück in Basic vorgearbeitet.

Lösungswege haben wir jetzt gefunden und wird die Tage in ein Programm 
umgesetzt.

Ich werde berichten sobald das Programm fertig ist und läuft.

Noch mal vielen Dank für die Hilfe und die vielen Tipps die ich hier 
bekommen hatte, und zumindestens für mein Kollege sehr hilfreich war.

Bis dann

Ralph Berres

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Von Dir finde ich hier genau garnichts. Woran liegt das wohl?
> Genau - nur dicke Backe.

 Weil MWS ihm alles ausreichend erklärt hat.
 Und du hättest dich mit deinen unnützen und falschen Beiträgen etwas
 zurückhalten können, wäre für alle viel besser gewesen.

Mi N. schrieb:
> Was hat denn das mit dem Problem von Ralph zu tun?
> Kommt gleich noch ein Foto von den Alpen?

 Ich sehe schon, du hast Schwierigkeiten zwischen .log files und
 RAW Ausgabe zu unterscheiden - lass es sein.

Mi N. schrieb:
> Mit UltraEdit im hex-Modus angesehen steht dort als Abschluß die
> Zeichenfolge 0x0D 0x0A. Gesendet wurde definitiv anders herum ;-)

 Eben.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Kommt gleich noch ein Foto von den Alpen?

Ein Screenshot des HTerm samt Hexanzeige kann dem TE durchaus nützlich 
sein, sofern er HTerm nicht kennt. Was wohl der Fall ist, sonst ätte er 
es längst genutzt.

Außerdem nimmst Du die Backen ein wenig voll für jemand, der in seiner 
Bedienungsanleitung falsch informiert und dann das noch schwach 
rechtfertigt:

> Als Abschluß werden 0x0A 0x0D ausgegeben, auch wenn sich als Begriff für
> einen Stringabschluß CR/LF 'eingebürgert' hat.

Mi N. schrieb:
> Was lernt man daraus? Einfach alle Steuerzeichen außer CR ignorieren!

Wenn Du glaubst ein CR reicht, warum packst Du dann ein LF dazu?

> Von Dir finde ich hier genau garnichts.

Die Kritik an Deinem Gebilde war zwar ein wenig harsch, andererseits 
wurde genau das Thema eines Stringüberlaufs in diesem Thread ein paar 
Posts vorher angesprochen. Dann einen Speicherüberlaufcode abzuliefern, 
zeigt: Thread nicht gelesen, aber vom eigenen Tun so überzeugt, dass man 
einen auf wichtig macht.

Da löst dann Dein faux pas mangelnder Längenprüfung zwingend den 
Antwortreflex aus.

Der TE holt, ob sinnvoll oder nicht, im Moment per Interrupt seine 
Daten. Sollte wider Erwarten dazu Notwendigkeit bestehen, warum denkst 
Du dass Dein dort nicht funktionierender Code Sinn macht?

Bzw. warum glaubst Du dass Dein Code besser ist als ein simples Input, 
welches noch dazu eine Längenprüfung der empfangenen Daten vornimmt, so 
dass nachfolgender Speicher eben nicht überschrieben wird?

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte Leute streitet euch nicht.

Es ist der Sache nicht einfach nicht wert.

Ralph Berres

Autor: BB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frust an Tag und Langweile am Abend findet man in diesem Forum wieder.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Bitte Leute streitet euch nicht.

Wir streiten nicht, wir diskutieren intensiv ;-)

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ist das der Zähler?
>
> http://www.mino-elektronik.de/

es ist dieser Zähler

nach oben
FMeter-407-TDC, 10 + 8 stellige Messungen/s

2017-10-17:
Im Gegensatz zur vorherigen Schaltung, wird hier ein einfaches LCD-Modul 
mit 2 x 16-> 4 x 20 zur Datenanzeige verwendet.

2018-07-01:
Es gibt eine Beschreibung im .pdf-Format des Moduls, die genauere 
Informationen enthält.

Ein affengeiles Teil.

Ralph Berres

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Gerhard O. schrieb:
>> Ist das der Zähler?
>>
>> http://www.mino-elektronik.de/
>
> es ist dieser Zähler
>
> nach oben
> FMeter-407-TDC, 10 + 8 stellige Messungen/s
>
> 2017-10-17:
> Im Gegensatz zur vorherigen Schaltung, wird hier ein einfaches LCD-Modul
> mit 2 x 16-> 4 x 20 zur Datenanzeige verwendet.
>
> 2018-07-01:
> Es gibt eine Beschreibung im .pdf-Format des Moduls, die genauere
> Informationen enthält.
>
> Ein affengeiles Teil.
>
> Ralph Berres

Danke. Das ist gut zu wissen. Der Zählerbaustein sieht sehr gut gelungen 
aus. Wünsche Dir viel Erfolg mit dem Program Fehlersuchen.

Ich schaute mir seine Webseite an. Sind die Sourcen für den Zähler auf 
Anfrage erhältlich? Das wäre für Anpassungen von Kleinigkeiten angenehm.

Falls noch von Interesse: Ich verwende für viele Frequenzzähler 
Aufzeichnungen schon viele Jahre einen uralten Philips PM6666 
Universalzähler+Rb87 Standard mit einer alten ISA NI IEEE-488 Karte und 
einen alten 486er Dolch Portable Computer mit einem selbstgestrickten 
kompilierten QB45 Logging Programm aus den 90er Jahren unter MSDOS. Das 
geht ganz ausgezeichnet. Die Daten werden in csv Format gespeichert. 
Beim PM6666 ist die Frequenzausgabe übrigens im Engineering Format mit 
Exponent und die Nummer der gesendeten Zeichen für das Messresultat ist 
immer gleichbleibend. Jedenfalls hatte ich mit QB45 überhaupt keine 
Schwierigkeiten mit dem Datenempfang. (Man kann auf den IEEE-488 Treiber 
als emulierten COM port zugreifen). Bei der NI Karten Einstellung kann 
man das Ende des Empfangs wie CR/Lf frei parametrisieren. Oft hänge ich 
zum Logging Programm noch ein HP34401A zur Temperaturmessung. Das ist 
bei Oszillator Temperatur Stabilitäts Messungen nützlich.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ich schaute mir seine Webseite an. Sind die Sourcen für den Zähler auf
> Anfrage erhältlich? Das wäre für Anpassungen von Kleinigkeiten angenehm.

Ich habe das nicht beim Michael angefragt. Ich könnte mir aber 
vorstellen, das er den Quellcode nicht offenlegen will.

Aber Michael kann sich ja selbst dazu äusern falls er hier mitliest.

Ralph Berres

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Gerhard O. schrieb:
>> Ich schaute mir seine Webseite an. Sind die Sourcen für den Zähler auf
>> Anfrage erhältlich? Das wäre für Anpassungen von Kleinigkeiten angenehm.
>
> Ich habe das nicht beim Michael angefragt. Ich könnte mir aber
> vorstellen, das er den Quellcode nicht offenlegen will.
>
> Aber Michael kann sich ja selbst dazu äusern falls er hier mitliest.
>
> Ralph Berres

Stimmt. Ich hätte im Prinzip auch Interesse an dem Teil. Macht ein 
schönes portables Meßinstrument.

Falls die Sourcen privat bleiben, dann kann man halt keine Änderungen 
wie  Z.B. ein anderes LCD verwenden zu wollen, das man vielleicht schon 
hätte verwenden können oder das Serial Protokol zu verändern. Aber das 
soll wirklich keine Kritik an Michael sein. Er ist ja großzügig bereit 
alles andere der Öffentlichkeit mitzuteilen.

Gerhard

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Falls die Sourcen privat bleiben, dann kann man halt keine Änderungen
> wie  Z.B. ein anderes LCD verwenden zu wollen, das man vielleicht schon
> hätte verwenden können oder das Serial Protokol zu verändern.

Hallo Gerhard

Ursprünglich hatte sein Zählermodul nur das normale LCD Display und 
keine Markenerzeugung.

Wie ich ihm erzählt habe welche Schwierigkeiten ich hatte, um 1KHz 
Frequenzmarken zu erzeugen, hat er sich sofort bereit erklärt mir 
probehalber eine geänderte Version nach meinen Wünschen zu erstellen, 
solange er die Software nicht grundlegend neu schreiben muss und keine 
Hardwareänderungen vornehmen muss, was eine neue Fertigung der 
Leiterplatte nach sich ziehen würde.

Ich habe das Modul bekommen , getestet, und als die für mich beste 
Lösung empfunden. Es hat mich komplett von der Problematik entbunden die 
Frequenzmarken für meinen Wobbler zu erzeuge.

Er hat mein sehr spezielles 2*16 Oled Display eingebunden, welches 
zufällig von den Abmessungen genau in meinen Wobbler passten ( das Modul 
gibt es nach wie vor bei Ebay für ca 30 Euro ), und er hatte die 
zusätzlichen Funktionen wie Markenbreite als Fernsteuerbefehle 
implementiert.

Mehr Entgegenkommen kann man wohl kaum erwarten.

Bei mir macht das Modul 1000 Messungen/Sek kontinuierlich um durch 
Vergleich mit internen Sollwerten an 4 Ports die Frequenzmarken 
auszugeben,
und zusätzlich noch durch einen externen Trigger ausgelöste Messungen, 
welche dann auf dem Display ausgegeben wird und per RS232 verschickt 
wird.

Bei der getriggerten Messung kann man die Messzeit getrennt von den 
kontinuierlichen Messungen einstellen. Also ideal für Schmalbandwobbler.



Wenn du spezielle Wünsche hast, würde ich ihn mal anrufen oder 
schreiben.

Ich bin von überzeugt, das er deine Wünsche berücksichtigen wird, sofern 
er es mit vertretbaren Aufwand kann.

Dieses Zählermodul ist bis dato das schnellste Modul was ich bisher frei 
erhältlich gesehen habe. Der Preis ist auch für diese Leistungen voll in 
Ordnung. Ich habe bei mir die schnellst mögliche Messzeit von 1 mSek 
eingestellt. Damit erhalte ich immerhin 7 gültige Stellen.

Es bietet ja zudem noch Funktionen welche ich garnicht nutze.

so jetzt habe ich genug Werbung gemacht.

Nur so am Rande, Ich bin mit Michael Novak weder verwandt noch 
verschwägert.
Auch bekomme ich keine Provisionen oder Erfolgsbeteiligungen für 
verkaufte Module. ( Ich schreibe das nur  um Verdachtsmomente von vorne 
herein aus dem Weg zu räumen).

Ralph Berres

Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Frag mal die Maus.

Alle wollen meine Programme mit mir 'teilen' aber keiner sein Geld ;-)

Warum essen wir heute Fisch? ...

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nnn

Ralph B. schrieb:
> Ursprünglich hatte sein Zählermodul nur das normale LCD Display und
> keine Markenerzeugung

Hallo Ralph,

Vielen Dank für den ausführlichen Kontext Deines Projekts. Das wird eine 
feine Sache und hoffe daß sich alle Probleme lösen lassen werden und 
wünsche Euch viel Erfolg. Es ist toll, daß Michael mit Dir 
zusammenarbeit. Ich nehme an, daß man dann eines Tages wie öfters schon 
in der Vergangenheit einen ausführliche Bericht irgendwo anders lesen 
kann:-)

Beim betagten HP8554/8444 half ich mir, wenn genaue Kenntnis gewisser 
Wobbelfrequenzen notwendig war, bis jetzt mit einem HP8640B, um über 
einen Koppler ein Signal miteinzuspeisen zu können um dann die genaue 
"Markenfrequenz" am HP8640 Display abzulesen. Das funktionierte ganz 
brauchbar. Man müßte sich überlegen ob man so einem System wie meinen 
auch was ähnliches machen könnte. Einblendbare Marken wären schon sehr 
angenehm.


Gruß,
Gerhard

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
>> Frag mal die Maus.
>
> Alle wollen meine Programme mit mir 'teilen' aber keiner sein Geld ;-)
>
> Warum essen wir heute Fisch? ...

Hallo Michael,

Das sitzt:-)

Da ich selber sehr gerne eigene uC Projekte mache, ist es natürlich sehr 
angenehm eigene SW/HW Anpassungen vornehmen zu können. Andrerseits 
verstehe ich auch voll Deinen Standpunkt. So ein Projekt wie Dein 
Frequenz Zähler schüttelt man nicht so einfach aus dem Ärmel und es 
steckt in der Entwicklung beträchtlicher Einsatz und Zeit dahinter. Es 
ist natürlich gut zu wissen, daß es im Notfall eine 
Verständigungsmöglichkeit geben würde. Aber wie schon vorher erwähnt, 
war es keinesfalls meine Absicht in irgendeiner Weise Kritik zu üben.


Gruß,
Gerhard

: Bearbeitet durch User
Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Aber wie schon vorher erwähnt,
> war es keinesfalls meine Absicht in irgendeiner Weise Kritik zu üben.

Was Du geschrieben hast, verstehe ich doch nicht als Kritik. Ich lese ja 
immer gerne, was ein Rentner aus Kanada zu berichten hat, auch wenn er 
teilweise seine Beiträge (leider) wieder löscht ;-)

Ralph B. schrieb:
> Ich war heute bei einen befreundeten Funkamateur der zumindest weit mehr
> Ahnung von Programmieren hat als ich.
>
> Wir haben und Stück für Stück in Basic vorgearbeitet.
>
> Lösungswege haben wir jetzt gefunden und wird die Tage in ein Programm
> umgesetzt.

Für das Endergebnis bin ich da sehr optimistisch! Auch gut, daß Dein 
Kollege vor Ort auf Deine Hardware zugreifen und sofort testen kann. Aus 
der Ferne ist alles viel mühsamer zu erkennen.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Gerhard O. schrieb:
>> Aber wie schon vorher erwähnt,
Wieder ein heißer Tag bei uns. Gestern waren es 35 Grad.
>> war es keinesfalls meine Absicht in irgendeiner Weise Kritik zu üben.
>
> Was Du geschrieben hast, verstehe ich doch nicht als Kritik. Ich lese ja
> immer gerne, was ein Rentner aus Kanada zu berichten hat, auch wenn er
> teilweise seine Beiträge (leider) wieder löscht ;-)
Rentner bin ich noch nicht. Ich stecke immer noch in der HW/SW 
Entwicklung im Betrieb und stricke industrielle Elektronik. Bezüglich 
der gelöschten Beiträge habe ich dann ab und zu dann doch beim 
wiederholten Lesen etwas Gewissensbisse und dann denke ich mir, besser 
nicht immer Öl ins Feuer zu schütten...
>
> Ralph B. schrieb:
>> Ich war heute bei einen befreundeten Funkamateur der zumindest weit mehr
>> Ahnung von Programmieren hat als ich.
>>
>> Wir haben und Stück für Stück in Basic vorgearbeitet.
>>
>> Lösungswege haben wir jetzt gefunden und wird die Tage in ein Programm
>> umgesetzt.
>
> Für das Endergebnis bin ich da sehr optimistisch! Auch gut, daß Dein
> Kollege vor Ort auf Deine Hardware zugreifen und sofort testen kann. Aus
> der Ferne ist alles viel mühsamer zu erkennen.


.

: Bearbeitet durch User
Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Man müßte sich überlegen ob man so einem System wie meinen
> auch was ähnliches machen könnte. Einblendbare Marken wären schon sehr
> angenehm.

hallo Gerhard

Das Novak Modul ( ich nenne es mal so ) kann aber nur eine 
Wobbelgeschwindigkeit von 1-2 Durchgänge / Sekunde.

Es liefert auch núr die Marken 1KHz 10KHz 100KHz und 1MHz

Für Schmalbandwobbeln ( wofür ich genau diese Marken benötige ) ist die 
Wobbelgeschwindigkeit ausreichend, weil die zu wobbelnde Filter auch 
schon Zeit zum Einschwingen benötigt.

Ich vermute mal das der HP8554 ( war das nicht ein Spektrumanalyzer? 
wozu benötigt der Marken? oder dient der HP8444 als Trackinggenerator?) 
ohnehin nur für Breitbandwobbeln geeigenet war.

In dem Swob5 sitzt von Haus aus ein eigener Markengeber, der die 1MHz 
10MHz und 100MHz Marken mit Hilfe von Schwebungsmarken erzeugt.
Das macht er mit Hilfe von aus einer Quarzfrequenz hergeleiteten 
Nadelimpulsen mit einer Frequenz welcher der Markenfrequenz entspricht.

Die Oberwellen der Nadelimpulse welche bis 1,5GHz reichen wird dann mit 
der Wobbelfrequenz gemischt.

Bis 1MHz Marken funktioniert das auch recht zuverlässig. Kleinere Marken 
lassen sich so aber kaum noch erzeugen, weil der Energiegehalt der 
einzelne Marke zu klein wird.

Und genau hier ist das Novakmodul zum Einsatz gekommen.

Ob die komplette Erweiterung des Swob5 für die UKW-Berichte interessant 
genug ist das zu veröffentlichen, entscheide ja nicht ich, sondern der 
Verlag.

Momentan schlage ich mich mit dem Problem rum, das der Atmaga8 nach dem 
Einschalten immer erst 2 mal hintereinander einen mehrere 100ms langen 
Reset am Eingang haben will, ehe er startet, wobei er dann beim Start 
das Logo am Anfang entweder viel zu kurz anzeigt, oder gleich 
überspringt.

Sehr merkwürdig das ganze. Am Reseteingang, welche über 10Kohm an +5V 
hängt habe ich schon einen 0,1uF gegen Masse geschaltet. Auch habe ich 
schon 10uF oder 100uF versucht. Ist im völlig egal.

Aber wenn ich mit dem Pr0grammer über isp einProgramm lade dann startet 
er nach dem Laden des Programmes sofort.

Verstehe wer will.

Aber vielleicht liegt es ja an der Software. Die neue Software ist zur 
Zeit in Arbeit, und bekomme sie wohl die Tage. Ich bin gespannt ob diese 
besser arbeitet.

Ralph Berres

Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Sehr merkwürdig das ganze. Am Reseteingang, welche über 10Kohm an +5V
> hängt habe ich schon einen 0,1uF gegen Masse geschaltet. Auch habe ich
> schon 10uF oder 100uF versucht. Ist im völlig egal.

Laß bitte die Kondensatoren ganz weg und verwende, wenn eh schon 
vorgesehen, einen Pullup-Widerstand von 3k3. Damit ist der Reset-Eingang 
niederohmig genug gegen äußere Störungen geschützt.
Wichtig ist, den Brown-Out-Detector zu aktivieren und auf 4 V 
einzustellen. Liefert das Netzteil nicht eine sehr langsam ansteigende 5 
V Versorgung?

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Laß bitte die Kondensatoren ganz weg und verwende, wenn eh schon
> vorgesehen, einen Pullup-Widerstand von 3k3.

OK das könnte ich ändern

Mi N. schrieb:
> Wichtig ist, den Brown-Out-Detector zu aktivieren und auf 4 V
> einzustellen.

was ist das? und wo stellt man den ein?

Mi N. schrieb:
> Liefert das Netzteil nicht eine sehr langsam ansteigende 5
> V Versorgung?

Ja , aber ich habe in der Stromversorgung der Mikroprozessoren ein 
Relais in Reihe , welcher erst bei ca 4V anzieht, und die 
Stromversorgung zum Prozessor frei gibt.

Dazu habe ich einfach die Relaisspule über eine Zenerdiode an die +5V 
gelegt.

OK das hätte man sicher uach eleganter machen können. Aber ich wollte 
auf der Basisplatine so wenig wie möglich zusätzliche Bauteile 
nachträglich ergänzen.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Relais in Reihe , welcher erst bei ca 4V anzieht, und die
> Stromversorgung zum Prozessor frei gibt.

Mit lustigem Kontaktprellen, bei dem es dem Prozessor schlecht wird.

Brownout wir über die Fuses eingestellt, Hilfe dazu findet sich 
allerorts nach kurzer Suche, ist je nach verwendetem Programmer und 
Bediensoftware unterschiedlich. Verwendest Du dazu Bascom, dann gibt's 
beim Programmierdialog auch die Einstellung Fuses.

Aufpassen, über die Fuses kannst Du den Prozessor stilllegen oder Dich 
aussperren.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Mit lustigem Kontaktprellen, bei dem es dem Prozessor schlecht wird.

Naja Die Betriebsspannung des Prozessors wird noch mit einen 220uF Elco 
gepuffert.

MWS schrieb:
> Verwendest Du dazu Bascom, dann gibt's
> beim Programmierdialog auch die Einstellung Fuses.

Ich habe mir mal gerade das Datenblatt des Atmega8 angeschaut. Da 
scheint es tatsächlich sowas zu geben.

das muss ich mir heute Mittag mal anschauen., vor allen welches Fuses 
man da setzen muss, wo man die Zeit des Resetimpulses einstellt, und wo 
man die Spannungen Vbot- und Vbot+ einstellt.

Ich weis garnicht ob das von Bascom aus geht.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Naja Die Betriebsspannung des Prozessors wird noch mit einen 220uF Elco
> gepuffert.

Merkwürdiger Aufbau, ein Relais für schnellen Spannungsanstieg und dann 
wieder ein Elko um's zu verlangsamen. Wären solche Winkelzüge 
tatsächlich notwendig, würde wohl keines der überall verfügbaren 
Arduino-Module funktionieren können.

Hier kannst Du mal schauen, was es einzustellen gibt, ohne dass Du 
gleich den Prozessor schredderst:

http://www.engbedded.com/fusecalc

Auch bei den Clock-Settings kann man optimieren, vorteilhaft ist eine 
lange Startuptime und da's hier nicht um Stromsparen geht, ist das 
Setzen der CKOPT-Fuse sinnvoll. Damit läuft der Quarzoszillator 
full-rail, stabiler, aber die Stromaufnahme ist höher.

Also Ext. Crystal/Resonator, 16k CK, 64ms (im DB mit 65ms bezeichnet)

Aufpassen I: Gesetzte Fuses haben den Level 0, ungesetzte 1, hängt von 
der Programmersoftware ab, wie's dort dargestellt ist.

Aufpassen II: Änderst Du die Fuses auf Ext.Clock, oder einer andere 
nicht zum Quarz passende Einstellung, dann ist der Prozessor mit Quarz 
erstmal lahmgelegt.

> Ich weis garnicht ob das von Bascom aus geht.

Klar geht das solange es ein kompatibler Programmer ist. Wenn Du jetzt 
bereits aus Bascom heraus flashst, dann kannst Du auch die Fuses 
einstellen.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Merkwürdiger Aufbau, ein Relais für schnellen Spannungsanstieg und dann
> wieder ein Elko um's zu verlangsamen.

naja das 5V Netzteil vom Swob braucht ca 500ms bis er die 5V aufgebaut 
hat, ist aber geregelt und niederohmig.

Ich schalte dann erst mit einen Relais die Stromversorgung ein, wenn 
wenigstens 4V erreicht sind. Der 220uF Elco wird dann in Bruchteile von 
einer Sekunde auf die 4V aufgeladen.

das mit den fusebits muss ich mir mal anschauen.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> naja das 5V Netzteil vom Swob braucht ca 500ms bis er die 5V aufgebaut
> hat, ist aber geregelt und niederohmig.

Diese Konstruktion sollte mit Brownout auf 4V, CKOPT und langer 
Startup-Zeit nicht mehr notwendig sein.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> ... ich vermute mal das der HP8554 ( war das nicht ein Spektrumanalyzer?
> wozu benötigt der Marken? oder dient der HP8444 als Trackinggenerator?)
> ohnehin nur für Breitbandwobbeln geeigenet war...

Hallo,

Danke für die Informationen. Ja. Bei mir geht es um den HP8443/4 und 
HP8553/4. Markenerzeugung dürfte hier einige Arbeiten auch im Mainframe 
machen. Bis jetzt konnte ich mir ganz gut mit dem HP8640B als 
Markemmesssender klarkommen wenn ich die genaue Frequenz wirklich wissen 
muss. Der 8640 hat ja einen Frequenzzähler zur Anzeige fest eingebaut. 
Ehrlich gesagt lasse ich die Geräte lieber im Originalzustand.

Die Kombination 8444/8554 ist mit PLL Lock für Quarzfilter wobbeln noch 
gut genug. Sonst ist der 8553/8443 hier günstiger.

Nicht zum Thema passend hätte ich da eher Ambitionen mir einen zweiten 
8554 zu besorgen und die Mischer und Verstärkerzüge bis zu 50Mhz 
herrunter mit moderneren Mischern zu ersetzen um den 
intermodulationsfreien Dynamikbereich zu verbessern. Aber das ist ein 
anderes Thema.

Jedenfalls hoffe ich, daß sich die Probleme bei Euch nach und nach 
bewältigen lassen. Mir ist vom Swob V nichts bekannt. Ich kann mich nur 
an die uralten 400Mhz Polyskope bei Kathrein erinnern wo praktisch in 
jeder Ecke einer rumstand. Die hatten eine grosse 20cm weissbläulich 
Bildschirmanzeige. Mit denen arbeitete ich damals ab und zu. Die hatten 
noch keine logarithmische Anzeige und hatten auch noch die großen 
Dezifix Anschlüsse. Ein viel moderneren Swob sah ich bei Körting. Hier 
in Kanada sind diese Geräte vollkommen unbekannt. Die Geräte waren 
allesamt sauschwer:-)

Schönes Wochenende noch,
Gerhard

: Bearbeitet durch User
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nnnn

Ralph B. schrieb:
> momentan schlage ich mich mit dem Problem rum, das der Atmaga8 nach dem
> Einschalten immer erst 2 mal hintereinander einen mehrere 100ms langen
> Reset am Eingang haben will, ehe er startet, wobei er dann beim Start
> das Logo am Anfang entweder viel zu kurz anzeigt, oder gleich
> überspringt.

Versuche mal den RESET Eingang beim Einschalten auf Masse zu legen und 
dann nach einer Sekunde manuell freigeben. Ob er sich dann noch genauso 
verhält?

Einen MCP120-4.5 Supervisor könnte man notfalls auch mal versuchen. Der 
BOD sollte sonst auch wie MWS vorgeschlagen hat, aktiviert und 
eingestellt werden.

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Versuche mal den RESET Eingang beim Einschalten auf Masse zu legen und
> dann nach einer Sekunde manuell freigeben. Ob er sich dann noch genauso
> verhält?
>
> Einen MCP120-4.5 Supervisor könnte man notfalls auch mal versuchen. Der
> BOD sollte sonst auch wie MWS vorgeschlagen hat, aktiviert und
> eingestellt werden.

Warum sollte man solche Verrenkungen machen, wenn offenbar die 
AVR-internen Möglichkeiten noch nicht genutzt werden?

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Gerhard O. schrieb:
>> Versuche mal den RESET Eingang beim Einschalten auf Masse zu legen und
>> dann nach einer Sekunde manuell freigeben. Ob er sich dann noch genauso
>> verhält?
>>
>> Einen MCP120-4.5 Supervisor könnte man notfalls auch mal versuchen. Der
>> BOD sollte sonst auch wie MWS vorgeschlagen hat, aktiviert und
>> eingestellt werden.
>
> Warum sollte man solche Verrenkungen machen, wenn offenbar die
> AVR-internen Möglichkeiten noch nicht genutzt werden?

Das ist schon klar; ist aber trotzdem einen Versuch wert.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> wie MWS vorgeschlagen hat,

Das war zuerst hier vorgeschlagen:

Mi N. schrieb:
> Wichtig ist, den Brown-Out-Detector zu aktivieren und auf 4 V

Nur fand's noch kein Gehör.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Mir ist vom Swob V nichts bekannt. Ich kann mich nur
> an die uralten 400Mhz Polyskope

Den hatte ich Anfangs auch es war der Polyskop1. Den hatte ich damals 
getunt, das er bis 450MHz ging um wenigstens das 70cm Band noch mit drin 
zu haben.

Wenig später kam der Swob2. Das war der Swob1 mit zusätzlichen UHF Teil.
Der ging von 400-1200 MHz den habe ich bis 1300MHz getunt und mit einen 
swep getriggerten Frequenzzähler ausgestattet, welcher auch in den UKW 
Berichten veröffentlicht wurde.

Der Swob2 konnte den Strahl aber nicht anhalten, so das nur eine 
Auflösung von 1MHz möglich war.
Aber auch er konnte nicht logarythmisch anzeigen.

Den Swob3 hatte ich auch mal. Ein Scheißteil sage ich dir.

Den Swob4 habe ich übersprungen. Der Swob5 hat übrigens eine 
Fernsehbildröhre   mit 28cm Bildschirmdiagonale.

Ralph Berres

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Gerhard O. schrieb:
>> wie MWS vorgeschlagen hat,
>
> Das war zuerst hier vorgeschlagen:
>
> Mi N. schrieb:
>> Wichtig ist, den Brown-Out-Detector zu aktivieren und auf 4 V
>
> Nur fand's noch kein Gehör.

Lass ihm doch etwas Zeit:-)

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Versuche mal den RESET Eingang beim Einschalten auf Masse zu legen und
> dann nach einer Sekunde manuell freigeben. Ob er sich dann noch genauso
> verhält?

Das hatte ich versucht, aber er will erst nach dem Einschalten ein Reset 
sehen.

Aber ich versuche das mit den Fusebits mal.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Das hatte ich versucht, aber er will erst nach dem Einschalten ein Reset
> sehen.

Der braucht nach dem Einschalten gar keinen Reset. Ich würde vermuten, 
dass der Quarzoszillator nicht anschwingt. Du bist doch viel mehr HFler 
als uCler, tipp doch mal mit einer Oszi-Messpitze an die Quarzpins, bzw. 
schau Dir an, ob dort was tut.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> CKOPT und langer
> Startup-Zeit nicht mehr notwendig sein.

bei welchen Fusebits stellt man ckopt und lange Startzeit ein?

den Brown Out Detektor habe ich auf 4V eingestellt und enablet, das 
hatte aber keine Auswirkung.

Ralph Berres

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CKopt stand bei mir auf 1

Ralph Berres

Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> CKopt stand bei mir auf 1

Das bedeutet, das diese Option nicht aktiviert ist. Und genau dies kann 
dazu führen, daß der Oszillator nicht richtig schwingt.
Also: CKOPT auf 0 setzen!

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> den Brown Out Detektor habe ich auf 4V eingestellt und enablet, das
> hatte aber keine Auswirkung.

Welche Programmer-GUI verwendest Du?

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bascom avr Version 2.0.7.8.001

als Programmieradapter den Diamex AVR ist so ein Grüner USB-Stick mit 
einen 6poligen Programmierkabel dran.

Ich habe mal gerade mit dem scope getestet. Der Quarz schwingt sauber 
an.

er benötigt 500us bis zu seiner vollen Amplitude. Das erachte ich für 
einen 14MHz Quarz eigentlich als normal.

Ralph Berres

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> als Programmieradapter den Diamex AVR ist so ein Grüner USB-Stick mit
> einen 6poligen Programmierkabel dran.

Beachte dass bei Verwendung der Bascom Programmer-GUI die entsprechenden 
putzigen kleinen Buttons rechts, auf denen "Write FS" & "Write FSH" 
steht, geklickt werden müssen:
Beitrag "Re: BASCOM ATTiny2313 + fuses?"
Denn sonst kannst Du im Fenster links soviel einstellen wie Du willst, 
es wird ignoriert.

Ob Deine Einstellungen übernommen wurden, siehst Du mit Klick auf 
"Refresh", kommt nach dem Refresh nur ein Fehler oder ein leeres 
Fenster, dann hast Du Dir den Prozessor gebrickt ;D

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Ich habe mal gerade mit dem scope getestet. Der Quarz schwingt sauber
> an.

Wenn er schwingt, startet dann das Programm?

Manchmal schwingt HF auch nur dann, wenn sie gemessen wird.

Ein einfaches Debugging besteht darin, dass man an unterschiedlichen 
Stellen im Code, einmal ganz zu Anfang, eine Led unterschiedlich oft 
blinken lässt. Daraus lässt sich schließen, ob und wann der Controller 
aussteigt.

Du erwähntest das Display zeigt den Startscreen schnell hintereinander 
an, also lässt man davor dem Anzeigeblock 3x blinken und danach 5x.

Dass der Controller nicht startet, nimmst Du doch nur an, es könnte doch 
genauso sein, dass das Display zickt und dunkel bleibt. Kannst Du das 
von einem "nicht starten" unterscheiden? Kannst Du ein Displayflackern 
vom Neustart unterscheiden?

Mit Led blinken lassen kannst Du's.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die vier Felder write LB, FS, FSH und FSE sind bei mir grau hinterlegt.

ein Refresch erzeugt bei mir keine Fehlermeldung.

Und wenn ich die Fusebits neu aufrufe scheinen die Fusebits übernommen 
worden zu sein.

Gibt es hier noch Fallstricke?

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Und wenn ich die Fusebits neu aufrufe scheinen die Fusebits übernommen
> worden zu sein.

Nach einem Refresh werden die neuen Fuse-Einstellungen angezeigt?

Beende mal den Programmerdialog, starte ihn neu, wähle dann den 
Fusebits-Reiter aus und kontrolliere nochmal.

Ralph B. schrieb:
> die vier Felder write LB, FS, FSH und FSE sind bei mir grau hinterlegt.

Zumindest nach einer Änderung links in der Liste der Fuses sollte das 
Grau verschwinden.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> es könnte doch
> genauso sein, dass das Display zickt und dunkel bleibt.

hmm könntest recht haben.

ich werde mal an einen noch freien Pin ein Speicherscope im Singleshot 
hängen und schauen ob bei aufruf des Logos  ein Impuls kommt.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so mit der Ursache des Startproblemes bin ich eine Erkenntnis weiter 
gekommen.

Ich habe ganz zu Anfang des Programmes folgende Zeile eingegeben

Config Portb.0 = Output
Portb.0 = 0

und an den Portb.0 einen Scope angeschlossen.

Dann habe ich mich mit dem Eintrag Portb.0 = 1 Stück für Stück in dem 
Programm vorgearbeitet.

An der Stelle

Interupt:
Enable Interrupts


On Int0 Marke1                          'Bei Interrupt springe zu Marke1
Enable Int0                             'Enable Interrupt 0
'Portb.0 = 1
Config Int0 = Rising                    'Interrupt bei ansteigender 
Flanke
Portb.0 = 1

On Int1 Marke2                          'Bei Interrupt springe zu Marke2
Enable Int1                             'Enable Interrupt 1
Config Int1 = Rising                    'Interrupt bei ansteigender 
Flanke

Goto Start

kam kein Signal mehr aus dem Portb.0

habe ich aber die Zeile vor dem Config Int0 = Rising  aktiviert, kam der 
Impuls.

Das heist beim Starten hängt er genau hier.

überspringe ich die Interuptroutine so wird Portb.0 direkt am Anfang von 
logo aktiviert allerdings erscheint nach jedem Start dann abwechelnd nur 
swob5 für 5 Sekunden und mal das komplette Logo für 5 Sekunden.

Also noch ein zweiter Fehler.

Ralph Berres
und dann

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Das heist beim Starten hängt er genau hier.

Das liegt daran, dass er vor dem Rising auf Default = Level steht und 
dann bei Level Low laufend den Interrupt auslöst. Schreib' Enable 
Interrupts ganz zum Schluss und lösche vorher beide Interruptflags, 
indem Du eine 1 in's jeweilige Flag schreibst.

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
MWS schrieb:
> indem Du eine 1 in's jeweilige Flag schreibst.

GIFR = Bits(INTF1, INTF0)

MWS schrieb:
> ganz zum Schluss

ganz zum Schluss des Konfigurationsblocks

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe das jetzt so geändert.
'Goto Start
'----------------------- Interrupts erlauben 
---------------------------------
Interupt:
'Portb.0 = 1
'Enable Interrupts
Config Int0 = Rising                    'Interrupt bei ansteigender 
Flanke
Config Int1 = Rising                    'Interrupt bei ansteigender 
Flanke
Enable Interrupts
On Int0 Marke1                          'Bei Interrupt springe zu Marke1
Enable Int0                             'Enable Interrupt 0
'Config Int0 = Rising                    'Interrupt bei ansteigender 
Flanke
'Portb.0 = 1

On Int1 Marke2                          'Bei Interrupt springe zu Marke2
Enable Int1                             'Enable Interrupt 1
'Config Int1 = Rising                    'Interrupt bei ansteigender 
Flanke
'Enable Interrupt
Goto Start

jetzt läuft er beim Start bis zum logo

und da erscheint auch
Rohde&Schwarz
Swob5
aber da wo wait 5 steht bleibt er hängen.

'---------------------------Logo anzeigen 
------------------------------------
Logo:
'Portb.0 = 1

Oled_col = 1                            'Zeile = 1
Oled_row = 1                            'Position = 1
Gosub Oled_position
Datensatz1 = Blank16                    'Zeile Löschen
Call Oled_zeile1


Oled_col = 1                            'Zeile = 1
Oled_row = 1                            'Position = 1
Gosub Oled_position
Datensatz1 = Rohde&Schwarz
Call Oled_zeile1


Oled_col = 2                            'Zeile = 2
Oled_row = 1                            'Position = 1
Gosub Oled_position
Datensatz2 = Blank16                    'Zeile Löschen
Call Oled_zeile2

Oled_col = 2                            'Zeile = 2
Oled_row = 1                            'Position = 1
Gosub Oled_position
Datensatz2 = Swob5
Call Oled_zeile2
Portb.0 = 1
Wait 5
Portb.0 = 0

Oled_col = 1                            'Zeile = 1
Oled_row = 1                            'Position = 1
Gosub Oled_position
Datensatz1 = Blank16                    'Zeile Löschen
Call Oled_zeile1

Oled_col = 2                            'Zeile = 2
Oled_row = 1                            'Position = 1
Gosub Oled_position
Datensatz2 = Blank16                    'Zeile Löschen
Call Oled_zeile2

Goto Beginn

er schaltet vor dem wait5 den Portb.0 auf 1 aber nach dem Wait 5 nicht 
mehr auf 0 und das Programm bleibt hier hängen.

Das heist den Wait5 interessiert ihn nicht. wenn ich das wait 
auskommentiere kommt am Port ein Nadelimpuls und das Display bleibt 
schwarz

setze ich den portb0 vor goto beginn dann dauert der impuls etwa 15ms.

warum geht der wait 5 nicht?

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> warum geht der wait 5 nicht?

Das Problem ist, dass a) Dir Programmieren und hier auch Debuggen schwer 
fällt und Du nach Hilfe suchst, Du aber b) sehr kreativ mit den 
gegebenen Ratschlägen umgehst und zwar soweit, dass a) eigentlich gar 
nicht der Fall sein dürfte. Gleichwohl erwartest Du vom Gegenüber aus 
Kaffeesatz lesen zu können und vergisst wieder und wieder sinnvolle 
Ratschläge.

Beispiel: Ich schreib' Dir, dass Du die Interruptflags löschen sollst, 
das ist Dir aber wurscht. Es bedeutet nicht, dass dies nun alles 
richtet, aber dennoch meinst Du soviel zu wissen, dass Du das ignorieren 
kannst. Was ich Dir mit $TIMEOUT schrieb - auch schon längst vergessen.

Da kommt das zum Tragen, was ich einmal mit "träger Reaktion" 
umschrieben hab. Es ist wirklich ein Riesenunterschied jemanden 
gegenüber zu haben, der sich da programmtechnish reindenken kann und 
nimm's mir nicht übel, das ist nicht Deine Stärke.

Nun zum Kaffeesatz: Das Problem Deines interruptgetriebenen Codes ist, 
dass keine Sicherheitsmechanismen eingebaut sind. Sobald eine Flanke an 
den Interrupteingängen auftaucht, rennt der uC dort hin und wartet bis 
über's UART was reinkommt. Kommt nichts rein, dann Ende. Der externe 
Interrupt ist dafür gedacht empfindlich und schnell zu reagieren, der 
vergibt nichts, damit wird's zu einer Hardwaregeschichte.

Du müsstest also überwachen, ob auf den Leitungen zu Int0/1 irgendwas 
rum-spiked. Geschrieben hast Du übrigens immer noch nicht, wo die 
Signale dazu herkommen, was Du sinnvollerweise schon längst getan haben 
solltest.

Hier hätte Dir das bereits empfohlene $TIMEOUT geholfen, zusammen mit 
einer Prüfung der empfangenen, bzw. nicht vorhandenen Daten.

Im Moment sieht es also so aus, als ob ein Interrupt während des Wait 5 
dazwischenschiesst.

Einfache Prüfung: Schieb' Enable Interrupts weiter nach hinten, nach 
Wait 5 und schau' was passiert. Wenn die angenommenen Spikes nur beim 
Start auftreten, dann hilft ein möglichst spätes Erlauben der Interrupts 
mit vorherigem Löschen der Interruptflags.
Wie das geht hab' ich bereits geschrieben...

Autor: Ralph B. (rberres)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
hallo MWS

MWS schrieb:
> Das Problem ist, dass a) Dir Programmieren und hier auch Debuggen schwer
> fällt und Du nach Hilfe suchst,

das ist leider wahr. Da habe ich mich schon immer extremst schwer getan.
Entwerfen von TTL Gräber fällt mir sehr viel leichter.

MWS schrieb:
> Du aber b) sehr kreativ mit den
> gegebenen Ratschlägen umgehst und zwar soweit, dass a) eigentlich gar
> nicht der Fall sein dürfte.

Besten Dank für die Blumen. Das ist aber ein Akt der Verzweiflung und 
weniger auf Wissen begründet.

MWS schrieb:
> Beispiel: Ich schreib' Dir, dass Du die Interruptflags löschen sollst,
> das ist Dir aber wurscht.

Nein Wurscht ist es mir nicht. Nur ich habe es nicht kapiert wie man es 
umsetzt.

MWS schrieb:
> aber dennoch meinst Du soviel zu wissen, dass Du das ignorieren
> kannst.

weniger sus wissen als das ich noch nicht weis wie man es umsetzt.

MWS schrieb:
> Es ist wirklich ein Riesenunterschied jemanden
> gegenüber zu haben, der sich da programmtechnish reindenken kann und
> nimm's mir nicht übel, das ist nicht Deine Stärke.

das gebe ich umunwunden zu. Ich lerne auch nicht sonderlich schnell.

Ich habe versucht das interupt Enable ganz zum schluss des 
Interuptblocks zu setzen, da bekam ich aber immer eine Fehlermeldung 
beim compilieren.

Warauf ich dann versucht habe wenigstens die Anweisung das die 
ansteigende Flanke ausgewertet werden soll vor das Interupt Enable zu 
setzen.

wenn ich weitere Anweisungen noch vor dem Internetenable gesetzt habe 
dann bekam ich wieder Fehlermeldungen beim compilieren.

Immerhin war nach der Änderung das Programm bis zur Routine Logo 
anzeigen weiter gelaufen.

MWS schrieb:
> Geschrieben hast Du übrigens immer noch nicht, wo die
> Signale dazu herkommen, was Du sinnvollerweise schon längst getan haben
> solltest.

ok das habe ich noch nicht erwähnt.

Es handelt sich um einen Wobbler der ryhtmisch die Frequenz von 
niedrigen nach hohen Frequenzen durchstimmt, und gleichzeitig eine 
Strahl eines Oszillografen auf der X-Achse synchron von links nach 
rechts bewegt.

Der Wobbler besitzt die Möglichkeit an zwei Stellen auf der X-Achse 
welche den Strahl für einige Milisekunden anzuhalten, und einen 
Triggerimpuls abzugeben. Und zwar für jede Stelle getrennt. So gesehen 
sind es zwei verschiebbare Frequenzmarken. Diese Triggerimpulse gehen 
auf die Eingänge Int0 und Int1.
Wenn der Eingang Int0 ein Trigger anliegt, dann wird augenblicklich an 
einen Ausgang ein Triggerimpuls abgegeben welcher den Zähler vom Michel 
Novak veranlasst die Frequenz innerhalb einer Milisekunde zu messen und 
als RS232 Telegramm dem Atmega8 zu senden.

Abhängig davon ob Int0 für die linke Marke oder int1 für die rechte 
Marke getriggert wird , soll der Prozessor die empfangene 
Frequenznachricht via RS232 in die obere Zeile bzw in die untere Zeil 
eschreiben.

Man könnte jetzt darüber streiten ob das so zeitkritisch ist, das man 
ein Interupt benötigt.

Die Erfassung der Frequenz hat aber oberste Priorität und es darf keine 
Marke verpasst werden.

Nebenbei werden noch zwei Potis abgefragt dessen ADC-Wert via RS232 dem 
Novak Zähler übermittelt werden soll.

Dies kann und soll bei Eintreffen eines Triggerimpulses unterbrochen 
werden.

Aber was ich ich jetzt parallel selbst unternehme liegt daran das ich 
mich an ein Problem gerne festbeisse, was nicht immer der richtige Weg 
sein muss.

Vermutlich wenn mein Freund ( der ja auch nicht immer Zeit hat ) das 
Programm überarbeitet hat  wird es vermutlich so laufen wie ich es mir 
vorstelle.

Aber immerhin konnte ich mit der Aktion beweisen das es kein 
Resetproblem des Prozesssors ist, sondern ein Softwareproblem.

Glaube mir anders wäre es mir lieber gewesen.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Nur ich habe es nicht kapiert wie man es umsetzt.

Was verstehst Du hiervon nicht? Hab's doch schon vorgekaut.

MWS schrieb:
> Schreib' Enable
> Interrupts ganz zum Schluss und lösche vorher beide Interruptflags,
> indem Du eine 1 in's jeweilige Flag schreibst.

MWS schrieb:
>> indem Du eine 1 in's jeweilige Flag schreibst.
>
> GIFR = Bits(INTF1, INTF0)

Ralph B. schrieb:
> weis wie man es umsetzt

Wenn Dir das schon jemand exakt hinschreibt? Brauchst doch im Zweifel 
nur noch den Cursor in Bascom drüber platzieren und die Hilfe aufrufen.

MWS schrieb:
> $TIMEOUT = 1000000   ' verschiedene Werte selber testen

Ralph B. schrieb:
> wenn ich weitere Anweisungen noch vor dem Internetenable gesetzt habe
> dann bekam ich wieder Fehlermeldungen beim compilieren.

Enable Interrupts gehört in so einem Fall unmittelbar vor die 
Hauptschleife aus Do/Loop.

Ralph B. schrieb:
> Aber immerhin konnte ich mit der Aktion beweisen das es kein
> Resetproblem des Prozesssors ist, sondern ein Softwareproblem.

Du konntest mit meiner Hilfe feststellen, dass wenn man Code nur 
ausreichend vermurkst, die Kiste dann nicht mehr tut.

Ralph B. schrieb:
> Vermutlich wenn mein Freund ( der ja auch nicht immer Zeit hat ) das
> Programm überarbeitet hat  wird es vermutlich so laufen wie ich es mir
> vorstelle.

Ist jetzt nicht böse gemeint, aber warum  tust Dir dann das Ganze an? 
Wenn Dein Freund programmieren kann, dann wird er versuchen den Ablauf 
zu verstehen, was er ein wenig aus Deinem Code rauslesen kann und danach 
wird er 90% Deines Codes in die Tonne treten.

Wie ich Deine Erklärung verstehe ist, dass Du zeitkritische Aktionen 
hast und weniger zeitkritische.

Tatsächlich zeitkritisch ist der Start der Messung, also Triggerung des 
Zählermoduls, die sollte im Interrupt bleiben. Gleichzeitig wird im 
Interrupt ein Flag gesetzt, welches anzeigt, dass Messwerte kommen.

Unkritischer ist das Abholen der vom Zählermodul gesendeten Daten. Diese 
können in der Hauptschleife nach Abfragen der Flags (jeder Interrupt ein 
Flag) ausgewertet werden. Sobald also ein Flag gesetzt ist, geht's in's 
Input, natürlich mit Timeout. Ist der Epfang beendet , dann wird das 
Flag gelöscht. Wenn die Hauptchleife "sauber", d.h. klein gehalten wird, 
dann ist die schnell genug, so dass kein Zeichen verloren geht. Selbst 
mit erhöhter Baudrate, was auch empfehlenswert ist. Denn wenn die Marken 
enger beeinander stehen, dann muss der Empfang und Displayausgabe 
schnell genug gehen, damit die Zuordnung der empfangenen Daten eindeutig 
bleibt.

Ziel muss es sein, dass die kritischen Dinge auch dann weiterlaufen, 
wenn unkritische wie Empfang und Anzeige mal scheitern und das Scheitern 
auch nicht den Prozessor lahmlegt.

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Mach' was draus...

Wobei ich soviel umgestellt hab', dass ich mich fast wetten traue, dass 
es auf Anhieb nicht läuft. Selbst dann kannst Du evtl. Nützliches für 
Dich rausziehen.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
hallo MWS

erst mal vielen vielen Dank das du dir überhaupt die Mühe machst und 
sogar versuchst mein Programm umzuarbeiten und mir mundgerecht zu 
servieren.

Ich habe es eben mal compiliert und es geladen.

Das Logo wird angezeigt. Dann zeigt er mir die Strichbreite an , welche 
sich auch einstellen lässt.

Das allerdings dauernd.

Ich habe dann mal die Befehle für die Strichbreite anzuzeigen 
auskommentiert, wobei ein schwarzer Bildschirm erscheint.

Ich muss mich jetzt mal in Ruhe mit deinen Code auseinandersetzen damit 
ich es kapiere.

Unabhängig habe ich meinen geistigen Erguss auch zum laufen gebracht, in 
dem ich das Interupt Enable direkt vor das Do gesetzt habe.

Zumindest ist jetzt erst mal der Druck weg, und kann mich um den 
entgültigen Einbau der Baugruppen kümmern.

unabhängig entsteht ja auch noch die dritte Version von meinen 
befreundeten Funkamateur.

Wenn er es genehmigt werde ich diesen Code auch mal hier 
veröffentlichen.

Ein paar Fotos werden auch noch kommen. Warscheinlich am Ende des 
Monats, wenn eine weitere baugruppe , die zur Zeit als Steckbrettaufbau 
läuft fertig eingebaut ist.

Erst mal vielen vielen Dank an alle die mir geholfen haben.
Insbesonders an die Geduld von MWS ( ich weis ich habe dich öfters zum 
verzweifeln gebracht ) und auch an den Michael Novak ohne ihn wäre das 
Projekt erst garnicht so weit gekommen.

Ich melde mich wieder wenn es was neues gibt. Und das Programm schaue 
ich mir näher an.

Ralph Berres

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> unabhängig entsteht ja auch noch die dritte Version von meinen
> befreundeten Funkamateur.

Ja, die compilierst Du dann alle zusammen und der µC wählt nach 
Tageslaune eine Version aus.

> Das Logo wird angezeigt. Dann zeigt er mir die Strichbreite an , welche
> sich auch einstellen lässt.
> Das allerdings dauernd.

Da wäre jetzt Debugging angesagt, also schauen, ob der Puls an's 
Zählermodul ausgegeben wird, ob serielle Daten reinkommen.

Wenn das wie ich annehme der Fall ist, dann wird's hier, bzw. in der 
damit aufgerufenen Eingaberoutine hängen:

> If read_UART() = Succ Then

Das spricht für:
> auskommentiert, wobei ein schwarzer Bildschirm erscheint.

Die Eingaberoutine hat zwar in der Simulation gut ausgesehen, wenn die 
jedoch scheitert, dann gibt sie ein Fail zurück und auf dem Display wird 
erst gar nicht versucht etwas auszugeben.

Es kann daran liegen, dass der Code nur ein Fenster von ca. 2ms erlaubt, 
bis ein Zeichen eingetroffen sein muss, nachdem das Zählermodul zur 
Messung aufgefordert wurde. Wenn das länger dauert, bricht der Code mit 
Fehler ab.

Probier' mal die anhängende Änderung, da wird auf das erste Zeichen 5x 
solange, also rund 10ms gewartet, auf die nachfolgenden Zeichen wieder 
normal.

Zuständig ist:
Const to_wait_chars = 2
Const wait_timeout = (_xtal / (_baud / 10) * to_wait_chars) / 82
Const init_timeout_preset = wait_timeout * 5
Const std_timeout_preset = wait_timeout

Wenn Du to_wait_chars erhöhst verlängerst Du die Timeouts.

Verstehst Du im Übrigen, was ich da zusammengeschraubt habe, möchtest Du 
für etwas eine Erklärung?

> Zumindest ist jetzt erst mal der Druck weg, und kann mich um den
> entgültigen Einbau der Baugruppen kümmern.

Ah, das war Deine Angst: dass Deine Hardware instabil ist?!

Autor: Ralph B. (rberres)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
MWS schrieb:
> Da wäre jetzt Debugging angesagt, also schauen, ob der Puls an's
> Zählermodul ausgegeben wird, ob serielle Daten reinkommen.

ja aber ich ich anfange wie zuletzt mit der Methode an bestimmten Stelle 
einen Port auf 1 zu setzen, möchte ich dein Programm erst mal so gut wie 
möglich verstehen.

Dazu werde ich mir zu jeder einzelne Zeile die Hilfedatei in Bascom 
anschauen müssen.

Das wird einige Zeit dauern.

MWS schrieb:
> Es kann daran liegen, dass der Code nur ein Fenster von ca. 2ms erlaubt,
> bis ein Zeichen eingetroffen sein muss, nachdem das Zählermodul zur
> Messung aufgefordert wurde. Wenn das länger dauert, bricht der Code mit
> Fehler ab.

Vielen Dank für den Tipp. Man sieht ich habe dein Code noch lange nicht 
verstanden.

das muss ich mir also mal genauer anschauen.  Ich habe ja die 
Geschwindigkeit nochmal auf 9k6 umgestellt. wenn man mal annimmt das ein 
Zeichen aus 10 Bit besteht, dauert ein Zeichen ja schon 1mS und ein 
String mit 12 Zeichen + cr und LF also 14ms. Auf höhere Baudrate werde 
ich später umstellen, wenn ich weis das das sicher funktioniert.

MWS schrieb:
> Verstehst Du im Übrigen, was ich da zusammengeschraubt habe, möchtest Du
> für etwas eine Erklärung?

Bitte lasse mich erst mal versuchen dein Code zu verstehen. Es kommen 
sicher noch genügend Fragen, zum eventuelle Klarheiten zu beseitigen.

Mit fast 64 Jahren lernt man nicht mehr so schnell wie mit 20 Jahren.
Das merke ich immer öfters das ich allmählich verkalke.

MWS schrieb:
> Ah, das war Deine Angst: dass Deine Hardware instabil ist?!

Das war nicht meine einzige Angst, sondern auch ob das was ich vorhabe 
grundsätzlich funktioniert. Wenn man eine Idee von Grund auf neu 
umsetzen will weis man ja nie sicher, ob man sich nicht auch noch einen 
Hardwarefehler eingebaut hat. Auch weis man Anfangs nie sicher wie das 
Zusammenspiel zwischen dem Wobbler und der neuen Hardware  funktioniert.

Wenn dann noch ein Oberdau, wie ich es nunmal bin, anfängt sich in 
Programmierung zu versuchen, kann es mitunter abenteuerlich werden, 
leider auch für die Personen die mir helfen wollen.

Morgen ( nachdem ich für einen Freund einen Rohde&Schwarz SMS2 
Signalgenerator repariert habe ) werde ich mich wieder dran setzen.

Heute Abend um 23:30 kommt in BR-Alpha wieder eine interessante 
Jazzsendung. Sie dauert 90 Minuten. sowas höre ich trotz später Stunde 
meistens an.Zumindest solange ich Urlaub habe.

Stressfreien Wochenanfang wünsche ich dir.

viele Grüße

Ralph Berres

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo MWS

Ich habe wie du vorgeschlagen hast die Zeilen

Const to_wait_chars = 2
Const wait_timeout = (_xtal / (_baud / 10) * to_wait_chars) / 82
Const std_timeout_preset = wait_timeout

in

Const To_wait_chars = 20                ' warte für die Länge von 2 
Zeichen, ggf. erhöhen
Const Wait_timeout =(_xtal /(_baud / 10) * To_wait_chars) / 63       ' 
63 clocks für eine timeout loop
Const Init_timeout_preset = Wait_timeout * 5
Const Timeout_preset = Wait_timeout

geändert.

es scheint zu funktionieren.

Jetzt werde ich als nächstes mal auf 115Kbaut umstellen und
Const To_wait_chars = 20 wieder auf 2 umstellen.

Ralph

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es funktioniert leider nur mit 9k6

bei 115k2 kommen nur die beiden ersten Ziffern. Allerdings auch bei 
meinen Programm. auch bei 38K6 funktioniert es nicht.

Es könnte also auch ein Hardwareproblem sein.

Ich habe es wieder auf 9k6 umgestellt. Damit funktioniert es ja.

jetzt muss ich mich erst mal an die Reparatur des SMS2 begeben.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Jetzt werde ich als nächstes mal auf 115Kbaut umstellen und
> Const To_wait_chars = 20 wieder auf 2 umstellen.

Da würde ich 2 oder 3 versuchen und dafür die 5 hier vergrößern:

> Const Init_timeout_preset = Wait_timeout * 5

Die 5 bestimmt wie lange gewartet wird von Impuls an den Zähler bis 
serielle Antwort.

Die 2, s.o. bestimmt, wie lange für jedes Zeichen gewartet wird, 
gleichzeitig beeinflusst auch die 2 die 5.

Mit diesen 4 Const kann der Compiler die Wartezeiten vorberechnen.
In Deinem Fall für To_wait_chars = 20 wird Init_timeout_preset zum 5 
fachen, also 100 Zeichen. Der Wert von ursprünglich 2 für To_wait_chars 
muss nur dann erhöht werden, wenn der Zähler während der seriellen 
Ausgabe rumtrödelt, d.h. unterbricht.

Je besser das angepasst ist, d.h. die kleinste Werte bei 
funktionierender Übertragung, desto schneller erholt sich der Code nach 
einem Übertragungsfehlernäher.

Ohne Übertragungsfehler geht's sowieso so schnell, wie es die 
Antwortzeit des Zählers, die Baudrate und die Durchlaufgeschwindigkeit 
der Hauptschleife hergibt.

Ralph B. schrieb:
> bei 115k2 kommen nur die beiden ersten Ziffern. Allerdings auch bei
> meinen Programm. auch bei 38K6 funktioniert es nicht.
> Es könnte also auch ein Hardwareproblem sein.

Wie sieht es denn aus, wenn der Zähler über PC ausgelesen wird, kommt da 
alles an?

Hast Du einen LA? Dann könntest Du ein Telegramm bei 115k ansehen und 
die Zeiten messen, vielleicht ist Dein eigentlich für Standardbaudraten 
idealer Quarz soweit außerhalb seines Solls, dass der Empfang bei 
höheren Baudraten scheitert. Wenn auch am PC die 115k nicht gehen, dann 
liegt's an der Sender-/Zählerseite. Auch ein Speicheroszi geht natürlich 
dafür. Vielleicht zickt Dein Max232, dann wär's tatsächlich die 
Hardware.

> Ich habe es wieder auf 9k6 umgestellt. Damit funktioniert es ja.
Ist aber unvorteilhaft, mehr Baud wäre besser.

Schick' mal Deine erzeugte Hex-Datei, die ist im selben Ordner wie Deine 
Bas-Datei, dann könnte ich nachsehen, ob das Baudratenregister richtig 
gesetzt wird.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Übertragungsfehlernäher

= Übertragungsfehler wieder.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Wie sieht es denn aus, wenn der Zähler über PC ausgelesen wird, kommt da
> alles an?

ja wenn ich den Zähler mit dem PC auslese kommen brav die kompletten 
Zeichen dieser Kette.

MWS schrieb:
> Hast Du einen LA?

Ich besitzer einen HP54645D. Der hat 2 analoge und 16 digitale Eingänge, 
aber auser das ich für die Triggerfunktion Bitkombinationen einstellen 
kann( was ziemlich unluxeriös geht ) hat er keine Möglichkeit serielle 
Daten zu decodieren. Da sind die modernen Geräte weit besser ( falls die 
Option freigeschaltet ist ).

MWS schrieb:
> Wenn auch am PC die 115k nicht gehen, dann
> liegt's an der Sender-/Zählerseite.

mit dem Pc geht das auslesen einwandfrei.

MWS schrieb:
> Vielleicht zickt Dein Max232, dann wär's tatsächlich die
> Hardware.

Hmm müsste ich mir mal überlegen wie ich das feststelle. Eigentlich 
müsste es ja reichen das Signal vor dem Max232 und hinter dem Max232 
gleichzeitig zu oszillografieren und dann Bitwuselei zu betreiben.

MWS schrieb:
> Ist aber unvorteilhaft, mehr Baud wäre besser.

sehe ich auch so. Aber falls ich den Fehler nicht finde muss ich es so 
lassen. Aber mein geschriebenes Programm zeigt das selbe Fehlerbild was 
aber nichts heisen muss.

MWS schrieb:
> Schick' mal Deine erzeugte Hex-Datei, die ist im selben Ordner wie Deine
> Bas-Datei, dann könnte ich nachsehen, ob das Baudratenregister richtig
> gesetzt wird.

werde ich nachher mal tun.

Ralph

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Da sind die modernen Geräte weit besser
Die billigsten LA's sind besser, aber Dein LA wird doch 'ne Zeitachse 
haben, daran könnte man das Timing ablesen. Es gibt ein Startbit, 8 
Datenbits und ein Stopbit, der Wechsel zwischen Stop-/Startbit ist 
typisch, da braucht's keinen Decoder.

Mess' doch mal die Quarzfrequenz Deiner Schaltung, Du hast doch 'nen 
Zähler.

Könnte man nicht messen, so könnte man in trial-and-error Manier 
versuchen die Angabe $CRYSTAL in kHz-Schritten oder weniger zu 
verändern, Bascom berechnet daraus die Werte des Baudratenregisters. 
Dann neu compilieren/flaschen und schauen was passiert. Das Timeout des 
Codes dafür auf eher lang stellen.

> Ich besitzer einen HP54645D
Irgend so eine Antiquität hab' ich auch noch, aber die hat mehr 
dekorativen Charakter, bzw. sorgt dafür, dass die Stellfläche nicht 
anstaubt.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Die billigsten LA's sind besser, aber Dein LA wird doch 'ne Zeitachse
> haben, daran könnte man das Timing ablesen. Es gibt ein Startbit, 8
> Datenbits und ein Stopbit, der Wechsel zwischen Stop-/Startbit ist
> typisch, da braucht's keinen Decoder.

klar hat er eine Zeitachse

MWS schrieb:
> Mess' doch mal die Quarzfrequenz Deiner Schaltung, Du hast doch 'nen
> Zähler.

Die Frequenz stimmt auf 2Hz genau

MWS schrieb:
> Schick' mal Deine erzeugte Hex-Datei, die ist im selben Ordner wie Deine
> Bas-Datei, dann könnte ich nachsehen, ob das Baudratenregister richtig
> gesetzt wird.

sag mir mal wo ich die Hex datei hinschicken soll.


Mittlerweile hat sich ein Problem rausgestellt.

wenn ich den Sweep auf 50Hz einstelle, bricht bei 9600bd die 
Datenübertragung zusammen. das heist es verscwinden Stellen und die 
Anzeige wird kürzer.

Vermutlich hängt das mit der niedrigen Baudzahl zusammen.

Momentan versuche ich den Fehler zu finden, warum es mit 115K2 nicht 
funktioniert.

Ich habe übrigens das Signal am Eingang des Max232 und am Ausgang des 
Max232 oszillographiert und übereinander gelegt.

Was mir aufgefallen ist, der Ausgang ist invertiert. Das müsste ich im 
Datenblatt mal nachschauen , ob das normal ist.

Aber die Telegramme stimmen am Ein und Ausgang exakt überein, abgesehen 
von der Invertierung.

So gesehen vermute ich mal das der Max232 nicht die Ursache ist.

Ralph Berres

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier mal das hexfile

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von einem Freund habe ich diesen acht Kanal Salae kompatiblen L.A. Der 
dekodiert RS232, SPI, I2C problemlos:

Ebay-Artikel Nr. 253686603328

Die SW ist leicht zu bedienen. ( von Salae runter laden ). USB 
Verbindung.
Habe ihn ein paar Mal benutzt und konnte verfolgen was ich sehen wollte. 
Er kann relative viele Zeichen speichern.

Vielleicht hilft das.

Gruss,
Gerhard

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Mess' doch mal die Quarzfrequenz Deiner Schaltung, Du hast doch 'nen
> Zähler.

ich habe nochmal gemessen 14,745328 MHz also 282Hz zu tief

kann das was ausmachen?

Das senden von Daten funktioniert übriens einwandfrei bei 115K2

Ich habe jetzt mal ein PC parallel an die Schnittstelle gehangen und 
kann am PC mit Hyperterminal einwandfrei die Daten empfangen.

noch was bei Dauerlauf funktioniert die Datenübertragung  nur bei 
interupt getriggerte Auslösung nicht.

ich teste aber mal was passiert, wenn ich die Dauerlaufschleife kürzer 
mache.

Ralph

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> sag mir mal wo ich die Hex datei hinschicken soll.

Wie ich sehe, hast Du es rausgefunden.

Ralph B. schrieb:
> Was mir aufgefallen ist, der Ausgang ist invertiert. Das müsste ich im
> Datenblatt mal nachschauen , ob das normal ist

Das ist normal.

Ralph B. schrieb:
> Vermutlich hängt das mit der niedrigen Baudzahl zusammen.

Tut es.

Ralph B. schrieb:
> ich habe nochmal gemessen 14,745328 MHz also 282Hz zu tief

Laut dem hier nicht:

http://mspgcc.sourceforge.net/baudrate.html

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn ich die Dauerschleife kürzer mache dann tritt auch hier der Fehler 
auf.

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> hier mal das hexfile

Das Hex habe ich angesehen, dort wir das Baudratenregister UBRR 
ordentlich auf 7 gesetzt. Allerdings hast Du alten Code verwendet, der 
neue wäre hier:

MWS schrieb:
> rberres_01.bas

Der durchaus wesentliche Unterschied ist, dass ich im alten Code ein 
Word für's Timeout verwendete, welches recht schnell überlief und 
vorzeitig timeoutete. Der rberres_01.bas verwendet ein DWord, da 
passiert das nicht mehr.

Wobei der rberres_01.bas auch 'nen Fehler hatte, das $SIM war nicht 
auskommentiert und damit werden Wait, Waitms übergangen.

Versuch' anhängenden Code, die normale Funktion ist abgeschaltet, 
Interrupts sind aus, Änderungen sind markiert. Das gibt nur einen Impuls 
an den Zähler und holt die seriellen Daten ab. Daran kann man einfacher 
testen und z.B. Interrupttätigkeit als Fehler ausschließen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerade noch übersehen, ändere:
> Const init_timeout_preset = wait_timeout * 5
in:
> Const init_timeout_preset = wait_timeout * 30

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
er zeigt unsinnige Werte 2 stellig in MHz an.

ich mache morgen weiter.

Ralph

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> er zeigt unsinnige Werte 2 stellig in MHz an.

Die unsinnigen Werte sind ok, denn schließlich wird der Zähler nicht 
mehr bei einer bestimmten Frequenz getriggert, sondern einfach jede 
Sekunde.

Ziel ist es jetzt, mehr Zeichen auf's Display zu bekommen. Ich würde ein 
eingehendes Telegramm auf den LA oder das Speicheroszi holen und schauen 
was los ist, ob das Timing von Start-/Stop-Bit mit der Baudrate 
übereinstimmt, etc. Das Telegramm könntest Du hier einstellen.

Ich konnte die Bezeichnung meines LAs nachschauen, es ist ein Gould K450 
mit Dual-5,25Zoll Floppy, gegen diesen Opa dürfte Dein HP54645D ein 
Heranwachsender sein ;-)

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Das Telegramm könntest Du hier einstellen.

ich müsste jetzt mal rausfinden wie ich statt eines Screenschotts das 
Datendiagramm aus dem Oszi bekommen kann.

Hast du Lust das wir mal telefonieren?

Sende mir mal deine Telefonnummer an r-berres et arcor.de

Am liebsten eine Festnetznummer dafür habe ich eine Flatrate in 
Deutschland.

Meine Telnummer 0651-44016

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> ich müsste jetzt mal rausfinden wie ich statt eines Screenschotts das
> Datendiagramm aus dem Oszi bekommen kann.

Das dürfte besser Auskunft geben wo's hakt, 115kBaud ist noch dazu mit 
Baudratenquarz eher kein Problem.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was beim Schaltplan und Layout auffällt, für den Max232 werden für die 
Ladungspumpe C6-C9 jeweils 10µF verwendet, obwohl wenn's nicht 
Uraltbausteine sind, eher 1µF richtig ist, bzw. 100nF beim Max232A.

Der Abblockkondesator C2 hat in Deinem Schaltplan 220µF statt 1µF, resp. 
10µF und ist relativ weit weg vom Max232, wird zwar von einer kräftigen 
Leiterbahn verbunden, aber ich bezweifle, dass das im Sinne des 
Erfinders ist, sonst würde man einfach dicke Leiterbahnen nehmen und 
alle Abblockkondesatoren irgendwo in 'ne Ecke packen wo sie nicht 
stören.

Im Fall des Max232 dient der C2 dem Abpuffern von Stromspitzen, die von 
der Ladungspumpe erzeugt werden und dafür ist ein kleiner Kerko mit 1µF 
und entsprechend Kerko-typisch kleiner Impedanz direkt am Baustein 
besser geeignet als ein 220µF Elektrolyt weit weg und mit hoher 
Impedanz.

An 'ne Softwaregeschichte glaub' ich in diesem Fall nicht, eher an der 
Kante befindliche Baudraten oder eine unsaubere Funktion des Max232.

Solltest Du dennoch in Richtung Software suchen wollen, dann schreib' 
das in die read_UART():
' ...
Loop Until time_out = 0
  If time_out = 0 Then
    PortD.4 = 1 : Waitms 100 : PortD.4 = 0
  End If
  read_UART = rslt
End Function
Zu beginn des Codes PortD.4 auf Ausgang setzen, ich sah dass der frei 
ist. Du kannst natürlich wieder ein Oszi dran hängen, das finde ich aber 
zu kompliziert, 'ne kleine Led tut's für's Debugging locker und kann 
weiteren Nutzen bringen.

Wenn die UART-Routine in's Timeout läuft, siehst Du so eine kurze Flanke 
auf dem Pin.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MWS

Ich habe mal den Max232 untersucht.

Zunächst habe ich die Spannungen an Pin2 und Pin6 oszillographiert.

Es wareen jeweils 8,6V DC ohne irgendwelches Ripple.

Dann habe ich mir das Signal an Pin12 angeschaut.

Es waren einwandfreie Flanken und war auch Deckungsgleich mit dem 
invertierten Signal an Pin 13

An Pin13 war der Ruhepegel - 6V und der Signalpegel +6V
An Pin12 war der Ruhepegel +5V und der Signalpegel 0V

Die Breite eines Bits ist 8,6usek was 116,3KHz entspricht.

Ich glaube den Max232 kann man ausschließen.

Das selbstgeschriebene Programm scheint jetzt auch mit 115K zu spielen.

Trotzdem will ich der Ursache auf den Grund gehen, warum dein Programm 
noch Probleme macht.

Ralph Berres

Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selber kann ich ja kein fertiges Bascom-Programm anbieten. Allerdings 
ist diese Diskussion über vermeintlich ungenaue Baudrate oder die 
Kondensatorwerte der Ladungspumpen nur eine Ablenkung vom eigentlichen 
Problem. Kostet Zeit und bringt garnichts.

Wenn empfangene Zeichen fehlen, würde ich zunächst sicherstellen, daß 
keine Zeichen verloren gehen können. Das erreicht man zuverlässig, wenn 
diese per ISR empfangen und gespeichert werden. Polling ist ja ganz 
nett, aber bei höheren Baudraten nie 100% sicher.

> An 'ne Softwaregeschichte glaub' ich in diesem Fall nicht, eher an der
> Kante befindliche Baudraten oder eine unsaubere Funktion des Max232.

Das sehe ich anders.

Autor: Äxl (geloescht) (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich mische mich auch nur ungern ein, (soviel Erfahrung habe ich mit 
BASCOM nicht) Aber Serielle Strings würde ich nie im leben pollen, 
sondern IMEMR im Interrupt in einen Puffer einlesen, der Hauptschleife 
eine Flag mit auf den Weg geben, sobald ein kompletter String im Puffer 
steht. Dort wirde er dann Zeichen für Zeichen abgeholt.

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mi N. schrieb:
> Das sehe ich anders.

Dein Meinung kannst Du gerne vertreten, meine hab' durch Nachrechnen 
fundiert, bevor ich sie zum Besten gab.

Eine Runde für die Abfrage des UDR per Inkey ohne eintreffendes Zeichen 
benötigt um die 82 Takte, mit eintreffendem sind's 250 Takte, im 
Simulator nachvollzogen.

Bei 115200 Baud kommen 11520 Byte/Sekunde rein, ein Zeichen benötigt 
damit 86,8µs, bei einem Takt von 14745600 Hz vergehen in dieser Zeit 
1280 Takte. Daher kann ich verbindlich sagen, dass Pollen in diesem Fall 
kein Problem ist.

Anders siehts's aus, wenn Dein Zählermodul bei der Ausgabe rumtrödelt, 
meine UART-Empfangsroutine bricht dann ab, sobald eines der Timeouts 
erreicht wird. Es war Absicht, dass die Empfangsroutine das Empfangene 
eher verwirft, als dass sie zu lange wartet.

Ralph B. schrieb:
> Trotzdem will ich der Ursache auf den Grund gehen, warum dein Programm
> noch Probleme macht.

Da wäre jetzt wichtig zu wissen, welche Version Du verwendest. Die 
ursprüngliche Version konnte Timeouts zu schnell erreichen, obwohl die 
Formel aus Consts das richtige Preset ermittelte.

Verwendest Du die rberres_02.bas, dann verlängere die Timeouts, setze 
also to_wait_chars auf 100, dann wird auf ein Zeichen um die 100ms 
gewartet, kannst auch 1000 schreiben, dann ist's etwas mehr als eine 
Sekunde, die er auf ein Zeichen wartet, bis er abbricht.

> Das selbstgeschriebene Programm scheint jetzt auch mit 115K zu spielen.
Das etwas plötzlich geht, obwohls's das vorher gar nicht tat hört sich 
verdächtig nach programming-by-random-changes an.

Solltest Du allerdings wissen, warum's jetzt klappt, bzw. was Du 
verändert hast, so lass' uns an Deinem Wissen teilhaben.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also bei meinen Kenntnisstand in Programmieren wäre ich vorsichtig von 
wissen zu reden.

Ich knn aber mitteilen was ich geändert habe.

1. Das enable Interupt habe ich mal direkt vor Beginn der Do 
loopSchleife gesetzt. Das funktionierte seltsamerweise.

Wenn ich aber das enable Interupt am Ende der
nterupt:

On Int0 Marke1                          'Bei Interrupt springe zu Marke1
Enable Int0                             'Enable Interrupt 0
Config Int0 = Rising                    'Interrupt bei ansteigender 
Flanke

On Int1 Marke2                          'Bei Interrupt springe zu Marke2
Enable Int1                             'Enable Interrupt 1
Config Int1 = Rising                    'Interrupt bei ansteigender 
Flanke

also hierhin
enable Interupt

gesetzt habe bekam ich beim compilieren Fehlermeldungen.
Verstanden habe ich es ehrlich gesagt nicht.

2.

 Pulseout Portd , 6 , 6000  habe ich auf 600 runter gesetzt.

und dann funktionierte es auf einmal.

MWS schrieb:
> Da wäre jetzt wichtig zu wissen, welche Version Du verwendest

das war rberres_02.bas also die Testversion wo die Interups abgeschaltet 
waren.
Davor hatte ich die Version rberres.bas verwendet.

Ich bin momentan immer noch am experimentieren, ohne das ich genau weis 
, was ich eigentlich tue.

Trial and error halt.

Nicht unbedingt die intelligenteste Art zu programmieren. Aber wenn man 
es nicht besser kann? Sorry

Ralph Berres

: Bearbeitet durch User
Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Pulseout Portd , 6 , 6000  habe ich auf 600 runter gesetzt.
>
> und dann funktionierte es auf einmal.

Jetzt habe ich die Dokumentation von Bascom angesehen und auch einmal 
gerechnet: Ursprünglich hast Du die Pulsbreite auf 1,627 ms (mit 6000) 
gesetzt. Die positive Flanke triggert die Einzelmessung, die bei 1 ms 
Meßzeit nach ca. 1,2 - 1,3 ms die serielle Ausgabe beginnt.

Die Übertragung eines Zeichen @ 115k2 Bd dauert 0,087 ms. Wenn der 
Triggerimpuls weggenommen wird, sind folglich schon 4 - 5 Zeichen 
ausgegeben und verloren!
Bei 1 ms Meßzeit und einem noch anliegenden Triggerimpuls >= 1 ms wird 
gleich eine Messung hinterher gestartet (kont. Messung). Folglich müßten 
zwei Ergebnisse verarbeitet werden.


MWS schrieb:
> Anders siehts's aus, wenn Dein Zählermodul bei der Ausgabe rumtrödelt,
> meine UART-Empfangsroutine bricht dann ab, sobald eines der Timeouts
> erreicht wird.

Das Timeout tritt womöglich auf, weil die Ausgabe schon längst 
abgeschlossen ist und Dein Programm davon nicht mitbekommen hat ;-)

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Bei 1 ms Meßzeit und einem noch anliegenden Triggerimpuls >= 1 ms wird
> gleich eine Messung hinterher gestartet (kont. Messung). Folglich müßten
> zwei Ergebnisse verarbeitet werden.

Das Problem war mir auch anfangs aufgefallen, wie ich die Hauptplatine 
in Betrieb genommen habe. Deswegen hatte ich eine Änderung vorgenommen.

der Ausgang des Triggerimpulses welches aus dem Atmega8 kommt, geht bei 
mir
noch auf ein Differnzierglied bestehend aus 220pF und 270K gegen Masse 
gefolgt von einen 74HCT00.

Der Impuls welcher deinen Zähler triggert ist tatsächlich nur ca 100us 
Lang.

Dein Zähler liefert nachweislich nur einen Wert/ Trigger.
Das konnte ich mit Hyperterminal am PC mitprotokollieren.

Ralph Berres

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte mich entschuldigen mich hier einzumischen. Ich habe keine 
Erfahrung mit BASCOM. Ich habe mir aber gerade diese Link angesehen:

https://avrhelp.mcselec.com/index.html?config_serialin.htm

Es sieht so aus als ob BASCOM voll gepufferten Serial Interrupbetrieb 
unterstützt:

The following internal variables will be generated for UART0:

_RS_HEAD_PTR0 , a byte counter that stores the head of the buffer

_RS_TAIL_PTR0 , a byte counter that stores the tail of the buffer.

_RS232INBUF0 , an array of bytes that serves as a ring buffer for the 
received characters.

_RS_BUFCOUNTR0, a byte that holds the number of bytes that are in the 
buffer.

Ich habe mir die Quelle angesehen, aber nichts disbezuegliches gefunden.

Mit gepufferten Serial Interrupt Betrieb gehen normalerweise keine 
Zeichen verloren wenn genug Pufferplatz da ist.

Da ich nur Erfahrung mit C habe, kann ich nur sagen, dass dort der 
Pufferbetrieb immer einwandfrei funktioniert hat und hohe Baud Raten 
kein Problem sind.

Mein Vorschlag wäre also die Serial Comm auf Interrupt betriebenen 
gepufferten Betrieb umzustellen.

Im Beispiel 2 in der LINK wird gezeigt wie man das macht.

Wie gesagt ich möchte mich hier nicht einmischen. Aber vielleicht hilft 
es die Serial Probleme endgültig zu bannen.

mfg,
Gerhard

Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Im Beispiel 2 in der LINK wird gezeigt wie man das macht.
>
> Wie gesagt ich möchte mich hier nicht einmischen. Aber vielleicht hilft
> es die Serial Probleme endgültig zu bannen.

Misch Dich ruhig noch mehr ein und sag, wo sich Beispiel 2 befindet ;-)
Die Beispiele, die unter "Hilfethemen" zu finden sind, lassen das Meiste 
im Dunkeln.

Ralph B. schrieb:
> der Ausgang des Triggerimpulses welches aus dem Atmega8 kommt, geht bei
> mir
> noch auf ein Differnzierglied bestehend aus 220pF und 270K gegen Masse
> gefolgt von einen 74HCT00.

Gut, dann gibt es auch nur ein Ergebnis.
Es würde aber auch ein Puls von 1 µs reichen, um zuverlässig zu 
triggern.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Gerhard O. schrieb:
>> Im Beispiel 2 in der LINK wird gezeigt wie man das macht.
>>
>> Wie gesagt ich möchte mich hier nicht einmischen. Aber vielleicht hilft
>> es die Serial Probleme endgültig zu bannen.
>
> Misch Dich ruhig noch mehr ein und sag, wo sich Beispiel 2 befindet ;-)
> Die Beispiele, die unter "Hilfethemen" zu finden sind, lassen das Meiste
> im Dunkeln.
>
> Ralph B. schrieb:
>> der Ausgang des Triggerimpulses welches aus dem Atmega8 kommt, geht bei
>> mir
>> noch auf ein Differnzierglied bestehend aus 220pF und 270K gegen Masse
>> gefolgt von einen 74HCT00.
>
> Gut, dann gibt es auch nur ein Ergebnis.
> Es würde aber auch ein Puls von 1 µs reichen, um zuverlässig zu
> triggern.

Das ist komisch. Auf der verlinkten Seite ist ein komplettes Beispiel 
(Example2) im unteren Drittel der Webseite wo das auf einem ATMEGA2560 
vorgeführt wird. Sollte auch mit den Kleinen gehen.
Example2

'-----------------------------------------------------------------------------------------

'name                     :

'copyright                : (c) 1995-2016, MCS Electronics

'purpose                  : test for M2560 support

'micro                    : Mega2560

'suited for demo          : yes

'commercial addon needed  : no

'-----------------------------------------------------------------------------------------
Hast Du das nicht gefunden?

https://avrhelp.mcselec.com/index.html?config_serialin.htm

: Bearbeitet durch User
Autor: Mi N. (msx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Hast Du das nicht gefunden?

NoScript hat dies bislang verhindert. Jetzt ist alles klar!

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Gerhard O. schrieb:
>> Hast Du das nicht gefunden?
>
> NoScript hat dies bislang verhindert. Jetzt ist alles klar!

Danke:-)

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Es sieht so aus als ob BASCOM voll gepufferten Serial Interrupbetrieb
> unterstützt:

Tut es. Das hatte aber keine Chance bei Ralphs zuerst 
zusammengebasteltem Code, in dem die seriellen Daten im externen 
Interrupt geholt wurden, denn dort sind andere Interrupts gesperrt. 
Gepufferter Empfang und Senden geht also innerhalb eines Interrupts 
nicht, außer man erlaubt dort gezielt wieder Interrupts, was einen 
ganzen Sack voller Flöhe aufmacht.

Also hab' ich Ralphs Code umgestrickt auf kleine Interruptlast in den 
externen Ints mit einer ungepufferten Empfangsroutine. Ich wusste 
natürlich, dass mit dieser Änderung den ganzen Krempel aus dem Interrupt 
zu schmeißen auch die gepufferte Eingabe möglich wird.

Andererseits nahm ich nicht an, dass der so weitgehend umgearbeitete 
Code überhaupt auf Anhieb funktioniert, was er jedoch tat. Noch weiter 
auf einmal zu ändern schien mir also erstmal nicht sinnvoll.

Also langsam machen, vor allem da Ralph in der Umsetzung der Vorschläge 
durchaus kreativ ist.

Gerhard O. schrieb:
> Wie gesagt ich möchte mich hier nicht einmischen. Aber vielleicht hilft
> es die Serial Probleme endgültig zu bannen.

Du kannst gerne mischen, aber so war halt der Gang den ich möglich sah, 
mit vorliegender Hardware und Beschreibung wäre ich in kürzester Zeit 
fertig gewesen, aber das war nicht das Ziel und auch über diesen Weg 
nicht zu machen.

Mi N. schrieb:
> Das Timeout tritt womöglich auf, weil die Ausgabe schon längst
> abgeschlossen ist und Dein Programm davon nicht mitbekommen hat ;-)

Das habe ich nicht hinterfragt da von Ralph bereits als ordentlich 
getestet angenommen, genau das mag aber der springende Punkt gewesen 
sein. Eine gepufferte Routine hätte hier tatsächlich den Kunstfehler des 
zu langen Triggerpulses kompensiert.

Also, frisch auf! Der neue Code wartet nur darauf geschrieben zu werden.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss gestehen das ich momentan den von mir selbst geschrieben Code 
vorrangig weiter bearbeitet habe, weil der mittlerweile halbwegst stabil 
auch mit 115K läuft. Zwischenzeitlich habe ich in meinen Programm auch 
noch weitere Funktionen implenmentiert.

Nicht desto trotz will ich aber MWS Ansatz weiter verfolgen, schon 
alleine um überhaupt zu verstehen wie er vorgeht. Das ist aber für mich 
ein erheblicher Lernaufwand was nicht so schnell geht. ( mit 64 kapiert 
man nicht mehr so schnell ).

Aus diesem Thread habe ich aber glaube ich schon so manches gelernt.

z.B. das man innerhalb eines Interuptaufrufes nicht noch ein Interupt 
aufrufen kann, was aber notwendig wäe wenn man die RS232 nachricht 
vorher zwischenspeichern will.

z.B. das es ratsam ist mit dem Interuptaufruf nur Flaks zu setzen und 
das eigentliche auslesen aus dem Register außerhalb des Interupts in der 
Hauptschleife zu realisieren.

z.B. das man ( wie ich heute schmerzlich erfahren musste ) in einer If 
then else Schleife keine Ports abfragen kann, sondern dem Port erst ein 
Alias zuordnen muss. ( Das hat mich zwei tage Arbeit gekostet ).

Nur muss ich erst mal lernen das alles umzusetzen.

Warscheinlich stolpere ich über noch mehr von mir konstruierte Klöpse.
Ich weis nur noch nichts davon.

Für euch ist es natürlich anstrengend einen 64jährigen halbsenilen Dau 
die elementarsten Grundlagen im Programmieren zu vermitteln, und dabei 
feststellen muss, das die Umsetzung meinerseits aus uerer Sicht 
unendlich langsam und holprig geschieht.

Aber vielleicht erreiche ich das Ziel ja doch irgendwann , um dann mich 
am nächsten für mich viel zu komplizierten Projekt abzuarbeiten.

Vielleicht sollte ich besser Briefmarken sammeln.

Ralph Berres

: Bearbeitet durch User
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Du kannst gerne mischen, aber so war halt der Gang den ich möglich sah,
> mit vorliegender Hardware und Beschreibung wäre ich in kürzester Zeit
> fertig gewesen, aber das war nicht das Ziel und auch über diesen Weg
> nicht zu machen.

Ich kann da wahrscheinlich nicht zu viel beitragen da ich nie mit BASCOM 
gearbeitet habe. Abgesehen davon, bist Du wahrscheinlich sowieso der 
hier der den besten Überblick hat. Jedenfalls wünsche ich "dem Team" 
einen guten Erfolg. Man lernt ja immer sehr viel dabei. Und ja, ich bin 
auch schon fast 64:-) Altes Eisen jetzt! Aber die Uhr lasst sich nicht 
zurückstellen...

Ich weiß nicht ob es Sinn für mich hat in BASCOM einzusteigen. Ich habe 
zwar eine ältere Version vor vielen Jahren gekauft aber nie was damit 
gemacht weil mir C einfach lieber ist. Dann kommt noch dazu dass ich in 
der Firma mit verschiedenen uC Familien/Produkten arbeiten muss. Da ist 
C günstiger weil ich oft modulare Teile auf andere uC portiere.

OK. Mittagspause ist um für mich...

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ich weiß nicht ob es Sinn für mich hat in BASCOM einzusteigen. Ich habe
> zwar eine ältere Version vor vielen Jahren gekauft aber nie was damit
> gemacht weil mir C einfach lieber ist.

Hallo Gerhard
wenn du C beherrschst, dann bleibe bei C da es ohnehin die bessere 
Sprache zu sein scheint.

Ich habe zwar mal versucht in C was zu machen. Dabei bin ich aber so 
verzweifelt gewesen, das ich doch wieder bei dem für mich viel 
verständlichere Sprache Basic gelandet bin.

Basic ist was für jemanden der bei anderen Sprachen vor unüberwindlichen 
Schwierigkeiten steht.

Ralph Berres

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Ralph,

Ralph B. schrieb:
> Gerhard O. schrieb:
>> Ich weiß nicht ob es Sinn für mich hat in BASCOM einzusteigen. Ich habe
>> zwar eine ältere Version vor vielen Jahren gekauft aber nie was damit
>> gemacht weil mir C einfach lieber ist.
>
> Hallo Gerhard
> wenn du C beherrschst, dann bleibe bei C da es ohnehin die bessere
> Sprache zu sein scheint.
Ja. Man soll halt das verwenden wo man seine "Feinde" kennt:-)
>
> Ich habe zwar mal versucht in C was zu machen. Dabei bin ich aber so
> verzweifelt gewesen, das ich doch wieder bei dem für mich viel
> verständlichere Sprache Basic gelandet bin.
Das verstehe ich 100%. Auch habe ich den Eindruck von der Doku her, dass 
BASCOM so ziemlich alles hat was man bei uC braucht. Wenn da nicht 
gerade Bugs Show Stopper sind, sollte es möglich sein viel Projekte 
erfolgreich zu verwirklichen. Wenn ich nicht so viel mit C in der Firma 
machen müsste, hätte ich damals wahrscheinlich auch mit BASCOM 
angefangen. So ist es halt liegen geblieben.
>
> Basic ist was für jemanden der bei anderen Sprachen vor unüberwindlichen
> Schwierigkeiten steht.
Ich habe auch mit BASIC angefangen. Ein HP85A und HP71B und sehr viel 
spaeter mit QB45 waren die ersten Computer zu denen ich damals Zugang 
hatte. Und dann zeigte ein Freund von mir wie cool doch Borland C auf 
seinen 8086 Rechner war und wie viel schneller es war und das zog mich 
hinein.

Gerhard
>
> Ralph Berres

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Vielleicht sollte ich besser Briefmarken sammeln.

Das würde Dir keinen Spaß machen ;-)

Außerdem, wenn's funktioniert, ist doch alles gut.

Du musst nur aufpassen, dass bestimmte Methoden, wie der Empfang in der 
Interruptroutine, eine Sackgasse sein können, wenn Du bestimmte weitere 
Funktionen willst, welche mit diesem Prinzip einfach nicht mehr zu 
machen sind. Da stößt Du schneller an Grenzen und die dann zu 
überschreiten geht nur mit Brutalomurks.

Um für etwas weitere Verwirrung zu sorgen: So wie im Anhang könnte das 
mit gepuffertem Serialin aussehen, k.A. ob das auf Anhieb geht oder 
nicht. Timer0 wurde als Monoflop benutzt um Pulsout zu ersetzen, das 
ansonsten die externen Interrupts für die Dauer des Triggerpulses 
blockieren würde.

So wie's gedacht ist, schnappt sich der gepufferte Uart alles was nach 
der steigenden Flanke des Zählertriggerimpulses an Seriellem reinkommt 
und zwar unabhängig davon wie lange der Impuls dauert.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> So wie im Anhang könnte das
> mit gepuffertem Serialin aussehen, k.A. ob das auf Anhieb geht oder
> nicht. Timer0 wurde als Monoflop benutzt um Pulsout zu ersetzen, das
> ansonsten die externen Interrupts für die Dauer des Triggerpulses
> blockieren würde.

das werde ich morgen doch glatt mal probieren.

Der Code sieht für mich einigermaßen nachvollziehbar aus.

So jetzt ist Matratzenhorschdienst angesagt.

Wie war der Spruch

Wieder ist ein Tag vollbracht
wieder wurde nur Scheiß gemacht.
leckt mich am Arsch bis Morgen.
Bleibt mir fern mit euren Sorgen.
Morgen gehts mit dem selben Fleiße
wieder an die selben Scheiße.

In diesem Sinne gute Nacht an alle.

Ralph Berres

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen zusammen.

Ich habe gerade die Version von MWS in den Atmega geladen.

Es funktionierte auf Anhieb.

Großes Lob an MWS.

Jetzt werde ich die weiteren Funktionen versuchen zu implementieren, die 
ich in meiner Version erarbeitet habe.

meine eigene letzte Version war strichbreite5 und strichbreite6 versuche 
ich den zweiten adc einzubinden.

Ralph

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MWS

Ich wollte jetzt in deinen letzten Programm im ersten Schritt dafür 
sorgen, das wenn der Dauerlauf eingeschaltet ist in der zweiten Zeile 
Sweep aus erscheint.
dazu habe ich folgendes geändert.

1. weitere Constanten hinzugefügt.


Const Marke2aus = "  Marke2 aus   "
Const Sweepaus = "  Sweep aus  "
Const Strichbreite = "Strichbreite "
Const Rohde_schwarz = " Rohde&Schwarz "
Const Swob5 = "   swob5

If Dauerlauf = 0 Then                   '0 = Dauerlauf

'*************** Dauerlauf an 
**********************************************
  If Schleife =< 1 Then
    Schleife = 128000
      Clear Serialin
      Portd.6 = 1
      Start Timer0                      'Triggerimpuls 150µs nur alle 
100ms
        Input Serialstring
          Oled_data = Blank2 + Serialstring
            Oled_show_data 1 , 1
  '--------------------------- Anzeige Sweep out in zweite 
Zeile---------
             Oled_data = Sweepaus
              Oled_show_data 2 , 1
  Else
    Decr Schleife
  End If

doch die Schleife scheint nicht mehr zu laufen.

es stehen in beiden Zeilen Frequenzen doch die obere Zeile wird nicht 
mehr aktualisiert.

was mache ich falsch?

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt mal was ausprobiert.

Meine Vermutung war das er in der Schleife die Konstante nicht mehr 
anspringt. Korrigiert mich  bitte wenn ich falsch liege.

die Konstante Const Sweepaus = "  Sweep aus  "

habe ich jetzt in die Schleife reingesetzt
also

If Dauerlauf = 0 Then                   '0 = Dauerlauf

'*************** Dauerlauf an
**********************************************
  If Schleife =< 1 Then
    Schleife = 128000
      Clear Serialin
      Portd.6 = 1
      Start Timer0                      'Triggerimpuls 150µs nur alle
100ms
        Input Serialstring
          Oled_data = Blank2 + Serialstring
            Oled_show_data 1 , 1
  '--------------------------- Anzeige Sweep out in zweite Zeile ------
Const Sweepaus = "  Sweep aus  "
             Oled_data = Sweepaus
              Oled_show_data 2 , 1
  Else
    Decr Schleife
  End If

jetzt funktioniert es zwar

doch beim einschalten des Dauerlauf bleibt die Schleife ab und zu mal 
stehen.

so etwa 5 mal einschalten funktioniert es beim 6. mal bleibt er stehen.

Ralph

Autor: Mi N. (msx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Großes Lob an MWS.

Auch von mir! Es ist gut, daß nach den anfänglich heißen Tagen hier 
nicht nur heiße Luft herausgekommen ist, sondern eine Lösung des 
Problems.

Gerhard O. schrieb:
> Und dann zeigte ein Freund von mir wie cool doch Borland C auf
> seinen 8086 Rechner war und wie viel schneller es war und das zog mich
> hinein.

Zumal BASIC seinerzeit nur als Interpreter verfügbar war. Ab 
Turbo-Pascal ging die Sache dann ab ;-)
Aber Bascom ist eher 'weichgespült' wie auch Arduino-Zeugs. Auf den 
ersten Blick schön einfach, auf den zweiten Blick eher geschwätzig und 
auch umständlich, wenn es zum Beispiel um mehrdimensionale, 
initialisierte Felder geht. Selber habe ich eine einzige Anwendung 
geschrieben und da ich es nicht besser wußte, Stringkonstanten mit DATA 
eingelesen. Das sind die Lochkarten, die immer zum Schluß kamen ;-)
Beitrag "reziproker Frequenzzähler mit BASCOM-AVR"

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi N. schrieb:
> Aber Bascom ist eher 'weichgespült' wie auch Arduino-Zeugs. Auf den
> ersten Blick schön einfach, auf den zweiten Blick eher geschwätzig und
> auch umständlich

hallo Michael

Das Problem was mich bei Bascom immer wieder einholt, ist die 
Hilfedatei, die nicht wirklich eine Hilfe ist. zm einen weil sie in 
Englisch ist ( ich hatte nie Englischuntericht ) zum anderen, weil sie 
viele Themen so oberflächlich behandelt, das die eigene Probleme nicht 
abgedeckt werden.

so zum Beispiel das man in eine if then elde Schleife zur Abfrage der 
Ports

nicht if portd.7 = 1 then schreiben darf sondern eine alias namen 
vergeben muss. gestern habe ich von jemanden erfahren das man statt 
Port7d pin7d schreiben muss. beide hinweise habe ich nicht in der 
Hilfedatei gefunden, und habe mir einen Wolf gesucht. Vielleicht steht 
es ja tatsächlich in der Hilfe, aber dann hat man das Thema nicht 
gefunden.

Ralph Berres

Autor: Keine Gerüchte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:

> so zum Beispiel das man in eine if then elde Schleife zur Abfrage der
> Ports
>
> nicht if portd.7 = 1 then schreiben darf sondern eine alias namen
> vergeben muss.

Das ist doch nicht wahr!

> gestern habe ich von jemanden erfahren das man statt
> Port7d pin7d schreiben muss.

Kunststück! Wenn man einen EINGANG abfragen will, muß man eben fragen, 
was am PIN passiert.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Hilfedatei, die nicht wirklich eine Hilfe ist.

LOL, die ist mit ein paar Schwächen sogar recht gut. Wenn Du die als 
"keine Hilfe" betrachtest, dann wärst Du bei C völlig aufgeschmissen.

Früher (tm) musst man sogar Bücher !!! benutzen um zu lernen, da konnte 
man's nicht mal schnell googeln. Und man musste auch tatsächlich willens 
sein zu lernen, das ist heute auch nicht anders.

> so zum Beispiel das man in eine if then elde Schleife

Ein "If Then Else End If" ist keine Schleife, sondern ein 
Bedingungsblock.

> zur Abfrage der Ports nicht if portd.7 = 1 then schreiben darf
> sondern eine alias namen vergeben muss

Das ist Unsinn, denn der Fehler hier ist tatsächlich, dass man bei der 
Abfrage eines Portpins das PIN-Register verwenden muss und nicht das 
PORT-Register. Ein If PinD.7 = 1 Then funktioniert natürlich im 
Gegensatz zu Deiner Annahme.

Hast Du ja auch in Deinem Code so gemacht: Dauerlauf Alias Pind.5
Das "Alias" sorgt nur für einen anderen Namen für die folgende 
Bezeichnung. Ähnlich das "Const", das macht eine Ersetzung an der 
Stelle, an der der Const-Bezeichner eingesetzt wird. Konstanten 
berechnen kann man damit auch, wie Du an meinen Beispielen siehst.

> zm einen weil sie in Englisch ist ( ich hatte nie Englischuntericht )

Wann gingst Du in die Schule und wie alt bist Du jetzt?!
Meinst Du nicht, das hättest Du in der Zwischenzeit lernen können, wenn 
Du gewollt hättest?
Heute gilt in der technischen Welt: Kein Englisch = leider verloren.
Atmel/Microchip schreibt die Datenblätter nicht in Deutsch wegen Dir.

> doch beim einschalten des Dauerlauf bleibt die Schleife ab und zu mal
> stehen.

Dann würde man erstmal das auskommentieren:
Oled_show_data 2 , 1
und sehen, ob's dann geht. Entsprechend des Ergebnisses baut man 
entweder noch mehr zurück oder man untersucht die OLed-Ausgaberoutine.

Nachdem Code bei Dir zufällig nachher geht und dann wieder nicht, kann 
ich mir durchaus vorstellen, dass bei Deiner Änderung ein Fehler dazu 
gebaut wurde.

Erhöhe auch mal die Stacks, Platz im SRam hast Du noch genug:
$hwstack = 192
$swstack = 192

> was mache ich falsch?

Z.B:
MWS schrieb:
> Genauso wie Du jeweils den
> kompletten neuen Code als Anhang anhängen und nicht in Fetzerl in
> Prosa beschreiben solltest.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Gerüchte schrieb:
> Das ist doch nicht wahr!

was ist nicht wahr?

Keine Gerüchte schrieb:
> Kunststück! Wenn man einen EINGANG abfragen will, muß man eben fragen,
> was am PIN passiert.

Wenn ich den Port als Eingang definiere, dann gehe ich erst mal davon 
aus, das, wenn ich den Port abfrage das Bascom weis das es ein Eingang 
ist.

Mit dem Aliasnamen weis er es ja dann offenbar.

Das es explizit noch einen Pin Befehl gibt habe ich nicht gewust.

Leider bin ich nicht mit kompletten Basickenntnissen auf die Welt 
gekommen.

Ralph Berres

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Wann gingst Du in die Schule und wie alt bist Du jetzt?!

Ich habe 1969 die Schule nach 9 Jahren mit einen Hauptschulabschluss 
verlassen, und danach direkt eine Lehre als Elektromechaniker begonnen.
Da gab es noch kein Schulenglisch.
1994 habe ich dann meinen Meister als Radio und Fernsehtechniker 
erworben.

Im November werde ich 64 Jahre alt.

Aber du hast recht Sprachen zu erlernen hat nir schon immer schwer 
gefallen.

Auch das Morsen zu erlernen hat mich 3 Jahre Arbeit gekostet, bis ich 
die 60 Zeichen / Min in der Amateurfunkprüfung mit weniger als 1 Fehler 
/ Minute hören und mitschreiben konnte.

MWS schrieb:
> Ein If PinD.7 = 1 Then funktioniert natürlich im
> Gegensatz zu Deiner Annahme.

Das hat mir gestern auch schon jemand am Telefon beiläufig verklickert.

Aber in der Hilfe von AVR hatte ich den Hinweis nicht gefunden. Könnte 
aber doch irgendwo stehen, und ich habe es nicht gefunden.

MWS schrieb:
> Erhöhe auch mal die Stacks, Platz im SRam hast Du noch genug:$hwstack =
> 192
> $swstack = 192

das kann ich mal noch machen. Obwohl der Aussetzer verhältnismäßig 
selten ist.

MWS schrieb:
> Ein "If Then Else End If" ist keine Schleife, sondern ein
> Bedingungsblock.

Sorry ich habe mich falsch ausgedrückt.

Heute Mittag versuche ich noch den zweiten ADC einzubinden.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Wenn ich den Port als Eingang definiere, dann gehe ich erst mal davon
> aus, das, wenn ich den Port abfrage das Bascom weis das es ein Eingang
> ist.

Bascom tut das, was Du anschaffst. Es kann ja Dein Wunsch sein 
festzustellen, ob der Pullup gesetzt wurde. Das würde man durch Abfragen 
des PORT-Registers erfahren, selbst wenn der Port auf Eingang 
konfiguriert ist. Der Compiler kann und soll auch nicht vermuten, was Du 
willst.

Ralph B. schrieb:
> Leider bin ich nicht mit kompletten Basickenntnissen auf die Welt
> gekommen.

Dir wurde auch nicht ein Wobbler in die Wiege gelegt.

> Das es explizit noch einen Pin Befehl gibt habe ich nicht gewust.
Du hast ihn im Code zum Eingangspost verwendet:
Config Portd.5 = Input                  'Dauerlauf
Portd.5 = 1
Dauerlauf Alias Pind.5

> Aber in der Hilfe von AVR hatte ich den Hinweis nicht gefunden.

Welche Hilfe von AVR? Von Bascom?

Bascom schützt Dich ein wenig vor den Details der Hardware, ab einem 
bestimmten Punkt muss Du, der Programmierer selber ran und Wissen 
vorweisen.

Dass es bei diesen AVRs PORT, PIN und DDR-Register gibt, gehört zum 
notwendigen Grundwissen und geht auch aus dem Datenblatt des verwendeten 
ATmega8 hervor. Wasch mich, aber mach mich nicht nass funktioniert 
nicht.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

Die Bezeichnung PinD.7 könnte man zum leichteren erinnern so 
expandieren:

(P)ort (In)put auf PORT(D) Bit(.7)

Gruss,
Gerhard

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Keine Gerüchte schrieb:
>> Kunststück! Wenn man einen EINGANG abfragen will, muß man eben fragen,
>> was am PIN passiert.
>
> Wenn ich den Port als Eingang definiere, dann gehe ich erst mal davon
> aus, das, wenn ich den Port abfrage das Bascom weis das es ein Eingang
> ist.

Solche grundlegenden Probleme kann man schön im Buch von Claus Kühnel 
studieren.

https://www.bod.de/buchshop/programmieren-der-avr-risc-microcontroller-mit-bascom-avr-claus-kuehnel-9783907857144/

Autor: Äxl (geloescht) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
komt denn ein Puls vom Wobbler gleichzeitig zur seriellen ausgabe? Das 
ist doch alles vorhersehbat und streng sequntiell.
Als sich zu tiefsten DOS Zeiten dieBeiden Grorillas noch mit Babanen 
beschmissen haben, war (Q)Basic natürlich standard. Gab soger ne 
Möglichkeit, sowas zu compileren.
Ich habe in letzter Zeit viel bis sehr viel mit "fastavr" gemacht. 
Leider wurde die weiterentwicklung/ die Anpassung auf neue AVR-Typen 
vernachlässigt bzw. komplett eingestellt. aber Bascom hatte immer so ein 
klein wenig unbehaben bei mir erzeugt.
Ihc habe mir für kleine Sachen jetzt ein paar Arduino Micro besorgt und 
die pasende Umgebeung. Lass die mal alle meckern. man kommt super 
schnell zum Ziel. Ist aber "C" bzw "C++", also dann sogar 
objektorientiert. Wobei ich das ziemlich überzogen finde, auf einem 
kleinen AVR mit OOP zu arbeiten.
---
Ich habe keinerlie Bedenken, das es in deiner speziellen Anwendung zu 
Problemen im Interrupptgesteuerten Betrieb kommen wird.
Ich hätts wahrscheinlich aufm Arduino umgesetzt oder auf'm Atmega8 in 
FastAVR. eben jeder, wie er kann.
Aber dieses "von oben nach unten programmiere" wäre mir nix.
Ich würde dort einen ordentlichen Zustandsautomaten aufsetzen und 
wirklich nur auf Flags warten und via "SELECT CASE" in die "abteilungen" 
springen, schnell den Kram abarbeiten, das Flag lschen und wieder auf 
die nächsten Flags lauern.
Der geht da alles sooo schnell in dem µC, da beisst sich nix.

Autor: Äxl (geloescht) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sind n paar Rechtschreibfehler drinn, welcher ob meiner augenblicklichen 
Sitzhaltung relativ zur Tastatur geschuldet sind, sry - 73

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
michael_ schrieb:
> https://www.bod.de/buchshop/programmieren-der-avr-...

Du hast recht vielleicht sollte ich mir mal ein wenig Literatur darüber 
zulegen.

MWS schrieb:
> Bascom tut das, was Du anschaffst. Es kann ja Dein Wunsch sein
> festzustellen, ob der Pullup gesetzt wurde. Das würde man durch Abfragen
> des PORT-Registers erfahren, selbst wenn der Port auf Eingang
> konfiguriert ist. Der Compiler kann und soll auch nicht vermuten, was Du
> willst.

OK ich weis es ja jetzt.

Äxl (geloescht) schrieb:
> komt denn ein Puls vom Wobbler gleichzeitig zur seriellen ausgabe?

nein die serielle Ausgabe kommt nach der eigentliche Messung der 
Frquenz.

Also Puls vom Wobbler , dann Messung im Zähler ( zur Zeit auf 1mS 
eingestellt, könnte aber später auch 10ms sein ) dann die serielle 
Übertragung vom Zähler an den Atmega 8.

also sogesehen sequenziell.

Aber wenn der Puls vom Wobbler kommt, dann sollte der Zähler möglichst 
Zeitnah beginnen zu messen, weil das sweepen nur( in diesen Falle ) ca 
1,3ms lang angehalten wird. In dieser Zeit sollte der Zähler die Messung 
vollzogen haben.

Ralph Berres

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> das kann ich mal noch machen. Obwohl der Aussetzer verhältnismäßig
> selten ist.

Es gäbe eine Konstellation, in der ein Blockieren denkbar ist.

Nimm das. :D

Bei der Simulation fiel mir auch auf, dass im unteren Endanschlag des 
Strichbreitepotis die Anzeige dauernd aufgerufen wird, da solltest Du 
Deine Hysterese-Logik noch ändern.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MWS

Besten Dank für dein update. Ich habe mal die Ergänzungen noch 
eingebaut, welches bei Dauerlauf in die zweite Zeile Sweep off einträgt 
und bei

abgeschalteter zweite Marke in die zweite Zeile Marke2 aus einträgt.

Falls dir noch ein update einfällt, nehme bitte die Datei rberres_24.bas 
als Ausgangsbasis. Dann brache ich meinen Müll nicht nachzutragen.

Offensichtlich kannst du das Verhalten meines Programmes simulieren.
( Ich weis nicht wie es geht, drum probiere ich es im Zielsystem ).

Was den ADC Strichbreite betrifft, ist mmir das auch schon aufgefallen.

Das Problem ist, wenn ich mit dem ausgelesenen Code des ADCs kleiner als 
50 werde, funktioniert natürlich meine Abfrage ob Abweichnung kleiner 50 
nicht mehr.

Mir ist da auch momentan keine andere Alternative eingefallen, als die 
Anzeige im Display zu unterbinden, und nur noch den String zu senden.

Ich bin mir momentan Gedanken am machen ob es was hilft den ADC Wert 
über 16 Abtastungen zu mitteln.

Aber dazu muss ich mir mal Gedanken machen wie man das am besten macht.

Momentan bin ich aber noch am verzweifeln nur den Inhalt des ADC Kanal2 
aufs Display zu bekommen.

Was ich auch noch nicht versucht habe, ob das Programm noch 
funktioniert, wenn ich die Messzeit auf 10ms hochsetze un eine Stelle 
mehr zu bekommen.

In meinen Wobbler kann ich über ein kleines Relais die Wartezeit auf ca 
12ms umschalten.

Aber einen Schritt nach dem anderen.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Offensichtlich kannst du das Verhalten meines Programmes simulieren.
> ( Ich weis nicht wie es geht, drum probiere ich es im Zielsystem ).

In Bascom ist ein Simulator eingebaut.

> Was den ADC Strichbreite betrifft, ist mmir das auch schon aufgefallen.
> Das Problem ist, wenn ich mit dem ausgelesenen Code des ADCs kleiner als
> 50 werde, funktioniert natürlich meine Abfrage ob Abweichnung kleiner 50
> nicht mehr.
> Mir ist da auch momentan keine andere Alternative eingefallen, als die
> Anzeige im Display zu unterbinden, und nur noch den String zu senden.

Schon überlegt was passiert, wenn man von einer Ganzzahlvariable mit 
Wert 0 die Zahl 50 abzieht?

Dimensionier' verwendete Variablen mit Integer statt Word, dann sollte 
das klappen.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
der zweite ADC funktioniert jetzt auch.

Bei Ablaufzeiten von länger 550ms ( entspricht einen ADCwert von 200 )

schaltet er jetzt an Portb.0 den Ausgang auf High, sendet den Befehl
10ms Messzeit und den Befehl 8 Stellen an den Zähler.

Bei kleineren Ablaufzeiten macht er ddas wieder rückgängig.

Mal sehen was mir noch einfällt.

Nachtrag

Mist jetzt geht dauerlauf nicht mehr.

Ralph Berres

: Bearbeitet durch User
Autor: Spocht-Therapeut (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ralph B. schrieb:

>
> Mist jetzt geht dauerlauf nicht mehr.

Machst Du bei den Temperaturen draußen doch sowieso nicht.

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der AVR speichert immer einen anstehenden Interrupt in einem Flag. Dies 
bedeutet: kam vor einer Stunde ein externer Interrupt rein und Du 
erlaubst die Interruptausführung jetzt, dann wird der "gemerkte" 
Interrupt unmittelbar nach dem Erlauben ausgeführt.

Bei sowas:
If Marke2_aus = 0 And Dauerlauf = 1 Then
  Disable Int1

Oled_data = Marke2aus
              Oled_show_data 2 , 1
Else
  Enable Int1
End If
muss man das Interruptflag also vor dem Erlauben löschen um böse 
Überraschungen zu vermeiden. Wie das für beide Flags geht, steht hier:
Gifr = Bits(intf1 , Intf0)
Für ein Flag, das Intf1, lässt Du einfach das Intf0 in Bits() weg, das 
M1_Flag würde ich auch zur Sicherheit löschen.

Ralph B. schrieb:
> Mist jetzt geht dauerlauf nicht mehr.

Der geht schon noch, Du musst nur seeehr lange darauf warten ;-)

Grund ist, dass ich mit:
If Dauerlauf = 0 Then
  If Dl_debnc = 1 Then
' ...
End If
eine kleine Entprellung gebaut habe, die notwendig wurde, um Probleme 
mit einem möglichen "Dauerlauf"-Schalterprellen zu vermeiden, wenn 
zeitgleich eine Marke getriggert wurde. Und für einen sauberen Übergang 
zwischen den Betriebs-Modi sorgt die auch noch.

Diese Entprellung benutzt jedoch die Laufzeit der Hauptschleife, die Du 
nun mit den Print-Ausgaben und der Messung des ADC deutlich verlängert 
hast.

Das was Du da machst ist auch sonst ungünstig, denn die Hauptschleife 
sollte so schnell wie möglich bleiben, damit sie auf eintreffende 
serielle Daten zügig reagieren kann.

Da tät's jetzt mehrere Möglichkeiten zur Behebung geben, welche auch in 
Kombination benutzt werden können, nach absteigender Priorität:

1) gepufferten Serialout installieren, dann haut er den ganzen 
Print-Kram in den Puffer und sendet im Hintergrund raus.
1.1) Den ADC-Kanal nur alle xxx ms oder xxxx Hauptschleifendurchgänge 
messen, für eine ordentliche Bedienung reicht alle 100 oder 200ms eine 
Messung, Du machst im Moment Messungen mit Maximalspeed.
2) Weg vom Zählen des Schleifendurchlaufs (ist eh ein wenig Murks) und 
hin zu einem Timer, der Dir bessere Verzögerungen oder Zyklen 
ermöglicht, ohne blockierend zu arbeiten. Man kann den laufenden Timer0 
umbauen und dafür benutzen, ich würde aber den Monoflop-Timer lassen wie 
er ist und einen weiteren Timer des ATMega8 verwenden.
..)
99) Verkleinern von Dl_preset

Ein Beispiel wie ein Soft-Timer für Deinen Zweck aufgebaut werden kann:
$Regfile = "m8def.dat"
$Crystal = 14745600
$hwstack = 64
$swstack = 32
$framesize = 32

Dim retrig_1 As Byte
Dim retrig_2 As Byte

Const retrig_1_preset = 5
Const retrig_2_preset = 10

Config Timer2 = Timer , Prescale = 1024                     ' 8-Bit Timer, 56,25 Überläufe pro Sekunde
On Timer2 timing
Enable Timer2                                               ' Overflow Interrupt erlauben

Enable Interrupts

Do
  If retrig_1 = 0 Then                                      ' ~ 88ms Aufrufrate
    retrig_1 = retrig_1_preset
    ' x = GetADC(0)
  End If
  If retrig_2 = 0 Then                                      ' ~ 177ms Aufrufrate
    retrig_2 = retrig_2_preset
    ' y = GetADC(1)
  End If
Loop

timing:
    If retrig_1 > 0 Then Decr retrig_1
    If retrig_2 > 0 Then Decr retrig_2
Return
Sowas hat natürlich ordentlich Jitter und erzeugt kein exaktes Timing, 
aber für relativ langsam zu wiederholende Aufgaben wie eine Messung alle 
xx ms reicht das allemal. Wenn die Körnigkeit der Soft-Zähler zu groß 
ist, dann verkleinert man den Prescaler und bekommt dafür mehr 
Prozessorlast.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo MWS

mir würde es prinziepiell reichen, wenn die ADCs alle 100mS abgefragt 
werden würde.

In der ADC Abtastung kann es auch ruhig zu einen Jitter kommen. Das ist 
vollkommen unkritisch.

Der zweite ADC schaltet je nach Ablaufzeit die Messzeit des Zählers auf 
1ms bzw 10ms um, der sweep wird für 1,5ms bzw 15ms angehalten.

Während des Dauerlaufes ist ja überhaupt kein Sweep vorhanden.

Ich hoffe das es mir irgendwie geling dein Beispielscode in dein 
Programm einzubinden.

Ich muss mich nachher mal dransetzen und schauen, wie damit ich komme.

Ralph

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> mir würde es prinziepiell reichen, wenn die ADCs alle 100mS abgefragt
> werden würde.

Schon klar, es geht nur um Bedienerfeedback, 10 Abfragen pro Sekunde 
sind locker ausreichend.

> Ich hoffe das es mir irgendwie geling dein Beispielscode in dein
> Programm einzubinden.

Da bin ich guter Dinge, es müssen ja nur aus dem Beispielcode die 
einzelnen Blöcke in Deinen Code übertragen werden.

> Während des Dauerlaufes ist ja überhaupt kein Sweep vorhanden.

Trotzdem muss man das Umschalten auf den jeweils anderen Codeteil sauber 
trennen, das hat in Folge dazu geführt dass es funktionierte.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS

ich werde mich morgen nochmal dran setzen.

Heute muss ich noch die Buchhaltung für meine Mutter machen. Die ist so 
gut wie blind.

Bis morgen

Ralph

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> ich werde mich morgen nochmal dran setzen.

Es eilt nichts. Manchmal hab' ich über den Tag viel, manchmal wenig 
Arbeit, das kommt recht zufällig. Dann kann ich auch erst antworten, 
wenn Zeit da ist.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
MWS bitte schaue mal über den Code.

Ich habe alles was ich seit deinem letzten Vorschlag gelesen habe , so 
gut wie möglich in den Code übertragen.

Was ich von dir ergänzt habe, habe ich mit Version45 kommentiert.

Doch ich habe wohl ein paar Fehler gemacht, weil ich es nicht besser 
weis, und mir ein paar Dinge unklar sind.

Jedenfalls blinkt jetzt das Logo und kommt nicht weiter.


Ralph Berres

Autor: Äxl (geloescht) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal uns mal bitte in Blockschaltbild auf, wo was mit wem verbunden ist. 
Ichkanns mir fast denken - andere evtl. nicht...
Hast Du einen SWOB5 und einen Zähler, sind die beide miteinander 
verbunden, oderwie?
Dankeschön...
Äxl

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das jetzt mal auf die schnelle handschriftlich skizziert.

falls Fragen sind bitte fragen.

Mein Swob5 ist von mir schon stark erweitert.
er hat z.B. 2 verschiebbare Marken statt wie im Original nur 1.
Die zweite verschiebbare Marke ist abschaltbar.

An den verschiebbaren Marken messe ich nicht nur die Frequenz sondern 
auch den Pegel der beiden Eingänge

Zusätzlich zu den im Original vorhandenen dekatischen Marken von 
100MHz,10MHz und 1MHz, erzeugt das Frequenzzählermodul von Michael Nowak 
zusätzlich dekadische Marken von 1MHz, 100KHz, 10KHz und 1KHz

Es ist zusätzlich eine PLL eingebaut, welche das wobbeln schmalbandiger 
Filter erlaubt.

Ralph Berres

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Ich habe alles was ich seit deinem letzten Vorschlag gelesen habe , so
> gut wie möglich in den Code übertragen.

Um einen Totalschaden zu produzieren ;D

"timing" ist eine ISR, die in die Hauptschleife zusammen mit einem 
weiteren Do-Schleifenstart reinzubacken und dann mit "Goto" wild 
herumzuspringen ist schon Evel-Knievel-mäßig.

Schau ob der Anhang funktioniert.
Den empfohlenen gepufferten Serialout hab' ich mit reingeschrieben.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo mws


Ich habe dein File jetzt mal geladen. Es funktioniert schon besser.

Jedoch passiert es beim Umschalten auf Dauerlauf, das es mal geht und 
mal nicht.

Im Falle wenn es nicht geht, werden die Messung der beiden letzten 
Marken eingefroren.



so etwa 5 mal geht es dauert aber zwischen einer halben Sekunde und 5 
Sekunden bis er umschaltet, und einmal friert er ein.

Ich habe die Schleife im Dauerlauf mal von 128000 auf 32000 verkürzt.

Jetzt kommt er beim umschalten ziemlich direkt ca 200msek

Bleibt nur noch das er ab und zu das letzte Messergebnis einfriert.

Notfalls kann man damit leben.

Mich interessiert allerdings was ich alles falsch gemacht habe.

Ralph

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> so etwa 5 mal geht es dauert aber zwischen einer halben Sekunde und 5
> Sekunden bis er umschaltet, und einmal friert er ein.

Das hatten wir bereits und dachten es behoben, als die simple 
Entprellroutine drin war.

> Notfalls kann man damit leben.

Nö, sicher nicht, wenn man was schreibt, dann ordentlich.

> Mich interessiert allerdings was ich alles falsch gemacht habe.

Wie meinen?
Im Moment hab' ich was falsch gemacht, ich vermute die neue Entprellung.

Oder meinst Du, was Du falsch gemacht hast beim Einbau des 
Beispielcodes?
Erinnere Dich, wie die Brundel-Fly endete, dann kannst Du Dir's 
vorstellen ;D

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Wie meinen?
> Im Moment hab' ich was falsch gemacht, ich vermute die neue Entprellung.

Also mal ganz ehrlich.

1. Ich bewundere erstens deine Geduld mit mir
2. ich bewundere dich das du ein Programm schreiben kannst ohne Zugriff 
auf das Zielsystem zu haben, und es dann ogar funktioniert.

du hast bisher tolle Arbeit geleistet. Meine Hochachtung.

MWS schrieb:
> Oder meinst Du, was Du falsch gemacht hast beim Einbau des
> Beispielcodes?

genau das meine ich.

Da muss ich ziemlich viele Fehler auf einmal aus Unkenntnis gemacht 
haben.

Offensichtlich habe ich viele Teile deines Codes immer noch nicht 
verstanden,

und noch viel wichtiger fehlen mir wohl Grundkenntnisse im 
Programmieren.

Ralph Berres

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wenn mein Code vom 15.08.2018 14:32 funktionierte, dann kann es die 
geänderte Entprellroutine sein, die ich nun erneut umgestrickt habe.

Allerdings vermute ich eine Deiner Selbsteinbauten als Schuldigen, 
nämlich:
If Marke2_aus = 0 And DL_switch = 1 Then
  Disable Int1
    Oled_data = Marke2aus
      Oled_show_data 2 , 1
Else
  Enable Int1
End If
Dieser Teil bei XXX entzieht sich ein wenig meiner Entprellroutine, über 
die ich einen kontrollierten Übergang zwischen den Modi herstelle und 
dafür sorge, dass Schalterprellen nicht schnell und unkontrolliert den 
Modus wechselt.

Im anhängenden Code ist dieser Codeteil von Dir auskommentiert, Du 
kannst ja mal den Unterschied testen, wenn Du ihn wieder einbaust. Dein 
Code hat jedoch bereits einen prinzipiellen Fehler, indem mit 
Maximalspeed in der Hauptschleife Daten an's OLed schickt.

Dieser Fehler wäre aber bereits abgestellt, nach Umstellung werden 
sowohl die Messung als auch die Ausgabe vom Timer kontrolliert, beides 
erfordert nur eine niedrige Aufrufrate.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> If Marke2_aus = 0 And DL_switch = 1 Then
>   Disable Int1
>     Oled_data = Marke2aus
>       Oled_show_data 2 , 1
> Else
>   Enable Int1
> End If

uff da muss ich wohl beim hin und her kopieren einen Fehler gemacht 
haben.

Eigentlich sollte da folgendes stehen

'Ma2aus:

If Marke2_aus = 0 And Dauerlauf = 1 Then
Disable Int1

Oled_data = Marke2aus
              Oled_show_data 2 , 1

Else
Enable Int1

End If

das werde ich aber mal nachschauen.

oder habe ich hier wieder was falsch verstanden?

10:10

Ich habe gerade gesehen du hattest die Variable Dauerlauf in DL_switch 
umbenannt.



Ich habe dein Programm jetzt getestet. Erst mit auskommentierte MA2 aus

Es hat sich nichts geändert.

Ich habe daraufhin das MA2 wieder aktiviert.


Ralph

: Bearbeitet durch User
Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Es hat sich nichts geändert.

Da wärst jetzt ein wenig Debugging angesagt, d.h. schauen, ob er in den 
Block des Dauerlaufs geht und wenn ja, warum keine Anzeige kommt. Das 
ist nicht mehr zu simulieren, weil's mit den ganzen Interrupts und 
Einfluss externer Hardware schon ein wenig komplexer ist. Simulieren 
kann man dagegen einzelne Funktionsblöcke.

Ob der Prozessor sich in einem bestimmten Block aufhält oder einen 
anderen völligen Blödsinn macht, könnte man mit der LED feststellen, die 
ich vor gefühlten 20 Posts empfohlen habe.

Beim Debuggen gibt man Statusinformationen egal über welche Kanäle raus, 
über die serielle Schnittstelle, über's OLed, oder einfach mittels LED 
rausgeblinkt.

Solltest Du's nicht bemerkt haben, hier würde ich auf eine Antwort von 
Dir warten:
> Wenn mein Code vom 15.08.2018 14:32 funktionierte,

Denn da ich hier nicht debuggen kann, muss ich mir den Ablauf des 
Programms vorstellen und raten - auch mittels Details des Fehlverhaltens 
- was da wohl reinspuckt. Vermuten würde ich, dass es an den Input()s 
hängt. Diese müssten, auch wenn der Puffer voll ist, noch auf LFCR 
reagieren, also eigentlich dürfte nix hängen, tut's aber scheinbar.

Das könnte man testen, indem man alle Input()s auskommentiert und statt 
dessen Beispiel-Text ausgibt.

Du müsstest da ein wenig aktiver werden, denn Du hast den Patienten am 
Tisch und kannst schauen: was passiert, wenn ich das mache, usw.

Wenn ein Display nichts anzeigt, kann es das Display sein und es kann 
sein, dass das Display nicht beschrieben wird. Wenn's nicht beschrieben 
wird, warum? So in etwa müssten Deine Gedankengänge gehen und dann 
kommentiert man aus oder ein, schreibt Testcode dazu, kompiliert, lässt 
das Ding erneut laufen, usw.

Der Vorteil den Du hast ist, wenn der Fehler nach 5-6 Mal umschalten 
bereits auftritt, dann ist das häufig, sowas bekommt man gut raus. Im 
Gegensatz zu Fehlern, die sporadisch alle paar Tage auftreten.
Die Chancen stehen gut.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MWS

Ich muss einfach mal eine Pause machen. Mir qualmt das Hirn schon.

heute hatte ich den halben Tag damit verbracht einen Fehler in meinem 
IEC-Bus zu finden. Kein einziges Gerät lies sich noch ansprechen.

Nach dem ich bei mir die halbe Wand abgeräumt habe und ein Gwerät nach 
dem anderen abgeklemmt habe , habe ich dann zwei Fehler gefunden.

1. Mein IEC-Bus Expander National GPIB120A ist defekt. Sobald ich den 
dran habe blockiert er mir den ganzen Bus.

2. Ein Oszillograf hat sich aus unerfindlichen Gründen auf eine IECbus 
Adresse gestellt, die schon ein anderes Gerät beansprucht, und es kam zu 
Kollisionen.

Ich muss jetzt auch mal meine Bastelecke aufräumen, denn am Mittwoch 
bekomme ich Besuch aus Bonn.

Das Fehlersuchen in deinem Programm werde ich vielleicht in einer Woche 
noch mal aufnehmen. Dazu werde ich ein Port an verschiedene Stellen im 
Programm auf 1 setzen, um zu sehen wo das Programm im Fehlerfall 
hinspringt.

Ab und zu findet auch ein blindes Huhn auch mal ein Korn.

Bitte gebe mir ein paar Tage Zeit. Ich melde mich wieder.

Ich habe ja noch eine andere lauffähige Programmversion, welche 
zugegeben nicht so elegant gelößt ist.

Bis hierhin erst mal vielen vielen Dank für deine Mühe und deiner 
Geduld.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, kein Problem.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so es ging weiter. Allerdings momentan noch nicht mit dem Programm von 
MWS. Da habe ich zugegeben nicht mehr durchgeblickt.
Deswegen habe ich an meinen Programmcode weiter gearbeitet.

Zunächst hatte ich noch Routinen geschrieben welche anhängig vom 
Sweepbereich ( es gibt davon 3 nämlich PLL an 0-2MHz Wobbelhub Bereich 2 
0-50MHz Wobbelhub und Bereich 1 7-1400MHz Wobbelhub )die Anzahl der 
angezeigten Stellen und die Sweephaltezeit ( somit auch die Messzeit ) 
umschaltet.

Mir war irgendwann aufgefallen, das bei hoher Ablaufgeschwindigkeit ( 50 
Sweepdurchgänge/Sek ) der Zähler nur noch Mist angezeigt hat. Aber nur 
wenn beide Marken aktiv waren.

Ich habe lange gesucht und bin in der Displayroutine fündig geworden bei 
welcher eine Wartezeit von 5msek implementiert war.

Nach dem ich diese auskommentiert habe lief es bereits stabiler.

Zwischenzeitlich habe ich versucht im Internet über das Thema Interupt 
schlau zu machen. Dort habe ich wieder was gelernt. Das wenn ein 
Interupt ausgelöst wird, aber es noch gesperrt ist, weil ein anderer 
Interupt abgearbeitet wird, sich der Prozessor den zweiten Interupt 
merkt und ihn dann abarbeitet, wenn er wieder freigegeben ist.

Dei Konsequenzen konnte ich mit dem Oszillograf sehen, wenn ich mir den 
Triggerimpuls zu Nowaks Zähler angeschaut habe.

Man hat deutlich gesehen das der Nowak-Triggerimpuls im zeitlichen Bezug 
zur Markle 2 extrem geschwankt hat, wenn man die Ablaufgeschwindigkeit 
erhöht hat.

Ursache waren die 5ms Wartezeit in der Displayroutine , welche in der 
Interuptroutine aufgerufen wurde.

Mir hat das ganze aber keine Ruhe gelassen. Jetzt habe ich die 
Interuptroutinen dahingehend abgeändert, das ich jetzt nur noch das 
Setzen des Triggerports und das einlesen der RS232 Schnittstelle nebst 
abspeichern in einer Variablen in der Interuptroutine mache.

Das Einlesen der Variablen geschieht jetzt in der Hauptroutine.

Der Triggerimpuls am Ausgang steht jetzt stabil.

ich stelle die Version 10 und 11 sowohl als BAS als Uch als RTF Datei 
hier ins Forum.

Mir ist bewust das mein Programmcode immer noch stümperhaft ist, aber 
besser bekomme ich es mit meinen Kenntnissen einfach noch nicht hin.

Also bitte mich nicht verhauen.

Ralph Berres

Ralph Berres

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade auf eine Webseite gestossen, wo das einlessen der rs232 
recht gut erklärt ist
https://halvar.at/elektronik/kleiner_bascom_avr_kurs/uart_rs232_vom_computer_2/

Zur Zeit habe ich mein Code ja dahin abgeändert, das in den 
Interuptaufrufen nur noch der Triggerausgang für den Nowakzähler gesetzt 
wird und mit dem Befehl Input die RS232 Schnittstelle vom Nowakmodul 
eingelesen wird, und die Interuptroutine erst mit CR der 
RS232Schnittstelle verlassen wird. Siehe Version11 im vorherigen Thread.

Es ist also folgender zeitlicher Ablauf

1.Triggerimpuls vom Swob5 an den entsprechenden Interupteingang.
2.Swob5 hält seinen Sweep für 1,5ms oder 15ms an
3.Der Interupt sendet ein Triggerimpuls an den Nowakzähler.
4.Der Nowakzähler sendet nach 1ms bzw 10ms Messzeit via RS232 einen 
String mit LF/CR am Ende zurück.( oder ist die Reihenfolge LF/CR?
muss ich nachschauen ). Das Senden des Strings dauert bis zu 1,4ms
Gespeichert wird der String in eine Variable.

5.Jetzt erst kommt das Return um den Interupt zu beenden.

Das Einlesen der Variable ins Display erfolgt in der Hauptschleife.

Das funktioniert auch offenbar ganz gut, weil der Sweep ja eh für die 
Zeit angehalten wird.


Meine Frage ist folgende

Macht es überhaupt noch Sinn das Einlesen des RS232 Stringes auch noch 
via Interupt zu machen? Siehe Beispiel im oben angeführten Link.

Ich müsste dann den Markeninterupt vor dem Einlesen des Strings mit 
Return verlassen und dann ( wenn ich es richtig verstanden habe ) mit 
eintreffen des CR einen Softwareinterupt auslösen, welches das Schreiben 
in die Variable veranlasst.

Wenn ich es so mache, besteht bei dieser Vorgehensweis nicht die Gefahr 
das ich mir der zweite Markeninterupt der ja schon im extremfall nach 
Ablauf des ersten Triggerimpulses vom Swob5 1ms später ausgelöst wird, 
mir entweder das lesen der RS232 Nachricht verhindert, oder umgekehrt 
das auslösen des zweiten Interupts verhindert?


Vielleicht kann mir jemand dazu was sagen?

Ralph Berres

: Bearbeitet durch User
Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Version 12 habe ich dafür gesorgt das mit Hilfe von im Interupt 
gesetzten Flags das Display nur aktualisiert wird wenn ein Interupt 
eintrifft.
Ansonsten springt er über die Displayroutine weg.

Das funktioniert auch.

Was ich nicht zum laufen bekomme ,

Ich wollte in Version 13 den Vorschlag von


https://halvar.at/elektronik/kleiner_bascom_avr_ku...
realisieren, das auch das einlesen des Strings einen Interupt auslöst.

doch ich erhalte entweder ein schwarzes Display oder ab und zu mal Müll.

Hat jemand eine Idee was ich falsch mache?

Ich habe bei jeder Zeile die ich in der jeweilgen Version geändert habe 
die Versionsnummer als Kommentar dahinter geschrieben, um Änderungen 
besser auffindbar zu machen.

Im Kopf des Programmes steht drin welche Version welche Änderungen 
gemacht wurden.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> doch ich erhalte entweder ein schwarzes Display oder ab und zu mal Müll.

Dir kam nicht die Idee in der Hilfe nachzulesen, was es mit einer als 
Local dimensionierten Variable auf sich hat?

Was wird wohl passieren, wenn eine Variable Serialstring_m1, mit 
gleichem Namen einmal global und einmal lokal dimenioniert wird? Meinst 
Du nur weil die gleich geschrieben sind, dass die dann eine Art magische 
Beziehung bekommen?

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Dir kam nicht die Idee in der Hilfe nachzulesen, was es mit einer als
> Local dimensionierten Variable auf sich hat?
>
> Was wird wohl passieren, wenn eine Variable Serialstring_m1, mit
> gleichem Namen einmal global und einmal lokal dimenioniert wird? Meinst
> Du nur weil die gleich geschrieben sind, dass die dann eine Art magische
> Beziehung bekommen?

Sorry

Danke für den Hinweis

Das muss ich mir morgen noch mal genauer anschauen, ob ich hier 
tatsächlich Variablen doppelt vergeben habe.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Das muss ich mir morgen noch mal genauer anschauen, ob ich hier
> tatsächlich Variablen doppelt vergeben habe.

Yep, Du hast:
Dim Serialstring_m1 As String * 20
...
Sub Serial0charmatch()
   'If Marke1_flag = 1 Then
   Local Serialstring_m1 As String * 30

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MWS

Ic habe im Header die Variablendefinition mal gelöscht. Doch ich komme 
nicht weiter.

Bein Compilieren bekomme ich Fehlermeldungen.

Auch umbennenen von variablen hat mich nicht weiter gebracht.

Ralph

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Bein Compilieren bekomme ich Fehlermeldungen.

Verständlich.

Ralph B. schrieb:
> Ic habe im Header die Variablendefinition mal gelöscht.

Warum? Das ist doch sinnlos und auch noch kontraproduktiv.
Hättest Du meinen Hinweis aufgenommen, nach "Local" in der Hilfe zu 
suchen, dann wäre Dir klar welchen Unsinn Du produzierst.

> A LOCAL variable is a temporary variable that is stored on the frame.

Temporär = zeitweilig.
Frame = Speicherbereich, der von mehreren Programmteilen nach Bedarf 
benutzt wird.

Da Du in der Serialcharmatch, welche lediglich eine "Verlängerung" des 
UART Receive Complete Interrupts ist, nichts anderes machst als die 
Daten abzuholen und in eine zeitweise Variable zu schreiben, die nach 
Verlassen der Interruptserviceroutine zerstört wird, ist Dein 
Unterfangen eben ziemlich zweckfrei.

Autor: Ralph B. (rberres)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist jetzt die endgültige lauffähige Version, die offenbar ohne 
Fehler bei mir läuft.

Ich danke allen die mir bei dem ziemlich beschwerlichen Weg zur Seite 
gestanden haben.

Auch wenn jetzt nicht das Programm von MWS zum Einsatz gekommen ist ( 
Ich habe meinen Fehler einfach nicht gefunden ), möchte ich mich auch 
ausdrücklich bei MWS noch mal für seine Geduld und Mühe bedanken.

Ralph Berres

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Hier ist jetzt die endgültige lauffähige Version, die offenbar ohne
> Fehler bei mir läuft.

Dann wurde Dein Ziel erreicht.

> Auch wenn jetzt nicht das Programm von MWS zum Einsatz gekommen ist

Das Risiko Zeit zu verschwenden indem eigener Code angeboten wird, war 
mir im Vorhinein bewusst, das kann man nur machen, wenn's einem selbst 
etwas bringt. Dass Du wieder zurück auf Dir bekanntes, d.h. auf eigenen 
Code zurückfällst, ist natürlich und hier ja auch geschehen.

Autor: Ralph B. (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> wenn's einem selbst
> etwas bringt.

falls du mit mir in Verbindung bleiben willst, gerne.

Vielleicht kann ich dir in der einen oder anderen Frage ja weiter 
helfen.

Es muss sich ja nicht um Programmcode handeln. Da sind die allermeisten 
hier ja eh mir um Längen vorraus. Ich mache das ja nur aus der Not 
heraus, nicht weil es mir Spass macht.

Ralph Berres

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.

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