www.mikrocontroller.net

Forum: Compiler & IDEs WinARM/CodeSourcry Startup/Linkerscipt Fragen


Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe ARM-Gemeinde,

möchte mich in die ARM-Welt einarbiten, nachdem ich schon einiges mit 
den AVRs und WinAVR gemacht habe. Soll erstmal nur 'ne Art Fortbildung 
sein.

Habe zu Hause ein kleines Modul von TaskIt mit einem AT91SAM7S256 drauf. 
Habe leider noch keinen JTAG Debugger, aber es ist ja der Bootloader 
drauf. Für erste "Gehversuche" reicht es. Habe ein Testprogramm mit 
SAM-BA laden können.

Nun zu meinem Problem: Habe ziemlich viel Suchmaschinen benutzt, aber 
bin aber es hat nicht geholfen :-( Das Testprogramm war eines aus der 
WinARM Toolchain von Martin Thomas (vielen Dank für die Toolchain 
Martin).
Ich würde aber gerne die CodeSourcery Lite Version verwenden, weil die 
den Cortex-M3 unterstützt.
Mir ist es nicht gelungen, ein kleines Programm zum laufen zu bekommen, 
weil mir folgendes nicht ganz klar ist:

1) Startup-Code: Laut Doku von CS gibt es einen Assemblerteil und danach 
läüft noch ein C-Teil für die Startup Sequenz ab. Von dem C-Teil geht es 
ab ins main(). Ich habe weder den C-Teil noch den Assemblerteil als 
Source gefunden. Wird der automatisch dazugelinkt? Sprich der Linker 
weiß es? Kann ich mir schwer vorstellen, da ja die Hardware 
unterschiedlich sein kann. Wo finde ich evtl. Beispiele dafür? Hat 
jemand soetwas?
Weiß jemand, wo das für CS dokumentiert ist, eine Startupsequenz zu 
schreiben? Ich habe nichts brauchbares gefunden.

2) Linkerscripte sind bei CS dabei für bestimmte Boards. Wenn ich das 
richtig sehe, ist da keines für einen AT91SAM7xxx dabei. Und die 
CS-"general" Linkerscripte sind so vollgestopft, dass ich echt nicht 
durchblicke. Kenne mich mit den Linkerscripten auch nicht besonders aus.
Hat jemand ein passendes oder ähnliches Script, passend zu meiner CPU?
Oder einen Link wie die soetwas für CS aussehen muß?

3) Frage zum Luminary LM3S6965 Evaluation Board
Dort ist eine JTAG-Schnittstelle drauf, mit der man auch externe ARMs 
debuggen kann. Laut Luminary auch nur Luminary-CPUs. Kann ich mir schwer 
vorstellen. Aber vorsichtshalber meine Frage, kann ich dieses EVAL-Board 
auch als JTAG Debugger/Programmer für beliebiege ARM und/oder Cortex-M3 
benutzen? Hat das jemand schon so benutzt und es geht ohne 
Einschränkungen? Funktioniert es mit OpenOCD?

4) Letzte Frage: Wenn ich nur den Bootloader verwende, kann ich diesen 
entweder mit meinem Testprogramm überschreiben (ist blöd) oder geht es 
evtl. auch, ein einfaches Testprogramm so zu schreiben, dass man es für 
das RAM linkt, dorthin hinter den Bootloader lädt und dann startet? Der 
Bootloader hat ja einen "GO"-Befehl. Z.B wegen den Interruptvektoren 
stelle ich mir das schwer vor. Oder weiß jemand, wie das geht?

Danke für Eure Hilfe.
Gruß Joachim

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe wrote:
> Hallo liebe ARM-Gemeinde,
>
> möchte mich in die ARM-Welt einarbiten, nachdem ich schon einiges mit
> den AVRs und WinAVR gemacht habe. Soll erstmal nur 'ne Art Fortbildung
> sein.
>
> Habe zu Hause ein kleines Modul von TaskIt mit einem AT91SAM7S256 drauf.
> Habe leider noch keinen JTAG Debugger, aber es ist ja der Bootloader
> drauf. Für erste "Gehversuche" reicht es. Habe ein Testprogramm mit
> SAM-BA laden können.
>
> Nun zu meinem Problem: Habe ziemlich viel Suchmaschinen benutzt, aber
> bin aber es hat nicht geholfen :-( Das Testprogramm war eines aus der
> WinARM Toolchain von Martin Thomas (vielen Dank für die Toolchain
> Martin).
Freut mich, dass mein Zeug hilfreich ist. Leider komme ich nicht dazu, 
dass Ganze mal auf neuesten Stand zu bringen. Einige Beispiele sind 
nicht wirklich toll. Betr. Toolchain wurde ja schon eine moderne 
Alternative gefunden.

> Ich würde aber gerne die CodeSourcery Lite Version verwenden, weil die
> den Cortex-M3 unterstützt.
CS lite nutze ich inzwischen auch meistens. Ist schon eine gute Wahl, da 
CS von ARM dafür bezahlt wird, die GNU Tools zu verbessern. Die Leute 
von CS kennen sich gut aus.

> Mir ist es nicht gelungen, ein kleines Programm zum laufen zu bekommen,
> weil mir folgendes nicht ganz klar ist:
>
> 1) Startup-Code: Laut Doku von CS gibt es einen Assemblerteil und danach
> läüft noch ein C-Teil für die Startup Sequenz ab. Von dem C-Teil geht es
> ab ins main(). Ich habe weder den C-Teil noch den Assemblerteil als
> Source gefunden. Wird der automatisch dazugelinkt? Sprich der Linker
> weiß es? Kann ich mir schwer vorstellen, da ja die Hardware
> unterschiedlich sein kann. Wo finde ich evtl. Beispiele dafür? Hat
> jemand soetwas?
> Weiß jemand, wo das für CS dokumentiert ist, eine Startupsequenz zu
> schreiben? Ich habe nichts brauchbares gefunden.

Die Fragen betreffen wohl CS3. Das muss man nicht benutzen, zumindest 
habe ich es selbst noch nie benutzt, obwohl ich das Toolchain-Paket von 
CS verwende. Man kann analog zu den Beispielen für andere Pakete 
Linker-Script und Startup-Code "von Hand" vorgeben. CS3 ist, soweit ich 
das nachvollziehen kann, nicht viel mehr als der Versuch eine Art 
Standard für Linker-Scripte und Startup-Code zu definieren, der 
möglichst unabhängig vom Zielcontroller ist. An sich eine gute Idee für 
Leute, die sich nicht mit eigenem Startup-Code und Linker-Skripten 
kasteien wollen.

> 2) Linkerscripte sind bei CS dabei für bestimmte Boards. Wenn ich das
> richtig sehe, ist da keines für einen AT91SAM7xxx dabei. Und die
> CS-"general" Linkerscripte sind so vollgestopft, dass ich echt nicht
> durchblicke. Kenne mich mit den Linkerscripten auch nicht besonders aus.
> Hat jemand ein passendes oder ähnliches Script, passend zu meiner CPU?
> Oder einen Link wie die soetwas für CS aussehen muß?

Man kann auch mit CS lite einfache (=nicht "vollgestopfte") 
Linkerscripte nutzen. Es ist schlussendlich immer noch eine "ganz 
normale" GNU-Toolchain mit ein paar extra Dateien. Es fehlen dann aber 
mglw. Definitionen, die von den mitgelieferten Startup-Codes und evtl. 
der libc (Heap-End in sbrk) genutzt werden. Also entweder alles nach 
CS3-"Style" oder eigene Scripte/Startup-Codes verwenden. Mischung dürfte 
mehr Verdruss als Nutzen bringen.

> 3) Frage zum Luminary LM3S6965 Evaluation Board
> Dort ist eine JTAG-Schnittstelle drauf, mit der man auch externe ARMs
> debuggen kann. Laut Luminary auch nur Luminary-CPUs. Kann ich mir schwer
> vorstellen. Aber vorsichtshalber meine Frage, kann ich dieses EVAL-Board
> auch als JTAG Debugger/Programmer für beliebiege ARM und/oder Cortex-M3
> benutzen? Hat das jemand schon so benutzt und es geht ohne
> Einschränkungen? Funktioniert es mit OpenOCD?

Bei den neueren Eval-Boards hat Luminary etwas mehr Aufwand für den 
JTAG-Teil betrieben als bei den alten LM3S811-Boards, wohl auch um das 
Cortex 2-wire Debug-Interface ansprechen zu können. Mit dem alten 
LM3S811 hatte ich erfolgreich AT91SAM7 über OpenOCD "flashen" können 
aber das hat simples FT2232-interface (ohne SRST und TRST). Habe auch 
schon Modifikationen des 811-Boards gesehen, um /SRST vom FT2232 an den 
Connector zu führen. Ob das mit den LM3S69xx-Eval-Boards geht, kann man 
ausprobieren, ist aber den Aufwand eher nicht wert. FT2232 "stand-alone" 
Adapter wie die "kleinen" von z.B. Olimex und Amontec sind recht 
günstig.

> 4) Letzte Frage: Wenn ich nur den Bootloader verwende, kann ich diesen
> entweder mit meinem Testprogramm überschreiben (ist blöd) oder geht es
> evtl. auch, ein einfaches Testprogramm so zu schreiben, dass man es für
> das RAM linkt, dorthin hinter den Bootloader lädt und dann startet? Der
> Bootloader hat ja einen "GO"-Befehl. Z.B wegen den Interruptvektoren
> stelle ich mir das schwer vor. Oder weiß jemand, wie das geht?

Das kann hoffentlich jemand anderes beantworten, habe den 
Atmel-Bootloader/SAM-BA vielleicht zweimal ausprobiert und auch nur zum 
flashen, war mir zu unpraktisch. Es gibt aber alternative Bootloader, 
die einem das 10-sec-Warte-Ritual ersparen und die gewünschte 
Funktionalität bieten sollten aber nicht selbst ausprobiert.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

jetzt mit Anmeldung, heute Nachmittag ging das nicht.

> Freut mich, dass mein Zeug hilfreich ist.
Ich muß nochmal danke sagen. Ohne die WinARM Toolchain wäre ich wohl 
verzweifelt. Ich habe auch schon öfter auf Deine Seite nach Tips 
gegraben zu den AVRs. Mein erster JTAG-ICE war ein Evertool (der 
modifizierte von myevertool). Ich war zu faul, auf Lochraster zu löten 
und bei dem gab es Platinen :-)

> Leider komme ich nicht dazu, dass Ganze mal auf neuesten Stand zu
> bringen.

Nun ja das ist schade, wahrscheinlich auch zu viele Projekte am laufen. 
Bei mir reicht es bis nach der Rente ;-)
Mit WinARM bekommt man immerhin auf Anhieb ein Beispiel zum laufen. :-)

> Einige Beispiele sind nicht wirklich toll. Betr. Toolchain wurde ja
> schon eine moderne Alternative gefunden.

Ich hatte die erst ausgewählt, da Cortex-Unterstützung drin ist. 
Inzwischen hatte ich auch erfahren, dass die Jungs von ARM gesponsert 
werden. Ein paar Beispiele für die CS-Lite Version wären allerdings 
nicht schlecht.

> Die Fragen betreffen wohl CS3. Das muss man nicht benutzen, zumindest
> habe ich es selbst noch nie benutzt, obwohl ich das Toolchain-Paket von
> CS verwende.

Womit wird denn gesteuert ob CS3 verwendet wird? Mit den Linkerscripten 
vermute ich. (?)

> Man kann analog zu den Beispielen für andere Pakete
> Linker-Script und Startup-Code "von Hand" vorgeben.

Ja, soetwas hatte ich schon gesehen, allerdings war ich mir nicht 
sicher, ob es funktioniert, wegen dem CS3 eben.

> CS3....   An sich eine gute Idee für
> Leute, die sich nicht mit eigenem Startup-Code und Linker-Skripten
> kasteien wollen.

Hab ich auch keine Lust zu. Aber nach Lust geht es leider nicht immer 
;-)

> Man kann auch mit CS lite einfache (=nicht "vollgestopfte")
> Linkerscripte nutzen.

Werde ich jetzt versuchen.
Hast du evtl. eine Art "Hello World" für mich?
Mal mein freundlichstes Gesicht aufsetze ;-)

> Ob das mit den LM3S69xx-Eval-Boards geht, kann man
> ausprobieren, ist aber den Aufwand eher nicht wert. FT2232 "stand-alone"
> Adapter wie die "kleinen" von z.B. Olimex und Amontec sind recht
> günstig.

Da ich mir eh einen Cortex-M3 zulegen wollte, dachte ich, da wäre das 
Board von Luminex eine gute Wahl. Dann hab ich das Board und ein JTAG 
zusammen. Ist denke ich etwas günstiger, als beides getrennt zu kaufen.
Hmmm.....

> flashen, war mir zu unpraktisch. Es gibt aber alternative Bootloader,
> die einem das 10-sec-Warte-Ritual ersparen und die gewünschte
> Funktionalität bieten sollten aber nicht selbst ausprobiert.
Hmm... muß wohl nochmal 'n Riemen auf die Suchmaschine werfen ;-)

Ich danke dir soweit für deine Hilfe. Hab mich sehr gefreut :-)

Gruß Joachim

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich nochmal.

[activateBrain]

Nachdem ich ein wenig überlegt hatte, bin ich drauf gekommen, einfach 
den Startup-Code und das Linkerscript zu nehmen und das Makefile so zu 
ändern, dass er die CS-Tools aufruft. Der Linker meckerte, dass er 
_isatty() nicht findet. Nun dass schnell behoben in syscalls.c und ....

HURRA! Jetzt läuft es mit der CS-Toolchain. Bin ja begeistert.
Beispiel war dein "at91sam7s64_Hello".

Habe es für den S256 modifiziert. War ja nicht so schwer. ;-)
Super! Nochmal danke.

Steht nur noch die Entscheidung an, ob ich mir einen extra JTAG kaufe. 
Mal sehen. Bei Amontec nervt mich, dass die Versandkosten so sind, als 
wenn sie einen berittenen Kurier schicken. Hmmm...

Gruß Joachim

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. wrote:
>...
>> Freut mich, dass mein Zeug hilfreich ist.
> Ich muß nochmal danke sagen. Ohne die WinARM Toolchain wäre ich wohl
> verzweifelt. Ich habe auch schon öfter auf Deine Seite nach Tips
> gegraben zu den AVRs. Mein erster JTAG-ICE war ein Evertool (der
> modifizierte von myevertool). Ich war zu faul, auf Lochraster zu löten
> und bei dem gab es Platinen :-)
Hehe, die Evertool-Seite wird immer noch gut besucht. Scheint noch für 
einige nützlich zu sein, v.a. für solche aus Nicht-Wohlstandsstaaten. 
Benutze meine Prototypen schon eine Weile nicht mehr, da inzwischen 
"offizielle" Tools im Werkzeugkoffer und Projekte mit "zu modernen" 
AVRs. Myevertool ist meines Wissens in "Stase".

>> Leider komme ich nicht dazu, dass Ganze mal auf neuesten Stand zu
>> bringen.
> Nun ja das ist schade, wahrscheinlich auch zu viele Projekte am laufen.
Eigentlich nicht. Aber auch auf zu vielen verschiedene "Baustellen" 
tätig Mikrocontroller-"Gebastel" ist nur eine davon.

> Bei mir reicht es bis nach der Rente ;-)
Ist doch prima.

> Mit WinARM bekommt man immerhin auf Anhieb ein Beispiel zum laufen. :-)
Das ist die Idee dahinter, eine Art "Batteries included" angelehnt an 
WinAVR. Ursprünglich aus reinem Eigennutz entstanden, als die anderen 
vorgefertigten Pakete unter Win32 noch die elende cgywin1.dll sehen 
wollten und die libc/newlib nicht so gebaut war, dass newlib-lpc 
funktionierte (achja, welch Freude, als seinerzeit der Timer-Interrupt 
die LED auf dem LPC-P1 blinken lies). Später ist WinARM offensichtlich 
auch für viele andere nützlich geworden, der kleine Server-Rechner 
"raucht" gelegentlich unter der Download-Last, musste den nicht 
unerheblichen Traffic schon - glücklicherweise problemlos - 
rechtfertigen. sf.net wollte mich seinerzeit nicht.

>> Einige Beispiele sind nicht wirklich toll. Betr. Toolchain wurde ja
>> schon eine moderne Alternative gefunden.
>
> Ich hatte die erst ausgewählt, da Cortex-Unterstützung drin ist.
Die Unterstützung durch den Compiler, Assembler, Linker sollte 
inzwischen in allen GCC>=4.2.x/binutils>=2.18 basierten Paketen drin 
sein. Die newlib ist aber meines Wissens erst in den aktuellsten 
Versionen für thumb2 tauglich. Da hat CS vorher schon eigene 
Erweiterungen eingebaut, die es wohl nicht immer zügig "upstream" 
schaffen.

Eine gute Alternative ist noch DevkitARM aber wenn man nicht grade eine 
Heimbrauerei für Spielkonsolen betreibt gibt es keinen wirklichen Grund 
von CS lite dahin zu wechseln. Ausser evtl. noch man ist dogmatischer 
"Open-Sourcer", denn das was-wie-wo ist bei DevkitARM genau 
nachvollziehbar. Bei CS darf man sich die darin gemachten Anpassung 
selbst aus einem friss-oder-stirb Quellcodepacken zusammendiffen, mglw. 
inzwischen schon alles "upstream" in den GNU Quellen. Was vielleicht 
noch wichtig ist: die aktuelle Version von CS (habe ich selbst noch 
nicht installiert) hat wohl Fehler im gdb (arm-none-eabi-gdb), ist aber 
nur Hörensagen aus der OpenOCD mailing-list, evtl. ja schon behoben. 
Alternativ an man die gdb-"exe" aus einer früheren CS Version, DevkitARM 
oder Yagarto nutzen, sollte nur nicht allzu alt sein.

Als weitere Alternative ist noch Anglia SARM/Idealist zu nennen, enthält 
ein paar nette Beispiele für STR7/9/STM32, aus denen man einiges lernen 
kann, auch wenn man Controller anderer Hersteller mit gleichen ARM-cores 
nutzt.

> Inzwischen hatte ich auch erfahren, dass die Jungs von ARM gesponsert
> werden. Ein paar Beispiele für die CS-Lite Version wären allerdings
> nicht schlecht.
Hat sich ja bereit erledigt. Im Grund fängt man einfach damit an, in den 
Makefiles arm-elf- durch arm-none-eabi- zu ersetzen und hangelt sich 
dann weiter.

>> Die Fragen betreffen wohl CS3. Das muss man nicht benutzen, zumindest
>> habe ich es selbst noch nie benutzt, obwohl ich das Toolchain-Paket von
>> CS verwende.
>
> Womit wird denn gesteuert ob CS3 verwendet wird? Mit den Linkerscripten
> vermute ich. (?)
Im Prinzip ja CS3 ist eine Sammlung aus Linker-Scripten, Startup-Code 
und w.r.e. noch specs-Dateien. Eigenes Linker-Skript angeben (-T) 
default startup-files deaktivieren und das sollte CS3 fernhalten aber ja 
schon selbst herausgefunden.

>> Man kann analog zu den Beispielen für andere Pakete
>> Linker-Script und Startup-Code "von Hand" vorgeben.
>
> Ja, soetwas hatte ich schon gesehen, allerdings war ich mir nicht
> sicher, ob es funktioniert, wegen dem CS3 eben.
>
>> CS3....   An sich eine gute Idee für
>> Leute, die sich nicht mit eigenem Startup-Code und Linker-Skripten
>> kasteien wollen.
>
> Hab ich auch keine Lust zu. Aber nach Lust geht es leider nicht immer
> ;-)
Etwas Linker-Skript know-how ist dann wichtig, wenn man etwas exotische 
Sachen bastelt: teile des Programmcodes im RAM, andere im Flash, 
bestimmte Sachen an festgelegten Adressen (Exceptions-Vector, 
Bootloader-Code). Sicher nicht simpel aber auch kein Hexenwerk. Man muss 
das Rad nicht neu erfinden: halbwegs passende Vorlage nehmen, ld-Manual 
lesen, anpassen, probieren, noch mehr lesen. MAP-files und Disassembly 
helfen und ersparen Debug-Sitzungen an der Hardware. Die vergleichbaren 
"Scatter-load-files" der kommerziellen Tools RV und EWARM sind auch 
nicht wirklich simpel - nach "Aktenlage", nie selbst daran Hand 
angelegt.

>> Man kann auch mit CS lite einfache (=nicht "vollgestopfte")
>> Linkerscripte nutzen.
>
> Werde ich jetzt versuchen.
> Hast du evtl. eine Art "Hello World" für mich?
Habe ich irgendwo aber hat sich ja schon erledigt.

> Mal mein freundlichstes Gesicht aufsetze ;-)
>> Ob das mit den LM3S69xx-Eval-Boards geht, kann man
>> ausprobieren, ist aber den Aufwand eher nicht wert. FT2232 "stand-alone"
>> Adapter wie die "kleinen" von z.B. Olimex und Amontec sind recht
>> günstig.
>
> Da ich mir eh einen Cortex-M3 zulegen wollte, dachte ich, da wäre das
> Board von Luminex eine gute Wahl. Dann hab ich das Board und ein JTAG
> zusammen. Ist denke ich etwas günstiger, als beides getrennt zu kaufen.
> Hmmm.....
Habe weiter untern ein wenig Nähkästchengeplauder dazu geschrieben.

>> flashen, war mir zu unpraktisch. Es gibt aber alternative Bootloader,
>> die einem das 10-sec-Warte-Ritual ersparen und die gewünschte
>> Funktionalität bieten sollten aber nicht selbst ausprobiert.
> Hmm... muß wohl nochmal 'n Riemen auf die Suchmaschine werfen ;-)
Jep, findet sich. Im Zweifel nochmal melden, habe zumindest einen 
Bootloadercode irgendwo auf der Transportplatte.

>...
> Nachdem ich ein wenig überlegt hatte, bin ich drauf gekommen, einfach
> den Startup-Code und das Linkerscript zu nehmen und das Makefile so zu
> ändern, dass er die CS-Tools aufruft. Der Linker meckerte, dass er
> _isatty() nicht findet. Nun dass schnell behoben in syscalls.c und ....
Jep, diese isatty-Geschichte kam irgendwann mit einer Umstellung in der 
newlib. Ist nicht CS spezifisch.

> HURRA! Jetzt läuft es mit der CS-Toolchain. Bin ja begeistert.
> Beispiel war dein "at91sam7s64_Hello".
Prima.

> Habe es für den S256 modifiziert. War ja nicht so schwer. ;-)
> Super! Nochmal danke.
Habe ja gar nichts gemacht ;-)

> Steht nur noch die Entscheidung an, ob ich mir einen extra JTAG kaufe.
> Mal sehen. Bei Amontec nervt mich, dass die Versandkosten so sind, als
> wenn sie einen berittenen Kurier schicken. Hmmm...

Zu Amontec JTAGkey/tiny vergleichbare Adapter gibt es in dem Shop, der 
im Menü links verlinkt ist. Die FT2232-basierten Adapter schenken sich 
nicht viel, die Belegung der GPIOs für SRST und TRST variiert und die 
eingesetzten Levelshifter. Von Olimex gibt es noch einen "großen" 
Adapter, bei dem man noch eine DC-Buchse an USB gehängt hat und den 
zweiten Kanal des FT2232 als "seriell-USB-Adapter" nutzen kann, sind 
ganz nette Bonbons aber muss man nicht haben. Von OpenOCD dürften alle 
unterstützt werden, wenn nicht, ist die Anpassung des Quellcodes kein 
Hexenwerk. Habe allerdings auf Basis FT2232 nur einen JTAGkey, ein von 
einem Dritten selbstgebautes Teil und das LM3S811 Eval-board, kann also 
zu den anderen keine Erfahrungsberichte liefern. OpenOCD unterstützt 
derzeit aber noch nicht SWD für z.B. Cortex M3. Wenn richtig erinnert, 
sind im CS-Packet aber "closed-source" GDB-server für LMI-Boards dabei. 
Nennen sich debug-sprites o.ä., viel mehr kann ich dazu aber auch nicht 
schreiben, da bis dato nicht selbst ausprobiert, das "große" LMI 
Ethernet/CAN board  hat es aus Zeitmangel immer noch nicht auf den 
Basteltisch geschafft.

Hoppla, schon wieder längliche Ausführungen mit Plappertendenz getippst, 
hoffe, zumindest irgend etwas dazwischen ist auch nützlich.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey man, brauchst du keinen Schlaf? Um die Uhrzeit hier posten, das 
nenne ich Einsatz :-)

Martin Thomas wrote:
> Hoppla, schon wieder längliche Ausführungen mit Plappertendenz getippst,
> hoffe, zumindest irgend etwas dazwischen ist auch nützlich.

Klaro ist was nützliches dabei.
Also wenn du mich fragst, manchmal ist der Verbose-Mode auch ganz
nett ;-) Passiert mir auch gerne mal. :-)
Macht natürlich das finden von Infos für andere geneigte Leser etwas 
schwierig.

Danke nochmal für deine Tips und Hinweise. Werde mal sehen, wie ich 
weiter komme. Wenn nicht, dann melde ich mich.

Gruß Joachim

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.