Forum: Mikrocontroller und Digitale Elektronik avrdude und Xmega


von Jones (Gast)


Lesenswert?

Hi, ich konnte leider noch nix finden. Kann avrdude schon die Xmega 
programmieren? Oder wie kann man das sonst wenn man Linux hat?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jones wrote:

> Kann avrdude schon die Xmega
> programmieren?

Die CVS-Version kann es, aber bislang nur mit einem STK600 im PDI-Mode.
JTAG-Mode könnte vielleicht in Kürze mal folgen (sowie ich Zeit dafür
finde), der müsste dann auch mit einem JTAG ICE mkII gehen (sofern es
aktuelle Firmware hat).

Klassische ISP-Adapter können mit dem PDI-Mode nicht mehr benutzt
werden, da er völlig anders funktioniert.  Da das Ganze mehr oder
weniger eine Highspeed-USART ist, denke ich nicht, dass man mit
einem Bitbang-Adapter irgendeine Chance hat, sondern man braucht
schon etwas auf Basis eines abgesetzten Controllers.  Inwiefern der
AVRISPmkII das mit aktueller Firmware bereits beherrscht, weiß ich
nicht.  Wenn er es mal tut, wäre zu hoffen, dass er sich so wie ein
STK600 benimmt, dann müsste der Support ins AVRDUDE relativ schnell
nachrüstbar sein.

von Jones (Gast)


Lesenswert?

Dh bisher kann man die Xmega nur mit dem STK600 programmieren? Oi. Und 
wie weit ist der avr-gcc?

Muss mir mal die Datenblätter in Ruhe anschauen

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jones wrote:
> Dh bisher kann man die Xmega nur mit dem STK600 programmieren?

Ja.  Was für eine Plattform hättest du denn für eine Inbetriebnahme
zur Verfügung?  Das ist ja ein 100-pin-TQFP (als bastlerfreundlichste
Gehäusevariante).

> Oi. Und
> wie weit ist der avr-gcc?

Naja, scheint allmählich zu werden.  Der ist ja ein wenig ,,ins
Wasser geschmissen'' worden, da es doch recht umfängliche Umbauten
waren und somit zugleich ein Update auf GCC 4.3 fällig wurde.

> Muss mir mal die Datenblätter in Ruhe anschauen

Fang mit dem family datasheet (Xmega A) an.  Das device datasheet
(Xmega A1) brauchst du nahezu gar nicht.

von Jones (Gast)


Lesenswert?

>Ja.  Was für eine Plattform hättest du denn für eine Inbetriebnahme
>zur Verfügung?  Das ist ja ein 100-pin-TQFP (als bastlerfreundlichste
>Gehäusevariante).

Plattform hab ich noch keine. Vor dem Gehäuse hab ich keine Angst. Hab 
auch schon ein Board für den Mega2560 gemacht. Ist das gleiche Gehäuse.

>Naja, scheint allmählich zu werden.  Der ist ja ein wenig ,,ins
>Wasser geschmissen'' worden, da es doch recht umfängliche Umbauten
>waren und somit zugleich ein Update auf GCC 4.3 fällig wurde.

Jo, schade. Gibt es denn ansonsten überhaupt IRGEND einen Compiler 
dafür? Zur Not tut es ne Demo Version von irgend einem IAR oder sowas. 
Noch hab ich Windows ;)

>Fang mit dem family datasheet (Xmega A) an.  Das device datasheet
>(Xmega A1) brauchst du nahezu gar nicht.

Na toll, genau das hab ich gerade ausgedruckt :D

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

>Inwiefern der AVRISPmkII das mit aktueller Firmware bereits
>beherrscht, weiß ich nicht.

Laut ATMEL Support soll die nächste AVR-Studio Version eine 
XMEGA-Firmware für den AVR-ISP mkII mitbringen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jones wrote:

> Jo, schade. Gibt es denn ansonsten überhaupt IRGEND einen Compiler
> dafür? Zur Not tut es ne Demo Version von irgend einem IAR oder sowas.

Naja, den GCC gibt es ja schon. ;-)  Bis du damit wirklich anfängst,
sollte er (und die avr-libc) allmählich die Xmega-Kinderkrankheiten
los sein.  Du klingst ja nicht so, als könntest du morgen schon
loslegen.

Meines Wissens sind die IAR-Testversionen auf 4 Wochen limitiert.
Den Preis danach wirst du nicht bezahlen wollen, wenn du nicht gerade
ein dickes Projekt in der Hinterhand hast...

von Jones (Gast)


Lesenswert?

> Du klingst ja nicht so, als könntest du morgen schon loslegen.
Nönö, so schnell schießen die Preußen nicht. Wäre aber gern vor 
Weihnachten mit der Hardware soweit das man mal erste Gehversuche machen 
kann.

>Meines Wissens sind die IAR-Testversionen auf 4 Wochen limitiert.
Zum Spielen reicht das erstmal. Wenn die neue Firmware für den AVRISP 
mkII mit den Xmega was anfangen kann ist das ja schonmal was. Den hab 
ich nämlich sowieso schon :)

Die Xmega sind ja erstmal komplettes Neuland. Von daher bin ich 
realistisch. Ich sammel einfach erstmal Infos. Die Xmega interessieren 
mich halt schon länger, dachte aber nicht das man die dieses Jahr 
überhaupt schon bekommt. Bin nur durch Zufall in nem anderen Forum 
darüber gestolpert das es die jetzt wohl doch schon gibt

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

>Die Xmega sind ja erstmal komplettes Neuland.

Nicht wirklich. Alles heißt anders und liegt woanders und viele Module 
sind neu oder erweitert, aber im Grunde ist es ein altbekannter AVR. Die 
Datenblattstruktur hat sich leider verändert und somit sucht man 
eigentlich sehr oft wie ein Maikäfer, bis man die notwendige Information 
extrahiert hat. Die Datenblätter sind auch noch unvollständig. Hier 
helfen die AppNotes weiter.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

ServicePack1 für AVR-Studio 4.14 unterstützt das Programmieren des 
ATXmega128A1 und ATXmega64A1 mit dem AVR-ISP mkII.

http://www.atmel.no/beta_ware/as4/414sp1/AS414SP1.exe

von Jones (Gast)


Lesenswert?

Dann weiß Jörg ja was er dieses Wochenende tun kann ;)

von Jones (Gast)


Lesenswert?

Im der AppNote "Getting Started" steht schon WinAVR drin, scheint also 
wohl schon halbwegs zu funktionieren

http://atmel.com/dyn/resources/prod_documents/doc8107.pdf

von Teplotaxl X. (t3plot4x1)


Lesenswert?

Ob usbprog, auch mal die Xmegas unterstützen wird?

von Jones (Gast)


Lesenswert?

Das Protokoll scheint offen zu sein, allerdings weiß ich nicht ob der 
usbprog mit der Hardware zurechtkommt. Diese PDI Schnittstelle ist sowas 
wie ein synchroner High Speed Half Duplex UART.

Eine Data und eine Clock Leitung. Bis zu 10MHz bei 1,8V. Das Protokoll 
erinnert aber eher an einen UART mit Start und Stopbits.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jones wrote:

> Das Protokoll
> erinnert aber eher an einen UART mit Start und Stopbits.

Das ist recht typisch für die Synchronmodi der AVR-USARTs.  Das Wort
,sychron' bedeutet dort nur, dass sie separat getaktet werden und
dass kein Oversampling mehr im Empfänger stattfindet.  Das hat also
nichts mit den Synchronmodi zu tun, wie man sie beispielsweise von
den Z80-SIOs kannte (SDLC/HDLC).

von Jones (Gast)


Lesenswert?

Ich frage mich warum Atmel das überhaupt gemacht hat. Welchen Vorteil 
hat das gegenüber der klassischen ISP Schnittstelle, außer das man 2 
Pins spart?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Beispielsweise den, dass man sich seinen AVR nicht mehr ,,verfusen''
kann. ;-)  Die PDI-Schnittstelle braucht keinen AVR-Takt mehr.

Außerdem haben sie darüber auch ein Debugprotokoll implementiert (das
ist aber nicht öffentlich).  Da es nur /RESET und TEST als Pins
benötigt, klaut es (im Gegensatz zu JTAG) der Applikation keine
Pins.

von Jones (Gast)


Lesenswert?

> Beispielsweise den, dass man sich seinen AVR nicht mehr ,,verfusen''
> kann. ;-)  Die PDI-Schnittstelle braucht keinen AVR-Takt mehr.

Ja, aber das hat letztendlich doch nix mehr mit den Fuses zu tun. So wie 
ich das verstanden habe (korrigier mich wenn ich mich irre) starten die 
Xmega sowieso immer mit dem internen 2MHz Oszi und wenn man einen 
anderen Takt braucht muss das die Software machen. Sollte es also 
tatsächlich mal ein Problem zb mit einem externen Takt geben kann man 
mittels Reset das Programm doch einfach daran hindern überhaupt zu 
starten und hätte in jedem Fall die 2MHz.

Letztendlich ist es mir egal weil ich einen ISP mkII hab, aber andere 
ärgern sich da schon drüber.

Das mit den Pins ist klar, vor allem nachdem es einen praktisch 
ungenutzten Pin gibt.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.