5*5*5 mal wieder :-)

  • Tag ich bin der Neue hier! :D


    Also ich hab folgendes Problem:


    Ich hab mir einen 5x5x5 Würfel gebaut, Java Prog geschrieben zum entwerfen von Mustern auf graphischer Oberfläche und n Bascom Code auf den 5x5x5 "angepasst"(Danke Fightclub ;-)).


    Hier der Bascom-Code:


    In der Muster.txt steht folgendes:



    Die Ausgabe soll sein, dass er alle LEDs nacheinander ein und wieder aus schaltet... Das klappt auch wunderbar, bis zum Bild 51. Das bekommt er noch hin und in Bild 52 vertauscht er Port D mit Port A und läuft weiter. Also genau dann, wenn die Variable Offset den Wert 1024 überschreitet. Das passiert bei allen Animationen, die mehr als 51 Bilder haben. Die Werte in der Muster.txt hab ich auch schon als Bytes gehabt, das hat auch nich geholfen! Das scheint wie schon gesagt ein absolut Software seitiges Problem zu sein, da er das am realen Würfel und in der BAscom Simulation gleichermaßen macht. Ich sitz hier schon ewig dabei und hab echt keine Einfälle mehr... wenn ich die Muster.txt in mehrere txts aufteile (jeweils 50 Bilder) und den offset wieder auf 0 setze geht es... aber wenn ich (übertrieben) 1000 Animationen machen will, hab ich keine Lust 200 txts anzulege. Kann mir da BITTE einer helfen!? Ich schmeiss das Ding sonst bald aus dem Fenster!


    Angesteuert wird das Ding mit dem Atmel Evaluations-Board V2.0.1 mit nem ATMega32 druff!

  • Das scheint tatsächlich ein Problem von Bascom zu sein, dass das Mucken macht, wenn man längere "Data"-Dateien per include einbindet - war hier schon mal das Thema, auch bei einem Cube...


    ob's da ne Lösung dafür gab, weiß ich nicht mehr, jedenfalls hat neni was dazu gepostet, also wenn Du Dir mal die Beiträge von "synvox" ansiehst, da müsste der dabei sein...


    aber wenn Du eh' die Muster.txt "automatisch" erzeugst, das sollte doch nicht sooo das Problem sein, dass Deine SW das halt dann in mehrere aufteilt..?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hi,


    ich habe mich mit dieser Problematik in Bascom für einen Bekannten auch schon rumgeschlagen und habe damals keine echte direkte Lösung gefunden...
    Wäre also wirklich schön, wenn synvox eine Lösung dazu hat...


    Gruß Flo

  • vielleicht koenntest du mir das bascom file und dein java prog zukommen lassen, dann koennten wir in unserer Ausbildungswerkstatt (etliche Ausbilder und 60 Azubis) mal schauen, ob wir da was machen können! Kann leider keinen Erfolg garantieren, aber wir werden es versuchen!


    MfG equi!

  • Oh Mann, jetzt habe ich mich fast zu Tode gesucht nach dem Beitrag von mir zu dem Thema ;) . Ich wusste selbst nicht mehr, was ich damals als mögliche Ursache vermutet habe ;) . Nachdem ich jetzt aber den Beitrag gefunden und nachgelesen habe, ist es mir auch wieder eingefallen, dass es eben ein Problem mit dem $include-Befehl sein könnte.
    Ich programmiere zwar relativ viel in BASCOM, aber $include verwende ich persönlich eben kaum, es war deshalb auch nur eine wage Vermutung. Ob sich diese im damaligen Fall bewahrheitet hat, kann ich nicht sagen. Ev. weiss Fightclub ja noch, ob es etwas gebracht hat.


    Im vorliegenden Code würde ich auch noch vorschlagen, den Rückgabewert der Lookup-Funktion nicht direkt an einen Port zuzuweisen sondern erst einer Byte-Variablen (z.Bsp. Temp) und diese dann dem Port. Der Compiler steuert den Lese-Pointer der Lookup-Funktion eben in Abhähgigkeit der definierten Grösse der Zielvariablen für den Rückgabe-Wert. Wenn man also z.Bsp. in eine Word-Variable speichert, dann liest Lookup automatisch zwei Bytes pro Aufruf etc. Port-Register sind zwar streng genommen auch Byte-Variablen, aber ob BASCOM das dann auch immer (im ganzen Programm-Verlauf) richtig macht, kann ich nicht sagen. Sicherheitshalber würde ich es eher wie oben erwähnt mit einer Zwischen-Zuweisung machen.


    Ferner ist mir im vorliegenden Code nicht ganz klar, wo die Ebenen-Umschaltung (multiplex) stattfindet. Wenn es, wie ich vermute, über einen der Ports via DATA-Zeilen gemacht wird, dann sind die gezeigten Zeilen aber nicht ganz korrekt. Denn dann müsste zumindest jeweils ein Byte der 5 Ebenen-DATA-Zeilen für jede Ebene etwas anders sein. In den vorliegenden DATA-Zeilen kommen dagegen oft vier genau gleiche Zeilen für ein Bild vor, also wird praktisch 3 oder 4 mal die gleiche Ebene aktiviert. Oder ist das jetzt nur ein Copy-Paste-Beispiel für den Post.


    Gruss
    Neni

  • Ja, da hast Du Recht, da ist wohl irgendwo ein Fehler (in der SW, die diese Zeilen erzeugt) - der äussert sich hier zwar nicht, da die jeweiligen Ebenen anscheinend immer aus sind (also 4x aus ist 4x aus, egal welche Ebene aktiviert ist), aber wenn da mal komplexere Muster angezeigt werden sollen, dann gibt's da auch Probleme...


    die Bascom-SW oben stammt übrigens ursprünglich von mir, also auch die hier für den 5x5x5, wurde nur leicht modifiziert, die Anzeigedauer steht hier in ner extra Datei... (warum eigentlich...?!?)


    equi: kann es sein, dass Du scharf auf den Editor bist....? :D - das Bascom-File ist doch ausserdem schon drin, musst Du doch nur oben rauskopieren.... ?(

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • equi: kann es sein, dass Du scharf auf den Editor bist....? :D - das Bascom-File ist doch ausserdem schon drin, musst Du doch nur oben rauskopieren.... ?(


    Na, der Editor is ja noch nicht fertig, wir koennten versuchen, den fertig zu stellen! Ja, und ich brauch ihn auch :D


    mfg!

  • Ja Pesi, mir ist beim Lesen des alten Threads auch aufgefallen, dass es exakt der selbe Code ist, den Fightclub dort als Datei velinkt hat. Möglicherweise ist ja Punk3110 genau die Person, für die er dort die Anpassung auf 5x5x5 gemacht hat? Aber da ist ja mittlerweile fast ein Jahr vergangen, also wohl eher doch nicht?


    Was mir noch zum Problem einfällt:
    51 Bilder mal 5 DATA-Zeilen pro Bild ergibt genau 255 DATA-Zeilen plus die erste für die Anzahl Bilder, sind also 256 DATA-Zeilen. Es könnte sein, dass der Compiler beim Compilieren Probleme hat, wenn mehr als 255 oder 256 DATA-Zeilen in einem Block (also bezogen auf ein Label) vorhanden sind (möglicherweise überlauft da ein interner Zähler beim Compilieren). Dies könnte man verifizieren, indem man zum Bsp. alle 20 Byte für ein Bild jeweils in eine DATA-Zeile schreibt und es so probiert. Falls diese Annahme stimmt, müsste man dann so immerhin 255 Bilder ausgeben können. Allerdings würde dann include oder nicht-include nichts an der Problematik ändern. Man müsste dann eben möglichst viele Daten pro DATA-Zeile ablegen. Ob es dann bei der DATA-Zeilen-Länge auch wieder ne interne Limite (also z.Bsp. max. 256 Elemente pro DATA-Zeile) gibt, weiss ich auch nicht genau, würde es aber vermuten.


    Ein Lösungsansatz, der möglicherweise grundsätzlich bei solchen Flash-Datenblöcken helfen könnte:
    In BASCOM gibt es auch den $INC-Befehl (am Besten mal die BASCOM-Hilfe zu "$INC" lesen), mit welchem man eine reine, binäre Datendatei an eine bestimmte Stelle im Code und mit einem vorgegebenen Label (so dass Lookup oder Read etc. einen entsprechende Referenzpunkt haben) einbinden kann. Diese Funktion wird auch in der BASCOM-Hilfe als die bessere Methode zur Einbindung grosser Datenblöcke gegnüber DATA-Zeilen genannt. Der grosse Vorteil ist eben, dass der Compiler eine solche Datei nicht erst 'übersetzen' muss. Er bindet sie einfach so an die entsprechende Stelle im Code ein, wie sie ist. Allerdings müsste dann eben das Daten-Erstellungs-Programm geändert werden und die Daten dann direkt binär in eine Datei schreiben. Ausserdem müsste man, wenn man die jetzige Struktur so behalten möchte, auch die Anzahl Bilder als Binärdaten (Low-Byte zuerst, dann High-Byte) am Anfang in die Datei schreiben. Ferner sollte man dann auch die hier separate Bilderlängen-Datei genau so als Binärdatei anlegen und einbinden, wenn man die eventuelle DATA-Zeilen-Limite nachhaltig überwinden will.


    Gruss
    Neni

  • Ja cool Danke erstmal für die Hilfe!^^ Der Editor IST fertig und funktioniert! Ich will ihn halt erst raus geben wenn ich alle Knöppe mit Funktionen belegt habe und die "Zusammenarbeit" mit Bascom läuft... kann ja sein das ich da noch was ändere!


    Pesi
    kann sein das der Code von dir is!:-) Hab den in nem anderen Forum gefunden und da hat ihn Fightclub gepostet!^^ In der Java Oberfläche hab ich einen Punkt eingebunden, in dem ich die Brenndauer der LEDs einstellen kann. Ich hatte auch schon versucht die Zeit bei den Mustern mit ein zu bauen, aber das ging merkwürdigerweise überhaupt GAR nich und mit ner zweiten txt auf anhieb! :)


    synvox
    Ich hab auch schon versucht die Daten aus der txt erstmal in eine andere Variable zu speicher... hat leider auch nich so einen Erfolg gehabt! Ich weiss jetzt aber nich mehr so genau ob es eine Byte Variable war.... Das mit dem Multiplexen hat eigentlich gut geklappt...




    Ich werd mich heute Abend noch mal hinsetzen und die txt in Bytes ausgeben lassen... Den zwischenschritt mit der txt werd ich dann auch mal zum testen raus nehmen und gleich eine .bas erzeugen und für die Muster nur noch ein Label verwenden also


    Code
    Muster:
    Data b00011110, b001110000, ..... // Nich auf der Syntax fest nagel jetzt ich weiss die is nich ganz richtig!^^


    dann müste es je laufen wenn es wirklich am include liegen sollte...


    Danke auf jeden Fall erstmal für eure Hilfe! In dem anderen Forum gibt es scheinbar keine Einfälle mehr!^^




    EDIT:


    Da war ich wohl zu langsam synvox :)
    Ok das war ein wenig viel so früh am morgen und vor dem ersten Kaffee!^^ Ich muss jetzt gleich erstmal in die Uni und dann les ich mir das ganze nachher noch einmal durch! :) Klingt so beim ersten lesen aber schon mal nich schlecht! Ach ja... ich hab mir den Code von Fightclub(pesi) genommen und habe den selbst umgeschrieben! Das waren meine ersten Unternehmungen in Bascom also hielt ich es für recht wahrscheinlich das ich da Bockmist gebaut habe!^^ Ich hatte schon befürchtet das Bascom little endian benutzt... mag ich persönlich nich! :rolleyes:

  • so... ich hab nun mal ausprobiert, die Bytes einfach unter nem Label einzufügen... ohne Erfolg! So viele Anweisungen wie möglich in eine Zeile war auch n Flop... 600 Einträge oder so in einer Reihe aber immernoch das gleiche Problem!

  • öhm, nur mal so zur Sicherheit, du arbeitest schon mit der BASCOM-Vollversion und nicht mit der Demo, oder? Die Demo hat eine Grössenbeschränkung für den compilierten Code und könnte somit dann auch ne Ursache sein. Welche Version (die aktuelle ist 1.11.9.9) von BASCOM verwendest du?


    Sonst werde ich den Code morgen mal bei mir in meine BASCOM-Installation laden und durchsimulieren. Mal sehen, ob ich das gleiche Verhalten reproduzieren kann. Irgendwie kommen wir so sonst nicht mehr weiter.


    Gruss
    Neni

  • Compiler version :1.11.9.0
    Compiler build :1.11.9.0.001
    IDE version :1.11.9.0


    Aber es wäre nett wenn du es trotzdem mal versuchen würdest! Nur um ausschließen zu können das in meinen Einstellungen irgendwas vermurkst is... oder ich doch noch mal n update machen muss...

  • ... Welche Version (die aktuelle ist 1.11.9.9) von BASCOM verwendest du?
    ....
    Gruss
    Neni

    Jo... ob Demo oder Vollversion hat er wohl gefragt... (Vollversion übrigens!:)) das hab ich wohl vergessen noch drunter zu schreiben... Aber nach der Versionsnummer hat er auch gefragt! :D

  • So, ich habe mich jetzt fast zu Tode analysiert, ich seh nur noch Hex-Code um mich herum schwirren :D .


    Fazit ist, dass es tatsächlich im 52. Bild (Bild 51) in der ersten Ebene (Ebene 0) zu einer Datenverschiebung um ein Byte kommt, und Fazit ist auch, dass weder die Lookup-Funktion an sich noch die direkte Zuweisung zu den Ports die Ursache dafür sind, sondern ein Fehler des Compilers in der Verarbeitung der Data-Anweisung.


    Bei einer mühseligen Analyse des compilierten Binärcodes in einem Hex-Editor ist mir aufgefallen, dass zwischen dem 1024. und 1025. Datenelement ein zusätzliches Element (in diesem Fall ein Byte) mit dem Wert 0 vom Compiler eingefügt worden ist, welches keine Entsprechung in den Data-Zeilen findet. Damit verschiebt sich natürlich das Ausleseraster, und die Daten, welche eigentlich für Port D der vorherigen Ebene bestimmt wären, werden dann Port A der nächsten Ebene zugewiesen etc. Das passiert unabhängig davon, wie die Data-Elemente eingebunden werden, via $include, direkt im Hauptfile oder wie auch immer.
    Ich habe nun nicht weiter analysiert (wäre mir zu mühselig), ob bei jedem Vielfachen von 1024 Datenelementen oder nur genau beim 1024. ein Zusatzelement eingefügt wird. Ferner habe ich auch nicht getestet, ob der Einschub beim 1024. Byte der Daten in einem Data-Block oder beim 1024. Datenelement (ob Byte, Word, Long etc.) geschieht, da im getesteten Code ein Datenelement gerade ein Byte war. Das könnte man aber noch machen, indem man in den Data-Zeilen jeweils zwei bzw. vier Byte-Datenelemente zu einem Word- bzw. Long-Datenelement zusammenfasst und dann testet, ob es dann noch über das 50. Bild hinaus funktioniert.


    Das Fazit bleibt aber, das Data-Datenblöcke mit mehr als 1024 Elementen (oder ev. Bytes) in BASCOM fehlerhaft compiliert werden. Damit bleibt als einzig wirksamer Workaround für grössere Datenblöcke die Verwendung der $INC-Funktion zur direkten Einbindung von Binärdaten (also ohne dass BASCOM die Daten aus den Data-Zeilen erst als Binärblock generieren muss).


    Ich schau mal, ob ich demnächst (wenn ich etwas mehr Zeit habe) die Problematik einigermassen vereinfacht und klar im MCSELEC-Forum als Bug-Meldung posten kann, so dass es Mark Alberts (der Entwickler von BASCOM) auch nachvollziehen kann.


    Gruss
    Neni


    EDIT: Ok, nach einem kleinen Zusatztest bin ich mir nun sicher, dass das Problem tatsächlich bei 1024 Data-Elementen (egal welcher grösse) und nicht 1024 Bytes auftritt. Ich habe bei den Data-Zeilen der ersten zwei Bilder (Bild 0 und Bild 1) die Daten der Ebenen jeweils als ein Long-Integer-Element (anstatt der 4 Byte-Elemente) eingetragen. Damit benötigen die beiden ersten Bilder 'nur' 10 (jeweils 5) Elemente statt der 40 (jeweils 20) vorher. Das ergab also eine Einsparung von 30 Elementen. Von der Byte-Anzahl bleibt alles beim Gleichen und somit auch für die Lookup-Funktion, welche ja hier byteweise ausliest. Mit dieser kleinen Änderung tritt Fehler erst bei Bild 52, Ebene 3 (statt wie vorher Bild 51, Ebene 0) auf. Das sind zwischen 29 und 35 Byte (Data-Elemente) Differenz (also etwa der Einsparung von 30 Elementen entsprechend), je nachdem an welchen Stelle der Ebenen-Daten die Fehler genau auftreten, was ich nicht genau bestimmt habe.

  • JAAAAAAAAAAAAAAAAAAAAAAAAAAAA Fehler wurde gefunden!


    Zitat Borax von http://www.ledhilfe.de

    Ich danke euch allen auch noch mal für eure Hilfe! Das Prog werd ich am We uppen denke ich mal! ;)