Hallo, Am Moment will ich eine kleines SCADA-system für mein Haus bauen (um die Heizung, Alarm, usw. zu Automatisieren). Ich habe mit C-Control Mikrocontrollers (ein Freescale MC68H12 programmierbar unter Basic), und finde dass es: + nicht genug leistung hat (~20000 I/s, nur 140 bytes RAM) + sehr limitiert ist (BASIC Sprache, keine threads, keine Coroutine, usw) + nicht "freundlich" zu ausprüfen ist (keine Simulation oder Debug-Programm). Ich suche eine Lösung dass besser Unterstützung hat (Debug- oder Simulation-Programm, C Sprache Kompiler). Die Hauptpunkte für mich sind: + Besser "Scalability" (durch die Möglichkeit eine RTOS oder ein interruptgesteuert Task-Scheduler zu nutzen). + Freies oder billiges Kompiler + Debug-Programm (ein IDE wenn möglich). Ich habe über einen Paar Möglichkeiten gedacht : + dsPIC 33 mit der IDE+Kompiler+Simulation-Programm von Mikroelectronika. + ARM (Was für IDE/Kompiler/Simulation- oder Debug-Programm gibt es? Was ist und wie funktioniert das JTAG?) Was empfehlen sie? Danke sehr! MfG, Gonzalo MEZA Danke
@Gonzalo Meza >Ich habe über einen Paar Möglichkeiten gedacht : > + dsPIC 33 mit der IDE+Kompiler+Simulation-Programm von >Mikroelectronika. Kann mich mit PICs nciht aus, aber nach allem was man so hört sind die eher Mist. >Was empfehlen sie? AVR, gibts von ganz klein (1k FLASH) bis recht gross (256K FLASH). Weit verbreitet (vorallem hier), leistungsfähig, sehr viele Programmiersprachen in verschiedenen Stufen (Bascom, C, ASM, etc.) MFG Falk
>Ich habe mit C-Control Mikrocontrollers (ein Freescale MC68H12 >programmierbar unter Basic), und finde dass es: > + nicht genug leistung hat (~20000 I/s, nur 140 bytes RAM) > + sehr limitiert ist (BASIC Sprache, keine threads, keine Coroutine, >usw) Was machst du in deiner Steuerung für dein Haus was mit 20000 I/s nicht zu erschlagen ist? Auch wenn ein heutiger Mikrocontroller 8.000.000 I/s aufwärts bietet, der Weg den du einschlägst führt dich möglicherweise nicht dahin, wo du hinwillst. Du willst einen Mikrocontroller in C mit oder ohne RTOS programmieren. >in Basic ..keine threads, keine Coroutine,usw) das gilt für C genauso, wenn man dieses Problem löst. Auf die gleiche Weise wäre es aber auch in Basic lösbar. >nicht "freundlich" zu ausprüfen ist (keine Simulation oder Debug-Programm reinhacken und ausprobieren ist meist die Ursache des Problems, egal wie schnell des Controller ist. > + Besser "Scalability" (durch die Möglichkeit eine RTOS oder ein >interruptgesteuert Task-Scheduler zu nutzen) in einem RTOS mußt du genau wissen was du tust, das zu debuggen ist nur bedingt möglich. Basic hat dir bisher viel abgenommen, dies wird in C nicht so sein. Wenn du deine Steuerung also realisieren willst, dann zeige mal dein Programm damit man sehen kann wo das Problem liegt. Wenn du was neues zum ausprobieren suchst, es gibt auch einen gcc für den 68hc12, wahrscheinlich wäre also auch deine alte Hardware in C programmierbar.
Mit ARM wirst du wahrscheinlich nicht an die Leistungsgrenzen stoßen. Der Einarbeitungsaufwand soll wohl etwas höher sein, als z.B. AVR. AVR sollte für dein Vorhaben genauso ausreichen. Es gibt viele freie und gute Werkzeuge. Sollten also beides gute Alternativen sein.
Saumäßige Projektvorbereitung kann man niemals durch noch soviel Rechenleistung kompensieren. Du mußt Dir nur einenm Ablaufplan machen, wie alles ineinander greift, dann kannst Du es bequem z.B. mit nem ATMega16 erschlagen. Ne Heizungssteuereung ist definitiv alles andere als rechenleistungshungrig. Einen kleinen effektiven Scheduler für Wartezeiten findest Du in der Codesammlung. Peter
Danke sehr für deinen Antworte. @Wolfram: > Was machst du in deiner Steuerung für dein Haus was mit 20000 I/s nicht > zu erschlagen ist? 20.000 I/s ist zu viel um die Heizung zu regeln... 140 bytes RAM, das kann ein Problem sein wenn man threads nutzen wollte. > Du willst einen Mikrocontroller in C mit oder ohne RTOS programmieren. Ich brauche ein Scheduler und ein RS-232 Stack (oder USB-Stack)... Wenn ich eine kleines RTOS nutzen kann, wäre es einfacher. Es gibt auch viele beispiele Schedulers (weighted Round-Robin, usw) und RS-232-Stacks im Internet, und mann sollt nur die µC-Spezifiches teil wechseln. >>in Basic ..keine threads, keine Coroutine,usw) > das gilt für C genauso, wenn man dieses Problem löst. Auf die gleiche > Weise wäre es aber auch in Basic lösbar. Die C-Control Basic++ ist sehr labil, wenn man pointers nutzt. >>nicht "freundlich" zu ausprüfen ist (keine Simulation oder Debug-Programm > reinhacken und ausprobieren ist meist die Ursache des Problems, egal wie > schnell des Controller ist. Stimmt, dass es SEHR wichtig ist. @Peter: Projektvorbereitung/Ablaufpläne/usw, das kenne ich (beruflich bin ich Projektleiter). Und ja, 20.000 I/s ist zu viel um zu steuern eine Heizung (Man kann die Eigenzeit des Systemes in Sekunden messen). Mit ein Thead/Task-Scheduler, gibt es die Möglichkeit um neuen Funktionen einfach beeinzufügen (ein Thread regelt die Heizung, andere die Diebstahlsicherung, ein kontrolliert die Datenkommunikation mit dem PC, usw). Für dem ARM, ich habe ein paar Fragen noch : + Kann man mit die GCC Toolkit (gdb) die µC über JTAG debuggen? + Gibt es andere freie oder billige Kompilers/Simulators/Debuggers für dem ARM? Danke sehr!
@gonzalo also für dein haus-projekt sollte ein avr allemale ausreichend sein. einen richtigen scheduler als solches (multi-threading) ist vollkommen oversized. bau dein programm so um das du mit kooperativen multitasking auskommst. das ist auf jedenfall machbar (vor allem in einem projekt wo du eh nur alle paar sekunden auf irgendwas reagieren musst, ein rtos ist total oversized). hat außerdem den vorteil das es einfacher zu debuggen ist. was meinst du mit rs-232-stack ? meinst du eine art shell mit der du über die rs232 oder usb befehle an das system geben kannst ?
wenn du noch nicht mit Mikrocontrollern vertraut bist, vergiss die ganze RTOS Geschichte ertstmal. Ich empfehle erstmal das Tutorial auf dieser Seite und dann erstmal nen paar LEDs blinken lasse. Die Empfehlung gilt ganz besonders für PC/Windows Programmierer die meinen schon alles zu können. Peter hat schon recht, geht sicher alles bequem auf nem Mega16. Gruß tom
>140 bytes RAM, das kann ein Problem sein wenn man threads nutzen wollte. stimmt Es gibt andere Möglichkeiten das gleiche einfacher zu erreichen, z.B. mit Statusmaschinen. Kann es sein, dass du sonst nur auf "grossen" Mikrocontrollern und dem PC programmierst? Dein Herangehen und Ausdrucksweisen wie "rs-232-stack" legt diese Vermutung nahe. Wenn es nur um eine Heizungssteuerung bei Dir zu Hause geht, kauf Dir ein kleines Board, wo ein Linux drauf läuft da kannst du genau deinen Ansatz umsetzen und es wird auch noch sehr bequem auch beim debugging, nebenbei das ganze mit Webinterface wär das nichts? Andere Variante: Board mit ARM/AVR + debugger ,Einarbeitung in z.B. FreeRTOS ist auf jeden Fall zeitaufwendiger. Wenn du nicht gerade alles selbst löten willst und es richtig ordentlich werden soll, wirst du am Ende sehr wahrscheinlich bei ähnlichen Kosten landen wie bei der vorherigen Lösung.
@Wolfram: Nochmal, danke sehr für deinem Antwort. Du bist recht, ich habe am meistens im Computern (C64, Amiga, PC, PowerPC) programmiert. @TheMason: Ja, ich will die µC "steuern" mit ein PC (um Daten im PC zu speichern, und das HIM im PC zu bauen). @Tom: Ich habe schon ein "blinking LED" mit ein PIC12 im Uni gemacht (in ASM). Wenn ich nur ein "simple" Heizungsteuerung machen wollte, könnte ich es mit ein PIC12 tun (aber nicht auf ASM - Harvard-Architecture-ASM ist nicht für mich). Ich habe es schon mit die C-Control gemacht, aber es ist sehr labil (die OS - der Autor des OSs hat mein Programm nachgeprüft und kann kein Fehler finden; trotzdem die OS hängt auch bei ihm). Am moment soll ich ein Heizungsteuerung machen dass : + 2 Klimaanläge über IR regeln (es soll alle die Befehle der Fernsteuerung des Anlages imitieren). Es sollt die Uhr und Tage des Woches betrachten + die Verbrauch des Anlages überwachen. Sage mir, warum empfehlst du ein AVR statt ein PIC? Was für Vorteile gibt es?
Hallo Für deinen Zweck dürfte ein AVR genau das richtige sein. Du scheinst dich ja mit Elektronik und Programmierung auszukennen, einzig der richtige Mikrocontroller fehlt dir noch. Ein AVR ist leicht zu beschaffen, leicht zu programmieren, AVRStudio bietet sogar einen Simulator, kostet nicht viel und hat locker die Leistung, die du brauchst. Zum Vergleich: Man kann damit (per Software natürlich) ein S/W-Videosignal mit einer Auflösung ähnlich einem Handy-Display generieren. Wegen den PICs: Man hört einfach beinahe nur schlechtes - kennen tu ich sie aber nicht. Gruss Michael
Hallo, jetzt moechte ich mal meinen Senf beitragen. :) Vor ein paar Jahren entwickelte ich fuer meine Firma ein PIC(18F8722) gesteuertes Kontrollsystem fuer eine Marine Umweltmesssystem. Dort musste der PIC das folgende in Real-time bewaeltigen: Die gleichzeitige PI Steuerung von drei Peltier Klimaanlagen fuer die Temperaturkontrolle der eigentlichen teuren Messgeraete in einem weiten Bereich. Gleichzeitige proportionale Innendrucksteuerung von zwei Instrumentkompartments. Wetterstationmessaufgaben. Protokolluebersetzung fuer ein Zusatzgeraet. Alarminterface. Erfassung aller wichtigen Telemetriedaten und AC und DC Schaltfunktionen bis zu 5KW Gesamtleistung (440V, 3-Ph. 230V). Autonomer Selbstschutz des System im Falle einer Communications-Stoerung. Gleichzeitiger Gebrauch beider UARTS mit dem Host und zusaetzlicher Peripherie. Real-time communications mit dem Hostsystem im Einsekundentakt mit ca. 5KB an Telemetrie und Steuerung ueber eine RS485 Leitung mit 57.6Kb/s . Das Programm wurde in CCS-C erstellt und lastet den PIC nur 35% (Zeit) aus bei 16MHz Takt. Ich will damit nur rausttellen dass es PICs auch wunderschoen tun. Realtime Leistung war unschwer zu bewaeltigen durch den sachgerechten Einsatz von State Machines und Interrupts. Diese Systeme funktionieren schon seit ihrer Erstellung jahrelang anstandslos ohne Stoerungen und ich finde dass man mit PICS durchaus Erfolg haben kann. Ich habe auch oft mit AVRs gearbeitet und sehr viel Erfolg und Freude damit gehabt. Meiner Meinung nach macht das wenig Unterschied, ausser dass der AVR etwas schneller ist. In Bezug auf Zuverlaessigkeit, kommt es natuerlich sehr auf den Aufbau und externe Beschaltung an, so dass der PIC/AVR von der Umwelt ausreichend geschuetzt ist. Home automation sollte anstandslos zu bewaeltigen sein, da Geschwindigkeit der Steuerung absolut unwichtig ist. Das Programm duerfte sich hoechstwarscheinlich ueber 90% im Leerlauf befinden. Ich hoffe dass meine Ausfuehrungen etwas helfen mehr Vertrauen zur Leistungsfaehigkeit dieser 8-bit MPUs zu haben und dass es hauptsaechlich auf die Art und Weise des Designs ankommt. Mit C zur Programmerstellung kann man erstaunlich viel anstellen. :) Ich bitte das alles auf keinen Fall als Besserwisserei aufzufassen und will hier niemand auf die Fuesse treten. Gruss, Gerhard
"ich finde dass man mit PICS durchaus Erfolg haben kann. Ich habe auch oft mit AVRs gearbeitet und sehr viel Erfolg und Freude damit gehabt." Das ist doch auch eine Art Bewertung, oder? :-) Der effektivste Prozessor ist immer der, den man gut bis bestens kennt. Das macht mehr oder weniger den Unterschied. Und am Einarbeiten in den PIC bin ich gescheitert, das war nicht meine Schiene. SIcher hat sich dieses Problem durch Hochsprachenprogrammierung entschärft - verschwunden ist es aber nicht. Insofern habe ich den AVR "sofort" kapiert, komme aus der Z80 und 8051 Ecke. Ich könnte mir gut vorstellen, das sich ein ehemaliger 6502-Fan sehr viel leichter mit dem PIC tut.
Ich komme auch aus der Z80/8051-Ecke und hab mir dann erst den PIC angesehen. Da muß man ganz zwangsläufig zu dem Schluß kommen: Nein, sowas total verqueres tue ich mir auf keinen Fall an. Als ich dieses umständliche RETLW gesehen hab, konnt ich mich vor Lachen kaum halten. Dagegen beim 8051: "MOVC A,@A+DPTR", wow wie clever, Indexaddition und Tabellenzugriff in einem Abwasch. Und "MOVC A, @A+PC", wow wie clever, Tabellenzugriff in Interrupts ohne DPTR sichern zu müssen. Und "ANL C, bit", "ORL C, /bit", wow Logikgleichungen einfach so hinschreiben, wie sie sind. Und "DJNZ byte", wow, haufenweise Countdown-Zähler ohne das SREG sichern zu müssen. Man hat sofort gemerkt, die 8051-Entwickler haben total mitgedacht und genau gewußt, wo der Schuh drückt. Etwas geärget hatte mich, daß "PUSH P2" nicht das Ausgangsregister sichert, aber da ich schon lange keinen externen Code-Flash mehr nutze, ist das Schnee von gestern. Man staunt manchmal, auf welche Ideen die PIC-Kids so kommen, was es so für Applikationen mit PICs gibt. Warscheinlich fördert die verquere Architektur sogar den Willen, etwas daraus zu machen. Das Schwierige ist ja immer, die Idee zu haben, das Umrubeln auf nen 8051/AVR ist dann nur noch ein Klacks. Man kann bestimmt viele 8051/AVR-Applikationen auch mit nem PIC machen, aber ohne mich. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.