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
Hallo Peter, ein ATmega8 könnte z.B. diese Anforderungen erfüllen. Software und Programmierkabel: http://s-huehn.de/elektronik Bernhard
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?
Auf AVRfreaks.net gibts eine dynamische Vergeleichsttablelle aller AVRs: http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=devCompare Einfach oben die Familie auswählen und unten die Features die man vergleichen will. Ziemlich praktisch finde ich. Rince
>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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.