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 :-) ).
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?
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)
