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
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
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.
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
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/
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...
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.
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?
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
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
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.
.
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
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.
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
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
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
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 testenRalph 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:
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
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
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
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.
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
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.
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
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
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.
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.
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
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:
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.
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
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
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
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 abschalten