Hi,
mal ne Frage zu dem Bootloader von den AT91SAM7Sxxx. Hab mir das
Datenblatt und die Anleitung auf at91.com mal durchgelesen. Der Ablauf
ist mir noch nicht ganz klar. Kann man den Bootloader immer nur einmal
verwenden? Das bezieht sich da alles auf das Kit
Wenn ich das richtig verstanden hab läuft das ja so ab:
- TST Jumper stecken
- Board einschalten
- 10 Sekunden warten
In der Zeit wird der Bootloader an den Anfang vom Flash kopiert
- Board ausschalten
- Jumper abziehen
- Board wieder einschalten
Jetzt springt der Controller in den Bootloader und man kann ein
Programm runterladen. Wenn man ein Programm runtergeladen hat springt
der Controller aber immer in das Programm.
Meine eigentliche Frage: muß man vor jedem Download das ganze
Brimbamborium durchziehen bis man mal downloaden kann oder bleibt der
Bootloader im Flash erhalten und man kann ihn anders anspringen?
Der Bootloader wird bei jedem download überschrieben, deswegen muß man
das 10-sekündige "Brimbamborium" jedesmal durchziehen, wenn man diese
methode anwendet. Allerdings soll das ganz ja auch nur eine
"Recovery-Prozedur" sein, die man anwendet, wenn man das Flash
versehentlich gelöscht hat. Einfacher ist es, den Bootloader (gibts im
Quelltext bei Atmel, ist compiliert ca. 4k groß) einfach zur
Applikation dazuzulinken, und dann bei Bedarf zu starten, da entfallen
dann die 10sec. (Der Bootloader muß übrigens aus dem RAM ausgeführt
werden)
Gruß
Wolfgang
Hallo!
Ich quälte mich ebnfalls gerade mit dem ARM-Controller (AT91SAM7S256)
herum! "Ich schmeiß die Scheiße ausm Fenster!!"
Was hab ich denn nun gewonnen, wenn ich den Bootloader im RAM habe? Ich
habe mir das Beispielprogramm (LED blinken) von P. Lynch draufgeladen.
Starten tut das erst nach einem Druck auf "Reset". Dann wird aber das
Eval-Board (Oimex SAM7-P256) nicht mehr per USB erkannt.... Dann muss
ich, um ein neues Programm draufzuladen erst wieder die prozedur mit dem
Jumper-Stecken durchführen....... Und was genau bringt mir dann der
Bootloader, der ja wohl beim abstöpseln der Stromzufuhr gelöscht
wird?!?!
Gruß
Der Praktikant
Okay cool........das ändert aber leider an der Problematik auch nix....
g
Und jetzt mal im Ernst.....Hat jemand ne genaue Ahnung?
Die TWI-Funktion hat wohl auch noch keiner hinbekommen.......habe
jedenfals im Internet noch nix brauchbares an Code gefunden.....
Gruß
Der Praktikant
>>Und was genau bringt mir dann der>>Bootloader, der ja wohl beim abstöpseln der Stromzufuhr gelöscht>>wird?!?!
Der Bootloader liegt schon im Flash wie der andere Sourcecode auch. Nur
wenn du ihn benutzen willst musst du ihn vorher in den RAM-Speicher
kopieren und von dort ausführen.
Gruß T.v.B.
Okay, aber wie geht sowas? Ich steh da völlig auf dem Schlauch....
Bin in meinem ganzen Leben dank Microsoft auf "Point & Click" getrimmt
worden und befasse mich jetzt erst seit ein paar Wochen mit der nackten
Hardware.....
Ich tu mich eben schwer mit der Vorstellung, dass ich da irgendwas
starten kann, obwohl ich keine Tastatur an den µC drangelötet habe?!
Habe zwar mittlerweile akzeptiert, dass ich auch mal ohne klicken
auskomme (Linux-Konsole) aber so recht gelingen will mir da noch nix....
Ja, dieser Atmel-Bootloader war auch mal ein Grund, warum ich die
Atmel-ARMs schon "aus dem Fenster schmeißen" wollte. Ein weiterer Grund
waren übrigends wie diese unmöglich zu lernenden Labels "AT91C_...",
"AT91S_..." usw. Wer sich das ausgedacht hat, muß wohl eine Tastatur mit
1000 Makrotasten haben.
Zwischendurch bin ich dann mal auf NXP-Controller umgestiegen (endlich
leicht zu merkende Labels, besserer aber sehr langsamer Bootloader). Da
es aber die neuen LPC236x-Typen noch nicht in Stückzahlen gibt und ich
für ein Project unbedingt USB und CAN in einem Controller brauche, bin
ich nun wieder zurück zu Atmels AT91SAM7X.
Den Bootloader des Atmel benutze ich gar nicht zum programmieren, das
ist einfach zu umständlich. Am besten geht es per JTAG und OpenOCD. Eine
geänderte Library ohne diesen ganzen AT91C_-Kram werde ich mir in der
nächsten Zeit mal erstellen (oder hat das jemand vielleicht schon
gemacht, dann kann ich mir das sparen).
An das TWI-Problem hab ich mich bis jetzt noch nicht gewagt. Das geht ja
wohl nicht ohne Interrupts. Aber vielleicht gibt es ja bis dahin die
neue Revision der Controller, bei denen der Fehler beseitigt ist.
Erwin
Achso, da ist auf jeden Fall ein Interrupt notwendig?? Wo steht das
bitteschön im Manual? Oder meinen die Jungs von Atmel, man müsse sich
das aus den Fingern saugen?!
Mir ist dabei nur nicht ganz klar, wo ich den Interrupt schalten muss.
Welches Ereignis sollte den Interrupt denn auslösen und was soll die ISR
dann veranstalten?!?!
Mein Gott, da bekomm ich in meinem jungen Alter schon graue Haare gg
Gruß Der Praktikant
hallo philip,
ich weiß ja nicht warum du als anfänger gleich mal mit einem arm
loslegst, aber nehmen wir mal an du hast einen driftigen grund.
in diesem fall würde ich dir mal vorschlagen die kapitel des datenblatts
komplett durchzuarbeiten welche für deine applikation benötigt wird.
desweiteren würde ich dir die examples von www.at91.com ans herz legen.
nun zu deinen eigentlichen problemen:
1. twi: da kann ich nicht viel dazu sagen, außer das eine ansteuerung
eines seriellen bauteils (sei es über twi, spi oder ssc) ohne interrupt
steuerung oder gar mit pdc (dma) nahezu sinnlos ist.
2. sam-ba:
die beim at91sam7s eingesetzte lösung zur aktivierung des sam-ba ist
nicht sehr glücklich. das dürfte auch atmel erkannt haben und hat dies
beim at91sam7x wesentlich verbessert. wenn du sam-ba zum debuggen
einsetzen willst dann hast du den falschen weg gewählt. ohne jtag-ice
(ARM USB JTAG für OpenOCD hierim shop um ganze 70,-€) kannst du das
programmieren am at921sam7s ohnehin vergessen.
gruss
gerhard
Hab nicht alles gelesen, deshalb schonmal ein "sorry", falls ich etwas
widerhole.
1. JTAG besorgen. Erlaubt mit openOCD und gdb Source-Level-Debigging und
das flashen des Controllers kostet mich ein müdes "make program". Oder
auch: "make all program debug". Sehr komfortabel, wie ich finde. Kosten
mit Wiggler < 5 Euro. Geschwindigkeit erträglich.
2. Die AT91 hab ich aus dem header gelöscht. Ansonsten find ich das
nicht schlecht.
F: Funktion
C: Konstante
S: Struktur
PS: Pointer auf Struktur
Dazu noch einen Editor, der Code-Vervollständigung beherrscht, und gut.
Vim und ctags leisten gute Dienste.
Frank wrote:
> 2. Die AT91 hab ich aus dem header gelöscht. Ansonsten find ich das> nicht schlecht.> F: Funktion> C: Konstante> S: Struktur> PS: Pointer auf Struktur
Was genau soll mir das sagen?!
Oh Mann, wäre mein Unternehmen mit einem ATMega denn einfach gewesen?!
Gruß der Praktikant
>Was genau soll mir das sagen?!>Oh Mann, wäre mein Unternehmen mit einem ATMega denn einfach gewesen?!
wenn du dich mit dem atmega genauso wenig auseinandersetzt wie mit dem
at91sam dann würde es dir auch nicht besser ergehen.
datenblätter und tutorials zu lesen ist nun mal pflicht wenn man sich
mit µcontrollern befaßt.
gruss
gerhard
Ja logisch hab ich das Datenblatt gelesen.....Danach hab ich nach bestem
Wissen und Gewissen versucht, die Register so zu setzen, wie es mir für
richtig erschien und scheinbar auch laut dem Ablauf im Datenblatt
richtig sein soll..... aber es hat sich trotzdem nichts getan....
Hallo Praktikant
>Wäre mein Unternehmen mit einem AtMega einfacher gewesen ?
Ja!
Einen Arm zum MC Einstieg zu wählen ist leider eine ziemlich
unglückliche Wahl.
>Ja logisch hab ich das Datenblatt gelesen
Glaub ich Dir nicht, die sind meißtens trocken wie Zwieback,
besonders für einen Anfänger.
Eine einfachere Strategie ist sich Demo Sourcode anzusehen
und sich anzusehen wie dieser funktioniert.
Dann siehst Du um vieles leichter was der Herr Autor des
Datenblattes gemeint hat.
Dann mittels Datenblatt den Democode ändern.
Letztendlich führt leider kein Weg um das Datenblatt herum.
LG
Michael
Also so ein blutiger anfänger bin ich damit auch nicht mehr. hatte eine
vorlesung µC und weiß mit registern und deren belegung einiges
anzufangen.....und um das geht es doch bei einem µC......egal ober es
ein ATMega oder ein AT91 ist.....Und einige Zeilen englischen Text
versteh' sogar ich zu interpretieren g
>Also so ein blutiger anfänger bin ich damit auch nicht mehr. hatte eine>vorlesung µC
und jetzt kennst du den unterschied zwischen theorie und praxis!
scherz bei seite.
kann die aussage von michael nur bestätigen:
demo code und datenblatt ansehen und auch versuchen zu verstehen.
gruss
gerhard
Philip Kottmann wrote:
> Frank wrote:>> 2. Die AT91 hab ich aus dem header gelöscht. Ansonsten find ich das>> nicht schlecht.>> F: Funktion>> C: Konstante>> S: Struktur>> PS: Pointer auf Struktur>>> Was genau soll mir das sagen?!> Oh Mann, wäre mein Unternehmen mit einem ATMega denn einfach gewesen?!>> Gruß der Praktikant
Hast Du überhaupt mal in den Header reingeschaut? Alle Namen fangen mit
AT91 an. Das habe ich überall gelöscht. Der nächste Buchstabe gibt an,
um was es sich handelt. Siehe oben.
Irgendwie hab ich nicht den Eindruck, dass Du es mit nem AVR einfacher
gehabt hättest, Du scheinst dich ja noch nichtmal mit dem Konzept des
Headers auseinandergesetzt zu haben. Obendrein bieten die AT91SAM
komfortables Debuggen via JTAG, die kleineren AVRs nicht. SAM-BA ist
keine gute Möglichkeit, zu programmieren.
Michael Rubitschka wrote:
> Hallo Praktikant>> Ich befürchte sehr das das so nichts wird.>> Wie steht es denn um die C Kentnisse?> Und vor allem was soll das Projekt denn werden?
Es handelt sich darum, 3 analoge Spannungen einzulesen, zu verrechnen
und das Ganze dann per TWI an ein LCD auszugeben.
