Bascom Quelltext aufsplitten und includieren?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Das End fehlt nicht. Er hat ja eine Endlosschleife (die nicht verlassen wird).

      End braucht man nur, wenn man keine Endlosschleife hat oder diese Codebedingt verlassen werden könnte.
      Aber dann wäre es keine Endlosschleife mehr sondern eine Endliche.

      Dann würde die Codeabarbeitung auch das End erreichen und Sinn machen.

      Das doppelte Return habe ich auch gesehen. Es wird das erste Return ausgeführt.
      Es stört also nicht weiter (belegt nur Platz) und ist nicht die Ursache für das Problem.
    • Hallo Mitch64!

      Mitch64 schrieb:

      Hi Amateurfunker @DG7GJ

      Ich habe mir deinen Code mal durchgesehen. Und auch verschiedene Dinge abgecheckt.
      Aber keins von den üblichen Fehlern Dingen scheint hier vorzuliegen.

      Das letzte womit ich gekämpft hatte waren die Speicherdefinitionen $hwstack, $swstack und $framesize.
      Ich bin mir bewusst das ich nicht gerade wenig Speicher nutze, deswegen auch der Mega1284.
      Aber mit dem Abschätzen dieser Werte tur ich mich noch immer schwer.

      Mitch64 schrieb:

      Da ich auch nicht deine Hardware habe, ist eine Fehlersuche fast aussichtslos.

      Klar, ist halt ein Platinchen mit zwei Sensoren und zwei E²PROM's am I²C und ein RFM69HW. Bis auf zwei Lötpunkte für den UART sonst keinerlei Ausgabemöglichkeiten wie LCD oder so.
      Soll in ein Schuko-Steckergehäuse als Datenlogger und RTC-Referenz (DCF77) dienen.

      Hab den Fehler jetzt erst mal ignoriert und widme mich jetzt erst mal der Gegenstelle um zu gucken ob das Teilchen tatsächlich nicht empfängt, oder nur die Variable irgendwo fals übergeben wird.

      Mitch64 schrieb:


      Was ich auf alle Fälle Remmen würde ist in der ISR "Sectic" die Ausgabe mit Print remmen.
      Denn die Ausgabe benötigt einen Interrupt und du befindest dich in einem. So was sollte man unterlassen.

      Hab ich gemacht, das Problem blieb aber unverändert.
      In Aufgabe 2 wird Modus auf 1 gesetzt. Kurz darauf ändert sich der Inhalt aber auf 0, egal ob irgendeine der anderen Aufgaben läuft oder auskommentiert ist.

      Jürgen
    • Ähm, ich hab' deinen code noch nicht durchgeschaut, aber wenn sich eine Variable ändert, obwohl das eigentlich nicht passieren sollte, dann schau mal bei den dims um diese Variable. Kann die davor gedimmte überlaufen und dann die betreffende überschreiben? Oder verschiebe mal die dimmung der betreffenden Variable (Modus) an eine andere Stelle, damit die im ram an einer anderen Stelle abgelegt wird.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • DG7GJ schrieb:

      Das letzte womit ich gekämpft hatte waren die Speicherdefinitionen $hwstack, $swstack und $framesize.
      Damit kämpfst nicht nur du. Um zu verstehen, in welcher Größe diese Bereiche etwa ausgelegt werden müssen, muss man verstehen, wie die Bereiche genutzt werden. Das kann man nicht in einem Satz erklären.
      Hier solltest du dir diesen Link mal zu Gemüte führen. Bascom Memory Usage.

      DG7GJ schrieb:

      Bis auf zwei Lötpunkte für den UART sonst keinerlei Ausgabemöglichkeiten wie LCD oder so.
      Es gibt auch fertige Displays, die an I2C angeschlossen werden können. Damit wäre auch ein Display möglich.

      DG7GJ schrieb:

      Hab ich gemacht, das Problem blieb aber unverändert.
      Dann bleibt nur Fehler eingrenzen. Funktionen deaktivieren, bis der Fehler erst mal weg ist. Dan hast du schon mal einen Anhaltspunkt wo du suchen musst.

      tschoeatsch schrieb:

      dimmung der betreffenden Variable (Modus) an eine andere Stelle
      Den Vorschlag von @tschoeatsch solltest du auch mal prüfen. Vielleicht wird da wirklich was überschrieben.

      Im übrigen habe ich auch je Routine gesehen, Da wird Mode umgestellt, dann wird was versendet, und dann der Mode zurückgestellt. Ich habe mich noch gewundert, ob das Sinn macht. Aber da ich nicht verstehe wozu der Mode da ist, habe ich nicht weiter darüber nachgedacht.

      Das hier ist z.B. so eine Stelle:

      BASCOM-Quellcode

      1. $Include TimestampTX.bas
      2. TimestampTX: 'Sub Timestamp Senden
      3. RFM = 0 'RFM Select
      4. SPIOUT RFM_OpModeW, 1 'RFM Register h01/h81 adressieren
      5. SPIOUT RFM_TX, 1 'Modeumschaltung TX
      6. RFM = 1 'RFM DeSelect
      7. Modus = 2 'Modus auf 2 = TX setzen (nur für Schleife)
      8. while RFM_DIO0 = 0 'Solange PaketSent Low bleibt
      9. waitms 1 'warten in 1ms-Schritten
      10. wend 'Bis PacketSent High wird
      11. RFM = 0 'RFM Select
      12. SPIOUT RFM_OpModeW, 1 'RFM Register h01/h81 adressieren
      13. SPIOUT RFM_RX, 1 'Modeumschaltung RX
      14. RFM = 1 'RFM DeSelect
      15. Modus = 1 'Modus auf 1 = RX setzen (nur für Schleife)
      16. Aufgabe = 0 'Aufgabe erledigt
      17. RssiS = 0 'RSSI-Minimalwert der letzten Minute zurücksetzen für nächste Minute
      18. Return
      Alles anzeigen
      Siehe Zeile 7 und 15.

      Wenn das Problem mit der Variable Modus zusammen hängt, kannst du im Code ja mal alle Stellen anschauen, wo der Modus geändert wird. Vielleicht findet sich so der Fehler.

      Noch eine Frage:
      Wenn so ein Fehler auftritt, z.B. bei Sekunde 0 oder 1. Bleibt dann das Programm hängen oder macht es einen Reset?
      Im Falle von Hängenbleiben kann ich aus eigener Erfahrung sagen, dass oft die RFM-Module "geklemmt" haben. Das liegt dann meist am nicht interpretiertem Statusbyte, das auf etwas hinweisen will. Man es aber ignoriert und weiter macht.
    • Was die stacks betrifft, im code-explorer gibt's eine 'info', da werden stack-Werte angezeigt.
      avrhelp.mcselec.com/view_code_explorer.htm
      hier noch den Text zu den stack-Werten lesen und berücksichtigen. Dann sollten die Größen passen.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • Hallo Mitch64!

      Mitch64 schrieb:

      Es gibt auch fertige Displays, die an I2C angeschlossen werden können. Damit wäre auch ein Display möglich.

      Ja, kenne ich. Du meinst diverse 2x16 oder 4x16 Standard-LCD's mit einer angelöteten Zusatzplatine mit einem PCF8574, die es aus Fernost gibt, gell?
      Da habe ich bislang nur Hinweise und Libs gefunden aus dem RPi-Bereich, jedoch nix aus dem Bereich Bascom.
      Habe ich aber keine Sekunde dran gedacht bei diesem Projekt, weil dort ganz andere Vorgaben wichtig waren:

      Über I²C hängen zwei Sensoren (MPL3115A2 und CC2D33) sowie zwei kaskadierte E²PROM's M24M02 mit Hauptaugenmerk auf EMV-Robustheit.
      Eben weil da knapp 5cm oberhalb eine Antenne hängt die auf 869MHz mit 50-100mW sendet.



      Mitch64 schrieb:

      Im übrigen habe ich auch je Routine gesehen, Da wird Mode umgestellt, dann wird was versendet, und dann der Mode zurückgestellt. Ich habe mich noch gewundert, ob das Sinn macht. Aber da ich nicht verstehe wozu der Mode da ist, habe ich nicht weiter darüber nachgedacht.

      Modus ist eine Indikatorvariable die ich manuell im Code setze, wann immer das Funkmodem in seiner Betriebsart umgestellt wird:
      Wenn das RFM69 im Standby ist, setze ich Modus auf 0.
      Wenn das RFM69 im Empfangsmodus ist, setze ich Modus auf 1.
      Wenn das RFM69 im Sendemodus ist, setze ich Modus auf 2.

      An diversen Stellen ist das wichtig, z.B hier:

      In der Hauptschleife frage ich den Eingang "DIO0" vom RFM69 ab.
      Das Signal dort hat aber je nach Betriebsart unterschiedliche Bedeutung:

      Wird DIO0 high, deutet dieses im Empfangsbetrieb auf ein empfangendes Paket im FIFO hin, dessen CRC als korrekt erkannt wurde -> dann muss dieses Paket sofort ausgelesen werden.
      Ebenso wird DIO0 im Sendebetrieb High, dort signalisiert es das ein zu sendendes Paket komplett gesendet wurde - dann muss das Modem sofort auf Empfangsmode umgeschaltet werden.

      DIO0 im Empfangsmode (signal CrcOK) werte ich in der Programmschleife aus:
      If RFM_DIO0 = 1 and Modus = 1 then gosub RxPacket 'Wenn CrcOK High wird und Modus auf RX steht, springe zu RxPacket

      DIO0 im Sendebetrieb (Modus = 2) werte ich bislang nur direkt in den Subs aus, welche Pakete aussenden.


      Gestern habe ich das Teilchen aber erst mal zu geschraubt.
      Denn ich kann nur sehen das dieses Teilchen pünktlich zu jeder vollen Minute sendet - mittels Spektrumanalizer.
      Um genauer zu prüfen ob er auch den korrekten Inhalt sendet, bzw. ob er Pakete auch empfängt, brauche ich erst mal die Gegenstelle.
      Die hat dann auch neben einer RS232 auch ein LCD, wenn auch ein nicht ganz einfaches (EADOGM128x64).

      Ich weis noch das ich zuletzt mit der grafischen Ansteuerung des LCD kämpfte.

      Jürgen
    • DG7GJ schrieb:

      Du meinst diverse 2x16 oder 4x16 Standard-LCD's mit einer angelöteten Zusatzplatine mit einem PCF8574, die es aus Fernost gibt, gell?
      Da habe ich bislang nur Hinweise und Libs gefunden aus dem RPi-Bereich, jedoch nix aus dem Bereich Bascom.
      Nichts einfacher als das.
      Die LIB nennt sich YwRobot_Lcd_i2c.lib und findet sich HIER.
      Diese LIB hat den Vorteil, dass es gar keine neuen Befehle gibt sondern die in BasCom vorhandenen LCD-Befehle dahin "umgeleitet" werden.

      Funktioniert bei mir in mehreren Projekten mit verschiedenen Displays.
    • Hallo tschoeatsch!

      tschoeatsch schrieb:

      Was die stacks betrifft, im code-explorer gibt's eine 'info', da werden stack-Werte angezeigt.
      avrhelp.mcselec.com/view_code_explorer.htm
      hier noch den Text zu den stack-Werten lesen und berücksichtigen. Dann sollten die Größen passen.

      Oha, da sagt der Code-Explorer zu meinem Programm:
      $FrameSize = 24
      $HwStack = 8
      $SwStack = 0

      Ich hätte da mit deutlich höheren Werten gerechnet.

      Jürgen
    • Hallo!

      Zitronenfalter schrieb:

      Nichts einfacher als das.Die LIB nennt sich YwRobot_Lcd_i2c.lib und findet sich HIER.
      Diese LIB hat den Vorteil, dass es gar keine neuen Befehle gibt sondern die in BasCom vorhandenen LCD-Befehle dahin "umgeleitet" werden.

      Funktioniert bei mir in mehreren Projekten mit verschiedenen Displays.
      Oha, danke für den Tip! Habe ich mir direkt mal gespeichert.

      Jürgen
    • DG7GJ schrieb:

      Hallo tschoeatsch!

      tschoeatsch schrieb:

      Was die stacks betrifft, im code-explorer gibt's eine 'info', da werden stack-Werte angezeigt.
      avrhelp.mcselec.com/view_code_explorer.htm
      hier noch den Text zu den stack-Werten lesen und berücksichtigen. Dann sollten die Größen passen.
      Oha, da sagt der Code-Explorer zu meinem Programm:
      $FrameSize = 24
      $HwStack = 8
      $SwStack = 0

      Ich hätte da mit deutlich höheren Werten gerechnet.

      Jürgen
      Also ich bin mir nicht sicher, ob im Code enthaltenen ISR‘s in die Kalkulation vom Code Explorer mit eingehen. Hab gerade nur mein iPad und kann nicht testen. Es müsste dann auch eine Änderung geben wenn z.B. NOSAVE als Option angegeben werden.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • In der Hilfe (Link von oben) steht das:




      mcs schrieb:

      The calculated stack settings are based on the program call tree and

      local variables. This is just a tool to give you an idea about stack
      usage. Not taken into account is the stack required by the assembler
      routines. This means that you need to add a certain amount to the
      calculated values. When your code uses interrupts you need to increase
      the calculated $HWSTACK by 32. Otherwise increase it by 16. The
      $FRAMESIZE should have a minimum value of 24. Add a value of 16 to
      $SWSTACK.
      Applications using AVR-DOS should use a minimum of 128 for all stacks.
      A future version will also take the assembler code into account.
      Heißt, dass die Werte, welche im Code-Explorer angezeigt werden, nicht korrekt sind.
      Aber zumindest ein Richtwert, zusammen mit obigem Text kommt man auf vernünftige Stackwerte.
    • Um die Stackwerte im Simulator zu ermitteln, müsste man alle Code-Pfade durchgehen (simulieren).
      Das würde viel Zeit kosten, zumal viele Befehle im Simulator problematisch sind.
      Ich denke da mal an I2C und an getKBD. Wird also nicht wirklich funktionieren, außer bei kleinen Programmen.
      Da kriegt man das noch hin.

      Aber im Grunde macht das ja genau der Code-Explorer. was er noch nicht berücksichtigt, sind die Bibliotheken (Libs) und Interrupt-Routinen.
      Das soll aber lt. Hilfe in einer zukünftigen Version noch implementiert werden. Das wäre mal ein Super Feature!

      Bis dahin wird man weiter schätzen müssen. Oder man legt anfangs die Werte höher aus, bis das Programm steht und reduziert die Stackwerte später, wenn man den SRAM für anderes braucht.
      Ich bin bisher immer gut gefahren, wenn ich alle Stackwerte erst mal auf 64 gesetzt habe (sofern genügend SRAM verfügbar ist). Auch Framesize. Natürlich reicht Framesize 64 nicht aus, wenn man längere Strings per ByVal an Routinen übergibt.

      Ein Indiz, dass einer der Stacks überläuft ist immer, wenn merkwürdige Effekte auftreten.
      In solchen Fällen kann man die Stackwerte mal vergrößern. Hilft das, lags am Stack. Hilfts nicht, liegt der Fehler i.d.R. wo anders.

      Pluto25 schrieb:

      Das wiederum kann im Simulator recht gut beobachtet werden: Ob die Stacks noch Luft haben oder sich "schreddern". Allerdings läuft der Code auch dann immer noch richtig weiter was er in der Realität nicht würde.
      Aber wie würdest du denn die Werte bestimmen? Wie ist deine Vorgehensweise?
    • Also die Bedarfe der ISR Routinen sind festgelegt (über deren Parameter) und zumindest für einen Aufruf klar, im schlechtesten Fall also 32 Register plus Rücksprungadresse. Für Nesteted Interrupts muss der Entwickler selbst rechnen. Alle anderen Varianten lassen sich leicht über einen Baum darstellen.
      Eine andere und für die BASCOM Architekten einfachere Variante wäre die Verfolgung im Simulator, der dann z.B. den Maximalwert und den Aufruf-Stack zurückliefert.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.