Forum: Mikrocontroller und Digitale Elektronik die Betty-Fernbedienung von Pollin als ARM-Eval Board


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von W.S. (Gast)


Lesenswert?

Hallo ihr alle zusammen,

hier im Forum gibt es immer wieder Nachfragen, was man denn als Hardware 
nehmen könnte, um mit dem Programmieren von ARM uC anzufangen.

Häufig wird mit "nimm ein STM32F4 Discovery" geantwortet, was ja 
eingentlich nicht soooo verkehrt ist. Aber dieses Board hat fast nix 
drauf außer dem nackten uC.

Die Betty hingegen hat nicht nur einen relativ riesigen Flash (2x 1 MB), 
sondern auch noch ein Grafik-Display, Tasten, RTC, Funkmodul, IR Sender 
und (mit Einschränkung) Empfänger, und (nicht zu verachten) ein Gehäuse. 
Obendrein ist sie auf recht billige Weise per Bootlader programmierbar 
und mit rund 4 Euro auch nicht teuer - und der Einstieg mit einem 
LPC2220 (ARM7TDMI) ist auch noch nicht wirklich veraltet.

Eigentlich ist sie mit diesen Eigenschaften eine passable Basis für den 
Einstieg in die ARM-Welt.
Aber: Die bei Bettyhacks herunterladbare "Boop"-Firmware ist alles 
andere als einsteigerfreundlich und in vielen Teilen ausgesprochen.. 
naja, ich sag mal "unpädagogisch" bis grob daneben (wenn ich mir z.B. 
den FIQ anschaue, kommt mir das Grausen).

Meine Idee ist nun, für die Betty eine neue Firmware aufzusetzen, die 
deutlich einsteigerfreundlicher ist und die wichtigsten Funktionen per 
SWI erreichbar bereits eingebaut hat. Dabei sollte die Funktion als 
Fernbedienung eben nicht die Hauptrolle spielen, sondern es sollte auf 
einfache Weise möglich sein, kleinere Anwendungen zu schreiben, die auf 
die Dienste der eingebauten Firmware (Grafik, Tasten, Konvertierungen, 
Sound, Uhrzeit usw.) aufsetzen können ohne daß dazu der gesamte Kram neu 
übersetzt werden müßte. Wer den STM32-Primer2 von Raisonance kennt, weiß 
was mir da so etwa vorschwebt. Es sollte aber einfacher handhabbar 
werden als das Circle-OS.

Frage an alle: Hat jemand Lust (und genug Ahnung), sich mit sowas zu 
befassen bis eine runde Sache dabei herauskommt?
( quasi den Forums-ARM-Primer zu kreieren ? )
Also: Gibt es Mitmacher?


W.S.

: Verschoben durch Moderator
von Walter S. (avatar)


Lesenswert?

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.)

von W.S. (Gast)


Lesenswert?

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.

von Walter S. (avatar)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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.

von A. S. (telekatz)


Lesenswert?

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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Angehängte Dateien:

Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Angehängte Dateien:

Lesenswert?

... und warum der TAE Adapter so interresant ist, bzw. der Chip darin.

Grüße,

Chris

von Jack B. (jackbraun)


Lesenswert?

>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

von swausd (Gast)


Lesenswert?

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

von Jack B. (jackbraun)


Lesenswert?

>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

von swausd (Gast)


Lesenswert?

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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Tester (Gast)


Lesenswert?

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.

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Jack B. (jackbraun)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von swausd (Gast)


Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von holger (Gast)


Lesenswert?

>Wie gesagt, mit Keil und nicht mit GCC.

Da wird es wohl ganz schwer jemanden zum mitmachen zu finden;)

von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>> 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.

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von A. S. (telekatz)


Lesenswert?

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

von Uwe B. (boerge) Benutzerseite


Lesenswert?

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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Bernhard M. (boregard)


Lesenswert?

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

von Michael G. (let)


Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von B. G. (smarti)


Lesenswert?

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

von Michael G. (let)


Lesenswert?

@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 ;).

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Tom K. (xpac)


Lesenswert?

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.

von Siegfried W. (swausd)


Lesenswert?

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

von Tom K. (xpac)


Lesenswert?

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?

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Tom K. (xpac)


Lesenswert?

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!

von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?


von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

W.S. schrieb:
> Ja. Ich hab heute mal versucht, den Startupcode mit nem Gnu-Assembler
> (arm-eabi-....-as.exe) zu übersetzen. O Gott, das Teil kriegt sich ja
> garnicht mehr ein. Völlig inkompatibel zum Assembler von ARM.

Was ganz einfach daran liegt das der GNU Assembler halt für mehr als nur 
eine Platform zu gebrauchen ist.

> Wenn man alle Kommentare entfernt, dann geht's weiter: EQU versteht er
> nicht, muß man durch = ersetzen.

Oder durch .equ

> Ob das dann etwas ist, was man
> exportieren kann, oder bloß wieder mal ne lexikalische Ersetzung, hab
> ich noch nicht herausfinden können. Sämtliche organisatorischen
> Anweisungen gehen auch erstmal nicht (AREA, ENTRY, die Stackpreserves,
> ARM ...)

http://www.cse.unsw.edu.au/~cs3221/labs/assembler-intro.pdf
http://tigcc.ticalc.org/doc/gnuasm.html

http://sourceware.org/binutils/docs-2.21/ld/

> Obendrein ist es mir nicht gelungen, diesem Assembler eine sinnvolle
> Übersetzungsliste zu entlocken. Normalerweise erwartet man ...

Normalerweise erwartet man das ein Tool die Dinge so macht wie sie in 
der entsprechenden Doku stehen. Man erwartet nicht das ein Tool sich 
identisch zu einem völlig anderen Tool verhält. Und schon garnicht 
erwartet man das sich etwas, das man nicht kennt bzw. dessen Bedienung 
man nicht kennt, gleich beim ersten mal genau das macht was man sich so 
denkt.

Achja, natürlich bleibt es dir ganz alleine überlassen welche Tools Du 
benutzt. Allerdings halte ich das Verwenden eines proprietären Tools das 
eine Stange Geld kostet für kontraproduktiv. Denn damit wird automatisch 
ein Großteil der interresierten Leute ausgeschlossen. Insbesondere wenn 
das ganze eine Eval/Dev-Platform werden soll. Desweiteren: Gäbe es Keil 
denn überhaupt auch für andere Plattformen außer Windows?

Grüße,

Chris

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>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.

von W.S. (Gast)


Lesenswert?

Nachtrag: Die bmplib.c schmeiß bitte ersatzlos raus. Bin gerade dabei, 
mir für Bilder was anderes auszudenken.

W.S.

von W.S. (Gast)


Lesenswert?

Noch'n Nachtrag:

Vorschlag:

#if defined (GCC)
#define _irq   __attribute_ ((interrupt("IRQ")))
#endif

in StdTypes.h reinsetzen?

W.S.

von W.S. (Gast)


Lesenswert?

.. 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.

von Siegfried W. (swausd)


Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Peter S. (petersieg)


Lesenswert?

@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

von Florian R. (zeflo)


Lesenswert?

Etwas OT:

Hat hier noch Jemand den IP-Adapter und würde den Loswerden wollen?

Florian

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Peter Sieg (Gast)


Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von Peter S. (petersieg)


Angehängte Dateien:

Lesenswert?

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

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Peter S. (petersieg)


Lesenswert?

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

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

@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.

von Siegfried W. (swausd)


Lesenswert?

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

von Peter S. (petersieg)


Angehängte Dateien:

Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von Peter S. (petersieg)


Lesenswert?

@Siegfried:

Bei mir noch Fehler:
thumbunopt.o infrared/ir_rca.thumbunopt.o infrared/ir_rcmm.thumbunopt.o 
infrared
/ir_rec80.thumbunopt.o infrared/ir_recs80.thumbunopt.o 
infrared/ir_rf.thumbunopt
.o infrared/ir_sirc.thumbunopt.o infrared/ir_spaceenc.thumbunopt.o 
infrared/ir_l
irc.thumbunopt.o -lc -lgcc
c:/WinARM/bin/arm-elf-ld: ERROR: 
c:/WinARM/arm-elf/lib/interwork\libc.a(siprintf
.o) uses hardware FP, whereas boop_rom.elf uses software FP
c:/WinARM/bin/arm-elf-ld: failed to merge target specific data of file 
c:/WinARM
/arm-elf/lib/interwork\libc.a(siprintf.o)
c:/WinARM/bin/arm-elf-ld: ERROR: 
c:/WinARM/arm-elf/lib/interwork\libc.a(vfiprint
f.o) uses hardware FP, whereas boop_rom.elf uses software FP

??

Peter

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von Peter S. (petersieg)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Peter Sieg (Gast)


Lesenswert?

@W.S. Lese mir die PDF durch - Hast du ein Beispiel app zum testen hier 
im Thread 'versteckt'? (Ich habe da zumindest nichts gesehen..)

Man braucht zum Übersetzen keine Batchdatei. Einfach 'make' reicht mit 
der mitgelieferten makefile:
1
###############################################################
2
#####
3
##### Makefile for boop - OpenSource firmware for Betty
4
##### adapted for "Lernbetty"
5
#####
6
##### original (C) 
7
##### Makefile V0.1 by alterego - alteregon@gmx.net
8
##### Makefile v0.2 by Tobias - tobias-betty@23.gs
9
##### Created at 15.11.2012 
10
#####
11
##### Adapted Makefile version for "Lernbetty"
12
##### V0.3 by swausd 18.11.2012
13
#####
14
###############################################################
15
16
###############################################################
17
#####
18
##### PATHS (default installation)
19
#####
20
##### You can put your path-config into Makefile.local
21
##### to override these defaults
22
#####
23
###############################################################
24
25
ARMBASE = C:/yagarto
26
INCLUDEPATH = $(ARMBASE)/include
27
LIBPATH = $(ARMBASE)/lib/gcc/arm-none-eabi/4.7.2 -L$(ARMBASE)/arm-none-eabi/lib
28
ARMPATH = $(ARMBASE)/bin
29
TOOLPREFIX = arm-none-eabi-
30
31
CFLAGS = -Wall -mthumb-interwork -msoft-float -ggdb
32
33
#OPENOCD = openocd -f betty.cfg -f interface/parport.cfg
34
35
###############################################################
36
#####
37
##### Compiler, Linker and Tools
38
#####
39
###############################################################
40
41
CC = $(ARMPATH)/$(TOOLPREFIX)gcc
42
AS = $(ARMPATH)/$(TOOLPREFIX)as
43
LD = $(ARMPATH)/$(TOOLPREFIX)ld
44
OC = $(ARMPATH)/$(TOOLPREFIX)objcopy
45
OD = $(ARMPATH)/$(TOOLPREFIX)objdump
46
47
CPUFLAGS = -mcpu=arm7tdmi-s
48
OPTFLAGS = -O0
49
CFLAGS = -Wall -mthumb-interwork -msoft-float
50
INC = -I$(INCLUDEPATH) -I.
51
#INC = -I$(INCLUDEPATH) -I. -Iinterrupt -Idisplay -Ikeyboard -Iaudio -Iinfrared -Iserial -Iflash -Icc1100 -Igui -Itimer -Igames -Iadc -Irtc  -Itools
52
ASFLAGS = -D --gstabs -mthumb-interwork -mfpu=softfpa
53
LDFLAGS = -Tlpc2220.ld -Map BaseBetty.map
54
LIBS = -lc -lgcc -lm
55
THUMBFLAGS = -mthumb
56
57
COMPILE = $(CC) $(CPUFLAGS) $(CFLAGS) $(INC)
58
59
###############################################################
60
#####
61
##### Do it
62
#####
63
###############################################################
64
65
# Recursive expansion of Makefile rules.
66
define expand_dir
67
 # Reset vars for subdir for the case that Make.conf does not exist
68
 SUBDIRS :=
69
 SRCS :=
70
 THUMBSRCS :=
71
 THUMBSRCSUNOPT :=
72
 -include $(1)Make.conf
73
 ALLSRCS += $$(SRCS:%=$(1)%)
74
 ALLTHUMBSRCS += $$(THUMBSRCS:%=$(1)%)
75
 ALLTHUMBSRCSUNOPT += $$(THUMBSRCSUNOPT:%=$(1)%)
76
 DEPS += $(1).deps
77
 $$(foreach adir,$$(SUBDIRS),$$(eval $$(call expand_dir,$(1)$$(adir)/)))
78
endef
79
80
ALLSRCS :=
81
ALLTHUMBSRCS :=
82
ALLTHUMBSRCSUNOPT :=
83
84
$(eval $(call expand_dir,))
85
86
OBJS := $(patsubst %.asm,%.o,$(ALLSRCS:.c=.o)) $(ALLTHUMBSRCS:.c=.thumb.o) $(ALLTHUMBSRCSUNOPT:.c=.thumbunopt.o)
87
88
all:  version $(DEPS) BaseBetty.bin BaseBetty.hex
89
90
debug:  version.h $(DEPS) BaseBetty.bin BaseBetty.hex
91
92
release: clean version $(DEPS) BaseBetty.bin BaseBetty.hex
93
#  @echo -n '\n\nRelease erstellt SVN Version ++'
94
#  @cat .svn/entries | sed -n '4p'
95
  
96
version: 
97
#  echo -n '#define SVNVERSION ' > version.h
98
#  sed -n '4p' .svn/entries >> version.h
99
100
version.h:
101
  echo -n '#define SVNVERSION ' > version.h
102
  sed -n '4p' .svn/entries >> version.h
103
  
104
test: BaseBetty.elf
105
  $(OD) -h $<
106
107
%.bin: %.elf
108
  $(OC) -O binary $< $@
109
110
%.hex: %.elf
111
  $(OC) -O ihex $< $@
112
113
BaseBetty.elf: $(OBJS)
114
  $(LD) $(LDFLAGS) -L$(LIBPATH) -o $@ $^ $(LIBS)
115
116
%.o: %.asm
117
  $(AS) $(CPUFLAGS) $(ASFLAGS) -o $@ $<
118
119
%.o: %.c
120
  $(COMPILE) $(OPTFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $<
121
122
%.thumb.o: %.c
123
  $(COMPILE) $(THUMBFLAGS) $(OPTFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $<
124
  
125
%.thumbunopt.o: %.c
126
  $(COMPILE) $(THUMBFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $<
127
128
$(DEPS):
129
  mkdir -p $@  
130
131
uresident: resident
132
resident: BaseBetty.bin
133
  $(LPCTOOL) -i -v -e -a $<
134
135
program: BaseBetty.bin 
136
  $(OPENOCD) -c init -c 'flash_boop $<' -c shutdown
137
138
clean:
139
  -rm -Rf $(DEPS)
140
  -rm -f $(OBJS) *.elf *.bin *.hex *~
141
142
-include $(DEPS:=/*)

Das Übersetzen der orig. Boop Firmware geht so auch mit der Yagarto 
Tollchain.

Ich nutze bisher noch gar keine IDE wie eclipse (sind mir immer viel zu 
riesig ;-)

Peter

von W.S. (Gast)


Lesenswert?

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.

von Peter S. (petersieg)


Lesenswert?

@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

von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Peter Sieg (Gast)


Lesenswert?

@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

von Ein_Mitnutzer (Gast)


Lesenswert?

Hallo W.S.


kann es sein, daß deine " LernBettyPacked_R0.02.zip " fehlerhaft gepackt 
ist?
Es wird beim Auspacken immer Diskette 2 verlangt....


Danke

von Siegfried W. (swausd)


Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von Ein_Mitnutzer (Gast)


Lesenswert?

Danke,
Habe Download nochmal probiert.
Jetzt ist alles i.O.

Viele Grüße

von Peter Sieg (Gast)


Lesenswert?

@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

von Bobby B. (mdabob)


Lesenswert?

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

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Peter Sieg (Gast)


Lesenswert?

@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

von Siegfried W. (swausd)


Lesenswert?

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

von Peter Sieg (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Peter S. (petersieg)


Lesenswert?

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

von Siegfried W. (swausd)


Lesenswert?

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

von Peter S. (petersieg)


Lesenswert?

@Siegfried: Doch.. von Zeit zu Zeit ein Full ZIP ist nicht verkehrt.

Um den Forumsplatz machen ich mir da keine Sorgen..

Peter

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von W.S. (Gast)


Lesenswert?

Ä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.

von Peter S. (petersieg)


Lesenswert?

@Siegfried: Danke. Make einwandfrei durchgelaufen. Base+Sokoban 
geflasht.
Nettes Mädel beim Einschalten/Reset ;-)

Peter

von Peter S. (petersieg)


Lesenswert?

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

von Peter S. (petersieg)


Angehängte Dateien:

Lesenswert?

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

von Peter S. (petersieg)


Angehängte Dateien:

Lesenswert?

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

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Heureka!

anbei die Version 0.03
und ähem.. Peters Probleme waren auch meine. Sch... Pointerarithmetik, 
ich Dussel.

W,S,

von Siegfried W. (swausd)


Angehängte Dateien:

Lesenswert?

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

von Peter S. (petersieg)


Lesenswert?

@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

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

So, ich hab Siegfrieds Anhang eingearbeitet und das Ganze in der 
Codesammlung gepostet.

W.S.

von Manni (Gast)


Lesenswert?

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.

von Siegfried W. (swausd)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Siegfried W. (swausd)


Lesenswert?

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

von Peter S. (petersieg)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Bobby B. (mdabob)


Angehängte Dateien:

Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Bobby B. (mdabob)


Lesenswert?

@ W.S.

Vielen Dank,  habe die Dokumentationen wirklich noch nicht vollständig 
gelesen....


Bobby

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von martin (Gast)


Lesenswert?

Najaa. -fPIC gibts ja auch.

von gruetzkopf (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Max H. (maexlich)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Roland H. (batchman)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Frank (Gast)


Lesenswert?

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

von Peter S. (petersieg)


Angehängte Dateien:

Lesenswert?

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

von Winnyboy (Gast)


Lesenswert?

Hallo Leute, wer kann mir eine neue Betty FB zu normaler FB 
umprogrammieren
kostenlos. Versandkosten klar gehen zu meinen lasten.
Danke mal im voraus.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Winnyboy schrieb:
> Hallo Leute, wer kann mir eine neue Betty FB zu normaler FB
> umprogrammieren
> kostenlos.

Das solltest du mal erklären. Es gibt für die Betty nur 2 Möglichkeiten: 
Entweder spielt man die letzte Firmware der Originalhersteller ein und 
hat dann einen lernfähige Fernbedienung für 4 Geräte oder man spielt 
Boop ein und hat dann eine lernfähige Fernbedienung mit den zusätzlichen 
Spässchen von Boop, wie dem Funkscanner Teil.
Die Jungs hier machen as anderes, sie machen aus der Betty eine ARM 
Spielwiese für den LPC2200 - das hat nur wenig mit der Eigenschaft als 
Fernbedienung zu tun.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.