Hallo allerseits,

ich möchte mir eigentlich nur einmal ein wenig Luft verschaffen. Es ist
mir doch tatsächlich gelungen, dem AP7000 zwei Bulk-Endpoints (1x OUT,
1x IN) zu verpassen und eine bidirektionale Kommunikation zwischen dem
µC und einem Linux-Rechner mit libusb aufzubauen.

Das Ganze hat mich zwei Tage gekostet. Ich frage mich, ob das so
kompliziert sein muss. Erst bekommt man von Atmel Header-Files mit
eingebauten Fehlern und sucht sich dumm und dämlich, nachdem man die
Ergebnisse aus dem ICE nicht nachvollziehen kann und dann kommt die
Sammlung von Status-Bits dazu, deren genauen Sinn man wahrscheinlich
erst nach dem Auswendiglernen der 650-seitigen USB 2.0 Dokumentation
kennt und es bitter bestraft wird, wenn man an bestimmten Stellen
vergisst, irgendein Bit zurückzusetzen. Mit knapp über 300 Zeilen ist
mein Quelltext recht kompakt geworden, da die meiste Zeit für
Trial-And-Error draufging und ich zumindest in der Anfangsphase mit zwei
Rechnern arbeiten musste, da anscheinend der JTAGICE sehr empfindlich
reagiert, wenn an denselben USB-Port ein Gerät hängt, dass die
Kommunikation ein wenig stört. Vielleicht war es auch der Linux-Kernel
selbst. Auf jeden Fall bliebt der ICE ständig hängen.

So, das ist genug Luft. Auf zu neuen Taten.

Gruß,

Florian

PS: Bei Interesse kann ich den entspr. Quelltext-Teil gerne hier posten.

Der AVR32 ist meiner Meinung nach zu neu, um damit wirklich gut arbeite
zu können. Das war mit den SAM7 schon so furchtbar, ich lass erstmal die
Finger davon und bau auf den SAM9 :-)

Wenn ich das richtig verstanden hab, läuft auf dem AP7000 kein Linux,
oder?

Bei solchen Kalibern würde ich selbst wirklich nur noch ungerne an der
Peripherie rumspielen ... Sowas lässt man doch Linux machen ;-)

Mfg
Thomas Pototschnig

Nein, alles höchstpersönlich eingetippt, sogar Startup-Routinen.
Außerdem auch auf sämtliche Standard-Libs verzichtet.

Unter Linux müsste auch jemand Treiber für die Peripherie basteln ;-))

Für meine Zwecke ist im Linux-Kernel zuviel Overhead eingebaut, um alle
Eventualitäten abzudecken. Ich habe vor, das Board als User-Interface
für einen selbstgebauten Logic-Analyzer zu misbrauchen und da brauche
ich nur das Nötigste und vermutlich noch Einiges an 'Dampf', um
Protokolle vernünftig zu dekodieren.

Bin mal gespannt, wie es denn demnächst mit dem LCD-Controller aussieht.

> Unter Linux müsste auch jemand Treiber für die Peripherie basteln ;-))

Dachte, dass es da schon ein fertiges Linux von Atmel gibt ...

> Für meine Zwecke ist im Linux-Kernel zuviel Overhead eingebaut, um alle
> Eventualitäten abzudecken. Ich habe vor, das Board als User-Interface
> für einen selbstgebauten Logic-Analyzer zu misbrauchen und da brauche
> ich nur das Nötigste und vermutlich noch Einiges an 'Dampf', um
> Protokolle vernünftig zu dekodieren.
>
> Bin mal gespannt, wie es denn demnächst mit dem LCD-Controller aussieht.

Have fun :-)

Mfg
Thomas Pototschnig

@Thomas

Da dachtest du richtig. Ich habe hier ein NGW100, und da ist alles
drauf, was man gemeinhin so braucht (außer USB Host).
Siehe
http://www.avrfreaks.net/wiki/index.php/Documentat...

Gruß, Matthias

@MNR:

USB Host kann der AP7000 an sich nicht. Dafür bräuchte man dann externe
Peripherie.

Das Problem mit dem Linux, das da drauf ist, ist erstens, dass der
AP7000 doch ein wenig langsamer getaktet wird, als er könnte (auch wenn
Atmel bis jetzt kein Maximum angegeben hat, wird doch zumindest auf 150
MHz verwiesen) und dass die SDRAM- und Flash-Timings doch relativ
vorsichtig gewählt wurden. Ansonsten natürlich der viel Overhead durch
den Kernel.

Ja, das mit dem Host finde ich auch bescheiden. Mein Foxboard ist da
schon besser...

Benutzt du das AVR32 Studio? FreeRTOS oder alles selber programmiert?

> USB Host kann der AP7000 an sich nicht. Dafür bräuchte man dann externe
> Peripherie.

Das nervt ja am Allermeisten am AP7000 ... Wieso hat der denn keinen
USB-Host??? :-)

War ein weiterer Grund mir lieber ein SAM9260-Board zuzulegen ...

Vielleicht ist das Langsamertakten ein ähnlicher Grund wie das Takten
der SAM7 auf 48MHz, damit die das USB sauber hinkriegen ...

Mfg
Thomas Pototschnig

AVR32 Studio unter Linux und alles selbst programmiert. Bis auf Flash
(seriell + parallel), SDRAM, USART1 und USB blinkt im Moment nur eine
LED mit 1 Hz. Wenn ich endlich den passenden Steckverbinder hätte, wäre
ein TFT dran, das ich irgendwann mal bei eBay geschossen habe.

Hm, jetzt sag auch noch, du hast das Board selbst zusamengelötet ;-)

Wenn du kannst/darfst, wäre ich mal am Code interessiert...

Ne, das ist auch das NGW100. Ich muss den Code gerade mal ein wenig
aufräumen, dann poste ich den gleich.

Hier der Quelltext...

... und der Mini-Linux-Test der USB-Übertragung.

Acho, ich sollte noch erwähnen, dass einige Atmel-Header-Files zu ändern
sind:

Siehe
http://www.avrfreaks.net/index.php?name=PNphpBB2&a...
http://www.avrfreaks.net/index.php?name=PNphpBB2&a...

Ah, sehr gut, danke! Probiere ich mal aus!

Läuft dein Code auch auf den UC3? Weil die sind ja flash-basiert und da
läuft eh kein Linux drauf. Da könnte man deinen USB-Code dann gut
gebrauchen.

Mfg
Thomas Pototschnig

edit
Aber ein EBI haben sie, also eigentlich doch Linux möglich. Aber
interessant ists doch für Systeme, die nicht unbedingt Linux brauchen.
Die AP7 gibts ja überhaupt nicht mit Flash ...

Mit dem UV3 hatte ich bis jetzt nichts zu tun. Daher kann ich nicht
sagen, ob der die gleiche Peripherie hat bzw. diese identisch
angesprochen wird. Der Code selbst setzt erst einmal einen 20 MHz-Quarz
voraus und taktet die CPU dann über den PLL auf 150 MHz, EBI wird auf 75
MHz getaktet (soll laut einem anderen Forum das Maximum sein).

Der AP7000 bootet von Adresse A000 0000, was nicht verbiegbar auf 0000
0000 gemapt ist, das bedeutet EBI CS0 @ 16 bit. Da liegt beim NGW100 ein
AT49BV642D.

Auf jeden Fall können sich noch nicht allzu viele Menschen mit dem Thema
der direkten Programmierung des AP7000 auseinandergesetzt haben, sonst
wäre die Geschichte mit den kaputten Header-Files schon früher
aufgefallen.

Hallo Flo,

hast du zufällig ein Makefile oder so noch da?

Gruss Bene