Hallo Gemeinde, aktuell bastel ich mit einer Flut an Sensoren. Bei dieser Bastelei werde ich nicht mit einem typischen ATMEGA128 oder einen der großen XMEGAS auskommen. Ist alles nicht eilig und bin grad am lesen und stöber. Ich brauch mehr Mips und mehr Pins, die direkt am Mc sind, da es sich um eine sehr zeitkritische Anwendung handelt. Bislang hatte ich nur mit Assembler, C (AVR-GCC) und Bascom gearbeitet. Das läuft mir auch recht flüssig von er Hand. Bislang auch viel AVR 8-bit also Attinys, Atmegas und auch schon Xmegas. Gibt es Aufgrund des vorhanden Wissens bezüglich der AVR Schiene eher die Empfehlung richtung ARM9 zu gehen also die von Atmel. Oder wäre das bei einem Umstieg in Richtung ARM erstmal egal bzw. empfehlenswerte Alternativen? In welche Richtung sollte ich (aufgrund der AVRs usw.) schauen um einen Einstieg in die nächste Leistungsklasse zu bestreiten? Dev-Board Empfehlungen? Gern auch was bei dem schon einige APIs dabei sind. Es kann gerne auch was kosten, für neues Wissen gebe ich gerne ein paar Euro mehr aus (Bin aber dennoch kein Millionär :-) ).
Wie rechenintensiv ist dein Vorhaben? Schon mal an programmierbare Logik gedacht?
Viele Sensoren? Schau Dir mal die dsPIC33 an, die sind auf Signalverarbeitung optimiert, haben viele Pins, viele und schnelle ADCs (bis 4 MSamples/sec)
Da muss ich ehrlich gestehen, das ich mich mit den Bereich VHDL usw. bis dato noch garnicht beschäftigt habe. Kenne also Keinerlei vorzüge bzw. Möglichkeiten dieser Technik. War bislang wie gesagt nur bei den 8Bittern von Atmel, damit zwar viel aber eben mit Scheuklappen anderen Möglichkeiten gegenüber. Über die exakte benötigte Rechenleistung und Anzahl an Möglichen direktansprechbaren I/Os sowie Schnittstellen bin ich mir leider noch nicht exakt im Klaren. Bis jetzt komme ich auf ca. 50 I/Os und 4 mal RS232 + X. Grobe also wirklich ganz grobe MIPs Anzahl würde ich mal in Richtung 66 MHz legen, aber auch gern mehr. Aber es ist wie es beim Basteln ist, wenn mal was gemacht wurde, wird es auch gerne erweitert. Manchmal auch komplett umgeschmissen. Dennoch wäre es mal interessant sich in einen neuen Bereich umzuschauen.
8Bitwechsler schrieb: > In welche Richtung sollte ich (aufgrund der AVRs usw.) schauen um einen > Einstieg in die nächste Leistungsklasse zu bestreiten? AVR32?
AVR32 halte ich persönlich für ne Totgeburt. Ich würde dir den STM32Fxxx empfehlen. http://www.st.com/internet/mcu/subclass/1169.jsp
Bin vor kurzem von AVR nach ARM7 (LPC2478) umgestiegen, allerdings nur als Zwischensprung zur ARM9 Fraktion. Mit ARM ist man bestens bedient, riesige community, sehr viele Beispiele und vieles mehr, was vor allem Anfängern zu Gute kommt.
LPC1768 / LPC1769 -> 100/120MHz, 100Pins, 4x UART LPC1758 / LPC1759 -> 100/120MHz, 80Pins, 4x UART Diverse PIC32 -> 80MHz, 80/100Pins, bis 6x UART STM32F1xx hat nur bis 3x UART wenn ich das richtig sehe. Es gibt anscheinend welche mit 5, allerdings ist das die low-cost Reihe mit max. 24MHz. Die STM32F2xx könnten mehr haben, sind soweit ich weiß aber noch nicht lieferbar.
Michael G. schrieb: > Die STM32F2xx könnten mehr haben, sind soweit ich weiß aber noch nicht > lieferbar. Falsch: STM32F2xx == lieferbar. Mache selbst Sensoren auf Basis STM32F1xx und habe keine Probleme. SPI, I2C, USARTS und CAN in vollem Einsatz. STM32F2xx liegt schon hier und wartet auf Portierung. Tools sind Yagarto mit gcc > 4.5.x und OpenOCD mit OpenOCD-USB als Dongle aus dem Web-Shop hier. Debugging mit insight-gdb. Einzig kommerzielles hier ist source-insight als Editor. Eclipse ist einfach viel zu Ressourcen-fressend. Gruß, Ulrich
8Bitwechsler schrieb: > Über die exakte benötigte Rechenleistung und Anzahl an Möglichen > direktansprechbaren I/Os sowie Schnittstellen bin ich mir leider noch > nicht exakt im Klaren. Bis jetzt komme ich auf ca. 50 I/Os und 4 mal > RS232 + X. Grobe also wirklich ganz grobe MIPs Anzahl würde ich mal in > Richtung 66 MHz legen, aber auch gern mehr. > Aber es ist wie es beim Basteln ist, wenn mal was gemacht wurde, wird es > auch gerne erweitert. Manchmal auch komplett umgeschmissen. > Dennoch wäre es mal interessant sich in einen neuen Bereich umzuschauen. ARM9 wirst Du nicht löten können, hier kommst Du in Bereiche, wo es die Bausteine nur noch als BGA gibt. Also ist Cortex M3 das Maximum, was Du realistisch verarbeiten kannst. Es sei denn, Du verwendest ein Prozessormodul mit ARM9 oder Cortex A8, an das Du Deine Peripherie anbastelst. Meist hast Du dann aber auch gleich ein Linux mit an der Backe, das Du oft gar nicht willst, weil es das ganze gleich viel fetter macht als beispielsweise ein FreeRTOS oder ein RTEMS. Andere Option: PIC32. Da ist MIPS drin, in etwa gleiche Leistungsklasse, aber der Herstellersupport von Microchip ist anerkanntermaßen einer der besten in dieser Branche. Du wirst es viel einfacher haben: auf der Microchip-Seite gibts fix und fertig alles, was Du brauchst: IDE (MPLAB), Compiler (C32 Lite), Bibliotheken, dazu einer der angeboteten Debugger (PicKIT3 für den schmalen Geldbeutel, ICD3 und RealICE für die Profis), und auf gehts. Es kommt alles aus einer einzigen Quelle, es passt alles perfekt ineinander, und die Dokumentation ist auch nicht die schlechteste. Für Einsteiger ist das einfacher als sich alles aus verschiedenen Ecken zusammenzusuchen und zusammenzubasteln. Und die Tools könne mit Ausnahme des Compilers für alle Architekturen von Microchip verwendet werden - vom kleinen 8-Pinner bis zum 32 Bit MIPS im 121'er BGA. Auch die Bibliotheken sind soweit möglich für alle Architekturen gleich. fchk
8Bitwechsler schrieb: > aktuell bastel ich mit einer Flut an Sensoren. Wieviel 1000 Sensoren denn und was für welche? 8Bitwechsler schrieb: > Bei dieser Bastelei werde > ich nicht mit einem typischen ATMEGA128 oder einen der großen XMEGAS > auskommen. Dann solltest Du erstmal rauskriegen, wo der Flaschenhals sitzt. Die reine CPU-Leistung wird es mit hoher Warscheinlichkeit nicht sein. Wie oft müssen die Sensoren abgefragt werden, d.h. welche Datenrate ist zu erwarten und was soll mit den Daten überhaupt passieren? Usw. Dein bisheriger Ansatz: "Ich nehme mal ne 66MIPS CPU und wurstele so drauf los", wird bestimmt nicht zielführend sein. 8Bitwechsler schrieb: > Manchmal auch komplett umgeschmissen. Nur, wenn man sich vorher wenig bis garkeine Gedanken macht. Einen gute Planung spart hinterher mindestens das 10-fache an Nacharbeit ein. Peter
Hi Peter, da hast Du natürlich recht. Ich hatte aber keinen 32 Bitter empfohlen, weil der auf jeden Fall passt, sondern, weil dieser die üblichen 10..16 Bit breiten Messwerte in einem Stück verarbeiten kann. Effektiv kann man damit Flash sparen und auch mit der Taktrate herunter gehen. Damit kann sinkt die Leistungsaufnahme und der DC/DC kann preiswerter ausfallen. Und da es eben unter den STM32 eine ganze Familie gibt, kann man munter mit einem 512k/64K 10x-Pinner los legen und die Serie auf einem 32k/8k auflegen, der nur mit 16MHz bei wenigen mA vor sich hin dümpelt. Ist günstiger als eine 8-Bit Lösung und das vor allem dann, wenn die letzten 4 Bytes Flash nun doch nicht ausgereicht haben oder man eben doch das ein oder andere Telegramm auf dem Bus verliert. Im 8-Bit Fall: Redesign; im Cortex Fall: einfach pinkonpatiblen größeren Bruder nehmen resp. PLL umprogrammieren. Wenn man Serie produziert, nimmt man den Chip, den der Bestücker ohnehin in Masse auf Lager hat, auch wenn er ein paar k Flash zu viel hat. Das ist billiger als extra ein paar nur für sich zu bestellen. Leider schreibt der TO (wie so viele) nicht wirklich, was er braucht. welche Sensoren an welchem Bus mit welcher max. Latenz auf welche Aktoren. Das wären Dinge, mit denen man rechnen kann und dann gäbe es auch eine Aussage was geht und was nicht. Gruß, Ulrich
Der Sprung auf ARM9 ist schon ein großer, da würde ich mir vorher mal die erwähnten ARM7 (LPC) oder Cortex M3 (STM32) anschauen. Falls die wirklich nicht reichen kann man sich auch überlegen mehrere Controller zu verwenden, z.B. ein paar kleinere um die Sensoren auszulesen und die Daten aufzubereiten und einen größeren zur Auswertung und Koordinierung.
Hallo, stimmt, war mit Infos etwas geizig. Es sind ja 2 Dinge die ich erschlagen möchte: Zum einen die Einarbeitung in einen anderen Prozessor (Wissensdurst) es wurden ja sehr viele genannt, da werde ich erstmal viel schmökern müssen, bis ich mich entscheide. Auf jeden Fall schonmal danke für die Tips und Ansätze welche Prozessoren interessant wären. Es geht um Winkel/Hallsensoren, Ultraschall, div. Serielle eingaben von z.B. GPS, usw. , Steuereung von bis zu 8 Schrittmotoren an deren Achsen die Hallsensoren angebracht sind. Dazu eben noch Display, Tastatur, Evtl. ein Paar 7 Segment anzeigen (Weniger kritisch, geht ja ohne probleme mit 595er usw. Für mich wäre es wichtig in Echtzeit aufgrund der Sensorik mit den Schrittmotoren zu agieren bzw. zu reagieren. Dazu kommt eine Flut an berechnungen. Es soll ja nicht dauernd zum Stillstand kommen um zu rechnen. Es ist einfach eine Robotik bastelei, die mich sicherlich einige Zeit beschäftigen wird. Und in diesem Fall ist mir eben ein Prozessor mit viel Reserve lieber als dauernd ein Redisgn durchzuführen. In diesem Fall zumindest für mein Empfinden sinnig. Werde mich jetzt aber erstmal über Details der genanten Prozessoren informieren. Die Evaluierung wird sicherlich auch erstmal etwas dauern. Aktuell werkelt ja schon ein Mega128 mit einigen der Komponenten, ist aber leider schon am Limit. Auf jeden Fall schonmal danke für die reichlichen und begründeten Infos!
@8Bitwechsler: Also für einen Roboter würde ich wirklich mal über die Anregung von Horst nachdenken. Einen Controller der gleichzeitig in Echtzeit irgendwelche Berechnungen machen soll und dann aber auch noch ein Bedieninterface bedienen soll halte ich für unglücklich. Warum nicht z.B. einen Controller der die Motoren anhand von irgendwelchen Vorgaben von außen steuert? Dann einen weiteren für das Bedieninterface und die 'High Level'-Sachen usw.. Nur so eine Idee.
Ich würde je Motor + Sensor einen eigenen MC benutzen, der dann vom Master nur Kommandos empfängt (Fahrweg, Geschwindigkeit). Z.B. der ATtiny261 hat einige nette PWM-Funktionen: • 10/8-Bit Accuracy • Three Independent Output Compare Units • Independent Dead Time Generators for each PWM channels • Fault Protection Unit Peter
Alles absolut richtige Aussagen, es lässt sich auch darüber streiten ob sinnig oder nicht z.B. jeden Sensor mit Motor einen eigenen uC zu spendieren. Habe ich für mich auch mal durchgespielt. Bin aber erstmal davon weg, da ich es in einem Haben möchte. Die Bedienung erfolt nur im Stillstand, also wenn keine Sensoren und Motorsteuerung nötig sind. Lediglich die Anzeige auf dem Display bzw. Segmentanzeige erfolgt.
8Bitwechsler schrieb: > Alles absolut richtige Aussagen, es lässt sich auch darüber streiten ob > sinnig oder nicht z.B. jeden Sensor mit Motor einen eigenen uC zu > spendieren. Ich versuche immer, möglichst wenige Leitungen zu ziehen und daher sind intelligente Aktoren besser. Auch möchte ich nicht die Leistungsströme der Motor-PWM über lange Kabel führen und mir damit nen Haufen Störungen erzeugen. Nichts ist unangenehmer, als wenn die Haupt-CPU sporadisch abstürzt beim Schalten der Motoren. In kommerziellen Produkten ist auch zu beobachten, daß man weg davon geht, separate Ansteuerungen zu bauen. Die Motoren werde direkt mit dem Leistungsteil+Controller verheiratet und nur die unkomplizierten DC-Versorgungsleitungen und der Steuerbus werden angeschlossen. Man spart sich damit die teuren doppelt geschirmten Kabel zur Steuerelektronik ein und die CE-Zertifizierung wird einfacher. Peter
Hi! Da kann ich Uwe, Jens und Peter nur zustimmen. Zerlege den Roboter in logische Einheiten und löse jede Aufgabe getrennt. Es ist immer leichter 4 Aufgaben nachträglich in eine CPU zusammen zu fassen, als 4 mal fest stellen zu müssen, dass es nicht reicht. Andererseits ist es auch einfacher mit einem CPU-Typ zu hantieren statt 4 verschiedene (allein schon wegen IDE, Programmer, Stecker...) Also schnapp Dir einen STM32F103 mit 128k und programmier den Bewegungsapparat, also PWM->Räder/Beine/Servos. schnapp Dir einen zweiten und programmier die Sensorik. Schnapp Dir einen kleinen STM32F101 oder ähnlich und mach ein kleines LCD, ein paar Tasten und einen IR-Empfänger dran oder ein Bluetooth-Modul. Dann klemmt man die alle zusammen an einen RS485 oder CAN und schon funktionierts. Du wirst immer wieder fest stellen, dass es hier und da noch Freiraum gibt, also kann man vielleicht wichtige Sensoren für die Bewegung doch noch an die CPU vom Fahrwerk klemmen. Oder die Display-Keypad CPU hat noch Ressourcen frei und man kann US und Helligkeitssensoren eben dort noch mit dran hängen. Oder Du findest ein direktes Camera-Interface toll, dann nimmst Du eben den STM32F20x und hast mit 120MHz sogar noch Zeit für Kursberechung. Die Dinger sind nicht so teuer, dass man nicht mal einen auf Seite legt und einfach einen anderen nimmt. Aber bei einem Prototypen oder einer Hobby-Bastelei ist es sehr frustrierend, wenn man minimalistische Lösungen dauernd gegen die (Leistungs-)Wand fährt. Auf jeden Fall bieten Dir CortexM3 Prozessoren einem Menge Features, die kein 8-Bitter halten kann. Bei einem STM32F20x oder F103 kannst Du sogar noch externes RAM oder FLASH dran klemmen, falls es am Ende doch nicht reicht oder per externem RAM und SD-Carte gleich von letzterer booten. Das ist Speicher, den man Layouten und mit dem man basteln kann. Gruß, Ulrich
Hallo, ich habe mich nun etwas eingelesen und mich erstmal für die STM32 Schiene entschieden. Gibt es eine Empfehlung für ein Devboard? In die Richtung wie z.B. STK500 also Programmer usw. mit Onboard (JTAG). Sockel für CPU muss ja keiner drauf sein, reicht wenn ein STM32 (evtl. ein größerer auch gern mit Netzwerk) von Haus aus drauf ist. Erfahrungen?
Also beim STM32 gibt es einige DevKits. Das original von STM ist das STM3210E-EVAL, dort ist ein dicker STM32F107 drauf mit USB, CAN, Ethernet, Display, liegt aber um die 150€. Dann gibt es ein ähnliches Board mit ähnlichem Namen von Olimex, dort sind einige Komponenten preiswerter ausgeführt, so ist nur ein kleines Handy-Display drauf, aber es sind ebenfalls alle Schnittstellen herausgeführt, die man so braucht. Das Board liegt unter 100€. Dann gibt es noch die kleinen Kits, also so eine Platine auf der einiges drauf ist, aber die eher alles auf Pinne nach unten geführt haben. Leider habe ich den Namen nicht im Kopf und der Kollege, der eines hat ist nicht da. Ich rate dringend dazu, sich den JTAG aus dem Shop zu kaufen, irgend einen, der mit openocd zusammen funktinoiert. ich haben hier massenweise die http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=14 im Einsatz. Die Programmieradapter, die auf den Kits fest drauf sind, sprechen nicht JTAG sondern ST-Link, womit man auf die kommerziellen IDEs festegelegt wäre. Aber alle genannten Kits haben auch einen 1:1 passenden JTAG Stecker drauf. Gruß, Ulrich
>dann nimmst Du eben den STM32F20x und hast mit 120MHz...
Nicht, wenn das Progr aus dem Flash läuft. Dann sinds wohl nur ca 30MHz!
(Der Accelerator (auch bei den neuen )geht nur in Ausnahmefällen)
@MCUA bei mir läuft der accelerator perfect auch wenn das programm im flash ist. spürbar schneller als lpc1769 (nur erster eindruck).
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.