Hallo, Ich schließe langsam meine Masterarbeit ab und arbeite gleichzeitig als HiWi in der Uni. Mein HiWi-Betreuer hat mir folgende Aufgabe gegeben: "Für unsere Labor brauchen wir 3 Modulen für die Ventilsteuerung. Diese werden mit den Schrittmotoren gesteuert. Du kannst die Module irgendwo aussuchen oder selbst bauen, es liegt völlig an dir. Wenn Du willst nimm einfach Arduino mit Shields oder wie du es sonst lieber hättest.Dieses Projekt kann ruhig 3 Monaten dauern..." Der Betreuer hat nicht so viel Ahnung von µC. Ich würde gerne die ganze Steuerung selbst bauen,d.h.einen µC aussuchen, mit einem Dev. Kit. Anfangen, dann eigene PCB erstellen usw. Ohne Arduino-Kindergarten also. Ich will noch einmal richtige Erfahrungen sammeln und irgendwas herstellen, was ich später meinem potentiellen Arbeitsgeber als fertiges Projekt zeigen könnte. Sooo.... Nun stehe ich vor dem Wahl eines richtigen µC für meinen Zweck. An sich soll der µC einen Steppermotor ansteuern, über USB mit Labview kommunizieren, dazu noch ein paar Taster und ein kleines Display. Gearbeitet habe ich bisher ein wenig mit MSP430, und recht viel mit EFM32 ARM M0+. https://hackaday.io/project/8610-coaster Ich würde gerne einen ARM nehmen (M0 oder M3 sollte eigentlich für meine Anwendung keine Rolle spielen). An sich , so wie ich gesehen habe, ist egal welchen Hersteller ich nehme: NXP, SiliconLabs, STM , Infineon etc. Gibt es spezielle Empfehlung ihrerseits? Irgendwelche µC die für meine Anwendung besonders geeignet sind?
Arm (M3) ist doch noch schlimmer als Arduino. Nimm direkt einen 8-Bit AVR, GCC-Tutorial dazu gibt es hier auf der Seite.
Moin, Böser K. schrieb: > Ohne Arduino-Kindergarten also. > Ich will noch einmal richtige Erfahrungen sammeln und irgendwas > herstellen, was ich später meinem potentiellen Arbeitsgeber als fertiges > Projekt zeigen könnte. Potentielle Arbeitgeber wissen's auch zu schaetzen, wenn der Entwickler nicht stumpf drauflosentwickelt, weil's ihm soviel Spass macht, sondern vorher durchaus guckt, ob man nicht irgendwas halb-dreiviertelfertiges zum Spottpreis irgendwo einkaufen kann. Insofern wuerd' ich z.b. "Arduino-Kindergarten" vielleicht doch nochmal genauer anschauen, ob's da nicht fuer relativ kleines Geld eine fertige Hardware gibt, die du niemals fuer aehnlich wenig Geld/Zeit selbst entwickeln koenntest. Umso mehr Zeit haettest du uebrig fuer Softwareentwicklung, Biertrinken, etc. Gruss WK
Wenn du wirklich kein Arduino nehmen willst kannst du dir mal die ATMega Reihe anschauen. Sehr beliebte µC die an sich auch gut funktionieren. Zum Beispiel den ATmega328P. Letztendlich ist ein Arduino aber nichts anderes als ein µC mit der benötigten Elektronik drumherum. Die kann man zwar sehr einfach selber bauen, doch ist der Nutzen insgesamt begrenzt. Man muss nicht unbedingt die Arduino Libarys benutzen. Die µC lassen sich auch mit normalem C programmieren.
Da Du offensichtlich schon Erfahrung mit dem Simplicity Studio hast, Silabs selber empfiehlt für Motorsteuerungen ja die EFM8 Busy Bee da robuster als die EFM32 und auch Industrial / Automotive Grade http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx Ansonsten gibt es spezielle ARM für Motorsteuerung, also mit QEI und State Machine PWM z.B. LPC1500 und hier gibt es ein günstiges Board wo auch Arduino Shields drauf passen: http://www.embeddedartists.com/products/lpcxpresso/lpc1549_xpr.php Programmierung mit LPCXpresso (praktisch dasselbe wie Simplicity Studio) oder IAR (besser) mit 32K Limit (das sollte aber reichen): http://www.nxp.com/products/software-and-tools/hardware-development-tools/lpcxpresso-boards/lpcopen-software-development-platform-lpc15xx:LPCOPEN-SOFTWARE-FOR-LPC15XX http://www.nxp.com/products/software-and-tools/software-development-tools/software-tools/lpc-microcontroller-utilities/lpcxpresso-ide-v8.2.0:LPCXPRESSO
Chase schrieb: > Wenn du wirklich kein Arduino nehmen willst kannst du dir mal die ATMega > Reihe anschauen. YMMD! :-)))))
Du hast nur was von FVentil/Schrittmotor-steuerung geschrieben, die Teile werden normalerweise per PWM angesteuert. Wirlich empfehlen kann man deshalb nichts, da jeder aktuelle MCU viele Timer (für PWM) hat und sie sich dann nru noch mit den anderen Peripherals unterscheiden. Du kannst also eigentlich den kleinsten nehmen, den du findest (in den M0 reihen oder so). Außer die Ventilsteuerung soll durch irgendwas spezifisches kontrolliert werden (UART etc), dann muss man halt wegen den periphs schauen.
Auch ein ATTiny (2313 z.B.) käme hier in Frage. Ich würde aber auch mal schaun, ob es nicht schon was Fertiges gibt. Eine Voraussetzung ist anscheinend LabView...via USB. Klar, kann man machen aber die USB-Implementation, so denn sie denn wirklich sauber/vernünftig sein soll, kann einen locker drei Monate kosten wenn man sowas bisher noch nicht gemacht hat. Das ist nämlich alles andere als Einfach wenns nicht auf einen USB2Serial-Adapter hinauslaufen soll.
Pete K. schrieb: > Chase schrieb: >> Wenn du wirklich kein Arduino nehmen willst kannst du dir mal die ATMega >> Reihe anschauen. > > YMMD! :-))))) Aber echt, .. lol ... Will er jetzt zeigen wie man vom Platinenlayout über Programmierung und Debugging bis zum fertigen Steuerungsprodukt kommt? Damit das nicht so ein Kindergarten wird, muss man hier ein RTOS einsetzen, 32Bit-MC mit 80MHz und 128kB RAM. Das sind immerhin DREI Schrittmotoren die Ventile öffnen/schliessen sollen. ;)))))
Böser K. schrieb: > potentiellen Arbeitsgeber Da sich in der Industrie niemand für Arduino bzw. AVR interessiert passt ARM schon. Allenfalls noch EFM8/C8051 wird in der Industrie genutzt, die (bessere) Alternative zum XMEGA > USB mit Labview kommunizieren Bin kein Labview Freund aber in der Industrie sehr verbreitet. Würde auch für den schon erwähnten LPC1500 sprechen, da gibt es ein fertiges USB Interface.
Ich würde auf jeden Fall von AVRs abraten, da selbiger als veralteter Bastel-µC gilt. Nimm direkt etwas Zeitgemäßes und zeige deinem zukünftigen Arbeitgeber,dass du fähig bist moderne Werkzeuge zu nutzen. Ich würde zu einem CortexM3 oder M4 raten. Besonders viel Hilfe findest du zu den STM32-µCs. Daher könnte das ein geeigneter Kandidat sein.
Chris F. schrieb: > Das sind immerhin DREI Schrittmotoren die Ventile öffnen/schliessen > sollen. ;))))) ... und LV per USB. Scharfe Nummer.
Böser K. schrieb: > über USB mit Labview > kommunizieren, ... auch wenn oben etwas anderes gemeint wurde: LabView versteht die serielle Schnittstelle sehr gut. Von daher wuerde ich eben doch USB2RS232 und virtuellen Comport nehmen (wenn unbedingt ohne virtuellen Comport dann STM32F103 und dort aufsetzen) Wenn schon eine komplett eigene Hardware mit PCB (auch zum "Angeben" bei potentiellen späteren Arbeitgebern), dann kostengünstige Entwicklung: MCU: STM32F030 oder (wenn viele GPIO benoetigt werden) STM32F103C8 - mit libopencm3 USB2UART: CH340G (hab ich unter Windows 7 in LabView angebunden) Motortreiber: L298N
Lothar schrieb: > USB Ist zwar offtopic aber warum nicht über ethernet? Ich habe mich zuerst mit rs232 rumgeprügelt dann mit usb. Bis ich merkte, dass ethernet einfach die Top Kommunikationsschnittstelle zum oc für mich War. Ein simpler stack is relativ schnell aufgesetzt und es ist eine standardschnittstelle in der Industrie. Keine treiberspielereien wie bei usb und höheres Tempo als rs232.
wenn du darüber nachdenken mußt, solltest du mal nachdenken oder du hast zuviel zeit. jedes rad 1000 mal erfinden?
Wenn du die Arbeitszeit rechnest und die Stückzahl (3) beachtest, dann MUSS die Antwort heißen : Steuerung, so fertig wie möglich. Also eine SPS oder etwas ähnliches. Ja, die kostet dann vermutilch 1k€/Stück oder so. Aber die ist fertig, getestet, und zuverlässig. Bei 3 Stück sind die hohen Stückkosten billiger als der Entwicklungsaufwand. Da braucht man nicht mal einen Taschenrechner, um das sicher sagen zu können. Dazu wird das Projekt damit dann auch tatsächlich fertig. Mit einer eigenen Steuerung wirst du in 3 Monaten nicht fertig. Du musst nämlich - dich in den µC einarbeiten - eine Hardware machen - die produzieren / in Betrieb nehmen ..zusätzlich zur eigentlichen Applikation. Nein, für 3 Stück macht man keine Eigenentwicklung! Natürlich kann die Rechnung fallweise anders aussehen, z.B. wenn du die Resultate für ein späteres Projekt benötigst. Aber in einer Firma macht man nichts einfach so "aus Interesse". Nicht wenn jemand die Arbeitszeit bezahlen muss.
Gästchen schrieb: > Aber in einer Firma macht man nichts einfach so "aus Interesse". Nicht > wenn jemand die Arbeitszeit bezahlen muss. Es ist aber keine Firma... Böser K. schrieb: > Ich ... arbeite gleichzeitig als HiWi in der Uni. > ...Dieses Projekt kann ruhig 3 Monaten dauern..."
Volker S. schrieb: > Böser K. schrieb: >> Ich ... arbeite gleichzeitig als HiWi in der Uni. >> ...Dieses Projekt kann ruhig 3 Monaten dauern..." Sinn machts trotzdem nicht. Einfach weil der Erkenntnisgewinn bei einer so trivialen Steuerung in keinem Verhältnis zum Aufwand steckt.
> Ich würde auf jeden Fall von AVRs abraten, da selbiger als > veralteter Bastel-µC gilt. Wer sagt das, du? Für mich ist die AVR Reihe nicht veraltet, da sie für viele meiner Anwendungsfälle geeignet sind und noch problemlos zu bekommen sind. Und warum meinst du, die AVR Serie sei veraltet? Komm mit bitte nicht mit dem Standard-Argument, dass andere Chips bei gleichem Preis/Größe/Stromaufnahme mehr Rechenleistung hätten. Das reicht mir nicht, um ein Produkt als veraltet zu bezeichnen. Mein 30 Jahre alter Casio Taschenrechner ist auch nicht veraltet, bloß weil ein neueres Modell vielleicht 10x schneller rechnet. Den er ist immer noch schnell genug - und darauf kommt es an. Mein 10 Jahre altes Auto ist auch nicht veraltet, bloß weil es schnellere Autos gibt. Dann wäre es nämlich schon von Anfang an veraltet gewesen. Das trifft übrigens auch auf sehr sehr viele Mikrocontroller zu. Komisch, was?
Wenn dir Arduino zu unprofessionell ist, könntest Du per Zeichenbrett ein Handrad für die Ventile designen und diese in einer Giesserei giessen lassen. Handfeste Hardwarelösung für Marlboro-Typen und absolut EMP-sicher... ;-)
Ach ja, da war doch noch was. https://www.raspiprojekt.de/kaufen/shop/raspberry-pi.html Technische Daten Chipsatz Broadcom BCM2837 mit Betrieb bei 1,2 GHz 64 bit Quad Core ARM Cortex-A53 802.11 b/g/n Wireless LAN Bluetooth 4.1 (Classic & Low Energy) Dual-Core-Coprozessor Videocore IV® Multimedia 1 GB LPDDR2-Speicher Unterstützt alle aktuellen ARM GNU/Linux-Distributionen und Windows 10 IoT MicroUSB-Anschluss für 2,5-A-Netzteil 1 x 10/100 Ethernet-Anschluss 1 x HDMI Video/Audio-Steckverbinder 1 x RCA Video/Audio-Steckverbinder 4 x USB 2.0-Anschluss 40 GPIO-Stifte Chip-Antenne CSI Camera und DSI Display-Steckverbinder Steckplatz für microSD-Karte Abmessungen: 85 x 56 x 17 mm
:
Bearbeitet durch User
Ok. Erstmal vielen dank für die Ratschläge. Was bei mir gegen Arduino spricht: Abgesehen von meiner subjektive Meinung und negativen Erfahrungen mit den "Ingenieuren" die ausschließlich mit Arduino arbeiten... Stellen wir vor, bei dem Vortstellungsgespräch werde ich folgendes gefragt: -Was haben sie schon so im Bereich µC and Hardware gemacht? Ich: Ja...ich hab mal Arduino Uno mit dem Motort-Schield in Betrieb genommen. Dazu habe ich einen fertige Bibliothek aus dem Internen genommen. Das ganze wird jetzt im Labor im Zusammenspiel mit Labview für die Ventilsteuerung verwendet. -Arduino? Na ja, wir arbeiten hier nicht mit Arduino. Wir entwickeln hier eigene Hardware, dazu verwenden wir seit Jahren den µC von STM (oder einen anderen Hersteller) und Ihr müsst unter Umständen selbst das Datenblatt des µC durchlesen, eigene Bauteile aussuchen,PCB layouten und vllt. alles selbst programmieren...ohne fertigen Bibliotheken aus dem Internet. Peinlicher wäre es noch, wenn der Vorgesetzter nicht weiss was Arduino ist, und ich muss ihm erklären, dass Arduino eine vereinfachte, zerkaute Lehrplatform für Einsteiger ist. Wie gesagt, das Projekt dringt nicht, und soll nebenbei laufen. Ich habe die LPC1500 und EFM32/8 angeschaut. Beide sehen recht gut aus. Was die USB<-> Labview angeht. Vorteil von EFM ist , dass ich damit schon gearbeitet habe und ein hübsches Gecko auf dem Chip hängt:) Ich kenne mich mit Labview gut aus: meine primären Aufgaben als HiWi sind Prozessautomatisierungen: Pumpen-, Laser-, Motorsteuerungen über Labview, Datenlogging, PI-Regelung des Induktionsoffens (bis 1800 C°), Umgang mit inkompetentem Kundensupport usw. Wir verwenden hier überall RS232<->USB Adapter (zum Teil weil viele Geräte nur über RS323 gehen), und ich dachte, wenn ich schon eigene Hardware baue, dann kann man von den lästigen Adaptern verzichten. Das Labview hat relativ einfache USB-Kommunikation, laut manuall soll man nur die PID/VID richtig einstellen und loss geht's... Nachtrag: Über die Verwendung von Rpi oder ähnlichen (sogar mit eingebauter WiFi für die drahtlose Steuerung !!) danke ich noch nach. Scheint für mich ein Overkill zu sein,ich mag sowas persönlich nicht.
:
Bearbeitet durch User
Stefan U. schrieb: > Für mich ist die AVR Reihe nicht veraltet, da sie für viele meiner > Anwendungsfälle geeignet sind und noch problemlos zu bekommen sind. Das Thema gibt es doch andauernd. Die Dinger werden bei Neuentwicklungen eingesetzt und auch im Automotive-Bereich sind die aktuell im Einsatz. Kann echt sein, dass es in 15 Jahren so einen QFP-32-chip gibt in dem ein 64Bit-MC ist, der alles kann, nix kostet und obendrein das kleinste was man bekommt. Bis dahin sehe ich das folgendermassen: "Bloß weil ein Pritschenwagen ein dickes Sofa direkt am Stück transportieren kann fahren ab morgen nicht alle mit Pritschenwagen herum."
Moin, Böser K. schrieb: > Ich: Ja...ich hab mal Arduino Uno mit dem Motort-Schield in Betrieb > genommen. Dazu habe ich einen fertige Bibliothek aus dem Internen > genommen. Das ganze wird jetzt im Labor im Zusammenspiel mit Labview > für die Ventilsteuerung verwendet. Ok, bislang nicht spektakulaer - aber es geht ja weiter: Du: Deshalb belaufen sich die Gesamtentwicklungskosten fuer das Projekt Bla auf EUR XY und die Entwicklung war nach 1 Monat abgeschlossen. Punkt. So schaut's aus... > -Arduino? Na ja, wir arbeiten hier nicht mit Arduino. Wir entwickeln > hier eigene Hardware, dazu verwenden wir seit Jahren den µC von STM > (oder einen anderen Hersteller) und Ihr müsst unter Umständen selbst > das Datenblatt des µC durchlesen, eigene Bauteile aussuchen,PCB layouten > und vllt. alles selbst programmieren...ohne fertigen Bibliotheken aus > dem Internet. Ja, das kannst du alles machen, wenn du ein Projekt an der Backe hast, was aus irgendwelchen Gruenden eben nicht mit Hardware von der Stange machbar ist. Aber nicht aus purem Jux und Tollerei - OK, an der Uni natuerlich schon noch eher... Natuerlich, wenn in der Firma schon seit 1840 der STM32 eingesetzt wird, dann siehts ganz anders aus; dann existiert ja schon Knowhow, etc. Ansonsten schaut man tatsaechlich, dass man bei eigenen Entwicklungen moeglichst wenige, idealerweise keine Bauteile "neu aussuchen" muss. Das zieht immer Papierkram und Aerger mit errata-sheets, schlechter Doku, Distributoren und Kaufleuten nach sich; wenns geht, vermeidet man den. > Peinlicher wäre es noch, wenn der Vorgesetzter nicht weiss was Arduino > ist, und ich muss ihm erklären, dass Arduino eine vereinfachte, zerkaute > Lehrplatform für Einsteiger ist. Was ist daran peinlich? Arduino ist eine Hardware, die man fuer kleines Geld nachgeschmissen bekommt (Nehm' ich mal an, ich hab' damit nix am Hut). Prinzipiell genau das gleiche wie ein Raspi. Sowas koenntest du auch niemals in vernuenftiger Zeit selbst designen. Wenn man's doch macht, brauchts stichhaltige Gruende. Gruss WK
Lass dich von den Laberköpfen hier nicht abbringen. Arduino ist genau so einen Bastlerkacke wie alle AVRs es sind. In der Industrie wird auf ARM gesetzt, wenn nicht ewiggestrige in der Entwicklung sitzen. Da du die Zeit und das Geld hast, zieh das Projekt von Grund auf durch und lerne dabei.
Motor Treiber Eval. Boards zählen zu dem beliebtesten was die Prozessor-Bauer anbieten. Da findet man evtl. auch für wenig Geld etwas was auch dem dauerhaftem Betrieb standhält. Gerade ST schmeisst ihr eval. Boards ja billigst unters Volk. Such´ doch einfach mal bei Mouser Motor Driver >> Engineering-Entwicklungstools. Vieleicht ist von den 364 Eins dabei was sich eignet. ST hat da schon einiges unter 30.´- Aufsteckmodule ab < 10.- Wirtschaftliches Denken ist ja auch eine Tugend die man vermarkten kann.
> Arduino ist eine Hardware, die man fuer kleines Geld > nachgeschmissen bekommt Die originalen Teile von Arduino sind sogar recht teuer. Aus China gibt es billige Clones, leider ist es bei denen Glückssache, in welche Qualität geliefert wird. > In der Industrie wird auf ARM gesetzt, wenn > nicht ewiggestrige in der Entwicklung sitzen. Sagt wer? Inwiefern hast du denn mit der Industrie zu tun? Wer von AVR abrädt, muss auch von PIC und MCS51 und dessen Nachfolger abraten. Du kannst ja das ja mal als Berater bei den Distributoren versuchen. Was wird wohl passieren? Goldregen oder Pech-Dusche? Möglicherweise wird die ARM Technologie genau so schnell wieder verschwinden, wie sie gekommen ist. Und dann sind alle in den Allerwertesten gekniffen, die sich auf ARM festgelegt haben. Diese Diskussion, welche µC-Technologie die beste ist, ist vollkommen Sinnlos, solange noch nicht mal nach dem "besten" µC verlangt wurde. Ich lass mir auch nicht im Autohaus das beste Auto zeigen, wenn ich eine Familienkutsche haben möchte. Da müsste ich dann schon eher nach der "besten Familienkutsche" fragen. Am Besten sind alle µC geeignet, welche die Anforderungen erfüllen. Noch wurden allerdings kaum Anforderungen genannt, die nicht von ALLEN Mikrocontrollern erfüllt werden. Es ist unwahrscheinlich, dass der TO jetzt irgendein K.O. Kriterium gegen ARM nennen wird. Und genau so unwahrscheinlich ist es auch, dass er ein K.O. Kriterium gegen irgendeine andere µC Serie (einschließlich AVR) nennen wird. > Arduino ist genau so einen Bastlerkacke Ist Dir Klar, welchen historischen Hintergrund der PC hat, vor dem Du gerade sitzt? Wenn nicht, dann Google mal nach "Microsoft" und "Apple". "Bastlerkacke" kann äußerst gewinnbringend sein.
Ich habe vergessen zu erwähnen das ein Vorteil von ST darin liegt das Sie neben Ihren ARM auch seit Jahren ein wichtiger Anbieter für Motor Treibern sind (Industriestandarts) und die Board entsprechen auch vernünftig beschaltet sind.
Stefan U. schrieb: > Wer von AVR abrädt, muss auch von PIC und MCS51 und dessen Nachfolger > abraten Keineswegs: 8051 z.B. als EFM8 ist von der Analog-Peripherie und vom Preis die deutlich bessere Alternative zum XMEGA der ja auch nicht mehr weiterentwickelt wird. PIC kommt immer dann rein, wenn es nur um den Preis geht, da kommt kein ATtiny ran. Chris F. schrieb: > Die ... AVR ... werden bei Neuentwicklungen eingesetzt und > auch im Automotive-Bereich sind die aktuell im Einsatz Kann bestätigen dass AVR begrenzt im Einsatz ist, aber nur noch Legacy Designs. Wie man auch im aktuellen Microcontroller Market Report sehen kann, nach Stückzahlen 30% 8051 30% ARM 10% PIC danach kommt lange nichts. Und nach Umsatz ist ARM 60% (sind halt immer noch teurer)
Ja und? Soll man jetzt nur noch die Produkte verwenden, die auch andere am meisten verwenden? Sind wir denn schon alle gleich geschaltet?
Stefan U. schrieb: > Möglicherweise wird die ARM Technologie genau so schnell wieder > verschwinden, wie sie gekommen ist. Und dann sind alle in den > Allerwertesten gekniffen, die sich auf ARM festgelegt haben. Klar, wahrscheinlich verschwindet die günstigere und leistungsfähigere Plattform eher wieder, als das alter, lahmer Schrott in den Ruhestand geschickt wird. Und bestimmt wir Microchip aktiv atmegas weiterentwickeln und vergünstigen, um ihren PICs Konkurrenz zu machen. Und wenn man sich auf AVRs versteift, ist man in den Arsch gekniffen, wenn Atmel weg ist. Ist ST weg, gibt es noch tausend andere Hersteller mit ARM Cores. Wesentlich sinnvoller also, auf ARM zu setzen. Stefan U. schrieb: > Ist Dir Klar, welchen historischen Hintergrund der PC hat, vor dem Du > gerade sitzt? Wenn nicht, dann Google mal nach "Microsoft" und "Apple". > "Bastlerkacke" kann äußerst gewinnbringend sein. Ich sitze vor keinem PC, sondern - wer hätte das gedacht - vor einem ARM-Device. Merkste selbst ne... Klar, für die Entwickler von Arduino ist Bastlerkacke gewinnbringend, für den Anwender nicht. Was MS oder Apple damit zu tuen haben soll, weiß ich nicht.
Stefan U. schrieb: > Sind wir denn schon alle gleich geschaltet Wenn du auf den Single Point of Failure Atmel stehst, bitte gerne. Ansonsten ist es sinnvoll darauf zu setzen, was es noch lange geben wird -> ARM. Moby A. schrieb im Beitrag #4693206: > Horst schrieb: > Arduino ist genau so einen Bastlerkacke > > Nö, umgekehrt: Aus Arduino ist eine ganze Industrie geworden. Die > Einfachheit hat es eben am einfachsten, viele Fans zu gewinnen, wenn die > Anforderungen erfüllt werden. Nur weil du zu blöd bist, ARM Assembler zu programmieren hängst du immernoch an deinen ollen AVRs?
Böser K. schrieb: > Über die Verwendung von Rpi .. danke ich noch nach Auch wenn Linux überall propagiert wird, in der Automatisierung hat man gerne eine physikalische Trennung von GUI (Windows, Linux) und Steuerung (Master-Mikrocontroller, SPS). Was ich aber tatsächlich schon gesehen habe sind zwei Pi: eines für GUI (Linux) und eines für Steuerung (Bare Metal)
Moby A. schrieb im Beitrag #4693206: > Aus Arduino ist eine ganze Industrie geworden Richtig aber Geld verdienen die die Arduino entwickeln und verkaufen und nicht die die mit Arduino entwickeln und Produkte mit Arduino drin verkaufen :-) Übrigens, Arduino hat ja schon länger gemerkt, dass AVR nicht so toll ist, und nachdem der Umstieg mit Arduino Zero auf Atmel ARM nicht so rund lief, mussten sie jetzt eine Kooperation mit ST eingehen und das kam dabei raus ist fast noch schlimmer: http://www.arduino.org/products/boards/arduino-star-otto
Moby A. schrieb im Beitrag #4693227: > Nur weil Du zu blöd bist irgendein stichhaltiges Argument für den > Umstieg zu nennen soll ich Zeit für was anderes investieren? Du kannst auf dem alten AVR-Schrott weiter deine ASM-Turnübungen machen, das interessiert mich nicht. Es geht nicht um DEINEN Umstieg. Sondern um den Neueinsteig vom TO und der ist sinnvollerweise NICHT AVR. Also lass den TO was vernünftiges lernen und zwing ihm nicht deinen alten Krempel auf.
Lothar schrieb: > Arduino hat ja schon länger gemerkt, dass AVR nicht so toll ist, Stimmt, ein weiteres sehr gutes Argument.
Moby A. schrieb im Beitrag #4693227: > stichhaltiges Argument für den Umstieg Warum machst Du Dir nicht selbst ein Bild: im heise MAKE dem Magazin für Arduino Jünger gibt es ein LPC810 DIP-8 Projekt mit Steckbrett-Schaltplan und DSP-Programm zum abtippen: Audioeffekte mit ARM-Achtbeiner http://www.heise.de/make/inhalt/2016/3/86/
Böser K. schrieb: > Ich: Ja...ich hab mal Arduino Uno mit dem Motort-Schield in Betrieb > genommen. Hast du ja nicht. Du hast eine Steuerung aufgebaut, auf Basis des Atmega 328 und diese entsprechend programmiert.
F. F. schrieb: > > Hast du ja nicht. Du hast eine Steuerung aufgebaut, auf Basis des Atmega > 328 und diese entsprechend programmiert. Naja, auch wenn man den ganzen Personalern den Spiegel vorhalten sollte, und selber nichts als heiße Luft zu produzieren, werden die Kollegen sehr schnell merken, ob jemand nur mit Stützrädern programmiert hat, oder wirklich programmieren kann.
Moby A. schrieb im Beitrag #4693281: > Was Leute wie Du nicht merken sind Techniken die vereinfachen und Deine > ARMselig komplexen Chips überflüssig machen. > > Fakt ist daß es für die Anwendung des TE keines ARM-Monstrums bedarf- > wie für so viele. Es hat niemand behauptet, dass der TO seine Aufgabe nicht mit AVRs erfüllen kann. Er hat aber ausdrücklich gesagt, dass es für Ihn eine Einarbeitung und Investition in die Zukunft sein soll. Und da ist es wesentlich sinnvoller, in ARMs Mühe zu investieren. Wenn man natürlich davon ausgeht, später im Job nur Lowtech zu entwickeln, und ein AVR dafür ausreicht, nimm den meinetwegen. Aber normalerweise haben (zumindest Uni-)Studenten Motivation, spannende und anspruchsvolle Dinge in der Zukunft zu tun.
Ich will zwar ihre spannende Diskussion nicht unterbrechen, aber...:) Als µC habe ich das hier ausgewählt: http://www.mouser.de/Search/ProductDetail.aspx?R=NUCLEO-F767ZIvirtualkey51120000virtualkey511-NUCLEO-F767ZI Scheint ein wenig zu viel für mein Projekt sein. Hat aber USB2.0 und außerdem auch Ethernet. Ethernet ist vor allem interessant, weil man das Modul einfach an das LAN-Netzwerk anschließen kann. Das spart die ganze USB Verkabelung (aktuell haben wir Dutzend 5-10 m lange USB-Kabel überall.) Für die Motorsteuerung nehme ich L6474: http://www.mouser.de/Search/ProductDetail.aspx?R=X-NUCLEO-IHM01A1virtualkey51120000virtualkey511-X-NUCLEO-IHM01A1 Zuerst werde ich alle mithilfe von Nucleo programmieren und austesten, später fertige ich eigene PCB...
Horst schrieb: > Wenn man natürlich davon ausgeht, später im Job nur Lowtech zu > entwickeln, und ein AVR dafür ausreicht, nimm den meinetwegen. Aber > normalerweise haben (zumindest Uni-)Studenten Motivation, spannende und > anspruchsvolle Dinge in der Zukunft zu tun. Offensichtlich hast Du nicht die geringste Ahnung wo AVRs überall eingesetzt werden. Geht es bei so einer Abschlussarbeit nicht darum zu zeigen, dass man begriffen hat worum es bei der Entwicklung geht? Dazu gehört auch, dass man nicht für den Betrieb einer Glühbirne ein Kernkraftwerk bauen muss. Ich finde Leute die für alles nur PICs oder AVRs nehmen wollen genauso beknackt wie die die für alles nur ARMs einsetzen wollen. Dieses engstirnige Bastlerdenken ist für mich der religionsartige Glauben an das Toolset mit dem man selber am häufigsten gearbeitet hat. Für den TE wäre es besser einen möglichst einfach zu dokumentierenden MC zu nehmen, die Aufgabe genau zu lösen, möglichst alle Teile selber zusammenzubauen und dann die Lösung superausführlich zu dokumentieren. Der hat ja jetzt noch nicht begriffen, dass es nicht darauf ankommt eine bestimmte Plattform einzusetzen, sondern eine Lösung und ein Produkt zu erstellen.
Böser K. schrieb: > Als µC habe ich das hier ausgewählt: > http://www.mouser.de/Search/ProductDetail.aspx?R=NUCLEO-F767ZIvirtualkey51120000virtualkey511-NUCLEO-F767ZI Jo, Cortex M7 mit 216MHz, FPU, 2M-Flash und 512K-Ram. Hoffentlich reicht das für drei Ventile ... Hol Dir bei Horst den Orden.
Na hoffentlich gibt es bald einen Cortex M8 mit 217MHz, FPU-256, 2.1M-Flash und 513K-Ram. Ich empfehle dir auch den Arduino, ist so ziemlich das Beste zum einsteigen. Alternativ kannst Du auch eine kleine Siemens-SPS nehmen, die läuft garantiert gut - ist halt kein µC.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4693281: > Moby A. schrieb: >> Lothar schrieb: >> XMEGA der ja auch nicht mehr weiterentwickelt wird >> >> Woher weißt Du das? > > Was ist jetzt Lothar? > Oder war diese Behauptung nur rhetorische heiße Luft? http://www.avrfreaks.net/forum/future-xmega?page=all Es wird zum Umstieg auf EFM8 geraten ...
Chris F. schrieb: > Offensichtlich hast Du nicht die geringste Ahnung wo AVRs überall > eingesetzt werden. > > Geht es bei so einer Abschlussarbeit nicht darum zu zeigen, dass man > begriffen hat worum es bei der Entwicklung geht? Dazu gehört auch, dass > man nicht für den Betrieb einer Glühbirne ein Kernkraftwerk bauen muss. Doch, aber das sind alles keine Neuentwicklungen. Wer AVRs noch in Neuentwicklungen einsetzt, dem ist nicht zu helfen. Spätestens seit Microchip die gekauft hat, sollte man da einen ganz großen Bogen drum machen. Kannst du nicht lesen? Der TO hat was von Hiwi-Job geschrieben, wo das gemacht werden soll. Sprich also bezahltes Erfahrung sammeln mit Auswahl worin. Und da ist ARM der Weg der Wahl. Ob der M7 jetzt dafür nötig war, wage ich stark zu bezweifeln. Ein M0 hätte es wohl auch getan. Jedenfalls ohne die zusätzliche Anforderung von Ethernet. @Moby: warum bist du bei deinen Supportern eigentlich noch nicht wegen Arduino völlig ausgeflippt, wo das doch kein ASM ist, sondern böses C++ auch noch?
Chris F. schrieb: > Cortex M7 mit 216MHz, FPU, 2M-Flash und 512K-Ram Es gibt einen großen Bedarf an kleinen uC bis 64K Flash und 4K RAM der weitgehend durch günstige 8051 und PIC abgedeckt wird. Vergleichbare AVR und XMEGA sind doppelt bis dreimal so teuer, warum sollten die eingesetzt werden. Bei mehr RAM sind die M0 und M3 die beste und günstigste Lösung und für digitale Regelung noch M4 bevorzugt als M4/M0 Kombi z.B. LPC4300 Der M7 sollte die Lücke zum R5 schliessen, da habe ich aber meine Zweifel. Der M7 ist wegen des M Interruptssystems nicht für harte Echtzeit geeignet, Automotive Control uC setzen auf R5
Hört hier eigendlich irgendjemand dem TS zu? Böser K. schrieb: > Hat aber USB2.0 und > außerdem auch Ethernet. Ethernet ist vor allem interessant, weil man das > Modul einfach an das LAN-Netzwerk anschließen kann. Das spart die ganze > USB Verkabelung (aktuell haben wir Dutzend 5-10 m lange USB-Kabel > überall.) Die 3 Ventile scheinen scheinen da die kleinste Hardwareanforderung zu sein. Mir fallen spontan wenig Lösungen ein, die günstiger zu haben sind. Dass das X-NUCLEO-IHM01A1 Board einfach aufsteckbar ist, mag dem anspruchsvollen Bastler zwar wehtun, genauso, dass 90% des Flashs unbenutzt bleiben. Aber man kann eben nicht alles haben ... Ich halte die Lösung des TS für sehr vernünftig. Viele Grüße, Stefan
Ethernet kann man auch mit wenig Aufwand anbinden. Es ist ja kein speed nötig. So ein Riesenkäfer treibt dann auch die Kosten bei der Platinenfertigung in die Höhe - wass macht man mit dern ganzen io's ? Könnte mir schon Vorstellen das das komisch wirkt - Kanonen Spatzenmäßig.
Böser K. schrieb: > Ethernet ist vor allem interessant, weil man das > Modul einfach an das LAN-Netzwerk anschließen kann Ethernet ist in der Industrie so eine Sache. Zum einen ist da die Latenz, selbst eine uralte PCI/RS485 Karte ist Faktor 100 schneller (bei der Baudrate natürlich nicht, aber darauf kommt es meist nicht an). Zwar gibt es Echtzeit-Ethernet und PROFINET etc. aber der Aufwand dafür ist (zu) hoch. Dann ist da noch die physikalische Verbindung. Wünschenswert wäre Zweidraht und da wird schon länger daran rumgebastelt, aber erst jetzt gibt es erste Lösungen: http://www.nxp.com/products/interface-and-connectivity/wired-connectivity/ethernet/open-alliance-broadr-reach-automotive-ethernet-phy:TJA1100HN Alles in allem ist USB in der Industrie eigentlich Standard, alle Messgeräte und -karten kommen damit, und mit USB-C sollte es noch besser werden.
Moby A. schrieb im Beitrag #4693417: > Soweit ich das überblicke wird da nur die Frage aufgeworfen, aber nix > genaues weiß man nicht Zum einen: wenn Hersteller A in 2015 verkündet wir machen eine ganz neue 8-Bit Generation: EFM8 und 2016 kommt davon die vierte Produktfamilie und Hersteller B sagt in 2015 und 2016 zum XMEGA genau gar nichts, was soll der Entscheider in der Industrie davon halten. Zum anderen ist es doch schon deutlich: 2015 product selection guide had a new product column that was empty for XMEGA. Jetzt schau mal in den aktuellen product selection guide ...
Moby A. schrieb im Beitrag #4693501: > Atmels > 8-Bitter sind gut, was sich auch in einer breiten Produktpalette > widerspiegelt. Das sehe ich auch so, ich wüsste nicht was schlecht an ihnen wäre. Klar, sie können für die ein und andere Anwendung unbrauchbar sein aber deshalb muss das ja nicht bedeuten, dass die AVRs generell schlecht sind. Können sie IMO auch nicht sein, sonst wäre Atmel damit ja nicht so erfolgreich gewesen was sich u.a. auch an dieser Seite/diesem Forum hier zeigt.
Also, ich halte M7 auch für übertrieben für meine Anwendung. Aber wie gesagt, wenn ich Ethernet haben will, spielt es schließlich keine Rolle ob ich direkt M7 nehme, oder M0+ mit externe Ethernet IC nehme...
Moby A. schrieb im Beitrag #4693521: > ohne echte Neuerungen Bei EFM8 wurden genau die Kundenanforderungen an die XMEGA Weiterentwicklung realisiert, die Atmel ignoriert hatte z.B. ADC mit höherer Auflösung, mehr DACs, 16-Bit PWM, schneller, kleinere Packages, geringerer Stromverbrauch. Und das alles bei deutlich geringerem Preis. M. K. schrieb: > sonst wäre Atmel damit ja nicht so erfolgreich gewesen Das wurde ja nun schon öfter hier diskutiert, was den Unternehmensgewinn betrifft waren sie damit alles andere als erfolgreich. Mit ein Grund für den Erfolg der Übernahme durch Microchip.
Horst schrieb: > oder wirklich programmieren kann. Es geht doch nur um die Hardware. Programmieren kann man die ganz normal in C.
Horst schrieb: > oder wirklich programmieren kann. Es geht doch nur um die Hardware. Programmieren kann man die ganz normal in C. Chris F. schrieb: > Jo, Cortex M7 mit 216MHz, FPU, 2M-Flash und 512K-Ram. > Hoffentlich reicht das für drei Ventile ... Hol Dir bei Horst den Orden. Auf nem Nano programmiere ich das und wenn alles klappt, kommt es auf einen Tiny10 und feddich.
Nun ja, ich bin wahrlich kein Freund von Overengineering und das Argument, daß man als Profi in erster Linie NICHT seinem Basteltrieb nachgibt sondern erstmal recherchiert, was es möglichst fertig am Markt zu kaufen gibt ist auch nicht von der Hand zu weisen. Auf der anderen Seite ist Hardware heute SPOTTBILLIG, da kann man auch ein paar Ventile mit einem 1000x überdimensionierten uC/embedded PC ansteuern. Der Schwerpunkt verlagert sich so oder so seit Jahren zur Software bzw. GUI und Netzwerkfähigkeiten. Der Low Level Kram ist nur noch notweniges Übel ;-) Außerdem spielen die Hardwarekosten bei dieser Kleinststückzahl kaum eine Rolle, ein Arbeitstag des Hiwis ist teurer als jeder Monster-ARM-uC. Da lohnt sich eine Hardwareminimierung keine Sekunde. Auf der anderen Seite ist eine Plattform ala Raspberry Pi & Co eher sehr schlecht geeignet, um PWMs und halbwegs schnelle Regler zu bauen, da wird dann oft ein kleiner AVR als Arbeitssklave per SPI angeschlossen, der große Bruder macht nur den Netzwerk- und GUI-Kram. Also sollte man sich fragen, was man will bzw. darf? Geht es in erster Linie um das schnelle, professionelle Lösen eines Problems? -> Fertiglösung mit minimalem Anpassungsaufwand suchen und kaufen. Geht es um der Erwerberben und Nachweisen von Fertigkeiten beim Thema uC Design, Doku, Lösungsfindung von ganz unten an? -> Elementare Teilkomponenten kaufen und von der Pike an alles neu und angepasst machen. Die Kosten für wenige Exemplare spielt man damit aber nie wieder rein. Institute sind ja oft recht sozialistische, chaotische Einrichtungen, wo Effizenz und Professionalität nicht so wirklich gefragt sind, da darf viel gebastelt werden . . . ;-)
Moby A. schrieb im Beitrag #4693633: > Prinzipielle Hindernisse sollte es da eigentlich nicht geben Selbst wenn es die nicht geben sollte schätze ich mal Microchip will die PIC32 Minis pushen, schau mal auf die Preise: http://www.microchip.com/promo/pic32mm Moby A. schrieb im Beitrag #4693633: > Masse an Produkten davon gar nicht wesentlich profitiert In dieser Masse sind aber billige 8051 aus China z.B. STC oder eben PIC und keine hochpreisigen ATtinys
Lothar schrieb: > Das wurde ja nun schon öfter hier diskutiert, was den Unternehmensgewinn > betrifft waren sie damit alles andere als erfolgreich. Mit ein Grund für > den Erfolg der Übernahme durch Microchip. Ja, das wurde hier schon oft diskutiert. Fakt ist aber auch: Kein Unternehmen hält über Jahre/Jahrzehnte an einem Produkt/einer Produktlinie fest, dass keinen Erfolg verspricht. So schlecht, wie hier im Forum immer wieder mal die AVR-Linie geredet wird, kann sie nicht sein. Vor allem da die Mikrocontroller-Sparte die Cash-Cow von Atmel ist (hab was um die 70% von Gesamtumsatz im Kopf, den Atmel aus den uCs erwirtschaftet).
Also, auf andere Seite, habe ich mir Universal Bee EFM8 angeschaut. Diese kann zwar kein Ethernet,hat aber USB, ist aber deutlich billigere (10 Euro Vs 1.5 Euro) und elegantere Lösung, so dass ich die Leistung von STM32F7 nicht verschwende. Alternative kann ich eine externe Ethernet IC aussuchen, soll ja nicht die Welt kosten .
Chris F. schrieb: > Arm (M3) ist doch noch schlimmer als Arduino. Nimm direkt einen 8-Bit > AVR, GCC-Tutorial dazu gibt es hier auf der Seite. What a shit? Du kennst den EFM, dann bleibe dabei. Auf alle Fälle solltest du beim ARM bleiben.
Moby A. schrieb im Beitrag #4693738: > Das wird man hoffentlich nicht so schnell einstampfen. Du glaubst deinen eigenen Quark ja schon nicht mehr. Wie willst du damit andere überzeugen?! Und nur weil du in Produkten AVRs findest, sind das erstens noch lange keine Neuentwicklungen und zweitens kann der Hersteller damit eines Tages genauso auf die Schnauze fallen, wie es bei dir passieren wird. Wobei dein Assembler-Gefrickel ja sowieso nur Hobby und kein professionelles Produkt ist, sodass das auch egal ist.
Hugo schrieb: > Chris F. schrieb: > Arm (M3) ist doch noch schlimmer als Arduino. Nimm direkt einen 8-Bit > AVR, GCC-Tutorial dazu gibt es hier auf der Seite. > > What a shit? > Na klar, ist doch logisch: AVR > Arduino > M3 Mich würde ja manchmal schon interessieren, in wie vielen Buden so Ingenieure sitzen, die "haben wir immer schon so gemacht" täglich zelebrieren.
Horst schrieb: > Du glaubst deinen eigenen Quark ja schon nicht mehr. Die AVRs lassen mich nicht glauben sondern wissen, alles andere dichtet Dir Deine blühende Fantasie ;-) > Und nur weil du in Produkten AVRs findest, sind das erstens noch lange > keine Neuentwicklungen und zweitens kann der Hersteller damit eines > Tages genauso auf die Schnauze fallen Auf die Schnauze fallen kann jeder Produzent dessen Zulieferer nicht mehr liefert. So einfach ist das. > wie es bei dir passieren wird Hast Du eine Ahnung. Der Bastler ist fein raus und frei aller Abhängigkeiten. Vor allem wenn er noch vor Monaten günstig seine Vorräte bis zum Lebensende aufgefüllt hat ;-) > Wobei dein Assembler-Gefrickel ja sowieso nur Hobby und kein > professionelles Produkt ist, sodass das auch egal ist. Das interessiert hier zufälligerweise rein gar nicht. Oder gehts hier gerade um Assembler oder Hobby- vs. Kaufprodukt? Professionell schreib ich schon gar nicht weil das was man so kaufen kann manchmal in der Qualität unter aller Sau ist ;-(
:
Bearbeitet durch User
Moby A. schrieb: > Die AVRs lassen mich nicht glauben sondern wissen, alles andere dichtet > Dir Deine blühende Fantasie ;-) Eben hieß es noch "hoffentlich". > Auf die Schnauze fallen kann jeder Produzent dessen Zulieferer nicht > mehr liefert. So einfach ist das. Schon klar, aber bei dem einen ist es wahrscheinlicher als bei dem anderen. Diversifikation nennt man das im Finanzbusiness. >10 Hersteller bieten ARM-Core basierte Mikrocontroller, und genau einer AVR basierte. Dieser eine wurde von einem Konkurrenten aufgekauft. Bei welchem ist Nichtlieferung bloß wahrscheinlicher, hmmm... > Hast Du eine Ahnung. > Der Bastler ist fein raus und frei aller Abhängigkeiten. > Vor allem wenn er noch vor Monaten günstig seine Vorräte bis zum > Lebensende aufgefüllt hat ;-) Ich sag ja für Bastler ist es wumpe, aber TO will Erfahrung für den Beruf sammeln, und nicht Assembler-Frickelein machen. > Das interessiert hier zufälligerweise rein gar nicht. Doch, s.o.
Moby A. schrieb: > Oder gehts hier gerade um Assembler oder Hobby- vs. Kaufprodukt? Geht um letzteres, der TO will es für den Beruf lernen. > Professionell schreib ich schon gar nicht weil das was man so kaufen > kann manchmal in der Qualität unter aller Sau ist ;-( Liegt vielleicht daran, dass du immer die Produkte mit AVRs drin kaufst ;) (siehe oben) SCNR
Horst schrieb: > Eben hieß es noch "hoffentlich". Tja ich sitze leider nicht im Microchip-Vorstand. > Schon klar, aber bei dem einen ist es wahrscheinlicher als bei dem > anderen. Diversifikation nennt man das im Finanzbusiness. >10 Hersteller > bieten ARM-Core basierte Mikrocontroller, und genau einer AVR basierte. > Dieser eine wurde von einem Konkurrenten aufgekauft. Bei welchem ist > Nichtlieferung bloß wahrscheinlicher, hmmm... Verteil Deine Wahrscheinlichkeiten wie Du magst. Fakt ist: Der 8-Bit Markt wächst unaufhörlich weiter und damit auch der Markt für AVR & Co. Hast Du eine Ahnung warum das so ist ??? > Ich sag ja für Bastler ist es wumpe, aber TO will Erfahrung für den > Beruf sammeln, und nicht Assembler-Frickelein machen. Ich glaub, Dir ist wirklich entgangen, daß ich dem TO hier zu Null,nix Asm empfehle. Das ist für die fetten ARM-Brummer die ihm vorschweben ohnehin uninteressant. Einfaches Asm ist was für einfache MCs ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Tja ich sitze leider nicht im Microchip-Vorstand. Das wäre auch zu witzig, wenn es dann keine C-Compiler mehr geben würde, weil ASM eh besser ist :) > Fakt ist: Der 8-Bit Markt wächst unaufhörlich weiter und damit auch der > Markt für AVR & Co. Mag ja sein, aber mal geguckt wie parallel der 32-bitter Markt gewachsen ist? Für Hobby-Arduinöler kann der Kram ja noch ein bisschen exisitieren meinetwegen. Aber der Rest ist und wird weiterhin ARM sein. > Ich glaub, Dir ist wirklich entgangen, daß ich dem TO hier zu Null,nix > Asm empfehle. Sag bloß, du bist von deiner Krankheit geheilt?! :P > Das ist für die fetten ARM-Brummer die ihm vorschweben > ohnehin unpraktikabel. Warum? Soo viel komplizierter als AVR-Asm sind die meisten Dinge auch nicht.
Hör mal auf dauernd alles zu editieren, sonst versteht nachher keiner mehr was ^^
Horst schrieb: > Hör mal auf dauernd alles zu editieren, sonst versteht nachher keiner > mehr was ^^ Manches kann man nicht deutlich genug machen damit es möglichst viele verstehen ;-)
Horst schrieb: > Das wäre auch zu witzig, wenn es dann keine C-Compiler mehr geben würde, > weil ASM eh besser ist :) Aha. Du willst mich also hier auf eine Asm-Diskussion festnageln. Danach hat der TO aber schon gar nicht gefragt. Verstanden? > Mag ja sein, aber mal geguckt wie parallel der 32-bitter Markt gewachsen > ist? Für Hobby-Arduinöler kann der Kram ja noch ein bisschen exisitieren > meinetwegen. Aber der Rest ist und wird weiterhin ARM sein. Glaube was Du willst. Ich sag Dir: 8-Bit wirds noch ewig geben. Da wird von den aktuellen ARM 64 Bittern schon lange keine Rede mehr sein. > Sag bloß, du bist von deiner Krankheit geheilt?! :P Driftest Du nun unter die Gürtellinie ab? Einfaches Asm ist ein Mittel der Wahl bei einfachen 8-Bittern. Ob Dir das sympathisch ist oder nicht. > Warum? Soo viel komplizierter als AVR-Asm sind die meisten Dinge auch > nicht. Es reicht locker um drauf verzichten zu können- wenn es die Anwendung ermöglicht ;-)
Moby A. schrieb: > Verstanden? Aber, aber, ...., das entspricht nicht der Erwartungshaltung an dich. Das ist doch langweilig. Moby A. schrieb: > Glaube was Du willst. Ich sag Dir: 8-Bit wirds noch ewig geben. Da wird > von den aktuellen ARM 64 Bittern schon lange keine Rede mehr sein. Solange es dich noch gibt, vermutlich schon. Moby A. schrieb: > Driftest Du nun unter die Gürtellinie ab? Ob die AVR/ASM-Krankheit unter deiner Gürtellinie lokalisiert sind, mag ich mir garnicht vorstellen ;-)
Moby A. schrieb: > Es reicht locker um drauf verzichten zu können- wenn es die Anwendung > ermöglicht ;-) Langsam komm ich dahinter: du bist nur so ein ASM Fanatiker, weil alle Anwendungen auf AVRs nicht drauf verzichten können, weil die Controller sonst zu lahm wären ^^
Deine letzten Beiträge sind nicht mehr "Von Horst" sondern im Prinzip nur noch "Vollhorst" ;-) Wenn Du gern mit mir über Asm diskutieren möchtest mach einen neuen Thread auf.
:
Bearbeitet durch User
Das läuft schon unter der falschen Überschrift... Aber Du darfst davon träumen ;-) Gute Nacht.
Moby A. schrieb: > Das läuft schon unter der falschen Überschrift... > Aber Du darfst davon träumen ;-) > Gute Nacht. Ach komm schon, sei kein Spielverderber
@Böser Kommunist: Wenn Du Dich demnächst bei Deinem zukünftigen Arbeitgeber vorstellst, wird das Vorweisen eines realisierten Projektes Dein kleinstes Problem sein. Wenn Du Dich nicht bemühst eine halbwegs ordentliche Rechtschreibung hinzulegen, wird es nicht erforderlich sein etwas vorzuweisen. Deine Rechtschreibung ist für einen angehenden Ingenieur unter aller Sau. Wenn Du mit der gleichen Sorgfalt Deine Projekte entwickelst, dann werden diese auch nur von mäßiger Qualität sein. Im Übrigen ist es keine Schande für ein Projekt einen RasPi, Arduino oder was es sonst noch so gibt zu nehmen. Einfach mal Aufwand und Nutzen abschätzen. Der Zeitaufwand für eine ordentlich konstruierte eigene Hardwarelösung, inclusive deren Umsetzung, steht bei einem so kleinen Projekt in keinem Verhältnis zum Nutzen. Investiere die eingesparte Zeit lieber in eine ausgefeilte Steuersoftware. Dein zukünftiger Arbeitgeber wird dies genau so sehen.
Horst schrieb: > Wer AVRs noch in Neuentwicklungen einsetzt, dem ist nicht zu helfen. Jo, warum werden die Dinger dann bei Neuentwicklungen von Steuergeräten und Haushaltsgeräten eingesetzt? Wieso sollte ich denn ohne Bedarf eine teurere, komplexere und neuere Architektur für eine Neuentwicklung einsetzen? Ich arbeite so, dass die Produkte zuverlässig die Spezifikation erfüllen. Natürlich sind manche der exotischeren und teureren AVRs mit Vorsicht zu geniessen und da muss bei einer kompletten Neuentwicklung von komplexeren Produkten untersucht werden, ob andere Plattformen sinniger sind. Ich fände es besser wenn sich ein Berufseinsteigeringenieur bewirbt und mit einem AVR plus Zusatzbausteinen wie Ethernetcontroller und EEPROM zeigt, dass er die Ansteuerung von den Bauteilen begriffen hat und eine Lösung schnell, effektiv, günstig und mit Standardteilen hinbekommt. Ein hochgezüchtetes Entwicklungsboard für 200€ holen, das schon alles kann, dann ein bissel Software aus den Beispiel-libs zusammenbauen und am Ende ein Referenzdesign auf Platine umsetzen ist 08/15. Die Wahrscheinlichkeit, dass man mit irgendeinem Board oder MC genau die Plattform trifft die spätere Arbeitgeber einsetzen ist sehr gering. Wenn mir einer erzählt er baut für Ethernet-Labview-Abfrage und 3 Ventile einen M7 ein, lasse ich mir erst einmal erklären wieso. Wenn er dann sowas in Richtung "wer nur einen Hammer hat, für den sieht jeder Nagel gleich aus" und "Kleinere Chips sind Kindergarten" erzählt ergibt das höchstwahrscheinlich nicht den von ihm gewünschten Effekt.
Chris F. schrieb: > Horst schrieb: >> Wer AVRs noch in Neuentwicklungen einsetzt, dem ist nicht zu helfen. > > Jo, warum werden die Dinger dann bei Neuentwicklungen von Steuergeräten > und Haushaltsgeräten eingesetzt? Nach meiner Kenntnis ist das nicht so. Bitte Beispiele nennen. Chris F. schrieb: > Wieso sollte ich denn ohne Bedarf eine teurere, komplexere und neuere > Architektur für eine Neuentwicklung einsetzen? EFM8 ist besser und deutlich billiger, PIC war schon immer deutlich billiger. Hier mal nur ein Beispiel wo man lange an AVR festgehalten hat, bis es nicht mehr ging. http://fpv-racer.net/blheli-s-firmware-for-busybee-esc-aikon-sefm-30a-dys-xs20a-dys-xs30a/
> Bastlerkacke > Was MS oder Apple damit zu tuen haben soll, weiß ich nicht. Sowohl Microsoft als auch Apple haben als Bastelbude begonnen und beide Firmen hatten ihre ersten erfolgreichen Computer bewusst nicht mit dem damals aktuellsten bzw Leistungsstärksten Mikroprozessor gebaut.
@Stefan Us (stefanus) >> Was MS oder Apple damit zu tuen haben soll, weiß ich nicht. >Sowohl Microsoft als auch Apple haben als Bastelbude begonnen und beide >Firmen hatten ihre ersten erfolgreichen Computer bewusst nicht mit dem >damals aktuellsten bzw Leistungsstärksten Mikroprozessor gebaut. So ein Käse. Microsoft hat NIE Hardware gebaut (und komm mir jetzt nicht mit der Microsoft-Maus). Aus Softwaresicht war Microsoft ganz am Anfang schon recvht innovativ, wenn gleich dort auch taktisch klug eingekauft und weitrverkauft wurde (DOS) Apple hat sehr wohl auch am Anfang auf neue, leistungsfähige CPUs gesetzt, so z.B. den 68000.
Das Problem bei den efm8 ist mMn der bescheidene C-Compiler. Der generiert wirklich relativ schlechten Assemblercode. Teilweise kann man mehr als Faktor 2 in codesize durch inline Assembler herausholen. Memcmp braucht knapp 400 Bytes mehr als eine entsprechende Schleife. Kein function inlining. Der Controller ist nicht schlecht, aber der Core wird ineffizient sobald xdata Zugriffe benötigt werden. Früher habe ich oftmals auch den avrgcc bemängelt, aber der ist gerade mit lto deutlich besser. Ich finde jedenfalls dass man aus den Controllern deutlich mehr herausholen könnte, bzw. man so überproportional viel Flash benötigt.
avr schrieb: > Das Problem bei den efm8 ist mMn der bescheidene C-Compiler Welcher? SDCC? Silabs hat doch den KEIL C51 eingekauft, der mal 3000 EUR pro Lizenz gekostet hat. Der ist so schlecht nicht. > Memcmp braucht knapp 400 Bytes mehr als eine entsprechende Schleife Meinst Du wirklich memcmp() oder doch memcpy()? Statt memcpy() nimmt man bei EFM8 eher DMA, das funktioniert tatsächlich ohne CPU Holdups z.B. für ADC oder USB. Wo man aufpassen muss, sind Flash Waitstates. Auf ein Array im Flash kann man nur bis 25 MHz CPU CLK ohne Waitstates zugreifen. Bei 50 oder 72 MHz sollte man ein auch READ-ONLY kritisches Array in XDATA machen.
Kann man den sdcc für die efm8 überhaupt nutzen? Ich meinte den Keil c51 und den Assemblercode von dem finde ich ziemlich schlecht. DMA haben übrigens nicht alle.
avr schrieb: > Kann man den sdcc für die efm8 überhaupt nutzen EFM8BB1 = C8051F850 EFM8SB2 = C8051F920 EFM8UB2 = C8051F380 EFM8BB2 und 3 und EFM8LB1 mit demselben Makefile wie EFM8BB1 EFM8SB1 und EFM8UB1 hab ich nicht da, haben aber denselben Core, also geht vermutlich. http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants
Mein Gott,Kinder... Ich wollte nur einen Ratschlag, und ihr habt hier so ein Theater gemacht:) Auf jedem Fall hab ich auf M7 verzichtet. Ich nehme entweder EFM8 Universal BEE (wegen USB-Schnittstelle) oder EFM32 (z.B. EFM32HG).
:
Bearbeitet durch User
Böser K. schrieb: > Ich nehme entweder EFM8 Universal BEE ... oder EFM32 (z.B. EFM32HG) Habe hier EFM8 und LPC ARM parallel und hätte nichts gegen einen Umstieg auf EFM32: Happy Gecko Board liegt im Schrank. Geht aber nicht, den Silabs schafft folgendes nicht: EFM32 Package mit T>85°C und irgendwas was noch gut lötbar für Tests ist: QFP48 gehört da nicht dazu. High Memory IRQ Vector und USB Bootloader, am besten als ROM wie bei LPC. Damit man vernünftig ohne Programmer flashen kann.
Moby A. schrieb im Beitrag #4694519: > fehlt DMA sowie eine ganze Reihe innovativer Features wie Event-System > Crypto-Engine oder Custom Logic Manual genauer lesen: DMA heisst dort nicht so sondern läuft beim ADC als Autoscan to Memory und bei USB als FIFO Management. Custom Logic heisst Configurable Logic Ein Event-System ist unnötig komplex für die Anwendungsfälle der EFM8 :-)
Moby A. schrieb im Beitrag #4694714: > daß Du nicht gleich wieder 32-Bit ARM empfielst Immer wenn es von Steuerung zu Regelung geht, mit Fixpoint Arithmetik oder Float oder Einsatz von externem ADC mit >16-Bit, geht es natürlich vom EFM8 zum LPC ARM Was ist nun damit: Lothar schrieb: > Warum machst Du Dir nicht selbst ein Bild: im heise MAKE dem Magazin für > Arduino Jünger gibt es ein LPC810 DIP-8 Projekt mit > Steckbrett-Schaltplan und DSP-Programm zum abtippen: > > Audioeffekte mit ARM-Achtbeiner > > http://www.heise.de/make/inhalt/2016/3/86/
Moby A. schrieb im Beitrag #4694741: > Solche Anwendungen hab ich nicht, wie wohl die meisten hier Die meisten Hobby-Projekte zur Regelung sehen genau so aus, einfach mal auf Youtube ansehen z.B. http://aimagin.com/blog/inverted-pendulum-project-stm32f4/ > Heizungs-Regelung kommt auch ganz wunderbar mit 8 Bits aus Eigentlich nicht, auch nicht im Hobby-Projekt, wenn man PTs verwendet, siehe hier. Es wird ein ATmega328 für den 24-Bit ADC verwendet, was nicht geschickt ist: http://www.energiesparhaus.at/denkwerkstatt/allgemein_a.asp?Thread=29583_3
Lothar schrieb: > Eigentlich nicht, auch nicht im Hobby-Projekt, wenn man PTs verwendet, > siehe hier. Es wird ein ATmega328 für den 24-Bit ADC verwendet, was > nicht geschickt ist: Naja, ich denke mal da wollte nur jemand mal mit einem 24 bit ADC spielen. Wenn man sich nur mal die Kabelkreuzung vom AD-Wandler-Board zum Atemga328-Board anschaut wird klar: Hier gehen mindestens 10 der 24 Bit im Rauschen unter. Und für die Anwendung hätte auch der 10 bit AD-Wandler des Atmega328 völlig genügt.
Lothar schrieb: > http://aimagin.com/blog/inverted-pendulum-project-stm32f4/ Servus, ist ein altes Projekt von mir. Das Disco Board 168MHZ ist sowas von unterfordert. Selbst ein Double oder Tripel Pendulum ist keine Herausforderung für den µC. Instabile Systeme brauche oftmals hohe Abtastzeiten. Heute mache ich fast alles mit stm32f103 (blue pill). Die Kosten sind nahezu lachhaft. Man muss halt die Erfahrung haben, um abwiegen zu können, welcher µC bei welchen Projekt passt. Fürs Hobby zählt nur das Preis-Leistung Verhältnis. Bei einer Firma würde ich erstmal Fragen, was dort bevorzugt wird...
M. K. schrieb: > denke mal da wollte nur jemand mal mit einem 24 bit ADC spielen Völlig richtig. Kann aber auch sein, der ADS1248 ist ja nicht nur ein ADC sondern eine komplette PT-Messbrücke (mit Dual-IDACs) die kann man sich also bei der Verwendung sparen, und die 24-Bit waren nur Bonus. Wenn man aber 24-Bit Auflösung tatsächlich braucht z.B. bei einem Prozessofen mit PT1000 und 0.01K Auflösung und +/-0.05K Genauigkeit, dann nimmt man zur Regelung eben einen 32-Bit uC Moby A. schrieb im Beitrag #4694822: > der AD-Wandler hat 10 Bit Schau es lieber nochmal an: http://www.ti.com/product/ADS1248
Lothar schrieb: > Wenn man aber 24-Bit Auflösung tatsächlich braucht z.B. bei einem > Prozessofen mit PT1000 und 0.01K Auflösung und +/-0.05K Genauigkeit, > dann nimmt man zur Regelung eben einen 32-Bit uC Und 32 bit genau warum? Ich denke, so pauschal kann man das nicht sagen. Mit einem 32 bit uC ist man vielleicht auf der sicheren Seite, ein 8 bit uC könnte aber auch genügen. Das muss man aber fallabhängig machen.
Kleines Beispiel aus der Praxis: Wir verwenden EFM32 (mit IAR) weil diese Controller ein paar Features haben, die keine andere Controllerfamilie bietet. Die Controller langweilen sich (schlafen) zwar die meiste Zeit, aber sie passen exakt zum Problem. Für andere Anwendungen haben wir neben MSP430 und ADuC702x mehrheitlich 8bit-AVRs eingesetzt - einfach, gut verfügbar und schnell programmiert (mit C/C++ natürlich). Seit einiger Zeit lässt Atmel aber den Support für die IDE schleifen und die Fehler häufen sich: Also Umstieg auf EFM8 (ebenfalls mit IAR), weil es dort für die Zukunft Unterstützung vom Hersteller geben wird und diese Controller weitaus mehr Features haben als die AVRs. ATXMega fassen wir aus guten Grund gar nicht erst an (AT91SAM7xxx!). Sicher trauern wir den einfachen 8bit-AVRs ein wenig nach, aber die Vorteile der EFM8 überwiegen. Übrigens; eine wirklich "einfach" zu programmierende 32bit-Arm-Controllerserie war/ist die ADuC70xx-Serie. Die hat alles was man braucht. Vielleicht kommt sie demnächst in anderer Form wieder. Blackbird
Moby A. schrieb im Beitrag #4695350: > Bei Atmels 8 Bittern gibts nach wie vor wesentlich mehr Auswahl in > unterschiedlichsten bastlerfreundlichen Gehäusetypen bei voller 5V > Kompatibilität. Bastlerfreundliche Gehäuse interessieren auch nur Bastler, das ist Dir schon klar, oder?!
Michael S. schrieb: > Bastlerfreundliche Gehäuse interessieren auch nur Bastler Auch mehrere Kunden waren nicht erfreut als Silabs die DIP Packages abgekündigt hat. Schliesslich muss man doch mal was auf Steckbrett testen. Bei den EFM8 nutzen wir dafür z.B. selbstgemachte SO-16/SIP-16 Steck-Kärtchen. Silabs liefert übrigens die EFM8 auch als Die, der Kunde kann dann selber DIP packagen lassen, ganz toll :-)
Autor: Moby AVR (moby-project) .... Wie oft willst Du es denn noch vorgekaut bekommen? Willst Du mir jetzt sagen, ein kleiner Bastler weiss es besser als die Entwicklungsabteilungen einer großen internationalen Firma? Als Hobby-Anwender habe ich auch noch genügend Bestände an AVRs. Wenn die weg sind, werden auch bei mir zu Hause EFM8 als Ersatz eingesetzt. Schon weil die Programmier- und Debug-HW unschlagbar günstig ist, da hat sich Atmel ebenfalls verschlechtert. Um es mal aus Deiner Sichtweise zu sehen: Ich habe auch noch jede Menge Z80 und Z8 nebst aller Peripherie zu Hause, das Wissen dazu, die Hardware und die Tools. Soll ich jetzt hier alle bekehren, so wie Du es machst? Nein, die Entwicklung ging weiter - auch hin zu den AVRs! Und jetzt geht sie schon wieder weiter. Auch wenn Du heulst. Deine diesbezüglichen Posts haben schon Spam-Charakter. Blackbird
Man braucht doch nur mal bestimmte Geräte, Steuerungen, halt alles wo ein uC werkelt, zerlegen. Und was findet man dort? Bei Weißware viel Cypress. In vielen anderen Geräten sind PIc's verbaut. In unseren Steuerungen ist Infineon sein. AVR's sehe ich eher selten.
Um die Unsicherheit des TO bezüglich der Fragen bei einem Einstellungsgespräch wenigsten etwas zu lindern: Egal welcher Controller jetzt verwendet wird - wenn man sachlich korrekt in ein paar Sätzen die Entscheidung für diesen Controller in dem Projekt(en) begründen kann, ist das viel mehr wert als eine Controllerfamilie zu nennen (und zu hoffen, dass der in der Firma auch ganz oben auf der liste steht). Dann hat der Fragesteller auch mitbekommen, dass da noch andere Controller in der Auswahl waren die der TO bei anderen Randbedingungen sonst auch verwendet hätte. Das ist Flexibilität und "Überblick behalten". Wenn man aber sagt: "Ich habe in einem Forum gelesen, das dieser (von mir eingesetzte) Controller der Beste/Schnellste/Einfachste ... ist", dann hat man verloren. Blackbird
Ihr habt alle keine Ahnung. Wie üblich. Der XMEGA ist für extrem viele Anwendungen ausreichend und extrem konfigurierbar. Der A läuft stabil bis 64 MHz und kann via PLL stabil 200 MHz Timer generieren. Wer mehr braucht, macht entweder Bildverarbeitung oder kann nicht programmieren. Obendrein hat der einen 150nA Sleep Mode (mit internem Aufwachtimer!). Damit läuft ne Knopfbatterie 10 Jahre lang problemlos durch. Und der AVR ASM ist der beste ASM, den ich bisher gesehen habe und ich habe mir wirklich viele uC Befehlssätze angeschaut. Ganz klar, nur mit AVR kann man noch vernünftig ASM programmieren. 32 Register sind einfach ein Traum. Bei nur 16 Registern artet das doch schnell mal in ein Gepushpoppe oder Ram-Geschubse aus. Das ist auch der Grund, warum ihr Loser einen fetten ARM braucht. Wahrscheinlich laufen eure ADC-Loops im RAM ab. Da geht unter 1 GHz natürlich nichts mehr mit Ventilsteuerung. Obendrein braucht der xmega für ein sbi und cbi nur 1 Takt. Und wenn man erstmal vernünftige ASM Makros hat, liest sich der Code auch wesentlich angenehmer. Ich empfehle einen AVR Tiny mit ASM. Da lernt man eine Menge über die Internas und wird nicht mit extrem komplexen RAM-Meachanismen und Pipelining gequält. Ich habe mit einem 13A angefangen und würde das auch heute noch jedem so empfehlen. Mehr Pins? 24A. Mehr Pins? 88A. Mehr IO und mul? Dann ist es auch ein grösseres Projekt und dann gönnt man sich auch direkt einen xmega. Die megas nutze ich nicht, da ich die Pseudoexperten der Arduinofraktion nicht ausstehen kann und deshalb auch eine Abneigung gegen mega habe. Ist aber rein subjektiv.
ASM Superprofi schrieb: > Die megas nutze ich nicht, da ich die Pseudoexperten der Arduinofraktion > nicht ausstehen kann und deshalb auch eine Abneigung gegen mega habe. > Ist aber rein subjektiv. Ja, das glaub ich dir gern, dass das rein subjektiv ist denn die Megas sind einfach nur große Tinys ;)
Ne, mal ernsthaft: Ist wirklich eine reine Kopfsache, weil ich schon öfters erlebt habe, wie ein Volldepp ein Shield anschliesst und dann meint, er wäre Elektronikexperte. Aber als dann eine LED nicht brannte "Hol mal Multimeter" "Hab ich nicht" ... WTF??????????????????
Moby A. schrieb im Beitrag #4696224: > Blackbird schrieb: >> Wie oft willst Du es denn noch vorgekaut bekommen? > > Statt mir hier irgendwas vorzukauen liefer mir lieber ein paar plausible > Antworten auf meine ganz konkreten Fragen... Ich fürchte aber daran > scheiterts ;-) Konzentriere Dich auf die Fragen des TO. Den kannst Du von Deiner persönlichen Meinung überzeugen. Das Missionieren anderen User, die auch nur die Fragen des TO beantworten, gehört nicht in einen Thread hinein und verstößt deutlich gegen die Nettiquette. Sollte ich eigentlich melden! Blackbird
"...Für unsere Labor brauchen wir 3 Module für die Ventilsteuerung. Diese werden mit (den) Schrittmotoren gesteuert. Du kannst die Module irgendwo aussuchen oder selbst bauen, es liegt völlig an dir...." Frage: Vorgaben für bereits existierende Klempner-"Hardware" wie Ventile bekannt? Sind das "Heizungsthermostatventile". Oder sind das Druckreduzierer, die "schneller" reagieren müssen? Wird das Ganze evtl noch "visualisiert" für Kontrolltafel? Hmmm.... ciao gustav
>Mein HiWi-Betreuer hat mir folgende Aufgabe gegeben: "Für unsere Labor >brauchen wir 3 Modulen für die Ventilsteuerung. Diese werden mit den >Schrittmotoren gesteuert. Wenn Du was lernen willst, nimm ein Zynq-Board. Da kannst Du Linux drauf laufen und auch VHDL lernen. http://www.myirtech.com/list.asp?id=502 Die Schrittmotoren lassen sich dann im Nanosekundentakt steuern. Wenn es einfach nur laufen soll, kauf eine RAMPs für 30 Euro https://www.roboter-bausatz.de/137/ramps-1.4-kit-mega2560-r3-5-x-a4988-treiber-fuer-reprap-3d-drucker?gclid=CKft3Prm3s4CFeIp0wodBL0Oeg Allerdings wärest Du dann in 3 Tagen fertig mit dem Projekt. Naja, Du könntest ja die restlichen Wochen in ein schönes Gehäuse investieren.
Herbert schrieb: > nimm ein Zynq-Board. Da kannst Du Linux drauf > laufen und auch VHDL lernen Was ich bisher gesehen habe, in den meisten Firmen werden nur deshalb häufig FPGA genommen, weil die Elektrotechniker mal VHDL gelernt haben und sich gegen uC Programmierung lernen sperren. Das läuft dann so dass z.B. mit einer Fuzzy-Regelung das teure FPGA zu 90% voll ist und grade so tut, wo ein viertel so teurer uC mit 100 Codezeilen reichen würde. Sowas wie Zynq wäre dann auch eine Lösung, aber meistens kann dann der der es machen soll entweder gut programmieren oder gut digitale Schaltungen. Was harte Motorsteuerung betrifft muss ich leider zugeben, dass auch die von TI beworbenen TMS Cortex-R noch nicht an die Piccolo DSP rankommen. Bezüglich Linux gilt meiner Erfahrung nach das hier: Lothar schrieb: > in der Automatisierung hat man > gerne eine physikalische Trennung von GUI (Windows, Linux) und Steuerung > (Master-Mikrocontroller, SPS)
Richtig! Ein FPGA-SOC für die einfache Motorsteuerung! Am besten nehme ich dann sowas: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=158&No=526 Mal sehen was der Chef sagt...
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.