Was mir jetzt aufgefallen ist, ist dass in Zeile 331 ein END fehlt und in Zeile 1806 ein RETURN zu viel ist.
Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
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!
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.
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.
DG7GJ schrieb:
Das letzte womit ich gekämpft hatte waren die Speicherdefinitionen $hwstack, $swstack und $framesize.
DG7GJ schrieb:
Bis auf zwei Lötpunkte für den UART sonst keinerlei Ausgabemöglichkeiten wie LCD oder so.
DG7GJ schrieb:
Hab ich gemacht, das Problem blieb aber unverändert.
tschoeatsch schrieb:
dimmung der betreffenden Variable (Modus) an eine andere Stelle
Mitch64 schrieb:
Es gibt auch fertige Displays, die an I2C angeschlossen werden können. Damit wäre auch ein Display möglich.
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.
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.
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.
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.
DG7GJ schrieb:
Hallo tschoeatsch!
Oha, da sagt der Code-Explorer zu meinem Programm: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.
$FrameSize = 24
$HwStack = 8
$SwStack = 0
Ich hätte da mit deutlich höheren Werten gerechnet.
Jürgen
Heißt, dass die Werte, welche im Code-Explorer angezeigt werden, nicht korrekt sind.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.
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.