Small ARM: Welcher taugt was?

Hab ein paar Erfarungen.  Der LPC2136 waere evtl. was oder wenn Du den
schon bekommen kannst der 2148 mit USB noch etwas besser. Philips hatte
jetzt fast 2 Jahre Zeit die Kinderkrankeiten zu beseitigen.
Zugegebenermassen ist der 2129 immer noch im ersten Release mit vielen
Fehlern, dasselbe gilt fuer den 2106.  Allerding ist mir unklar weshalb
Atmel mit den ersten SAM7 einen Deut besser sein sollte. Da haben
einfach alle Neuland betreten und muessen Lehrgeld bezahlen. Von Keil
gibts das MCB 2130 oder auch MCB2140, beide sehr zu empfehlen.

Von http://www.embeddedartists.com in Schweden gibt ein sehr nettes
kleines Board mit dem 2138 fuer schlappe 35 Euro (+ Versand ;-)

Zum Download von guten freien Programmen kann ich auch diese Seite
empfehlen:
http://www.newmicros.com
Die haben auch das billigste Board mit dem LPC2131 mit 29 Dollar aber
halt nicht fuer den groesseren Chip (so billig)

Vielleicht hilft das ein wenig weiter, Gruss, Robert

Hi Robert,
ich tendiere im Moment eher zu den SAM7S von Atmel. Zum einen weil die
anscheinend billiger sind als die Philips, die haben USB und das Errata
ist noch nicht ganz so lang und hat nicht ganz so gravierende Fehler wie
die von Philips. Wobei ich allerdings über die Preise von den Boards
doch erstaunt bin. Was ich irgendwann mal gebrauchen könnte ist sowas
wie diese Plug-an-ARM
http://www.newmicros.com/store/product_pictures/PlugaARM.jpg
Allerdings fehlt mir da gleich der JTAG Anschluß. Außerdem finde ich
die Montage der beiden Spannungsregler erschreckend
Aber wie gesagt, die AT91SAM7S gefallen mir bisher von der Ausstattung
besser

Mal schauen was ich mache. Wenn jemand noch Tipps und Anregungen
hat...

JarJar

Hallo JaJar,

ich stand vor der gleichen Entscheidung und habe mich für den AT91SAM7S
entschieden.
Die Entscheidung diesen Controller der LPC-Serie vorzuziehen waren
hauptsächlich folgende:
-Integrierter Spannungsregler für 1,8V
-USB-Schnittstelle
-mehr RAM
-Errata-Sheet

Ähnlich dem Atmel ist der STR711 von STM. Der Nachteil ist jedoch der
höhere Stromverbrauch, der fehlende Trennung zwischen PWM/Timern.
Außerdem ist der ATMEL deutlich flexibler in der PORT-Konfiguration.

Ich entwickle gerade ein miniBoard (ähnlich dem Plug-An-Arm). Das Board
wird als Big-Chip in meine Applikation eingesetzt und enthält folgende
Features:

-kleine Abmasse ca. 20mm x 30mm (Multilayer-Design)
-onBoard AT91SAM7S256
-onboard Spannungsregler für 3,3V mit Shutdown und Fault-Ausgang
-onboard Supervisory-IC mit Batt-Anschluss und PFI-Komparator
-onboard RTC
-onboard FLASH (2Mbyte Speichergröße)
-alle Controller-Pins an den Steckerleisten verfügbar

Gruß Tom

Hi Tom,
das sind im Wesentlichen auch die Punkte warum ich mich für die SAM7S
entschieden hab. Der integrierte Spannungsregler ist nicht so
entscheidend, aber ne nette Zugabe.

Bei solchen Modulen hat denk ich jeder andere Anforderungen. Was ist
das denn für ein Onboard Flash und wofür braucht man das?

Onboard RTC: ist das ein extra Uhrenbaustein? Der SAM hat doch nen RTC
eingebaut. Ist zwar keine echte Uhr, aber soweit ich das bisher
verstanden hab ein Realtime Timer der eine eigene Versorgung hat und
unabhängig laufen kann. Oder hab ich mich da verguckt?

Und wozu braucht man denn extra noch nen Supervisor IC oder nen Regler
mit Fault Ausgang? Die Controller haben doch eigene Resetschaltungen
und Brow Out Detection? Bin bei den AVR bisher damit immer gut
gefahren. Hatte nie mehr als nen Pullup Widerstand an Reset und nie
Probleme

Die SAM7S-Controller gefallen mir sehr gut. Die integrierte Peripherie
ist genial :-)

Allerdings bin ich auf das Problem gestoßen, dass die noch so neu sind,
dass sie von GnuARM noch nicht unterstützt werden. Das war der Grund,
warum ich erstmal mit dem LPC2214 basteln will.
Auch der standardmäßig integrierte Bootloader, mit dem man über die
RS232 den LPC flashen kann, gefällt mir sehr gut. Ja - ich weiß
natürlich, dass es sowas jetzt bei den SAM7S auch gibt :-)

Ich warte jedenfalls noch auf die GnuARM-Unterstützung und erst dann
wird damit gearbeitet ...

Mfg
Thomas Pototschnig

Hi JarJar,

der Flash ist ein SPI-Flash. Dieser wird benutzt um Daten, wie z.B.
Programmparameter oder Messdaten zu speichern. Mann könnte auch Daten
im internen RAM halten. Die externe Lösung mit dem FLASH ist jedoch
sicherer, weil der FLASH-Speicher nicht gepuffert werden muss. Außerdem
mehr Speicherplatz als das interne RAM. Datenverlust ist somit
ausgeschlossen wenn die Spannung weg ist.

RTC: Der Atmel hat einen Real-time Timer, das ist richtig. Allerdings
habe ich mich entschlossen eine separate RTC einzusetzen, da die
Stromaufnahme der externen RTC deutlich geringer ist (ca. 300nA) als
die Stromaufnahme das Controllers im UltraLowPower-Mode (ca. 38µA).
Selbst wenn nur die Core läuft sind es 4µA. Ein positver Nebeneffekt
ist der geringere Programmieraufwand für die RTC. Weiterhin steht der
interne RealTimer für andere Aufgaben zur Verfügung.

Eine meiner eigenen Vorgaben für mein Modul war, die Pufferung mit
möglichst geringem Stromverbrauch zu realsieren. Daten werden im Flash
gespeichert, sodass nur noch die externe RTC mit einer Batt. gepuffert
werden muss.

Der Supervisor hat nur untergeordnet die Funktion, das Reset-Signal zu
generieren. Primär hat der Baustein die Funktion die
Batterieumschaltung auf die RTC zu realsieren sowie eine Überwachung
der Pufferbatterie (oder einer anderen Spannung) zur Verfügung zu
stellen. Exterene Komponenten außerhalb des Moduls (wie. Z.B.
Komparator) entfallen somit. Ein kleiner Vorteil ist auch, dass der
externe Reset solange erzeugt wird, bis 3,0 Volt überschritten werden.
Der OnChip Brownout-Detector überwacht jedoch nur die Core-Spannung
(1,8V). Über die externe Lösung läuft der Controller somit erst dann
an, wenn alle erforderlichen Spannungen im grünen Bereich sind (nicht
nur Core, sondern auch Flash und I/O-Spannung).

Gruß Tom

@JarJar: Mit Stromaufnahme bei der RTS meinte ich die Stromaufnahme zur
Pufferung, nicht die Stromaufnahme im Betrieb

@Thomas: Da geb ich Dir vollkommen Recht! Die integrierte Peripherie
ist absolut klasse, da jeder Port sehr flexibel eingesetzt werden kann.
Sehr durchdacht der ganze Chip. Bezüglich GnuARM solltest Du mal im
Forum auf www.at91.com suchen (Suchbegriff GnuARM). Ich meine dort
gelesen zu haben, dass SAM7S unterstützt wird.

Gruß Tom

@Tom: Danke für den Tipp. Das letzte mal war ich vor 2 Monaten dort -
kann schon gut sein, dass die das jetzt schon supporten. Gleich mal
schauen.

Mfg
Thomas Pototschnig

@ Tom: danke für die ausführliche Erläuterung. Nette Hilfe :)

A propos GNU  - ARM : Da kann man von der Atmel-Seite oder auch von Keil
eine Eval-Version von µVision herunterladen. Der µVision ist zwar beim
Debuggen in dieser Eval-Version auf 16k begrenzt. Aber es wird eben
auch ein GG für ARM und CygWin mitinstalliert, und dann kann man
µVision halt als IDE für den Gcc benutzen - ist eine feine Sache, dann
so kommt man recht stressfrei zu einer Gcc-Version für die SAM7, mit
Headerfiles und startup-code und allem.

Gruß
Wolfgang