Hallo, Wie im Betreff vermerkt suche ich eine Lösung, den Hardwarestack in Bascom zu löschen. Ich möchte ähnlich wie der Watchdog den Controller neu initisieren. Allerdings über einen einen externen Interrupt. Nun war die Idee aus der Interruptroutine zum Programmstart zu springen. Leider bekomme ich den HWStack nicht resetet was nach geraumer Zeit zum überlaufen und anschließend zur Fehlfunktion des uc führt. Bin führ alle Ideen offen!
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
0815User:) schrieb: > Die aktuelle Beschaltung des uc erfordert leider > solch verzweifelten Taten :). Es gibt keine Beschaltung, die einen schlechten Programmierstil erfordert. Alle Probleme kann man auch sauber und strukturiert lösen. 0815User:) schrieb: > Sind weit über 1000 > Zeilen, meiner Meinung nach sowieso unübersichtlichen Bascom > geschrieben. Es gibt auch keine Programmiersprache, die unübersichtliches Programmieren erzwingt. Selbst in Assembler kann man sich Funktionen definieren und die dann aufrufen. Du solltest mal den PC abschalten und mit Papier und Bleistift einen Programmablaufplan malen. Aber nicht als Spaghetticode sondern in einzelne Funktionsmodule unterteilt. Jedes Modul kriegt dann wieder seinen eigenen PAP. So als Richtwert, ein PAP sollte auf 1-2 A4 Seiten passen, ansonsten ist er zu lang und man verliert die Übersicht. Ist ein Modul zu groß, dann versucht man, es in Teilaufgaben zu zerlegen. Ob nun Top-down oder Bottom-up oder beides, ist egal. Man fängt da an, wo man einen Ansatzpunkt sieht. http://de.wikipedia.org/wiki/Top-down_und_Bottom-up Niemals eine Aufgabe als großen monolithischen Block ansehen. Peter
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.