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
scheint sich wohl keiner damit auszukennen Ralph Berres
BASKOM ist BAH! Für die Spezies hier. Lese mal die Anleitug sorgfälltig durch und/oder gehe in eines der speziellen BASKOM Foren.
Vermutlich weil da ein "," als Trenner in der Frequenz ist, und kein ".".
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?
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
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.
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
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.
Simpelbeispiel:
1 | ' ... |
2 | $TIMEOUT = 1000000 ' verschiedene Werte selber testen |
3 | Config Input = LFCR ' Sicher dass vom Modul nicht CRLF kommt? |
4 | ECHO OFF ' mit Echo würden über Input empfangene Daten zurückgegeben und das Modul sich verschlucken |
5 | ' ... |
6 | Marke1: |
7 | ' ... |
8 | '*************** Characters über UART empfangen **************************** |
9 | Input Serialstring_m1 |
10 | |
11 | 'in Zeile 1 anzeigen |
12 | Oled_col = 1 'Zeile = 1 |
13 | ' ... |
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.
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!
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.
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
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?
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:
1 | Print "mache meine eigentliche Arbeit" 'für Test |
2 | Print "Blablabla" 'für Test |
3 | 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.
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.
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
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
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
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.
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.
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
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
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.
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
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.
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
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
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:
1 | 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.
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
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.
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.
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.
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
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
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:
1 | 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.
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 ;-)
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.
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
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.
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
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
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:
1 | Dim Char_buffer1(16) As String * 1 |
2 | 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:
1 | GIFR.INTF0 = 1 |
2 | Do |
3 | If GIFR.INTF0 = 1 Then |
4 | Portd.6 = 0 |
5 | Pulseout Portd , 6 , 6000 'Triggerimpuls 150µs |
6 | Input Serialstring_m1 |
7 | ' ... |
8 | GIFR.INTF0 = 1 |
9 | End If |
10 | ' ... |
11 | Loop |
Im Vergleich zum Pollen des betreffenden Pins merkt sich der Prozessor über das Flag, ob eine Flankenwechsel statt fand.
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.
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...
Angehängte Dateien:
-
2018-08-09_175435.png
8,9 KB -
2018-08-09_175405.png
2,9 KB
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
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 ;-)
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
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.
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?
Bitte Leute streitet euch nicht. Es ist der Sache nicht einfach nicht wert. Ralph Berres
Frust an Tag und Langweile am Abend findet man in diesem Forum wieder.
Ralph B. schrieb: > Bitte Leute streitet euch nicht. Wir streiten nicht, wir diskutieren intensiv ;-)
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
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.
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
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
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
> Frag mal die Maus.
Alle wollen meine Programme mit mir 'teilen' aber keiner sein Geld ;-)
Warum essen wir heute Fisch? ...
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
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
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.
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
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
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?
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
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.
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
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.
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
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.
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
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
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?
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.
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.
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
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:-)
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
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.
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
CKopt stand bei mir auf 1 Ralph Berres
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!
Ralph B. schrieb: > den Brown Out Detektor habe ich auf 4V eingestellt und enablet, das > hatte aber keine Auswirkung. Welche Programmer-GUI verwendest Du?
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
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
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.
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
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.
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.
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
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.
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
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?
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...
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
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.
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.
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
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:
1 | Const to_wait_chars = 2 |
2 | Const wait_timeout = (_xtal / (_baud / 10) * to_wait_chars) / 82 |
3 | Const init_timeout_preset = wait_timeout * 5 |
4 | 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?!
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
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
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
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.
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
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.
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
Von einem Freund habe ich diesen acht Kanal Salae kompatiblen L.A. Der dekodiert RS232, SPI, I2C problemlos: https://www.ebay.com/itm/24MHz-8CH-USB-Logic-Analyzer-24MHz-8-Channel-Compatible-to-Saleae-ARM-FPGA-M100/253686603328?hash=item3b10e65e40%3Ag%3AqeoAAOSwkKBa%7E8Ls&_sacat=0&_nkw=logic+analyzer+saleae&_from=R40&rt=nc&_trksid=p2380057.m570.l1311.R5.TR11.TRC1.A0.H0.Xlogic+anal.TRS0 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
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
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
wenn ich die Dauerschleife kürzer mache dann tritt auch hier der Fehler auf.
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.
Gerade noch übersehen, ändere: > Const init_timeout_preset = wait_timeout * 5 in: > Const init_timeout_preset = wait_timeout * 30
er zeigt unsinnige Werte 2 stellig in MHz an. ich mache morgen weiter. Ralph
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 ;-)
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
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.
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():
1 | ' ... |
2 | Loop Until time_out = 0 |
3 | If time_out = 0 Then |
4 | PortD.4 = 1 : Waitms 100 : PortD.4 = 0 |
5 | End If |
6 | read_UART = rslt |
7 | 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.
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
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.
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.
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.
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
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 ;-)
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
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
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.
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.
1 | Example2 |
2 | |
3 | '----------------------------------------------------------------------------------------- |
4 | |
5 | 'name : |
6 | |
7 | 'copyright : (c) 1995-2016, MCS Electronics |
8 | |
9 | 'purpose : test for M2560 support |
10 | |
11 | 'micro : Mega2560 |
12 | |
13 | 'suited for demo : yes |
14 | |
15 | 'commercial addon needed : no |
16 | |
17 | '----------------------------------------------------------------------------------------- |
Hast Du das nicht gefunden? https://avrhelp.mcselec.com/index.html?config_serialin.htm
:
Bearbeitet durch User
Gerhard O. schrieb: > Hast Du das nicht gefunden? NoScript hat dies bislang verhindert. Jetzt ist alles klar!
Mi N. schrieb: > Gerhard O. schrieb: >> Hast Du das nicht gefunden? > > NoScript hat dies bislang verhindert. Jetzt ist alles klar! Danke:-)
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.
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
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...
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
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
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.
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
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
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?
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
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"
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
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.
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:
1 | 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:
1 | $hwstack = 192 |
2 | $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.
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
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
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:
1 | Config Portd.5 = Input 'Dauerlauf |
2 | Portd.5 = 1 |
3 | 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.
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
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/
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.
sind n paar Rechtschreibfehler drinn, welcher ob meiner augenblicklichen Sitzhaltung relativ zur Tastatur geschuldet sind, sry - 73
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
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.
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
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.
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
Ralph B. schrieb: > > Mist jetzt geht dauerlauf nicht mehr. Machst Du bei den Temperaturen draußen doch sowieso nicht.
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:
1 | If Marke2_aus = 0 And Dauerlauf = 1 Then |
2 | Disable Int1 |
3 | |
4 | Oled_data = Marke2aus |
5 | Oled_show_data 2 , 1 |
6 | Else |
7 | Enable Int1 |
8 | 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:
1 | 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:
1 | If Dauerlauf = 0 Then |
2 | If Dl_debnc = 1 Then |
3 | ' ... |
4 | 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:
1 | $Regfile = "m8def.dat" |
2 | $Crystal = 14745600 |
3 | $hwstack = 64 |
4 | $swstack = 32 |
5 | $framesize = 32 |
6 | |
7 | Dim retrig_1 As Byte |
8 | Dim retrig_2 As Byte |
9 | |
10 | Const retrig_1_preset = 5 |
11 | Const retrig_2_preset = 10 |
12 | |
13 | Config Timer2 = Timer , Prescale = 1024 ' 8-Bit Timer, 56,25 Überläufe pro Sekunde |
14 | On Timer2 timing |
15 | Enable Timer2 ' Overflow Interrupt erlauben |
16 | |
17 | Enable Interrupts |
18 | |
19 | Do |
20 | If retrig_1 = 0 Then ' ~ 88ms Aufrufrate |
21 | retrig_1 = retrig_1_preset |
22 | ' x = GetADC(0) |
23 | End If |
24 | If retrig_2 = 0 Then ' ~ 177ms Aufrufrate |
25 | retrig_2 = retrig_2_preset |
26 | ' y = GetADC(1) |
27 | End If |
28 | Loop |
29 | |
30 | timing: |
31 | If retrig_1 > 0 Then Decr retrig_1 |
32 | If retrig_2 > 0 Then Decr retrig_2 |
33 | 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.
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
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.
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
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.
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
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
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
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.
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
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
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
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:
1 | If Marke2_aus = 0 And DL_switch = 1 Then |
2 | Disable Int1 |
3 | Oled_data = Marke2aus |
4 | Oled_show_data 2 , 1 |
5 | Else |
6 | Enable Int1 |
7 | 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.
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
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.
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
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
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
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
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?
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
Ralph B. schrieb: > Das muss ich mir morgen noch mal genauer anschauen, ob ich hier > tatsächlich Variablen doppelt vergeben habe. Yep, Du hast:
1 | Dim Serialstring_m1 As String * 20 |
2 | ... |
3 | Sub Serial0charmatch() |
4 | 'If Marke1_flag = 1 Then |
5 | Local Serialstring_m1 As String * 30 |
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
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.
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
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.