mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM, Luminary, JTAG Frage


Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo !

Hab mir für den Einstieg in die ARM-Welt (genauer gesagt Cortex-M3) ein 
Evaluation Board von Luminary (EKK-LM3S6965) gekauft. Komm mit der 
Programmierung so weit auch gut zurecht. (Beruflich arbeite ich mit 
M16C, früher 8051)

Hab jetzt aber doch ein paar Fragen zu den Luminary-Teilen:

*) Im User-Manual des Boards steht, dass es über die JTAG Schnittstelle 
andere Luminary Micros programmieren/debuggen kann.
Leider finde ich da keine wirklich konkreten Informationen. Wie muss ich 
das verstehen ?
Kann ich einen eigenen Controller über JTAG am EV-Board anschliessen und 
dann in den Entwicklungsumgebungen (Keil/Crossworks) transparent mit 
diesen arbeiten ? D.h. kann ich dann einfach den Target Treiber von 
Luminary auswählen um über das EV-Board (über USB am Computer 
angeschlossen) meine eigene Hardware programmieren zu können ?

*) Was ist der Unterschied zwischen JTAG und diesem SWD ? Hab da bis 
jetzt nur herausgefunden, dass SWD weniger Pins benötigt.

*) Gibt es eine Möglichkeit, eine eigene Hardware (ohne der CPLD-Logik 
vom EV-Board) so aufzubauen, dass ich über den Luminary Treiber per USB 
in Keil/Crossworks damit arbeiten kann ? D.h. nur mit einem FT2232 und 
eventuell ein paar Logikgattern.
Wäre nämlich toll, wenn ich für die Anfänge keinen eigenen JTAG-Adapter 
brauchen würde.

Besten Dank und schöne Grüße,
Thomas

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe dunkel in Erinnerung, dass diese Erleuchteten mit integriertem 
Bootloader daherkommen. Damit wäre dann JTAG nicht zwingend.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja gut, aber das ist dann ja nur zum Programmieren und nicht zum 
Debuggen geeignet, oder ?!

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt drauf an, wie du üblicherweise zu debuggen pflegst. Mir sind 
JTAG-Debugger meist zu umständlich. Es gibt Fälle, wo sie nützlich sind, 
aber i.d.R. reicht mir eine serielle Ausgabe aus, plus ein paar LEDs 
wenn's zeitkritisch ist. Egal ob ARM oder AVR.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas B.
1. & 3.
Ein externer Controller wird automatisch erkannt, sobald man ihn 
angesteckt hat. Die Debug Out LED leuchtet dann. (DB Abschnitt 
Debugging)
Die Logik ist nur zum Umschalten des JTAG-Interfaces gedacht. Daher 
müsste man auch ein abgespecktes JTAG-Interface ohne die Logik bauen 
können. Der FT2232 muss dann nur mit den Luminary IDs programmiert 
werden, damit er auch vom Treiber als Luminary Gerät erkannt wird.

2.
http://www.arm.com/products/solutions/SWD.html

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach naja, ich hab das "Anhalten und Reinschauen" beim Debuggen gerade 
bei größeren oder komplexeren Programmen doch sehr zu schätzen gelernt.
Debug-Ausgaben über die serielle Schnittstelle verwende ich aber auch.

D.h. wenn die Möglichkeit da ist, würde ich das schon auch gern nutzen.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leutz,

der JTAG OUT ist wirklich nur ein jtag out; d.h. wenn es funktioniert 
kann man damit nur andere devices programmieren.
Das Doard, auf dem der JTAG Anschluss drauf ist, lässt sich damit weder 
debuggen noch programmieren.

Standard JTAG hat eine Hand voll Pins. SWD steht für Serial Wire Debug, 
und ist eine Art "Zusammenfassung" einiger JTAG Pins auf eine Leitung.

Tipp: Immer das Luminary Unlock Tool zur Hand haben (geht erst ab Chip 
Rev.C) :-)


VG,
/th.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Random ... wrote:
> der JTAG OUT ist wirklich nur ein jtag out; d.h. wenn es funktioniert
> kann man damit nur andere devices programmieren.
> Das Doard, auf dem der JTAG Anschluss drauf ist, lässt sich damit weder
> debuggen noch programmieren.

Was meinst Du damit genau?
Über den USB-Anschluss auf dem LMI Board kann man den Controller auf dem 
Board selbst auch debuggen...

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lt. Auskunft vom Techn. Support von LMI kann man mit dem JTAG OUT auf 
dem kleinen Lumi EK das Board selbst nicht debuggen oder proggen.
Ich wäre da lieber mit dem uLINK drangegangen, aber das Board lässt sich 
nur über den FTDI JTAG proggen.


VG,
/th.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches LMI Board ist denn für dich klein?
Also bei dem EK-LM3S811 geht das genauso und ein kleineres kenne ich 
nicht.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Random
Also im UserManual zum LM3S9665 Kit steht, dass mit dem Board 3 
Varianten funktionieren: "Internal ICDI" (über USB), "ICDI out to 
JTAG/SWD" (das Board arbeitet als externer Debugger) und "In from 
JTAG/SWD" (mit ULink, JLink usw.).

Was du vielleicht meinst: der Controller des EV-Board ist während der 
Verwendung als Debugger nicht ansprechbar.

Das Unlock-Tool hab ich allerdings auch schon verwenden müssen. Weiß 
aber nicht genau was ich gemacht habe, da es nach dem Einspielen eines 
mitgelieferten Demo-Files passierte.
Weil du das so explizit schreibst: Tritt das nur bei Verwendung des 
SWD-Interfaces auf ??

@ Andreas Watterott
Du meinst also, dass der CPLD nur zum Umschalten zwischen internem 
Debuggen und externem Debug-Modus verwendet wird ? Also Umschalten 
zwischen "Internal ICDI" und "ICDI out to JTAG/SWD" ?

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ist es. Am Ende des DB vom EK-LM3S6965 ist auch ein Schaltplan.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja den Schaltplan hatte ich schon gesehen. Nur kann ich so auf Anhieb 
aus dem Schaltplan der CPLD-Logik nicht herauslesen was das Teil wann 
macht. (Die Schaltung an sich ist mir klar, nur müsste ich dazu wohl 
wissen wie genau das JTAG-Protokoll arbeitet).

Besten Dank !

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas B. wrote:
> @Random
> Also im UserManual zum LM3S9665 Kit steht, dass mit dem Board 3
> Varianten funktionieren: "Internal ICDI" (über USB), "ICDI out to
> JTAG/SWD" (das Board arbeitet als externer Debugger) und "In from
> JTAG/SWD" (mit ULink, JLink usw.).
Oki, ich meinte das LM3S811 EK Kit. Die Variante von vor ca. 1,5J (ich 
weiss nciht, wie es jetzt ist) konnte man tatsächlich per JTAG nciht 
proggen/debuggen, das war nur ein JTAG OUT.


> Was du vielleicht meinst: der Controller des EV-Board ist während der
> Verwendung als Debugger nicht ansprechbar.
s.o.


> Das Unlock-Tool hab ich allerdings auch schon verwenden müssen. Weiß
> aber nicht genau was ich gemacht habe, da es nach dem Einspielen eines
> mitgelieferten Demo-Files passierte.
Ich hab mit div. Kits gearbeitet (Vom DEV-Board über EKs), und auch 
meine DA damit gemacht. Hatte viele Probleme. Dank des guten Support 
sind wohl die Probs, die ich hatte, mit in die Rev.C eingeflossen, da 
mittlerweile verschiedene Unlock-Verfahren existieren (LMI Flash Tool 
hat zwei Gruppen von Devices, und je nachdem welche man auswählt 
versucht der auf verschiedene Arten, den Core wieder zu erreichen).
Es kommt (öfters) vor, dass sich der Controller beim Proggen scheinbar 
verschluckt und dann nciht mehr erreichbar ist. Wenn das Unlock-Tool 
hilft, super, wenn nicht, --> Tonne. Rev.B: --> Tonne.
Dabei ist es egal, ob man eine Demo verwendet, oder eigenen Code 
schreibt.

Achtung:
Nicht ansprechbar per JTAG / USB wird der Core, wenn man die JTAG Pins 
als GPIO konfiguriert, das ist aber bei allen so.
Vertut man sich im Clock Tree (z.B. durch schreiben eines 
Null-Dividers), dann hilft auch das Unlock Tool nicht mehr (Stand: vor 
einem Jahr, Rev.C).


> Weil du das so explizit schreibst: Tritt das nur bei Verwendung des
> SWD-Interfaces auf ??
Egal.



> @ Andreas Watterott
> Du meinst also, dass der CPLD nur zum Umschalten zwischen internem
> Debuggen und externem Debug-Modus verwendet wird ? Also Umschalten
> zwischen "Internal ICDI" und "ICDI out to JTAG/SWD" ?
Das mit dem CPLD kenne ich noch nicht, das ist neu. Ist auf den alten 
LM3S811 EKs nicht drauf.



VG,
/r.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Random ... wrote:
> Oki, ich meinte das LM3S811 EK Kit. Die Variante von vor ca. 1,5J (ich
> weiss nciht, wie es jetzt ist) konnte man tatsächlich per JTAG nciht
> proggen/debuggen, das war nur ein JTAG OUT.

Du meinst wahrscheinlich, dass man keinen externen JTAG-Adapter an das 
Board anschließen kann. -> Das Board hat keinen JTAG-Eingang.
Der FT2232 kann aber entweder den onboard Controller oder einen externen 
MCU debuggen. Ansonsten könnte man den Controller auf dem Kit ja nie 
über JTAG erreichen.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Random
Hm, dass man ab und zu das Unlock-Tool benötigt hatte ich schon gelesen, 
aber dass man den Controller dauerhaft aussperren kann wusste ich nicht.
Ist dir das passiert ?

Ich denke, dass ich die Revision C habe (wegen dem Display), allerdings 
steht auf der Rückseite "EK-LM3S6965-D" was mich auf eine Revision D 
schliessen lassen würde - wenn es sie offiziell geben würde.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> *) Gibt es eine Möglichkeit, eine eigene Hardware (ohne der CPLD-Logik
> vom EV-Board) so aufzubauen, dass ich über den Luminary Treiber per USB
> in Keil/Crossworks damit arbeiten kann ? D.h. nur mit einem FT2232 und
> eventuell ein paar Logikgattern.
> Wäre nämlich toll, wenn ich für die Anfänge keinen eigenen JTAG-Adapter
> brauchen würde.

Die Geschichte mit dem FTDI nennt sich OPEN-OCD. Ist für's Hobby nicht 
schlecht, aber relativ langsam im Vergleich zum ULINK-II oder anderen 
JTAG Adapter der gehobenen Preisklasse. Ausserdem ist das ein Level 
Shifter drin, der die Schaltung und den JTAG elektrisch trennt, so dass 
man normalerweise nur den Level Shifter killt, wenn hardwareseitig was 
schief geht.

Es gibnt ausserdem im Zusammenhang mit STM32 Evalboards einen ULINK in 
der "light" Ausführung für ca. 100 Euro (zzgl. Evalboard). Das Teil hat 
zwar keinen Level Shifter, soll aber laut Keil den vollen 
Funktionsumfang (Geschwindigkeit, Debug, ..) haben. Hab aber noch keine 
Erfahrungen dazu gesammelt. Vielleicht hab ich mal in den nächsten 
Wochen so ein Teil hier rumliegen.... Dann kann ich mal einen 
Erfahrungsbericht liefern, da ich das bisher nur auf der Embedded World 
gesehen hab.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo merkt man eigentlich den Geschwidigkeitsunterschied bei JTAG? Ich 
habe das bisher nur an der längeren Flashdauer bemerkt.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hm, dass man ab und zu das Unlock-Tool benötigt hatte ich schon gelesen,
> aber dass man den Controller dauerhaft aussperren kann wusste ich nicht.
> Ist dir das passiert ?
Mit meinem ersten (LM3S811, DEV-Kit) funzte das eigentlich sehr gut mit 
dem ULINK und µVision. Ich hatte nur Probleme, weil die Sachen neu waren 
und ich ebenfalls in der Materie ARM neu war. Scvhwirigkeiten bereitete 
mit die komische Driverlib mit n-stufigen #defines, und ein paar 
Programmierkonzepte.

Auf der Elektronica, wo mein System lief, wurde der Core am letzten Tag 
durch unsachgemässe Handhabung "gelockt" (ich war an diesem Tag nicht 
auf der Messe). KA, elektrostatische Aufladung oder so ...
Jedenfalls lief die Software noch, aber kein JTAG/SWD access möglich.

Auf diese Art sind auf der Embedded noch zwei weitere Lumis 828 
"gestorben". Lock-out, aber Soft lief.
Alles Rev.B.

Weitere Probleme gabs bei der Umsetzung zwischen den Revisionen B und C. 
Undokumentiert war, dass die Clocks nach dem Einschalten eines 
Peripherals erst ne Weile brauchen. Das war in der riverlib implizit in 
den funktionsaufrufen/returns versteckt, also ungefähr (Pseudocode!):
setClockEnable(UART0);
setUart0(57600, 8, 'n', 1);
Der Rücksprung von der setClockEn und der Einsprung in die setUart 
reichten aus, dass sich die Clocks einschwangen.
Machte man das über Registerprogrammierung (mein Favorit), dann ging das 
ab Rev.C schief und führte zu einem Hard Fault (Hardware nicht da). KA, 
warum das beim Rev.B funktioniert hat.

An sowas bitte denken!!!

Z.B. macht es hier sinn (wenn man den UART im Griff hat), sich ein paar 
"Bluescreens" einzubauen:
// Debug!
void hardfault_handler(void)
{
  printf("\nHard Fault!");
  while(1);
}

void busfault_handler(void)
{
  printf("\nBus Fault!");
  while(1);
}

void usagefault_handler(void)
{
  printf("\nUsage Fault!");
  while(1);
}
Die Namen müssen nur mit denen in der Interrupt-Vectortable 
übereinstimmen. Printf-retargeting über fputc reicht aus.


> Ich denke, dass ich die Revision C habe (wegen dem Display), allerdings
> steht auf der Rückseite "EK-LM3S6965-D" was mich auf eine Revision D
> schliessen lassen würde - wenn es sie offiziell geben würde.
Rev.B gibt es (sollte man nciht mehr verwenden) und Rev.C (nummer).
http://www.luminarymicro.com/home/errata.html

Mit der Rev.C sind die mittlerweile um einiges besser geworden, zumal 
ein paar Rettungsanker für den Core mit eingebaut wurden.

Bei der Rev.C hatte ich aber dauernd das Problem, was auch schon oben 
geschildert wurde, dass sich der Core trotz richtiger Software "lockt". 
Hier sollte das Unlock-Tool aber helfen.


Mein persönliches Fazit:
Der µC ist vom Konzept her sehr schön, mit interessanten Peripherals 
versehen und hat auch - wenn man sich erst mal eingearbeitet hat - ein 
nettes Programmiermodell.
Allerdings habe ich zu viele Probleme gehabt, was den µC leider erst mal 
wieder zurückstellt...


> Die Geschichte mit dem FTDI nennt sich OPEN-OCD. Ist für's Hobby nicht
> schlecht, aber relativ langsam im Vergleich zum ULINK-II oder anderen
> JTAG Adapter der gehobenen Preisklasse. Ausserdem ist das ein Level
> Shifter drin, der die Schaltung und den JTAG elektrisch trennt, so dass
> man normalerweise nur den Level Shifter killt, wenn hardwareseitig was
> schief geht.
Jap, ich hatte das Glück, von Anfang an mit ULINK(2) unterwegs zu sein, 
und habe den ebenfalls zu hause (z.B. für's AT91SAM7X-Kit).

Der ULINK / ULINK2 von Keil in Verbindung mit µVision ist eine sehr 
schöne, einfache Möglichkeit, einen Core kennenzulernen. Allerdings hat 
das auch seinen Preis, der für Hobbyisten sicherlich nicht immer in 
Frage kommt. Trotzdem: Wer sich so ein Dingen zulegt, hat was gutes 
(eigene Erfahrung, jetzt seit 2 Jahren).



> Es gibnt ausserdem im Zusammenhang mit STM32 Evalboards einen ULINK in
> der "light" Ausführung für ca. 100 Euro (zzgl. Evalboard). Das Teil hat
> zwar keinen Level Shifter, soll aber laut Keil den vollen
> Funktionsumfang (Geschwindigkeit, Debug, ..) haben.

Der ULINK ME ist seit ca. einem Jahr erhältlich, und wesentlich 
günstiger als sein grosser Bruder.
Es ist eine etwas abgespeckte Variante des grossen ULINK2. Der 
Levelshifter  wurde weggelassen, und die Möglichkeiten auf ARM basierte 
µCs beschränkt.
Man kann damit alle ARM basierten µCs per JTAG/SWD programmieren und 
debuggen, Breakpoints, Watches, Register anschauen funktionieren 
ebenfalls.


> Hab aber noch keine
> Erfahrungen dazu gesammelt. Vielleicht hab ich mal in den nächsten
> Wochen so ein Teil hier rumliegen.... Dann kann ich mal einen
> Erfahrungsbericht liefern, da ich das bisher nur auf der Embedded World
> gesehen hab.
Funktioniert - wieg gesagt - genau so wie der ULINK2, nur halt ohne 
Levelshifter.


Die STM32-Boards sind übrigends sehr zu empfehlen. Hab da eins von 
bekommen und war sofort gefesselt. Sehr schönes Programmiermodell, keine 
Probleme mit Lockouts etc. Clock Tree/PLL lässt sich auch einfacher 
"bedienen".



VG,
/r.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Random
Im Datasheet vom LM3S6965 gibts auf Seite 57 eine Vorgehensweise zum 
Unlocken des Controllers - vermutlich genau das, was das Unlocker Tool 
vom LMI Flasher macht.
Hier wird das aber so dargestellt, dass es zwar passieren kann, dass der 
Controller gelockt wird, aber dass er immer wieder "zurückgeholt" werden 
kann.

Aber Danke für die Tipps ! Sowas findet man ja leider selten in den 
Datenblättern.

Ich nehme mal an, dass man den ULINK-ME nicht einzeln sondern nur im 
Bundel mit einem Kit bekommt, oder ? Hab jetzt etwas gesucht aber nur 
die EV/Starter-Kits gefunden.
Bei Digikey kostet das ST32-Kit STM3210B-SK/KEIL 253 Euro und das 
MCB2103UME 173 Euro, und das ist mir jetzt für den Einstieg doch etwas 
zu viel (da ich ja nur gern den ULINK-ME hätte).

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas B. wrote:
> @Random
> Im Datasheet vom LM3S6965 gibts auf Seite 57 eine Vorgehensweise zum
> Unlocken des Controllers - vermutlich genau das, was das Unlocker Tool
> vom LMI Flasher macht.
Hmmm ... kenne ich noch nciht, ist neu. Ich hab seit nem Jahr nix mehr 
mit den Dingern gemacht ;-)
Gleich mal nachsehen...


> Hier wird das aber so dargestellt, dass es zwar passieren kann, dass der
> Controller gelockt wird, aber dass er immer wieder "zurückgeholt" werden
> kann.
Nein, mit dem Clock Tree kann man den dauerhaft totsetzen:
Ich hab - im Nachhinein dumm - gedacht, dass ich mit "null" im Prescaler 
diesen ausser Funktion setze. Allerdings muss da ein Wert >= "1" rein, 
und der MUX bekommt die "null".
Da der Prescaler mit div/0 nix anzufangen wusste war der Core damit 
"totally scrwewd up" g
Unrettbarer Fall für die Tonne in so einem Fall. Von daher gehe ich beim 
Lumi auch nur ungern an den Clock Tree.


> Aber Danke für die Tipps ! Sowas findet man ja leider selten in den
> Datenblättern.
Jap, it took me much time to find out :-(
Hatte zeitweise nen Eimer danebenstehen zum ko**** :-)
Durch Zufall hab ich das dann rausgefunden, das in der DriverLib ein 
verstecktes Timing drin ist.


> Ich nehme mal an, dass man den ULINK-ME nicht einzeln sondern nur im
> Bundel mit einem Kit bekommt, oder ? Hab jetzt etwas gesucht aber nur
> die EV/Starter-Kits gefunden.
Eine nette Mail an Keil und ich denke er macht dir nen Angebot :-)


> Bei Digikey kostet das ST32-Kit STM3210B-SK/KEIL 253 Euro und das
> MCB2103UME 173 Euro, und das ist mir jetzt für den Einstieg doch etwas
> zu viel (da ich ja nur gern den ULINK-ME hätte).

Schreib ne Mail an Keil und bitte um ein Angebot. Ich denke er macht dir 
(ev. auch im Bundle mit einem STM32) ein nettes Angebot, wenns für deine 
privaten Basteleien ist.


Anmerkung:
Ich denke mittlerweile sind die Lumisachen einigermassen aus den 
Anfangsproblemen raus. Ich war zwar derbe am fluchen über diese Dinger, 
trotzdem sind sie vom Prinzip her nett zu programmieren und haben einige 
interessante peripherals.
Vielleicht lege ich mir in nem Jahr mal wieder ein DEV-Kit zu...


Weiter bin ich mal gespannt, was von den anderen Firmen noch kommt. LMI 
war ja das "Startup" des Cortex-M3.

Die Implementierung von STM funktioniert sehr gut bisher, keine Probleme 
mit gehabt (wenn auch in der GPIO-Programmierung etwas sonderbar, aber 
dafür hab ich hier im Forum mal ein Mini-Tutorial gemacht).
Beitrag "STM32 alias cortex m3 brauchbar?"

Mal schauen, ob und was von Atmel, NXP usw. (also die anderen Hersteller 
von General Purpose µCs) noch so schönes kommt.



VG,
/r.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tipp mit Keil, werd denen eine Mail schreiben und 
erwähnen, dass ich Student bin (zwar im Endstadium, neben Arbeit DA), 
aber doch.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was machste als DA?

VG,
/r.

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, im Hauptteil der Arbeit gehts um ein Bedienterminal (Basis ist 
hier ein fertiges ARM9-Modul auf dem ich ein Linux laufen lasse), 
Implementierung des PTP-Stacks und Verteilung der Zeit über ein 
Wireless-Netzwerk (eigene Anpassung des MiWi-Stacks von Microchip). 
Zusätzlich fliesst auch ein Projekt ein, an dem ich vor der DA 
gearbeitet habe.
Die Arbeit ist also relativ breit gefächert (mehrere Platinen 
entwickeln, Softwareentwicklung, usw), macht aber Spaß. Vor allem weil 
ich ja beruflich schon einige Jahre in dem Bereich zu tun habe und daher 
nicht irgendwo frustriert an "Anfängerproblemen" hängenbleibe.

Die Luminary's bzw. konkret die ARMs schau ich mir aber rein privat an, 
brauch ich an sich für die DA nicht. Beim ARM9 Modul beschränkt sich 
(nach der Konfiguration) die Tätigkeit ja auf Anwendungsprogrammierung 
(die am PC stattfindet). Deswegen habe/brauche ich dazu auch keinen 
JTAG-Debugger.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuch, ein gutes Angebot von Keil für's MCBSTM mit ULINK ME zu 
bekommen. Da wirste einiges an Spass mit haben. Ich hab mich da 
mittlerweile ziemlich gut drin eingearbeitet.


VG,
/r.

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.