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
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.
>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.
>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.
>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/Porterweiterung_mit_SPI
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.
>... 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...
>(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?
>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.
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
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
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
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
> 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
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
>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
