mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welches sind die richtigen ATMELS für meine Zwecke?


Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

Für mein aktuelles Projekt (ein Datenlogger) möchte ich zum ersten mal 
Atmel µCs einsetzen. Bisher habe ich nur mit den PICs von Microchip 
gearbeitet, aber wegen meiner Vorliebe für OpenSource Software möchte 
ich in Zukunft lieber auf die Atmels umschwenken. Das Herzstück des 
Loggers bildet ein ARM9 von Atmel, auf dem Linux läuft. Über SPI sollen 
nun zahlreiche Microcontroller angesprochen werden. Da ich von den 
Eigenschaften der verschiedenen Atmels µCs (AVR, ATtiny, ATmega...) noch 
nicht so den Durchblick habe, wäre es nett, wenn Ihr mir an Hand der 
unten stehenden Anforderungen ein paar Typen Vorschlagen könntet:

Generell:
Versorgungsspannung und Signalpegel: 3,3V
Taktrate des SPI: 4MHz
Die µCs sollten den 4 MHz SPI im Slave Betrieb auch unterstützen können.
Temperaturbereich: -40°C bis +85°C
Bauart: SMD
Programmierung über In System Programming (ISP)

Erster Baustein:
Zweck: LEDs schalten (über Transistoren) und dimmen (über PWM)
Anzahl Ausgänge f. LEDs: 14
Hatte mir mal den ATtiny 2313 herausgesucht, ist der geeignet?

Zweiter Baustein:
Zweck: Taster abfragen, evtl. mit Softwareentprellung.
Anzahl Eingänge: 5
Passt hier auch der ATtiny 2313?

Dritter IC:
Zweck: Zählung der Drehimpulse eines optischen Drehencoders 
(Bestellnummer ENC 62P22-H6S bei Reichelt)
Anzahl Eingänge: 2 (Reichen hier eigentlich "normale" I/O für die 
Interpretation Pulsreihenfolgen aus, oder sollte man lieber mit 
Comparatoren / Interrupts arbeiten?)

Eventuell könnten IC 2 und 3 auch zusammengefasst werden, sofern dies 
Sinnvol ist.
Noch eine Frage: Für die Programmierung der Atmels benötigt man meines 
Wissens eine IDE (Editor, Compiler) und ein Brennprogramm welches die 
Hexfiles über einen ISP-Adapter o.ä. auf die µCs rüberspielt. Habe ich 
da nicht noch irgentwas vergessen?

So, das wars erstmal mit Fragen :-),
Viele Grüsse und ein frohes Neues,
Peter

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Hallo Peter,

ein ATmega8 könnte z.B. diese Anforderungen erfüllen.


Software und Programmierkabel:

http://s-huehn.de/elektronik

Bernhard

Autor: Henrik J. (henrikj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omg. Du willst über die Tinys zum ARM9? Hmm... Warum nicht gleich den 
ARM, wenn du schon Erfahrung mit PICs hast? LEDs schalten geht aucnb mit 
nem ARM.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Software und Programmierkabel:

>http://s-huehn.de/elektronik

Schlechter Tip für Anfänger/Umsteiger. Dann doch lieber gleich einen 
original ATMEL AVR_ISP oder AVR_ISP mkII als Programmer mit AVR_Studio 
dazu, damit wird der Kollege schneller glücklich.

Zur Frage nach dem richtigen ATMEL Controller: auf der Seite von ATMEL 
gibt es eine schöne Controller-Übersicht und zu jedem Controller extra 
großzügige Datenblätter - einfach mal ein wenig Zeit investieren und 
dann den richtigen Controller aussuchen. Tips haben immer den Nachteil, 
subjektiv zu sein. Der ATMEGA8 ist so ein "ich mach mal auf die Schnelle 
alles" - Kandidat, muß aber nicht unbedingt Deinen vollen Geschmack 
treffen.

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Omg. Du willst über die Tinys zum ARM9? Hmm... Warum nicht gleich den
>ARM, wenn du schon Erfahrung mit PICs hast? LEDs schalten geht aucnb mit
>nem ARM.

Die Erklärung hierfür ist relativ einfach zu verstehen: Wenn ich für 
jede benötigte I/O einen Pin vom ARM verschwende, komme ich nicht 
sonderlich weit, da es sich bei den oben genannten ICs nur um die 
Umsetzung der Bedieneinheit handelt. Bei SPI wird pro Slav-IC nur eine 
zusätzliche Chipselect Leitung benötigt, die zur Not auch noch 
gemultiplext werden könnte. Ausserdem spart man am ARM wertvolle 
Rechenzeit, wenn dieser lediglich Stellwerte versenden und fertig 
skalierte Werte auslesen muss.

Ich habe gehofft, daß evtl. jemand schon mal eine gleiche oder ähnliche 
Aufgabe zumindest teilweise gelöst hat und mir wertvolle Tips geben 
könnte. Die Frage die mich zur Zeit am meisten quält ist der 
SPI-Slavebetrieb der ATMEL µCs. Habe die Befürchtung, daß die vollen 4 
MHz nicht so leicht umzusetzen sind. Von meinen PIC Projekten habe ich 
den I2C-Slavebetrieb noch in sehr schlechter Erinnerung, und da warens 
nur 400KHz... Wenn es hierzu Informationen gibt, wäre das schon ein 
riesen Schritt.

@Travel: Hatte auf der ATMEL Seite schon mal geschaut, aber irgentwie 
nicht so richtig was brauchbares finden können. Naja, werde trotzdem 
gleich nochmal einen Blick drauf werfen.

Autor: fieser Rahul (auch Oskar genannt) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Eventuell könnten IC 2 und 3 auch zusammengefasst werden, sofern dies
>Sinnvol ist.

Die kannst du auch alle in einen Mega32 oder so packen...(sofern 
räumlich halbwegs dicht beieinander).

>Reichen hier eigentlich "normale" I/O für die Interpretation >Pulsreihenfolgen 
aus
Guck mal in der Codesammlung nach "bulletproof". 
Tastenenprellungsroutinen von Peter Dannegger. Effizienteren Code wirst 
du kaum finden.

>LEDs schalten (über Transistoren) und dimmen (über PWM)
>Anzahl Ausgänge f. LEDs: 14

Mach daraus 2: 2 Schieberegister
http://www.mikrocontroller.net/articles/Porterweit...
Ob du einen AVR per SPI "vollquatscht" oder ein Schieberegister, sollte 
aufs gleiche hinauslaufen, sofern die LEDs nicht gemultiplext werden 
sollen.
Eingänge könnte man auch so betun...
... oder alles in einen Controller packen, der genug Beinchen hat 
(Mega64 sollte soich dabei richtig langweilen...)

Wegen der SPI-Frequenz musst du mal ins Datenblatt der Controller 
gucken.

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... oder alles in einen Controller packen, der genug Beinchen hat
>(Mega64 sollte soich dabei richtig langweilen...)

Das wäre natürlich auch eine Möglichkeit, die Entfernung der Bauteile 
voneinander liegt bei maximal 16cm, macht 80mm weitesten Weg, wenn der 
µC mittig sitzt.
Bin mir aber nicht so sicher, wie das aussieht, wenn gleichzeitig 
SPI-Datenverkehr, Encoderdrehungen und gedrückte Tasten bearbeitet 
werden wollen.
Hmm, werd mal drüber nachgrübeln, scheint an sich eine vernünftige 
Lösung zu sein. Spart ausserdem 2 CS Leitungen :-) und ne Menge 
Peripherie (Quarze, Pullups, Block-Cs, ISP-Anschlüsse...)

>Guck mal in der Codesammlung nach "bulletproof".
>Tastenenprellungsroutinen von Peter Dannegger. Effizienteren Code wirst
>du kaum finden.

Danke für den Tip, denke das kann ich noch sehr gut gebrauchen!! Meinte 
zwar eigentlich die Auswertung des Drehencoders (Drehrichtungserkennung 
und Zählen der Pulse), aber die Tasterentprellung ist auch ein wichtiges 
Thema das noch ansteht.

>Mach daraus 2: 2 Schieberegister

Und wie funktioniert das dann mit der Dimmung der LEDs über PWM? Müsste 
dann wahrscheinlich mit ~100Hz und exaktem Timing der Duty time Daten an 
das Schieberegister senden, oder?

>Wegen der SPI-Frequenz musst du mal ins Datenblatt der Controller
>gucken.

Jo, hab ich grad getan. Die maximale SPI Frequenz im Slave Betrieb 
sollte nicht größer fosc/4 (d.h. 16MHz Taktung des µC) betragen. 
Allerdings lassen die ATmegas, die ich gefunden habe bei 3,3V Vcc 
maximal eine 8MHz Taktung zu. Die vollen 16MHz gibts nur bei 5V...

Autor: fieser Rahul (auch Oskar genannt) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(Drehrichtungserkennung und Zählen der Pulse),

Entweder wird genau das auch darin behandelt oder es gab da noch einen 
extra Thread mit Encoderauswertung (Graycode).

>Und wie funktioniert das dann mit der Dimmung der LEDs über PWM? Müsste
>dann wahrscheinlich mit ~100Hz und exaktem Timing der Duty time Daten an
>das Schieberegister senden, oder?

Ja, sowas in der Richtung. Je nach Schieberegister haben die auch noch 
einen Output-Enable-Eingang, dem man die PWM verpasst.

>Die maximale SPI Frequenz im Slave Betrieb sollte nicht größer fosc/4
Bist du an die 4MHz gebunden?

Autor: Michael E. (rince)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf AVRfreaks.net gibts eine dynamische Vergeleichsttablelle aller AVRs:

http://www.avrfreaks.net/index.php?module=Freaks%2...


Einfach oben die Familie auswählen und unten die Features die man 
vergleichen will. Ziemlich praktisch finde ich.

Rince

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Entweder wird genau das auch darin behandelt oder es gab da noch einen
>extra Thread mit Encoderauswertung (Graycode).

Ah, das hört sich gut an. Such ich gleich mal nach.

>Ja, sowas in der Richtung. Je nach Schieberegister haben die auch noch
>einen Output-Enable-Eingang, dem man die PWM verpasst.

Hmm, so könnte man es auch machen, aber ein µC ist mir dafür doch lieber 
(Fire-and-Forget Prinzip).

>Bist du an die 4MHz gebunden?

Ja, da an dem Bus noch viele andere Teilnehmer hängen. Z.B. ein OLED, 
daß alle 50ms mit neuen Daten (~4kByte) versorgt werden will. Wenn ich 
nicht mit den maximalen 4Mhz arbeite, geht da nicht mehr viel... Dann 
würde ich eher eine Pegelwandlung von 5V auf 3,3V im SPI-Bus in Kauf 
nehmen, um  einen 5V-µC anschliessen zu können.

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo peter,
wenn du ohnehin schon erfahrung mit atmel arm9 hast, dann würde ich dir 
als slaves at91sam7s empfehlen.
gründe:
-) der at91sam7s "verkraftet" deinen 4mhz spi-takt dank pdc ohne jedes 
problem.
-) du hast ein weit besseres flash/ram-Verhältnis als bei avr
-) der at91sam7s kostet nahezu gleich viel wie die avr's
-) du kannst die gleiche entwicklungsumgebung benutzen wie beim arm9

gruss
gerhard

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Gerhard,

das wäre natürlich auch eine Lösung. Zum Thema Erfahrung mit ARM9:
Habe zwar ein ARM9 Evaluierungsboard von Conitech hier rumliegen, 
allerdings habe ich bisher aus Zeitgründen kaum mit dem ARM9 spielen 
können (ausser vielleicht einem "Hallo Welt" Programm), und da der ARM9 
unter Linux läuft wären die Gemeinsamkeiten schon begrenzt.

Der Vorteil läge aber wohl vor allem in den Geschwindikkeitsreserven und 
der hardwareseitigen Ähnlichkeit beider ARMs. Kannst Du mir 
zufälligerweise einen geeigneten ARM7 empfehlen (vorzugsweise von 
ATMEL), dann werde ich mir das Datenblatt schon mal zu Gemüte führen...
Wie werden die ARM7er eigentlich programmiert? Über einen Bootloader wie 
der 9er, oder gibts da eine ISP Lösung?

Gruß Peter

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo peter,
wenn ich die angaben aus deinem 1.posting ansehe sollte eigebtlich ein 
at91sam7s reichen. datenblatt findest du auf der atmel homepage, 
erläuterende infos auf www.at91.com.

zu deiner frage betreffend isp:
ja es gibt eine einfache isp-lösung (nennt sich sam-ba), ist allerdings 
eine sehr mühsame sache und damit kannst du nur das flash programmieren 
(und ev. das sonstige memory bearbeiten). besser du verwendest einen 
jtag-ice. ich habe den j-link (in verbindung mit iar ewarm) im einsatz. 
eine günstigere lösung ist sicher der ARM USB JTAG für OpenOCD (von 
olimex, gibts hier im shop) in verbindung mit gdb.

gruss
gerhard

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
peterguy wrote:

> Das Herzstück des
> Loggers bildet ein ARM9 von Atmel, auf dem Linux läuft.

Wow !

Da würde mich mal interessieren, was ein Linux auf einem Datenlogger 
bringt ?

Wieviel GB an Daten müssen denn so geloggt werden ?

> Über SPI sollen
> nun zahlreiche Microcontroller angesprochen werden.

SPI ist da definitiv nicht so der Bringer.
Besonders, da die AVRs keine Sendepuffer haben. Du mußt Dir entweder 
noch zusätzlich Handshakesignale definieren oder immer nach jedem Byte 
lange Pausen lassen, damit die AVRs das nächste Byte in das 
Senderegister stellen können.
Etwas besser sind da die AT89LP4051, die haben noch ein Byte Puffer und 
Interruptprioritäten, damit sollten die 4MHz klappen.

Ich kenne ja nur die ARM7 (LPC2xxx), und die haben ein I2C, womit man 
wesentlich besser MCs vernetzen kann, wenn wie bei Dir keinerlei hohe 
Zeitanforderungen bestehen.
Der I2C hat quasi das Handshake schon im Protokoll, d.h. es kann nie 
einer zu langsam sein.

Obwohl ich ja bei Vernetzung eindeutig CAN favorisiere (z.B. 
AT89C51CC03), ist ein rundum sorglos Protokoll.
Und das Programmieren kann gleich über den CAN mit erfolgen 
(Custom-Bootloader).


Peter

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da würde mich mal interessieren, was ein Linux auf einem Datenlogger
> bringt ?
vielleicht weil er ein filesystem braucht?
oder weil es die hardware schon gibt?

> SPI ist da definitiv nicht so der Bringer.
diese aussage ist zu generell, sie trifft wohl auf die avr's zu aber 
sicher nicht auf den at91sam7s (aufgrund pdc).

gruss
gerhard

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gerhard wrote:

>> SPI ist da definitiv nicht so der Bringer.
> diese aussage ist zu generell, sie trifft wohl auf die avr's zu

Die Frage war doch gerade auf AVRs bezogen (und daher auch so 
beantwortet) oder hab ich da was falsch verstanden ?

Und die genannte Lösung ist ja kein AVR.


Peter

Autor: Peter Weber (peterguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wow !
>Da würde mich mal interessieren, was ein Linux auf einem Datenlogger
>bringt ?

Das Gerät soll mit unterschiedlichen Speichermedien klar kommen. Z.B. 
stehen USB und SD-Card im Lastenheft. Eine entsprechende 
Schnittstellenunterstützung sowie ein Filesystem sind also unumgänglich.
Zudem wird der Datenlogger sehr modular aufgebaut und mit der gewählten 
Konstellation bleiben nach hinten raus genug Reserven.

>Wieviel GB an Daten müssen denn so geloggt werden ?

Soviel wie das Speichermedium abkann. Bei Datenerfassungsraten von bis 
zu 20Hz kommt da schon ein nettes Sümmchen zusammen, wenn der Logger 
mehrere Stunden läuft.

>Obwohl ich ja bei der Vernetzung eindeutig CAN bevorzuge.

Ja, an CAN hatte ich im Ersten Entwurf auch gedacht. Allerdings macht es 
in meinen Augen wenig Sinn, an den ARM9 ein SPI-CAN IC zu hängen um dann 
am Ziel (im schlimmsten Fall) mittels CAN-SPI Wandler wieder an die 
Daten ranzukommen. Zudem war mir unklar, ob nicht noch entsprechende 
Transceiver Bausteine benötigt würden.
Da SPI sowieso für mehrere Bausteine (z.B. OLED, SD-Card) gelegt werden 
muss, habe ich mich für diesen Bus entschieden.
Ein riesen Vorteil von CAN wäre natürlich die Bootloadergeschichte, mit 
der ein Firmwareupdate möglich wäre. Mit SPI sollte das aber doch auch 
zu machen sein, oder?

Ich denke mal, daß Ich anstelle der 3 AVRs einen ARM7 nehmen werde. Da 
beides für mich Neuland ist, wird der Zeitverlust fürs Einleren hier wie 
dort ungefähr gleich sein..

Gruß Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.