Reset HW-Stack Bascom

Das hört sich nach Murks an.
Die Lösung den WDT einen Reset machen zu lassen ist bekannt ?
Ansonsten, den Stack muss man nicht löschen, wozu auch ? Aber der 
Stackpointer SP müsste neu initialisiert werden.

Da muss ich dir zustimmen. Sauber Programmiert ist das nicht, aber ich 
sehe in dem Zusammenhang keine andere Lösung. Es wäre auch nur eine 
Vorübergehende Lösung. Die aktuelle Beschaltung des uc erfordert leider 
solch verzweifelten Taten :).

Das der Watchdog einen Reset durchführen kann ist mir bekannt. 
Allerdings nach einer gewissen Zeit. Ich bräuchte quasi einen Watchdog 
der von externen Signalen ausgelöst werden kann.

Beim Stackpointer hab ich mich Vllt etwas falsch ausgedrückt. Ich möchte 
die Rucksprungadresse sowie die Registerinformation welche bei auslösen 
des Interrupts auf den von Bascom angelegt HW-Stack gepusht werden 
wieder Popen damit der Stack nicht überläuft.

Die Frage ist nun wie ich das in Bascom implementiere. Ich meine gelesen 
zu haben dass der HW-Stack in Bascom je nach Größe des Programms und das 
Stacks an unterschiedlichen Adressen im Speicher stehen kann. Eine von 
mir angelegt Funktion welche einfach die Infos vom Stack popt ist damit 
schwer zu realsieren.

Hi

Um welchen Controller geht es denn überhaupt? HW-Stack ist keine 
Funktion von Bascom, sondern ist im Aufbau einiger AVRs begründet. Bei 
einem AVR mit HW-Stack (z.B. ATTiny15) gibt es keine Möglichkeit den 
Stack manuell zurückzusetzen. In keiner Programmiersprache.

MfG Spess

Es handelt sich um einen AT-Mega 128. Dass es keine Methode gibt würde 
ich jetzt nicht auf Anhieb unterschreiben. Schließlich wird jedes mal 
wenn ein "Return" aufgerufen wird ebenfalls vom Stack gepopt. Leider 
auch anschließend an die entsprechende Stelle gesprungen weswegen ich 
das nicht verwenden kann.
Weiterhin steht in der Bascom Hilfe das der HW-Stack sich im SRAM 
befindet also zwischen sämtlichen Variablen die im Programm definiert 
werden.

Wenn man allerdings weiß an welcher Adresse genau sich der Stack 
befindet, sollte es doch ein leichtes sein via Assembler den 
Stackpointer zu manipulieren.

Noch ein Argument was gegen die Behauptung spricht, der Hardwarestack 
habe einen exklusiven Speicherplatz, ist die Definition. Wenn im ATMega 
ein Stück Speicher für den HW-Stack allokiert ist, macht es keinen Sinn 
ihn zu definieren. Da er immer eine bestimmte Größe haben muss. Im SRAM 
macht es hingegen schon mehr Sinn da unnötig allokierter Speicher 
unnötig viel SRAM verbraucht.

Trotzdem danke für die Antworten ;)

Hi

Irgendwie ist die Bezeichnung 'Hardwarestack' von Bascom irreführend. 
Bei AVRs hat das eine andere Bedeutung.

Der ATMega128 besitzt einen Stackpointer, also die Register SPL und SPH. 
Normalerweise werden die beim Programmstart mit der höchsten RAM-Adresse 
initialisiert. Ob das BASCON anders macht weiß ich nicht.

MfG Spess

spess53 schrieb:
> Irgendwie ist die Bezeichnung 'Hardwarestack' von Bascom irreführend.

Bascom kennt auch einen Softwarestack, deshalb die Unterscheidung. Der 
Hardwarestack beginnt wie üblich bei RAMEND.

0815User:) schrieb:
> Das der Watchdog einen Reset durchführen kann ist mir bekannt.
> Allerdings nach einer gewissen Zeit. Ich bräuchte quasi einen Watchdog
> der von externen Signalen ausgelöst werden kann.

Man könnte die kleinste WD Zeit einstellen und dann den WDT in eine 
Do/Loop laufen lassen.

> Beim Stackpointer hab ich mich Vllt etwas falsch ausgedrückt. Ich möchte
> die Rucksprungadresse sowie die Registerinformation welche bei auslösen
> des Interrupts auf den von Bascom angelegt HW-Stack gepusht werden
> wieder Popen damit der Stack nicht überläuft.

Wenn Du an den Resetvektor springen willst, so kannst Du das mit:

1

Goto 0

erledigen.
Daraufhin wird von der Bascom-Init der Stack sowieso wieder neu 
initialisiert, also SPL/SPH auf RAMEND gesetzt. Eventuelle 
Rücksprungadressen oder gepushte Register sind damit "vergessen".

Die Bascom-Init löscht in Folge den SRam. Was allerdings nicht passiert, 
ist daß der IO-Bereich zurückgesetzt wird, ein Timer wird weiterlaufen 
und sobald die Interrupts wieder erlaubt sind, werden anstehende Ints 
auch ausgeführt.

Das hier würde den Stackpointer neu initialisieren, aber da solltest Du 
schon sehr genau wissen, was Du machst:

1

!LDI   R24,   lbyte(_HWSTACKSTART)

2

!OUT   SPL,   R24

3

!LDI   R24,   hbyte(_HWSTACKSTART)

4

!OUT   SPH,   R24

Wird Goto 0 auch explizit ausgeführt wenn der Watchdog anspringt. Klingt 
ja nach interessanten Lösungen. Bin mir gerad aber unschlüssig ob das 
die richtigen Ansätze sind.
Deswegen gerad nochmal was ich eigentlich vorhab. Interrupt tritt auf 
und IR-Routine wird ausgeführt. Anschließend soll an eine bestimmte 
Adresse in der Hauptschleife gesprungen werden.
Dabei treten zwei Probleme auf. Erstens ist durch die gesetzten Register 
sämtliche anderen Interrupts blockiert und zweitens konnte der Stack 
überlaufen und den uc Abstürzen lassen.

Deswegen mein Plan die Register zu löschen und damit sämtliche Spuren 
des Interrupts zu löschen.

Was mir noch nicht ganz klar ist, was passiert genau bei einem goto 0?

vielen dank für die vielen Tipps

Mfg

0815User:) schrieb:
> Wird Goto 0 auch explizit ausgeführt wenn der Watchdog anspringt.

Wenn der WD anspringt, dann wird ein Hardwarereset ausgeführt, in dessen 
Folge der Resetvektor mit Programm- = Flashadresse 0 angesprungen wird. 
Nach dem Resetvektor sind im Flash die Interruptvektoren angeordnet, 
also enthält der Resetvektor wiederum einen Sprungbefehl auf das 
eigentliche Programm, welches dann unmittelbar nach den Interrupvektoren 
folgt.

Der Unterschied von Soft-Reboot zu Hard-Reboot ist, daß beim Hardboot 
der IO-Bereich auch auf vordefinierte Werte gesetzt wird, während beim 
Softboot dies nicht passiert.

0815User:) schrieb:
> Interrupt tritt auf
> und IR-Routine wird ausgeführt. Anschließend soll an eine bestimmte
> Adresse in der Hauptschleife gesprungen werden.

Solche Verrenkungen sind bei vernünftiger Programmierung überhaupt nicht 
notwendig. Wenn die Hauptschleife immer durchlaufen wird, dann ist's 
kein Problem bei erfolgten IR-Befehl zu verzweigen. Da darf man 
natürlich nichts mit langen Waits gemacht haben.

Zeig' doch mal Deinen Code.

Tatsächlich wäre es möglich dem Prozessor eine beliebige 
Rücksprungadresse unterzumogeln, so daß der Return aus der ISR auf eben 
diese Adresse erfolgt.

Das sind aber richtig üble Tricks, die in 99.999% aller Fälle unnötig 
sind. Und 'ne simple IR-Code Erkennung ist da keine Ausnahme.

Hi

>Wird Goto 0 auch explizit ausgeführt wenn der Watchdog anspringt.

Wenn als Frage gemeint: Ein Goto 0 ist nicht identisch mit einem, wie 
auch immer gearteten, Reset. Das gemeinsame ist, das das Programm an 
Adresse $00 anfängt. Aber bei einem Reset werden auch noch sämtliche 
I/O-Register auf Defaultwerte gesetzt.

MfG Spess

OK also wird mit Goto 0 die Speicheradresse 0 angesprungen. Das schon 
mal ein guter Start. Nun schreibt ihr noch das beim Softboot die IOs 
nicht initialsiert werden. Das eigentlich kein Problem da am 
Programmstart sowieso explizit alle IOs zugewiesen werden.
Zuvor wurde geschrieben das bei einem Goto 0 der Stackpointer 
initalisiert wird. Das müsste dann ja implizit passieren da es nicht in 
meiner Initialisierung passiert. Ist dem so?

Dass der Sachverhalt in die Kategorie absolut schlechte Programmierung 
fällt ist mir klar. Es gibt auch alternative Lösungen. Diese beinhalten 
aber ein neu Design des Boards sowie eine komplette Überarbeitung der 
Software da es mit dem aktuellen Layout nicht möglich ist. Der At-Mega 
war zu Beginn nur dafür verantwortlich mehrere diverse Takte zu 
erzeugen. Alle Timer gesteuert. Das ist das hauptsächliche Problem.
Interessant ist also wie ich entweder die Rücksprungadresse der 
Interruptroutine auf eine fixe Adresse zeigen lassen kann, oder wie ich 
den Stack sauber initalisieren kann sodass keine Werte mehr darin 
enthalten sind. Dann kann die Interruptroutine via goto verlassen 
werden, da hier ja keine Rücksprungadresse auf dem Stack angelegt wird.

Den Code zu posten will ich euch nicht antun. Sind weit über 1000 
Zeilen, meiner Meinung nach sowieso unübersichtlichen Bascom 
geschrieben.

Mfg

Ich kann Peter nur zustimmen, denn Programmieren bedeutet nicht, den PC 
anzuwerfen und irgendetwas in den Editor eines Compilers zu hacken. 
Programmieren bedeutet, sich die einzelnen Prozeduren und Funktionen als 
Ablaufdiagramm schriftlich aufzuzeichen, bis die gewünschten Reaktionen 
einzelner Programmschritte mit ihren Programmteilen definiert worden 
sind. Das Eintippen in der jeweiligen Sprache nennt man dann kodieren 
und hat in diesem Moment nichts mehr mit Programmieren zu tun.

0815User:) schrieb:
> Interessant ist also wie ich entweder die Rücksprungadresse der
> Interruptroutine auf eine fixe Adresse zeigen lassen kann, oder wie ich
> den Stack sauber initalisieren kann sodass keine Werte mehr darin
> enthalten sind. Dann kann die Interruptroutine via goto verlassen
> werden, da hier ja keine Rücksprungadresse auf dem Stack angelegt wird.

Ich denk' auch, daß das besser zu lösen ist.

Aber gut...

Die Rücksprungadresse wird vom Controller vor dem Sprung in die ISR auf 
den Stack geschoben. Wenn man weis wo die Adresse ist und sie popt und 
eine neue Adresse auf den Stack pusht, so wird beim RETI diese Adresse 
angesprungen. Es gibt ein paar Sachen die zu beachten sind, aber 
prinzipiell geht das.

Der Stack ist bereits mit Setzen des SPs auf RAMEND initialisiert.

Mir ist durchaus klar wie man eine Software richtig entwirft und 
anschließend umsetzt. Das steht hier eigentlich auch nicht zur Debatte. 
Aber um mich ein wenig zu rechtfertigen, die Software stammt nicht von 
mir. Ich bin lediglich dafür verantwortlich eine weitere Funktion 
hinzuzufügen. Dabei ist es mir aus zeitlichen Gründen aktuell nicht 
möglich die Software komplett neu in einem sauberen Programmfluss zu 
implementieren.

Die eigentliche Frage lautete kann man den Hardwarestack so 
manipulieren, dass aus einem Interrupt gesprungen werden kann ohne dabei 
wieder in die Interruptroutine zurück kehren zu müssen. Meiner Meinung 
nach ist das in Bascom nicht möglich. Ich dachte allerdings dass ich 
mich hier noch einmal erkundigen sollte bevor ich die Software komplett 
neu schreiben muss. Dann natürlich nach bekannten Entwurfsrichtlinien 
die solche krassen Aktionen nicht verlangen.

Lg

Hi

Wenn ich deine Äußerungen hier so lese, keimt der Verdacht auf, das du 
dich weder mit µCs, noch mit BASCOM so richtig auskennst.

Liege ich da falsch?

MfG Spess

0815User:) schrieb:
> Meiner Meinung
> nach ist das in Bascom nicht möglich.

Gut dann muss ich das teilweise zurücknehmen. Problem was ich allerdings 
noch sehen, wenn ein Interrupt ausgelöst, so wird nicht nur die 
Rücksprungadresse auf den Stack gelegt sondern auch Registerinformation. 
Ich nehme an eben jene die für die Sperrung aller anderen Interrupts 
etc. verantwortlich sind. Diese müssten dann ebenfalls gelöscht werden 
um eine sauberen Programmablauf gewähren zu können. Dennoch stellt sich 
die Frage wo der Stack sich eigentlich befindet. In der Bascom-Hilfe 
steht ja wie schon gesagt lediglich das der Stack im SRAM angelegt wird.

Grundsätzliche gibt es ja zwei Möglichkeiten den Schabanack umzusetzen.

1. ich manipuliere die Rücksprungadresse der IR-Routine. Somit wird der 
Stack automatisch durch das Retrun gecleart und der µC in seinen 
Ursprungszustand versetzt.

2. ich setze in der IR-Routine einen Goto 0 oder andere Adresse. Damit 
spring ich aus der Routine heraus und muss anschließend dafür sorgen das 
sämtliche Informationen die der IR in den Stack geschreiben hat gelöscht 
werden.

Ich muss ehrlich dazu sagen, ich bin von der Idee überhaupt kein Freund. 
Schon allein deswegen nicht weil man damit den µC ganz schnell in einen 
undefinierten Zustand versetzen kann. Ihr könnt also auch ruhig posten 
wenn ihr die Idee einfach Kacke findet und ihr der Meinung seit ein 
Redesign von Soft- und Hardware ist zwingend notwendig. Allerdings bitte 
unter Angabe von Gründen! Einfach nur doof bringt keinem was ;)

Setz doch den Watchdog auf ein sehr kurzes Intervall (das sollten IMHO 
ein paar ms sein).

Edit: Datenblatt sagt 14ms bei VCC=5V, 14.8ms bei VCC=3V.

Hast du vielleicht noch einen I/O Pin frei?
Dann könntest du doch einfach damit einen Transistor ansteuern, der den 
Reset-Pin auf Masse zieht.
Mit einem Digitaltransistor (z.B. BCR135) kommst du dann sogar mit nur 
einem Bauteil aus.

spess53 schrieb:
> Wenn ich deine Äußerungen hier so lese, keimt der Verdacht auf, das du
> dich weder mit µCs, noch mit BASCOM so richtig auskennst.
>
> Liege ich da falsch?

Nun sagen wirs mal so, ich finde Bascom zum entwickeln von blinkenden 
LED Leuchten und Hello-World Programmen ganz gut. Um damit Software zu 
entwickeln die wirklich 100% läuft und dabei mehr wie 50 Zeilen 
Quellcode beinhaltet dabei noch effizient in Maschinencode gewandelt 
wird jedoch ehr ungeeignet.

Mit µC kenne ich mich eigentlich sehr gut aus. Auch wenn das jetzt jeder 
auffassen kann wie er möchte ;) Was mich allerdings etwas enttäuscht 
sind die Beiträge al la wie schreibe ich ein Programm... und doofe Idee. 
Beides weiß ich selber und Helfen eigentlich auch nicht wirklich weiter. 
Zumindest ohne Begründung.

Das hier
MWS schrieb:
> Das hier würde den Stackpointer neu initialisieren, aber da solltest Du
> schon sehr genau wissen, was Du machst:!LDI   R24,   lbyte(_HWSTACKSTART)
> !OUT   SPL,   R24
> !LDI   R24,   hbyte(_HWSTACKSTART)
> !OUT   SPH,   R24
war bis jetzt auch der einzigste Beitrag der dem Problem auf dem Grund 
ging. Auch wenn ich bis jetzt noch keine Möglichkeit hatte das zu 
überprüfen.

Bitte nicht falsch verstehen an alle anderen. Ich bin für jede Teilnahme 
dankbar! Ich habe ja auch schon eingeräumt das es durchaus die beste 
Idee wäre das ganze neu aufzusetzen. Allerdings habe ich auch offen 
gelegt warum ich es nicht unbedingt darauf ankommen lassen möchte. 
Deinen Kommentar kann ich damit also eigentlich genau nicht verstehen...

Leo-andres H. schrieb:
> Hast du vielleicht noch einen I/O Pin frei?
> Dann könntest du doch einfach damit einen Transistor ansteuern, der den
> Reset-Pin auf Masse zieht.
> Mit einem Digitaltransistor (z.B. BCR135) kommst du dann sogar mit nur
> einem Bauteil aus.


Klingt verlockend! Auch wenn mich die anderen jetzt Steinigen werden :D 
Ist halt Aufwand Hardware umzubauen aber als Übergangslösung vllt sogar 
noch ehr geeignet als die IR-Pointer Geschichten.

Wer oder was löst eigentlich den Interrupt aus?

Wenn das wirklich nur ein Reset-Signal ist kannst du doch damit direkt 
auf den Transistor gehen.

Die Schaltung wolltest du später noch umbauen wenn ich das richtig 
gelesen habe. Dann stört ein Transistor + Fädeldraht auf dem Prototypen 
wohl nicht wirklich, oder? ;)

Das würde mir persönlich besser gefallen wie so ein Software-Gewürge, 
was der Atmega eigentlich nicht unterstützt. Es wird wohl einen Grund 
haben, wieso das Atmega kein "reset();" kann.

Ein kleines Problem sehe ich noch bei der Länge des Reset-Impulses. Man 
müsste mal probieren, ob das ausreichend lang ist. Ansonsten wird es 
doch wieder aufwendig.

Gerad im Datenblatt vom Atmega128 gelesen dass die Adresse 0 Reset bei 
mehreren Funktionen angesprungen wird. Einmal beim auslösen des externen 
Pins, beim Power-on Reset, Brown-out Reset, Watchdog Reset und beim JTAG 
AVR Reset.

Würde ja bedeuten dass ein externen Reset mit einem Goto 0 gleich 
zustellen ist.

Leo-andres H. schrieb:
> Wer oder was löst eigentlich den Interrupt aus?

Es ist ein externes Signal was von einem Auswerter kommt. Der Impuls 
hängt von mehreren Faktoren ab, ist aber mindestens eine halbe Sekunde 
lang. Würde von Impulsdauer also sicher funktionieren. Wenn nicht würde 
es eine Kippstufe sicher erreichen. Sind dann statt einem zwei 
Transistoren.

Die Geschichte mit dem Umbau ist vllt. falsch rüber gekommen. Es sind 
aktuell weit über 100 Karten im Einsatz die alle umgebaut werden 
müssten. Da ist es natürlich einfacher neue Software aufzuspielen statt 
mit Lötkolben rum zu werkeln.

Mit vorübergehender Lösung meinte ich, dass ich die vorhanden Karten 
noch so gestalten wollte. Sobald neue beim PCB Hersteller geordert 
werden, dann sämtliche Hardware Änderungen mit berücksichtigt werden und 
natürlich auch neue Software dafür geschrieben wird.

0815User:) schrieb:
> Nun sagen wirs mal so, ich finde Bascom zum entwickeln von blinkenden
> LED Leuchten und Hello-World Programmen ganz gut. Um damit Software zu
> entwickeln die wirklich 100% läuft und dabei mehr wie 50 Zeilen
> Quellcode beinhaltet dabei noch effizient in Maschinencode gewandelt
> wird jedoch ehr ungeeignet.

Siehst Du, das ist jetzt schon mal ein Trugschluss.
Außerdem zeugt es nicht von überragender sozialer Intelligenz, sich von 
jemand der sich in Bascom gut auskennt Hilfe zu erwarten und 
gleichzeitig zu erklären Bascom wär' nur was für blinkende Leds.

Dann wünsch' ich mal weiter viel Spaß Murks für etwas zu schreiben, 
wovon Du nicht viel Ahnung hast.

Eine fast sichere Garantie für ein Desaster :D

Peter Dannegger schrieb:
> Es gibt keine Beschaltung, die einen schlechten Programmierstil
> erfordert. Alle Probleme kann man auch sauber und strukturiert lösen.

Naja wie beschrieben werden die Takte via Timer gesteuert. Das ist schon 
mal eine schlechte Beschaltung da hierfür ein PWM Modul vorhanden ist. 
Leider nicht auf dem selben Pin wie der Timer...

Peter Dannegger schrieb:
> Es gibt auch keine Programmiersprache, die unübersichtliches
> Programmieren erzwingt. Selbst in Assembler kann man sich Funktionen
> definieren und die dann aufrufen.

Ebenfalls naja! In Bascom ist die maximale Stringlänge 254. Mit 
Bigstrings.lib komme ich auf bischen größer 500. Ich meine 504. Wenn mir 
das nicht ausreicht muss ich anfangen zu experimentieren.
Weiterhin kennt Bascom oder hier viel mehr der AT-Mega keine 
Priorisierung der Interrupts was wiederum zu umständlichen Code führt.
Nochmal weiterhin erzeugt der Bascom Compiler 30% mehr Maschinencode wie 
der gcc-gnu Compiler für C. (Bitte nicht auf die genauen 30% festnageln. 
Habe das hier im Forum gelesen und meine es waren 30%)

Das sind nur ein paar Probleme die mir in Verbindung mit Bascom auf 
anhieb einfallen. In Summe zeigt es mir aber dennoch das es gewaltige 
Unterschiede zwischen den diversen Sprachen den damit verbunden 
Compilern und natürlich auch der Hardware gibt, die ich im großen und 
ganzen in meiner Software ausgleichen muss.

MWS schrieb:
> Siehst Du, das ist jetzt schon mal ein Trugschluss.
> Außerdem zeugt es nicht von überragender sozialer Intelligenz, sich von
> jemand der sich in Bascom gut auskennt Hilfe zu erwarten und
> gleichzeitig zu erklären Bascom wär' nur was für blinkende Leds.
>
> Dann wünsch' ich mal weiter viel Spaß Murks für etwas zu schreiben,
> wovon Du nicht viel Ahnung hast.
>
> Eine fast sichere Garantie für ein Desaster :D

Ok... Das war sicherlich etwas doof und ich möchte mich dafür auch 
entschuldigen. Aber ich arbeite seit jeher in C oder Assembler. Dabei 
meistens in MP-Lab mit Pics aber auch schon des öfteren in AVR-Studio 
mit Atmegas. Du kannst es mir jetzt aber nicht übel nehmen wenn ich der 
Meinung bin das Bascom im Vergleich zu den anderen aufgeführten 
Programmen etwas laienhaft wirkt.
Ein ganz großer Zuspruch gibt mir meiner Meinung nach die Tatsache das 
Bascom keine Debugger unterstützt.

Da ich mit der Aussage Bascom wirkt etwas laienhaft sicherlich wieder 
Gefahr laufe jemanden zu verärgern möchte ich das an einem Beispiel 
belegen.

2x16 Display Hello World

Bascom: (Basic)

Locate 1 , 1
lcd "Hello World"

------------------------------------------------------------------------ 
---

MP-Lab: (C)

putrsXLCD( Hello World , 1 , 1);

auf Anhieb kein großer Unterschied. Beides stellt an identischen Stellen 
im Display Hello World dar. Genügt mir das, ist auch alle soweit in 
Ordnung.

Will ich jedoch tiefer in die Materie, aus welchen Gründen auch immer, 
bin ich in Bascom aufgeschmissen da ich nicht sehe was eigentlich hinter 
dem LCD "" steht.
In C MP-Lab öffne ich den eingebunden Header und schau auf welche Datei 
die Funktion putrsXLCD verweißt. Ein klick darauf und ich sehe die 
komplette Funktion putrsXLCD mit Timings etc. und kann diese nach meinen 
Wünschen manipulieren. Weil das 2x16 Zeilen Display z.B. keinen HD 4480 
Chip besitzt und daher ein anderes Timing verlangt oder was auch immer.

Genügt mir das immernoch nicht kann ich mir zur Programmlaufzeit via 
Debugger den ausgeführten Assemblercode anzeigen und manipulieren sodass 
er beim nächsten Durchlauf verändert ausgeführt wird. Ich finde das ist 
eine ganz andere Freiheit mit dem Tool zu arbeiten.

------------------------------------------------------------------------ 
---

Da ich jetzt aus beruflichen Gründen allerdings vorerst dazu gezwungen 
bin mit Bascom zu arbeiten, bringt es mir nicht viel zu erzählen wie 
toll andere Tools & Compiler sind und dass ich mich zugegebenermaßen mit 
Bascom nicht so recht anfreunden kann.

Ich wollte damit eigentlich nur meinen Standpunkt gegenüber MWS 
aufzeigen und mich nochmal bei allen entschuldigen denen ich mit meinen 
Aussagen über Bascom auf dem Slips getreten bin

MFG

0815User:) schrieb:
> Du kannst es mir jetzt aber nicht übel nehmen wenn ich der
> Meinung bin das Bascom im Vergleich zu den anderen aufgeführten
> Programmen etwas laienhaft wirkt.

Der Meinung kannst Du ja gern sein, der Umstand, daß Bascom dem User den 
Einstieg leicht macht und da dann halt auch mal Merkwürdiges daraus 
resultiert, sagt nichts darüber aus was man tatsächlich damit anstellen 
kann. Du wärst überrascht, in wievielen kommerziellen Produkten Bascom 
drinsteckt.

Wie Peter schon sagt, man kann in jeder Sprache strukturiert 
programmieren, so auch in Bascom. Strukturierter, oder auch durchdachter 
Code wurde hier offensichtlich nicht geschrieben, sonst würde man 
einfach in der ISR ein Flag setzen und in der regelmäßig durchlaufenen 
Mainloop auswerten.

0815User:) schrieb:
> Ebenfalls naja! In Bascom ist die maximale Stringlänge 254. Mit
> Bigstrings.lib komme ich auf bischen größer 500. Ich meine 504. Wenn mir
> das nicht ausreicht muss ich anfangen zu experimentieren.
Gerade einen String mit 1000 Byte definiert und gefüllt, mit AVR-Studio 
simuliert. Klappt einwandfrei.

Nur, ich muss Bascom nicht verteidigen, wer's mag soll's nehmen, wer C 
lieber mag, auch ok. Letzten Endes ist entscheidend wer vor der 
Mattscheibe sitzt ;-)

Ich lass mich gerne verbessern. Hatte halt vor nem halbem Jahr den Fall 
einen String grösser 254 Zeichen zu gebrauchen. Das war damals laut mcs 
nicht möglich. Schön wenn es jetzt reibungslos funktioniert.

Mit dem Flag im Interrupt, das kam mir auch schon in den Sinn. 
Allerdings müsste ich es an mehreren Stellen abfragen um auch die 
benötigte Geschwindigkeit zu erreichen.
Es kann durchaus vorkommen das der uc in einer Unterroutine fest steckt 
um Beispielsweise FSK Daten zu verschicken. Das kann dann schon mal ne 
halbe Sekunde dauern. Die Verzögerung Interrupt bis Hauptschleife darf 
allerdings maximal 10 MS dauern. Um das zu erreichen musste ich 
vermutlich 50 Abfragen oder mehr Abfragen in den Code einfügen.

Mit der Behauptung das in vielen Produkten Bascom eingesetzt wird gebe 
ich dir 100% Recht. Hab Bascom im Studium mal angeschnitten, aber nicht 
erwartet das es mich mal so Verfolgen wird :D

Würdest du die hohe Anzahl an Abfragen in kauf nehmen und auf die 
Interrupt Geschichte verzichten? Um das noch mal klar zustellen, es wird 
an keiner Stelle im Programm ein Wait ausgeführt was die Abfragerei 
negativ beeinflussen könnte.

0815User:) schrieb:
> Würdest du die hohe Anzahl an Abfragen in kauf nehmen und auf die
> Interrupt Geschichte verzichten?

Da kein Code gezeigt wird (werden kann), ist das schlecht zu sagen, 
hängt tatsächlich vom Aufwand ab.

Die ganze Beschreibung ist etwas schwammig, aber gehen wir davon aus, 
daß einfach ein Reset erfolgen soll. Da ein Goto 0 aber wie gesagt die 
I/Os unangetastet lässt, muss sicher gestellt werden daß keine Int-Flags 
mehr gesetzt sind, sonst lösen die aus sobald die globalen Interrupts 
wieder erlaubt werden.

Ein:

1

Config Int0 = Rising

2

On Int0 Int0_ISR

3

Enable Int0

4

Enable Interrupts

5

' ...

6

Int0_ISR:

7

' ...

8

  Goto 0

9

Return

führt bei steigender Flanke einen Softreset aus, initialisiert den Stack 
neu und löscht das SRam. Ein Stacküberlauf wird nicht vorkommen.