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.
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.
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
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
>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.
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?
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.pdfhttp://tigcc.ticalc.org/doc/gnuasm.htmlhttp://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.
.. 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
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
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:
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 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
@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
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.
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
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.
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.
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
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
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.
