Hallo,
ich habe mir zum experimentieren für die Diplomarbeit ein
AT91SAM3S-Board besorgt und zwar das SAM3-H256 von Olimex, siehe
http://elmicro.com/de/sam3-proto.html
Dazu gibt es ja freundlicherweise von Atmel das SAM3S Softpack 2.1 for
CodeSourcery welches Peripherie-Bibliotheken, Ressourcen und Beispiele
für GNU-basierte Toolchains mitbringt.
(siehe http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4705
unter dem Namen AT91SAM3S-EK GNU Software Package)
Außerdem gibt es zu dem Olimex-Board von Olimex auch ein Demo-Package
welches das Softpack von Atmel enthält und ein kompiliertes Beispiel.
Mein Problem ist das foldende…
Ich habe das Softpack übersetzt, alle Beispiele und die Bibliotheken.
Wenn ich ein beliebiges Beispielprogramm mittels SAM-BA (dem ROM
Boot-Assistant von Atmel) in’s Flash lade - passiert rein gar nichts.
Kein Beispiel tut auch nur irgendwas auf dem Board.
Wenn ich die Demo von Olimex flashe - funktioniert sie wie es sein soll.
Nehme ich aber das Softpack und den Demo-Sourcecode von Olimex,
übersetze alles und flashe das Resultat - funktioniert wieder nichts.
Also hab’ ich versucht auf das Softpack zu verzichten und von Grund auf
anzufangen. Ich habe nur einige Quellen aus den Libs genommen (Clock,
Supply Controller, GPIO), das mitgelieferte Linker-Script und den
Startup-Code und das zusammen mit einer ganz simplen main.c kompiliert -
funktioniert auch nicht.
Nochmal ganz klar: die binäre Demo von Olimex funktioniert auf dem Chip,
d.h. es passiert was passieren soll. Egal was oder auf welchem Wege ich
etwas selbst übersetze, passiert gar nichts - außer, dass eine LED auf
dem Board ganz leicht glimmt, wenn überhaupt sollte sie hell leuchten
oder gar nicht.
Das Kompilieren verlief immer fehlerfrei, bzw. ich konnte Fehler beheben
(typos, fehlende #include etc). Ausprobiert habe ich CodeSourcery,
Yagarto, WinARM.
Das einzige was immer wieder auftauchte war die Warnung:
1
moving section .stack by 4 bytes
Ich weiß nicht ob das fatal ist oder nicht so schlimm :/.
Ich bekomme langsam graue Haare und hoffe es gibt hier irgendjemanden
der Erfahrung mit Atmel’s Cortex-M3 und GNU-Toolchains hat.
Meine Vermutung ist ja, dass es am Startup-Code und/oder dem
Linker-Script liegt. Ich wüsste aber nicht was ich daran ändern sollte.
Und ich hoffe auch, dass Code und Ressourcen, die ich von Atmel bekomme,
korrekt sind. -.-
Ich brauch dringend Hilfe,
Vielen Dank,
mo.
Ich hatte mal startschwierigkeiten weil ich eine Taktquelle
initialisiert habe, an der kein Quarz hing. Also hat der Controller sich
in ne Endlosschleife verkrümelt in der er auf den Takt gewartet hat.
Vielleicht hängt er sich bei dir ja bei was ähnlichem auf?
Hauke Radtki schrieb:> Ich hatte mal startschwierigkeiten weil ich eine Taktquelle> initialisiert habe, an der kein Quarz hing. Also hat der Controller sich> in ne Endlosschleife verkrümelt in der er auf den Takt gewartet hat.> Vielleicht hängt er sich bei dir ja bei was ähnlichem auf?
Ah danke, das ist immerhin etwas. Ich werde mir das morgen mal ansehen.
>Ich bekomme langsam graue Haare und hoffe es gibt hier irgendjemanden>der Erfahrung mit Atmel’s Cortex-M3 und GNU-Toolchains hat.
Auch wenn dir das nicht unbedingt weiterhilft:
Besorg dir ein Board mit STM32. Da können dir hier wesentlich mehr
Leute helfen. Exoten wie Atmels Cortex-M3 benutzt hier wohl niemand.
> Wenn ich die Demo von Olimex flashe - funktioniert sie wie es sein soll.
Ist das ein bereitgestelltes "binary" ?
> Wirklich, keiner eine Ahnung? Oder weiß jemand wo ich Hilfe finden> könnte?
Evtl. vergrössern sich die Chancen, wenn ein Projekt mit Makefile,
main.c, Startup-Code und Linker-Skript angehängt wäre. So minimal wie
möglich. Der Kram mit dem Takt kann vermutlich komplett weggelassen
werden. Es genügt etwas GPIO und eine "busy delay" Schleife.
Ich kenne SAM-BA nicht. Läuft das via UART? Muss da eine Prüfsumme
irgendwo wie bei den lpc eingetragen werden?
JTAG-Adapter vorhanden? Debugger vorhanden?
> moving section .stack by 4 bytes
Die Suchmaschine findet zu diesem Text genau einen Treffer ...
Roland H. schrieb:>> Wenn ich die Demo von Olimex flashe - funktioniert sie wie es sein soll.>> Ist das ein bereitgestelltes "binary" ?
Ja. Binary und Source. Binary klappt, selbst-kompilierte Quellen nicht.
> Evtl. vergrössern sich die Chancen, wenn ein Projekt mit Makefile,> main.c, Startup-Code und Linker-Skript angehängt wäre. So minimal wie> möglich. Der Kram mit dem Takt kann vermutlich komplett weggelassen> werden. Es genügt etwas GPIO und eine "busy delay" Schleife.
Ähm, ich werde morgen mal was hochladen. Die Idee mal Clock-Setup etc.
wegzulassen kam mir auch schon, probiere ich morgen aus.
> Ich kenne SAM-BA nicht. Läuft das via UART? Muss da eine Prüfsumme> irgendwo wie bei den lpc eingetragen werden?
Das läuft per USB. Also der Bootloader im Controller initialisiert den
USB Port und das kleine Tool von Atmel schiebt dann darüber das Binary
und kann den Speicer auslesen etc.
> JTAG-Adapter vorhanden? Debugger vorhanden?
Noch nicht.
Ich kenne mich nicht aus. Wenn es so aussieht als wäre der Controller
noch nicht richtig initialisiert, funktioniert JTAG dann trotzdem? :/
>> moving section .stack by 4 bytes>> Die Suchmaschine findet zu diesem Text genau einen Treffer ...
Ja, meinen Thread, wenn ich das richtig sehe ;)
holger schrieb:> Auch wenn dir das nicht unbedingt weiterhilft:> Besorg dir ein Board mit STM32. Da können dir hier wesentlich mehr> Leute helfen. Exoten wie Atmels Cortex-M3 benutzt hier wohl niemand.
Das habe ich auch schon festgestellt. Und nicht nur hier.
Warum musste ich mich auch für Atmel entscheiden? Vielleicht war’s nur
die Tradition wg. AVR -.-
Ich habe mir aber auch schon gedacht, wenn ich das nicht in den nächsten
Tagen zum Laufen bekomme (ich versuche es schon lange), steige ich auf
STM32 um. Aber wehe das klappt dann auch nicht!! ;)
hallo mo,
frage zu deinem problem:
welche entwicklungsumgebung benutzt du?
ich würde dir empfehlen die CodeSourcery einzusetzen, da die beispiele
auch dafür geschrieben wurden.
meiner erfahrung nach ist das aufsetzen einer open-source
entwicklungsumgebung extrem zeitaufwendig (wenn es nicht schon eine fix
und fertige lösung gibt) und frustrierend.
daher ein paar empfehlungen meinerseits (bevor du auf stm32 umsteigst
und odrt ähnliche probleme hast):
1) verwende eine kommerzielle entwicklungsumgebung. es gíbt sowohl für
iar als auch für keil sog. kick-start versionen die gratis sind und für
kleinere projekte vollkommen ausreichen. die von atmel zur verfügung
gestellten beispiele dafür funktionieren alle problemlos.
2) besorg dir eine jtag-emulator. den j-link von www.segger.com gibt es
in der edu-version (für nicht-kommerziellen einsatz) um weniger als
100,-€. damit ersparst du dir sehr viel zeit und graue haare.
3) wenn dir hier keiner weiterhelfen kann dann versuch dein glück auf
www.at91.com. da gibt es einige (unter anderem auch mich) der dich ev.
unterstützen kann.
leider habe ich keinerlei erfahrung mit open-source
entwicklungsumgebungen (verwende iar workbench).
gruss
gerhard
@ batchman
Anbei mal ein (nicht ganz so kleines) Projekt.
@ gerhard
Ich benutze CodeSourcery. Und ich frage mich vor allem was an
"kommerziellen" Systemen so anders ist..
Und es sieht nicht so aus als wäre so viel auf www.at91.com los ;)
> 2) besorg dir eine jtag-emulator. den j-link von www.segger.com gibt es> in der edu-version (für nicht-kommerziellen einsatz) um weniger als> 100,-€. damit ersparst du dir sehr viel zeit und graue haare.
Dem würde ich prinzipiell in so einem Fall auch zustimmen, aber wenn man
noch folgendes berücksichtigt ...
Remo Giermann schrieb:> Und es sieht nicht so aus als wäre so viel auf www.at91.com los ;)
... dann schließe ich mich denen an, die stm32 ins Spiel gebracht haben.
Denn dort kosten Debugger und das Modul 13 EUR.
Die ersten Problem werden ähnlich gelagert sein, aber zumindest hier im
Forum wird's eher Hilfe geben.
> Anbei mal ein (nicht ganz so kleines) Projekt.
Zu groß.
Ich weiss nicht, ob -O0 irgendetwas bewirkt, ich würd's weglassen.
Ebenso das ganze -Wl,--gc-sections, da hat er mir damals auf msp430
zuviel weggeräumt.
Der Stack ist mit 0x900 recht üppig, aber da wird's nicht dran liegen.
Den ganzen syscalls / exceptions Kram, ich weiss nicht.
Was ich im Makefile nicht sehe, was wird letztlich für SAM-BA
gebaut/benötigt? hex? bin?
Bei den Interrupt-Vektoren gibt es 2x "reserved", beim lpc muss da eine
Prüfsumme rein, sonst akzeptiert der UART-Boot loader das nicht.
In der ResetException würde ich LowLevelInit() und __libc_init_array()
entfernen.
So wie das Projekt zu groß ist, so ist die main zu klein.
In main eine Schleife, in dieser Schleife LED an, warten, LED aus.
Warten mit einer busy loop, entweder Variable als volatile oder ein
asm("nop") dazwischen. Eine zusätzliche LED zu Beginn auf Hi stellen.
OK… das ich darauf noch nicht gekommen bin -.-
Also erstmal habe ich die main um eine Blinkschleife erweitert und in
board_cstartup_gnu.c den Aufruf von LowLevelInit() auskommentiert.
Und? ES BLINKT!! Au mann, das gibt’s doch gar nicht! ;)
Roland H. schrieb:> Ich weiss nicht, ob -O0 irgendetwas bewirkt, ich würd's weglassen.
Ja… statt das -Os auszukommentieren hatte ich das daraus gemacht.
> Ebenso das ganze -Wl,--gc-sections, da hat er mir damals auf msp430> zuviel weggeräumt.
Sehe ich mir nochmal genauer an.
> Der Stack ist mit 0x900 recht üppig, aber da wird's nicht dran liegen.
Was ist denn so "normal"? ;) Der meiste Code ist von Atmel. Die machen
natürlich auch Blödsinn, aber ich dachte mir ich lass das erstmal alles
so.
> Den ganzen syscalls / exceptions Kram, ich weiss nicht.
Überflüssig oder fehlerhaft?
> Was ich im Makefile nicht sehe, was wird letztlich für SAM-BA> gebaut/benötigt? hex? bin?
Ein Binary wird erzeugt:
> Bei den Interrupt-Vektoren gibt es 2x "reserved", beim lpc muss da eine> Prüfsumme rein, sonst akzeptiert der UART-Boot loader das nicht.
Das ist so OK, habe nichts anderweitiges gelesen und es funktioniert ja
auch.
> In der ResetException würde ich LowLevelInit() und __libc_init_array()> entfernen.
Dito.
Also, wie gesagt, in LowLevelInit() liegt irgendwo der Fehler. Das werde
ich dann mal unter die Lupe nehmen.
1
WEAKvoidLowLevelInit(void)
2
{
3
uint32_ttimeout=0;
4
5
/* Set 3 FWS for Embedded Flash Access */
6
EFC->EEFC_FMR=EEFC_FMR_FWS(3);
Erste "Auskommentier"-Tests haben ergeben, dass es bis hierhin noch
klappt.
Der Rest geht schief.
Ich werde mal sehen ob ich das noch hinbekomme.
Auf jeden Fall vielen Dank! Wenigstens geht schon mal irgendetwas.
Danke, danke, danke! Ganz große Hilfe! :)
Gruß,
mo.
Ich verziehe mich dann mal in mein stilles Kämmerchen und studiere das
Datenblatt genauestens.
Wenn mich nicht alles täuscht, müsste Slow Clock doch auch sowas wie ein
32kHz Quarz sein, für interne RTC/RTT etc.; so einen hab’ ich aber gar
nicht auf dem Board. Naja, ich gehe mal lesen... :)
Nochmals vielen Dank an alle.
Ha wusst ichs doch ;)
Wenn kein externer quarz angeschlossen ist, dann wartet er ewig drauf,
dass dieser anfängt zu schwingen. Wenn er das nicht tut, dann hängt er.
Also schließ entweder einen 32,786kHz Quarz an (auch als Uhrenquarz
bekannt) oder kommentier den Part aus, wenn du diesen Takt nicht
brauchst.
Alternativ könnte man auch eine Art Fallback lösung programmieren, die
eine Zeit drauf wartet, dass der Takt stabil wird, und wenn nicht, eben
"aufgibt". Genauso für den Systemtakt, wenn der externe Quarz nicht
geht, lauf weiter auf internem takt. Hätte mir auch ein paar
nervenaufreibende Stunden gespart. Vor allem weil ich die Hardware
komplett selbst zusammengestrickt habe und man eben nciht weiß wo man
ansetzen soll.
Remo Giermann schrieb:> Danke, danke, danke! Ganz große Hilfe! :)
Ist ja gut, sag einfach, wohin wir die Rechnung schicken sollen :-)
Remo Giermann schrieb:> Der Fehler liegt hier: /* Select external slow clock */> [...]> timeout = 0;> while (!(SUPC->SUPC_SR & SUPC_SR_OSCSEL_CRYST) );> }
Hier hat jemand zuviel gekürzt. Man sieht, dass die timeout-Variable
verwaist "rumhängt".
Man sieht am obigen kompletten Ausschnitt, dass beim nachfolgenden main
oscillator die timeout-Variable genau dafür verwendet wird, aus der
Schleife irgendwie rauszukommen.
Wie dem auch sei, die Tool chain geht, die LED blinkt. Der Rest ist
Fleißarbeit.
Viel Spaß mit dem Cortex
Ach ja, wäre nett, wenn Du das funktionierende Beispiel nochmals
komplett anhängst, falls es mal wieder jemand anderes auf diese
exotische Insel verschlägt.
hallo mo,
die von dir verwendeten examples sind auf SAM3S-EK abgestimmt,welches
einen ext. 32khz Quarz aufweist und dessen oszillator in der von dir
festgestellten schleife init. wird.
das von dir verwendete olimex-board besitzt diesen quarz nicht und daher
bleibt die init. in der schleife hängen.
sicher keine meisterleistung an programmierkunst seitens atmel.
allerdings habe ich schon sehr viele examples angewandt und noch selten
einen fehler gefunden.
dieses beispiel zeigt aber auch, dass es ohne einarbeiten in die div.
peripherals und in die low-level-funktionen nicht geht.
trotz hier anders lautender "vermutungen" wird dir auf at91.com sicher
auch geholfen. englisch ist halt pflicht, aber das sollte bei jemand,
der eine dipolmarbeit schreibt, ja kein thema sein.
btw: so einen fehler mit jtag-ice zu finden hätte ca. 1h gedauert.
gruss
gerhard
gerhard schrieb:> hallo mo,> die von dir verwendeten examples sind auf SAM3S-EK abgestimmt,welches> einen ext. 32khz Quarz aufweist und dessen oszillator in der von dir> festgestellten schleife init. wird.> das von dir verwendete olimex-board besitzt diesen quarz nicht und daher> bleibt die init. in der schleife hängen.
Ja, das ist mir dann auch aufgefallen.
> trotz hier anders lautender "vermutungen" wird dir auf at91.com sicher> auch geholfen. englisch ist halt pflicht, aber das sollte bei jemand,> der eine dipolmarbeit schreibt, ja kein thema sein.
Also, wie ich gesehen habe, gibt es nicht viele Beiträge zum SAM3S auf
at91.com und überhaupt ist die Aktivität dort eher bescheiden.
Zumindest dem nach zu urteilen, was ich gesehen habe.
> btw: so einen fehler mit jtag-ice zu finden hätte ca. 1h gedauert.JTAG ist unterwegs.
>> gruss> gerhard
Remo Giermann schrieb:>> trotz hier anders lautender "vermutungen" wird dir auf at91.com sicher>> auch geholfen. englisch ist halt pflicht, aber das sollte bei jemand,>> der eine dipolmarbeit schreibt, ja kein thema sein.>> Also, wie ich gesehen habe, gibt es nicht viele Beiträge zum SAM3S auf> at91.com und überhaupt ist die Aktivität dort eher bescheiden.> Zumindest dem nach zu urteilen, was ich gesehen habe.
dann sind wohl die prozessoren, die dokumentationen und examples so
perfekt dass es gar keine fragen und probleme gibt;-)
gruss
gerhard
ich nutze meistens den hotline support von Atmel bevor ich mich mit
trolls in Foren ärgern muß - wobei jetzt mal ST außen vor zu lassen (die
STM32 Datenblätter kenn ich nicht) wenn jemand das Datenblatt von NXP
LPC mit denen von Atmel vergleicht wird die Doku von Atmel zu schätzen
wissen.
Remo Giermann schrieb:> Also, wie ich gesehen habe, gibt es nicht viele Beiträge zum SAM3S auf> at91.com und überhaupt ist die Aktivität dort eher bescheiden.
Die Atmel M3 sind einfach viel zu jung, als daß sie weit verbreitet sein
können. Farnell hat die noch nichtmal im Sortiment.
Ich vermeide es generell, zu neue Bauteile einzusetzen. Das spart einem
wertvolle Entwicklungszeit ein.
Sollen doch andere erstmal die Bugs rausfinden oder bei Lieferengpässen
die Broker abtelefonieren.
Erste wenn neue ICs bei mindestens 2 Distris lagernd sind, setze ich sie
ein.
Peter
gerhard schrieb:> sicher keine meisterleistung an programmierkunst seitens atmel.
Wobei es natürlich auch keine Meisterleistung von Olimex ist, auf
einem Experimentierboard ausgerechnet auf den slow-clock-Quarz zu
verzichten ...
Ich habe letztens auch mal mit SAM3 angefangen zu experimentieren
(vor allem, um ARM/Cortex-M3 überhaupt kennenzulernen, das SAM3S-EK
war mir "zugeflogen"). Ich bin dann auch dazu übergangen, statt
irgendwelcher Beispielcodes wirklich Schritt für Schritt jede Zeile
Code selbst zu schreiben. Dabei habe ich deutlich mehr gelernt als
beim Runterbrechen fertiger Beispiele, musste mich am Ende auch noch
durch einen memory fault durchhangeln (und dabei lernen, dass der
memory fault standardmäßig nicht aktiv ist, sodass man einen hard
fault bekommt). Dafür fühle ich mich jetzt wohl genug bei dem
Gedanken, dass morgen jemand auf mich zu kommt und von mir erwartet,
demnächst ein Cortex-M3-Projekt zu erledigen.
Schön beim Cortex-M3 ist eigentlich, dass viele Dinge dort bereits
von ARM vereinheitlicht worden sind im Vergleich zu früheren ARMs.
Obige Behauptung "Nimm doch einen STM32, dann bekommst du mehr Hilfe"
ist damit eigentlich mehr eine Ausrede, denn vieles haben beide
gemeinsam. Erst bei den weiteren Peripherals unterscheiden sich dann
die Hersteller wieder, aber für die muss man ohnehin jeweils das
Datenblatt wälzen.
(JTAG ist ja bei ARM ohnehin schon immer genormt. Man muss also nicht
unbedingt ein teures Segger nehmen, ein Wiggler oder FT2232-basierter
Adapter tut's genauso.)
> Wobei es natürlich auch keine Meisterleistung von Olimex ist, auf> einem Experimentierboard ausgerechnet auf den slow-clock-Quarz zu> verzichten ...
D. h. alle Board-Hersteller mit einem Atmel Cortex-M3 müssen den 32 kHz
Quarz auflöten, nur damit die Beispiele von Atmel auch laufen können ;-)
Aber dass an einem so wichtigen Punkt das mit der "timeout-Behandlung"
angefangen, aber nicht zu Ende geführt wurde, nun ja.
> Ich bin dann auch dazu übergangen, statt> irgendwelcher Beispielcodes wirklich Schritt für Schritt jede Zeile> Code selbst zu schreiben. Dabei habe ich deutlich mehr gelernt als> beim Runterbrechen fertiger Beispiele,
Das stimmt. Das ist nur nur leider beim Wechseln der Cortexe schnell
sehr aufwändig, da der "clock tree" teilweise sehr komplex ist. Da ist
man dann schon froh, wenn es funktionierende SystemInit() gibt, welche
sich mit ein paar #defines zufrieden geben. Habe heute zufällig das
Excel-Sheet für den stm32f4 in der Hand gehabt, der spuckt dann das
Stück C aus.
> musste mich am Ende auch noch> durch einen memory fault durchhangeln (und dabei lernen, dass der> memory fault standardmäßig nicht aktiv ist, sodass man einen hard> fault bekommt).
Muss man nicht, man "darf" :-) Leider ist die "escalation" standardmäßig
aktiviert. Aber die Berechnung der fault-Adresse und ggf. ein breakpoint
in den fault handlern ... für härtere Fälle durchaus wichtig.
> Schön beim Cortex-M3 ist eigentlich, dass viele Dinge dort bereits> von ARM vereinheitlicht worden sind im Vergleich zu früheren ARMs.> Obige Behauptung "Nimm doch einen STM32, dann bekommst du mehr Hilfe"> ist damit eigentlich mehr eine Ausrede, denn vieles haben beide> gemeinsam. Erst bei den weiteren Peripherals unterscheiden sich dann> die Hersteller wieder.
Zumindest meinem Gefühl nach traten die Gemeinsamkeiten schnell in den
Hintergrund, man nimmt es nicht mehr so richtig war. Es reduziert sich
auf den NVIC. Die Peripherie ist in der "Überzahl" und ziemlich anders.
Ich schätze es dennoch, dass z. B. der NVIC genormt und ein
Systick-Timer einfach immer vorhanden ist.
Na da habe ich ja doch noch eine interessante Diskussion losgetreten ;)
Also ich gebe euch einfach allen Recht. Zumindest wurden viele
verständliche und vernünftige Punkte genannt die ich so auch
unterstützen würde (ja ehrlich). ;)
Gruß,
m.
Remo Giermann schrieb:> Na da habe ich ja doch noch eine interessante Diskussion losgetreten ;)
Dann darfst Du diese auch mit folgender Kleinigkeit schliessen :-)
> Ach ja, wäre nett, wenn Du das funktionierende Beispiel nochmals> komplett anhängst, falls es mal wieder jemand anderes auf diese> exotische Insel verschlägt.
Roland H. schrieb:>> Ach ja, wäre nett, wenn Du das funktionierende Beispiel nochmals>> komplett anhängst, falls es mal wieder jemand anderes auf diese>> exotische Insel verschlägt.
Das wäre toll, bekomme nächste Woche mein Demo Board mit SAM3U.
Cortex-M3 mit High Speed USB, yeeeheees!
@x-rocka
Als Lektüre kann ich dir den Quellcode des OsmoSDR empfehlen.
Da entsteht gerade ein Software Defined Radio basierend auf dem SAM3U.
Die benutzen auch die High Speed USB Verbindung zur Übertragung der
Rohdaten an den PC.
Quellcode gibts im Git Repository.
http://sdr.osmocom.org
Mehr über SDR:
http://cre.fm/cre087
Roland H. schrieb:>> Ach ja, wäre nett, wenn Du das funktionierende Beispiel nochmals>> komplett anhängst, falls es mal wieder jemand anderes auf diese>> exotische Insel verschlägt.
So, besser spät als nie.
Wurde noch erweitert um eine blinkende LED basierend auf dem SysTick
(wollte das mal ausprobiert haben ;)).
Die betreffende Datei und Funktion wurde allerdings umbenannt in
system.c bzw. SystemInit().
LG, m.
Roland H. schrieb:>> Wobei es natürlich auch keine Meisterleistung von Olimex ist, auf>> einem Experimentierboard ausgerechnet auf den slow-clock-Quarz zu>> verzichten ...>> D. h. alle Board-Hersteller mit einem Atmel Cortex-M3 müssen den 32 kHz> Quarz auflöten, nur damit die Beispiele von Atmel auch laufen können ;-)
Nein, mir ging es hier nicht um die Atmel-Beispiele, sondern darum,
dass ich den slow clock für ein ausreichend wesentliches Feature
halte, als dass man ihn auf einem Experimentierboard nicht weglassen
sollte. Letztlich wird ja damit die time-of-day clock realisiert,
die man häufig genug auch in einer eigenen Applikation brauchen kann.
Bezüglich des Atmel-Codes kann man gut und gern auch mal einen
Bugreport schreiben. Ein Fehler wie ein nicht funktionierender
slow clock sollte zumindest irgendwie erkannt werden und zu einer
sinnvollen Behandlung führen, statt sich in einer Endlosschleife zu
verheddern.
Remo Giermann schrieb:> So, besser spät als nie.
Danke Dir.
Jörg Wunsch schrieb:> Nein, mir ging es hier nicht um die Atmel-Beispiele, sondern darum,> dass ich den slow clock für ein ausreichend wesentliches Feature> halte, als dass man ihn auf einem Experimentierboard nicht weglassen> sollte.
Ja, das ist natürlich richtig.
> Ein Fehler wie ein nicht funktionierender> slow clock sollte zumindest irgendwie erkannt werden und zu einer> sinnvollen Behandlung führen, statt sich in einer Endlosschleife zu> verheddern.
Das habe ich gemeint. Ich weiß zwar nicht, woher der Source letztlich
herkam (und ob er aktuell ist oder ob etwas gelöscht wurde), aber wenn
es die Atmel-Referenz-Implementierung ist, dann ist das etwas unschön.
Roland H. schrieb:> Das habe ich gemeint. Ich weiß zwar nicht, woher der Source letztlich> herkam (und ob er aktuell ist oder ob etwas gelöscht wurde), aber wenn> es die Atmel-Referenz-Implementierung ist, dann ist das etwas unschön.
in den aktuellen atmel examples (software package rev. 2.1) ist die
endlosschleife auch noch drinnen.
gruss
gerhard
moin moin,
der startup code hats in sich + nach langem suchen bin ich hier
gelandet.
das test.zip projekt funzt mit ner kleinen änderung in board.h
#define LED_STATUS PIO_PC18
#define LED_ALARM PIO_PC19
#define PIN_LED_ST {LED_STATUS, PIOC, ID_PIOC, PIO_OUTPUT_1,
PIO_DEFAULT}
#define PIN_LED_AL {LED_ALARM, PIOC, ID_PIOC, PIO_OUTPUT_1, PIO_DEFAULT}
auch auf dem teil hier:
http://www.tinkerforge.com/doc/Hardware/Bricks/Master_Brick.html#master-brick
vielen vielen dank + bis denne
-matze
Thank you for this.
Simply commenting out the slow clock section from
libraries/libboard_sam3s-ek/source/board_lowlevel.c
and replacing the PIN_LED_0 in
libraries/libboard_sam3s-ek/board.h with
#define PIN_LED_0 {PIO_PA8, PIOA, ID_PIOA, PIO_OUTPUT_1, PIO_DEFAULT}
// OLIMEX
made many of the examples work.
Sorry for the lack of German and thank you Google translate.
-Rick
Thread beobachten
Seitenaufteilung abschalten