Hallo ihr alle zusammen, hier im Forum gibt es immer wieder Nachfragen, was man denn als Hardware nehmen könnte, um mit dem Programmieren von ARM uC anzufangen. Häufig wird mit "nimm ein STM32F4 Discovery" geantwortet, was ja eingentlich nicht soooo verkehrt ist. Aber dieses Board hat fast nix drauf außer dem nackten uC. Die Betty hingegen hat nicht nur einen relativ riesigen Flash (2x 1 MB), sondern auch noch ein Grafik-Display, Tasten, RTC, Funkmodul, IR Sender und (mit Einschränkung) Empfänger, und (nicht zu verachten) ein Gehäuse. Obendrein ist sie auf recht billige Weise per Bootlader programmierbar und mit rund 4 Euro auch nicht teuer - und der Einstieg mit einem LPC2220 (ARM7TDMI) ist auch noch nicht wirklich veraltet. Eigentlich ist sie mit diesen Eigenschaften eine passable Basis für den Einstieg in die ARM-Welt. Aber: Die bei Bettyhacks herunterladbare "Boop"-Firmware ist alles andere als einsteigerfreundlich und in vielen Teilen ausgesprochen.. naja, ich sag mal "unpädagogisch" bis grob daneben (wenn ich mir z.B. den FIQ anschaue, kommt mir das Grausen). Meine Idee ist nun, für die Betty eine neue Firmware aufzusetzen, die deutlich einsteigerfreundlicher ist und die wichtigsten Funktionen per SWI erreichbar bereits eingebaut hat. Dabei sollte die Funktion als Fernbedienung eben nicht die Hauptrolle spielen, sondern es sollte auf einfache Weise möglich sein, kleinere Anwendungen zu schreiben, die auf die Dienste der eingebauten Firmware (Grafik, Tasten, Konvertierungen, Sound, Uhrzeit usw.) aufsetzen können ohne daß dazu der gesamte Kram neu übersetzt werden müßte. Wer den STM32-Primer2 von Raisonance kennt, weiß was mir da so etwa vorschwebt. Es sollte aber einfacher handhabbar werden als das Circle-OS. Frage an alle: Hat jemand Lust (und genug Ahnung), sich mit sowas zu befassen bis eine runde Sache dabei herauskommt? ( quasi den Forums-ARM-Primer zu kreieren ? ) Also: Gibt es Mitmacher? W.S.
:
Verschoben durch Moderator
Lust schon, aber aus Zeitgründen könnte ich nur einen kleinen Beitrag leisten. Verstehe ich dich richtig: Eine Art Bibliothek (oder Betriebssystem) auf der Betty die per SWI verwendet werden kann? Wie kommen dann Programme auf die Betty? Über den eingebauten Bootloader oder muss dann in der Firmware ein eigener Loader drin sein? Auf die Schnelle weiß ich jetzt auch nicht wie man den Programmspeicher löschen kann, müsste dafür ja auch sektorweise gehen? Grüße Walter (auch W.S.)
Bin momentan noch am Nachdenken über die Grundstrukturen. Aber im Grunde hast du schon Recht: Eine Art Mini-Betriebssystem, das den I/O über die diversen Kanäle (UART, I2C usw), Grafik, Fonts, Tastatureingaben usw. organisiert und per selbstdefiniertem API den Anwendungen zur Verfügung stellt, Zugriff über SWI und das Ganze im Flashrom 0. Dort passt dann noch eine Art Ladeprogramm hinein, mit dem man Anwendungen in den zweiten Flashrom laden kann. Ob das per Intel- oder Motorola-Hexfile oder in nem eigenen Format passiert, müssen wir erst noch sehen. Ebenso, wie die Flashroms im Großen organisiert sein sollen, also ob eine Art Filesystem oder ganz simpel gehalten oder so ähnlich wie die XIP-Strukturen bei den WinCE-Images. Die Idee mit dem Timer-Pool bei der Boop-Firmware finde ich nett. Aber den RAM für OS-Programmteile zu verballern, finde ich schlecht. Sind ja nur 64 K und von dem müssen noch mehrere Stacks, Bildschirmspeicher usw. abgezweigt werden - und den Anwendungen soll ja auch noch was übrigbleiben. Hast du schon mal mit dem RealMonitor dich befaßt? Eingebaut ist das Stück Software ja fast überall bei NXP - und gerade Neulinge schreien zuallererst nach einem Debugger um zu sehen, was der Compiler aus ihrer Quelle macht. W.S.
W.S. schrieb: > Hast du schon mal mit dem RealMonitor dich befaßt? Nee, wäre aber natürlich interessant. Wenn ich mir deine Ideen so durch den Kopf gehen lasse klingt alles gut, aber dann sehe ich die ganze Arbeit die da zu tun ist ... Was mich an der Betty etwas stört, sind die kaum vorhandenen Schnittstellen zur Außenwelt, von daher frage ich mich ob sich der Riesenaufwand "lohnt" oder ob man nicht einfach auf der Basis der Bettysoftware Verbesserungen/Erweiterungen macht. Walter
Es ist eigentlich bei der "Swissbetty" ne Menge frei (oder noch nicht herausgefunden..), u.a. auch 2 Analogeingänge, wenn ich mich nicht irre. Und sowas wie ne Smartcard brauchen wir wohl nicht. Das läuft darauf hinaus, auf die CPU eine kleine einseitige LP zu kleben, wo nur Lötaugen drauf sind: Damit man mit feinen CuL-Drähten diverse Pins kontaktieren und dort erstmal auf eine Lötinsel führen kann, von wo aus dann normale Litzen weitergehen können. Ich denke mal an nen Steckverbinder dort, wo die IR-Diode sitzt. Die kann man ja zur Seite rücken, um Platz zu schaffen. Ansonsten hab ich so einiges an Softwarestücken: GDI, Fonts, Zahlenkonverter (LongToString und Konsorten), Updatelader usw. schon seit langem in der Schublade. Es bleibt trotzdem ne Menge zu tun. W.S.
Angehängte Dateien:
-
Betty-Heaven.jpg
73 KB -
LPC2000Programmer.jpg
84 KB
So. Ich muß jetzt mal etwas Frust ablassen. Das Programm "Betty-Heaven" ist ja ganz nett gedacht, aber offenbar fast unbrauchbar. Den Grund kann man in den beiden angehängten Bildern sehen. Mal abgesehen, daß die Signale für /Reset und /Boot vertauscht sind im Vergleich zu den üblichen Tools wie FlashMagic und LPC2000Tool (was man durch Umlöten beheben kann), baut das Betty-Heaven ausgesprochenen Mist. Einige Zeit nach der eigentlich richtigen Resetsequenz gehen sowohl /Reset als auch /Boot wieder auf Low und erst danach kommt das zum Synchronisieren gesendete Fragezeichen. Kein Wunder, daß so viele Leute an diesem Programm verzweifelt sind. Der einzige Workaround besteht also darin, Reset und Boot von Hand per Mikrotaster o.ä. zu steuern. W.S.
W.S. schrieb: > Die Idee mit dem Timer-Pool bei der Boop-Firmware finde ich nett. Aber > den RAM für OS-Programmteile zu verballern, finde ich schlecht. Sind ja > nur 64 K und von dem müssen noch mehrere Stacks, Bildschirmspeicher usw. > abgezweigt werden - und den Anwendungen soll ja auch noch was > übrigbleiben. Moin, das ich seinerzeit einige Teile der Firmware in das RAM gepackt habe hat eigentlich einen recht einfachen Grund: Geschwindigkeit. Um das IR Signal zu erzeugen muss halt alles in Software gemacht werden, u.a. die Erzeugung des Trägers. Zugriff auf das RAM, sowie Ausführungsgeschwindigkeit von Code im RAM is wesentlich schneller als aus dem externen Flash. Am Ende stand ich vor der Wahl diese kritischen Funktionen im Flash zu haben, und so reichlich Zeit zu vertrödeln für die Zugriffe, oder eben das ganze in das RAM zu packen. Ebenso Teile z.B. der LCD Routinen. Ich hasse langsamen Bildaufbau, ist halt mein persönlicher Geschmack. Ziel war damals einfach nur etwas an Firmware zu bauen das als Fernbedienung funktioniert und rudimentären Zugriff auf die einzelnen Hardware-Teile erlaubt. Als das fertig war habe ich dann auch nicht mehr viel daran gemacht, da haben dann andere übernommen und weitergemacht. Vieles ging damals über das Forum dort, sowie in eMails, so das dort zwar Dinge erklärt wurden, diese Hinweise dann aber irgendwie nie im Quellcode als Kommentare auftauchten. Und ja, im Quellcode-Dokumentieren bin ich lausig ;) Klar, einiges würde ich Heute anders machen. Die Betty-Geschichte war mit eines meiner ersten ARM Projekte, dementsprechend neu und unerfahren war ich auf der Plattform. Grüße, Chris Edit: Achja, mit Betty-Heaven hatte ich auch oft Probleme, habe das aber auf die Tatsache geschoben das ich unter Linux arbeite, und das ganze dann mit Wine lief. Daher hatte ich dann mein eigenes Tool geschrieben, lpctool, welches den Firmware-Upload erledigt.
W.S. schrieb: > Aber: Die bei Bettyhacks herunterladbare "Boop"-Firmware ist alles > andere als einsteigerfreundlich und in vielen Teilen ausgesprochen.. > naja, ich sag mal "unpädagogisch" bis grob daneben (wenn ich mir z.B. > den FIQ anschaue, kommt mir das Grausen). Könntest du das bitte etwas näher erläutern. Das interessiert mich jetzt, so rein aus pädagogischer Sicht. Zum programmieren würde ich empfehlen JTAG mit OpenOCD anstatt von Betty-Heaven zu benutzen. Geht schneller und man kann damit auch On-Target debuggen. Gruß Telekatz
Die Idee, eine Betty als Evalboard zu nehmen, ist ja nett, aber leider gibts so gut wie keine lesbare Dokumentation für * Programmierung - wie flashe ich das Dings? * Hardware - was hat die Betty an nutzbaren Ressourcen und wie spreche ich sie an? Tasten, LCD, IR usw. * Was kann der MC? Gut, das lässt sich bei NXP zusammenklauben. Aber weder das Wiki noch das Forum hat irgendeine brauchbare Zusammenfassung oder ein 'Getting Started'. Ich werd mir allerdings mal in Zukunft ein oder zwei von den Dingern besorgen und dann mal sehen, ob man da nicht ein wenig Doku generieren kann.
A. S. schrieb: > Könntest du das bitte etwas näher erläutern. Das interessiert mich > jetzt, so rein aus pädagogischer Sicht. Also erstens: Soweit ich das beim Durchsehen der Quellen hab entdecken können, wird der FIQ sowohl für das Dudeln als auch für IR-Zwecke gebraucht. Obendrein gibt es ne Latte von Aufrufen in Reihe: vom FIQ zu einem Programmstück im Startup, von dort einen Call zu nem Handler in irq.c und von dort nochmal zwei Calls zu Dudeln und IR. Da bleibt vom FIQ nix mehr übrig. Sollte man SLIC nennen. Das Faste am FIQ ist ja gerade, daß er durch die hardwareseitige Registerumschaltung keine Register retten muß und deshalb mit einem stack von nur 4 Byte auskommt - wohlüberlegte Assemblerprogrammierung vorausgesetzt. Ansonsten ist er (wenn man das nicht so machen will) langsamer als ein gewöhnlicher Interrupt, weil man ja mühsam den FIQ-Status softwaremäßig wieder aufheben muß. Für nen gewöhnlichen vektorisierten Interrupt sollte man aber im Startup das stehenhaben: LDR PC,[PC, #-0x0FF0] ; Vector from VicVectAddr Damit kommt man mit 1 Befehl direktemang zur Interruptroutine - vorausgesetzt, man hat den Vektor richtig in den Interrupt-Controller geschrieben. Das ist viel schneller, als das, was da bei der Boop abgeht. Wesentlich sinnvoller wäre es also gewesen, beide Sachen strikt zu trennen. Der IR-Kram sollte dann den FIQ kriegen und komplettico in Assembler gehalten sein, was ja kein Problem ist, wenn man alle Sende-Berechnungen zuvor gemacht hat und die Nachbereitung beim Empfang danach erledigt. Der enorme Vorteil des FIQ ist es ja gerade, daß man einen zweiten Registersatz per Hardware hat (ich glaub ab R8) und deshalb sofort was tun kann, ohne Register retten zu müssen. Ellenlange Berechnungen sind aber nix dafür. Der Dudel-Interrupt kriegt dann seinen separaten Vektor als normaler vektorisierter Interrupt und sollte unterbrechbar sein, damit der FIQ zwischendurch ran kann. Bei der Dudelei wird ja sowieso ne Menge herumgerechnet, das sollte besser auch vorher erledigt worden sein, soweit geht. Nochwas: Ich sag's mal so: Wer sowas wie Get_CSPR und DisableIRQ benötigt, hat im Systementwurf was falsch gemacht. Ansonsten zur Pädagogik: Bei der Boop-Software geht alles durcheinander. Im Programmteil für den ADC wird Bildschirmausgabe betrieben, es erfolgt die Darstellung des Batteriesymbols usw. Sowas gehört dort nicht hin. Ich formuliere das mal ganz grob so: ---- Hardware ---- | | Treiber Treiber ... | | ---- Ereignisse ---- | Dispatcher | Menüsystem | Programmteile, die sich um die Darstellung kümmern. Beispielsweise sollte der ADC-Treiber die aktuellen ADC-Werte irgendwo bereitstellen, aber nicht sich darum kümmern, wie der Bildschirm aussehen soll. Der Systemtick hingegen sollte aber in angemessenen Zeitabständen sich sagen "Lassen wir mal das Menüsystem wissen, daß wieder mal ein Stück Zeit vergangen ist", beispielsweise eine Sekunde. Er würde also in die Ereignis-Warteschlange ein Ereignis hineinstopfen "EineSekundeIstUm". Die Grundschleife, in der sich der Prozesor die ganze Zeit herumdrückt, sollte schauen, ob ein Ereignis (Taste gedrückt, IR empfangen, IR fertig gesendet, Sekunde um, und so weiter) in der Ereignis-Warteschlange steht, selbiges nehmen und dem Menüsystem vor die Füße werfen. Wenn sich dann dort im Menüsystem ein Teil findet, der sich für das Umsein der Sekunde interessiert, dann ist das für diesen Teil ein Anlaß, sich zu rühren. So würde sich dann die Uhr auf dem Screen mit aktueller Uhrzeit neu zeichnen, die Batterieanzeige würde vom ADC-Handler den Wert abholen und das Symbol neu zeichnen usw. Ich hatte vor gefühlten 100 Jahren auch mal so prozedural und geradeaus angefangen zu programmieren, wie das in der Boop-ware aussieht, aber irgendwann verstrickt man sich in die eigenen Fallstricke und fällt auf die Nase. W.S.
Matthias Sch. schrieb: > Aber weder das Wiki noch das Forum hat irgendeine brauchbare > Zusammenfassung oder ein 'Getting Started'. Ja, eben !! Deshalb war hier mein Gedanke, diese Sache zusammen mal auf die Beine zu stellen. Zum sofortigen Reinhauen in die Programmiertasten ist es noch viel zu früh, erstmal nen Grundgedanken ausformulieren über die Systemstruktur als solche streiten, bis was dabei herauskommt. Dazu gehört auch, sich erstmal Klarheit zu verschaffen darüber, was man bei der derzeitigen "Swissbetty" an Hardware überhaupt vorfindet. Soweit ich es aus der Leiterplatte sehen konnte, sind z.B. mehrere ADC-Kanäle freigelegt und zweie davon sogar an Lötflächen geführt. Hab's auch mal während des Laufens oszillografiert und mal hochohmig auf 0 und 3.3V gelegt, Ergebnis: scheinen tatsächlich unbenutzt zu sein. Immerhin zwei relativ leicht anzuschließende ADC-Eingänge ist doch schon mal was. Dazu kämen noch diverse Anschlüsse, die zu überflüssigen Chips gehen (wer braucht nen Krypto-Dingens?) Aber ultimativ sehen kann man's erst, wenn man mal den LPC ablötet. und A. S. schrieb: > Zum programmieren würde ich empfehlen JTAG mit OpenOCD anstatt von > Betty-Heaven zu benutzen. Geht schneller und man kann damit auch > On-Target debuggen. Davon halte ich nun wiederum gar nichts. Grund: Viele Leute haben keinen wirklich gur funktionierenden JTAG-Adapter. Da ist Betty-Heaven zusammen mit nem FT232 ohne MAX232 aber mit nem Schalter für /BOOT und nem Taster für /RESET wesentlich einfacher beschaffbar. Abgesehen davon: Ich hab mir mal vor langer Zeit einen tollen J-Link Edu von Segger gekauft. Resultat: unbenutzbar. Nee, die Hardware geht bestens, aber es sind keinerlei Lizenzen dabei und sobald ich IRGENDWAS mit diesem Teil tun will, werde ich undezent daran erinnert. Das einzige, was geht ist Download in den RAM. Bäh.... W.S.
W.S. schrieb: > Also erstens: Soweit ich das beim Durchsehen der Quellen hab entdecken > können, wird der FIQ sowohl für das Dudeln als auch für IR-Zwecke > gebraucht. Obendrein gibt es ne Latte von Aufrufen in Reihe: vom FIQ zu > einem Programmstück im Startup, von dort einen Call zu nem Handler in > irq.c und von dort nochmal zwei Calls zu Dudeln und IR. Da bleibt vom > FIQ nix mehr übrig. Sollte man SLIC nennen. Dir ist aber bewusst zu welcher Zeit und mit welcher GCC Version das ganze mal gemacht wurde, oder? > Das Faste am FIQ ist ja gerade, daß er durch die hardwareseitige > Registerumschaltung keine Register retten muß und deshalb mit einem > stack von nur 4 Byte auskommt - wohlüberlegte Assemblerprogrammierung > vorausgesetzt. Ansonsten ist er (wenn man das nicht so machen will) > langsamer als ein gewöhnlicher Interrupt, weil man ja mühsam den > FIQ-Status softwaremäßig wieder aufheben muß. Für nen gewöhnlichen > vektorisierten Interrupt sollte man aber im Startup das stehenhaben: > > LDR PC,[PC, #-0x0FF0] ; Vector from VicVectAddr Wie gesagt, überlege mal welcher GCC zu der Zeit zur Verfügung stand, und welche Bugs er hatte. Dann dürftest Du recht schnell erkennen warum das mit den IRQ's im allgemeinen so war wie es war. Und warum nicht nur dieser Code das so macht. > Nochwas: > Ich sag's mal so: Wer sowas wie Get_CSPR und DisableIRQ benötigt, hat im > Systementwurf was falsch gemacht. Get_CSPR oder asm_get_cpsr? Verstehe mich nicht falsch, aber wer etwas bemängeln will, der sollte schon exakt sagen können um was es geht. Ach ja, und benutze mal Tante Google mit z.B. der asm_* Funktion. Und beachte mal die Tatsache das es eigentlich nut in Verbindung mit den LPC's auftaucht.... Und Du hast noch die Situation gehabt das Du kritischen Code hattest der am besten eben nicht durch einen IRQ unterbrochen werden sollte? Das heisst nicht das es in diesem Fall vorkommt, aber ist es wirklich so dumm eine entsprechende Funktion bereit zu haben für den Fall das man es mal braucht? > Ansonsten zur Pädagogik: Bei der Boop-Software geht alles durcheinander. > Im Programmteil für den ADC wird Bildschirmausgabe betrieben, es erfolgt > die Darstellung des Batteriesymbols usw. Sowas gehört dort nicht hin. > Ich formuliere das mal ganz grob so: > > ---- Hardware ---- > | | > Treiber Treiber ... > | | > ---- Ereignisse ---- > | > Dispatcher > | > Menüsystem > | > Programmteile, die sich um die Darstellung kümmern. Ja, wie gesagt, manches würde ich Heute anders machen. Andererseits: Wo ist das Problem an sich wenn die ADC Sachen den Batterie-Status auch gleich ausgeben? Bitte behalte im Kopf das es sich hier nicht um ein Dev-Kit handelt. Es handelt sich auch nicht um irgendein RTOS oder ähnliches. Boop wurde mit genau einem Ziel geschrieben: Eine Fernbedienung zu implementieren. Und das in einer Art die es ermöglich das ganze in Grenzen zu erweitern. Achja, und wenn Du mal das Vergnügen hattest die Original-Firmware bei der Arbeit zuzuhören, dann wirst Du vielleicht auch verstehen warum die Soundausgabe so erfolgt wie sie erfolgt. Warum soll es krachen und knacksen nur weill gerade auch etwas über IR gesendet wird? Hier funktioniert nämlich beides gleichzeitig, und das so das auch noch genug CPU Zeit übrig bleibt um anderes zu machen.... > Der Systemtick hingegen sollte aber in angemessenen Zeitabständen sich > sagen "Lassen wir mal das Menüsystem wissen, daß wieder mal ein Stück > Zeit vergangen ist", beispielsweise eine Sekunde. Er würde also in die > Ereignis-Warteschlange ein Ereignis hineinstopfen "EineSekundeIstUm". Ja, Ereignisorientierte Programmierung. My ass.... Sorry, aber wenn ich eine Taste betätige dann will ich auch sofort eine Reaktion haben. Ich finde es unmöglich das jeder Furz in irgendwelche Puffer gepackt wird die dann irgendwann mal bedient werden. Wer hat sich diesen Mist eigentlich für GUI's auf kleinen Embedded-Systemen ausgedacht? Die Dinger sind kein Desktop-Rechner der reichlich CPU Zeit übrig hat und schnell genug ist um alles so abzuarbeiten das es flüssig aussieht. Wenn ich eine Menü bediene dann will ich sofort eine Reaktion. Damit ich weiss das meine Eingaben akzeptiert wurden. Das System muss das machen was ich will, wenn ich es will. Ja, ich bin auch jemand der lieber 4 Datenleitungen mehr benutzt für ein Textdisplay anstatt sich mit dem 4-Bit Modus zu begnügen. Weil die Sachen dann schneller abgearbeitet werden. > Die Grundschleife, in der sich der Prozesor die ganze Zeit herumdrückt, > sollte schauen, ob ein Ereignis (Taste gedrückt, IR empfangen, IR fertig > gesendet, Sekunde um, und so weiter) in der Ereignis-Warteschlange > steht, selbiges nehmen und dem Menüsystem vor die Füße werfen. Wenn sich > dann dort im Menüsystem ein Teil findet, der sich für das Umsein der > Sekunde interessiert, dann ist das für diesen Teil ein Anlaß, sich zu > rühren. > > So würde sich dann die Uhr auf dem Screen mit aktueller Uhrzeit neu > zeichnen, die Batterieanzeige würde vom ADC-Handler den Wert abholen und > das Symbol neu zeichnen usw. > > Ich hatte vor gefühlten 100 Jahren auch mal so prozedural und geradeaus > angefangen zu programmieren, wie das in der Boop-ware aussieht, aber > irgendwann verstrickt man sich in die eigenen Fallstricke und fällt auf > die Nase. > > W.S. Ahja. Hey, hier ist ein Vorschlag: Mach es! Zeige und wie es richtig geht. So als Zeitrahmen gebe ich Dir mal 2 Monate, vorausgesetzt Du hast auch noch einen Job. Ansonsten machen wir daraus mal 2 Wochen. Oh, und das Ergebnis muss all das machen was Boop zu der Zeit als ich veröffentlicht habe auch konnte. Plus ein Tool für den Firmware-Upload. Was wann funktionierte kannst Du ja den entsprechenden Posts in dem Forum entnehmen (Netguy war mein ursprünglicher Nickname damals). Achja, und das ganze bitte genau so schnell und "responsive" wie das derzeit bestehende. Und nochmals achja: Ich habe den Original-Quellcode der Original-Firmware der Betty hier. Den haben wir damals von denen bekommen, wie auch den Schaltplan der Hardware. Da wird zum Teil mit eben solchem Ereignis-Müll gearbeitet. Was eben auch zu dem Ergebnis führt das Du kennen müsstest wenn Du die FB mal "im Original" benutzt hast. Und dann müsstest Du den Unterschied eigentlich auch sehen können. Der Code ist sicherlich nicht der schönste. Aber er macht was er soll. Und das macht er schnell. Ohne "Aussetzer". Er lässt sich in einem angemessenen Umfang relativ leicht erweitern. Wie z.B. neue FB Codes/Systeme. Aber ich kann mich nur wiederholen: Mach! Jetzt ist der 3.11., also können wir am 3.01. doch sicherlich von Dir eine FW sehen die das gleiche bietet, mit gleicher "responsiveness". Wenn Du einen normalen Job hast, natürlich. Ansonsten sollten wir doch am 18.11. was ordentlich sehen können, oder? Grüße, Chris
Angehängte Dateien:
-
lpc.png
300 KB
W.S. schrieb: > Ja, eben !! > Deshalb war hier mein Gedanke, diese Sache zusammen mal auf die Beine > zu stellen. Zum sofortigen Reinhauen in die Programmiertasten ist es > noch viel zu früh, erstmal nen Grundgedanken ausformulieren über die > Systemstruktur als solche streiten, bis was dabei herauskommt. Dazu > gehört auch, sich erstmal Klarheit zu verschaffen darüber, was man bei > der derzeitigen "Swissbetty" an Hardware überhaupt vorfindet. Dort wird man genau die gleiche HW finden wie bei allen Betty's. Da gibt es nämlich keine wirklichen Unterschiede. Lediglich die (Wieder-)Verkäufer nehmen halt alles aus dem Karton heraus das nicht nach FB aussieht: Den Scart-Adapter sowie den TEA Adapter. Beides sehr interresante Teile. Letzteres mit einem Chip für den man normalerweise kein DB ohne ein NDA bekommt. Normalerweise.... Und was die eigentliche FB angeht: Was ich in meinem vorherigen Post geschrieben habe bezieht sich natürlich auch darauf das man erstmal alles aus der originalen FW zusammensucht. Also IDA anwerfen und gucken. Nix mit fertigem Sourcecode auf den man sich berufen kann. > Soweit ich es aus der Leiterplatte sehen konnte, sind z.B. mehrere > ADC-Kanäle freigelegt und zweie davon sogar an Lötflächen geführt. Hab's > auch mal während des Laufens oszillografiert und mal hochohmig auf 0 und > 3.3V gelegt, Ergebnis: scheinen tatsächlich unbenutzt zu sein. Immerhin > zwei relativ leicht anzuschließende ADC-Eingänge ist doch schon mal was. > Dazu kämen noch diverse Anschlüsse, die zu überflüssigen Chips gehen > (wer braucht nen Krypto-Dingens?) Dabei auch mal alle Tasten benutzt? > Aber ultimativ sehen kann man's erst, wenn man mal den LPC ablötet. .... oder wenn man den originalen Schaltplan hat. Anbei mal ein Ausschnitt. Welche ADC Eingänge meintest Du nochmal? Grüße, Chris
Und übrigens: Für HW Erweiterungen bietet sich der unbestückte Connector für den Lauterbach ETM bestens an. Die TRACE* und PIPESTAT* signale liegen dort auf, welche sich auch als normale Portpins nutzen lassen. Ebenso liegt dort JTAG auf. Und natürlich VDD, EXTINT0 und RESET. Die Leitungen für den Smartcard-Chip kann man entweder als I/O oder z.T. als PWM nutzen, viel gibt es da nicht (enable, clock, i/o). Grüße, Chris
Angehängte Dateien:
-
vega.png
170 KB
... und warum der TAE Adapter so interresant ist, bzw. der Chip darin. Grüße, Chris
>Ahja. Hey, hier ist ein Vorschlag: Mach es! Zeige und wie es richtig >geht. So als Zeitrahmen gebe ich Dir mal 2 Monate, vorausgesetzt Du hast >auch noch einen Job. Ansonsten machen wir daraus mal 2 Wochen. Damit ist dieser Thread gestorben. Deine Antworten habe ich mit großem Vergnügen gelesen. Ich habe damals die Entwicklung bei bettyhacks verfolgt und weiß ungefähr, wieviel Gehirnschmalz damals verbraucht wurde. Und dann kommt so ein Mund- programmierer daher, und will alles besser machen, das ist schon lustig. Schöne Grüße Jack
Hallo zusammen, ich mische mich mal ein, weil ich auch in Vorbereitung bin, mich mit der Betty-Umgebung zu beschäftigen. Die bisher geleisteten Arbeiten schaffen die Basis dafür, dass Bastler wie ich sich überhaupt mit Betty beschäftigen können. Dafür haben sie Dank verdient. Natürlich lässt sich das alles besser machen. Aber mit welchem Einsatz? Die von W.S. eingebrachten neuen Ideen finde ich gut. Die vorgebrachte Kritik verstehe ich weniger als Vorwurf an die bisher wirkenden Personen, sondern als Anregung für ein sehr viel aufwändigeres neues Projekt. Warum versuchen wir nicht gemeinsam unsere Energie und Möglichkeiten zu bündeln und das Gesamtsystem zu einer neuen Höhe zu bringen? Also meine Bitte an die "Parteien" 1. Kritik konstruktiv zu formulieren und 2. Kritik nicht persönlich zu nehmen, auch wenn sie mal so verstanden werden könnte. Sobald meine Hardware von Pollin da ist, werde ich gerne "mitspielen" ... Gruß swausd
>Die von W.S. eingebrachten neuen Ideen finde ich gut. Das sind keine Ideen, sondern nur Vermutungen. Lies doch mal, was er schreibt: >Zum sofortigen Reinhauen in die Programmiertasten ist es >noch viel zu früh, erstmal nen Grundgedanken ausformulieren über die >Systemstruktur als solche streiten, bis was dabei herauskommt. Das heißt im Klartext: Ich hab noch überhaupt nichts auf der Hand, aber wir können schon mal ein bißchen quatschen. Schöne Grüße Jack
Jack Braun schrieb: >>Die von W.S. eingebrachten neuen Ideen finde ich gut. > > Das sind keine Ideen, sondern nur Vermutungen. > Lies doch mal, was er schreibt: > >>Zum sofortigen Reinhauen in die Programmiertasten ist es >>noch viel zu früh, erstmal nen Grundgedanken ausformulieren über die >>Systemstruktur als solche streiten, bis was dabei herauskommt. > > Das heißt im Klartext: > Ich hab noch überhaupt nichts auf der Hand, aber wir können schon mal > ein bißchen quatschen. > > Schöne Grüße > Jack Hallo Jack, die von Dir zitierten Punkte sind nicht "neu" und ich würde sie auch nicht als "Idee" bezeichnen wollen ;-). Und die bereits vorliegenden Arbeitsergebnisse der bisher Aktiven, sind beeindruckend, da stimme ich Dir zu! Auch die Dokumentation. Was ich beispielhaft aufführen möchte ist der Ansatz, die Betty als kostengünstige "all in one" Plattform für die Einführung in die Mikrocontroller-Programmierung einzusetzen. Gerne auch mit pädagogischem Ansatz, beispielsweise für Schulprojekte. Das ist die Basis für mein Interesse. In der Vergangenheit haben erste Versuche gezeigt, dass man Schülern der Oberstufe durchaus dafür gewinnen kann, entsprechende Vorbereitung eines passenden Umfelds vorausgesetzt. Vor diesem Hintergrund gäbe es also noch Optimierungspotential. Und dafür wäre es schön, wenn wir unsere Energie nicht mit Streiten vergeuden würden. Gruß Siegfried
swausd schrieb: > Und dafür wäre es schön, wenn wir unsere Energie nicht mit Streiten > vergeuden würden. Ja, schade eigentlich. Bei einem Entwicklungssystem wäre es eben auch schön, wenn man die Unterlagen bekommen könnte. Wie sieht es denn z.B. mit dem kompletten Schaltplan aus? Ist der rechtlich geschützt? oder ist das ein 'Schau was ich habe, aber ich gebs euch nicht' Ding? Mir jedenfalls zeigt dieser Thread, das es eben doch besser ist, ein Discovery Board zu nehmen, wenn es nicht mal möglich ist, eine sachliche Diskussion darüber zu führen, wie man die Betty den Neulingen näher bringen kann.
W.S. schrieb: > Ich hab > mir mal vor langer Zeit einen tollen J-Link Edu von Segger gekauft. > Resultat: unbenutzbar. Nee, die Hardware geht bestens, aber es sind > keinerlei Lizenzen dabei und sobald ich IRGENDWAS mit diesem Teil tun > will, werde ich undezent daran erinnert. Das einzige, was geht ist > Download in den RAM. Bäh.... Ähhh...wie kommst du dadrauf? Beim J-Link EDU ist alles dabei, was man braucht, Flash Download und Breakpoints sowie GDB Server (http://segger.com/comparison-charts.html). Unter welcher IDE bzw. wie hast du den J-Link EDU denn benutzt? Beim GDB Server musst natürlich schon per GDB Kommando angeben, welche CPU du flashen willst, damit der richtige Algo benutzt wird.
Jack Braun schrieb: >>Ahja. Hey, hier ist ein Vorschlag: Mach es! Zeige und wie es richtig >>geht. So als Zeitrahmen gebe ich Dir mal 2 Monate, vorausgesetzt Du hast >>auch noch einen Job. Ansonsten machen wir daraus mal 2 Wochen. > > Damit ist dieser Thread gestorben. > Deine Antworten habe ich mit großem Vergnügen gelesen. Ich habe damals > die Entwicklung bei bettyhacks verfolgt und weiß ungefähr, wieviel > Gehirnschmalz damals verbraucht wurde. Und dann kommt so ein Mund- > programmierer daher, und will alles besser machen, das ist schon lustig. > > Schöne Grüße > Jack Naja, wenn es jemand besser machen will, und dann auch macht, ist das ja erstmal eine feine Sache. Auch Kritik ist natürlich erwünscht, mann will ja vorwärts kommen. Was ich aber unmöglich finde ist, das nichts weiter als "Dies ist Mist. Und das da auch. Jenes dort ist ja gleich ganz unmöglich." zu lesen war, ohne konkret zu werden. Das ist einfach nur pure Nörgelei ohne Substanz. Wenn estwas schlecht ist dann sollte man 1) Zeigen können was genau daran schelcht ist, und 2) dann auch gleich zeigen wie es besser gemacht werden sollte. Grüße, Chris
Hallo Siegfried, >Was ich beispielhaft aufführen möchte ist der Ansatz, die Betty als >kostengünstige "all in one" Plattform für die Einführung in die >Mikrocontroller-Programmierung einzusetzen. Vor 5 Jahren wäre das vielleicht ein Knüller gewesen, mittlerweile gibts alle möglichen Boards für wenig Geld; sauber dokumentiert, mit Schaltplan und allem was dazugehört. Wenn Du Deine Stunden zusammenrechnest, die Du in die Betty investieren müßtest, dann kann von "kostengünstig" gar keine Rede mehr sein. >Gerne auch mit pädagogischem Ansatz, beispielsweise für Schulprojekte. Beim Reengineering können Dir die Schüler nicht helfen, und bis Du überhaupt mal einen Schaltplan zusammen hast, lassen die anderen, die vielleicht das STM Discovery benutzen, schon die ersten LEDs blinken. >Und dafür wäre es schön, wenn wir unsere Energie nicht mit Streiten >vergeuden würden. Bisher habe ich nichts von "Streiten" bemerkt, und Energie ist auch noch keine verschwendet worden. Schade wäre es nur, wenn harmlose Gemüter auf einen notorischen Selbstdarsteller hereinfallen würden. Schöne Grüße Jack
Christian Klippel schrieb: > Bitte behalte im Kopf das es sich hier nicht um ein Dev-Kit handelt. Es > handelt sich auch nicht um irgendein RTOS oder ähnliches. Boop wurde mit > genau einem Ziel geschrieben: Eine Fernbedienung zu implementieren. Und > das in einer Art die es ermöglich das ganze in Grenzen zu erweitern. JAJAJA! Genau das habe ich im Kopf. Meine Idee ist es nicht, eine noch bessere Fernbedienung zu bauen als du, sondern eben ein Eval-Board für Leute, die sich zwar in die ARM-Programmierung einarbeiten wollen, aber weder teuer Geld ausgeben können/wollen noch mit so steril ausehenden Boards wie dem von ST anfangen wollen. Also Dev-Kit und nicht Fernbedienung. Genau das ist anders als dein damaliges Anliegen. Hier haben wir ne Menge Hardware, die das Ding interessant machen kann, aber für die von mir angedachten Zwecke ist es besser, einen anderen Programmierstil zu fahren. Lies doch mal die unzähligen einschlägigen Beiträge hier in diesem Forum, wo nach Hilfe geschrien wird. So, Stand der Dinge bei mir: ich hab nur gelegentlich und dann auch nur zwischendurch Zeit dafür, hab auch mehrere andere offene Baustellen, aber ich hab bislang: 1. den Flash0 mal abgenommen und per Galep ausgelesen (hab's irgendwo schon mal gepostet) 2. IDA bemüht, aber da will ich eigentlich nicht weitermachen. 3. einen meiner Startup-codes von LPC2214 auf LPC2220 umgerubelt, Konfiguration in nen separaten Modul verfrachtet, UART eingerichtet, ein vorläufiges simples main zum Testen geschrieben und mich erstmal um die Tasten gekümmert. Mehrere Tasten separat zu dekodieren geht, bin momentan aber am Überlegen, ob es sich lohnt, alle Tasten separat zu entprellen und ob es sich lohnt, die Tastennummern in mehr oder weniger passende ASCII codes zu übersetzen. Mal sehen. 4. Die LCD-Initialisierung und Ansteuerung geht noch nicht, darum kümmere ich mich später. Das GDI hingegen geht, das weiß ich, weil ich es schon in diversen anderen Projekten benutzt habe. Bin bloß am Überlegen, ob es sich bei 4 Graustufen und nur 128x160 und nur einem Grafikdevice lohnt, mit Devicekontexten zu arbeiten. Bei Bastelprojekten mit Monochrom-LCD's hab ich DC's bislang weggelassen. Das Programmieren mit dem Betty-Heaven ist ne relativ langsame Sache, aber geht zuverlässig (wenn man Reset und Boot per Hand bedient). JTAG wäre schöner und schneller, hat aber nicht jeder. und: Christian Klippel schrieb: > Dir ist aber bewusst zu welcher Zeit und mit welcher GCC Version das > ganze mal gemacht wurde, oder? Nein. Ich stelle nur fest, daß sich mit meinen Tools die Boop-Quellen nicht übersetzen lassen. Weder mit dem steinalten Metrowerks (muß schon mindestens 10 Jahre alt sein) noch mit dem aktuellen Keil. Ja, ich arbeite beruflich mit Keil. Natürlich kenne ich die 32K-beschränkung von dessen Eval-Version und habe mir aus gutem Grund vorgenommen, Systemaufrufe per SWI einzurichten. Christian Klippel schrieb: > Und Du hast noch die Situation gehabt das Du kritischen Code hattest der > am besten eben nicht durch einen IRQ unterbrochen werden sollte? Nein. Noch nie. Allerdings habe ich mich vorher hingesetzt und zeitkritische Dinge durchgerechnet. Und so kommt es, daß meine Geräte auch ohne ein RTOS ne ganze Menge quasi parallel können, ohne daß sich verschiedene Teile spürbar in die Quere kommen. In diese Gefilde kommen wir hier aber erst sehr viel später, wenn sowas wie Soundausgabe und IR-Ausgabe/Eingabe aktuell werden. Bis dahin sollte aber das restliche Grundgerüst stehen. Christian Klippel schrieb: > Ja, Ereignisorientierte Programmierung. My ass.... > > Sorry, aber wenn ich eine Taste betätige dann will ich auch sofort eine > Reaktion haben. Hmm, meinst du nicht, daß ein systematischerer Entwurf letztendlich besser wäre? Mit der "Mit_dem_Kopf_durch_die_Wand"-Methode kriegt man irgendwann immer Schwierigkeiten. Glaub's mir einfach, daß ein eventgesteuertes Menüsystem besser ist. Bei meinem Empfängerprojekt hab ich ein vergleichbares LCD (Pollin, Sharp, 240x64) als Display drin und sowohl die Abstimmung als auch RSSI-Meter kommen ohne jegliche Zähigkeit. Noch besser wäre es, wenn man es hier echt objektorientiert machen könnte, aber das verbietet sich von selbst aus Ressourcengründen und auch wegen C. Aber dieses Forum ist ja genau dazu gedacht, daß man sowas diskutieren kann. Christian Klippel schrieb: > Ahja. Hey, hier ist ein Vorschlag: Mach es! Zeige und wie es richtig > geht. So als Zeitrahmen gebe ich Dir mal 2 Monate, vorausgesetzt Du hast > auch noch einen Job. Wie nett von dir. Mir klingt das aber ein bissel sehr hochnäsig. Ich schlag dir was anderes vor: Komm von deinem hohen Roß herunter und mache einfach mit. Sei positiv eingestellt, wir wollen hier nicht auf dem Turnierfeld sein und uns bekriegen. Wenn es stimmt, was du behauptest, daß du Schaltpläne, Quellen und sonstige Infos hast, die ich eben nicht habe, dann wäre es eine wesentlich freundlichere Geste, selbige zu posten, als mir hier irgendwelche Fristen setzen zu wollen. Dreistigkeit sowas. Das Thema, was ich angeschnitten hab, ist kein Egiosmus meinerseits, sondern eher was Gemeinnütziges. Das sollte von vornherein klar sein. Was bleibt, ist die bastlerische Freude. Also, ich frag nochmal: Gibt es Mitmacher? W.S.
Hallo Jack, unter wirtschaftlicher Betrachtung und mit Blick auf die Zukunftsfähigkeit der Plattform ist Deine Argumentation absolut stimmig. Ich sehe die Sache mehr aus diesem Blickwinkel: 1. Das Reverse-Engineering ist eine Herausforderung für mich mit kalkulierbarem Aufwand, weil ich sowas schon mehrfach gemacht habe und die Comunity in diesem speziellen Fall schon eine Menge Vorarbeit geleistet hat. Ich verbuche das unter Freizeitgestaltung für mich. 2. Stichwort "mach flott den Schrott" (ct). Nicht alles was alt ist, ist veraltet und reif für den Müll. Knüpft auch an 1. die Herausforderung an. 3. Der "all in one" Ansatz (ARM CPU, einfache Systemarchitektur, Funk Transceiver, Grafik-Display, Gehäuse und Tastatur) ist für ein Schülerprojekt ideal. Und das für einen sehr geringen Einstandspreis. Voraussetzung für die Nutzung, ist ein simples Framework. Ziel ist es z.b. innerhalb von 3-4 Tagen in einem Workshop eine Einführung in die Programmierung mit dem Ergebnis eines Multi-Client Schiffe-Versenken zu realisieren. Das ist meines Erachtens machbar - Vergleichbares habe ich schon praktisch durchgeführt. Natürlich nur unter intensiver Anleitung bzw. Betreuung. Geld verdienen kann man damit nicht. Die investierte Zeit rechnet sich aber aufgrund des Erkenntnisgewinns. Wer Hard und Software analysiert, wird sie auch besser verstehen, so zumindest meine Meinung. Ich habe mit Taschenuhren und Röhrenradios angefangen. Die Uni Karlsruhe bietet übrigens immer noch Studienarbeiten auf der Betty-Plattform an... Ich denke auch, dass nun genug geredet wurde und hoffe, die Geräte treffen bald bei mir ein, damit ich nicht nur theoretisieren muss ;-) Gruß Siegfried
W.S. schrieb: > 1. den Flash0 mal abgenommen und per Galep ausgelesen (hab's irgendwo > schon mal gepostet) Wozu? Lässt sich ja problemlos mit den vorhandenen Tools auslesen über die serielle, ohne das man da was ablöten muss. > 2. IDA bemüht, aber da will ich eigentlich nicht weitermachen. Auch das ist alles bereits geschehen. Dadurch haben wir das ganze ja erst zum laufen gebracht bzgl. der Hardware. Klassiches reverse-engineering halt. Irgendwann hat FAST dann freundlicherweise eine FW rausgebracht die im Flash noch Strings gesetzt hatte. Nämlich die Funktionsnamen/Prototypen des jeweils folgenden Codes. Somit ging das letzte bischen reversen noch einfacher. Ich habe da sehr, sehr viele Stunden in IDA verbracht. Erst lange nachdem alles schon gegessen war, sprich wir alles bereits benutzbar hatten, haben wir dann freundlicherweise von FAST den Schaltplan sowie die originalen Quellen bekommen. > Das Programmieren mit dem Betty-Heaven ist ne relativ langsame Sache, > aber geht zuverlässig (wenn man Reset und Boot per Hand bedient). JTAG > wäre schöner und schneller, hat aber nicht jeder. Dann nimm halt das lpctool. Lässt sich auch unter Win kompilieren und benutzen, und ist eine Ecke schneller. > und: > Christian Klippel schrieb: >> Dir ist aber bewusst zu welcher Zeit und mit welcher GCC Version das >> ganze mal gemacht wurde, oder? > > Nein. Ich stelle nur fest, daß sich mit meinen Tools die Boop-Quellen > nicht übersetzen lassen. Weder mit dem steinalten Metrowerks (muß > schon mindestens 10 Jahre alt sein) noch mit dem aktuellen Keil. Ja, ich > arbeite beruflich mit Keil. Natürlich kenne ich die 32K-beschränkung von > dessen Eval-Version und habe mir aus gutem Grund vorgenommen, > Systemaufrufe per SWI einzurichten. Hier wäre jetzt ein riesiges Facepalm-Bild genau das richtige. Das "wann" lässt sich ganz einfach durch einen Blick in die Boop-Quellen feststellen. Welche GCC Version ist ganz einfach durch das Wiki und Foren-Posts auf Bettyhacks zu erfahren. Und das Facepalm-Bild könnte man gleich nochmal benutzen, den GCC ist weder Metrowerks noch Keil. Er ist eben, nunja, GCC. Und da gab es seinerzeit meistens Versionen die einen Bug hatten: IRQ Code wurde fehlerhaft erzeugt so das ein Rücksprung zur falschen Adresse erfolgte. Der Entry-Code hat 4 vom LR abgezogen, auf den Stack gelegt. Und der Exit-Code hat dann nochmal 4 davon agezogen. Daher der Extra-Code dazwischen der das behebt, sowie das nicht-deklarieren der betreffenden Funktionen als interrupt, sondern ganz gewöhnliche Funktionen. Bei den neuesetn Versionen müsste das eigentlich behoben sein, aber man weiss ja nie. GCC hat ja leider manchmal das Problem das alte Bugs wieder reinkommen. Und bevor jemand dumm im Kreis herumläuft und sich wundert warum der Code zwar kompiliert, aber nicht funktioniert... > Christian Klippel schrieb: >> Und Du hast noch die Situation gehabt das Du kritischen Code hattest der >> am besten eben nicht durch einen IRQ unterbrochen werden sollte? > > Nein. Noch nie. Allerdings habe ich mich vorher hingesetzt und > zeitkritische Dinge durchgerechnet. Und so kommt es, daß meine Geräte > auch ohne ein RTOS ne ganze Menge quasi parallel können, ohne daß sich > verschiedene Teile spürbar in die Quere kommen. In diese Gefilde kommen > wir hier aber erst sehr viel später, wenn sowas wie Soundausgabe und > IR-Ausgabe/Eingabe aktuell werden. Bis dahin sollte aber das restliche > Grundgerüst stehen. Und oh Wunder, Boop hat das alles schon hinter sich. Daher sind die Dinge dort so wie sie sind. Was man eigentlich merken sollte. Aber einfach drauf los meckern wie schlecht doch alles ist, ja, das ist natürlich schon eine Ecke einfacher als vorher mal zu Fragen warum es so ist. > Wie nett von dir. Mir klingt das aber ein bissel sehr hochnäsig. Ich > schlag dir was anderes vor: Komm von deinem hohen Roß herunter und mache > einfach mit. Sei positiv eingestellt, wir wollen hier nicht auf dem > Turnierfeld sein und uns bekriegen. Sorry, aber die hochnäsigkeit kam in erster Linie von Dir. Das einzigste was Du hier vorgebracht hast war Meckerei ohne Substanz. Leuten erzählen wie schlecht das doch alles ist, ohne aber selber handfeste Beispiele zu bringen wie es besser sein sollte. An Sachen rummäkeln ohne zu wissen warum sie sond sind, siehe Beispiel des IRQ Codes. Ach was sage ich, ohne nicht einmal zu wissen das die Sachen mit GCC zu übersetzen sind, und stattdessen mit Metrowerks und Keil ankommen. Ernsthaft, es sieht so aus als ob Du dich genau Null mit dem bestehenden Code auseinandergesetzt hast, geschweige denn mal das Wiki/Forum auf bettyhacks durchgelesen zu haben. Soooo viel steht da nun auch nicht drin, kann also nicht am Volumen des Inhaltes dort liegen. > Wenn es stimmt, was du behauptest, daß du Schaltpläne, Quellen und > sonstige Infos hast, die ich eben nicht habe, dann wäre es eine > wesentlich freundlichere Geste, selbige zu posten, als mir hier > irgendwelche Fristen setzen zu wollen. Dreistigkeit sowas. Nein. Diese Sachen sind nachwievor (C) FAST, und daher kann und werde ich die nicht einfach so öffentlich zum Download anbieten. Sollte eigentlich klar sein. Andersherum wird ein Schuh draus: Du hättest ja mal freundlich anfragen können ob es da evtl. was gibt was man Dir zukommen lassen könnte. Meine Bemerkung das diese Sachen existieren, und andere sowie auch ich sie haben, hatte einzig und alleine einen Grund: Dir klarzumachen das andere schon etwas länger mit der ganzen Sache beschäftigt sind. Und die Fristen waren lediglich ein Vorschlag um Dir zu zeigen in welchem Zeitrahmen das alles ablief bevor ich da etwas vorzeigbares hatte. Ohne Pläne oder Originalquellen gehabt zu haben. Ich habe mir das alles mittels IDA zusammengereimt. Du hätetst hier sogar einen enormen Vorteil: Du kannst in offenen Quellcode gucken um zu sehen wie die jeweilige Hardware angesteuert wird. Stattdessen hast Du es vorgezogen lediglich über das bestehende zu meckern, mehrfach anzumerken wie schlecht da so manches doch ist. Und dabei schön vermieden etwas eigenes vorzuzeigen. Und auch ohne konkret zu zeigen welche Stellen denn wirklich so schlecht sein sollen. Achja, übrigens: Auch der original Quellcode zeichnet das Batteriesymbol aus der Battery/Charger Routine heraus. Eben da wo es hingehört. > Das Thema, was ich angeschnitten hab, ist kein Egiosmus meinerseits, > sondern eher was Gemeinnütziges. Angesicht der Tatsache das von Dir zwar viel Gemecker über das bestehende kam, viel heisse Luft wie das alles doch viel viel besser zu machen ist, und genau Null greifbares Ergebnis deinerseits... Sorry, aber das ist etwas was genau dich hochnäsig macht. Grüße, Chris
Christian Klippel schrieb: > Wozu? Lässt sich ja problemlos mit den vorhandenen Tools auslesen Tja, eben nur dann, wenn diese auch funktionieren, was bei mir damals noch nicht der Fall war. Dem Grund für das Nichtfunktionieren von Betty-Heaven bin ich erst später auf den Grund gegangen, siehe Oszi-Bilder weiter oben. Jetzt ist die Sache abgeklärt und erledigt. So. Du hast also keine Lust, was Positives zu diesem Projekt beizutragen. Nun denn, dann laß es sein, ich frag dich nicht nochmal dazu was. Aber tu dem Rest der Welt einen Gefallen: Mosere nicht alleweil dazwischen. Ich hab inzwischen mit der Testerei auf eigener Softwarebasis weiter gemacht und mal ein paar Fonts ausprobiert. Die in der Boop enthaltene LCD-Initialisierung hat's bei mir hartnäckig nicht getan, also hab ich auch dort mir was Eigenes geschrieben. Jetzt ist das Thema Grafik fast abgehakt. Mein bisheriger Code ist noch meilenweit entfernt von dem, was ich mir als Ziel vorstelle, deswegen poste ich erstmal nur nen Zwischenstand, der nur zu einem gut ist: diverse Fonts anzugucken. Mir gefallen sie alle noch nicht so richtig, aber wer will, gucke selbst. Einfach mit Betty-Heaven in den ersten Flashrom schreiben. Falls aber jemand hier "haben wollen, mitmachen wollen" ruft, dann häng ich den Iststand an nen nächsten Beitrag dran. Wie gesagt, mit Keil und nicht mit GCC. W.S.
>Wie gesagt, mit Keil und nicht mit GCC.
Da wird es wohl ganz schwer jemanden zum mitmachen zu finden;)
holger schrieb: >>Wie gesagt, mit Keil und nicht mit GCC. > > Da wird es wohl ganz schwer jemanden zum mitmachen zu finden;) Diese Aussage kann ich nur unterstützen. Ich werde auch gcc verwenden. Gruß Siegfried
holger schrieb: > Da wird es wohl ganz schwer jemanden zum mitmachen zu finden;) Hmm. Ideologie? Kann GCC kein C90 oder wenigstens klassisches ANSI-C? W.S.
>> Da wird es wohl ganz schwer jemanden zum mitmachen zu finden;) > >Hmm. Ideologie? Preis? Kein Privatmensch kauft sich eine Keil Vollversion. Mit der (32kB ?) Demoversion bist du doch schon mit drei Fonts im Flash am Ende.
holger schrieb: > Preis? Kein Privatmensch kauft sich eine Keil Vollversion. > Mit der (32kB ?) Demoversion bist du doch schon mit drei > Fonts im Flash am Ende. Und Verfügbarkeit. GCC (und die restlichen GNU Tools, wie z.B. make, etc.) gibt es für so gut wie jedes Host-OS. Grüße, Chris
W.S. schrieb: > holger schrieb: >> Da wird es wohl ganz schwer jemanden zum mitmachen zu finden;) > > Hmm. Ideologie? Kann GCC kein C90 oder wenigstens klassisches ANSI-C? W.S. schrieb: > Ich stelle nur fest, daß sich mit meinen Tools die Boop-Quellen > nicht übersetzen lassen. Weder mit dem steinalten Metrowerks (muß > schon mindestens 10 Jahre alt sein) noch mit dem aktuellen Keil. Genauso wie du Probleme hattest Boop mit deinen Tools zu übersetzen kann es Probleme geben deinen für Keil erstellten Code mit GCC zu übersetzen. Gruß Telekatz
MoinMoin, eigentlich finde ich das ursprüngliche Thema auch recht interessant, da ich letztens auf einem Flohmarkt eine Betty für 1,50 Euro geschossen habe... Allerdings bin ich recht verwundert, wohin die bisherige Diskussion abdriftet. Was soll der Müll, wer und warum den besseren Code schreibt? Immerhin hat Christian ein lauffähiges System geschrieben, nach besten Wissen und Gewissen, was auch funktioniert! @W.S.: zeige doch mal deinen Code und töne hier nicht so rum... und erstelle doch mal eine Projektseite, auf der du mal deine Ideen und Ziele für jedermann und in geordneter Form der Gemeinde zur Verfügung stellst! ...und ja, ich finde auch, dass gcc das Mittel der Wahl darstellt! Die meisten hier werden sich nicht einen kostenpflichtigen Compiler leisten wollen. Das es mit gcc auch gehen sollte, hat Christian schon bewiesen. Grüße Uwe
Christian ist sehr hilfreich, wenn man die richtigen Fragen stellt. Für mich ist es im Moment die Frage, wie weit die Abstraktion der Hardware gehen könnte. UCLinux z.B. teilt da fein säuberlich in I/O Devices mit Treibern für Framebuffer, Keyboard, IR usw. auf, während das ja die meisten anderen nicht so streng tun. Eine solche Unterteilung könnte m.E. hilfreich sein, kostet aber eben auch Flash. Ein lauffähiges uCLinux auf einem Dragonball (MC68EZ328) braucht eben 2MB Flash und min. 4MB RAM und da isses eng auf der Betty.
Uwe Berger schrieb: > MoinMoin, > > eigentlich finde ich das ursprüngliche Thema auch recht interessant, da > ich letztens auf einem Flohmarkt eine Betty für 1,50 Euro geschossen > habe... Falls Du mehr brauchst, PM an mich, habe noch komplette Sets hier. Also inkl. der SCART und TAE Adapter. > Immerhin hat Christian ein lauffähiges System geschrieben, nach besten > Wissen und Gewissen, was auch funktioniert! Danke, aber ich muss auch sagen das ich eigentlich eher den Grundstein dazu gelegt habe. Das heisst die ersten Versionen von Boop. Danach haben andere übernommen und weitergemacht, da es mir einfach an Zeit fehlt(e). Die jetzige FW ist da ordentlich erweitert worden von anderen. Grüße, Chris
Matthias Sch. schrieb: > Christian ist sehr hilfreich, wenn man die richtigen Fragen stellt. Der Ton macht halt die Musik ;) > Für mich ist es im Moment die Frage, wie weit die Abstraktion der > Hardware gehen könnte. UCLinux z.B. teilt da fein säuberlich in I/O > Devices mit Treibern für Framebuffer, Keyboard, IR usw. auf, während das > ja die meisten anderen nicht so streng tun. Eine solche Unterteilung > könnte m.E. hilfreich sein, kostet aber eben auch Flash. Ein lauffähiges > uCLinux auf einem Dragonball (MC68EZ328) braucht eben 2MB Flash und min. > 4MB RAM und da isses eng auf der Betty. Ja, das ist eben das verzwickte an der Betty. Für ein "großes" OS hat sie dann doch zu wenig Resourcen, für eine einfache FB ist sie aber völlig überdimensioniert. Ich hatte mir damals auch Gedanken gemacht wie man Flash und RAM erweitern könnte. Theoretisch würde das sogar gehen. P3.24/CS3 am LPC ist unbenutzt, da könnte der Chip-Select eines externen SRAM dran. Die Addressleitungen des Flash gehen bis A19. Am LPC sind auf A20 und A21 zwei Leitungen des Keyboards, die man aber auf ein Pin-Paar der noch freien P3.28/29/30/31 umlegen könnte. Wenn man also ein SRAM mit "gleichem" Pinout wie das Flash findet (welches ja lt. Footprint zwei unkonnektierte Addressleitungen hat) könnte man das Huckepack auf einen Flash löten und dann die entsprechende CS sowie die beiden extra Addressleitungen zum LPC fädeln. Allerdings ist so ein Umbau halt nicht wirklich trivial, also nicht von jedem so einfach machbar. Und das schränkt dann den Kreis derer, die sowas nutzen könnten, auch wieder stark ein. Dazu kommt noch das die Betty ja eher ein "one-off" Dingen ist. Ausser Restbeständen gibt es die nicht mehr. Sofern man dann nicht mini-OS macht, welches man auch auf anderen Plattformen verwenden will, endet das ganze dann in sehr viel Arbeit für ein obsoletes Nieschenteil. Wobei der Zeitfaktor im Hobbybereich ja eigentlich auch nicht so wild ist. Grüße, Chris
Hallo, mich würde ein ARM Eval Board, schon mit Display, auch stark interessieren. Im Keller habe ich auch noch 10 Betty Pakete liegen. Was mich aber davon abhält, die als Eval Board zu nehmen ist das unhandliche Format. Die sind als Fernbedienung ideal designed. Man kann auch ein tolles Tool für RC Modellbau daraus bauen (eben etwas, daß man so in der Hand halten kann und will). Aber in ein anderes Gehäuse sinnvoll einbauen, oder in ein anderes Gerät installieren kann man sie meiner Meinung nach nicht sinnvoll, die Platine hat da einfach das falsche Format. Deshalb ist für mich die Idee uninteressant. Ich nutze sie als Fernbedienung zuhause, ich habe mir die Tastenbelegung für meine Geräte eingebaut (im Code, nicht angelernt); dafür ist der Boop Code wirklich Super, da gibt es nichts dran zu meckern. Gruß, Bernhard
Wie sieht es eigentlich mit der Flash-Performance aus? Der Memory Controller im LPC scheint den Burst Mode zu beherrschen aber aufgrund der 16-Bit Anbindung wird eine "Beschleunigung" a la MAM wohl nicht möglich sein. MAM basiert ja auf dem 128-Bit breiten internen Flash den andere LPCs haben. Ich nehme daher an daß Code im RAM deutlich schneller läuft als im Flash. Oder wie sind da die Erfahrungen? - Michael
M. G. schrieb: > Wie sieht es eigentlich mit der Flash-Performance aus? Der Memory > Controller im LPC scheint den Burst Mode zu beherrschen aber > aufgrund der 16-Bit Anbindung wird eine "Beschleunigung" a la MAM > wohl nicht möglich sein. MAM basiert ja auf dem 128-Bit breiten > internen Flash den andere LPCs haben. > > Ich nehme daher an daß Code im RAM deutlich schneller läuft als > im Flash. Oder wie sind da die Erfahrungen? > > - Michael Ja, der Code im internen RAM ist wesentlich schneller. Nicht nur das der Flash nur mit 16 Bit angebunden ist, sondern er braucht auch noch Waitstates. Man braucht also für einen 32 Bit Zugriff zwei 16 Bit Zugriffe, jeder davon mit Waitstates. Daher hatte ich im Boop mehrere Funktion in das RAM gelegt (die .fastcode section). Ebenfalls kommt der "Umweg" des LCD Zugriffes über die rcu Funktion daher. Das LCD hängt ja am gleichen Bus. Würde man nun direkt den Code aus dem Flash auf das LCD schreiben lassen müsste man erst auf das Flash warten, und anschliessend auf das LCD, da auch dieses Waitstates benötigt. Durch die rcu, die im RAM liegt, wird erst der betreffende Speicherbereich aus dem LCD in das RAM gelesen, dort modifiziert, und dann wieder in das LCD zurückgeschrieben. Das hat die Grafikausgabe dann erheblich beschleunigt. Natürlich liegen auch "kritische" Sachen wie IR Ausgabe, Sound, RF, etc. im RAM, eben wegen der Geschwindigkeit. Grüße, Chris
Hehe, schön zu lesen, dass die Betty Idee wieder auflebt. Ich hab mir auch noch nach dem Hipe einen Karton Bettys geschossen: Beitrag "[V] Paket mit 16 Bettys" Zwei davon sind im alltäglichen Einsatz... Die Betty als reines DevKit zu nutzen habe ich immer geträumt, habe aber den Aufand geschäut die Boop Firmware entsprechend umzubiegen, da mir schlicht die Zeit fehlt... Aber ich würde es begrüßen wenn um die Betty wieder eine Interessengemeinschaft aufleben würde. Grüße Smarti
@Christian: Danke für die Erläuterungen. Ich habe bei einem Projekt mit einem LPC1758 eine ISR im RAM laufen. Geht damit gut 20% schneller. Aber bei dem externen Flash der Betty würde ich spielerisch einfach mal 300+% ansetzen (thumb mode). Da lohnt es sich schon sich zu überlegen welchen Code man wo ausführen läßt ;).
M. G. schrieb: > @Christian: > > Danke für die Erläuterungen. Ich habe bei einem Projekt mit einem > LPC1758 eine ISR im RAM laufen. Geht damit gut 20% schneller. > Aber bei dem externen Flash der Betty würde ich spielerisch > einfach mal 300+% ansetzen (thumb mode). Da lohnt es sich schon > sich zu überlegen welchen Code man wo ausführen läßt ;). Ja, das externe Flash ist da echt langsam. Der 1758 hat ja internes Flash, welches einen wesentlich schnelleren Zugriff erlaubt. Ich bin mir nicht ganz sicher, aber hatten die mit internem Flash dann nicht auch noch einen eigenen Bus bzw. Controller dafür, der den Zugriff beschleunigt? Irgendwas war da, weiss aber nicht mehr genau was. Aber naja, man muss ja auch im Auge behalten das es sich bei den Dingern um Microcontroller handelt, und keine reguläre CPU. Klar, ein "dicker" µC, aber doch eben nur µC. Und dafür sind die Teile doch recht schön, finde ich. Grüße, Chris
Hallo zusammen, nachdem meine Bettys von Pollin in der letzten Woche eingetroffen sind, habe ich am Wochenende nun auch praktische Erfahrungen machen können, von denen ich einige hier weitergeben möchte. Da für ein Schülerprojekt Windows die Plattform sein wird, habe ich als Entwicklungsumgebung Yagarto unter Windows 7 eingerichtet http://yagarto.de/ Dabei ist gcc 4.7.2 die Basis. Um die original Betty-Boop Firmware von hier http://boopfirmware.svn.sourceforge.net/viewvc/boopfirmware/ übersetzen zu können, musste ich die Makefiles an meine Umgebung und an den aktuellen Stand der Toolchain anpassen. Dazu waren Lib-Pfade für lc und lgcc anzupassen. Weiterhin fehlten einige Bibliotheksfunktionen (wie z.B. _sbrk) die ich durch folgende Datei libnosys_gnu.c ergänzt habe, die ich von hier http://sw.lpcware.com/?p=lpc3xxx_cdl.git&a=blob&hb=ec41f56c91f32003562f9c8f2acbfbdf7a367f8c&f=csps/lpc313x/bsps/ea3152/source/libnosys_gnu.c habe. Nun ließ sich die Firmware bauen. Da ich noch einiges mit ARM-CPUs vorhabe, habe ich mir folgenden JTAG Adapter gegönnt: https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/ den Watterott super schnell geliefert hat. Nach entsprechendem Studium des folgenden Threads auf bettyhacks http://bettyhacks.com/forum/index.php?topic=160.0 habe ich mir einen Adapter 20 polig JTAG auf 12 Polig Betty (siehe hier http://www.bettyhacks.com/wiki/index.php/Betty_Hardware) auf einer Lochrasterplatine angefertigt. Nach einigem Probieren habe ich den Adapter abweichend zur obigen Foren-Beschreibung eränzt: JTAG (Pin 15) RESET mit Betty (Pin 9) nRESET sowie einen Widerstand 10K von JTAG (Pin 4) RTCK nach JTAG GND (Pin 4) und einen weiteren Widerstand 4,7K von Betty (Pin 9) nRESET nach Betty (Pin 7) 3,3V. Die Widerstände waren notwendig, damit JTAG auch ohne funktionsfähige Firmware in der Betty initialisiert wird und auch Reset zuverlässig funktioniert. Das Betty.cfg Script für die openocd Initialisierung habe ich meiner Umgebung entsprechend angepasst. Nun lässt sich die Firmware via JTAG und openocd flaschen. Erste Experimente mit gdb, dem Debugger, waren auch vielversprechend. Wirkliche Erfahrungen über das Stoppen und Starten der Firmware hinaus habe ich damit aber noch keine gemacht. Nach dem Flaschen war ich sehr erstaunt, dass die Firmware auch im Wesentlichen funktionierte! Das hatte ich nicht erwartet. Die Steuerung meines TVs mit der Standadreinstellung sowie die Games funktionieren. Fehlfunktionen habe ich noch keine entdecktz, es wurde aber auch nicht alles probiert. Ach ja, ich habe den Define für die Swiss-Betty Tastatur im Keyboard-Include-Datei gesetzt, da die aktuellen Pollin Geräte dieser Bauart entsprechen. Die von mir angepassten und oben benannten Dateien sind in der Anlage zu finden. Vielleicht helfen sie jemandem. Bitte dabei im Auge behalten, dass ich kein besonderer Experte bin und die Ergenisse empirisch durch Versuche ermittelt wurden. An dieser Stelle möchte ich meiner Bewunderung über die geleistete Vorarbeit des Betty-Boop-Teams Ausdruck verleihen. Super Arbeit, die da geleistet worden ist! Danke! Und wie bereits Matthias Sch. oben schrieb, ist Christian Kippel sehr hilfsbereit, wenn man freundlich die richtigen Fragen stellt. Danke, Christian, auch noch mal an dieser Stelle. Gruß Siegfried
Ja halloo... hab jetzt auch 4 bettys von pollin zu liegen. Würd gern mal ein Basis-system zusammensetzen welches die Hardware-komponenten (Display, Funk, Tastatur, etc.) jeweils als "treiber" ansprechen kann. Zum debuggen ist JTAG ja wohl gut. Kann man das auch selbst basteln, JTAG-interface? SW-Tools? Welche Kompiler Umgebung ist angesagt? GCC ? Suche ein paar praktische Tips zum Starten. Gruss T.
Hallo Tom, dass gcc einsetzbar ist, habe ich im Beitrag direkt über Deinem ausgeführt. Für ein Fun-Projekt aus meiner Sicht ein gutes Preis/Leistungsverhältnis. Einen JTAG Adapter kann man selbst bauen, ja. Aber die mit Parallelinterface sind mangels fehlender Schnittstelle an den PCs und wegen der geringen Geschwindikeit nicht erstrebenswert. Ha e ich selbst ausprobiert. Und die USB Adapter zum Selbstbau sind entweder echte halbfertige Bastelprojekte oder aber aufwändig von der Herstellung. Daher habe ich eine Lösung gekauft, um mich zunächst auf die Betty konzentrieren zu können. Ansonsten solltest Du diesen Thread lesen und dich bei www.bettyhacks.com schlau machen. Gruß Siegfried
Ja danke siegfried, nun fangen wir doch erstmal ganz prakmatisch an. Also die Betty ist mit zwei Accus zu bestücken, also Ub=2.4V. gehe davon aus, das die Signale alle 3.3V kompatibel sind (betty läuft auf 2.4V). Die Betty hat einen Bootloader mit dem man via seriell software flashen kann. Aktivierung: Reset ind INT1 Pins auf GND legen. Dann reset loslassen und dann INT1 loslassen. Dann sollte sich der Bootloader melden. BettyHeaven ist das Program dazu. Baud=115200,8N1. 3.3V pegel. Muss ich eigentlich zum flashen die Batterien einlegen oder kann man auch 3.3V über einen Pin einspeisen? oder doch nur 2.4V? Was jetzt JTAG angeht, so fange ich gerade erst damit an. Hab ein bischen gelesen. Es gibt "intelligente" Adapter die einen prozessor drauf haben die die jtag-sequenzen schon im program haben, und ganz einfache Adapter wo alles software-mässig auf dem PC läuft. Einfache Adapter wären zB der Wiggler (parallel port) oder ein USB_to_serial adapter FT2232. Das Software Angebot ist recht verwirrend. Opensource wäre wohl angesagt. Vielleicht WINARM? Grundsätzlich möchte man dann auch über jtag debuggen, steppen, breakpoints etc. und das wenn möglich nicht auf Terminal-ebene. Einen Wiggler hab ich. Was empfielt der Experte an Software? Hat jemand zufällig die komplette Pinbelegung des Servicesteckers in der Betty.? Gibt es eigentlich einen Betty Schaltplan?
Angehängte Dateien:
-
RIMG0001.JPG
49 KB
Tom K. schrieb: > Das Software Angebot ist recht verwirrend. So? Naja, dann mußt du dort halt durch. Wenn es schon GNU sein soll, dann würde ich dir empfehlen, RIDE7 von Raisonance dir mal runterzuladen. Das sind die mit dem "Circle OS" und deren GNU-Variante soll wohl angeblich recht ordentlich sein. Ansonsten hänge ich hier mal 2 Dateien dran: Ein Bild, das von Bettyhacks stammt und mein Vorentwurf für das, was ich gerade an der Betty mache. Meine "BettyBase" läuft schon ganz ordentlich, bloß den bislang vernachlässigten Systemtimer muß ich noch in Fasson bringen. Dann dürfte es soweit sein, die allererste Version zu posten. Ich werd das aber im Bereich Codesammlung tun, denn dort dürfte es am ehesten hingehören. Was das ewige Schielen nach JTAG-Adaptern betrifft: Da kann ich nur dazu raten, die Sache kritisch zu sehen. Ich hab hier auch so einige verschiedene Adapter herumfliegen, vom steinalten Wiggler, der nie je sauber funktioniert hat, über das Parallelkabek#3 von Xilinx, das mit Impact und deren Chips immer noch sauber und zuverlässig funktioniert, über ein Teil auf FT2232 Basis, wofür es niemals funktionable Treiber gegeben hat, über mehrere Adapter von Nuvoton, die nur mit Nuvoton-Chips können bis hin zu einem technisch sehr guten Teil von Segger, was als solches zwar bestens funktioniert, wofür ich aber keine ausreichenden Lizenzen hab, um damit irgendwas zu programmieren - und dafür auch nicht mal eben 400 Euro abdrücken will. Besorg dir nen USB zu Serial Adapter, der TTL-Anschlüsse hat und benutze Betty-Heaven und gut isses. Das geht und kostet fast nix. W.S.
Hi "Gast" WS. ;-) Cool, danke für das Pinout und Support.pdf. Jaja diese jtag adapter. Das is auch irgendwie ein gutes Geschäft denke ich. Die eigentliche Datenübertragung (hardware) ist ja nix dolles. Eben eine serielle Übertragung wie zB auch ein ISP adapter. Die Software muss eben die jtag-sequenzen bilden und übertragen. Übersprünglich als PinLevel Tester gedacht ist es nun auch zum flashen und debuggen geeignet. sprich, spezielle sequenzen sind dann die flash oder debug befehle. (soweit ich das verstanden habe). Ich denke mal, es liegt nur an der software das es richtig funktioniert. Hät gern einen debugger der über die jtag-schnittstelle den zugriff auf die cpu ermöglicht. Werd mir mal die RIDE7 Geschichte anschauen. Achja, kann ich die Betty über die zwei Pins (3.3V/GND) mit power versorgen? freundliche Grüsse!
Man oh man ... wenn ich die Zeiten sehe, zu denen Ihr Beiträge schreibt denke ich: schlaft Ihr eigentlich nie? Oder schlaft Ihr jetzt noch ;-) Hallo W.S., die umfangreiche Dokumentation in dem PDF-Dokument sowie die Ankündigung Deiner Arbeitsergebnisse macht mich neugierig darauf, was da kommen mag. Das sieht doch sehr vielversprechend aus! Einige Deiner festgeschriebenen Ansichten teile ich nicht unbedingt, aber wer den Text schreibt, darf den (pädagogischen) Ansatz bestimmen. So halte ich den Einsatz von JTAG und IDE durchaus für sinnvoll. Wenn Du wie Du schreibst in der Software-Entwicklung arbeitest, wirst Du entsprechende Werkzeuge zur Produktivitätssteigerung auch verwenden, nehme ich an Als alternative Umgebung kann ich nur nochmals auf Yagarto verweisen (gcc, eclipse, openocd). Die ist meiner Erfahrung nach funktionsfähig. Auf ein Werkzeug zur Menü-Erstellung könnte ich für überschaubare Anwendungen beispielsweise verzichten. Programmieren würde ich solche Tools nicht. Wenn sie existieren würden, würde ich sie natürlich nutzen. Andererseits stimme ich Dir zu, dass ein ernsthafter Interessent sich mit der Hardware bis zum "Blech" und dahinter beschäftigen sollte. Ich selbst muss mich zunächst noch etwas mit der ARM Theorie beschäftigen (weil ich mich zu den oben genannten ernsthaften Interessenten zähle). Mein letzter Kontakt mit ARM7tdmi ist schon einige Jahre her. Zurzeit versuche ich den lpc2220 Start-up für das Starten im RAM zu verstehen. Bin also sehr an Dein Framework interessiert und gehe davon aus, dass es an gcc angepasst werden kann. Daran werde ich gerne mitwirken. Vielleicht bist Du ja bereit auch Deinen Zwischenstand zu zeigen. Dann könnten andere sich unnötige Doppelarbeit sparen und einen Teil Deiner Arbeit übernehmen. Gruß Siegfried
Tom K. schrieb: > Achja, kann ich die Betty über die zwei Pins (3.3V/GND) mit power > versorgen? Mach es lieber nicht. Ich hab's so nicht ausprobiert, aber die Betty hat einen Schaltregler drin, der aus der Batteriespannung die 3.3V macht. Als ich die Batterianzeige programmiert habe, hab ich's ausprobiert: so ab 2.12 Volt fängt die Betty an, zu arbeiten und mehr als 2.8 Volt wollte ich ihr nicht zumuten. Die beiden dicken Kontaktflächen gehen direkt an die Akkus. Der Laderegler sitzt also in der Ladeschale. Siegfried W. schrieb: > So halte ich den Einsatz von JTAG und IDE durchaus für sinnvoll. Du verwechselst etwas: Ich finde IDE's und JTAG nicht schlecht, ABER: etwas wirklich gut funktionales kostet auch richtig Geld und wir schreiben hier über ein Projekt, das pekuniär auf kleinster Stufe angesiedelt sein soll. Das Hauptaugenmerk soll also nicht darauf liegen, wie man sich nen Keil für einige KiloEuro leistet oder sich nen teuren Adapter und noch viel teurere Software irgendwo kauft oder sich damit beschäftigt, irgendeine spezielle IDE mit deren Befindlichkeiten richtig aufzusetzen. Auch Eclipse will erstmal eingerichtet sein. Und nochwas: Ich möchte nicht, daß das Projekt zwingend an irgendeine bestimmte Toolchain gebunden ist, sondern eher, daß verschiedene Leute mit unterschiedlichem Equipment miteinander zurechtkommen. Da ist ne simple Batchdatei (oder ein simples Script unter Linux) der kleinste gemeinsame Nenner und die Verwendung von Betty-Heaven beim Programmieren ebenfalls. Stell dir einfach vor, du wärest ein Schüler mit 10 Euro Taschengeld und wolltest dir nicht nur die Nase von außen an der Fensterscheibe plattdrücken, sondern mitmachen - deshalb habe auch ich mir verkniffen, hier großartiges Equipment aufzufahren. So ungefähr ist mein gedanklicher Ansatz. Wer besseres Equipment hat, wird es sicherlich benutzen, aber das Gesamtprojekt soll bittesehr nicht davon abhängig werden. W.S.
Hallo W.S., die Argumente zu JTAG und den dadurch verursachten Kosten kann ich nachvollziehen. Die Einschränkung auf die Basis-Investition von 10 EUR kann ich mir problemlos vorstellen, da ich mit meinem Einsatzziel da drunter bleiben muss. JTAG ist natürlich nicht enthalten. Die IDE nebst Toolchain schon. Zum Aufwand des EInrichtens einer Toolchain kann ich nur sagen, dass Yagarto nach Anleitung funktioniert. In Eclipse können Makefile-Projekte problemlos bearbeitet werden, also kein Problem für Deine Vorarbeiten. Die Kosten dafür sind 0 EUR. Es spricht also nichts dagegen, die Basis ausschließlich auf Makefiles aufzubauen. Dann kann sich jeder sein Umfeld anpassen bzw. es können, wenn interesse besteht, unterschiedliche Umgebungen vorkonfiguriert werden. Es sollte nur niemand durch den puristischen Ansatz abgeschreckt werden. Das wäre schade, da der bisher von Dir und anderen investierte Aufwand dann ins Leere ginge. Eine Anmerkung zu Deinem Framework. Die bisherige Doku deutet an, dass es sich um eine leistungsfähige, aber auch komplexe Umgebung handeln wird. Dies ist für erfahrene Anwender vielversprechend. Für Anfänger/Schüler sollte die Komplexität überschaubar bleiben, damit schnelle Erfolge aber auch die Chance des Verstehens gegeben ist. Dafür ist eventuell weniger Funktionalität hilfreich. Bin gespannt auf den Zeitpunkt, wenn Du die Katze aus dem Sack lässt ;-) Gruß Siegfried
Hallo W.S., vielen Dank für Deinen Beitrag. Man kann sehen, da steckt eine Menge Arbeit drin. Ich habe mir die BettyBase unter dem Gesichtspunkt der Anpassung an die Gnu-Toolchain angesehen. Folgendes ist festzustellen: 1. Die C-Programme kompilierem aber Umschaltung zwischen ARM und THUMB lässt sich nicht mit Pragmas erledigen. Hier ist wohl eine Trennung in verschiedene Dateien vorzunehmen, damit für jede Datei einzeln mit Compiler-Direktiven die ARM oder THUMB Option eingestellt werden kann. 2. Interrupt Service Routinen müssen mit void _attribute_ ((interrupt("IRQ"))) eingeleitet werden. 3. SWI Aufrufe mit Parametern werden meines Erachtens von gcc nicht unterstützt. Hier ist ein Workaround nötig. 4. Die Assembler-Datei Startup_LPC2220.asm ist mit gas nicht zu assemblieren. Hier ist meiner EInschätzung nach ein komplettes Umschreiben notwendig, weil einfach zu viele Abweichungen gegeben sind. Das ist mir bisher aufgefallen. Ein lauffähiges System habe ich bisher noch nicht erstellen können. Gruß Siegfried
Ja. Ich hab heute mal versucht, den Startupcode mit nem Gnu-Assembler (arm-eabi-....-as.exe) zu übersetzen. O Gott, das Teil kriegt sich ja garnicht mehr ein. Völlig inkompatibel zum Assembler von ARM. Wenn man alle Kommentare entfernt, dann geht's weiter: EQU versteht er nicht, muß man durch = ersetzen. Ob das dann etwas ist, was man exportieren kann, oder bloß wieder mal ne lexikalische Ersetzung, hab ich noch nicht herausfinden können. Sämtliche organisatorischen Anweisungen gehen auch erstmal nicht (AREA, ENTRY, die Stackpreserves, ARM ...) Obendrein ist es mir nicht gelungen, diesem Assembler eine sinnvolle Übersetzungsliste zu entlocken. Normalerweise erwartet man, daß der Assembler den Quelltext auf der rechten Seite, den erzeugten MC auf der linken Seite und die etwaigen Fehlerbemerkungen zwischendurch in die Ü-Liste einträgt. Aber bei diesem Gnu-Assembler krieg ich zwar tonnenweise Fehlermeldungen auf dem Konsolenfenster, aber nix dergleichen in den Ü-Liste. Kurzum, ich brauch erstmal ein Bier, um mich zu beruhigen.. Sonst fang ich an, hier über Gnu mich auszuwerfen. Ich hänge hier mal den Startup per ARM-Assembler übersetzt dran. Das Objektfile ist ein .ELF und das läßt mich hoffen, daß es sich eventuell auch vom Gnu-Linker linken läßt. Vielleicht kannst du das ja mal kurz testen. Falls es der Librarian in eine Lib verfrachten kann, sollte es eigentlich gehen. W.S.
Hallo W.S., sorry, aber ich hatte bisher keine Zeit meinen Stand zu berichten. Um Doppelarbeit zu vermeiden, sollten wir - die hier mitmachen wollen - uns etwas besser abstimmen. Anbei mein bisheriges Ergebnis bei der Anpassung der asm-Datei. Assemblieren ist fehlerfrei möglich. Da ich aber noch Verständnisprobleme mit dem Linken habe, kann ich nicht sagen ob es auch funktioniert. Die von mir vorgenommenen Änderungen habe ich in der Datei Changelog.txt zusammengefasst. Änderungen habe ich rein mechanisch vorgenommen. Auf Formatierung habe ich nicht geachtet. Bin zurzeit dabei zu verstehen, was in Deinem Code vorgeht. Sehe es als Fingerübung an, mich mit der Betty-Systemumgebung auseinanderzusetzen. Ob ich auf dieser Basis weitermachen will, habe ich noch nicht entschieden :-) Es wäre hilfreich, wenn Du bei Änderungen die Dateien nicht vollständig neu formatieren würdest. Dann könnte ich anhand eines Diffs zwischen den Versionen nur die Änderungen in meinen Gnu Stand übernehmen. In einem weiteren Schritt ist dann conditional compiling für die c-Module und eine Anpassung der asm-Module beispielsweise über sed möglich. Nur so eine Idee. Zunächst will ich die Base zum Laufen bringen. Dann sehen wir weiter. Mit anderen Worten: Ich versuche die gnu-Version der Base ans Rennen zu bringen. Du machst auf dem Keil Stand weiter (Fehlerbeseitigung ...). Über Fortschritte berichten wie hier. Und wer mitmachen möchte, tut dies ganz zwanglos ... Gruß Siegfried
W.S. schrieb: > Ja. Ich hab heute mal versucht, den Startupcode mit nem Gnu-Assembler > (arm-eabi-....-as.exe) zu übersetzen. O Gott, das Teil kriegt sich ja > garnicht mehr ein. Völlig inkompatibel zum Assembler von ARM. Was ganz einfach daran liegt das der GNU Assembler halt für mehr als nur eine Platform zu gebrauchen ist. > Wenn man alle Kommentare entfernt, dann geht's weiter: EQU versteht er > nicht, muß man durch = ersetzen. Oder durch .equ > Ob das dann etwas ist, was man > exportieren kann, oder bloß wieder mal ne lexikalische Ersetzung, hab > ich noch nicht herausfinden können. Sämtliche organisatorischen > Anweisungen gehen auch erstmal nicht (AREA, ENTRY, die Stackpreserves, > ARM ...) http://www.cse.unsw.edu.au/~cs3221/labs/assembler-intro.pdf http://tigcc.ticalc.org/doc/gnuasm.html http://sourceware.org/binutils/docs-2.21/ld/ > Obendrein ist es mir nicht gelungen, diesem Assembler eine sinnvolle > Übersetzungsliste zu entlocken. Normalerweise erwartet man ... Normalerweise erwartet man das ein Tool die Dinge so macht wie sie in der entsprechenden Doku stehen. Man erwartet nicht das ein Tool sich identisch zu einem völlig anderen Tool verhält. Und schon garnicht erwartet man das sich etwas, das man nicht kennt bzw. dessen Bedienung man nicht kennt, gleich beim ersten mal genau das macht was man sich so denkt. Achja, natürlich bleibt es dir ganz alleine überlassen welche Tools Du benutzt. Allerdings halte ich das Verwenden eines proprietären Tools das eine Stange Geld kostet für kontraproduktiv. Denn damit wird automatisch ein Großteil der interresierten Leute ausgeschlossen. Insbesondere wenn das ganze eine Eval/Dev-Platform werden soll. Desweiteren: Gäbe es Keil denn überhaupt auch für andere Plattformen außer Windows? Grüße, Chris
Hallo zusammen, die prinzipielle Machbarkeit des Build mit der aktuellen Windows Yagarto-Toolchain kann hiermit gezeigt werden. Bei mir läuft eine erste Version der BaseBetty mit folgenden EInschränkungen: 1. Alle Anpassungen sind im Hau-Ruck-Verfahren gemacht worden, mit dem Ziel mit möglichst geringem Aufwand die Machbarkeit zu zeigen. "Schön machen" erfolgt frühestens im übernächsten Schritt. 2. Kein Thumb-mode, da Pragmas ignoriert werden und eine weitergehende Anpassung noch nicht gemacht wurde. 3. SWI ist augeblendet, hier wird wohl ein Wrapper benötigt, da das komfortable Handling von Keil in gcc nicht abbildbar ist. 4. Assemblieren und Linken nach Gefühl angepasst, ohne im Detail zu verstehen, was hier passiert. Vielleicht kann einer der Experten hier Verbesserungen vornehmen oder Ratschläge dazu geben. 5. Das Display zeigt ein Menü und reagiert auf Tasteneingabe. Serielles I/O habe ich nicht getestet, da ich noch keinen Seriellen Adapter habe. 6. All die anderen Dinge, die ich momentan übersehen habe ... Was die C-Programme machen, habe ich auch noch nicht verstanden. Da ist wohl noch etwas Einarbeiten notwendig. W.S. vielleicht kannst Du die von mir im C-Code eingebrachten Änderungen in Deinen Originalstand übrnehmen? Auch sollte eine Versionierung der Quelldateien mit Änderungsnotizen als nächste Anpassung ergänzt werden. Anbei die LernBetty V0.01 für gnu angepasst. Es geht also ... somit existiert kein Grund mehr, hier nicht mitzuspielen. Bitte mitmachen! Gruß Siegfried
Ach, ich glaub nicht, daß es Doppelarbeiten gibt - dazu ist Gnu ja doch zu sehr anders als ARM und ich halte mich ab sofort aus dem Gnu-Geschäft komplett raus. Das mit dem umgeschriebenen Startupcode sieht ja schon ganz gut aus. LTORG gebraucht man eigentlich nur, um gezielt die Literale, die sich bis dato angesammelt haben, abzustapeln (scheinbare Direktoperanden, die tatsächlich per (PC+offset) ins Register geladen werden). Wenn der Assembler sowas rechtzeitig von selbst tut, kann man sich LTORG sparen. Ich mach's bloß lieber selber und dediziert, um mich nicht auf eventuelle Automatismen verlassen zu müssen - und wer sich ins ARM-Geschäft einarbeitet, soll ruhig merken, wie sowas wie LDR R0, =PLL_BASE tatsächlich funktioniert. AREA Reset, CODE, READONLY Die Wandlung von AREA --> section überschaue ich momentan noch nicht. Im Prinzip muß man dem Assembler klarmachen, daß der Kram absolut und in den ROM gebunden werden muß und auszuführender Code ist. Das sind alles Dinge, die der Assembler über entsprechende Einträge im Objektfile dem Linker verklickern soll. Aber vielleicht ist auch dies bei Gnu ganz anders.. Ich würde rein gefühlsmäßig etwa so schreiben: section code, absolute, readonly; (falls es das gibt) Ich denk mal, wenn der Startup richtig übersetzt werden kann, ist die halbe Durststrecke bereits erledigt. Was die fehlende Unterstützung von SWI bzw. SVC betrifft, da fällt mir nur ein, einen Assembler-Unit zu schreiben, wo all die Funktionen drinstehen, die ich im .h File definiert habe. Das macht die Sache ein bissel länger und langsamer, aber was kann man tun, wenn der Compiler sowas wichtiges einfach nicht unterstützt? Ich frag mich bloß, wie die Leute, die ein kleines RTOS geschrieben haben und Gnu benutzen, das trotzdem hinbekommen. Bei dem fehlenden #pragma arm und #pragma thumb wirst du wohl mal eine Versuchs-Übersetzung machen müssen und die dann reassemblieren. Dann sieht man, ob der Gnucompiler vielleicht von sich aus bei Interruptroutinen auf arm umschaltet (und danach wieder zurück). Wenn er sowas nicht kann, dann ist entweder Assembler oder eine separate C-Quelle fällig. Ärgerlich - und unübersichtlich. Müßte man in den jeweiligen Quellen als Kommentar erläutern, zwecks Verständlichkeit. W.S.
>Es geht also ... somit existiert kein Grund mehr, hier nicht >mitzuspielen. Bitte mitmachen! Wozu? Langweiliges Teil. Alte Technik. Die Welt spielt jetzt mit Cortex M3 und M4. Auf meinem STM32F4 Discovery komme ich ohne löten an die meisten Pins ran. SD Karte an SDIO, an SPI ein 320x240 Display und schon spielt das Ding ein Video (vorerst noch ohne Ton und mit Tricks, aber es geht). Debugger ist auch drauf. Was wollt ihr mit dieser Betty Gurke? Für Einsteiger nicht zu gebrauchen und auch nicht zu empfehlen.
Nachtrag: Die bmplib.c schmeiß bitte ersatzlos raus. Bin gerade dabei, mir für Bilder was anderes auszudenken. W.S.
Noch'n Nachtrag:
Vorschlag:
#if defined (GCC)
#define _irq __attribute_ ((interrupt("IRQ")))
#endif
in StdTypes.h reinsetzen?
W.S.
.. langsam wird's peinlich: noch'n Nachtrag, bevor ich Feierabend mache: bitte guck in deine Linkerscripte. Ich hab gerade in LernBetty\BaseBetty.map gesehen, daß du den Ram auf 0x40000000 gesetzt hast. Damit sind die ersten 48 K nicht frei für Apps. Setze ihn lieber auf 0x4000C000 Siehe mein Linkscript: --cpu=arm7tdmi --output linked.axf --ro-base 0x80000000 --rw-base 0x4000C000 ..usw. Ansonsten sieht es ja danach aus, daß du die Lernbetty auch unter Gnu schon fast im Kasten hast. Das SWI-Testkommando in cmd.c sollten wir auch rausschmeißen, da es bei Gnu nur Späne macht. Zum LCD: Am Anfang gibt es ne Darstellung von allen Fonts, darunter eine Demo von FillREct und Linien ziehen. nach 1.5 sek wird das überlagert von der Betty-Anfangsmeldung und nach weiteren 1.5 sek kommt das (simple) Menü, wo man Tastentest, Licht aus und an, ADC's und den Appfinder wählen kann. Letzterer findet natürlich nur was, wenn auch irgendwo ne App einprogrammiert ist. Ansonsten hat man oben dden Batteriefüllstand und ne Uhr. Mehr ist momentan noch nicht geschrieben. So. Feierabendbierchen! W.S.
holger schrieb: > > Was wollt ihr mit dieser Betty Gurke? > Für Einsteiger nicht zu gebrauchen und auch nicht zu empfehlen. Hallo Holger, Du warst offensichtlich nicht angesprochen, sondern diejenigen, die sich diese "Gurke" gekauft haben. Warum kauft jemand so "Gurken"? - Weil es Spaß macht, Gurken zu züchten. - Weil 16 Stück günstig eingekauft nur 42 EUR kosten. - Pollin EInzelstücke für 4 EUR abgibt. - Weil es Mitmenschen gibt, für die 10 EUR schon viel Geld ist - Weil ich für ein Schulprojekt problemlos 10 Stück sponsern kann. - Weil das Gelernte dennoch auf andere Plattformen übertragen werden kann. - Weil Kreuzworträtzel auch ohne Farbe Spaß machen. ... Gruß Siegfried
Hallo W.S.,
#define GCC
kann man sicher statt im setup.h woanders ablegen, aber die
Funktionseinleitung
void _attribute_ ((interrupt("IRQ")))
würde ich als #ifdef #else #endif Variante vor der eintlichen Funktion
stehen lassen. Eventuel hast Du was übersehen? In Serial.h kann man
eigentlich gut sehen wie es von mir umgeetz wurde.
Es ist doch OK und gängige Praxis, die verschiedenen Compiler-Varianten
im Quellcode transparent aufzuzeigen.
Das mit der RAM Nutzung ab 0x4000C000 gucke ich mir an. Das ist eine der
Stellen, wo ich bisher noch nicht durchgeblickt habe.
Ansonsten macht das Progrmm bei mir das was Du in Deinem obigen Posting
beschreibst.
Gruß
Siegfried
Hei, dann läuft's ja schon bei dir. Prima. Kann z.Z. auf Arbeit nur mal eben reinschauen, alles weitere wenn ich Feierabend hab und mir die Frau nix anderes aufhilft... W.S.
@W.S. & Siegfried W. Bitte weiter so! Ich freue mich das dieser Thread nicht wie so viele andere in eine heute übliche Schlammschlacht abgedriftet ist, sondern das man sich wieder auf Inhalte und das weiterführen zu Besserem konzentrieren konnte. Ich selbst habe sogar noch eine Betty ovp hier liegen und habe nun Lust da mal einen USB TTL Wandler dran zu hängen und ein wenig zu probieren etc. Super! Und DANKE! Ggf. könnte es interessant sein aich mal die fertig compilierte Firmware/Flashdatei hier einzuhängen. Ich z.B möchte ersteinmal sehen, das das alles klappt bevor ich die Toolchain (GCC) aufsetze. Peter
Etwas OT: Hat hier noch Jemand den IP-Adapter und würde den Loswerden wollen? Florian
Zwischenstand (in aller Eile): hab ins gdi Grafik eingebaut, nen netten Startbildschirm gemacht und (wichtig) ne namentliche Trennung der tool-relevanten Dateien eingeführt, also z.b. ccc.bat --> cccarm.bat und cccgcc.bat usw. Obendrein hab ich die Interrupt-Services in ne separate Quelle verschoben, weil bei Gnu unmöglich, arm und thumb gemeinsam in einer Quelle zu haben. Nächstes Thema bei mir: Wrapper für SWI bzw. SVC für Gcc schreiben, Beschreibung auf neuesten Stand bringen. btw: Tool-Aufruf per cccgcc.bat geht prinzipiell, auch Steuerdateien für Compiler und Linker mit arm-eabi-etcetc.exe @steuerdatei quelle.c geht prinzipiell. Meine Bitte: kann jemand dies mal verifizieren? Quellen-Update kommt alsbaldigst. Bitte Geduld. W.S.
Peter Sieg schrieb: > Ggf. könnte es interessant sein aich mal die fertig compilierte > Firmware/Flashdatei hier einzuhängen. guck bei der Codesammlung, dort findest du die aller-aller-allererste Version, wo jeweils eine fertige Hex- und Bin-Datei enthalten ist. Die Hex für Leute mit jtag und die bin für Betty-Heaven. Eine App (so gut wie leer) für den Rom2 ist auch dabei, W.S.
Zitat: "guck bei der Codesammlung, dort findest du die aller-aller-allererste Version" Ja, zum testen kann ich wohl auch die allererste boop nehmen.. Um aber hier im Thema zu bleiben würde ich ein Kompilat der hier zusammen gestellten Umgebung bevorzugen. Peter
Hallo Peter, zunächst vielen Dank für Deine motivierenden Worte. Bei mir läuft zunächst nur die BettyBase ohne Applikation mit der gnu-Toolchain, weil ich noch keinen SWI-Wrapper hinbekommen habe. Ich kann heute abend gerne eine gcc Version der BettyBase mit Hex-File zur Verfügung stellen. Für den Build habe ich weiter oben aber alle Dateien zur Verfügung gestellt. Mit der aktuellen Yagarto-Umgebung (arm Toolchain und Eclipse)ist die übersetzbar. Um lediglich einen Überblick über die aktuelle Funktionalität der Software zu erhalten, reicht tatsächlich die von W.S. gepostete erste Version aus. Gruß Siegfried
Hallo W.S., schön, dass Du Dich auch in das gcc Umfeld einbringst. Speziell in Sachen SWI habe ich mich bisher auch bemüht, bisher alledings ohne wirklichen Erfolg. Es wäre interessant zu sehen, welchen Ansatz Du hier gewählt hast (nochmal das Stichwort Doppelarbeit). Wird von der Software auch die ursprüngliche Betty-Hardware unterstütz, oder nur die Swiss-Betty? Da ich selbst lediglich letztere habe, habe ich das bisher nicht verfolgt. Für andere Interessenten (eventuell auch für Peter) ist dies vielleicht von Bedeutung. Gruß Siegfried
So. Hardware steht ersteinmal. Konnte heute Boop erfolgreich flashen. Ich weiß allerdings nicht, ob ich eine 'Swiss-Betty' habe?? Woran erkennt man das..? Lag schon 1-2J hier bei mir rum. Peter
Hallo zusammen, in der Boop Software gibt es in der Datei keyboard\keyboard.h ein #define SWISSCOM Wenn das bei Dir, Peter, nicht aktiviert ist, wovon ich ausgehe, dann hast Du keine Swiss-Betty und es sind nach meiner Einschätzung an der Software von W.S. Anpassungen notwendig. Mindestens die Tastatur ist anders angebunden. Habe mich aber bisher nicht um die Abweichungen gekümmert. Anbei mein aktueller Stand für die gnu Umgebung erzeugt mit Yagarto und Eclipse in aktueller Version. Allerdings nur die Base ohne Apps. Das ganze muss komplett im arm-mode compiliert werden, sonst funktioniert nicht alles. Habe zwar die ISRs in eigene Dateien getrennt, das reicht aber nicht. Da W.S. auch eine Überarbeitung in Arbeit hat, ist meine Version lediglich eine temporäre Testversion. Zusammen mit dem App-bin aus dem original Posting von W.S. funktioniert dies auf einer Swiss-Betty (!). Für den build habe ich Makefile und Makefile.conf aus der Boop-Umgebung angepasst. Bin und Hex Datein sind enthalten. Ich werde mich erst am Wochenende wieder mit der Betty beschäftigen können, weil ich die nächsten Tage untrwegs bin. Gruß Siegfried
Hi. Yagarto Toolchain inst. und BettyBase.bin nach make erhalten. Geflasht = Display bleibt dunkel = keine swissbetty = läuft nicht :-( Boop wieder geflasht = alles ok. Ich habe mir mal eine weitere Betty über Pollin bestellt. Da das ja swissbetty's sein sollen.. hätte ich dann beide zum testen. Peter
So Leute, anbei der aktuelle Stand. Ich hatte es ja heut früh in aller Eile schon angekündigt. Bilder darstellen ist drin und hat zu nem neuen Begrüßungsschirm geführt ;-) hoffentlich gefällt's. Ansonsten hab ich mal ne Batchdatei für ne ältere Yagarto geschrieben und kurz angetestet. Assemblieren+Compilieren (arm als auch thumb) geht ohne Gemecker, der Linker scheint auch alles zu verstehen, aber er findet seine Libs nicht.. ich denke mal, da werde ich Siegfried das Feld komplett überlassen. So ganz bleiben lassen hab ich es bis jetzt nicht, um soweit es geht, Grundstrukturen rein zu kriegen. Siegfried arbeitet ja mit IDE und nicht per Batchdatei. Ach, guckt euch das Package von innen an, da sieht man's. Zur NichtSwissBetty: Da müßte in config.c und tasten.c geändert werden und gut ist. Wenn hier einer die beiden Quellen geändert postet, dann mach ich ein Kompilat zwecks Ausprobieren. Ich hab bloß ne Swissbetty und keine ältere. Ansonsten denk ich mir, daß wir inhaltlich mit der BettyBase soweit rund sind. Es muß bloß noch alles per Gnu so laufen, wie gewollt und dann sollten wir diskutieren, ob und was noch an den Menüs getan werden sollte/könnte. Anschließend heben wir die Rev 0.10 aus der Taufe und packen die in den Codebereich. Ich guck in der Zwischenzeit, was mir zum Grafik-Konvertieren so einfällt. W.S.
@Siegfried: Schmeiß die olle bmplib.c raus, die ist obsolet. Peter Sieg schrieb: > Geflasht = Display bleibt dunkel kannst du wenigstens über den seriellen Port (9600Bd 8N1) was sehen? Was sagt deine Betty denn, wenn du das .bin file aus meinem vorigen Post mal mit Betty-Heaven reinbrennst? Zumindest das Display sollte sich rühren. Ich hab in setup.c so ziemlich alles an Belegung zusammengetragen, was ich finden konnte - manches dürfte nicht mehr stimmen, da von Bettyhacks für die alte Betty. Ich hatte auch angefangen, die Schaltung soweit bekannt in Eagle reinzuhacken aber dann bei den diversen Änderungen zur Swissbetty damit aufgehört. Will wer dort weitermachen? Ansonsten würde ich dir die Swissbetty empfehlen, denn wie es scheint, sind dort einige interessante Sachen (ADC's) besser zugänglich als bei der alten. W.S.
Hallo Peter, wenn Du magst, kannst Du Deine Bin-Datei mal hier einstellen, dann würde ich probieren, ob diese auf meiner Swiss-Betty funktioniert. Gruß Siegfried
ok. Hängt hier an. Könnte mir jemand diese Datei aus der orig. Boop Firmware hier zur Verfügung stellen: version: echo -n '#define SVNVERSION ' > version.h sed -n '4p' .svn/entries >> version.h version.h: echo -n '#define SVNVERSION ' > version.h sed -n '4p' .svn/entries >> version.h Es geht um die .svn/entries Datei. Ich habe nur einen GNU tarball heruntergeladen und da ist sie wohl nicht dabei.. aber ohne läuft make nicht durch.. Peter
Hallo Peter, Deine Bin-Datei läuft bei mir inkl der von W.S. zur Verfügung gestellten Application bin. An Deiner Toolchain liegt es also nicht. In der Datei version.h steht lediglich die Versionsnummer. Ich habe in der Makedatei die sed Mimik entfernt und in die version.h einfach eine Konstante eingefügt: #define SVNVERSION 999 Dnn läuft der Build durch. Gruß Siegfried
@Siegfried: Bei mir noch Fehler: thumbunopt.o infrared/ir_rca.thumbunopt.o infrared/ir_rcmm.thumbunopt.o infrared /ir_rec80.thumbunopt.o infrared/ir_recs80.thumbunopt.o infrared/ir_rf.thumbunopt .o infrared/ir_sirc.thumbunopt.o infrared/ir_spaceenc.thumbunopt.o infrared/ir_l irc.thumbunopt.o -lc -lgcc c:/WinARM/bin/arm-elf-ld: ERROR: c:/WinARM/arm-elf/lib/interwork\libc.a(siprintf .o) uses hardware FP, whereas boop_rom.elf uses software FP c:/WinARM/bin/arm-elf-ld: failed to merge target specific data of file c:/WinARM /arm-elf/lib/interwork\libc.a(siprintf.o) c:/WinARM/bin/arm-elf-ld: ERROR: c:/WinARM/arm-elf/lib/interwork\libc.a(vfiprint f.o) uses hardware FP, whereas boop_rom.elf uses software FP ?? Peter
Hallo Peter, ich kann Dir leider auch nur die Fehlermeldung "übersetzen". Die Libs die Du verwendest nutzen wohl die Hardware Floating Point Libs. Die hat die CPU aber nicht. Daher ist die Betty mit einer Software Floating Point Lib compiliert. Ich habe folgende Toolchain http://sourceforge.net/projects/yagarto/files/YAGARTO%20for%20Windows/20121013/ Meine Make-Umgebung sowie libnosys_gnu.c (siehe mein Posting weiter oben) für die Boop habe ich angehängt. Vielleicht hilft es Dir. Ich bin dann mal weg ... Gruß Siegfried
Hallo W.S., super Arbeit! Danke! Soeben habe ich auch die Applikation zum Laufen gebracht. Einige kleine Anpassungen waren noch nötig. Als nächstes geht es an das Verstehen und Testen der Programme und APIs. Aber erst am Wochenende. Jetzt bin ich wirklich weg. Gruß Siegfried
Ahh.. ich hatte die orig. Entwicklungsumgebung auch noch heruntergeladen und verwendet.. du hast yakarto auch für die orig. boop Firmware verwendet.. nachdem ich auf Windows angepasst hatte, lief make durch ich habe ein boop_rom.bin = super! Danke! Das dann noch mal zu flashen komme ich heute auch nicht mehr zu.. Habe nur gesehen, das es 250k groß ist und die orig. boop_rom.bin 262k? --- Zitat: "Deine Bin-Datei läuft bei mir inkl der von W.S. zur Verfügung gestellten Application bin." ok. Aber das mir der App. bin ist mir nicht klar..? Wo kommt die hin? Wird die mit eingelinkt beim build Prozeß? Peter
Peter Sieg schrieb: > ok. Aber das mir der App. bin ist mir nicht klar..? > Wo kommt die hin? Wird die mit eingelinkt beim build Prozeß? Nein. Wird völlig separat erstellt und kommt als selbständiges Stück Soft in einen der beiden Flashroms. Lies doch bitte die beigefügte PDF Doku (hab mir extra Mühe gegeben damit..). Ich habe die BettyBase so konzipiert, daß man sich völlig losgelöst von BettyBase seine Apps schreiben kann. Diese verkehren mit der BettyBase über Supervisor-Calls (auch SWI oder SVC oder SoftInts genannt) Das hat den Vorteil, daß es ein geregeltes API gibt und etwaige Änderungen in BettyBase kein Neucompilieren von Apps nach sich zieht. Die Vorlage für Apps ist im Zipfile mit dabei. Apps kannst du vorzugsweise in den zweiten Flashrom brennen, immer auf glatten 32 K Grenzen. Der Appfinder in BettyBase findet die dann und man kann sie mit dem Appfinder starten. Ich hab aber noch ein Anliegen: Schau dir mal die Batchdatei cccgcc.bat und die zugehörigen Compier- und Linker-Steuerdateien an. Ich hab die quasi im Blindflug geschrieben und es wäre schön, wenn jemand von euch diese Batchdatei zum Laufen bringen würde. Dann könnte man auch ohne eine spezielle IDE das Ganze per Gcc übersetzen. Die diversen bei Siegfried im Directory herumschwirrenden Eclipse-Projektdateien sind nämlich für mich ein bissel verwirrend. Soweit ich mit cccgcc.bat gekommen bin, laufen Assembler und Compiler ohne Error und ohne Warnings durch, Compiler für die Interruptsquelle nur per Kommandozeile (wegen arm), die anderen per @steuerfile (alle thumb). Lediglich der Linker macht noch Späne, aber das liegt wahrscheinlich an fehlenden Pfadangaben zur richtigen Library. Ich hab schon mal ein Linkerlog gesehen und dort drin festgestellt, daß der Linker zumindest alle Betty-Objektdateien auf die richtigen Adressen verfrachtet hatte. W.S.
@W.S. Lese mir die PDF durch - Hast du ein Beispiel app zum testen hier im Thread 'versteckt'? (Ich habe da zumindest nichts gesehen..) Man braucht zum Übersetzen keine Batchdatei. Einfach 'make' reicht mit der mitgelieferten makefile:
1 | ############################################################### |
2 | ##### |
3 | ##### Makefile for boop - OpenSource firmware for Betty |
4 | ##### adapted for "Lernbetty" |
5 | ##### |
6 | ##### original (C) |
7 | ##### Makefile V0.1 by alterego - alteregon@gmx.net |
8 | ##### Makefile v0.2 by Tobias - tobias-betty@23.gs |
9 | ##### Created at 15.11.2012 |
10 | ##### |
11 | ##### Adapted Makefile version for "Lernbetty" |
12 | ##### V0.3 by swausd 18.11.2012 |
13 | ##### |
14 | ############################################################### |
15 | |
16 | ############################################################### |
17 | ##### |
18 | ##### PATHS (default installation) |
19 | ##### |
20 | ##### You can put your path-config into Makefile.local |
21 | ##### to override these defaults |
22 | ##### |
23 | ############################################################### |
24 | |
25 | ARMBASE = C:/yagarto |
26 | INCLUDEPATH = $(ARMBASE)/include |
27 | LIBPATH = $(ARMBASE)/lib/gcc/arm-none-eabi/4.7.2 -L$(ARMBASE)/arm-none-eabi/lib |
28 | ARMPATH = $(ARMBASE)/bin |
29 | TOOLPREFIX = arm-none-eabi- |
30 | |
31 | CFLAGS = -Wall -mthumb-interwork -msoft-float -ggdb |
32 | |
33 | #OPENOCD = openocd -f betty.cfg -f interface/parport.cfg |
34 | |
35 | ############################################################### |
36 | ##### |
37 | ##### Compiler, Linker and Tools |
38 | ##### |
39 | ############################################################### |
40 | |
41 | CC = $(ARMPATH)/$(TOOLPREFIX)gcc |
42 | AS = $(ARMPATH)/$(TOOLPREFIX)as |
43 | LD = $(ARMPATH)/$(TOOLPREFIX)ld |
44 | OC = $(ARMPATH)/$(TOOLPREFIX)objcopy |
45 | OD = $(ARMPATH)/$(TOOLPREFIX)objdump |
46 | |
47 | CPUFLAGS = -mcpu=arm7tdmi-s |
48 | OPTFLAGS = -O0 |
49 | CFLAGS = -Wall -mthumb-interwork -msoft-float |
50 | INC = -I$(INCLUDEPATH) -I. |
51 | #INC = -I$(INCLUDEPATH) -I. -Iinterrupt -Idisplay -Ikeyboard -Iaudio -Iinfrared -Iserial -Iflash -Icc1100 -Igui -Itimer -Igames -Iadc -Irtc -Itools |
52 | ASFLAGS = -D --gstabs -mthumb-interwork -mfpu=softfpa |
53 | LDFLAGS = -Tlpc2220.ld -Map BaseBetty.map |
54 | LIBS = -lc -lgcc -lm |
55 | THUMBFLAGS = -mthumb |
56 | |
57 | COMPILE = $(CC) $(CPUFLAGS) $(CFLAGS) $(INC) |
58 | |
59 | ############################################################### |
60 | ##### |
61 | ##### Do it |
62 | ##### |
63 | ############################################################### |
64 | |
65 | # Recursive expansion of Makefile rules. |
66 | define expand_dir |
67 | # Reset vars for subdir for the case that Make.conf does not exist |
68 | SUBDIRS := |
69 | SRCS := |
70 | THUMBSRCS := |
71 | THUMBSRCSUNOPT := |
72 | -include $(1)Make.conf |
73 | ALLSRCS += $$(SRCS:%=$(1)%) |
74 | ALLTHUMBSRCS += $$(THUMBSRCS:%=$(1)%) |
75 | ALLTHUMBSRCSUNOPT += $$(THUMBSRCSUNOPT:%=$(1)%) |
76 | DEPS += $(1).deps |
77 | $$(foreach adir,$$(SUBDIRS),$$(eval $$(call expand_dir,$(1)$$(adir)/))) |
78 | endef |
79 | |
80 | ALLSRCS := |
81 | ALLTHUMBSRCS := |
82 | ALLTHUMBSRCSUNOPT := |
83 | |
84 | $(eval $(call expand_dir,)) |
85 | |
86 | OBJS := $(patsubst %.asm,%.o,$(ALLSRCS:.c=.o)) $(ALLTHUMBSRCS:.c=.thumb.o) $(ALLTHUMBSRCSUNOPT:.c=.thumbunopt.o) |
87 | |
88 | all: version $(DEPS) BaseBetty.bin BaseBetty.hex |
89 | |
90 | debug: version.h $(DEPS) BaseBetty.bin BaseBetty.hex |
91 | |
92 | release: clean version $(DEPS) BaseBetty.bin BaseBetty.hex |
93 | # @echo -n '\n\nRelease erstellt SVN Version ++' |
94 | # @cat .svn/entries | sed -n '4p' |
95 | |
96 | version: |
97 | # echo -n '#define SVNVERSION ' > version.h |
98 | # sed -n '4p' .svn/entries >> version.h |
99 | |
100 | version.h: |
101 | echo -n '#define SVNVERSION ' > version.h |
102 | sed -n '4p' .svn/entries >> version.h |
103 | |
104 | test: BaseBetty.elf |
105 | $(OD) -h $< |
106 | |
107 | %.bin: %.elf |
108 | $(OC) -O binary $< $@ |
109 | |
110 | %.hex: %.elf |
111 | $(OC) -O ihex $< $@ |
112 | |
113 | BaseBetty.elf: $(OBJS) |
114 | $(LD) $(LDFLAGS) -L$(LIBPATH) -o $@ $^ $(LIBS) |
115 | |
116 | %.o: %.asm |
117 | $(AS) $(CPUFLAGS) $(ASFLAGS) -o $@ $< |
118 | |
119 | %.o: %.c |
120 | $(COMPILE) $(OPTFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $< |
121 | |
122 | %.thumb.o: %.c |
123 | $(COMPILE) $(THUMBFLAGS) $(OPTFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $< |
124 | |
125 | %.thumbunopt.o: %.c |
126 | $(COMPILE) $(THUMBFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $< |
127 | |
128 | $(DEPS): |
129 | mkdir -p $@ |
130 | |
131 | uresident: resident |
132 | resident: BaseBetty.bin |
133 | $(LPCTOOL) -i -v -e -a $< |
134 | |
135 | program: BaseBetty.bin |
136 | $(OPENOCD) -c init -c 'flash_boop $<' -c shutdown |
137 | |
138 | clean: |
139 | -rm -Rf $(DEPS) |
140 | -rm -f $(OBJS) *.elf *.bin *.hex *~ |
141 | |
142 | -include $(DEPS:=/*) |
Das Übersetzen der orig. Boop Firmware geht so auch mit der Yagarto Tollchain. Ich nutze bisher noch gar keine IDE wie eclipse (sind mir immer viel zu riesig ;-) Peter
Peter Sieg schrieb: > Man braucht zum Übersetzen keine Batchdatei. Einfach 'make' reicht mit > der mitgelieferten makefile: Ja, ist mir ein bissel unübersichtlich. Inhaltlich: die Quelle interrupts.c muß im arm mode compiliert werden und alle anderen im thumb mode. Hab ich das in deinem makefile übersehen? (Ähem, kannst du's trotzdem mal probieren? zumindest aus Neugier..) Peter Sieg schrieb: > Hast du ein Beispiel app zum testen hier > im Thread 'versteckt'? (Ich habe da zumindest nichts gesehen..) aber ja freilich. guck in die zuletzt gepostete Zipdatei von mir, dort findest du mehrere Verzeichnisse, eins davon enthält die BettyBase und das andere heißt Betty_App und enthält eine App-Vorlage, also ne winzige App, 216 Byte "groß", die nix macht außer Hallo und BettyApp auf den Screen zu schreiben. .bin und .hex sind dabei. Im einfachsten Fall die .bin mit Betty-Heaven auf ROM2 schreiben. W.S.
@W.S. ah.. ok. Mein selbst übersetzte boop_rom.bin läuft übrigens auf der Betty. BettyBase kann ich noch nicht nutzen, weil ich anscheinend keine swissbetty habe. Die von Pollin ist noch unterwegs. Peter
Hallo zusammen, die make Umgebung, die ich verwendet habe, ist eine mit geringen Änderungen versehene Umgebung aus dem BettyBoop. Da hatte sich jemand einige Mühe gemacht, um eine flexible Konfiguration zu bauen. Die zu übersetzenden Dateien stehen in der Datei Make.conf. Dort wird auch angegeben, welche Dateien im Thumb oder Arm Mode zu Übersetzen sind. Auch Unterverzeichnisse können mit einbezogen werden. Kann man gut in der Entwicklungsumgebung der original Betty sehen und verstehen. Angepasst sollte diese Make Umgebung auch für den Keil Build funktionieren. Das Linken erfolgt über das Linker Script ld2220.ld Gruß Siegfried
Siegfried W. schrieb: > Das Linken erfolgt über das Linker Script ld2220.ld Ist was Generisches für den Prozessor. Ich denke mal, das wirst du ersetzen müssen gegen ein Linkersteuerfile, wo die Linkadressen für RAM und ROM an die Betty angepaßt sind: BettyBase: RAM ab 4000C000, ROM ab 80000000 BettyApps: RAM ab 40000000, ROM unterschiedlich ab 82000000 in 32 K Schritten (Je nach Größe der App) W.S.
Hallo zusammen, ich habe mich am Wochenende mal mit einer Applikation zur "LernBetty" beschäftigt. Dazu habe ich das Spiel Sokoban aus "BettyBoop" übernommen und angepasst. Das Ergebnis ist im Dateianhang zu finden. Folgendes war zu tun: 1. Die Datentypen und einige Definitionen mussten angepasst werden (z.B. BYTE zu byte). Das habe ich in der Datei Sokoban.h ergänzt. 2. Dann mussten die Systemaufrufe in Sokoban.c angepasst werden. Ich habe die ursprünglichen Aufrufe im Source gelassen und durch #if defined (LERN_BETTY) ausgeblendet. So kann man sehen, wie ich es gemacht habe. 3. Da die verfügbaren Fonts in beiden Umgebungen unterschiedlich sind, habe ich die Proportonalschrift des Originals durch den kleinste "LernBetty" Fixedfont ersetzt und einige Positionierungen angepasst sowie Abkürzungen eingebracht. Das Ergebnis ist nicht ganz so gefällig wie das Original, aber brauchbar. Das Spiel funktioniert, ist aber merkbar langsamer im Bildaufbau. Bei der Umsetzung ist mir aufgefallen, dass bei den Systemfunktionen der "LernBetty" eine gute Mischung zwischen englischen und deutschen Bezeichnungen gegeben ist. Eventuell muss man hier durch ein Refactoring in einem nächsten Schritt eine Einheitlichkeit herstellen - insbesondere unter dem Lehr-Ansatz. Was mir auch noch aufgefallen ist, wofür ich aber zurzeit keine Erklärung habe: Wenn die Applikation verlassen wird, sollte die angezeigte Messagebox mit dem Return-Code nach einger Zeit verschwinden. Das funktioniert aber nicht immer. Durch die Exit Taste kann man zum Hauptmenü der LernBetty zurück. So, wie kann das ganze nun kompiliert werden? Da gab es weiter oben immer wieder Vermutungen. Es ist aber ganz einfach. Es wird lediglich eine funktionierende gcc Toolchain inclusive der make-utility benötigt. Unter Windows z.B. die Yagarto gcc arm Toolchain sowie die Yagarto Tools (yagarto.de). Beides installieren und die Verzeichnisse in den Windows Pfad aufnehmen. Befinden sich die Programme in den Verzeichnissen C:\yagarto und C:\yagarto-tools-20121018 ist in einer DOS-Shell im Arbeitsverzeichnis C:\workspace\LernBettyApp01 nur make einzugeben und der Build wird gestartet. Wie oben bereits ausgeführt, erfolgt eine eventuell notwendige Konfigurationsänderung in den Dateien Makefile - für Pfadnamen und z.B. Lib- oder Optimierungseinstellungen Make.conf - für die im Projekt enthaltenen Dateien lpc2220.ld - für das Linken z.B. für die Startadresse. Die von W.S. zur Verfügung gestelltten Batch-Dateien zum Kompilieren der App sind im Dateianhang zwar enthalten, diese habe ich aber nicht angepasst. Sie werden also nicht funktionieren. Bitte Make verweden! Im Dateianhang sind auch die Bin und Hex Dateien enthalten, so dass ohne Kompilieren ausprobiert werden kann. Vielleicht nutzt es jemandem. Gruß Siegfried
Hallo Siegfried, das sieht ja schon nett aus, wa du da zu berichten hast. Ich hab mich ein bissel um die Grafik gekümmert und dabei herausgekommen ist ein kleiner Konverter nebst einigen Demografiken und eine App, die so ein Bild zeigt. Ich hab auch noch etwas an der BettyBase gefeilt und jetzt läßt sie sich auch per Batchfile und GNU kompilieren. Damit sollte dieser Teil so langsam in der Zielgeraden sein. Das mit der stehenbleibenden Messagebox ist mir auch schon aufgefallen - und zwar gleich bei beiden Versionen (arm+gcc). Einen Punkt habe ich noch, der mich fast zum Platzen gebracht hat: Apps mit Gcc kompiliert stürzen ab. Soweit ich das per Ida heute hab feststellen können, sieht das etwa so aus: main(thumb) ruft per BL einen Wrapper(thumb) auf, wrapper geht per BX PC in den arm modus und ruft dann per B den SWI-Wrapper(thumb) auf. !!! per B !!! Eigentlich ein kompletter Irrsinn, denn die Wrapper in BettyApiGcc.asm liegen ja im thumb modus vor! Was da der vom Linker eingebaute Wrapper soll, der zuerst in den arm modus wechselt und dann ohne BX mit einfachem B eine thumb funktion aufruft, ist mir schleierhaft. Kannst du bitte mal die Minimal-App in BettyApp übersetzen und die .hex posten? Ich würde sie mir gern mal von innen anschauen. Die Ida auf Sokoban anzusetzen ist mir ein bissel zu dick. Bei dir funktionieren ja die SWI-Wrapper ganz offensichtlich. Ich werd mir morgen mal den Sokoban auf die Betty packen und gucken, wie er sich macht. Ansonsten werde ich mich mal darum kümmern, wie man am PC verschiedene Apps verwaltet und zu brennbaren .bin's zusammenfaßt. W.S.
Hallo W.S., anbei die Base und App in V0.02 von mir übersetzt. Laufen bei mir OK. Ich habe aber deine Bat-Dateien auf die Schnelle nicht zum Laufen gebracht (Linker findet auch nach Pfadanpassung die Libs nicht) und habe daher meine Make-Scripts verwendet (auch enthalten). Optimierung ist -O3 Gruß Siegfried
@W.S. & Siegfried: Jetzt ist das Chaos aber perfekt.. der eine hängt ein *gcc.* dazwischen - der andere nicht, der eine nennt es Bettybase* der andere Basebetty* Ich habe das gerade festgestellt, weil ich versucht habe beide ZIP's zusammen zu fahren.. ich gebe das nun auf und warte auf ein konsolidertes ZIP.. sonst blickt da keiner mehr durch. Frage: ist es wirklich notwendig alle Sourcefiles *arm.* und *gcc.* doppelt zu führen?? Das Sollte doch eher im Source mit #IFDEFINE... erfolgen, falls überhaupt nötig.. Bitte schaut mal, ob ihr euch hier einigen könnt und das Ganze zusammenführen könnt in ein ZIP, wo sowohl Keil als auch gcc mit aktueller base02, small/test App. und Sokoban drinnen sind und sich diese einfach über make im jeweiligen Verzeichnis übersetzen lassen.. Ich hoffe ich war nicht zu harsch in meiner 'Kritik'.. habe aber gerade doch einen Schrecken bekommen, bei dem erfolglosen Versuch beides zusammen zu führen.. Gruß Peter
Hallo W.S. kann es sein, daß deine " LernBettyPacked_R0.02.zip " fehlerhaft gepackt ist? Es wird beim Auspacken immer Diskette 2 verlangt.... Danke
Hallo Peter, wie war das mit dem Rosengarten bzw. dem Frühstück am Bett? Wurde von niemandem versprochen ;-) Ich kann Deine Anmerkungen verstehen. Also mitmachen und selber verbessern oder auch ordnend eingreifen. Bezüglich des Durcheinanders der Bezeichnungen BettyBase bzw. BaseBetty, bekenne ich mich schuldig und gelobe Besserung. Bezüglich Batch- oder Make-Dateien für die Übersetzung stelle ich fest, dass die Batch-Dateien bei mir nicht laufen. Habe es zuletzt gestern noch versucht, aber nicht hinbekommen. Werde ich gerne noch mal drüber sehen. Ich selbst werde diese aber nie verwenden - unabhängig davon, ob eine IDE zum Einsatz kommt. Eine Zusammenführung der bisherigen Ergebnisse ist sicher wünschenswert. Ich habe zwar Projekterfahrungen aber nur aus der klassischen Projektarbeit. In losen, ungesteuerten Interessen-Verbündgen wie wir sie hier haben, habe ich bisher keinerlei Erfahrung. Es wäre vielleicht hilfreich, wenn W.S. als Initiator die Zügel etwas fester halten würde. Mein Ansatz ist es nicht allen Zuschauern hier im Forum die Arbeit abzunehmen und das "Frühstück ans Bett" zu servieren. Dazu fehlt mir neben der Zeit auch die innere Einstellung ;-) Also weitermachen und aus den Fehlern lernen. Gruß Siegfried
Ein_Mitnutzer schrieb: > kann es sein, daß deine " LernBettyPacked_R0.02.zip " fehlerhaft gepackt > > ist? > > Es wird beim Auspacken immer Diskette 2 verlangt.... ich hatte keine Probleme mit der Datei ... Gruß Siegfried
Danke, Habe Download nochmal probiert. Jetzt ist alles i.O. Viele Grüße
@Siegfried: Zitat: "wie war das mit dem Rosengarten bzw. dem Frühstück am Bett? Wurde von niemandem versprochen ;-)" Haha ;-) Da hast du Recht.. den hatte ich mir verdient ;-) Ich habe allerdings etwas Erfahrungen mit so verteilten Projekten.. daher weiß ich, das es wenig Sinn macht, wenn ich als 'Dritter' hier versuche etwas wieder gerade zu biegen.. während ihr 2 Entwickler parallel weiter dran seit.. das einzig Richtige hier ist es es anzusprechen und ihr solltet euch evtl. kurz dazu abstimmen. Meine Vorschläge dazu: Keine *arm.* und *gcc.* Varianten, es sein denn es gibt triftige Gründe Die Kompilate kann man *arm.* und *gcc.* nennen, um sie auseinander zu halten, muss man aber nicht ;-) jeder wird selbst wissen womit er übersetzt hat.. Ich wäre dafür das jeder nur die Build scripte pflegt, die er auch selbst immer nutzt.. alles andere läuft sonst ggf. auseinander bzw. ist ungetestet. Das heißt: W.C verwendet und pflegt die Keil scripte/batch-Dateien und Siegfried die für gcc/yagarto, wobei ich das auch als ausreichend ansehen das ein make in dem jeweiligen Verzeichnis ausreichend ist ;-) Just my 2 cents! Ihr beide seit z.Z die Macher und könnt/solltet das entscheiden. Ansonsten, bitte weiter so! Ich denke. das könnte das Thema arm eval und Betty wirklich neu beleben! Grüße, Peter
Hallo W.S. und Siegfried W. habe heute das Erstemal eine "BettyBase" oder "BaseBetty" (:-) kompiliert. Mit der bat-Datei unter einer gcc-Umgebung wie von Siegfried hat der Linker drei fehlende Dateien (libgcc.a , libc.a und libm.a). Ich vermute es liegt an der älteren Version von W.S., daß es bei ihm geht. Die Make-Dateien von Siegfried liefen anstandslos durch. Solange es eine Möglichkeit gibt ALLE Applikationen und "Base"-Versionen zu kompilieren ist es relativ egal, wer die Umgebung dazu pflegt. Bei eigenen Applikationen ist man sowieso selbst in der Pflicht. Und nun: Weiter so.... ES IST EINE LERNUMGEBUNG, wie sie im Buche steht, und eine gute Erklärung... Applikationen, die schon jetzt zeigen, was möglich ist. Meine Hochachtung... Viele Grüße Bobby
Hallo zusammen, ich habe die Anregungen von Peter aufgegriffen und versucht die Build-Scripts für die GNU gcc Umgebung anzupassen. Jeweils für BettyBase, BettyApp (Vorlage) und BettyAppSokoban (Game-App). 1. Build mit Make make auf der Kommandozeile im Verzeichnis mit den Quelldateien eingegeben, startet den Build. Die Quell-Dateien sind in Make.conf anzugeben. Hinter dem Label SRCS die mit arm zu kompilierenden Dateien und hinter THUMBSRCS die mit thumb zu kompilierenden Dateien. 2. Build mit Batch-Datei die Batchdatei auf der Kommandozeile im Verzeichnis mit den Quelldateien starten. Bei neuen Quellen müssen die Kommandos in der Batch-Datei sowie der Linker xlc Datei angepasst werden. Die vorhandenen Einträge können als Muster verwendet werden. Die Dateien mit der Endung .ld definieren, an welche Speicheradressen die verschiedenen Segmente geladen werden sollen. Diese Dateien werden für beide Varianten benötigt. In der bisherigen Batch-Version ohne die ld-Dateien wurde zwar fehlerfrei durchkompiliert, die Programme wurden aber "seltsam" gelinkt und haben nicht funktioniert. Beide Versionen setzen die zurzeit aktuelle Yagarto Toolchain und die Yagarto-Tools sowie die Integration der Verzeichnisse zu den Tools im Pfad (siehe weiter oben) voraus. Wird eine andere gcc Toolchain verwendet, sind Anpassungen notwendig. Version 1 und 2 sind alternativ zu sehen. Ich persönlich bevorzuge die make-Variante, die sowohl mit als auch ohne eclipse als IDE funktioniert. @W.S. vielleicht magst Du die Scripts in Deinen Release integrieren. Ein zusätzlicher Test wäre aber sicher angezeigt. Wer meine Ausführungen nicht versteht, muss eventuell weiter oben im Thread aufsetzen oder sich etwas mit den Tools auseinandersetzen. Vielleicht findet sich auch jemand, der die bisherige Dokumentation zusammenfasst. Bitte in die von mir zusmmengetragenen Scripts nicht zuviel hineininterpretieren. Ich verstehe auch nicht alles im Detail. Habe teilweise durch Mustervergleich und Versuch eine lauffähige Umgebung zusammengestellt. Also viel Erfolg. Noch ein Nachsatz: Wie Bobby oben bereits geschrieben hat, ist das vorliegende System eine Lern-Umgebung. Ich habe durch die Beschäftigung damit schon einiges gelernt. Im Ergebnis bin ich meinem Ziel näher gekommen. Die Lernbetty ist für mich "nur" ein interessanter Zwischenschritt auf diesem Weg. Gruß Siegfried
@Siegfried: Vielen Dank! Dürfte ich dich noch bitten, mal den ganzes LernBetty Verzeichnis als ZIP hier einzustellen? Ich bin mir nicht sicher, das ich sonst alle Änderungen/Erweiterungen, sauber übernehme.. Meine swissbetty ist auch gestern angekommen, sodaß ich dann mal testen kann. Danke! Gruß Peter
Hallo Peter, kann gerne heute Abend einstellen. Das wäre aber ein Verhalten gegen Deine bsiherige Argumentation, denn eigentlich sollte W.S. zunächst eine Konsolidierung anstreben. Denn die Keil-Umgebung kann ich nicht anpassen bzw. testen mangels Ausstattung. Es ist halt doch nicht so einfach es allen recht zu machen ;-) Gruß Siegfried
Da hast du sicher Recht.. aber Keil gehe ich davon aus, das W.S das schon in der 02 Version am Laufen gehabt hat.. ;-) und wenn du nun gcc ergänzt hast + BettyApp (Sokoban), sollte das der aktuelleste Stand sein.. W.S hatte ja auch einen 2ten Thread eröffnet, um dort definierte 'Release'-Stände dann wohl von Zeit zu Zeit zu posten.. Mikrocontroller Forum hat meine ich auch einen SVN Server.. Grüße, Peter
Peter Sieg schrieb: > Frage: ist es wirklich notwendig alle Sourcefiles *arm.* und *gcc.* > doppelt zu führen?? Das Sollte doch eher im Source mit #IFDEFINE... > erfolgen, falls überhaupt nötig.. Das ist bei Lichte besehen, gar kein Problem, man sollte aber einige Details verstehen: - Die C-Quellen und ihre .h usw, sind universell (bis auf die .h für die Apps, wo die SVC's auf Wrapper umgeleitet werden) und können ohne jegliche Änderung von beiden Toolchaines übersetzt werden. Die nötigen Tool-Unterscheidungen existieren bereits und sie sind auch ausführlich im PDF dokumentiert. (Man kann natürlich die Gcc-Version des o.g. Headerfiles auch für Keil nehmen. Dann geht es auch beim Keil über die Wrapper. Aber effizienter ist eben die Keil-Version ohne Wrapper.) - Die 2 Startupcodes MÜSSEN (leider) völlig separat sein, weil die Assembler sich nicht verstehen. - die intermediären Dateien, also die Objektdateien, das beim Linken herausgekommene Elf-File und die diversen Report- und Map-Dateien kannst du getrost weglöschen, sie werden bei jedem Übersetzungslauf erneut erzeugt. - die finalen .hex und .bin Dateien sind die (begehrten) Ziele der ganzen Übung. Ich hab sie nach 'arm' und 'gcc' unterschieden, damit man mal nen Vergleich haben kann, wenn man das wünscht. - Die restlichen Dateien sind keine Sourcefiles, sondern gehören jeweils zu einer der bislang 'aufgefahrenen' Toolchaines - und da finde ich es besser, wenn man schon aus dem Namen erkennen kann, ob die Datei zu Arm/Keil oder zu Gcc gehört. Wenn du Keil sowieso nicht hast, dann kannst du die dazu gehörigen Dateiel einfach weglöschen. Und wenn du mit einer IDE arbeitest, dann sind auch die für Gcc gedachten .bat und .xcl (ExtendedCommandLine) überflüssig. Diesen Part kann/sollte/müßte jeder nach seinem Gusto gestalten. Siegfried und ich haben bloß danach geschaut, daß keiner im Regen stehen muß (Beispiel: SVC-Wrapper), weil der betreffende Compiler irgend ein Feature nicht eingebaut hat. Was meinen Frust mit den Betty-Apps und GCC betrifft, hab ich vorhin ne Anfrage im Gcc-Bereich gestartet. Vielleicht gibt es Abhilfe. Was den Thread in der Codesammlung betrifft, so meine ich, daß dort möglichst problemarme (oder problemlose) Entwicklungsstände von Zeit zu Zeit gepostet werden sollten - oder Tools, sobald diese eine gewisse Reife haben. Den Hinweis auf einen SVN-Server hab ich gelesen, aber eigentlich möchte ich mich dort nicht hineinhängen. In diesem Thread hier können wir uns ausheulen, wenn was nicht wie gewünscht klappt. Das ist sozusagen unser Basteltisch. So, und nun schau ich mir das Testfile von Siegfried an. An irgend etwas MUSS es ja liegen, daß es bei ihm klappt und bei mir nicht... W.S.
Kurzer Update. SwissBetty von Pollin geflasht mit BaseBetty.bin in Flash1 und BettyApp.bin (Sokoban) in Flash2. (Noch die 0.01 Version) Läuft alles SUPER! Peter
Hallo Peter, schön zu hören, dass es bei Dir läuft. Ich werde dann keine aktualisierten Komplettstände hochladen wie zuletzt zugesagt, denn das bringt keine Neuigkeiten (siehe Changelog von W.S.) und würde nur das Forum zumüllen. Falls ich da was falsch einschätze, bitte kurze Rückmeldung. Gruß Siegfried
@Siegfried: Doch.. von Zeit zu Zeit ein Full ZIP ist nicht verkehrt. Um den Forumsplatz machen ich mir da keine Sorgen.. Peter
Na gut, auf Wunsch eines einzelnen Herrn hier mein aktueller Stand. Ich hoffe ich habe keine zusätzlichen Fehler eingebaut. Der Dateianhang enthält keine hex oder bin Dateien. Diese zu erzeugen überlasse ich dem geneigten Leser zur Fingerübung. Achtung: dies ist keine "offizielle" Version von W.S. Gruß Siegfried
Ähem.. Peter, Ich sehe das ähnlich wie Siegfried. Du hast eigentlich alle relevanten Infos und Dateien, um selber so richtig loszulegen. Ich hätte da auch schon eine Idee für dich: mal durchkalkulieren, ob und wie sich das macht, 8 Bit mono Wavfiles mit 11.025 kHz Abtastrate. nee, kein Erwartungsdruck...;-) Wahrscheinlich wird Siegfried demnächst hier posten, was ihm an meinem gemixten Neudenglisch mißfällt, dann können wir das bereinigen. Ich hab inzwischen sein obiges Testfile seziert und meine, daß ich alsbald die Komplettübersetzung auch per Yagarto und Batchfile hinkriege. Dann ist das nächste "Release" fällig. Grund: entweder schaffe ich es, das Batchfile-Verfahren hinzukriegen - auch wenn ihr es nicht benutzt - oder die Batchfiles müssen rausfliegen, aus Sauberkeitsgründen. Natürlich bin ich derweil auch an einigen Sachen dran, Hilfsprogramme, z.B. eins, wo man diverse Apps zu einem kompletten Rom-Inhalt zusammenfassen kann. So die zündende Idee hab ich allerdings noch nicht. Hat einer von euch Lust auf Font-Gestaltung? Wenn ja, ansagen. Die Font-Bestückung der BettyBase muß ja nix endgültiges sein, da werden Ideen + Meinungen + Leute gesucht. Hardware-Angelegenheiten haben wir bislang auch völlig außen vor gelassen. ist auch ein Thema, z.B. Buchse für Stromversorgung, ne Art Breakout-Steckverbinder vorn und Festschreiben seiner Belegung, ne Anleitung wie und welche Prozessorpins anzuzapfen usw.. W.S.
@Siegfried: Danke. Make einwandfrei durchgelaufen. Base+Sokoban geflasht. Nettes Mädel beim Einschalten/Reset ;-) Peter
Ich bin kein (guter) C Entwickler :-(
ABAP geht, nützt hier aber nichts..
Daher bin ich vorerst beim Testen dabei..
Zitat:
"Natürlich bin ich derweil auch an einigen Sachen dran, Hilfsprogramme,
z.B. eins, wo man diverse Apps zu einem kompletten Rom-Inhalt
zusammenfassen kann. So die zündende Idee hab ich allerdings noch
nicht."
-> Wenn ich es richtig verstanden habe, müssen die immer an einer 32kb
Grenze anfangen. Ich würde da mal mit dd und bs=32k versuchen die
einzelnen Apps zusammen zu fügen..
Ich habe hier auch noch ein Util. makeimage, das wir bei avrcpm
verwendet haben, das ein bin auf x bytes anfüllt.. danach kann man das
mit copy /b zusammen fügen.
Ich hatte das gerade mal probiert und Adeline erst auf 32768 bytes
aufgefüllt und dann Sokoban dahinter kopiert. Ging nicht.. hat nur
Adeline gefunden und das Verhalten war irgendwie 'instabil'?
Ich vermute man muss bei einem nachfolgenden App bei diesem auch die
Startadresse (flash : ORIGIN = ...) anpassen:?
MEMORY
{
ram : ORIGIN = 0x40000000, LENGTH = 0x0c000 /* free RAM area
*/
flash : ORIGIN = 0x82000000, LENGTH = 1M /* FLASH ROM */
}
Peter
Hab das jetzt noch schnell mal getestet. Adeline ganz normal kompiliert. Mit makeimage auf 32768 Bytes angefüllt. Sokoban kompiliert mit: flash : ORIGIN = 0x82032768, LENGTH = 1M Hinter Adeline kopiert mit copy /b.. Auf Flash2 geflasht. Erkennt wieder nur Adeline.. läuft aber stabil.. Flash2.rom im zip Peter
Lag eigentlich schon im Bett.. Ich Dussel! Muss natürlich Hex sein: flash : ORIGIN = 0x82008000, LENGTH = 1M Nochmal übersetzt und verbunden mit copy wie oben beschrieben. Geht aber trotzdem nicht. Findet wieder nur Adeline. Neue Datei hängt an. Peter
Heureka! anbei die Version 0.03 und ähem.. Peters Probleme waren auch meine. Sch... Pointerarithmetik, ich Dussel. W,S,
Hallo zusammen, hier zwei notwendige Ergänzung für den Release 0.03 1. make-Umgebung für BettyBase und BettyApp hier wurden die *.ld Dateien an die Segmentänderung für den Startup (bisher .text, jetzt .text.startup) in den asm-Dateien angepasst. 2. gcc Umgebung für BettyApp hier wurden für die neuen APIs die .global Deklarationen in BettyApiGcc.asm ergänzt. Gruß Siegfried
@W.S.: Super!! Läuft bei mir. Was mir noch aufgefallen ist: BettyManager unter Bettyman scheint älter zu sein als unter Tools. Kann vieles noch nicht was die Version unter Tools kann. In den gcc Batch-Dateien und xcl stehen 'falsche' Pfade drin.. Teils c:\gcc.. teils e: Habe ich auf C: geändert. Die make Dateien fehlen teilweise in den Verzeichnissen.. Prima!! Danke+Gruß, Peter
Jau. Ich meine, jetzt ist ein bissel Konsolidierung angesagt. Ich war nur so happy, daß es ENDLICH !! geklappt hat. Noch einDetail, was ich aber schon eingearbeitet habe: Bei GCC lieber nur R0 im Startup der Apps benutzen, weil bei der GCC-BettyBase offenbar so gut wie alle Register in Benutzung sind. Da der Returnwert in R0 geliefert wird, ist also zuvor R0 für anderes benutzbar. Ach, nochwas: Das Linkerscript, was Siegfried benutzt, ist eine gekürzte Version eines der originalen Linkerscripts von Yagarto. Nach meiner bescheidenen Meinung hätte ein Hinweis auf diesen Umstand in den Kopf des Scripts gehört. Wenn man im Makefile die RAM- und ROM- Adressen vereinbart, dann sind auch die originalen Linkerscripts benutzbar. W.S.
So, ich hab Siegfrieds Anhang eingearbeitet und das Ganze in der Codesammlung gepostet. W.S.
Hi, mal eine kurze Meldung abgebe. Hab mir auch so eine Betty mitbestellt, werde mich auch damit beschäftigen sobald ich zeit finde. Danke für die Anleitung im anderen Thread, wollte den jetzt nicht zuspammen, aber mal positive Resonanz geben und mich bedanken für die Veröffentlichung es Leitfadens.
W.S. schrieb: > Ach, nochwas: Das Linkerscript, was Siegfried benutzt, ist eine gekürzte > Version eines der originalen Linkerscripts von Yagarto. Nach meiner > bescheidenen Meinung hätte ein Hinweis auf diesen Umstand in den Kopf > des Scripts gehört. Nur der Vollständigkeit halber möchte ich darauf hinweisen, das das von mir verwendete Linkerscript im Kopf den Copyright Vermerk Copyright (C) 2007 Ch. Klippel enthält und aus Betty Boop stammt. Ich habe lediglich die Anpassung an die Lernbetty vorgenommen und das auch so im Kopf der Datei vermerkt. Gruß Siegfried
Ach Siegfried, du warst nicht gemeint - ich habe das "Copyright..." sehr wohl gelesen, als ich die diversen Linkerfiles miteinander verglich und bin ein wenig pikiert darüber. Möchte jetzt aber nicht die ganze GPL durchzulesen um daraus ein Thema zu machen. Ich hab's in die Doku geschrieben, daß man auch die originalen Linkerfiles nehmen kann, für den Fall, daß jemand ein copyright issue aufmacht. Die Lernbetty soll jedenfalls nicht darunter leiden. Ich sag's mal so: Die in der ganzen Lernbetty enthaltenen Files sollten nach meiner Meinung dazu dienen, daß der ursächliche Zweck der Lernbetty erreicht wird, daß also all diejenigen, die sich mit ihr in die ARM-Programmierung einarbeiten wollen, dies auch können und dabei was dazulernen bzw. sich selbst was beibringen. Und damit bin ich es zufrieden. Irgendwie ist es auch ein bissel Ingenieurs-Ehre, sein Wissen an die nachfolgenden Generationen weiterzugeben. Ich denke mal, du siehst das ähnlich. Aber es gibt Wichtigeres: Wie geht's weiter? Zunächst kommt mir die Frage hoch: Ist es sinnvoll, daß wir uns jetzt Gedanken machen über Hardware-Veränderungen wie z.B. Steckverbinder oben und/oder unten, um interessante Signale vom uC zugänglich zu machen? Eigentlich meine ich, daß andere ihre eigenen Interessen und Ideen haben und sich beim Basteln selbst was ausdenken. Eine ordentliche Basis haben sie ja. W.S.
Hallo W.S., wie geht es weiter, fragst Du. Ich kann die Frage lediglich für mich beantworten. Zunächst möchte ich mit der einen oder anderen kleinen App sehen, wie brauchbar die jetzige Umgebung ist. Erst dann kann man Optimierungs- oder Erweiterungspotential erkennen. Wenn das dann in eine Weiterentwicklung mündet, schön, da mache ich gerne mit. Zurzeit habe ich den Eindruck, dass Du eine menge Energie investiert hast, ansonsten aber wenig konkrete Rückmeldungen kommen. An der fehlenden gcc Unterstützung kann es nicht liegen. Vielleicht warten die stillen Beobachter auf die Implementierung einer youtube App - oder was wäre die Killer-App? Was aus meiner Sicht in einem nächsten Schritt interessant wäre, ist einfache Sound-Unterstützung zur Untermalung einfacher Spiele. Für den Datenaustausch zwischen zwei Bettys wäre ein einfaches Funkprotokoll hilfreich. Und bevor hier wieder jemand tönt, dass es dafür leistungsfähigere Plattformen gibt: ja, stimmt. Für mich ist die jetzige Umgebung eine gute Ausgangsbasis. Daher zunächst Dank an Dich, W.S. Mal sehen ob Ideen, Anforderungen oder gar Unterstützungsbeiträge von den stillen Beobachtern kommen. Also Leute, was habt Ihr mit Euren Bettys vor? Gruß Siegfried
Ein paar 'wilde' Ideen: Als Retro-Computer Fan: Retro-Spiele wie: Pong, Invaders, Missile Command, Asteroids, etc. Pong ggf. als Spiel über 2 Betty's Ggf. kann man die andere Hardware mit nutzen (Scart-, TAE-Adapter) Implementierung I2C - Protokoll in der Base und dann Nutzung von solchen Sensoren. KIM-1 Emulation; LMC-Emulation (Little Man Computer) An dieser Stelle auch nochmals meinen Dank an W.S. und Siegfried! Was auch noch schön wäre, wäre die Unterstützung der DE-Betty's. Peter
ich hab mir mittlerweile eine Handvoll rote Laserdioden per ebay von nem netten Chinesen gekauft und in der Betty nachgesehen, ob man den IR-Sendetrakt vom Empfangstrakt trennen kann. Ja, sollte gehen. Damit wäre der berührungslose Drehzahlmesser realisierbar: Laserdiode anstelle der IR-Diode, Fototransistor daneben mit nem schwarzen Röhrchen als "Scheuklappe" drumherum. Mal sehen. Das wäre dann die erste Hardware-Modifikation.. W.S.
Hallo, eine Frage an W.S. , in den Dateien BettyAPIxxx.asm und BettyAPPxxx.h fehlt ein Verweis auf die Funktion DrawLine aus aus dem GDI. Füge ich die entsprechenden Aufrufe ein, so stürzt beim Aufruf die Betty ab und führt einen Reset aus. Daher meine Frage: ist DrawLine vieleicht fehlerhaft (was ich nicht glaube), läuft nur ein Stack über, oder habe ich vieleicht doch einen Fehler gemacht und etwas übersehen. Vielen Grüße und schon einmal Danke Bobby
Bobby B. schrieb: > Füge ich die entsprechenden Aufrufe ein, so stürzt beim > Aufruf die Betty ab und führt einen Reset aus. Siehste, genau deswegen gibt es genau diese Funktion per SWI nicht, sondern zwei andere Funktionen MoveTo und LineTo. Der Grund dafür ist, daß die Hardware beim SWI bzw. SVC (Supervisor-Call) vom aktuellen Stack auf den SVC-Stack umschaltet. Deswegen sind bei allen SVC's nur maximal 4 Argumente erlaubt, und diese müssen sich in jeweils einem Prozessor-Register darstellen lassen, dürfen also int oder float oder Pointer oder sonstwas sein, was in 32 Bit reinpaßt. Gemäß Aufrufkonvention werden nämlich die ersten 4 Argumente in Registern übergeben und alle weiteren über den Stack. Aber der ändert sich ja, deswegen der Absturz. Du kannst das alles in den Dokus zum ARM7TDMI von ARM nachlesen, wozu ich hier auch alle anderen Leser animieren möchte. W.S.
@ W.S. Vielen Dank, habe die Dokumentationen wirklich noch nicht vollständig gelesen.... Bobby
Was ist eigentlich der Vorteil von SWI/SVC Calls in diesem Kontext? Also anders als "weil man kann, wenn es geht"? Immerhin ist das hier doch eine sehr limitierte Platform bzgl. verfügbarer Resourcen. Warum nicht einfach eine Function-Pointer Tabelle nutzen dafür, wenn es schon "linker unabhängig" sein soll? So wie ich sehe soll der Hauptgrund doch sein das nachladbare/spaäter-definierte Programmschnipsel wissen was aufzurufen ist wenn z.B. ein drawIrgendwas() benutzt wird. Nun hat man aber sowieso schon das Problem das diese Schnipsel an festen Adressen anfangen müssen. Also muss der Linker das auch wissen. Man hat also eh einen "Overhead" um das zu realisieren. Warum dann nicht gleich ein Compilerunabhängiges Lookup? Nur weil "Keil kann's ja"? Sehe den Sinn dahinter einfach nicht.... Ausser das man damit wunderbar die Einsteiger frustrieren kann. Und nein, nur weil ein Firlefanz weniger deklariert werden muss ist kein Grund wenn man bedenkt was sowieso schon abhängig von der main-app definiert werden muss... Grüße, Chris
Christian Klippel schrieb: > Sehe den Sinn dahinter einfach nicht.... Ausser das man damit wunderbar > die Einsteiger frustrieren kann. SVC's, also Supervisor-Calls sind eine in der ARM-Hardware schon ewig vorgesehene Schnittstelle zwischen Anwendungen und Betriebssystem. Dafür gibt es spezielle Maschinencodes, "SVC nnn" wobei nnn bei thumb für 0..255 steht. Es ist sozusagen ein geregeltes Tor zwischen App und BS, wobei es für eine App völlig uninteressant ist, wo im BS die eigentlichen Dienstroutinen stehen - (compilerunabhängige) Sprungadressen sind dabei völlig überflüssig - ebenso jegliche Vorkehrungen zwischen arm und thumb (das erledigt die Hardware und das BS). Vergleiche das also mal mit dem Benutzen einer Dienstfunktion von Windows. Wenn du in irgendeinem Programm CreateWindowA(....) schreibst, dann rufst du damit eine Dienstfunktion von Windows auf, ohne daß es dich bekümmern müßte, in welchem Teil von Windows sich diese eigentlich befindet und wie sie intern funktioniert. Für sowas gibt es ein API. Abgesehen von der generellen Entkopplung zwischen BS und Apps durch die SVC's haben diese SVC's auch noch eine andere gute Eigenschaft: Durch sie ergeben sich recht kompakte Binaries, denn es ist für den Compiler und Linker eben nicht nötig, sich um irgendwelche Funktionsadressen zu kümmern. Das macht den Aufruf ausgesprochen kompakt. Ein Beispiel kannst du in der Doku nachlesen. Der Wermutstropfen dabei ist, daß dieses ausgesprochen wichtige Hardware-Feature vom GCC offenbar nicht unterstützt wird, weswegen wir uns für den GCC einen Workaround haben ausdenken müssen, der die eigentliche Kompaktheit zum Teil wieder zunichte macht. Ansonsten verstehe ich deine Adreßbedenken nicht: Christian Klippel schrieb: > Nun hat man aber sowieso schon das Problem das diese Schnipsel an festen > Adressen anfangen müssen. Es sind keine Schnipsel, sondern Apps, also Anwendungen, die die Dienste der BettyBase als eines (kleinen) Betriebssystems benutzen. Dafür gibt es das API in Form einer Headerdatei. Jede App hat ihre eigene main() und ihren eigenen Startupcode. Das ist genauso, als wenn du ne ganz gewöhnliche Firmware für nen uC schreiben würdest - mit dem Unterschied, dß du Zugriff auf Betriebssystem-Funktionen hast, ohne selbige schreiben/implementieren zu müssen. Daß die Apps bei 32K Grenzen beginnen müssen leitet sich daher, daß ich im Appfinder der BettyBase es eben so vorgesehen habe, daß der Appfinder nur dort nach Apps sucht. Ich denke, dieses 32K Raster ist fair, nicht zu fein und nicht zu grob und es stimmt recht gut mit der Blockstruktur der Flashroms überein, die sich ja auch nur in 32K Bereichen löschen lassen - mal von den Bootblocks abgesehen. Aber all denjenigen, denen das nicht gefällt, steht es frei, den Appfinder umzuschreiben. Denkbar wäre ja auch eine Art Inhaltsverzeichnis an einer bestimmten Stelle im Flashrom, wo die (dann beliebigen) Anfangsadressen der vorhandenen Apps vermerkt sind. Aber das empfinde ich als unangemessenen Overhead. Das ganze ist also überhaupt nicht zum Frustrieren von Einsteigern vorgesehen, sondern zu deren Komfort. Man brennt die BettyBase einmal irgendwann in den ersten Flashrom (egal welche Version, Keil oder GCC) und braucht sich ab da nicht mehr um die BettyBase zu kümmern - und wenn es ein Update der BettyBase gibt, braucht mn an den bestehenden Apps nix zu ändern, sondern nur die BettyBase "upzudaten". Das Einzige, was man zum Schreiben einer App sich vorher überlegen muß ist die Anfangsadresse des Codes, da man ja - soweit der Platz im Flash reicht - beliebig viele Apps in der Betty haben kann und selbige logischermaßen nicht alle auf der gleichen Adresse im Flash stehen können. Die Apps sind XIP (also eXecuted In Place), werden also direkt aus dem Flash ausgeführt und nicht zuvor in den RAM geladen. Aber hat man die Flashadresse erstmal in sein Linkersteuerfile oder Makefile oder (je nach benutzter Toolchain) in das zugehörige Projektfile geschrieben, braucht man sich anschließend nur noch um das zu kümmern, was man eigentlich in seiner App realisieren will. W.S.
Ich nehm mich grade an, die sache mit devkitARM bauen zu können. Das ist eine fertig gebaute ARM-Toolchain, momentan GCC4.7.1, eigentlich gedacht für GBA/GP32/NintendoDS-Hacks. Passt aber optimal, der GBA ist auch nichts anderes als unser ARM7TDMI-S. Melde mich wieder, der Grützkopf
So Leute, in der Codesammlung gibt's ein kleines Update der Lernbetty. Ich habe die Soundausgabe inzwischen eingebaut, das API etwas erweitert und noch ein paar kleinere Unpäßlichkeiten beseitigt, z.B. wenn eine App mit 0 zurückkehrt, daß dann auch das Appfinder-Menü neu aufgebaut wird. Ich bin die ganze Zeit am Grübeln, wie man am glimpflichsten einen richtigen E/A-Schalter einbaut, denn bloß so mit Standby klappt das nicht gut genug, da ist nach recht kurzer Zeit der Akku trotzdem leer. Obendrein ist m.E. jetzt der Zeitpunkt gekommen, nun endlich physische Veränderungen vorzunehmen, also Portpins zugänglich zu machen. Mal sehen, was mir dazu einfällt. Frohes Basteln im neuen Jahr wünscht W.S.
Hallo Zusammen, Ich versuche seit einiger Zeit die JTAG pins als GPIO zu nutzen. Leider reagieren die Pins trotz Deakivierung des JTAGs in PINSEL2 ( PINSEL2 &= ~(1<<2) ) nicht auf Änderungen beim Schreiben von IO1SET oder IO1CLR. Habe auch schon in der Initialisierungs asm das JTAG bit entfernt -> keine Änderung an den Pins zu beobachten Kann mir jemand weiterhelfen? MFG Max
Guck mal im Datenblatt des LPC nach: soweit ich mich recht duster erinnere, laufen Port0 und 1 im schnelleren FIO-Modus, also FIO1SET oder FIO1CLR (ohne jede Gewähr so spät am Abend). W.S.
Hallo, ich habe gestern die Kombination - LernBettyPacked_R0.04.zip - GCC ARM 4.8 2014q2 (vorkompiliert von https://launchpad.net/gcc-arm-embedded) - lpctool (gepatcht auf 38400 baud, http://www.bettyhacks.com/wiki/index.php/LPCTool#Lpctool-Probleme) - Linux - Makefile erfolgreich zum Laufen gebracht; von den Applikationen habe ich Sokoban getestet. Danke an alle, die bei der Zusammenstellung mitgewirkt haben! Neben ein paar Kleinigkeiten (make funktionierte nicht wg. Groß/Kleinschreibung), gibt es ein paar Differenzen zwischen dem Batch- und dem Makefile-Ansatz zum Kompilieren. Die würde ich aufräumen, deshalb - Ist 0.04 die aktuellste Version? - Spricht etwas dagegen, den Ansatz mittels Batch-Dateien zu entfernen, um damit die GCC-basierte Kompilierung auf einen Weg zu reduzieren? Zwei Varianten ARM/GCC sind die Mühe sicherlich wert, aber zwei Varianten im GCC-Bereich bergen die Gefahr, dass es auseinander läuft ohne einen besonderen Mehrwert. Schliesslich: Kennt jemand das Problem, dass die Betty "pfeift"? Es sind nicht mehr die neuesten Akkus, aber im Vergleich zur Standard-Firmware ist ein deutliches Pfeifen im höheren Bereich zu hören. Ciao Roland
Es hatte einige Unstimmigkeiten gegeben, ob und welches Linkerscript nötig wäre, aber wenn man sich mal durch das ganze Link-gewusel beim GCC durchgelesen hat, merkt man, daß man mit passenden Sektions-Namen in den Quellen auch ohne jegliches separates Linkscript auskommt, da der GCC-Linker schon was Passendes per Default eingebaut hat. Ebenso hatte sich herausgestellt, daß man für unterschiedliche Optimierungsstufen beim GCC eher unerwartete Ergebnisse kriegt. -O3 oder so war wohl schlechter als -O2 ..sofern mich meine Erinnerung nicht trügt. Die Übersetzung per Make zu tun, kann man ja jederzeit, wenn die Arbeitsplattform es erlaubt. Aber gerade bei Leuten wie ich, die NUR mit Windows entwickeln, wird das zum Krampf, die Details hatte ich m.W. schon mal geschrieben. Deshalb ist der schlichte Weg über eine einfache Batchdatei in meinen Augen immer noch der am besten nachvollziehbare und das ist - zumindest mir - durchaus ein Anliegen. Es soll die Lernbetty ja ein System sein, wo Benutzer unterschiedlichster Toolchaines damit zu Potte kommen, ohne sich in den Spezifika ihrer jeweiligen IDE's zu verlieren. Das per irgendeiner IDE durchzuziehen, kann man ja immer noch. Die eventuellen Probleme, die man mit einem case-sensitiven BS hat, kann ich verstehen, aber sowas tritt bei mir nicht auf, deswegen ist das ne Sache, wo entsprechende Leute hiermit aufgerufen seien, da nen Beitrag zu leisten. Es ist aber im Grunde völlig wurscht, welcher Teil (Bettybase, Apps) mit welchem Compiler übersetzt worden sind. Es spielt alles mit allem. Und Sokoban ist wirklich die einzige "richtige" App auf der LernBetty. Die anderen Apps sind eher nur Demos, um z.B. die Bild-Ausgabe oder die Audioausgabe und die Verwendung von SVC's zu demonstrieren. Im Grunde wäre mir danach, daß ein IAR-Benutzer die Lernbetty auch mal mit IAR übersetzt und das als Variante beisteuert. Ebenso frag ich mich, ob es denn nicht mal ne Möglichkeit gäbe, z.B. den ARM-Port von Free Pascal für die Betty nutzbar zu machen. Inzwischen hab ich einiges mit Cortexen gemacht, aber die Grundstruktur der Lernbetty hat sich auch für Cortexe als erstaunlich tragfähig erwiesen. Das Einzige, wo man nen dezenten Paradigmenwechsel sieht, ist der Startupcode und die Interrupt-Handler. Also: Mach mal, hau rein, alles Gute! W.S.
Hallo, ich habe hier mehrer Betty`s (keine SwissBetty) und würde gerne die mit LernBetty probieren. Hat jemand dieses schon erfolgreich laufen ? Wenn ja könnte mir jemand die sourcen dafür schicken ? Gruß Frank
Angehängte Dateien:
-
BettyMandel.JPG
80 KB -
BettyPhilo.JPG
87 KB
Hänge hier mal mein Projekt-ZIP ein. Unter Win$ fehlen da nur noch Yagarto ARM GCC und MS$ Laufzeitbibliotheken. 2 kleines Apps/Demos's sind enthalten. Apfelmänchen und philosophische Sätze ;-) Evtl. inspiriert das ja den einen oder anderen auch mal etwas dafür zu (um)zuschreiben.. Peter
Hallo Leute, wer kann mir eine neue Betty FB zu normaler FB umprogrammieren kostenlos. Versandkosten klar gehen zu meinen lasten. Danke mal im voraus.
Winnyboy schrieb: > Hallo Leute, wer kann mir eine neue Betty FB zu normaler FB > umprogrammieren > kostenlos. Das solltest du mal erklären. Es gibt für die Betty nur 2 Möglichkeiten: Entweder spielt man die letzte Firmware der Originalhersteller ein und hat dann einen lernfähige Fernbedienung für 4 Geräte oder man spielt Boop ein und hat dann eine lernfähige Fernbedienung mit den zusätzlichen Spässchen von Boop, wie dem Funkscanner Teil. Die Jungs hier machen as anderes, sie machen aus der Betty eine ARM Spielwiese für den LPC2200 - das hat nur wenig mit der Eigenschaft als Fernbedienung zu tun.
:
Bearbeitet durch User
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.